5
\$\begingroup\$

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?

|improve this question|||||
\$\endgroup\$
  • 1
    \$\begingroup\$ what are the port settings, and what have you connected it to so far? was this a PC you connected it to? is this the 921600 bps device in your other question? \$\endgroup\$ – JustJeff Jul 17 '10 at 1:03
  • \$\begingroup\$ I have set the device and VCOM port to 115200, 8bit, no parity, 2 stopbits, no xonxoff, no rtscts, no dsrdtr. Yes, it is the device in my other question. For the moment I will be using a PC, but would like to put the whole system into a box later on. \$\endgroup\$ – talsit Jul 17 '10 at 7:35
  • 2
    \$\begingroup\$ VCC is not standard RS232. \$\endgroup\$ – starblue Jul 17 '10 at 8:42
  • \$\begingroup\$ 2 stop bits is uncommon, the default usually is one stop bit. \$\endgroup\$ – starblue Jul 17 '10 at 8:44
  • \$\begingroup\$ I accepts 5-30V as its VCC, and it does use 2 stop bits. I have tried both 1 and 2 stop bits though. \$\endgroup\$ – talsit Jul 17 '10 at 9:24
12
\$\begingroup\$

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.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ I think this sounds like what I'm doing wrong. I would need one of those transceivers. I think they chose the MAX3160, because it does up to 1Mbps. Anyone know where I can get a single board that can do USB at one end, and "true" rs232/EIA-232 the other? And be capable of speeds up to 921600? \$\endgroup\$ – talsit Jul 19 '10 at 5:25
4
\$\begingroup\$

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.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ I'll have another stab at it, but from reading the specs, the xsens will accept 5-30v! \$\endgroup\$ – talsit Jul 17 '10 at 9:25
  • \$\begingroup\$ Yes, but what does it output? \$\endgroup\$ – Connor Wolf Jul 17 '10 at 10:18
  • 3
    \$\begingroup\$ Also note that polarity between RS232 and TTL is inverted. \$\endgroup\$ – starblue Jul 17 '10 at 18:21
3
\$\begingroup\$

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.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Yes, I have tried most of the baud rates available to me. I have tried all stopbit, bytesize, buadrate combinations. I am sending through about 44kB/s through the serial cable. However, as a trial, I have tried reducing the datarate from the device to 8.4kB/s, and the baudrate to 115200. With their USB-Serial, it all works, with the FTDI, I get the same gibberish as before. I can configure the device to a variety of baudrates, sample rates, etc, but I have not had any luck with the FTDI :( But thanks! \$\endgroup\$ – talsit Jul 17 '10 at 7:56
  • \$\begingroup\$ I ran into a situation once where a USB/FTDI based port that was supposed to be capable of 115.2k wouldn't play at that speed with a certain device. In that case, the device worked fine when connected to a 'real' com port built into the computer, and the FTDI based port worked with other devices at 115.2; but FTDI and that one device was just a pathological combination of interface chips. \$\endgroup\$ – JustJeff Jul 17 '10 at 12:55
  • \$\begingroup\$ JustJeff, I have a similar situation with a peripheral we embed in our products. It works fine with a computer's serial port, but not with a PIC. Turns out its baud rate is a bit off. Apparently 'real' serial ports are more forgiving than microcontrollers. Luckily the PIC can be run at non-standard baud rates. \$\endgroup\$ – Jeanne Pindar Jul 17 '10 at 14:14
  • \$\begingroup\$ @Jeanne Pindar: yeah, i've had that happen too. You get one device that's a little slow, another that's a little fast, and most things play with most other things. But once in a while you find that even though A talks to B and B talks to C, you just can't get A and C to talk, and the O-scope comes out.. \$\endgroup\$ – JustJeff Jul 17 '10 at 15:11
1
\$\begingroup\$

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.

|improve this answer|||||
\$\endgroup\$
1
\$\begingroup\$

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

|improve this answer|||||
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.