Serial communication stops after long periods.

I use my Arduino as a remote control for my PC. It has a IR Receiver connected, it decodes the RC5 protocol and sends a character through the serial port.
My Arduino uses a FT232RL chip.
It works perfectly, except for the fact that after a long period of time(sometimes 30min, sometimes 3hours), it simply stops sending data through the serial port.
It continues to receive and decode the signals from the IR remote, but no longer sends them through the serial port. (the FT232RL "TX" LED no longer lights up).

This looks like a Windows driver problem to me.
Sometimes, disconnecting and reconnecting the USB cable fixes the problem, but many times, I can't even shut down the computer and have to reset it.

I have Windows 7 x64, and Virtual Com Port driver 2.8.17. (I have tested 2.08.14 and it behaves the same).
Has anyone experienced anything like this before?

Thank you in advance.

Here is my code just in case you need it.

int ir_pin = 2;				//Sensor pin 1 wired through a 220 ohm resistor
int led_pin = 13;
int debug_pin = 11;		    //"Ready to Recieve" flag, not needed but nice
int debug = 0;				 //Serial connection must be started to debug
int start_bit = 2000;			//Start bit threshold (Microseconds)
int bin_1 = 1000;			    //Binary 1 threshold (Microseconds)
int bin_0 = 400;			     //Binary 0 threshold (Microseconds)
int data[12];


void setup() {
  pinMode(led_pin, OUTPUT);
  pinMode(debug_pin, OUTPUT);
  pinMode(ir_pin, INPUT);
  digitalWrite(led_pin, HIGH);
  digitalWrite(debug_pin, HIGH);
  delay(100);
  digitalWrite(led_pin, LOW);
  digitalWrite(debug_pin, LOW);
  delay(150);
  digitalWrite(led_pin, HIGH);
  digitalWrite(debug_pin, HIGH);
  delay(100);
  digitalWrite(led_pin, LOW);
  digitalWrite(debug_pin, LOW);
  delay(150);
  digitalWrite(led_pin, HIGH);
  digitalWrite(debug_pin, HIGH);
  delay(100);
  digitalWrite(led_pin, LOW);
  digitalWrite(debug_pin, LOW);
  Serial.begin(9600);
}

void loop() {
  int key;
  while(1)
  {
     key = getIRKey();		    //Fetch the key
    //  Serial.print("Key Recieved: "+ key);
    if (key > 0)
    {
      //Serial.println(key);
      Serial.print(char(key));
    }
    else
    {
     digitalWrite(debug_pin, HIGH);
    }

  }
}


int getIRKey() {
  digitalWrite(led_pin, LOW);	   //Ok, i'm ready to recieve
  digitalWrite(debug_pin, LOW);
  while(pulseIn(ir_pin, LOW) < 2200) { //Wait for a start bit
  }
  digitalWrite(led_pin, HIGH);
  data[0] = pulseIn(ir_pin, LOW);	//Start measuring bits, I only want low pulses
  data[1] = pulseIn(ir_pin, LOW);
  data[2] = pulseIn(ir_pin, LOW);
  data[3] = pulseIn(ir_pin, LOW);
  data[4] = pulseIn(ir_pin, LOW);
  data[5] = pulseIn(ir_pin, LOW);
  data[6] = pulseIn(ir_pin, LOW);
  data[7] = pulseIn(ir_pin, LOW);
  data[8] = pulseIn(ir_pin, LOW);
  data[9] = pulseIn(ir_pin, LOW);
  data[10] = pulseIn(ir_pin, LOW);
  data[11] = pulseIn(ir_pin, LOW);

  if(debug == 1) {
    Serial.println("-----");
  }
  for(int i=0;i<11;i++) {		  //Parse them
    if (debug == 1) {
      	  Serial.print(i);
          Serial.print(":");
	  Serial.println(data[i]);
    }
    if(data[i] > bin_1) {		  //is it a 1?
	data[i] = 1;
    }  else {
	if(data[i] > bin_0) {		//is it a 0?
	  data[i] = 0;
	} else {
	 data[i] = 2;			  //Flag the data as invalid; I don't know what it is!
	}
    }
  }

 for(int i=0;i<11;i++) {		  //Pre-check data for errors
    if(data[i] > 1) {
	return -1;			     //Return -1 on invalid data
    }
  }

  int result = 0;
  int seed = 1;
  for(int i=0;i<11;i++) {		  //Convert bits to integer
    if(data[i] == 1) {
	result += seed;
    }
    seed = seed * 2;
  }
  return result;			     //Return key number
}

