Serial only working right after being uploaded

Projects Programming
1

I'm working on a program that talks between two arduinos, most of you have helped me a whole heck of a lot already with my project so you might be familiar with my code. Well I believe that my code is 100% correctly written but it only works right after I upload it to the Arduino. Let me explain more:

If I plug it in via usb and upload the program it works perfectly, I can see it on the serial monitor working 100% and the TX led is flashing.
Once I unplug it from the USB cord and use either a 9V battery adapter or plug the USB cord back in, it will not work, the ON led is lit up but the TX does not flash, the only thing I can get it to do is flash the L button after I reset it.

Has this ever happened before? I have tried with another arduino and i get the same results so the problem is in my code.

My code:

// SENDER
int grabValue, wristValue, elbowValue, shoulderValue, twistValue, val1, val2, val3, val4, val5;

void setup()
{
  // start serial port at 19200 bps
  Serial.begin(19200);
}

void loop()
{
  // reads analog input for each sensor on the controling arm
  grabValue = analogRead(0);
  wristValue = analogRead(1);
  elbowValue = analogRead(2);
  shoulderValue = analogRead(3);
  twistValue = analogRead(4);

  // remap values
  // 251 through 255 for SYNC
  val1 = map(grabValue, 0, 1023, 0, 249); 
  val2 = map(wristValue, 0, 1023, 0, 249); 
  val3 = map(elbowValue, 0, 1023, 0, 249);
  val4 = map(shoulderValue, 0, 1023, 0, 249); 
  val5 = map(twistValue, 0, 1023, 0, 249);

  Serial.print(251, BYTE); //SYNC char
  Serial.print(val1, BYTE);

  Serial.print(252, BYTE); //SYNC char
  Serial.print(val2, BYTE);

  Serial.print(253, BYTE); //SYNC char
  Serial.print(val3, BYTE);

  Serial.print(254, BYTE); //SYNC char
  Serial.print(val4, BYTE);

  Serial.print(255, BYTE); //SYNC char
  Serial.print(val5, BYTE);

  delay(150);
}
2

only thing I see is that you could make val1..5 of the type uint8_t iso int,

What is on the analog ports?

9Volt battery's are not the best powersource, have you tried a wall wart?

How does the code of the RECEIVER look like?

3

Lets try this approach, I stripped down both codes to basically nothing, the only connections I have are between:
TX pin of the sending arduino to the RX of the receiving
ground from one arduino to the other
a pot hooked from +5V to ground and the middle pin going to A0 on the sending arduino
one arduino hooked to power through my USB cable
one arduino hooked to power through a 9V adapter

Code:

Sending

// SENDER
byte grabValue, val1;

void setup()
{
  // start serial port at 19200 bps
  Serial.begin(19200);
}

void loop()
{
  // reads analog input for each sensor on the controling arm
  grabValue = analogRead(0);

  // remap values
  // 251 through 255 for SYNC
  val1 = map(grabValue, 0, 1023, 0, 249); 


  Serial.print(val1, BYTE);

  delay(150);
}

Receiving:

// RECIEVER
byte incomingByte, grabValue;
byte grabPos;

void setup() {

  // start serial port at 19200 bps
  Serial.begin(19200);
  pinMode(13, OUTPUT); 
  delay(100);

}

void loop() {

  // reads in arm position
  grabPos = analogRead(0);
  if(Serial.available()) {

    grabValue = Serial.read();

  }
  if (grabValue < 150)
  {
    digitalWrite(13, HIGH);   // set the LED on
  }
  delay(150);
}
4

Maybe you should try running the simple blink program on each arduino and see if it continues to run when the power supplies are changed.

5

magruder13:
...
Once I unplug it from the USB cord and use either a 9V battery adapter or plug the USB cord back in, it will not work, ...

Try the following:

int grabValue, wristValue, elbowValue, shoulderValue, twistValue, val1, val2, val3, val4, val5;

void setup()
{
  // start serial port at 19200 bps
  Serial.begin(19200);
  pinMode(13, OUTPUT);
}

void loop()
{
  // reads analog input for each sensor on the controling arm
  grabValue = analogRead(0);
  wristValue = analogRead(1);
  elbowValue = analogRead(2);
  shoulderValue = analogRead(3);
  twistValue = analogRead(4);

  // remap values
  // 251 through 255 for SYNC
  val1 = map(grabValue, 0, 1023, 0, 249); 
  val2 = map(wristValue, 0, 1023, 0, 249); 
  val3 = map(elbowValue, 0, 1023, 0, 249);
  val4 = map(shoulderValue, 0, 1023, 0, 249); 
  val5 = map(twistValue, 0, 1023, 0, 249);

  Serial.print(251, BYTE); //SYNC char
  Serial.print(val1, BYTE);

  Serial.print(252, BYTE); //SYNC char
  Serial.print(val2, BYTE);

  Serial.print(253, BYTE); //SYNC char
  Serial.print(val3, BYTE);

  Serial.print(254, BYTE); //SYNC char
  Serial.print(val4, BYTE);

  Serial.print(255, BYTE); //SYNC char
  Serial.print(val5, BYTE);
  digitalWrite(13, !digitalRead(13));

  delay(500);
}

Here's what happens with my Duemilanove: (See Footnote.)

