Plans for this week

OK, looks like my data-collection run that I started on Friday is still running, so that's good. I should have a full weekend's worth of data. The file is 111 MB. Some next steps:

• Contact Gordon to see what his status is on the code. I emailed him just now, asked him to please finish it in the next few days, or hand it over to me.
  
  
• Alternatively, as a contingency plan, we could always slurp the raw data directly into Matlab and do all the processing there. However, although this probably wouldn't be difficult, it doesn't really make sense to replicate the work Gordon has already done. It would probably be easier to just fix the Java code, even if it turns out that Gordon is no longer available to finish it up.
  
  
• Aha! Gordon is here now. He modified his code to count the number of bad checksums. He found 70-something glitches in the 74MB data file from Jan. 26th (just before the new level shifter and gender bender were put in place), that's an average rate of about 1 glitch per MB. Not too bad, but of course we'd prefer to see zero. I stopped my data-collection run that was going over the weekend at 112 MB - Gordon can run his code again on that.
  
  
• If there still a lot of serial glitches, and we decide we need to reduce them further, there are two more things I can try: (1) Lowering the baud rate on all 3 boards (GPS, DE3, WiFi), and (2) Seeing if I can turn on CTS/RTS flow control for the DE3->WiFi link, at least - this may be possible.
  
  
• Independently of all this offline data-analysis, I could [ ] add some features to the Python server to allow us to graph the incoming time data (in particular, the OCXO frequency drift, the self-reported GPS accuracy, the # of satellites, etc.) in real time. Not sure if this is worth the effort though. Meanwhile, another needed change to the server is: [ ] Allow us to type input in the TikiTerm windows. That is probably easier, so maybe I should do that first.
  
  
• Also need to clean off my desk, do some filing, fill in my timesheet.

After Gordon left, I spent a while re-studying all my old TikiTerm code, adding some comments, and getting ready to add the user input capability to it. I've been wanting to keep the input line below the output. I guess I need to figure out if I can intercept cursor-placement events and enforce that they can only happen below all output. Then I have to somehow receive the text that has been typed, and place it in an input buffer that client threads can read from. Tricky! Need to spend some time studying the TkInter docs to do this...

I think I can do it. I can create a new mark to designate the start of the input region. New output can always be inserted before (to the left of) this point. I can add a new event handler to the mouse-click and key-press events, while keeping the existing ones. I can use mark_set() to force-move the insertion point back to the start of the input region, in case the user moves it out of the input region. And when the user hits enter, I can grab the text in between the start and end of the input region, change its color, append it to the input buffer, and adjust the start-input marker to the new spot. Meanwhile, other threads can asynchronously consume data from the input buffer, using an appropriate lock. When no data is available, they can block on a condition flag that we can raise whenever we put new info into the input buffer.