Things are Going Smoothly Today (Knock on Wood)

I picked up the two NI softwarez ("LabView Full Development System") from my mailbox yesterday, and brought them into the lab with me today. Perhaps I will go ahead and install one of them on the Acer PC (don't want to install on COSMICi because I'm in the middle of data collection, and the install may choke it off or require a reboot). Did receiving on the NI stuffs. Did activation of one of the units, & installing it now on the Acer. Gave the other unit to Ray for him to give to Eliot for physics dept. use.

Also tried to do budget check on XMath, but it isn't working for some reason - try again next week.

The GPS time data collection run I started on Monday is still going strong. It seems I definitely solved the crashing problem, alright! Although I have been making some firmware changes that I want to test, I think instead I will let this run keep going through the rest of this week and this weekend. That way we will have a nice, full week-long run (our first) - a good candidate for inclusion in the paper.

Gordon is working on the graphs from home this week based on my instructions. I emailed him with some additional info on status of recent runs.

Another thing I can work on today is adding capability to the server to work with the data from the GPS time app. Basically, the generic sensor node model needs to be subclassed to create the CTU_GPSapp node type. The UART BridgeServer needs to have a message handler added to it to parse input lines, and look for the $NODE_TYPE message. When it sees this message, if the type is CTU_GPSAPP, it should turn the generic node instance into a CTU_GPSapp subclass instance, and pass subsequent lines to this object. This object will maintain internal data structures needed to store the needed time data & various derived quantities in a useful form, and will support queries (from other server modules) to look up the best estimate of the absolute real time (together with an uncertainty estimate) for a given OCXO-based time (specified with precision down to a hundredth of a cycle, or 1 ns) relative to the start of the run. It will also pop up and maintain a TkInter window for displaying its state, including, say, warning lights for various GPS conditions, real-time graphs of cumulative relative phase wander & frequency over the run (maybe zoomable and scrollable!), uncertainty estimates from TRAIM (& also combined with OCXO phase uncertainty using the quadrature rules), # of satellites / good satellites, etc. This window could also have buttons for remotely commanding the CTU, although this might be dangerous - we might not want to make it *too* easy to interrupt a run in case a casual user tinkers with the controls. Probably best to have a "lock-down mode" for all sensitive controls.