1
$\begingroup$

I have some sensors connected to an Arduino Due. The Arduino sends the buffer of data over the its SerialUSB connection. The last element of this buffer defines when are passed 1 seconds (it is 0 "inside" the second and a 1 on the second). In this way, in post processing, I can count the number of the sample revealed each second.

I usually don't lose any data. It doesn't a standard band and, as a consequence, it does not have a stable serial communication time. When I receive the wrong data, I discard it. In addition, the Arduino's clock is not as accurate, so it sometimes time-shifts the data.

What is the best way to stabilize my sampling rate in post processing?

Below is a histogram of the sample rate revealed by an experiment on my Arduino:

Sample rate

X-axis is the number of samples per second, Y-axis is the # of occurrences.

Edit 1:

After some testing, I've noticed an Arduino procedure exists that requires a "variable" amount of time (according to its datasheet, the DS18B20 temperature sensor requires a specific amount of time to collect data and it is "odd" with the second clock).

So, I printed the sample rate (# of samples/second) of my device (without considering the correct data or the wrong data), it appears different each second. Thus, I am considering to interpolate the data and reduce them to a lower sample rate (e.g. 256 each second).

$\endgroup$
  • $\begingroup$ Can you please indicate what are the units in each of the plot axis, and how did you obtain that data? $\endgroup$ – MBaz Apr 17 '17 at 13:23
  • $\begingroup$ I am sorry, on the X there is the number of samples for second and on the Y there is the occurrence of the value each second. $\endgroup$ – youngz Apr 17 '17 at 20:37
  • 1
    $\begingroup$ Read a little on Allen Variance. $\endgroup$ – Stanley Pawlukiewicz Jun 17 '17 at 3:56
  • 1
    $\begingroup$ It sounds like you should be discarding the concept of a sampling rate altogether and simply record time stamps with your data and transmit both. $\endgroup$ – Jazzmaniac Feb 12 '18 at 14:46
1
$\begingroup$

first an embedded engineering comment:

Don't use a UART/RS232-style serial port to communicate numerical data, if you can at all avoid it. I don't know about the arduino you're using, but I worked with far less opulently equipped microcontrollers than what you'd typically find on an arduino board, and those often come with a USB controller, so that you "just" have to write a USB handler (or typically, use the handler offered by the manufacturer) to put data into USB packets. That way, you'd be able to use 1 Mb/s (USB1) or 12 Mb/s (USB2 full speed) on many cheap microcontrollers. Compare that to the 115.2 kb/s max that most of the serial port adapters do... if Arduino doesn't support that, it might be worth to look at the competitors of the beginner-friendly Arduino platform family (namely, ARM's mbed, for example). This applies twice if data corruption is an issue with your serial port. USB is really really robust, in my experience.

Now, generally, the answer to "some samples are missing" is either interpolation (ie. looking at surrounding samples and finding a nice one to fill the gap ) or compressed sensing (ie. guessing based on a metric of what is most likely for the signal you actually want to observe).

For varying sampling rate, you'd typically use some kind of clock recovery (which, at its heart, is usually also an interpolator).

Now, with your figure, I'd say: this data is probably not worth salvaging. Even if I take that large bar as "wrong" and just consider the others, your variations in samples are really large, and your 1 second granularity doesn't allow for sufficient info about the actual sampling rates in between. There's simply not enough info on when things actually happened, so that we can't reconstruct the original signal.

So, I'd say: sampling stuff has been done before, very often, and it might be a good idea to look at the firmware other folks wrote. The way you do doesn't seem to be fit for the purpose, whatever you're doing.

$\endgroup$
  • $\begingroup$ So, you said that I have to trash this data? I am using an Arduino Due, what do you suggest to improve my communication? Can you link some example or documentation? $\endgroup$ – youngz Apr 17 '17 at 10:22
  • $\begingroup$ I'll be honest with you: Read my answer. I said, from all I can tell from your graph, the data is probably already trash. Also, I'm not an Arduino expert, which I also said in my post. Also, on arduino.SE you already got the strong recommendation to check why your communication goes wrong. Fix your digital communication first. Then try to deal with the data. $\endgroup$ – Marcus Müller Apr 17 '17 at 10:39
  • $\begingroup$ Yes, I tried to improve my Arduino code and it is the better communication that I reach to obtain (considering the payoff with the sample rate). So, maybe I have to find a new way to collect the data and, as you say, don't use anymore the serial communication. $\endgroup$ – youngz Apr 17 '17 at 10:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.