using a RS232->RS485 adapter issues...

Hello,

I'm perplexed in using a RS232C->RS485 dongle that worked perfectly on a Debian Lenny box for years. Now that I'm migrating to Debian Wheezy, albeit, different mobo (Intel mini-itx D2500CC) and serial card (RocketPort), this dongle doesn't work as before.

The dongle sourced working power *from* the host serial port (cannibalizing DTR, etc?). Using the RocketPort, I have to power the dongle separately and create a simple data only pass-thru (TX\RX\GND, no other connections) connection for this dongle to function.

So I don't know if there are voltage level differences on the DTR etc that result in the failure to power the dongle from the serial port.

Also, having examined the serial port configs with stty between the two machines, and making all the settings identical, I don't understand why I have to create the data only pass-thru for communication to work. All hw\sw flow controls are identical between the working machine and the new machine... at least as far as stty reports.

1) What serial pin can reliably measure to determine voltage level for the port (i.e. 12V, 5V, 3.3V)?

2) What else might be different between the working machine and the new machine with respect to serial port config?

3) Is there an stty config that should effectively provide me with the same "port config\functionality" that the data only pass-thru adapter gives me (i.e., can I achieve in software config what I'm doing in hardware)?

The working (and duplicated) stty config is:

speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Or in stty form:

0:4:cbd:a30:3:1c:7f:15:4:0:0:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Thanks,

Rick

That could be.

It's not as common as it used to be, but motherboard serial ports used to put out +/- 12V. The RocketPort card is probably only putting out +/- 5V (the RS-232 spec only requires +/- 3V). Even if the RS485 adapter could run off 5V, the RocketPort card might not be capable of sourcing enough current at 5V to power it.

Have you verified that the pins from which you're scavenging power are in the same states in the two different setups? Is your software explicitly setting the states of the pins from which you're scavenging power (RTS and DTR), or are you relying on the default states for DTR and RTS when the port opens. IIRC, it should be the same for the RocketPort card as for the motherboard UART, but you might want to verify that.

If your adapter requires DTR to be (for example) at 9V or higher, then connecting it to a DTR driver that's only putting out 5V might cause it to malfunction. It's also possible that the adapter with the external power supply is trying to put out a voltage on DTR that's higher than the RocketPort DTR driver output voltage. If that's the case, your adapter could be sourcing current into the RocketPort DTR output. Transceivers can act pretty weird when you do that, and it can corrupt either transmit or receive data. I saw that happen just last week when a 5V RTS driver on one machine was connected to a 12V RTS driver on another machine. Even though nobody was doing anything with the RTS pins, the overvoltage condition on the RTS pin was causing the charge-pump in the transceiver to malfunction causing the negative rail to collapse and as aresult tx data would get corrupted.

Data lines should idle low (-5V). DTR and RTS are usually low when the port isn't opened and high (+5) when the port is opened.

Grant Edwards               grant.b.edwards        Yow! Excuse me, but didn't
                                  at               I tell you there's NO HOPE
                              gmail.com            for the survival of OFFSET
                                                   PRINTING?