Serial lag

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

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?

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.

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.

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.

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.

I wanted to build the application up piece by piece to make debugging easier

A VERY good plan.

And I'm confused by this stuttering behavior of the simplest possible piece of the application.

I suggest staging a more realistic test...

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?

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.

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.")

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.

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

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.