Maximum Sampling rate for cli-data-forwarder

I want to understand the maximum sampling rate that is supported by cli-data-forwarder.

Sample Sensor Reading = -0.12,-6.20,-7.90\n
Hex Value = 2D302E31322C2D362E32302C2D372E39300D0A

Number of bytes per transmission = 20 Bytes Approx

Number of baud / Byte(8N1) = 10

Number of bauds = 20 * 10 = 200

Transmission rate = 115200

Max Sampling rate = 115200/200 = 576 Hz

  1. Is time delay between \r\n used for the calculation of sampling time
  2. What will be the maximum safe sampling frequency recommended for using with the cli-data-forwarder.
  3. Should timers be used to add delay between each sensor data write to UART
  4. Is the Calculation above correct

Hi @paulphilip, the actual rate depends a bit on the underlying serial connection. E.g. do you use flow control, do you use buffers between your code and the UART or use an unbuffered serial, how much time does your platform spend formatting your string, etc. But globally your numbers are OK. My suggestion would be to sample at a set interval (e.g. 200Hz) and busy-loop (or use a timer) until the next tick. Example on how we do this on the ST IoT Discovery Kit: . This mitigates things where you might send more bytes (and thus spend more time) and thus have imprecise intervals (e.g. 100.00,100.00,100.00 is more bytes than 0.00,0.00,0.00).

The calculation in the forwarder is done like this: after initial connection the data forwarder samples data for 500 ms, then looks at the number of lines that came in in that time and it will keep that as the sample rate. If the sample rate differs more than 10Hz from the last time you used the forwarder it’ll update the internal sample rate, otherwise it’ll stay the same (even if there are small differences). We’ve done it that way because a consistent sample rate is important in your dataset (even if it’s a few Hz off).

Thank you so much for your comprehensive answer in such a short time. :smile:

1 Like