5

I use a FTDI USB-RS485 adapter cable to connect a RS-485 device to a computer.

The communication is fairly simple, the computer sends periodic requests, the device answers them.

On one computer (Dell laptop, Win XP) this works as expected, but with another (Fujitsu laptop, Win XP) I have some problems.

Every couple of request, the device does not answer them and claims a parity error. From what we see with PortMon and an oscilliscope the requests are always the same, so should be answered.

The application on the laptops is exactly the same and all drivers (CDM 2.08.24) are the same. One difference is that the problematic laptop had a previous version of the driver installed.

Any hints what I should check?

Edit:

So wie investigated the issue a little more: 2 laptops are working fine (HP, Dell, both WinXP and Intel Centrino), three others don't work (2 Fujitsu, Sony, WinXP, Win7, all Intel i5 or i7).

We measured the signals with an oscilloscope, which are sent to the device. The not working laptops send signals, which jitters around between 3-6 microsec. So we assume, the device is not able to recognize the correct bits due to that jitter. We used different FTDI USB-RS485 cables, but always same symptoms. The working laptops have a jitter of max. 1 microsec.

So my question: why jitters the signal transmitted by the cable on some computers, on others not?

We also contacted FTDI support, but no sufficient answer yet.

Edit2:

So far we have 2 working laptops and several not working. It seems older laptops with Centrino stuff work, so far no newer laptop with Intel i5/i7 CPU worked.

We suspected that there's no internal clock on the adapter and the adapter uses a clock from the laptop, but FTDI support confirmed that the adapter has its own internal clock. FTDI support hasn't heard of this problem in the past and has no solution so far.

Simon
  • 223
  • 1
  • 2
  • 7
  • 1
    You've already gotten two potentially useful answers and subsequent follow up comments, but you've not bothered to upvote anything. You're more likely to continue to get answers if you do. Regarding your update, maybe a full speed vs high speed issue, but I don't know. – Jim Paris Nov 22 '12 at 20:15
  • 2
    You should make some effort to differentiate between jitter within a given character (which is bad and must be contained within limits) vs jitter in the timing between characters, which any receiver should tolerate without upper limit. – Chris Stratton Nov 28 '12 at 21:04
  • 1
    The jitter is within a given character and so the device does not tolerate it. – Simon Nov 29 '12 at 07:30
  • 1
    Check the grounding of the laptop / power supply. – John U Jan 23 '13 at 10:32

4 Answers4

3

I encountered exactly the same problem: FTDI based USB<>RS485 converter (brand is "DIGITUS"), running at 57600bps, working on some machines properly and on some it send bigger chunks of data very very unreliable. What I found out (after wasting lots of time of investigations on grounding and bus termination), is that on fast machines it did not work, because the RS485 driver chip (not made by FTDI) did not release the RS485-bus fast/reliable enough in relation with the output of the FTDI chip. FTDI is releasing the bus after each and every byte (right after the stopbit) via the TXEN port and acquires it immeditately again for the next byte (which on fast machines is already in the buffer). The workaround was, to put a delay between every sent byte and it worked. Yes, pretty bad workaround. Wish FTDI would give an option e.g. in the driver to adjust the TXEN timing.

Ein Gast
  • 31
  • 2
  • 1
    Which delay did work for you? Did you provide feedback to FTDI? – Simon Feb 01 '16 at 16:04
  • I used 1millisecond (since programming in higher language, doing a simple SLEEP(1)). For the application (connecting embedded self developed stuff to the PC), it was not really time critical, just annoying about the uncertainty what might be the problem. – Ein Gast Feb 02 '16 at 20:17
  • That's atrocious on FTDI's part, the driver should have kept TXEN on until the buffer was empty! Grabbing and releasing after every character is just not how RS485 is meant to work. – Milind R Jul 23 '23 at 18:50
2

There are two possibilities as I see it.

1:
You are not completely overriding the FT232 configuration settings when you open the serial interface.

I've done fairly extensive work with FTDI's serial interfaces, and I can tell you that it is very possible to have a serial interface based on one of their devices be in a very weird state upon initial opening. Depending on how you're talking to the port (are you treating it like a serial port, or are you using FTDI's D2XX driver?), I actually had one port open in 7E1 (7 bit, even parity, 1 stop bit) mode upon every initialization, despite the fact that I had never actually used it in that configuration.

