Sample rate of analog Inputs (RevolutionPi)

[Bastian]

Hi there,

I'm using a RevPi Compact to manage some analog sensor data.
The revpi single input data is written directly to a file to create a list of values.

Now I investigated a very low sample rate of about 1-2 values per second, rather even less.

The question for me is if it's a software problem of Node-RED or a too low sample rate of the adc.

Any ideas how to test or fix it?

Regards
Bastian

[Gunner]

@Bastian

Any ideas how to test or fix it?

I think you would first need to supply much better details of how you are doing what you are now.

[davidz]

The rate is definitely too low. RevPi uses Pi compute 3+, which should be fast enough. To give you an example, our ultra low power wireless sensor sends data to our GU200 gateway wirelessly at a steady rate of 50Hz in real time mode. In batch mode, the sampling rate can go up to 10KHz and allows for FFT analysis:

Wireless gateway GU200 with BLE 5.0 for IIOT applications

GU200 uses Node-RED, so there is definitely no problem with the Node-RED. This is a visualization of vibration data.

Most likely, it is your software set up problem. I don't think RevPi's data acquisition will be that slow with wired connection. They have excellent product line.

[Bastian]

Hi Gunner,

like davidz said im using a Pi compute 3+ based compact control called Revolution Pi to directly record analog sensor data. Additionally I will have 3 Raspberries who add more data (including fotos) via Node-RED and MQTT. (Those arent't part pf the testing setup)

The RevPi has 8 single ended 16bit analog-IN ports with a voltage of 0-10V.

For testing I'm using an analog-OUT with 10V and a potentiometer to create data.
All at the same device, only the cables of the AOUT-Poti-AIN.

This is my Node-setup to collect the data:

That's what's inside the Node: (That I did not create myself cause I fell for the idea to use Node without pragramming in Java Script )

And this is what my recorded data look like on a dashboard: (10s record time, gently turning the poti)

Today the sample rate is quite exactly 1 Hz. The ADC should be able to do better, so the problem seems to be in the transfer to Node-RED or in Node itself.
Even if my record function was slow, the refresh of the AIN-Node has about the same (slow) sample rate.

Regards

[Bastian]

Hi David,

Thanks for your answer and for sharing your project!
10Hz would be already perfectly fine for me. Is your data source also analog voltage?
Your diagram looks a bit higher in resolution but I still count only ~2Hz there (3-4 values every 2s-step). Especially for vibration analysis and fourier transformation you need a much higher sample rate to avoid aliasing (as you know).
In my case we measure the temperature of coolant in a welding application. So the graph should be quite smooth in its course. But still we need more than 1 value every second...

If it's not about Node-RED the only option i see is to directly get the values from the pins with a python script and see if the sample rate is higher there. Is there anything I don't see here (it obviously is ^^)?

Regards

[Bastian]

It could be the AIn node itself. Is there any way to see and change the source code of existing nodes?

[davidz]

Hi Bastian,

There is a reason that you only see limited points in our chart, which is due to Node-RED's dash board chart limitation. If the chart has higher resolution, then it makes the browser slow or even disconnect. We limit the number of points drawn in the chart so that the dashboard works also for slow laptops. Once you reach a high sampling rate, you want to use the delay node immediately before drawing the chart, so that the chart won't slow down the computer. See attached picture for the delay node.

We changed the rate to 10 msg/s one time and the chart froze an i7 laptop. So we had to change it back to 5 msg/s and it is shared among x, y, z curves of the accelerometer. That's why you only see a limited number of points in the chart.

Fortunately, if you want higher solution chart, then you can retrieve the data and view them again in the charts. For static data, you can use much higher resolution. In real time chart with fast data rate, unfortunately, the current dashboard chart does not work well.

For us, we use wireless sensors, so the data transferred are all digital data. The sampling rate at the wireless sensor side can be guaranteed at 25.6KHz, 12.8KHz or 10KHz or lower sampling rate(depending on the model). The resolution is 16 bit.

We use RPI3b/RPI4 and influxdB to save data and also use MQTT to send data out to remote server, which has a much bigger capacity.

[davidz]

This flow supports more than 10 wireless sensors with different types (different types of wireless vibration sensors, wireless temperature sensors, wireless angle sensors and wireless strain sensors et al). You can take a look at our data flow architecture attached here:

The data are saved in the database without the delay node (dropping points).
For real-time chart display, you need to limit the number of points going to the chart node once you reach a high sampling rate.

[Bastian]

Hi David,

your overall setup generally looks quite similar to what we are planning to do. Good to see this kind of systems can work with the RevPi. Thanks for the insight!

Besides the resolution in the dashboard-chart my Analog-In-Node wont record in a higher rate than the 1Hz I mentioned.

Any ideas how to fix this or identify the actual cause?

Thanks and regards

[davidz]

We have influxDB running at the Pi too. It should work very well for your low speed applications.

Do you have an inject node? The "Payload recorder" function needs a source to trigger the measurements. You can add an injection node in front of the "Payload recorder" with a repeating rate of 100ms. This should give you 10Hz sampling rate.

Your temperature data has only one curve, so the chart should be able to handle 10Hz well.

BTW, do you have information about this node? The sampling rate is related to this node too.

[Bastian]

Thanks for the advice but as I understand the code of the record function, it should record all incomming data immediately.
Seeing what is possible with the RevPi makes me think the input node is the root of my problem.
It's the "noderedrevpinode-server"-node for analog inputs of the RevPi. This server works as a bridge between the hardware-layer and node-red.
I just had some trouble updating it, my dashboard still doesn't work^^

[davidz]

Your "Payload recorder" function will record the data coming in. But I don't see a source to set up the rate and that's why I suggest that you put an "inject" node if there is no place to set up the rate.

Can you put a debug node after the "Pin:Ain_1" node and check the rate of message coming in? There should be a place to adjust the sampling rate.

[davidz]

To give you an example, even our ultra low power wireless sensor can adjust the sampling rate easily (see the red line):

There has to be a place to set up the rate for a wired connection with constant power supply

[Bastian]

I think in theory there is this server node to configure, but i dont have it...

I used a chart and a debug node to check the revpi-pin output before the recording node and it's the same result...
how can I use an inject-node to trigger without writing its paylaod into my array?

[Bastian]

Hi David,

I tested the get-pin-node with a 100ms trigger inject node and get 10 identical values before refreshing^^

The problem is the refresh time of the revpi-server.

[davidz]

Yes it is confirmed that the node updates very slow.
Did you install their server software by any chance?

sudo apt-get install noderedrevpinodes-server

If it still does not work, you may have to contact their tech support.

[Bastian]

Hi David,

I just reinstalled everything and the problem is still remaining... I tried to contact their support since I started this topic and I guess I will have to find an independant solution for this. Some external ADC's and RasPis are ordered. The management of the recorded data should work with the Revolution Pi.

Thank you very much for your help. It really helped me out.

Regards
Bastian