SparkFun Forums

[UhClem]

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?

The key word is "unconnected". When connected to something, especially if you have bus termination resistors, it will not fail safe. I suspect that they use weak pull up/down resistors. As I mentioned before some of the Maxim devices do a better job:

The MAX3430 uses a -50mV to -200mV differential
input threshold to ensure true fail-safe receiver inputs.
This threshold guarantees the receiver outputs a logic
high for shorted, open, or idle data lines. The -50mV to
-200mV threshold complies with the ±200mV threshold
EIA/TIA-485 standard.

You might like to read an old article on RS-485 from The Circuit Cellar:

Often a system integrator or even a software engineer is given the task of assembling the RS-485 network. The reasoning is usually something like, "RS-485 is just a twisted pair of wires. How hard can that be to hook up?" The answer is, "Harder than you may think."

[fll-freak]

"Harder than you may think."

You got that right!

The key word is "unconnected".

I read that as no input rather than unconnected. Time to drag to scope out and see what is going on. Thanks for the hints.

[macegr]

When you have the hardware problem sorted out...it's always good to manage serial communications with an eye to signal corruption. Either use a checksum to throw away bad packets if losing a few isn't an issue, or set up a bidirectional system with retries. Non-blocking communication and packet-complete timeouts are also good. That way your program will do something predictable if it loses communication, and won't get hung up on a single byte of corruption.

[fll-freak]

I agree that many applications need some form of error detection and recovery. I deal with these types of communication links all the time. But in this case, it is not critical. The data being sent is status data that comes every 20 seconds. Since it is only being logged, if one number is bad, it is not the end of the world. But with that said, I do plan to add a checksum to the message once the code is stable.

[Polux rsv]

USB is very sensitive to EMI, mainly surge and ESD, even at low level. The controller inside PC shuts down all ports it manages.
Windows is not able to/will not recover alone from this situation. You can only recover by unplug/repluging the device. And sometimes you should reboot windows.
Linux is better on this, as you already know.
Using TVS, capacitors and good shielded cables could help. Adding a ferrite clip close to PC also.

That's why USB is not used as device main interface in industrial world. If only I knew that some years ago, I would not face a lot of complains from customers.

Angelo

[fll-freak]

So this project got interrupted by year end craziness at work and holiday preparations. Yesterday I got some time to play and added the fail safe resistors to the RS-485 converter. Unfortunately I still had the converter disconnect all by itself. Next I spent some time Goggling the EMI error message I get during a disconnect and found that it is not just me. Many people have this problem with a host of different equipment. Some can correlate the issue to EMI, others cannot. So as a test, I plugged the RS-485 into a small un-powered hub and that into my Linux file server. After nearly 24 hours I have not had a single fault.

Not sure what conclusions I take from this. Perhaps the USB hardware on the motherboard is overly sensitive. Perhaps the Linux core is defective (some people have created patches for this issue). Perhaps I still have an EMI issue that the hub is just less sensitive to.

So I will attack the problem on several fronts.
1) I will install the latest Fedora Core OS on my file server (I am currently 4 revs behind).
2) I will order the TSVs and add then to the converter board.
3) I will put the RS-485 converter on another PC and see if the problem follows the board or the computer.