Shepard Test Stand

While Aaron, Chris and I were doing some testing last night it was noticed that we're getting a little over 1000 samples per second (SPS) from the Arduino when we're reading both the thrust and temperature sensors. While this is great, and much more than we ever expected to get out of the Arduino, it creates another challenge. Currently we are using the millis function on the Arduino for our time stamps. When you're sampling faster than millisecond resolution, you begin to get time stamp duplicates with this method. Beyond that it seems that the Arduino's ability to handle nanosecond resolutions is unreliable. There have been a few solutions put forth which will require some debate, probably during a hardware Hangout.

1. Create the time stamp on the client rather than the Arduino. This is my least favorite option. I'm a proponent of keeping the time stamping as close to the source of the data as possible. Still, it's an option.
2. Incrementally add a decimal to the end of the time stamps as they come through. If you got two time stamps with 2256 as their value, the first would be 2256.1 and the second would be 2256.2. This would give you a safety net up through 10 samples in one millisecond.
3. "Rev limit" the sample rate so that the most you can have is 1000 SPS. This would probably involve throwing away any duplicate time stamps after the first is received. The idea was also proposed that we could average the values from the duplicate time stamps, but my personal preference would be to do as little manipulation of the data as possible before the users get it.

There are probably other options, but those are the three that I got out of the conversation. If you have thoughts on time stamping, feel free to contribute them here.