Read data continuously from accelerometer through serial COM

Hi all,

i would like to read continuos data from an accelerometer.Before i was using hterm but it does not support long recording.

I was wondering if i can do that with matlab

baud 8200000 (13byes=1+4+2+2+2+2)

Can anyone help me with this?

Thanks a lot in advance!

[Walter Roberson]

With that baud rate and that packet size, in theory you could be aiming for an update rate on the order of 70000 updates per second. In practice, using the serial port facilities, you will not get even remotely close to that.

Unfortunately I have not had time to do any tests for what update rates are possible in practice.

If you were using Simulink, you could use Simulink signal logging; there are a couple of explicit examples about that in the context of serial communications, including https://www.mathworks.com/help/supportpkg/texasinstrumentsc2000/examples/parameter-tuning-and-signal-logging-with-serial-external-mode.html

Do you have an SSD you can log to?

[Francesco Lucarelli]

Hi Walter, Thanks for your reply

I take out data from 2 accelerometer via STM board, so the comunication is made via serial. previously i was using hterm

In matlab i can log the serial port with that baud (device=serialport("COM3",8200000)), but i don't know how to read continuosly data streamed out of it.

I don't have an SSD embended on the board

[Walter Roberson]

Use the serialport read() function to read from the serial port.

configureCallbackFcn (or a similar routine name) to be trigger a callback when data is available. I would not recommend setting the threshold at 13 bytes: set it for on the order of a quarter second of data unless you need to plot more often.

[Walter Roberson]

The question about SSD is not about whether you have one on the board, but rather whether you have one on the host system that you are doing the logging on. When the data you are logging exceeds the amount of memory you have available, then it helps to have a fast mass storage system.

Question: do you need to do anything with the data as it is being read? Or do you just need to record the data for later analysis? If you do need to process, do you need to do so continuously (most events), or would it be okay to just sample periodically?

What is your target samples per second ?

[Francesco Lucarelli]

Hi Walter,

Thanks again for your feedback. Much appreciated.

Question: do you need to do anything with the data as it is being read? Or do you just need to record the data for later analysis?Answer: The analysis is done after the acquisition, so i just need to record the data for later analysis

I do have an SSD on the host system.

Question:What is your target samples per second ?

Answer: the sampling frequency is at 26khz

That' why i was thinking about matlab, to store data directly and then analysing them. I wrote a small script like the one below:

%%
device=serialport("COM3",8200000);
n=1;
while n>0    
    read(device,13,"uint16")
    n=n+1;
end
%%

Could you give me an example of how i can improve it?

Thanks a lot for your help and your time

Kind Regards

[Walter Roberson]

%read a nominal second's worth of data at a time
%in this version, store it all at first -- it should be about 600 megabytes

blocksize = 13;         %bytes
test_duration = 30*60;  %seconds
target_sps = 26000;
bytes_per_second = target_sps * blocksize;
buffer = zeros(bytes_per_second, test_duration, 'uint8');

device = serialport("COM3",8200000);
full_cols = 0; partial = 0;

start_time = tic;

for K = 1 : test_duration
   try
     thisbuffer = read(device, bytes_per_second, 'uint8');
     blen = length(thisbuffer);
     buffer(1:blen,K) = thisbuffer;
     if blen == bytes_per_second
         full_cols = K;
         partial = 0;
     else
       full_cols = K - 1;
       partial = blen;
       break;
     end
   catch ME
       full_cols = K - 1;
       partial = 0;
       break
   end
end

read_time = toc(start_time);

clear device

bytes_received = full_cols * bytes_per_second + partial;
bytes_per_second = bytes_received / read_time;
samples_per_second = bytes_received / blocksize / read_time;
fprintf('Actual throughput: %.3f bytes/second, %.3f samples/second\n', bytes_per_second, samples_per_second);

[fid, msg] = fopen('testlog.bin', 'w');
if fid < 0
   fprintf('Could not open output file because: "%s"\n', msg);
   fprintf('Data is still in buffer(1:%d)\n', bytes_received);
else
    fwrite(fid, buffer(1:bytes_received), '*uint8');
    fclose(fid);
end

Start with a shorter test.

If the logic works and the throughput is high enough, clone the function and rearrange slightly to fwrite() thisbuffer to the file as you go, and see whether the throughput drops more than you are willing to live with.

The more data you can record in memory before writing to disk, the more efficient writing will be -- but the more risk that everything will get lost if something goes wrong. For example, this code has no STOP logic in it, and if you control-C then it will not write to disk (but buffer will still exist). It would be more robust to write results to disk as you go, but you need to accumulate enough to be worth writing.

Generally speaking, operating systems need to be fed at least 4096 bytes to write efficiently, preferably 16K at least, 64 K is better.