Working from home a little tonight. Plan: See how far I can get through the new SensorHost model.
In Dropbox/COSMICi_devel/Server Code/src. In model.py. In WiFi_Module._UART_MsgHandler.handle(). Let's comment out the early return and see what happens.
First, archiving the current log files in a new folder with today's date in Server Code/data.
OK, now running the server. It's started.
Started UwTerminal on COM1:; now powering up the Wi-Fi module... OK, the TikiTerm windows for the three (MAIN/AUXIO/UART) connections to the server from the module are up.
Now, in the UwTerminal, let's try manually typing just the first line of CTU output from yesterday's test run:
HOST_STARTING,CTU_GPS,1.9
OK, straightforward error in handle(): The node has no .sensor_host attribute set. We can fix that. A placeholder SensorHost object ought to be created when the node is created. Its initializer just needs the node. OK, SensorNode's initializer now creates the .sensor_host sub-object. Let's try again...
OK, now it's complaining that SensorHost has no .sentMessage() method. I didn't write that yet? Ah, I had done so in ShowerDetectorHost, moving that definition up to SensorHost. (It just dispatches to the _handleMsg() method.) Let's try again...
Hm, for some reason we are getting a SYN (0x16) character:
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 816:_announce | DEBUG: Connection._announce(): Announcing incoming message [ ] to our message handlers...
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 821:_announce | DEBUG: Connection._announce(): Announcing incoming message [ ] to a [std.brdg] message handler...
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 821:_announce | DEBUG: Connection._announce(): Announcing incoming message [ ] to a [Wi-Fi.UART] message handler...
2012-02-16 21:14:21,733 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:1221:handle | DEBUG: WiFi_Module._UART_MsgHandler.handle(): The Wi-Fi module relayed the message [ ] from the sensor host to the server.
2012-02-16 21:14:21,733 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:2412:_handleHostMsg | DEBUG: SensorHost._handleHostMsg(): Handling host message [['\x16']]...
2012-02-16 21:14:21,733 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:2427:_handleHostMsg | ERROR: SensorHost._handleHostMsg(): Unknown host message type [ ]. Ignoring...
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 826:_announce | DEBUG: Connection._announce(): Finished announcing incoming message [ ] to message handlers...
Also, for some reason I have to hit Enter twice, still haven't figured that out... ^M^J (CR/LF) at end of line seems to work better... But then I get _handleHostStarting() not defined... Ah, I forgot the "this." Try again... OK, that's better, now on server console I get the following:
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Let's now try the next line...
HOST_READY
This does nothing observable (all it does is toggle a couple of flags). Add diagnostic statement... Ok, now it shows:
Node #0's host is ready to accept commands.
Meanwhile, on the line-end issue... It's starting to come back to me... After the end-of-line character, we are waiting to see what the next character will be before proceeding, so that if it's another end-of-line character we can ignore it. This could be programmed better. However, I am currently stuck with using io.TextIOWrapper which has this limitation. Bleh.
Anyway, for now I am working around by streaming a file "mock_CTU_output.txt" instead of typing the lines by hand. The file contents are:
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ACK,WIFI_STARTING,v0.19*67
$ACK,WIFI_READY*60
$GPRMC,212143.013,V,3025.676,N,08417.112,W,0.0,0.0,161211,4.1,W*70
and now from the server I get in response:
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Node #0's host is ready to accept commands.
ERROR: SensorHost._handleHostMsg(): Unknown host message type [ACK]. Ignoring...
ERROR: SensorHost._handleHostMsg(): Unknown host message type [ACK]. Ignoring...
ERROR: SensorHost._handleHostMsg(): Unknown host message type [GPRMC]. Ignoring...
So, that is pretty much what's expected. I haven't implemented these other messages yet so of course they are "unknown message". Now slogging through code to change class to CTU_Host and then dispatch GPRMC to the GPS module proxy...
OK, after debugging for a while (during which I learned not to begin a method name with double-underscore!) we are now making it all the way into the GPS_Module._handleGPRMC() method. That's where I left off the other day. It pulls data out of the fields but does nothing with it. It should probably store the data as some module state information, and wave some flag that will be being watched by the GPS_Manager thread (am I even starting that thread yet?). Of course, yon GPS manager still needs to be written.
In a bit more detail, probably we should stuff all the GPRMC data into attributes of a new GPRMC_Record object, and install that as the value of the gps_module.last_GPRMC_record attribute, also tagged with the system time at which yon data was received. Then raise a flag gps_module.got_GPRMC. GPS manager will be waiting for that flag to be touched, and will go fetch the last_GPRMC_record. It will parse out the fields that it's interested in, and notice that the date/time is way off from the system time (NIST-slaved via NTP), and then this will trigger it to inform the model/proxy of the correct date & time; the gps_module object will translate this info to an appropriate $PDME command which it will pass to the CTU_host proxy, which will pass it (prefixed with the new "HOST" command name) to the WiFi_Module proxy, which will pass it to the UART bridge connection, which will send it to the real Wi-Fi module, which will relay it to the real host, which will strip off "HOST" and send it to the GPS. Ta-dah! That's not so hard, is it? Not really. Maybe another day of coding and a day of testing. And once that infrastructure is in place, adding more code to send other kinds of commands to the GPS (and process other kinds of incoming GPS commands) will be easy.
That's enough for tonight...
HOST_STARTING,CTU_GPS,1.9
OK, straightforward error in handle(): The node has no .sensor_host attribute set. We can fix that. A placeholder SensorHost object ought to be created when the node is created. Its initializer just needs the node. OK, SensorNode's initializer now creates the .sensor_host sub-object. Let's try again...
OK, now it's complaining that SensorHost has no .sentMessage() method. I didn't write that yet? Ah, I had done so in ShowerDetectorHost, moving that definition up to SensorHost. (It just dispatches to the _handleMsg() method.) Let's try again...
Hm, for some reason we are getting a SYN (0x16) character:
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 816:_announce | DEBUG: Connection._announce(): Announcing incoming message [ ] to our message handlers...
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 821:_announce | DEBUG: Connection._announce(): Announcing incoming message [ ] to a [std.brdg] message handler...
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 821:_announce | DEBUG: Connection._announce(): Announcing incoming message [ ] to a [Wi-Fi.UART] message handler...
2012-02-16 21:14:21,733 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:1221:handle | DEBUG: WiFi_Module._UART_MsgHandler.handle(): The Wi-Fi module relayed the message [ ] from the sensor host to the server.
2012-02-16 21:14:21,733 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:2412:_handleHostMsg | DEBUG: SensorHost._handleHostMsg(): Handling host message [['\x16']]...
2012-02-16 21:14:21,733 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:2427:_handleHostMsg | ERROR: SensorHost._handleHostMsg(): Unknown host message type [ ]. Ignoring...
2012-02-16 21:14:21,733 | COSMICi.server.comm | Thread-19: node #0 uart0.con0.rcvr | communicator.py: 826:_announce | DEBUG: Connection._announce(): Finished announcing incoming message [ ] to message handlers...
Also, for some reason I have to hit Enter twice, still haven't figured that out... ^M^J (CR/LF) at end of line seems to work better... But then I get _handleHostStarting() not defined... Ah, I forgot the "this." Try again... OK, that's better, now on server console I get the following:
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Let's now try the next line...
HOST_READY
This does nothing observable (all it does is toggle a couple of flags). Add diagnostic statement... Ok, now it shows:
Node #0's host is ready to accept commands.
Meanwhile, on the line-end issue... It's starting to come back to me... After the end-of-line character, we are waiting to see what the next character will be before proceeding, so that if it's another end-of-line character we can ignore it. This could be programmed better. However, I am currently stuck with using io.TextIOWrapper which has this limitation. Bleh.
Anyway, for now I am working around by streaming a file "mock_CTU_output.txt" instead of typing the lines by hand. The file contents are:
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ACK,WIFI_STARTING,v0.19*67
$ACK,WIFI_READY*60
$GPRMC,212143.013,V,3025.676,N,08417.112,W,0.0,0.0,161211,4.1,W*70
and now from the server I get in response:
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Node #0's host is ready to accept commands.
ERROR: SensorHost._handleHostMsg(): Unknown host message type [ACK]. Ignoring...
ERROR: SensorHost._handleHostMsg(): Unknown host message type [ACK]. Ignoring...
ERROR: SensorHost._handleHostMsg(): Unknown host message type [GPRMC]. Ignoring...
So, that is pretty much what's expected. I haven't implemented these other messages yet so of course they are "unknown message". Now slogging through code to change class to CTU_Host and then dispatch GPRMC to the GPS module proxy...
OK, after debugging for a while (during which I learned not to begin a method name with double-underscore!) we are now making it all the way into the GPS_Module._handleGPRMC() method. That's where I left off the other day. It pulls data out of the fields but does nothing with it. It should probably store the data as some module state information, and wave some flag that will be being watched by the GPS_Manager thread (am I even starting that thread yet?). Of course, yon GPS manager still needs to be written.
In a bit more detail, probably we should stuff all the GPRMC data into attributes of a new GPRMC_Record object, and install that as the value of the gps_module.last_GPRMC_record attribute, also tagged with the system time at which yon data was received. Then raise a flag gps_module.got_GPRMC. GPS manager will be waiting for that flag to be touched, and will go fetch the last_GPRMC_record. It will parse out the fields that it's interested in, and notice that the date/time is way off from the system time (NIST-slaved via NTP), and then this will trigger it to inform the model/proxy of the correct date & time; the gps_module object will translate this info to an appropriate $PDME command which it will pass to the CTU_host proxy, which will pass it (prefixed with the new "HOST" command name) to the WiFi_Module proxy, which will pass it to the UART bridge connection, which will send it to the real Wi-Fi module, which will relay it to the real host, which will strip off "HOST" and send it to the GPS. Ta-dah! That's not so hard, is it? Not really. Maybe another day of coding and a day of testing. And once that infrastructure is in place, adding more code to send other kinds of commands to the GPS (and process other kinds of incoming GPS commands) will be easy.
That's enough for tonight...
No comments:
Post a Comment