Shepard v1.1 Sample Rate

Added by Jeremy Wright about 10 years ago

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.

Replies (1)

RE: Shepard v1.1 Sample Rate - Added by Jeremy Wright about 10 years ago

I really wasn't paying attention to when the sample rate jumped from about 250 SPS to over 1000 SPS, but as I glanced through the code this morning I feel it was probably when I shifted the temperature conversion/scaling calculations off onto the client. The Arduino is just reading raw values from the sensors and sending them directly out over serial. That makes for very low overhead and much faster sample rates. I had made some tweaks to the Mach 30 I2C library that may have helped a little too, but couldn't account for that kind of jump.