The defaults are stored using a whole set of registry keys, but I would recommend manually setting all the port configuration options every time you open the interface, even if you are confident the computer you are on has the correct defaults.

2:
The other possibility I see is more involved:

Basically, FTDI doesn't make USB-RS-485 devices. They only make USB-Parallel, and USB-RS232 devices. As such, to make a FTDI based USB-RS485 interface, you need an additional buffer IC, that is generally controlled by some of the additional IO lines on one of FTDI's USB-serial ICs.

I would guess that it's possible some of the ancillary control lines in your USB-RS485 interface are being set up differently on each computer.

For example, see this schematic of FTDI's demonstration USB-485 converter:
enter image description here

As you can see, the state of CBUS2 and CBUS4 are involved in handling transmit/receive and receive enable respectively.

I can conceive (though it's pretty unlikely), that the FS485 transmit or receive enable line is being configured to use the wrong pin by the driver on one of the computers (you can set TXEN and RXEN to be any of CBUS0-CBUS4. This could cause interesting issues with the 485 interface IC's control lines being floating/indeterminate. However, This seems pretty unlikely to me.

Connor Wolf
  • 31,938
  • 6
  • 77
  • 137
  • I treat it like a serial port and use boost::asio library for the serial communication. – Simon Nov 06 '12 at 11:32
  • @Simon - Is there any way you could test things using the FTDI D2XX driver? – Connor Wolf Nov 06 '12 at 12:03
  • Not a very easy one, but I was considering using the D2XX driver anyway (at leat to test). – Simon Nov 06 '12 at 13:13
  • 1
    A likely suspect where the RS485 enable is concerned would be improper timing of that signal relative to the data, for example the data being disabled before the end of a character. This could happen on some computers but work fine on others, if the scheme for controlling it makes unsafe assumptions about the timing of operations on the USB bus. Increasing the delay before deactivating the driver (or even waiting until you have received it) might be a fix, if you can tolerate a long bus turn around time. But a custom serial converter made from a USB micro would manage the enable best. – Chris Stratton Nov 28 '12 at 21:06
2

We did some more testing on different laptops (sorry for the formatting, I didn't figure out how to format a table here):

Laptop Type | Processor | Serial Comms

DELL Precision M6300 | Intel Centrino | OK

HP EliteBook 6930p | Intel Centrino | OK

Panasonic Toughbook CF-18 | Intel Centrino | OK

Roda Rocky RK9 | Intel Core 2 | OK

Fujitsu Lifebook S Series | Intel Core i5 | FAIL (even on USB3-ports)

Sony Vario | Intel Core i5 | FAIL

HP | Intel Core i5 | FAIL (even on USB3-ports)

So it seems that laptops with USB chipsets for Intel i-processors don't work, older ones work.

However, I bought a USB-ExpressCard (sorry, German webshop) with Renesas USB 3.0 chipset and with that the Fujitsu laptop worked just fine.

So using ExpressCards is a workaround for us, but I still don't know what the exact problem is. FTDI support seemed to be unaware of that issue.

Simon
  • 223
  • 1
  • 2
  • 7
1

Maybe a power quality problem? The chips in adapters like that are usually powered by the PC.

You could use a usb analyzer (software or hardware) to rule out software or driver issues.

Jim Paris
  • 2,685
  • 1
  • 12
  • 12
  • Thanks for your hint. Any suggestions for an Win-based test tool? – Simon Nov 08 '12 at 07:24
  • I now suspect a power issue, because the cable needs 300mA and at that specific laptop serveral other internal devices are connected to one internal hub, so this exceeds 500mA. I will test that next week with an externally powered USB hub. – Simon Nov 08 '12 at 09:06
  • 1
    For Windows software bus analyzers, try [USB Snoopy](http://www.wingmanteam.com/usbsnoopy/) or the newer [Usb Sniffer](http://sourceforge.net/projects/usbsnoop/). In Linux, Wireshark will work. – Jim Paris Nov 08 '12 at 17:17
  • Seems not a power issue, see edited question – Simon Nov 22 '12 at 09:13