Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

To resolve issues starting MATLAB on Mac OS X 10.10 (Yosemite) visit: http://www.mathworks.com/matlabcentral/answers/159016

how to make fscanf faster

Asked by Jong Kim on 29 Jan 2013
Latest activity Commented on by Jan Simon 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

Jong Kim

Products

No products are associated with this question.

3 Answers

Answer by Cedric Wannaz on 29 Jan 2013
Edited by Cedric Wannaz on 30 Jan 2013
Accepted answer

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

Jong 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 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 Kim on 31 Jan 2013

Thank you so much. I really appreciate that. I will try and see.

Cedric Wannaz
Answer by 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

Jong 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 on 30 Jan 2013

See the EDIT in my answer..

Jong 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.

Walter Roberson
Answer by Mozhdeh 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 Simon on 3 May 2014

Please open a new thread for a new question.

Mozhdeh

Contact us