I upload the sketch and do not open the Serial Monitor window. The pin 13 LED blinks at a 1 Hz rate. The TX led flickers briefly every transition of the pin 13 LED. After 25 or 26 on-off cycles of the pin 13 LED, the TX LED doesn't flicker any more but the pin 13 LED just keeps on keepin' on. (The buffer in the USB chip is full and it doesn't try any more transfers.)

Now, I open the Serial Monitor window. (Of course putting out BYTEs, it doesn't show anything meaningful) The TX LED starts flickering again in concert with the pin 13 LED.

Does that shed any light on the subject? (Ten bytes per loop, stops trying after 2x25 or 2x26 loops...)

Now I unplug the Duemilanove and shut down the Arduino IDE. When I plug in the USB cable again it goes through seven or eight pin 13 LED on-off cycles before the TX LED stops. When I open a terminal program on the USB/Serial port it resets the Duemilanove and transfer is normal (complete with blinking TX LED).

Regards,

Dave

Footnote:
I don't have access to a Uno at the moment, so I couldn't verify the symptoms with anything other than the FTDI interface chip. But maybe it's something you can try. I know the firmware in the USB chip on the Uno has a few problems...

6

magruder13:
Well I believe that my code is 100% correctly written

Worst... assumption... EVER.

magruder13:
After 25 or 26 on-off cycles of the pin 13 LED, the TX LED doesn't flicker any more but the pin 13 LED just keeps on keepin' on. (The buffer in the USB chip is full and it doesn't try any more transfers.)

Maybe I understood this wrong, but the TX LED is driven by the Arduino... so if it doesn't blink, it's the ARduino's fault and not the USB chip on that board. If you were writing on the terminal, and the RX didn't change, then the problem would be on the USB chip.

About the problem... can you try and use this program:

void setup()
{
  // start serial port at 19200 bps
  Serial.begin(19200);
}

void loop()
{
  // reads analog input for each sensor on the controling arm
//  grabValue = analogRead(0);
//  wristValue = analogRead(1);
//  elbowValue = analogRead(2);
//  shoulderValue = analogRead(3);
//  twistValue = analogRead(4);

  // remap values
  // 251 through 255 for SYNC
//  val1 = map(grabValue, 0, 1023, 0, 249); 
//  val2 = map(wristValue, 0, 1023, 0, 249); 
//  val3 = map(elbowValue, 0, 1023, 0, 249);
//  val4 = map(shoulderValue, 0, 1023, 0, 249); 
//  val5 = map(twistValue, 0, 1023, 0, 249);

  Serial.print("This is a test"); //if this works, swap this instruction with: 
//  Serial.print(251, BYTE); //SYNC char
//  Serial.print(val1, BYTE);

  delay(1000);//Start decreasing the timing as you test. 
}

I've never seen the serial print with the byte in it (anywhere), and since this is a problem that hasn't showed up here before, maybe it comes from there.

7

Bubulindo:
I can get it to write correctly in the serial window on my computer but when i try to read the data on another arduino is the problem.

8

bubulindo:
...
Maybe I understood this wrong

That is correct: You "understood it wrong."

The TX and RX LEDs on Arduino boards are driven by the USB interface chip. My example shows, I think, that the TX led does not give a meaningful indication of whether stuff is coming out of the Arduino chip TX pin; only tells us something about USB data being transferred somewhere. There is no hardware handshake between the Arduino UART and the USB chip, so the Arduino can not know whether its stuff is actually going somewhere. If the Arduino TX pin is connected directly to another Arduno's RX pin and there is no USB cable (or the USB cable is plugged into a PC and there is no corresponding USB port open on the PC) the TX LED won't blink the way it does in the presence of an active USB port at the other end of the USB cable.

In the case of Arduino boards with FTDI chips, the blinking apparently occurs when bytes are put into a buffer inside the FTDI chip. (I don't know for sure, since the firmware is closed-source, but my guess is based on observation of programs like the example in my previous post.)

For a Uno or Mega2560 board the USB chip is different from the other Arduino boards (it's an ATmega8U2), and the symptoms are different: If there is no USB connection the TX LED goes on and stays on after the Arduino has sent stuff out its UART pin. You can examine the source code for the Arduino 8U2 firmware that shows why this happens.

If Arduino TX pin is connected directly to another Arduno's RX pin, the bytes go from one to the other. What happens at the other end depends on the software there. (And depends on having the grounds connected together. And depends on the length of the connection wires. And depends on presence and strength of electromagnetic interference. Etc.)

Bottom line: If the TX LED doesn't blink when no data are being transferred out of the USB connector, it's not necessarily the "fault" of the USB chip, it is a result of the design of the USB chip and the firmware thereon. Period. Full stop.

Regards,

Dave

9

Thanks for the explanation Dave, it made perfect sense and I should just trust that my data is being sent. I have another simple question, why do the grounds of each need to be connected together? I'm going to use Xbee's therefor the arduinos will be far apart and the grounds wont be connected together.

10

magruder13:
Thanks for the explanation Dave, it made perfect sense and I should just trust that my data is being sent. I have another simple question, why do the grounds of each need to be connected together? I'm going to use Xbee's therefor the arduinos will be far apart and the grounds wont be connected together.

Grounds only need to be wired together on modules that are electrically connected, like the arudino to it's mated Xbee module. Things that are connected together by radio signals (RF transmission between Xbee modules) do not have that requirement and that is fortunate as we would have to stop calling them wireless. :smiley:

Lefty

11

Thanks for clearing that up Lefty!