Pages: [1]   Go Down
Author Topic: Serial lag  (Read 1120 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Newbie
*
Karma: 0
Posts: 4
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi all,

When I run a simple program (listed below) at 57600 baud, then view the output in the IDE's serial monitor, I find that the output stream stops and waits every second, as if running up against some buffer.  Is this a commonly asked question? What is causing this stuttering behavior?

Here's the program. I'm just running some speed tests; my goal is to sample four analog channels at a minimum of 300 samples/second/channel.

//CODE:
 unsigned long time;
void setup() {
  Serial.begin(57600);
}
void loop() {
  time = millis();
  Serial.println(time);
 }

Thanks,
kpofler
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 176
Posts: 12285
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


Board?

So long as there is a sustained transfer that meets your 300 s/s/c goal, will the "stuttering" itself cause problems?  Does your application also require a low latency?

Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 4
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It's a Fio, with a 328p I believe.

And you raise a good point; my application doesn't need low latency.  It's just a bit unsettling to run into a limitation somewhere in the data channel and not know where it is.  There will be an XBee-to-XBee hop in the final application's data channel, so I wanted to build the application up piece by piece to make debugging easier.  And I'm confused by this stuttering behavior of the simplest possible piece of the application.

At least it doesn't appear to lose any information during the stutters.  The timestamps seem to come in all right:

6000
6002
6002
6004
6006
6006
6008
6008
6010
6012
6012
6014
6017
6017
6019
6021
6021
6023
6025
6025
6027
[ROUGHLY ONE SECOND PAUSE]
6029
6029
6031
6031
6033
6035
6035
6037
6039
6039

I just think that it might be maddening to debug a complex app if I can't get this working as expected.  But hey, I'm not an experienced embedded developer, so maybe that instinct is wrong.
Logged

Seattle, WA USA
Offline Offline
Brattain Member
*****
Karma: 547
Posts: 45982
Seattle, WA USA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Have you tried some other serial monitoring application. The Serial Monitor allows you to scroll all the way back to the beginning of the received data.

So, periodically, it needs to allocate more space to hold that data. I suspect that that is the cause of the pause you are seeing. An application that just let the data scroll off the screen might not exhibit the stutter you are seeing.
Logged

A Coruña
Offline Offline
Jr. Member
**
Karma: 0
Posts: 55
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
So, periodically, it needs to allocate more space to hold that data. I suspect that that is the cause of the pause you are seeing. An application that just let the data scroll off the screen might not exhibit the stutter you are seeing.
And I will add something as a curiosity: if you don't send data with '\n' to Serial Monitor, you will see arduino app crawl.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 176
Posts: 12285
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


You're sending data to Serial Monitor at a fairly high rate.  Even a very good terminal program sometimes has problems keeping up in that situation.  In other (less) words, I agree with PaulS.

Quote
I wanted to build the application up piece by piece to make debugging easier
A VERY good plan.

Quote
And I'm confused by this stuttering behavior of the simplest possible piece of the application.
I suggest staging a more realistic test...

Quote
my goal is to sample four analog channels at a minimum of 300 samples/second/channel
4 channels * 300 samples per second * 2 bytes per sample (minimum) = 2400 bytes per second (minimum)

57600 / 10 = 5760 bytes per second

(5760 - 2400) / 5760 * 100 = 58.4% of the time the serial connection will be idle

(3360 / 5760) / (300 * 2 / 4) * 1000000 = 3889 microseconds between each four bytes

Add a delayMicroseconds(3889); to your Sketch.  How does it behave?

Quote
I just think that it might be maddening to debug a complex app if I can't get this working as expected.  But hey, I'm not an experienced embedded developer, so maybe that instinct is wrong.
I'm not an experience embedded developer either but I can say you will be well served to go with your instinct.
Logged

Austin, TX
Offline Offline
Faraday Member
**
Karma: 63
Posts: 6049
Baldengineer
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I just think that it might be maddening to debug a complex app if I can't get this working as expected.  But hey, I'm not an experienced embedded developer, so maybe that instinct is wrong.

If you make assumptions about the complex system that lets you monitor the simple microc-ontroller, you will go mad.  (e.g., assuming the behavior you see is not "normal."  Streaming a very large amount of serial data from a micro-controller to a PC over several layers of conversion is not "simple.")
Logged

Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com

0
Offline Offline
Newbie
*
Karma: 0
Posts: 4
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks to everyone for the info and suggestions.

I'll try a standalone serial terminal or two and see if that improves things; if I can set a terminal program's input buffer to a large size and still see stuttering, it would leave the Arduino or FTDI cable as likely sources of the stuttering, correct?

I'll also try CodingBadly's idea of a more realistic-for-my-application data rate into the channel.  I was hoping to get it working at close to full 57600 baud, however, so I have a little headroom if we want more samples/second later on.

alfonso.nishikawa:  Am I not sending '\n' over serial currently? Serial.println should terminate with a newline character, right? Since I'm on Windows, I figured Serial.println was sending "\n\r" or whatever the Windows newline is; when I'm on Linux I figured it was terminating with '/n'.  Give me a little more detail on what you meant, please.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 176
Posts: 12285
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


In the final application, what will be receiving the data on the PC side?
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 4
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

An XBee Series 1 in a serial-to-usb breakout board, listened to by a Java app using the RxTx java serial library, and Andrew Rapp's XBee-API java library hosted at Google Code.

I've had no problem setting this up, and can receive and store test data on the destination machine.
« Last Edit: November 23, 2010, 04:20:47 pm by kpofler » Logged

Pages: [1]   Go Up
Jump to: