Strange RS485 response

Hi everyone,

I am trying to get two Arduinos to talk to each other via RS485 but I'm only receiving garbage. Here is what I have done:

The three wires connecting them (A, B, and GND) are OK (i.e. ohm-meter confirmed continuous). The wires are about 1' long.
The circuit incorporates a 180 Ohm resistor as a terminator at each end for the A & B.
Transmission and Reception enable has been set (i.e. pull DE/RE pins low on receiving side vs. pulling them high on transmitting side)
I have tried speeds ranging from 4800 to 19200 baud.
The arduinos are using this RS485 communication example code.
The Serial ports of each Arduino are attached directly to these RS485 chips.
I am using version 022 of the IDE for compatibility reasons.

Anyhow, I receive something on the other side, just not the character I sent. Instead of 'A' I get an A with an accent grave (i.e. À) and instead of B I am getting an A with an accent aigu (i.e. Á). The numerical values are 192 and 193 respectively. I know I must be doing something wrong, it's just not apparent to me.

Could the FTDI header that is sharing the serial bus be interfering? The only other thing I can think of is that the 5V rail voltage is too low... I've measured 4.68V on the rail (thanks to a polyfuse) which is below what the RS485 chip is rated for. I could short the polyfuse to get 5V throughout but somehow I doubt this is the cause of my troubles...

Two steps forward, one back.

Took another look at various outputs, realized that the “Master” Arduino was actually serial printing the weird characters that the RS485 chip was faithfully transmitting. The other Arduino had no such issues. At first, I suspected the RS485 chip on the troublesome board somehow influencing the the output, but no such luck. It appears that there is something quite wrong with the Atmel on that bad board. Can’t fix that… short of yanking the chip and soldering a new one on.

I successfully reburned the bootloader, uploaded sketches, etc. But I still do not get good serial output from that Atmel. My guess is that I somehow fried the poor thing during assembly. The good news though may be that I got the RS485 implementation right after all.

I do have two remaining questions re: RS485 implementation:

  1. The data sheets of RS485 chips that I’ve looked at vary in their topology implementation features. Some show A&B being connected to 5V and ground via individual resistors (respectively), some do not. I assume I’m OK in not implementing these additional 560-4.7k Ohm resistors if the manufacturer doesn’t show them in their suggested circuits?

  2. All data sheets show terminating resistors, I’m assuming that a 120 Ohm resistor between A&B as suggested in the data sheet is about right for Cat5E cabling even though my frequency is likely lower than what the Cat5e spec (@ 100MHz) calls for? Or should I be using a 100 Ohm Rt since that’s what the Cat5e specification is suggesting as a characteristic impedance?

I have a diagram here:

The resistors (just the one set) are intended to take the lines to known states while the devices are powered off. I don't know about the terminating resistors, I assume they are more important if you have the ends unconnected (and tap off the middle).

As usual, you have excellent advice. Thank you! The one bit of trouble I ran into is that your library doesn't seem to want to work with the 022 version of the Arduino IDE on my CPU. I am using hardware serial pins, adding a delay as suggested did result in successful transmissions, though the character received is a constant 'h', even when the transmitter is alternating between 'A' and 'B'. More to learn, for sure. Thanks again for the help.

The 120R terminating resistors would not be required for such a short line and (presumably) low speeds. The biasing resistors are often a good idea to pull the line to a known state as Nick said, so-called fail-safe biasing. These days most transceivers have a fail-safe feature so I don't know now necessary it is with a modern chips.


Rob

Graynomad:
The 120R terminating resistors would not be required for such a short line and (presumably) low speeds. The biasing resistors are often a good idea to pull the line to a known state as Nick said, so-called fail-safe biasing. These days most transceivers have a fail-safe feature so I don't know now necessary it is with a modern chips.

Hi and thanks for the response.

The mystery deepens as I delve into the issues on hand. For one, this teaches me to implement test points in all my PCB designs to make deploying a logic analyzer / Oscilloscope easier.

Secondly, there appear to be major software issues on my CPU end that I need to resolve first. Specifically, I have been able to crash the serial monitor application (and by extension the Arduino IDE) quite consistently.

Stranger still, was being able to read in the Serial monitor window output from the Arduino that was being transmitted at 9600 baud while the serial monitor window was set to 28,800 baud. Clearly, that should not have worked.

So now I have little faith in what Serial monitor is reporting to me. Are there solutions out there for Windows 7 that work better? Putty.exe failed miserably... perhaps my USB drivers are toast and need an update?

implement test points in all my PCB designs

That should be standard practice, even if it's only not "tenting" a few vias.

Are there solutions out there for Windows 7 that work better?

I'm surprised that Putty fails, that's a pretty universal program. I use Teraterm but with Vista.

I have been able to crash the serial monitor application (and by extension the Arduino IDE) quite consistently.

It would be good to track it down to the character(s) that caused the problem. Maybe there's a bug in the terminal.

As for the 9600/12800 thing that doesn't make sense. Are you saying that the screen showed exactly the same chars as your Ardiuno is transmitting?


Rob

Here is a quick update,

Arduino 1.0 appears more stable... the 022 Brewtroller derivative I used in the past still crashes happily ever after. I also checked Java, it appears I am current (V6, ed 31). As for the bug in the terminal, I am giving up on that for now.

However, I may have discovered an issue that affects the performance of the 1284p, and hence may explain my RS485 woes. I downloaded and installed the maniacbug bootloader successfully but now wonder if my pin assignments may be off for the Serial1 port because the pins file he shows only indicates pins for the DIP version of the chip, while I am using the TQFP version. Thus, I suspect that there would be similar issues re: the bootloader as with the TQFP vs. DIP versions of the 328P (i.e. the addition of two analog channels, among other things).

So, I'll be PM'img Maniabug to see if his files support the TQFP version or not, and if not, if he would be kind enough to consider releasing a version that does.

Constantin:
Stranger still, was being able to read in the Serial monitor window output from the Arduino that was being transmitted at 9600 baud while the serial monitor window was set to 28,800 baud. Clearly, that should not have worked.

I've seen strange stuff with baud rates. I suspect that the USB converter might be syncing to what it sees as the baud rate.

A logic analyzer would clear that up.

It might be that the IDE is trying to reset the baud rate but that the Win 7 system won't let it. When I tried diving into the advanced options re: my serial driver, Win 7 blocked me. Lacking admin rights, I'll just let this one pass. However, I will attempt the use of a logic analyzer to see what is going on, communications-wise.

Hello,

Just trying to help you out. I had a similar issue when I was connecting my Mega 2560s with RS485s. Make sure you connect RS485’s A and B common to a breadboard and not to connect it directly with another arduino’s RS485.

When I was trying to communicate two Megas with RS485 connecting directly to each other, is when I had garbage values in the serial monitor.