This looks like a Windows driver problem to me.

That is very very very unlikely to be the case. There are thousands of people using the same OS, driver, and chip to shuttle significantly more data without problems.

Please describe the PC side program.

If you ever figure it out please let me know because I've had the same problem for a long time!

I don't know what's causing the problem, but since the PC is locking up that's where I'd start looking.

Can you find out anything from the Arduino side about what state it thinks the USB interface is in? Is it just not clear to send, or is there something else going on like a soft flow control?

While looking for the cause of the problem, I'd also consider more crude workarounds such as resetting the USB interface from either/both sides if it goes silent for an extended period. I decent watchdog and automatic reset can get you out of all sorts of grief. :wink:

Simple test code for use with the serial monitor. Load the code, open the serial monitor, and let the program send the updates to the serial monitor. See how long the serial monitor will continue to update.

int x=0;

void setup() {                
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  Serial.begin(9600);
  pinMode(13, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(2500);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(2500);  // wait for a second
  x=x+1;  
  Serial.println(x);
}

The PC side program is not the problem.
I have this issue when using putty to connect to the com port, and even when no application are connected to the com port. At some point, when using the remote control, the FT232RL "TX" LED no longer lights up.

Now I'm running zoomkat's code. I'll see how it behaves. It's hard to do extensive testing, because many times it takes up to 4 hours for the problem to happen.

oook...
I was testing serial communication with the simple code from zoomkat, and I found what was causing this: the refrigerator... that's right, the refrigerator...

This might seem like a bad joke, but I replicated this 4 times today and I didn't believe it either. Every single time the refrigerator turns off, the serial connection just breaks.

The only connections is that the computer and the refrigerator is plugged in the same wall socket.
Being an old fridge, I'm guessing an electric impulse is sent through the wall socket, through the power supply, and somehow messes up the USB port.

Still looks like a driver problem to me. The driver does not behave correctly when it gets interference through the USB cable.

Any other ideas? Any way to fix this? This shouldn't be happening obviously, since all other things plugged in the USB ports and all of the computer components work perfectly.

Hi i have the same problem.

I see this is only related to arduino uno, as my program is working already for aprox 5 days on arduino duemilanove.

The problem is that i'm building an Andon sistem , and i print on serial the production line status, as messages like, "x" , "a", "f" and i need this messages to always be recieved.
I manage to reset the Arduino Uno Board with watchdog timer, and to trigger an wtd_reset every let's say 1 hour, but the fact all the program variables initialize to 0 this also not quite the solution in my case.
Anyone having other ideas ?

I really feel that the milis() counter gets too big and then the board stucks somehow, but i can't understand why Arduino uno hanges after some random hours amount compared to Arduino Duemilanove.

I also have almost 10 Arduin uno's that I would like to use.

Thank you.

I had a similar problem. The TX light stops blinking. The Sketch continues to run, but the PC doesn't see the data. It has something to do with the USB chip on the Uno. When you run the same sketch on a Pro mini using only 1 wire connected to the serial TX, obviously an LED will still blink if you connect one. You can read this data with serial TTL to USB converter. I'm not saying the USB chip is defective or stops on it's own. It's reacting to something on the PC. Perhaps closing the PC port inadvertently. I'm going to say something obvious here: Something is changing on the PC causing this to happen after a few hours. You can prove this by disconnecting the USB cable, then restarting the sketch without it.

A power surge from the refrigerator could effect the USB chip without resetting the 328?

Twinsen:
oook...
I was testing serial communication with the simple code from zoomkat, and I found what was causing this: the refrigerator... that's right, the refrigerator...

This might seem like a bad joke, but I replicated this 4 times today and I didn't believe it either. Every single time the refrigerator turns off, the serial connection just breaks.

The only connections is that the computer and the refrigerator is plugged in the same wall socket.
Being an old fridge, I'm guessing an electric impulse is sent through the wall socket, through the power supply, and somehow messes up the USB port.

Still looks like a driver problem to me. The driver does not behave correctly when it gets interference through the USB cable.

Any other ideas? Any way to fix this? This shouldn't be happening obviously, since all other things plugged in the USB ports and all of the computer components work perfectly.

Actually it might completly be the fridge. I recall a couple months ago a person was having some trouble with a machine that would monitor the temperature of some beer storage I think, and then use that to control when to turn on the refridgeration. But it kept breaking down because they eventually found out the fridge was causing the problem. Try connecting the fridge into a socket a little farther away and running it. Honestly thats what the other guy ended up doing to fix it. I'll find that forum a little later and link it to you if you don't believe me.

Run the PC through a small UPS - that should completely eliminate any talk between fridge & PC.

Hello,

The same thing happens to me: "TX" LED no longer lights up, but this happens in less than a minute if I send through com port
almost 40 characters at 100ms.

Probably it has something with x64 OS, mine is win 8.1 x64. After updating the FTDI drivers I was able to get around 2-minutes of consistent output.

On a Win Xp machine, with different code, though I haven't got issues :frowning:

I had an identical issue. The port would stop sending after a long time. This would typically be around 2 to 6 hours. At first I was convinced it was spikes on the mains supply causing the Arduino Serial Port Chip to stop working, so I spent a fair bit of time beefing up my power supply. But that didn't fix it. I was on the verge of swapping out the Arduino itself when I thought perhaps there was something going on with the USB ports themselves and so being without a spare Arduino Mega, I decided to investigate that first.

Turns out (in my case) that the USB ports was the problem. I had a USB mouse connected to a motherboard backplane (main) USB port, and the Arduino connected to an "extension" or "extra" USB port hanging off another header off the Mobo. What I did was move the mouse to another Extension port, then moved the Arduino to one of the main backplane ports. Bingo ! - no more problems and it hasn't faulted since. I don't know if its possible for 2 USB ports to have some kind of resource conflict, but it certainly seems that way to me.

Anyway I relate all this just in case it helps someone....

Cheers
David

Update: 10 October 2014 - Its happening again. I now have 2 Mega's: a 1280 and a 2560. The problem occurs on both. Back to the drawing board to try to find out what is going on here. Note: On the PC I've tried Power Options->USB Settings->USB selective suspend (Disable), still no good. Will update here again if I have any more info to share....

David

I'm measuring temperature with uno and ds18b20 and have similar problem, communication stops after hours out of nowhere. For now, to fix it, I have to disconnect arduino from usb then plug it again, and restart my python app.

...which is painfull every time.

AdeV:
Run the PC through a small UPS - that should completely eliminate any talk between fridge & PC.

+1

There is a known Windows bug with USB "unexpected disconnects". One of the members here actually registered a bug report with MS and linked to his video demonstrating it. Seems like it was supposed to be fixed in Windows 8 or 10, IIRC. It was specifically stated that it would not be fixed in earlier versions.

Perhaps the power surge/sag affects some part of the USB hardware chain, and it "looks" like a disconnect. In which case, filtering the power through a UPS or isolation transformer should fix it.

For others with similar symptoms, be sure you're not having a millis rollover problem instead.

Cheers,
/dev

Hi there... same problem here with a chinese nanoV3 clone using the CH340

First of all, me move out last year, on the previous house I did a long log with the arduino, I don't recall any issue.
On the new house, I'm trying to do some recordings, so I put a laptop PC to log the arduino... connection lost after ~2 hours... I thought this might be a USB energy saving problem or something related. But then I change the laptop for a RaspberryPi 3 (under raspbian, the last one to the date) and same problem happened over and over again... time interval for interruption is not fix, but is in the 2 hours order.

And cherry on top, the arduino, the RPi or the laptop, are plugged on the same socket as a refrigerator! what are the odds?

I don't have the time right now, but I'll try to correlate the connection loss with the fridge turning on/off....

Hi there,

For anyone reading this topic.... a minor update:
I burnt my code into the same nano clone, WITHOUT the bootloader, (using another nano as ISP programmer) and it seems to fix the problem... no more sudden stops.

Is it my imagination, or has there been a general increase in exhuming several years old threads lately?