He recompiled the high-speed counter in a LogicLock region with the device set properly and got close to 700 MHz! He is still using the Classic timing analyzer though; these tests should probably be redone in TimeQuest for improved accuracy / more detailed reporting.
Samad & Aarmondas arrived, and the students are going to go have their internal team meeting in the library.
Spoke to Samad briefly about the power board design. We are going to go over it in depth tomorrow afternoon (no class tomorrow).
Later this afternoon I will go over the startup procedure with everyone (ECE students). They should also plan to practice it themselves soon. Also, they should put the server (& Python 3.1) on their laptops so that they can monitor the run from there.
David didn't yet have the full version of Quartus on either his laptop (under parallels) or in VirtualBox on Ray's iMac. He's started those downloads. On his laptop he needs the FAT32 version. Meanwhile, while those are downloading he's just reading documents.
David didn't yet have the full version of Quartus on either his laptop (under parallels) or in VirtualBox on Ray's iMac. He's started those downloads. On his laptop he needs the FAT32 version. Meanwhile, while those are downloading he's just reading documents.
My main technical task for today is continuing to work on the remote GPS initialization code. Let's look at where we stand at the moment:
When we startup CTU's WiFi+DE3+GPS, we get:
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ERR,BAD_CHK,[$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1]*25
$ERR,BAD_CHK,[$GPTXT,COSMICi Custom_Config_0.0.3]*27
$ACK,WIFI_READY*60
$GPRMC,222517.001,V,3025.676,N,08417.112,W,0.0,0.0,131211,4.1,W*70
$GPGGA,222517.001,3025.67587,N,08417.11218,W,0,00,99.0,051.73,M,-29.7,M,,*60
$PDMETRAIM,2,0,0.000000000,0,0,0,0,0,0,0,0,0,0,0,0,0*43
$PDMEPOSHOLD,0,0000.000,N,00000.000,E,000.00*4A
At home working on GPS initialization code. I'm wondering now if communicating between threads via an update flag is the right approach. Because wouldn't we need a separate flag for each type of message? It might be cleaner to have a subscription system, in which the GPS manager "subscribes" to specific types of messages, via registering a callback, and then the GPS proxy "publishes" announcements of the messages, calling the callback. But then, if we still have a separate thread for the GPS manager, the callback routines will still have to signal that thread using flags or something similar. So it doesn't really save us any trouble, I think... OK, I ended up creating an "Inbox" abstraction that tracks the most recent value of a given type of data record and alerts whoever's interested in that record about updates by waving a flag.
Made some progress on gps.py. I'm wondering now if it might not work simply to do a warm start so that the ephemeris gets invalidated. (The current problem might be that it thinks the ephemeris from December is still valid even though it isn't.) The almanac should still be good, since it was last working less than 6 months ago (specifically, last December). I could even try doing this manually, with a "HOST GPS $PDME,1" command line typed in node 0's UART bridge terminal window. If that works reliably to trigger the initial acquisition, then it makes initialization extremely simple. I have already written the code to send the warm-start command (although not yet tested). Test this in lab tomorrow (after the faculty meeting).
When we startup CTU's WiFi+DE3+GPS, we get:
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ERR,BAD_CHK,[$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1]*25
$ERR,BAD_CHK,[$GPTXT,COSMICi Custom_Config_0.0.3]*27
$ACK,WIFI_READY*60
$GPRMC,222517.001,V,3025.676,N,08417.112,W,0.0,0.0,131211,4.1,W*70
$GPGGA,222517.001,3025.67587,N,08417.11218,W,0,00,99.0,051.73,M,-29.7,M,,*60
$PDMETRAIM,2,0,0.000000000,0,0,0,0,0,0,0,0,0,0,0,0,0*43
$PDMEPOSHOLD,0,0000.000,N,00000.000,E,000.00*4A
...
Now, for some reason the main server console is reporting this error message:
WARNING: SensorHost._handleHostMsg(): Unknown host message type [ERR]. Ignoring...
WARNING: SensorHost._handleHostMsg(): Unknown host message type [ERR]. Ignoring...
More details from COSMICi.server.log:
2012-02-22 15:05:02,058 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:2436:_handleHostMsg | WARNING: SensorHost._handleHostMsg(): Unknown host message type [ERR]. Ignoring...
2012-02-22 15:05:02,059 | COSMICi.server.model | Thread-19: node #0 uart0.con0.rcvr | model.py:2436:_handleHostMsg | WARNING: SensorHost._handleHostMsg(): Unknown host message type [ERR]. Ignoring...
Let's look at model.py line 2436... OK, yes, we don't have a case for message type ERR yet. Let's add one and try again.
Hm, if you start up the boards with more of a delay between them, the NMEA stream starts up muted (as I intended). Wonder why it didn't work when I started them more quickly. Hm.
Took Juan & Aarmondas through the startup sequence.
OK, here again is the initial output from the CTU. This time, the Wi-Fi board got started up so long before the DE3 that we missed the WIFI_READY message. The "ACK,UNMUTE" is in response to an UNMUTE command typed by the user to unmute the NMEA pass-through.
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ERR,BAD_CHK,[$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1]*25
$ERR,BAD_CHK,[$GPTXT,COSMICi Custom_Config_0.0.3]*27
$ACK,UNMUTE*77
$GPRMC,222829.029,V,3025.676,N,08417.112,W,0.0,0.0,131211,4.1,W*7A
$GPGGA,222829.029,3025.67587,N,08417.11218,W,0,00,99.0,051.73,M,-29.7,M,,*6A
$PDMETRAIM,2,0,0.000000000,0,0,0,0,0,0,0,0,0,0,0,0,0*43
$PDMEPOSHOLD,0,0000.000,N,00000.000,E,000.00*4A
...
Initial server console errors are now:
ERROR: SensorHost._handleHostMsg(): Sensor host reports a BAD_CHK error with data [[$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1]].
ERROR: SensorHost._handleHostMsg(): Sensor host reports a BAD_CHK error with data [[$GPTXT].
At least this looks a little bit less retarded. We should probably, however, at some point modify the CTU firmware to not bother reporting a BAD_CHK error if the NMEA checksum is entirely missing, but only if it's actually present but the value mismatches.
Some more server console output:
|------------------------------------------------------------|
| Node 1 log started. |
|VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV|
Node 1 reports its MAC address is 00:1E:3D:33:E9:42.
Node 1 turned on at Wed Feb 22 15:47:08 2012 + 380 ms.
Starting AUXIO server for node 1 on port 52738...
Starting UART server for node 1 on port 63767...
Node 1 reports that its bridging mode has changed to NONE.
Node 1's bridge mode is now NONE.
Node #1's host (type FEDM, firmware version v0.10) is starting up...
Node 1 reports that its bridging mode has changed to TREFOIL.
Node 1's bridge mode is now TREFOIL.
WARNING: SensorHost._handleHostMsg(): Unknown host message type [DAC_LEVELS]. Ignoring...
Node #1's host is ready to accept commands.
WARNING: SensorHost._handleHostMsg(): Unknown host message type [FIFO_FULL]. Ignoring...
WARNING: SensorHost._handleHostMsg(): Unknown host message type [NC_PULSES]. Ignoring...
WARNING: SensorHost._handleHostMsg(): Unknown host message type [NC_PULSES]. Ignoring...
ERROR: SensorHost._handleHostMsg(): Sensor host reports a UNK_CMD error with data [WIFI_STARTING].
WARNING: SensorHost._handleHostMsg(): Unknown host message type [NC_PULSES]. Ignoring...
WARNING: SensorHost._handleHostMsg(): Unknown host message type [NC_PULSES]. Ignoring...
WARNING: SensorHost._handleHostMsg(): Unknown host message type [NC_PULSES]. Ignoring...
WARNING: SensorHost._handleHostMsg(): Unknown host message type [PULSE]. Ignoring...
WARNING: SensorHost._handleHostMsg(): Unknown host message type [PULSE]. Ignoring...
...
The data that generated this was (with blank lines removed):
HOST_STARTING,FEDM,v0.10
DAC_LEVELS,-0.200,-2.500,-0.299,-0.447,-0.669,-1.000
HOST_READY
FIFO_FULL,3,1
NC_PULSES,121360254,153,51,201
NC_PULSES,239902156,120,70,205
ACK,WIFI_STARTING,v0.19
ERR,UNK_CMD,WIFI_STARTING,v0.19
ACK,WIFI_READY
NC_PULSES,355829245,142,80,200
NC_PULSES,457349235,92,69,200
NC_PULSES,587443282,157,70,204
PULSE,0,0,3,1,632470702,3,(0,(1,(2,2),4),4)
PULSE,0,0,2,1,632470705,1,(0,7)
The "Unknown host message type" warning messages are all happening because I haven't yet implemented the ShowerDetectorHost subclass of SensorHost, or mutated the .sensor_host instance into it, and so the _handleHostMsg() method call is still getting handled by the SensorHost base class, which of course doesn't know about all these message types, since of course they are specific to the ShowerDetectorHost. But, we'll worry about all that later; for now we need to finish working on the GPS initialization.
I think first I want to break model.py up into several files as it's getting a little unwieldy (2,664 lines). Here are some thoughts about how to break it up into modules:
- model - Defines SensorNet, SensorNode, SensorHost?
- wifi - Defines WiFi_Module
- ctu - Defines CTU_Node, CTU_Host
- gps - Defines GPS_Module, GPS_Manager
- fedm - Defines Detector_Node, ShowerDetector_Node, Detector_Host, ShowerDetector_Host
At home working on GPS initialization code. I'm wondering now if communicating between threads via an update flag is the right approach. Because wouldn't we need a separate flag for each type of message? It might be cleaner to have a subscription system, in which the GPS manager "subscribes" to specific types of messages, via registering a callback, and then the GPS proxy "publishes" announcements of the messages, calling the callback. But then, if we still have a separate thread for the GPS manager, the callback routines will still have to signal that thread using flags or something similar. So it doesn't really save us any trouble, I think... OK, I ended up creating an "Inbox" abstraction that tracks the most recent value of a given type of data record and alerts whoever's interested in that record about updates by waving a flag.
Made some progress on gps.py. I'm wondering now if it might not work simply to do a warm start so that the ephemeris gets invalidated. (The current problem might be that it thinks the ephemeris from December is still valid even though it isn't.) The almanac should still be good, since it was last working less than 6 months ago (specifically, last December). I could even try doing this manually, with a "HOST GPS $PDME,1" command line typed in node 0's UART bridge terminal window. If that works reliably to trigger the initial acquisition, then it makes initialization extremely simple. I have already written the code to send the warm-start command (although not yet tested). Test this in lab tomorrow (after the faculty meeting).
No comments:
Post a Comment