Serial port freezes

I'm working on a way of getting data into into the Orbiter spaceflight simulator from external controls. I finally figured out how to read my data in C++ computer-side. I had success with a single analog input, it was fast and responsive enough to fly a spacecraft into orbit with just the one input. However a single input isn't very useful so I decided to push things to the max and simulate 100 inputs plus the real input. This introduced control-input lag of course even upping the Serial port speed from 9600 to 115200. So I decided to try and find just where the lag is by timing my inputs. The first time I tried measuring the time however, the serial stream on the serial monitor froze, and I had to manually kill the javaw process and restart the IDE (version 0018). Via commenting, I've reverted my program to the last known working state, but I still get the same lag problem. Here's the complete sketch:

/*
  Interface to Orbiter Flightdeck 
 */
int analog = 0;
//unsigned long time1 = 0;
//unsigned long time2 = 0;
//unsigned long runtime = 0;
char pitch[11];
//char timeout[30];
void setup() 
{
  Serial.begin(115200);  
}

void loop() 
{
  analog = analogRead(0);
  //time1 = millis();
  sprintf(pitch, "<129 %4d>",analog); //the real input
  Serial.print(pitch);
  for(int i = 0; i<100; i++) //simulated 100 inputs
  {
    sprintf(pitch,"<%3d %4d>",i,i*10);
    Serial.print(pitch);
  }
  //time2 = millis();
  //runtime = time2-time1;
  //sprintf(timeout,"Time: %lu",runtime);
  //Serial.print(runtime);
}

Does anyone know what could be causing the Serial port lag and program freeze, particularly since this code used to work? I've checked the Arduino using PuTTY, and the data doesn't stream like it used to either. It comes in blocks, then delays before sending the next set of 101 Serial prints.
Thanks for any help.
Matt

I've checked the Arduino using PuTTY, and the data doesn't stream like it used to either. It comes in blocks

Using which version of the IDE? Since 1.0, output of serial data is interrupt driven. Serial data is buffered until the buffer gets full. Then, the Serial.print() function blocks until there is room in the buffer for more data.

Version 0018 of the Arduino IDE.

What board are you using?

You don't have to output the position as fast as possible. You can only move the control so fast, so add some delay in the loop code so the output buffer can drain.

OH! I'm sorry, I forgot the board, the Mega. Actually, with greater number of inputs, it's beneficial to send the data as fast as I can. In the current setup, I'm sending 11 bytes, or 88 bits, at a speed of 115,200 bits per second. Which for 100 inputs (8800 bits) means a "framerate" of 13fps, or 26fps for 50 inputs, 65 for 20, etc. So I need to make sure that the control inputs are smooth, which means as fast as possible. Of course, these numbers don't include any processing on either end so the "fps" goes down slightly.

MattW:
Version 0018 of the Arduino IDE.

Your sketch may really benefit with upgrading to IDE 1.0.3 as it runs both send and rec serial data in full duplex interrupt mode where as version 18 only used interrupts on receiving serial data from the USB.

Lefty

So you are saying that the FPS is dependent on the speed of the data rate? I would only transmit the updated control position only when they change. You can only move a couple of controls at a time.

You are sending updates as fast as you can generate them. You should adopt a design that either only sends them when they change, or sends them at a defined frequency which the serial link can cope with.

ASCII encoding is easy to develop and debug and a good starting point, but if bandwidth is an issue then you may need to use a binary encoding scheme.

I downloaded the latest IDE (1.0.3) and tried that, and I get the same issue with the serial stream. It's just not sending the data as fast as it should be and freezing the Serial Monitor requiring me to end the javaw process through Task Manager (Windows 7 x64, I also forgot to include my OS, I'm sorry). As for how I send the serial stream, please just let me worry about that until I ask for help. The point is that this was working before, I added the time functions, it began freezing things, I remove the time functions, it's still freezing and I need to know how to fix it. All I want to do is get it back to the way it was before playing with time so I can then begin experimenting on other things.
Thanks,
Matt

Are you using the USB connection for the serial communication? The serial CDC driver uses Bulk transfer which doesn't guarantee a set bandwidth or latency. If you want that you should use a true RS-232 connection or a similar type of connection. You can try connecting the Arduino board to another USB port - one that has fewer devices connected to it. But for any of this to work, you must not fill the buffer on the serial interface faster than it can empty. (115200bps/10cps = 11520Bps for 8N1, note: 1b for the start bit)

