SparkFun Forums

[fll-freak]

I have a 9600 baud communication link between an Arduino and a Linux box using these two products:

http://www.sparkfun.com/products/9822 (USB to RS-485)

http://www.sparkfun.com/products/10124 (CMOS logic to RS-485)

I have connected the two together using 30 feet of 2 strand signal wire with foil and wire shield cable. The center wires are used for the A and B. I used the shield for the ground connection.

For the most part, the system works well. But I have two small issues that are driving me nuts.

1) On occasions (~10 times a day), the data coming from the Arduino seems to get corrupted. But the corruption is not overt. Seems like a lost byte not a corrupted byte. Not too worried about this in that I can compensate with checksums and the like. But this may be a symptom of my "real" problem.

2) On occasions (~20 times a day), my Python program barfs trying to determine the number of bytes in the incoming buffer. When this happens, the Linux error log (/var/log/messages) reports the following:

Code: Select all

Oct 29 18:12:17 tux kernel: hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
Oct 29 18:12:17 tux kernel: usb 3-1: USB disconnect, address 28
Oct 29 18:12:17 tux kernel: ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2
Oct 29 18:12:17 tux kernel: ftdi_sio 3-1:1.0: device disconnected
Oct 29 18:12:17 tux python: abrt: detected unhandled Python exception in ./FurnaceMonitor.py
Oct 29 18:12:17 tux kernel: usb 3-1: new full speed USB device using uhci_hcd and address 29
Oct 29 18:12:17 tux kernel: usb 3-1: New USB device found, idVendor=0403, idProduct=6001
Oct 29 18:12:17 tux kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 29 18:12:17 tux kernel: usb 3-1: Product: FT232R USB UART
Oct 29 18:12:17 tux kernel: usb 3-1: Manufacturer: FTDI
Oct 29 18:12:17 tux kernel: usb 3-1: SerialNumber: A800f8b7
Oct 29 18:12:17 tux kernel: usb 3-1: configuration #1 chosen from 1 choice
Oct 29 18:12:17 tux kernel: ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
Oct 29 18:12:17 tux kernel: usb 3-1: Detected FT232RL
Oct 29 18:12:17 tux kernel: usb 3-1: Number of endpoints 2
Oct 29 18:12:17 tux kernel: usb 3-1: Endpoint 1 MaxPacketSize 64
Oct 29 18:12:17 tux kernel: usb 3-1: Endpoint 2 MaxPacketSize 64
Oct 29 18:12:17 tux kernel: usb 3-1: Setting MaxPacketSize 64
Oct 29 18:12:17 tux kernel: usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB2

The USB subsystem seems to close down the port and that kills my Python application. If I wait a few moments I can often restart the program. But sometimes the OS reassigns the USB device to a new device.

My goggling finds people who have had this issue with devices that generate lots of static like those vinyl dance pads. My implementation does not seem to have include a large static source, but it might include sparking as the furnace it monitors includes relays. But the monitoring is all done via optical isolators and isolated power supplies for the Arduino.

So I am wondering what I might do differently to suppress noise that somehow is going up the USB cable and nuking the USB device driver on the Linux box. Any ideas welcome.

I have been thinking of making sure the ground/shield on my 485 cable is well grounded to the safety ground in the house, but I am unsure if that is wise.

[MichaelN]

I'd be surprised if this is EMI, especially with such a short cable & low data rate. My money would be on this being a software issue. RS-485 is half-duplex, so you''ll have problems if both ends try to transmit at the same time.

Can you give more detail about the "ground" connections? It sounds like you're connecting it via the cable shield, which would be good. RS-485 is designed to tolerate up to several volts difference between the ground at each end, but there needs to be some connection. Sometimes I've seen a single, unshielded twisted pair used, with the RS-485 ground provided by the house ground connected at each end, but a dedicated ground conductor as you have is best.

The PC end will be grounded to the house ground via the USB ground, unless you're using a laptop without a ground connection on the power supply. In any case, I wouldn't suggest adding additional ground connections, since you're not relying on the house ground.

[Mee_n_Mac]

Off the top of my head I'd try holding the Arduino in reset (or otherwise ensure it's not sending anything) and leaving all the connections intact. Just have the PC looking for messages and see what happens. If there's truely noise on the line you should still see some malformated messages from time to time.

How does the Arduino get it's power ? I'll guess some form of USB "charger" ? Are it's 5 V output and return isolated from the house AC ground ? (my guess is yes but ...) If not then you might be getting ground noise on your cable shield and so cutting that connection might help.

I'll assume for the moment the line is used for 1 way comm, from Arduino to PC. How sure are you that the USB converter isn't occasionally switching from Rx to Tx and putting a glitch on the line ? From the schematic it's hardwired so there's no easy way to isolate the TxDEN line short of cutting a trace.

How hard would it be to make another 20' cable and have your Arduino sitting at the base of the PC, connected by this new cable ? (obviously not monitoring anything real) If the problem persists despite the change in environment, it would seem to rule out relays, etc being the cuplrit.

[Xantor]

The BOB is missing all basic protection circuitry on the RS-485 side.

I'd start with something like this:

Code: Select all

 |---+-----------+--------------- VCC
 |    |             ^
 |    \ 1K        TVS
 |----/----+-----+--------+------- A
 |    \      |      ^          /
 |    |      \     TVS        \ 120
 |---+-----/-----+--------+------- B
 |           \      ^ 
 |       1K |    TVS
 |---------+-----+--------------- GND

and see if things improve

Edit #&* ascii art..

1K from VCC to B, 1K from A to GND, 120 OHM from A to B (termination), 3x TVS between VCC and A, A and B, B and GND

[fll-freak]

Thanks for the ideas. Currently they are all "useless" as I am the victim of the massive snow storm that hit New Hampshire. Saturday night was like living in a war zone. Transformers exploding lighting up the night sky. Trees snapping taking down power lines and damaging homes. I slept on the ground floor dressed in my clothes against an interior load bearing wall away from all windows. The morning showed major tree damage but luckly nothing that hit the house.

I am told to expect power to be out for a week. When I get back on the grid I will try out these ideas. Hope others survived as well as I did.

[Mee_n_Mac]

I am told to expect power to be out for a week. When I get back on the grid I will try out these ideas. Hope others survived as well as I did.

A liuttle OT but ...

Fun wasn't that ?!? I left Alton Bay about 4:30 pm to drive south. Got a bit ugly just south of Manchester. Power just over the border in northern MA is out (in most places) as well. I heard it'll be at least another 2 or 3 days and even then ... Wouldn't you know it, work is the only place nearby that has power.

[fll-freak]

Day 3. Power still out. 29,000 houses in my zip code still without power. Had to drive 35 miles to find a gas station that had electricity for the pumps. Have a small generator to run hot water and pellet stove. Now I need a camp stove to cook. Hosting a family that has no source of heat. This is getting old. I want to play with my toys and hunt down this problem.

[UhClem]

I see one possible problem.

When the RS-485 line isn't driven it will float and the 120 Ohm termination resistor will tend to keep the differential voltage very close to zero. The SP3485 receiver output is only defined for differential input voltages greater than +/-200mV. Zero is in the middle of this no mans land so the output is undefined and the receiver could do anything including spitting out random crud. Which could confuse the USB hardware.


You could add fail safe termination resistors to make sure of the line state but that adds parts and extra power dissipation. I happen to like some of the Maxim parts such as the MAX3430. Its receiver has switching thresholds that put zero volts squarely in a defined state. It also has good fault and ESD protection.

I have a MAX3430 connected to a modified SparkFun FTDI Basic and I am not having your problem.

[fll-freak]

I am now back on the grid and can respond to the great responses I got.

I'd be surprised if this is EMI, especially with such a short cable & low data rate. My money would be on this being a software issue. RS-485 is half-duplex, so you''ll have problems if both ends try to transmit at the same time.

I am aware that 485 is half duplex. This project is only every using the link in one direction. The furnace monitor talks and the Linux box listens. The fact that the Linux box reports an EMI issue is interesting. I will try to find the source for the driver and see under what circumstances the driver reports EMI.

Can you give more detail about the "ground" connections?

On the furnace monitor side, the cable shield (foil and wire overwrap) is connected to the CMOS to RS-485 Sparkfun BOB. The BOB has a common ground with the CMOS side. The CMOS side is connected to the Arduino's ground. The Arduino ground comes from a 2 plug wall wart. This might be an issue in the wallwart ground is likely floating relative to the earth ground.

The Linux side ground connects to the USB to 485 converter. This ground is tied to the USB ground. I assume this ground is not floating but tied to earth ground.

You could add fail safe termination resistors to make sure of the line state but that adds parts and extra power dissipation.

Thanks for the link. I have studied the document and will likely implement the various ideas. Due to a change that SFE put into the CMOS to 485 converter, the bus is mostly un-driven. Rather than using the RTS line to switch direction they allow the chip to enable the TX enable line automagicaly. When ever the UART is active it enables the transmit the buffer.

The BOB is missing all basic protection circuitry on the RS-485 side.

Seems like a theme that is evolving with SFE products. I have found several products that get close, but miss the mark in some way. I think in the rush to get products for the weekly "new products video" the engineering testing cycle is reduced or they fail to include independent peer reviews. The 485 devices are the worst so far. My biggest complaint being that they switch off the receiver buffer when transmitting. This makes multidrop or full duplex operation IMPOSSIBLE.

In any case, your protection circuit is similar to that of the document UhChem linked to. Yours include the TVS that just makes the design that much more polished. Now to see if I retrofit the BOB.

Thanks you all for the help. I hope to get to work on this today. Besides the 7 day power outage, I have been up to my eye balls in a do or die demo project at work.

[fll-freak]

Well I solved the corruption problem. This was indeed a software bug. My code timed out waiting for a carriage return and terminated the input. This had the effect of looking like a corruption by inserting a CR. Changed the receive timeout mechanism and no more corruption.

Now the second problem of the USB driver going off line due to an "EMI" issue is still an open issue. I have not seen the problem in the hours I tested today. But today was warm and the furnace did not come on very often. I am thinking the issue is from a power spike when the air handler (220V AC motor) or circulation pump (110V) kicks on. We shall see.

[fll-freak]

Another fascinating tidbit for those coming after me...

The Arduino Serial.print and Serial.println functions have an errata that would mostly be immaterial except when using RS-485. When calling these functions, the last byte(s) are not transmitted till sometime after the function call returns. If after a return, you immediately disable the transmitter you will chop off all or part of those last bytes.

The Arduino reference page indicates it is just the last byte, but it the case of println, I see both the CR and the LF being nuked.

There is a slight chance that my "EMI issue" may in fact simply be cut apart terminal bytes. We will see...

[fll-freak]

I have gotten some time to get back to this problem. My initial "fix" was just to allow the device driver on the Linux side to disconnect and when it did, I would have the software find its new device name, open it an continue on. A terrible hack that was good for the short term only.

I am fairly convinced that the lack of fail safe pull up/down resistors is allowing the bus to float and likely causing a glitch that the FTDI chip reports to the device driver that causes it to disconnect. I have read the TI document linked to on failsafe resistors for a passive bus. But a comment in the Conclusion section indicates that some transceivers have built in failsafe such as the SN65HVD308xE family. Reading the Sipex datasheet provides the following comment:

The receiver for each of the three devices is equipped with fail-safe. Fail-safe guarantees that the receiver output will be in a HIGH state when the input is left unconnected.

This would tend to make me think that the SP3485 has built in failsafe resistors and I should not need to add my own. Am I missing something?

[fll-freak]

1K from VCC to B, 1K from A to GND, 120 OHM from A to B (termination), 3x TVS between VCC and A, A and B, B and GND

Any suggestions for values of TVS? I assume the values should be about 3.3V preventing any line from having a higher potential than any other line by Vcc (3.3V).

[Dave Mueller]

For RS485, use a TVS of at least 6V. Also, to see if the bus is floating, simply measure the voltage across the A and B terminals.

[fll-freak]

For RS485, use a TVS of at least 6V.

Amazing what you see when you read a datasheet for the tenth time. The AB lines are rated to +- 15V. Your suggestion of 6V makes sense. I alos like your idea of measuring the voltage across AB. Should have figured that out sooner. I think I will set up my scope to look for spikes on either A or B and see if it corresponds to the device driver freaking out. Now I have something to do tonight!