MATLAB Answers

how to make fscanf faster

42 views (last 30 days)
Jong-Hwan Kim
Jong-Hwan Kim on 29 Jan 2013
Commented: Jan on 3 May 2014
Hi, all
I have problem with getting data from a sensor using serial communication rs-232. The problem is fscanf takes much time. There is profiler result below.
time calls for i=1:1:1501
2.61 1501 Out(i,1) = eval(fscanf(s));
0.01 1501 end
The sensor provides data(13X1 char) when it is called. I used a for-loop to acquire whole data (1501X13)
1501 calls increase its time. If I reduce the number of calls, the accuracy will be reduced. I want to have high accurate data that means I need to call 1501 times. Is there any way to make fscanf faster? OR any better code to get data faster in serial communication?
Thanks in advance.

  0 Comments

Sign in to comment.

Accepted Answer

Cedric Wannaz
Cedric Wannaz on 29 Jan 2013
Edited: Cedric Wannaz on 30 Jan 2013
15 years ago, I would use fread and "format" the data myself. I don't know how the technology evolved, but my guess is that fscanf, which is quite flexible and powerful, generates a significant overhead.
The list of functions dedicated to managing serial com. can be found here: http://www.mathworks.com/help/matlab/serial-port-devices.html
One additional point, do you really need to format the data "real time" as you receive it? Couldn't you just buffer it for a moment and then format the whole in one shot if really needed? On this matter, you could read the doc of fread, in particular the section about InputBufferSize.
EDIT after seeing your screenshot.
If you read directly 1501 floats with fscanf() or 1501*13 char or uint8 with fread(), you don't need the loop at all for reading the whole stream.
One thing that could happen in your profiling (but I am unsure now, because I've not been playing with serial coms for a long time) is that both fscanf() and fread() are blocking methods that won't return before they get the exact amount of data that you ask them to receive. So in all three cases, the 2.6x seconds that you are measuring are the time that it takes internally to receive 1501*13 bytes (for your bit-rate setting), plus a little overhead due to MATLAB processing. And the overhead is almost not visible because MALTAB format processing goes much faster than usual serial communications.

  6 Comments

Show 3 older comments
Jong-Hwan Kim
Jong-Hwan Kim on 30 Jan 2013
Additional Question After reading your recent comment.
So, How can I use fread() to acquire all the data without a loop. Honestly, when I commanded "char(fread(s,19513))", the data comes 19513 X 1 size of array. For example, ...
4
9
4
3
1
.
0
0
0
0
0
0
O
K
It took about 10 seconds and How can I get only 49431? Thank you.
Cedric Wannaz
Cedric Wannaz on 30 Jan 2013
To summarize, if it makes no difference when you profile with or without feval, or when you profile reading by 13 characters packets or all at once, then it means that the bottleneck is the communication (and that feval,format processing, etc introduce almost no overhead in comparison to the communication).
This doesn't leave you with a lot of options other than to use another type of communication (USB,Firewire,GPIB?), or to change the format of your data. For example, if you have any control on this, send 32bits floats instead of 13*8bits chars. You can compute a rough estimate of the absolute limit of your RS232 communication actually, and see that if your setup is working at 115200 bit/s, sending 19513 characters with 10bits per char (8+2 for the frame) will take 19513*10/115200 = 1.7s approximately. So whatever you do with the current data format, your profiler will never go below 1.7s.
Jong-Hwan Kim
Jong-Hwan Kim on 31 Jan 2013
Thank you so much. I really appreciate that. I will try and see.

Sign in to comment.

More Answers (2)

Walter Roberson
Walter Roberson on 29 Jan 2013
You do not know you are testing the speed of fscanf(): you might be testing the speed of eval(). Are you certain you need eval?

  9 Comments

Show 6 older comments
Jong-Hwan Kim
Jong-Hwan Kim on 30 Jan 2013
Additional result
eval(fgets(s)) and eval(fgetl(s)) produced the same response time. -,.-
Thank you all for advising for my problem. I did what you guys mentioned, but the results showed that the response time was the same as 2.62 sec. Here are detail results from the Profiler.
It was difficult to upload results as pictures here, let me write down below. (1) eval(fscanf(s)) => 2.62 sec (2) fscanf(s, '%f') => 2.62 sec (3) fmt = remat('%f',1,1501); => 0.03 sec Out(i,1) = fscanf(s,fmt); => 2.59 sec => total 2.62 sec
All three approach has the same response time, but all of them acquired data correctly. Is there another approach? I am thinking of that the problem comes from not algorithm but the sensor. I don't know. :( If you guys have another opinion I would appreciate your advice. Thank you.
Cedric Wannaz
Cedric Wannaz on 30 Jan 2013
See the EDIT in my answer..
Jong-Hwan Kim
Jong-Hwan Kim on 30 Jan 2013
I tried to use the parallel processing to make the serial communication faster, like
parfor i=1:1:1501
Out(i,1) = str2double(fscanf(s));
end
But the error message said
Unsuccessful read: OBJ must be connected to the hardware with FOPEN.
Error stack: fscanf.m at 154
Error in Radar_System_04_301 (line 38) parfor i=1:1:301
Could you tell me how to fix the code? Thank you.

Sign in to comment.


Mo
Mo on 1 May 2014
Has anybody a new answer to the latest question here? Why this error might be produces "Unsuccessful read: OBJ must be connected to the hardware with FOPEN." while the port is already open and ready to use?

  1 Comment

Jan
Jan on 3 May 2014
Please open a new thread for a new question.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by