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.
Best Answer
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.