rs232slaveusb
I have a system where there is usb slave device that is in a rotating structure behind a slipring. I need to pass the signal through the slipring (we only have 4 "wires") and onto a computer. Due to the long distance and noisy environment I'd like to convert the usb signal to rs232 or 485 but my understanding is that usb to rs232 dongles do not work on slave devices.
Does anyone have an idea as to how to do this? There are usb to cat5 but I only have four conductors.
Here is how I would suggest going about debugging this problem:-
Check the connections.. if you've mixed up signal ground and chassis ground (shield) you could get funny behavior just like you describe. Pin 7 on the DB-25 is the one you want to connect to DE-9 pin 5. I'll assume you're using a commercial adapter/cable or have one wired like this.
Maybe check the transmit out line to ensure it's idling at -12 ( < -3 anyway).
Make sure the instrument is set to RS-232, and not current loop (Jumper 7,8 and 1,2).
Try the most common serial port setting (9600/8-N-1), 9600 baud, NO parity, 1 stop bit switch 1, 2, 3 OFF switch 4, 5 ON switch 6 ON switch 7, 8 ON
Make SURE you understand which is 'OFF' and which is 'ON'. Don't laugh, I've seen this happen more than once, and some types of DIP switches are kind of ambiguously marked. If in doubt, an ohmmeter across the switch.. in fact you could check all of the switches to ensure they're working.
I like Realterm as a terminal program. It's free, and easy to change the parameters. Try it on something known working first of course, and look for an online tutorial. Really worth it.
If still gibberish after that, get a scope screen cap or photo and post it.
If you have a continuing need for a logic analyzer, this one is very cheap and relatively useful. Not as good as my Tektronix boat anchor, but this one will fit in a coat pocket. But I'd get a scope first if you don't have one. Even the worst scope is better than nothing.
At my last company we found that USB-to-RS-232 converters can have a problem when they expect an almost instant responce from the RS-232 device. I was advised by the design engineer for our equipment that USB uses data packets. So when using USB, unless the software/drivers force a USB packet of data to be sent, the USB driver can hang around for more than a second (5000 ms) waiting for the packet to be filled before sending the incomplete data packet.
This meant that a lot of older DOS/Windows programs where they monitored RS-232 status lines would time out. The older programs often used timing loops based on looping a certain number of times... So as the PCs got faster, the polling got faster. As the length of time the polling continued to effectivly get shorter, USB came along.
The polling effectively became a memory location... (The drivers are usually optimised for maximum data packet throughput and didn't pass the status information on, because it was waiting to fill a packet). The drivers can sometimes be adjusted to help with this. FTDI drivers can adjust a lot of values in their configuration file. (Great for non-standard data rates.)
This meant we often had to run programs on desktops with RS-232 ports or drag the laptop base station out to the equipment to get it to work.
See page 6 of the application note Advanced Driver Options for USB time out adjustments...
And for odd baud rates up to 3 Mbit/s, see Configuring FT232R, FT2232 and FT232B Baud Rates.
Best Answer
I don't think this is straightforwardly doable, the speeds are too different. Best you could manage is: