Fri., Mar. 2nd

M. Dean said he & Juan couldn't get in the lab yesterday and couldn't run the license server and didn't know how to do the Logic Lock (they are waiting for me to instruct them on that), so nothing got done yesterday.  He said he is going out of town mid-day today.

So, it looks now like probably the performance-improvement task won't get finished until the week after Spring break.  The other day, Dr. O'Neal and I agreed on Mar. 15th as a good new deadline.  Actually, though, I will be out of town the 14th-16th for the SEALeR workshop trip, so really we only have Monday and Tuesday of the week after Spring break - if the students need more help from me.  Hopefully if I get them started Mon. & Tue. they can make progress on their own on Wed.-Fri., if Ray can let them into the lab.

Some upcoming things I want to focus on (besides that):

• [ ] Finish up the automatic initialization of the GPS by the server.  Can work on this today.
• [/] Ray and I need to discuss the pulse model.  He says Abraham has been collecting some data on that.  My thinking is, when only one threshold is crossed, we should use default parameters for things like leading/trailing edge width ratio to infer a most-likely peak time value.  When multiple thresholds are crossed, then we have more information that can be used to infer values of such parameters.  An ideal approach would be a Bayesian model of the pulse shape distribution and measurement uncertainty, such that if we plug in our data points we can then infer a mean value of the peak time.  However, for now we may want to do something simpler. - Ray agreed he & I and Abraham should have a meeting to discuss this after Abraham has a little more time to gather data.
• [ ] The students will soon need to be given a concrete task for server-side programming.  Possibly the first, simplest useful thing, in terms of visualization, would be to plot the raw pulse data points for the most recent shower event.  I probably need to help the students get started on this, in terms of sketching the interface to this module.
• [ ] Also, in terms of analysis, we need a module that will store the time data from the CTU, and allow us to use it to convert pulse time data to absolute times.  I probably need to sketch an interface to this module as well.

Let's see where we start wrt the GPS initialization...

1. Archiving data files.

2. Starting server.
3. Powered up CTU in sequence: (1) GPS, (2) Wi-Fi, (3) DE3.

We started up with a satellite already acquired (by the time the pass-thru started).

Output is:


HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ACK,WIFI_READY*60
$GPRMC,204732.999,V,3025.665,N,08417.096,W,0.0,0.0,020312,4.0,W*74
$GPGGA,204732.999,3025.66454,N,08417.09648,W,0,01,99.0,109.08,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

...

However, we did get this error (trefoil bridge-mode command not seen in time).

   ERROR: WiFi_Module.sendHost():  I don't know any way to communicate with the sensor host in the present briding mode.  Giving up.

This happens when we don't give the Wi-Fi board enough time to start up before we start the DE3 board, and it is in bridging mode NONE (between DEFAULT and TREFOIL) when we are trying to send the command.  However, really in this mode we should just use the AUXIO or MAIN connection to send the line.  Did that change.  Let's try again.

This worked.  We finally are automatically sending the warm-start command:

HOST_STARTING,CTU_GPS,1.9

HOST_READY

$ACK,WIFI_READY*60

$GPRMC,212556.000,A,3025.675,N,08417.096,W,0.2,0.0,020312,4.1,W*6F

$GPGGA,212556.000,3025.67532,N,08417.09555,W,1,04,3.3,083.30,M,-29.7,M,,*53

$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

$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,212558.749,3025.67523,N,08417.09543,W,0,00,99.0,083.67,M,-29.7,M,,*67

$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,212559.000,V,3025.675,N,08417.095,W,0.0,0.0,020312,4.1,W*76

$GPGGA,212559.000,3025.67523,N,08417.09543,W,0,00,99.0,083.67,M,-29.7,M,,*6C

$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

...

In this run, it took 35 seconds after the warm start for the GPS to start acquiring satellites, which is in line with the module documentation.  I wonder though if maybe I should be doing a hot-start instead of a warm-start, since it is now acquiring right away on power-up.  Probably should just try a hot-start first, and only resort to a warm-start if it seems to be necessary.  Or even better, not even do the hot-start if we are already acquiring satellites; in that case go straight into POSHOLD/TRAIM mode.  Anyway, worry about those changes next week.  Gotta go for now.

Did some more work at home later in the evening.  I wrote a new module "publisher.py" to provide a general publisher/subscriber event-notification facility.  The idea here is that the GPS model/proxy will publish the messages received from the GPS module, and a new "Timekeeper" module will subscribe to those message types that are important for timekeeping purposes (PPSCNTR, GPRMC, PDMETRAIM) and store this data in a persistent database and allow absolute times to be inferred from it.

The reason for the subscription interface (as opposed to the existing approach with a WatchBox for each message type) is that: (1) it ensures you don't miss any messages; and (2) it makes it possible to wait for any of several different message types (as opposed to just waiting for one at a time).  This can be accomplished by delivering the messages to a worklist.

Some notes on the run above:

1. The PDMEHEADER1 and PDMEHEADER2 messages really need to be reformatted upon receipt to be consistent with the other message types:  I.e., comma-separated.  Replace ": " with ",".
   
2. When we see the PDMEHEADER1, that should be considered to be the confirmation of the $PDME,1 (warm-start) command.  We don't receive the normal type of confirmation ("$PDME,1,OK") because the module resets before getting to that point.
   
3. As I mentioned earlier, instead of doing the reset at all, better would be for the GPS Manager to notice in the first GPGGA message that we are already acquiring satellites, and proceed to turn on POSHOLD and TRAIM modes.  Then it can announce that time lock has been acquired, and this can trigger other processes - such as waiting for the FEDM to come online, and then starting the run (which includes creating & starting the Timekeeper thread).  Carrying out this sequence of steps should perhaps be handled by a new "CTU Manager" worker thread.