RS232 reading problems

Hello forum, I am trying to interface an Arduino Mega 2560 to another board (where an ELM232 chip lives) via serial.

To troubleshoot, I have connected as follows on a breadboard:

ELM232 board's Tx to:

  • PC via USB to serial adaptor.
  • Arduino's Rx3.

All share a common ground.

When powering up the ELM232, it sends the following string:

ELM323 v2.0

>

I see this perfectly well on the PC, using a terminal program at 9600 8N1.

The Mega, however, spits out complete garbage. The source code I use is here:

#define ELM_BAUD 9600

int buffer[50];

void setup() {

Serial.begin(9600);
Serial3.begin(ELM_BAUD);

}

void loop() {

int c;

// We will let a long time pass between the incoming data burst to make 100% sure no timing problems occur
if (Serial3.available() > 0) {
delay(1000); // twiddle thumbs for a second to make sure burst is over
int index = 0; // this will count our incoming bytes

while ( (c = Serial3.read()) != -1) buffer[index++] = c; // fetch the received bytes

Serial.print("Read these ");
Serial.print(index, DEC);
Serial.println(" characters:");

for (int i=0; i < index; i++) {
Serial.write(buffer*); // print as a byte*
_ Serial.print(":");_
_ Serial.println(buffer*, DEC); // print ASCII value*_
* }*

* }*

}
[/quote]
The result I 'm getting on the Arduino IDE's terminal is:
*_ <em>*Read these 18 characters: y:121 ½:189 ×:215 V:86 V:86 ¶:182 ?:150 ö:246 ?:155 ?:155 £:163 ?:159 å:229 ë:235 å:229 ë:235 ?:131 :0*</em> _*
I 'm completely stumped. I 've tried all the Mega's available UARTs but it's the same everywhere. Any idea what is happening here?
P.S. The characters are indeed 18 and in Hex they are these (copy pasted from the PC terminal shown in hex, including linefeeds and carriage returns):
*_ <em>*0d 0a 45 4c 4d 33 32 33  20 76 32 2e 30 0d 0a 0d 0a 3e*</em> _*
Out of desperation, I have tried other baud rates (by changing the #define ELM_BAUD ... in the code) but, unsurprisingly, only 9600 gets the correct number of bytes.

Serial.read() returns an int, so that it can indicate that an error occurred. The real data that it returns is a byte, though. Why not use a byte array to hold the values?

If the terminal application is showing the data in hex, why are you printing it in decimal?

Agreed with previous post: You are storing each byte of data as an integer. Since integers are greater than 8 bits, you will not get the correct ascii representation when you use serial.print or serial.write.

Can I ask, how did you use the PC to read the elm chip? Was this with an FTDI breakout type device? Do you have the correct start/stop/parity bits setup with the Arduino as you used in the terminal program you used?

Regarding my last post: I wanted to if the ELM 232 board is a TTL interface or PC-RS232 voltage level.

Guys, thank you for the replies. Unfortunately, I found the reason, my intellectual inadequacy :stuck_out_tongue: :blush:

The RS232 coming from the PC is at a different logic level than the 0-5 the Arduino uses.

@johnnyonthespot. The ELM232 datasheet contains two sample circuits for interfacing the chip and I 'm using a board made by a friend which follows one of them. Now, the board converts the ELM232 Rx/Tx to the logic level expected of a PC RS232 and spits it out over a DB9 plug but that is not readable "raw" by the Arduino. The simple solution was to touch the ELM232 Tx pin directly with a jumper wire connected to the Arduino's Rx and hey presto, it all works. Quick and dirty hack is to simply bypass the board between the chip and the RS232 plug and solder wires directly to the tracks under the chip's legs.

As for using int as opposed to bytes, I was in a hurry (OK, guilty, I could have cast it into byte before putting it into the array).

Thanks again guys.

I'm glad you figured it out. During my senior design project (a few years ago) I ran into the same issue when trying to get 2 microcontrollers to talk to eachother; it turned out one had a jumper-selectable pc-level rs232 output that was selected. Took a looong while to figure out, since it was my first time dealing with serial communications.