Juan and Michael Dean are here and are going to tweak the FEDM high-speed subsystem from yesterday to see if they can improve the performance any before they start Logic-Locking.
I resoldered the jury-rigged SMA connector on the OCXO board (old CTU controller) which had broken off earlier in the week.
I re-supplied power cables to everything to get ready for the demo. Let's try doing a dry run.
- Starting server.
- Switching on: (1) CTU WiFi, (2) DE3, (3) GPS in rapid sequence (~1 sec between).
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ACK,WIFI_READY*60
$GPRMC,225634.008,V,3025.660,N,08417.096,W,0.0,0.0,280212,4.0,W*7D
$GPGGA,225634.008,3025.66011,N,08417.09553,W,0,00,99.0,104.16,M,-29.7,M,,*64
$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
...
and in the Console window:
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Node #0's host is ready to accept commands.
ERROR: WiFi_Module.sendHost(): I don't know any way to communicate with the sensor host in the present briding mode. Giving up.
Node 0 reports that its bridging mode has changed to TREFOIL.
Node 0's bridge mode is now TREFOIL.
...
This is because the server hasn't yet received the bridge-mode command that tells it the Wi-Fi board has switched to Trefoil mode at the time when the GPS manager is trying to send the warm-start command. This needs to be fixed sometime. For now, we can try warm-starting manually:
3. Manually type "HOST GPS $PDME,1" in the UART window. Get:
HOST GPS $PDME,1
HOST GPS $PDME,1
$ACK,GPS $PDME,1*24
$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1
$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1
$GPTXT,COSMICi Custom_Config_0.0.3
$GPGGA,182901.764,3025.66011,N,08417.09553,W,0,00,99.0,104.16,M,-29.7,M,,*6E
$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
$GPRMC,182902.014,V,3025.660,N,08417.096,W,0.0,0.0,290212,4.0,W*75
$GPGGA,182902.014,3025.66011,N,08417.09553,W,0,00,99.0,104.16,M,-29.7,M,,*6D
$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
...
After a short delay, we acquire a satellite. Now, let's switch on POSHOLD and TRAIM modes. The commands sent by the old CTU firmware were:
$PDME,21,1,3025.694,N,08417.1,W,0040
$PDME,22,1,0.000000100
So we prefix these with "HOST GPS" and send:
4. Type "HOST GPS $PDME,21,1,3025.694,N,08417.1,W,0040" in the UART window.
Oops, got an error in gps.py... Just forgot the "this." in front of the _PDME_Record() constructor call. Fixed that, re-running.
Now we're not getting any satellites... The clock is about a minute behind (due to the GPS being powered off briefly as I was restarting everything). Maybe I should put the batteries back in once we get a signal, so that doesn't happen again...
We seem to be slow re-acquiring, so I'm trying a cold-start now. It erases the position/time settings. (Not just the almanac!) We seem to be taking a long time to re-acquire. Maybe I shouldn't have done that... If it doesn't eventually sync up, I might need to reinitialize using the demo app now.
Anyway, whatever... We can still run our demo without the real GPS time sync. We still need to manually start the timer with the START command. That's fine.
5. Power up the FEDM & its Wi-Fi board.
6. Type "HOST START" at the UART.
I had some issues with loose cables; eventually we need to go through and create properly soldered connectors everywhere (or at least high-quality removable connectors).
Anyway, the demo is running OK at the moment except for the GPS still not acquiring satellites.
UPDATE: It finally did acquire satellites after I manually set the time & location and then just let it sit for a long time. It took maybe 30 minutes though.
Juan and Michael made some more minor simplifications and got the slow-corner speed for the high-speed stuff up to 537.35 MHz. They are archiving that and putting the archive up on the group blog.
Next I will show them how to logic-lock just the components we want.
One thing that might be moderately useful, until we can power up the whole CTU all at once through the power distribution board: Program the system to start up appropriately no matter what order the individual components of the CTU are powered up in. Possible orders are:
Anyway, the demo is running OK at the moment except for the GPS still not acquiring satellites.
UPDATE: It finally did acquire satellites after I manually set the time & location and then just let it sit for a long time. It took maybe 30 minutes though.
Juan and Michael made some more minor simplifications and got the slow-corner speed for the high-speed stuff up to 537.35 MHz. They are archiving that and putting the archive up on the group blog.
Next I will show them how to logic-lock just the components we want.
One thing that might be moderately useful, until we can power up the whole CTU all at once through the power distribution board: Program the system to start up appropriately no matter what order the individual components of the CTU are powered up in. Possible orders are:
- (1) WiFi, (2) DE3, (3) GPS (nominal order). - Currently, even this doesn't work ideally well because the server sees that the host is up and then tries sending the warm-start command to the GPS before the GPS is even turned on. The server needs to recognize that the GPS isn't responding, display a warning (and a reminder to the operator to turn on the GPS), and keep retrying until it is turned on. Also, with this sequence, if it is executed too slowly, we can miss catching the WIFI_READY message in the CTU firmware and fail to automatically unmute the GPS pass-thru.
- (1) WiFi, (2) GPS, (3) DE3. - This order works pretty well, apart from the fact that the DE3 (& thus the server) never get to see the turn-on messages from the GPS - so we can't rely on those messages to detect that the GPS has turned on. Also, with this sequence, if it is executed slowly, we can miss the WIFI_READY message.
- (1) DE3, (2) WiFi, (3) GPS - This actually works OK, we get "--" followed by "oh" on the 7-segment display temporarily when we turn on the Wi-Fi, and output like the following.
$ACK,*65
$ERR,UNK_CMD,*00
$ACK,WIFI_STARTING,v0.19*67
$ACK,WIFI_READY*60
$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1
$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1
$GPTXT,COSMICi Custom_Config_0.0.3
$GPRMC,223052.165,V,3025.656,N,08417.093,W,0.0,0.0,290212,4.0,W*76
$GPGGA,223052.165,3025.65566,N,08417.09318,W,0,00,99.0,111.34,M,-29.7,M,,*65
$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
...
Note the HOST_STARTING and HOST_READY messages are missing, because when those are sent, the Wi-Fi board isn't yet turned on, so they go in the bit bucket. So the server doesn't receive the information it requires to realize that this is the CTU. Beyond that, other than getting rid of the "ACK" and "UNK_CMD" on the initial empty line (00 byte) from the Wi-Fi, I'm not sure how this could be improved. (Other than adding the automatic warm-start etc.) - (1) DE3, (2) GPS, (3) WiFi - When this works, we get output like this:
$ACK,*65
$ERR,UNK_CMD,*00
$ACK,WIFI_STARTING,v0.19*67
$ACK,WIFI_READY*60
$GPRMC,224111.999,A,3025.655,N,08417.095,W,0.5,165.9,290212,4.0,W*60
$GPGGA,224111.999,3025.65503,N,08417.09511,W,1,03,5.4,111.33,M,-29.7,M,,*57
$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
Of course, the HOST_STARTING and HOST_READY messages are missing. The GPS startup messages are also missing because we intentionally mute them until we receive the WIFI_READY. - (1) GPS, (2) WiFi, (3) DE3 - This may work, and produce output like the following (although whether we catch the WIFI_READY message depends on how quickly we turn the DE3 on):
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ACK,WIFI_READY*60
$GPRMC,224401.999,A,3025.651,N,08417.100,W,0.2,0.0,290212,4.0,W*61
$GPGGA,224401.999,3025.65087,N,08417.09954,W,1,03,5.2,111.30,M,-29.7,M,,*52
$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
...
Note the HOST_STARTING and HOST_READY messages are present b/c the Wi-Fi board has already powered up by the time the DE3 sends them. - (1) GPS, (2) DE3, (3) WiFi - Comes out similar to case 4. Works fine apart from the fact that we miss the GPS startup messages. However, they are not particularly critical. Output similar to the following:
$ACK,*65
$ERR,UNK_CMD,*00
$ACK,WIFI_STARTING,v0.19*67
$ACK,WIFI_READY*60
$GPRMC,224919.999,A,3025.684,N,08417.092,W,0.3,63.4,290212,4.0,W*57
$GPGGA,224919.999,3025.68390,N,08417.09239,W,1,03,4.9,109.57,M,-29.7,M,,*5C
$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
...
We had the review, with Dr. Arora & Matthieu present. It seemed to go pretty well - Dr. Arora asked a lot of questions.
After the review I happened to notice a bug in the CTU firmware where I was getting an E5 (discrepancy too large) error consistently (this might have been triggered when we re-acquired time lock) - that was just because I didn't re-align last_counter_val after seeing a phase mismatch; fixed that. Then I tested the startup sequences 3-6 above.
The GPS reliably re-acquired pretty quickly (and without manual commands) later in the afternoon, although that may have been because I had the batteries in, so it never powered down totally, just went into sleep mode. We need to do some more experiments w.r.t. re-acquiring time lock after it has been off for a while, to really pin down what's needed for that.
No comments:
Post a Comment