Anything special I need to know about RS232 & FT232R?

Question

I'm trying to interface an XSens IMU with my computer, and I'm running into interesting difficulties. The IMU has an RS232 connector that just uses the pins VCC, GND, TX, RX, nothing else. The SDK comes with it has a custom RS232-USB adapter that uses the FT232R and MAX3160, but apart from that it doesn't seem to do anything special.

The manufacturer claims that the IMU uses standard RS232 (and I have no reason to doubt them), so, in order to save space (their converter is quite bulky), I am trying to use a Sparkfun FTDI Basic Breakout 5V.

If I set all the COM settings the same (baudrate, parity, stop, etc), and I connect to the device, I do get data back, but it just seems like gibberish. I issue commands, the TX LED on the FTDI blink, the RX one too, and I get data, but it's nothing like what I am expecting.

Can anyone think of any "gotchas" I may be missing? Is there a FooBar that needs to be connected to the DingDing to Actuate?

Answer 1

Standard rs-232 (like your IMU) and TTL level rs-232 (like the FTDI chip) are different.

Standard rs-232 switches between +V and -V ( where V was originally 12, but now most devices will work on much lower voltages). TTL level rs-232 switches between 0 and 5V. You need an rs-232 transceiver to convert the voltages, such as that MAX3160 chip (Though that's an unusual one - something like the max2332 is more common).

The USB to TTL level rs-232 converters like the one you linked to are are used to connect to a microcontroller, not to a typical rs-232 device.

Answer 2

Are you sure the voltage levels are compatible?

Standard RS232 has ±12V levels, which are usually converted by some MAX chip to TTL levels.

In your case the Sparkfun FTDI breakout board has TTL levels (0/5V), while the MAX3160 can do RS232 and RS485(!), so there is a mismatch.

Answer 3

Looking at the specs for some of the devices on that site, they list the digital interface as being 'max 921600 bps' - so unless you have very good reason to believe the device is operating at that particular baud rate, it would be worth your while to try talking to it at a few other baud rates, especially if you have a good idea what the data is supposed to look like. I'd set my terminal for 115200 and see if the data made any sense at that rate, then, work down the baud rate scale. If you get to 9600 and it still looks like gibberish, go back to 115200 and work up.

A rate of 921600 is almost unheard of. It's a standard multiple, but I honestly haven't seen anything push RS232 faster than 115200 before. By the time it becomes necessary to use faster rates than 115200, designers usually switch to some other, more reliable interface.

Btw, I'm still just assuming that you've connected the device to a PC com port and have some documentation that suggests what the data format is. If it's an option to select a baud rate, use 115200, it will be much more reliable, assuming it is compatible with your overall data rate needs.

Answer 4

One annoyance I've had with FTDI chips, which is probably not the cause of your problems but potentially might be, is that if the remote device sends what the FTDI perceives as a "long break", the FTDI will discard information which it has received from the remote device but not yet forwarded to the PC. This can cause problems in two ways:

• Some embedded devices idle with their serial output low; when they have something to say, they turn on their serial output, send some data, and then go back to idling low once they've said it. If the embedded device is feeding something which can go to sleep when its serial input is low for an extended period and wake up when it goes high, this feature may provide an effective means of wakeup signalling without requiring an extra pin. Unfortunately, the remote device switching off its serial port may cause the FTDI to drop the last portion of the data sent by the device (I've checked with a scope--the data was sent before the line went dead, but the FTDI dropped it anyway).

• When using a typical UART which is set for a faster baud rate than the device to which it is connected, one will generally receive garbage data that contains an identifiable subset of possible byte values. For example, if one is configured for 38,400 and the remote device is set for 9600, one will receive properly-framed byte values and 80, F8, and improperly-framed byte values 00 and 78. Receiving lots of those particular byte values can make it easy to identify the problem. Unfortunately, each time the FTDI sees an improperly-framed 00, it is prone to discard the data preceding it. Consequently, instead of seeing readily-identifiable garbage data, one may end up seeing nothing.

For this reason among others, I have something of a love-hate relationship with the FTDI chips. I use them, and they're reasonably convenient in many ways, but they're not as simple a drop-in replacement for a UART as one might like.

Answer 5

If you are using their software, make sure to change your FTDI's VID/PID to match theirs. Otherwise their software won't recognize your custom serial converter