Power supply testing

• Gordon emailed over the weekend that his code is still having a problem parsing the "*" splits. He shared his Dropbox code folder with me. Installing NetBeans so I can start working with it.
  
  
• Going to work today on figuring out if our existing ATX-type power supply for the FPGA board can also power the GPS and the EZURiO board. First need to see what voltages are available on the extra cable. Downloaded datasheet, it says that 3.3 and 5V are available, but it is not very informative regarding the cable pinouts. Going to use multimeter to test.
  
  
• Found these voltages on primary connector: 2.7, 5.1. Found these voltages on secondary connector: .44, 1.7. Not sure why I'm not finding these other documented voltages: 3.3, +12, -12. Wonder if what's supplied is conditional on how it's connected. Or, maybe I'm just not using the right grounds to measure against. The different grounds seem to be internally connected though. Perhaps the best thing is just to buy another ATX supply.
  
  
• Our power supply needs are as follows:
  - EZURiO Wi-Fi board: 5V, max current unknown (need to experiment) but must be within the limits of USB.
  - GPS module: 5V USB -or- 6.5V AC/DC adapter block -or- 12-to-6.5V car adapter. Max current unknown but adapters are limited to 600 mA
  - OCXO: 3.3V, max current about 850 mA.
  
  
• Juan came by and Mike & Juan worked together to debug latest firmware changes (command processing). STOP, GO, RESET, RESTART commands have all been verified. There was a bug where GO wasn't turning the sync pulser back on, but that's fixed now.
  
  
• Now Juan is working to help debug Gordon's parser code. The docs for Pattern confirm that "\\*" is indeed the correct literal-escape syntax. Aha, it turns out that there was a line with a missing "*" character. Modified code to skip these lines and it now processes the data file with no errors. However, records that have bad checksums aren't getting handled properly in the output. Suggested to Gordon that we need to include an extra field in the output which indicates whether there were errors.
  
  
• Another thought: If we turn down the baud rate of the communication stream to/from the GPS (which has to go through our crufty level-shifter), this might reduce the serial errors. Alternatively, we could replace the hand-wired level shifter with the small PCB we bought from SparkFun. That might help a lot too. Day's almost over, so [ ] do this tomorrow. Also, starting a data-collection run before heading out - just for fun.