Mon., Mar. 5th

Plan for today:  Test & debug my new GPS initialization code.

Some major tasks I could work on this week:

• [ ] Plan/specify interfaces to some new code modules for the students to work on.
• [ ] Start design of new OCXO board.

OK, let's set up the test.

1. Archive log files.
2. Start server.
3. Power up CTU's WiFi/DE3 (in that order, quickly; GPS already powered on).

DE3's UART output (as wirelessly relayed to server) is:

HOST_STARTING,CTU_GPS,1.9

HOST_READY

$ACK,WIFI_READY*60

$GPRMC,184801.999,A,3025.668,N,08417.098,W,2.4,353.1,050312,4.0,W*61

$GPGGA,184801.999,3025.66805,N,08417.09799,W,1,05,1.4,080.70,M,-29.7,M,,*50

$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

...

So the GPS already has satellites (I left it turned on and plugged into the USB over the weekend), so there's no real initialization to be done right now.  However, I should probably still do a test a little later on to exercise the initialization code for real.  I can try power-cycling the GPS on startup; I can try manually sending commands for warm and cold restarts before startup so it starts with less info.

On console we see:

|------------------------------------------------------------|

|  Node 0 log started.                                       |

|VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV|

Node 0 reports its MAC address is 00:1E:3D:33:ED:CF.

Node 0 turned on at Mon Mar 05 13:47:55 2012 + 552 ms.

Starting AUXIO server for node 0 on port 52737...

Starting UART server for node 0 on port 63766...

Node 0 reports that its bridging mode has changed to NONE.

Node 0's bridge mode is now NONE.

Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...

Node #0's host is ready to accept commands.

Node 0 reports that its bridging mode has changed to TREFOIL.

Node 0's bridge mode is now TREFOIL.

 WARNING: GPS_Module._GPRMC_Record.extract_datetime(): Reported time was offset -0.001 from the exact start of a second.  Rounding off and ignoring...

 WARNING: GPS_Module._GPRMC_Record.extract_datetime(): Reported time was offset -0.001 from the exact start of a second.  Rounding off and ignoring...

The GPS module is receiving signals from 5 satellites.

 WARNING: GPS_Module._GPRMC_Record.extract_datetime(): Reported time was offset -0.001 from the exact start of a second.  Rounding off and ignoring...

...

So this is fine given the data.  However, I might want to consider changing the warnings to info messages, since otherwise, they might start to get kind of annoying after a while.

Next step:  Engage POSHOLD and TRAIM codes - those methods haven't been implemented yet.

OK, wrote that code; let's test it.

Note: We should send "HOST UNMUTE" after getting HOST_READY to make sure that the host will go ahead and start relaying GPS data.  (It might not if it didn't catch the WIFI_READY.)

Would it be possible to have the Wi-Fi module respond to PINGs from the host on its UART port with WIFI_NOT_READY or some such, if such messages are received before the server connection is established?

Realized there's an issue where the PDME commands to enable POSHOLD and TRAIM actually return two replies, one that's just "OK" and another that echoes their arguments.  Really we should check the extended one to make sure the arguments match, but we're not doing that yet.

Next, we really need to do something with the TRAIM alarm codes.  OK, now I'm examining them and displaying various warnings if things are awry.

For some reason, today the CTU's Wi-Fi module seems slow to acquire a connection.  It's almost like the router's acting up.  Should I maybe try a different router?

OK, we're now getting various warnings, info messages, & normal reports from the GPS_Manager._checkTRAIM() fanboy (subscription delivery address callback) method .

Adding some attributes to GPS_Module based on contents of TRAIM line.

I need to figure out whether the VALID bit reported by TRAIM refers to whether the TRAIM algorithm is enabled or whether the solution is valid.

One major outstanding issue:  What exactly is the TRAIM algorithm doing, and how accurate are its timing solutions really?  How much are things being screwed up by our antenna being in the window?  Even if that weren't an issue, don't we really need to validate these absolute times by comparison with another timing reference?  We really should address this someday if we are really going to compare our data with that collected by other sites.

Tomorrow:  Work on code to automatically start up the FEDM once we're confident that we're getting a reasonable quality timing signal from GPS.