linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: linux-serial@vger.kernel.org
Subject: Re: using a RS232->RS485 adapter issues...
Date: Mon, 22 Apr 2013 21:53:37 +0000 (UTC)	[thread overview]
Message-ID: <kl4bh1$lir$1@ger.gmane.org> (raw)
In-Reply-To: 51757F18.8070908@gmail.com

On 2013-04-22, Rick Bolen(gm) <rickbolgm@gmail.com> wrote:

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

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.

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

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.

> 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)?

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?


      reply	other threads:[~2013-04-22 21:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-22 18:19 using a RS232->RS485 adapter issues Rick Bolen(gm)
2013-04-22 21:53 ` Grant Edwards [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='kl4bh1$lir$1@ger.gmane.org' \
    --to=grant.b.edwards@gmail.com \
    --cc=linux-serial@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).