What is matlab's sampling rate through Arduino analog input?

45 hz. In my case average sample time is 0.011008 sec/sample, roughly 45hz, while the Arduino's sampling rate is 10000hz.

[Walter Roberson]

The obvious answer is to program the arduino to collect batches if data, instead of going through the procedure that asks for one sample at a time.

[Jun W]

say I program through arduino ide, and send the data to matlab. and still the data wouldn't be continuously available, which means matlab is the wrong thing for sensor data acquisition.

[Walter Roberson]

I put a lot of effort into answering this question for you. I am disappointed that you deleted your part of the conversation.

[Jun W]

sorry, didn't think those questions were valuable. let me undelete them

Answer 1

[Walter Roberson]

Sensor data is numbers (or sometimes text strings). Sensors do not emit datetime objects. Most sensors do not return times at all. There are some sensors and some recording devices that time-stamp samples; they transfer that information a variety of formats. (For some sensors, resolution to minutes is more than enough; for other sensors, nanoseconds is too crude.)

MATLAB can read whatever data is sent. Sometimes converting the data to a useful format can be a bit of a nuisance (for example the encoding of GPS signals is a bit strange.) The datetime() 'InputFormat' and 'ConvertFrom' options are useful for doing conversions of various time-stamps.

However... your previous questions involve devices that do not emit timestamps, so I suspect that you are asking the wrong question.

[Walter Roberson]

Sure, MATLAB is able to do vibration analysis if it is programmed to do so.

The frequency range that you would be able to analyze over would depend upon how quickly you are able to sample.

The accuracy of the analysis would be limited by your algorithm and by the accuracy of the sensor itself. (Algorithms are important here, because vibration analysis often involves accelerometer readings, but converting acceleration to position is quite prone to numeric errors.)

Your previous question involved querying an analog voltage from an arduino. Each time, that requires that MATLAB send a command to the arduino, and the arduino has to receive the command and interpret it and take the reading and send back the result, and MATLAB has to do whatever is needed to convert what the arduino sent into numeric form. This can be a relative slow process, especially over a true serial port.

USB ports are typically higher data rates than true serial ports, but USB ports have the difficulty that they are a master/slave polled system: the USB master (the PC) sends a query out to each device that it knows is on the USB bus, asking the device whether it has any data to report, and the device answers Yes/No and how much data, without sending the data itself. Then the USB master sends out a message to one of the devices that had data available, saying "Okay, device #C038B9D287, send the next 1000 bytes you have ready" and that slave system has exclusive access to the bus while it does that. And then the USB master sends out the go-ahead message to the next device that had data ready, and so on. Notice that in this process that there is a variable delay between the time that the device has the data ready and the time that the device is told it can send the data, with the delay depending upon what else is going on with the (shared) USB bus -- and even if it is the only device on the bus, there will be a delay between the time the data is ready to go and the time the USB master gets around to giving the go-ahead to send the data. A USB device has no way to interrupt to say "Here's data!!". True serial devices do have the ability to interrupt, but the rate at which they send data is typically slower (they have to work over longer lengths and have to cope with more noise than a USB is designed for.)

Now, one way of reducing the time per sample is to write some code to run on the arduino which waits for a signal from the PC host, and when it gets it, goes ahead and records a number of samples from the analog device as quickly as it can, and when the batch of data is ready, it sends the entire batch back to the PC host. The overhead can be much lower for this kind of setup, but the trade-off is that the data is not continuously available. If you do not need to update your plot faster than 50 frames per second then recording 20 ms worth of data and transferring it as a group is quite plausible.

The overhead of communicating sample-by-sample with arduino is not MATLAB's fault: it is simply the cost of flexibility when communicating with a remote device that is doing things on your behalf. The record-a-batch possibility that I described is less flexible and requires writing more code.

[Walter Roberson]

When you are working with sensors, there are a small number of basic possibilities:

1. That as well as giving you back the instrument reading you asked for, the sensor hardware records some information about the time the sample was recorded, and transfers the time information back along with the instrument reading; or
2. That you use a data acquisition system that communicates with hardware to get instrument readings, and the system supervising the hardware data collection records some information about the time the sample was recorded, and transfers the time information back along with the instrument reading; or
3. That the data collection system makes no attempt to record time information about when the data was collected, but that your host itself records the time at which it receives the data.

Typically if hardware records the time for each sample, it is doing so with respect to triggered samples -- samples that are recorded when particular conditions are noticed.

Typically data acquisition systems that manage data collection and provide time-stamps along with the data are the more "professional" (expensive) systems such as the NiDAQ data acquisition chassis. This is not usually done by individual sensor boards, except sometimes for triggered samples.

Devices that make no attempt to record time are pretty common, and include most of the devices you can attach to arduino or Raspbery Pi.

[Walter Roberson]

Suppose that it took 10 clock cycles for the Arduino to receive the instruction from MATLAB, decode it, take the reading, and send back the results (it probably takes more).

Many of the Aduino run at 16 Mhz, so in this example, that would take about 6.25E-7 seconds

Now how long does it take USB 2.0 to send a packet from the host and get an immediate reply? The answer, according to https://electronics.stackexchange.com/questions/192920/usb-device-latency is about 1 millisecond, 0.001 seconds.

So PC asks to send out a request, it takes about 1/2 millisecond to get there. The Arduino takes (say) 6.25E-7 seconds to process the request, and the reply takes about 1/2 millisecond to get back. Total: 1 millisecond to within the measurement error of "1 millisecond latency".

Now suppose you use an Arduino Due, clock rate 84 Mhz. 10 cycles would be about 1.19E-7 seconds. Host sends out a command, USB 2.0 takes about 1/2 millisecond to get there, arduino takes 1.19E-7 seconds to process (in this example), response takes 1/2 millisecond to return. Total: still 1 millisecond to within the measurement error of "1 millisecond latency".

Now, at 1 millisecond per sample, the most we can expect to be able to process is 1000 samples per second.

Now, I invented the figure of "10 clock cycles" to decode and process and respond, but you can see that because of the 1 millisecond that it would take quite a number of clock cycles to decode and process and respond before using an arduino that is 10 times faster would be the limiting factor. At present we do not have the evidence that it takes that long. It might, and perhaps we could improve from about 45 samples per second (calculated based on the times you show) up to 1000 samples per second. But to do any better than that we need to batch samples, because the 1 millisecond is costing you a lot.

[Walter Roberson]

"Is there a way to "send the request once in the beginning of the frame->Hardware get the N samples->samples go back to PC" ->next frame?"

Yes. As I posted above:

"Now, one way of reducing the time per sample is to write some code to run on the arduino which waits for a signal from the PC host, and when it gets it, goes ahead and records a number of samples from the analog device as quickly as it can, and when the batch of data is ready, it sends the entire batch back to the PC host. The overhead can be much lower for this kind of setup, but the trade-off is that the data is not continuously available."

[Walter Roberson]

You are using the arduino in a way that is easy to program and which is flexible. With simple instructions on the MATLAB side, you can tell it to read one particular voltage, and then you could read a digital pin, and then you might have it send a pulse width modulation to control a motor. Maybe then you would cycle through reading a digital pin until it flipped, indicating that the limiter switch on the motor had been reached. The interface is easy to use and does not require that you know how the arduino works, and you can use the analog inputs and outputs and any add-on boards in any order you want.

The trade off for this is that you have to command every I/O operation, not being able to easily create an input buffer or an output queue.

The arduino can be programmed to do specific operations, such as continually reading from a sensor and putting the information in a buffer to be transmitted as a batch to the host. That can be more efficient -- but it is not as flexible or as easy to code.

[Walter Roberson]

The piezo-electric device you mentioned does not appear to have a serial port: it looks like it just has connectors that you attach to a sensor that samples the voltage. It is not a requirement that the sensor be connected through serial port to MATLAB.