Don't use the Serial Monitor for high bandwidth traffic; it cannot handle it. Use PuTTY, Hyperterminal, or some other terminal program.

If you don't want to understand what is causing the problem or how to fix it then I don't see what help you're expecting here.

MattW:
I added the time functions, it began freezing things, I remove the time functions, it's still freezing and I need to know how to fix it. All I want to do is get it back to the way it was before playing with time so I can then begin experimenting on other things.

Go back to the version of code that worked before. If you've changed the hardware since then, change it back to how it was at that time. If you've installed any software on the PC that could have any bearing on USB or serial ports, uninstall it. (Mobile phone apps are a favorite.)

mkwired:
Are you using the USB connection for the serial communication? The serial CDC driver uses Bulk transfer which doesn't guarantee a set bandwidth or latency. If you want that you should use a true RS-232 connection or a similar type of connection. You can try connecting the Arduino board to another USB port - one that has fewer devices connected to it. But for any of this to work, you must not fill the buffer on the serial interface faster than it can empty. (115200bps/10cps = 11520Bps for 8N1, note: 1b for the start bit)

Don't use the Serial Monitor for high bandwidth traffic; it cannot handle it. Use PuTTY, Hyperterminal, or some other terminal program.

Yes I'm using the USB port, but I'm using the same port as I used before with no other hardware alterations to the PC. I'm not really using the Serial Monitor for anything except making sure the Serial stream is actually working. Which it was before, but now is not.

PeterH:
If you don't want to understand what is causing the problem or how to fix it then I don't see what help you're expecting here.

MattW:
I added the time functions, it began freezing things, I remove the time functions, it's still freezing and I need to know how to fix it. All I want to do is get it back to the way it was before playing with time so I can then begin experimenting on other things.

Go back to the version of code that worked before. If you've changed the hardware since then, change it back to how it was at that time. If you've installed any software on the PC that could have any bearing on USB or serial ports, uninstall it. (Mobile phone apps are a favorite.)

I do want to understand, but I understand that some of the suggestions about only sending the data when it changes or other ways of sending the data, isn't relevant yet. I'm working on a faster way to send data, which is what led me to trying and figure out how long the simulated outputs were taking, so I could see where the slowest code sections were and know what to work on first.

I am using the version of code that worked before, with the exception that the new code is commented out. Could the compiler be doing something weird with the comments and still including them a little, or something else weird? My process went like this code that works -> code with time measuring functions causes Serial Monitor to freeze -> new functions commented out, but they still freeze.

Here's the version of the code that used to work. As you can see, it's identical to the above code if the commented lines are actually removed. But even going back to this, the Serial Monitor still freezes, and using another program like PuTTY or my own test application, shows very slow transfer of data rather than the continuous stream of data this code used to produce:

/*
  Interface to Orbiter Flightdeck
 
 */
int analog = 0;
char pitch[11];
void setup()
{
  Serial.begin(115200);  
}

void loop() 
{
  analog = analogRead(0);
  sprintf(pitch, "<129 %4d>",analog);
  Serial.print(pitch);
  for(int i = 0; i<100; i++)
  {
    sprintf(pitch,"<%3d %4d>",i,i*10);
    Serial.print(pitch);
  }
}

MattW:

/*

Interface to Orbiter Flightdeck

*/
int analog = 0;
char pitch[11];
void setup()
{
  Serial.begin(115200); 
}

void loop()
{
  analog = analogRead(0);
  sprintf(pitch, "<129 %4d>",analog);
  Serial.print(pitch);
  for(int i = 0; i<100; i++)
  {
    sprintf(pitch,"<%3d %4d>",i,i*10);
    Serial.print(pitch);
  }
}

I doubt that this code never "freezed." It fills the TX buffer quite quickly.

MattW:
But even going back to this, the Serial Monitor still freezes, and using another program like PuTTY or my own test application, shows very slow transfer of data rather than the continuous stream of data this code used to produce

My conclusion is that either that code is not identical the the code you had working previously, or that the change in behaviour is not caused by the code.