Tue., Nov. 22nd

Was thinking of doing some work today on improving time resolution of CTU.

First, an issue list with the current CTU setup:

• [ ] For some reason, the Wi-Fi board failed to connect when I powered up the system today.  But then, after some fiddling, it started working again.  Loose connection somewhere?  Watch out for this to happen again, try to diagnose.
• [ ] When the CTU firmware receives a blank line on its input, at present it generates an "UNK_CMD" (unknown command) error message.  Instead it might make more sense to simply ignore these lines.
• [ ] After being powered off for a while (like overnight), the GPS module seems to have difficulty acquiring satellites again.  This is perhaps because the time-of-day is wrong.  (At the moment, the GPS thinks it's 19:50 GMT, when actually it is 20:17; so the GPS is running almost half an hour slow.)  One way to address this:  Have the CTU query the server to find out the current time, then send a command ("$PDME,9,...") to the GPS to set the time (as well as setting the position)
• [ ] When restarting, sometimes there are server errors on the 2nd (or later) connection attempts.  These need to be tracked down and fixed at some point.

Samad is here and he brought the new 10-pin connector with him.  I showed him the proto board I picked up the other day at Fouraker's and the extra breakaway headers and jumpers I ordered from Adafruit, so that he can work on soldering up our power distribution board.  We discussed the connections needed.  He is going to write it all up and include it in the presentation #3 (SLDR), as well as the next report (DDR).

I scanned the bare proto board for him, so if he runs out of time to finish the soldering today, he can at least still make a nice sketch of the wiring for the presentation:

Bare proto board, to be used for soldering
prototype of main power distribution board.

Back on the GPS - I inserted two fresh AA batteries into the GPS kit as a battery backup, so that once we get a fix we don't lose it again.  Although, this conflicts somewhat with the use of the $PDME,9 command, because the docs for that say it needs to be done right after startup to be most effective.

Based on aerial photos from Google Earth (latest imagery), the coordinates of the windowsill where the GPS antenna is currently located are as follows:

• Latitude:     30°25'41.65"N
• Longitude:  84°17'6.00"W

This is a little west of where it looked like the window was in earlier images, but I think the current image is more direct (from overhead), so let's go with that.

Using the coordinate converter at GPSVisualizer.com, in terms of just degrees and minutes (what we get back from the GPS) this is:

• Latitude:     N30°25.694167
• Longitude:  W084°17.1

and in terms of just degrees (which we supply on the $PDME,9 line), it is:

• Latitude:     30.42823611111
• Longitude:  -84.285

Altitude, guesstimating from Google Earth, is about 50 m (164 ft).  So, the actual $PDME,9 command line would be (right now, 2011 Nov. 22nd, 21:12:00 GMT):

• $PDME,9,30.428236,-84.285,50,2011,11,22,21,12,00

Now, the only problem is, getting this information to the GPS will be somewhat involved, requiring changes to the CTU firmware, the Wi-Fi script, and the server.  I think perhaps as a short-term solution, I will get the GPS set up manually, and just rely on the batteries for a while to keep the fix active.  Remember, though, to later go back and solve this issue more permanently!

Muting GPS echo and stopping timer.  Exiting from Wi-Fi.  Powering off CTU.  Yes, GPS still has power (from batteries).  Unplugging level shifter.  Plugging in COM1 cable.  Setting UwTerminal to 57600, no flow control.  Sending commands from UwTerminal:  NMEA-off.txt, hot-start.txt, init-pos.txt (with the new location/time as above).  Still no satellites!  Maybe I need to re-run the eval app.  Have to revisit this on Monday.  Happy Thanksgiving all!