Discrete custom design of RS485 driver

On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>Hi
>
>The standard RS485 drivers available has a minimum voltage of 3V and a rarther large drop voltage when loaded with the defined bus load for Modbus of 54ohms, and this causes problems for our design since we have limited power available for driving the bus
>
>So, we are thinking about designing our own driver in discrete components, so we can reduce the supply down to 2V and still comply with minimum 1.5V differential voltage into 54ohms.
>
>We only need 115k baud, so we could use a tiny logic level FET as the output stage. Shortcircuit protection would be done with a current limit circuit along with a low value supply capacitance (to reduce peak power in the FETs)
>
>Backfeed would need to be solved with a beefy diode to a defined clamp voltage.
>
>So, anyone been down this road, designing your own RS485 driver?
>
>Cheers
>
>Klaus

This should do what you want...

    http://www.vishay.com/docs/71168/si1016x.pdf
		
                                        ...Jim Thompson
-- 
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
I love to cook with wine.     Sometimes I even put it in the food.

On Friday, December 21, 2012 9:16:02 AM UTC-8, John Larkin wrote:
> Just use a cmos quad xor gate; two paralleled sections for one phase, two=
 for the other, with maybe 3.3 volt supply and 30 ohm source terminations. =
There's no need to use discrete fets.

I'm working on a project that's so far not found a viable stock RS-485 tran=
sceiver (max13451, sn65hvd24, and max3292 all fail in various ways), so thi=
nking about designing a discrete transmitter.

The quirk of my design is that (by requirement) the RS-485 rides capacitive=
ly coupled over the 0-36V DC lines, and the wire isn't twisted, it's just r=
egular "lamp cord".  The baud rate (dynamic 500Kbps-4Mbps in powers of 2, p=
reamble autobauds the receiver) is fast enough to avoid "sag", and the data=
 is manchester encoded anyway.  However, the more units on the bus, the fun=
kier the waveform.  My goal is to come up with something that actually work=
s.

The max13451 is a pretty straight xcvr, but the waveform would start to mas=
sively struggle to rise/fall, with it actually losing ground and causing sp=
urious transitions on the receiver.  The sn65hvd24 was not able to compensa=
te for that with its receive equalizer (that I could tell).

The max3292 has pre-emphasis, but once the pre-emph is done the base drive =
lets the bus sag into nothing of note, and the receivers tend to get badly =
confused.

> The downstream junk is selectable line driver equalization, to partially =
correct for CAT5 cable losses. This runs up to 125 MHz.

(fair warning: my analog skills are ... lacking)

My thought here would be to actually take each of the 3 inverter outputs an=
d rather than bussing them together, drive different parts of the EQ circui=
t directly from each and *then *bus* them together: (ignore the values)

https://www.circuitlab.com/circuit/jqmsj8/screenshot/540x405/

Even better, if those are tri-state gates, you can drive the OE's of each g=
ate independently in order to change which chains are active.  The RS-485 D=
E function consists of turning all the OE's off.

AFAICT the Line_Driver.PDF circuit drives directly at all times, then can s=
witch the 2 different EQ'd forms in on top of that.  If my idea above works=
, you'd have 8 options instead of just 3.

That make any sense or am I just smoking something?

On Sat, 17 Aug 2013 13:39:54 -0700 (PDT), omega@omegacs.net wrote:

>The quirk of my design is that (by requirement) the RS-485 rides 
>capacitively coupled over the 0-36V DC lines, and the wire isn't twisted, 
>it's just regular "lamp cord".  The baud rate (dynamic 500Kbps-4Mbps in 
>powers of 2, preamble autobauds the receiver) is fast enough to avoid "sag",
> and the data is manchester encoded anyway.  
>However, the more units on the bus, the funkier the waveform.  
>My goal is to come up with something that actually works.

If you are going to use lamp cord, _use_ a modulation method suitable
for lamp cords, i.e. PLC/PLT Power line communication. These are
usually DMT/COFDM style multitone modulation methods with a large
number (tens to hundreds) subcarrier in the MF or lower HF band. Each
subcarrier carry only a limited amount bits in order to keep the
symbol rate low. The total bit stream is divided and interleaved among
the subcarriers and a strong error correction coding is used.

In a multitone system with say 256 subcarriers, the 4 Mbit/s is
divided into the 16 kbit/s each, the 1/4 wave problems will start only
after a few kilometers.

In a single carrier system, e.g. the cabling to a light switch cause a
1/4 wave stub, distorting the waveform, but in multitone will only
take out individual subcarriers, with the redundancy, the ECC can
reconstruct the lost bits.

Trying to use some primitive Manchester/single carrier modulation
methods is not going to work if the network is large and there are a
lot of branches. The reflection will distort the waveform to useless
levels. At 4 Mbit/s with PVC insulation, the 1/4 wavelength is about
12 m.

omega@omegacs.net wrote:
> On Friday, December 21, 2012 9:16:02 AM UTC-8, John Larkin wrote:


Don't have the old thread anymore, they roll of after two months on my
PC. But let me try.


>> Just use a cmos quad xor gate; two paralleled sections for one
>> phase, two for the other, with maybe 3.3 volt supply and 30 ohm
>> source terminations. There's no need to use discrete fets.
> 
> I'm working on a project that's so far not found a viable stock
> RS-485 transceiver (max13451, sn65hvd24, and max3292 all fail in
> various ways), so thinking about designing a discrete transmitter.
> 
> The quirk of my design is that (by requirement) the RS-485 rides
> capacitively coupled over the 0-36V DC lines, and the wire isn't
> twisted, it's just regular "lamp cord".  The baud rate (dynamic
> 500Kbps-4Mbps in powers of 2, preamble autobauds the receiver) is
> fast enough to avoid "sag", and the data is manchester encoded
> anyway.  However, the more units on the bus, the funkier the
> waveform.  My goal is to come up with something that actually works.
> 
> The max13451 is a pretty straight xcvr, but the waveform would start
> to massively struggle to rise/fall, with it actually losing ground
> and causing spurious transitions on the receiver.  The sn65hvd24 was
> not able to compensate for that with its receive equalizer (that I
> could tell).
> 
> The max3292 has pre-emphasis, but once the pre-emph is done the base
> drive lets the bus sag into nothing of note, and the receivers tend
> to get badly confused.
> 

Careful with the stock situations at distributors if this is for
production. Doesn't look too great IMHO. The SN65HVD24 looks ok though.


>> The downstream junk is selectable line driver equalization, to
>> partially correct for CAT5 cable losses. This runs up to 125 MHz.
> 
> (fair warning: my analog skills are ... lacking)
> 

If it's any comfoert, my programming skills are ... lacking :-)


> My thought here would be to actually take each of the 3 inverter
> outputs and rather than bussing them together, drive different parts
> of the EQ circuit directly from each and *then *bus* them together:
> (ignore the values)
> 
> https://www.circuitlab.com/circuit/jqmsj8/screenshot/540x405/
> 
> Even better, if those are tri-state gates, you can drive the OE's of
> each gate independently in order to change which chains are active.
> The RS-485 DE function consists of turning all the OE's off.
> 
> AFAICT the Line_Driver.PDF circuit drives directly at all times, then
> can switch the 2 different EQ'd forms in on top of that.  If my idea
> above works, you'd have 8 options instead of just 3.
> 
> That make any sense or am I just smoking something?


I don't have the PDF link but the stuff in your link can work. I assume
they aren't tied together but driven from different EQ sections. It's
hard on the drivers though because they are seeing two other active
100ohm loads plus the cable. This is where discrete solutions can be
better if you need more amplitude than what chips can deliver. Or
parallel a few for each EQ section.

What I don't know is how you change the EQ settings when the
constellation of other nodes on the line changes. Something has to look
at the transitions and the ringing and change the EQ accordingly.

Also, mind potential *PHUT* situations. For example, what if there is
suddenly a dead short and the line voltage goes from 36V to zero in
nanoseconds? That puts a hard 36V across all device, with a long line
maybe even more. This is going to be a differential transition, not
common mode against many chips would be fairly robust.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Sunday, August 18, 2013 7:40:33 AM UTC-7, Joerg wrote:
> Don't have the old thread anymore, they roll of after two months on my PC=
.
> But let me try.

I'm going through the google groups page I initially found, which has the w=
hole history:

https://groups.google.com/forum/#!topic/sci.electronics.design/YZJz8Ys8KuU

> Careful with the stock situations at distributors if this is for producti=
on.
> Doesn't look too great IMHO. The SN65HVD24 looks ok though.

Yeah, I watch that when I select parts.  At least for now Maxim has been ab=
le to provide parts directly when needed.  But a) right now I'm just graspi=
ng at straws for anything that will work, and b) a discrete solution with m=
ulti-source parts (e.g. 74xx gates) fixes the problem ;-)

> If it's any comfoert, my programming skills are ... lacking :-)
;-)


> I don't have the PDF link but the stuff in your link can work. I assume
> they aren't tied together but driven from different EQ sections. It's
> hard on the drivers though because they are seeing two other active
> 100ohm loads plus the cable. This is where discrete solutions can be
> better if you need more amplitude than what chips can deliver. Or
> parallel a few for each EQ section.

One thing I haven't actually been able to figure out is how to compare disc=
rete gates to standard 485 transceivers as far as how "hard" they drive the=
 bus.  This is where my lack of analog foo really bites: I'm pretty sure th=
e info is there somewhere, but I don't know how to translate it.  Given tha=
t some of the chips (like the sn65hvd53 iirc) claim to be "high-drive", it'=
d be really nice to have some concept of how to compare against e.g. a trio=
 of 74Fxx gate outputs.


> What I don't know is how you change the EQ settings when the
> constellation of other nodes on the line changes. Something has to look
> at the transitions and the ringing and change the EQ accordingly.

In theory I have a backchannel: the main bus runs at 500kbps-4Mbps, but I a=
lso have a 'slow-mode' receiver, which is just an R/C on the receive line. =
 I'm going to be sandwiching the R/C in the middle of a pair of inverters i=
n future rev's to avoid having to re-tune the R/C to the drive of the trans=
ceiver-of-the-day, however.

Basically, as long as the transmitter and receiver can actually send some a=
pproximation of a waveform, thus I can get a reasonable "PWM" out of the re=
ceiver, I can send e.g. 10% duty and 90% duty by just spamming 0x00 and 0xf=
e out the transmit UART.  ~50-ish cycles(bytes) per bit, and the result at =
far end of the receiver's R/C circuit is a very slow serial sequence.  This=
 is the fallback mode I use to upload the stage-2 (fast-mode) bootloader to=
 the units over the bus.

As far as the iterative trial-and-error, my system can deal with a certain =
amount of packet loss, and I have packet counters that will be able to tell=
 me if something is missing (master knows how many packets sent, can ask th=
e units how many they received via slow-mode), and I can switch the EQ and =
see if it gets better or worse.

The main complication is that units will need to hear (and comprehend) not =
only the controller, but their neighbors - they "follow" in sequence to opt=
imize the bus.  That means I may end up having to tune each unit's *transmi=
t* to a dumb receiver in the neighboring unit (since units are space-constr=
ained), while also tuning the controller's receive on a continuous basis to=
 keep up with the units (since the controller is bigger).


> Also, mind potential *PHUT* situations. For example, what if there is
> suddenly a dead short and the line voltage goes from 36V to zero in
> nanoseconds? That puts a hard 36V across all device, with a long line
> maybe even more. This is going to be a differential transition, not
> common mode against many chips would be fairly robust.

Yeah, definitely something I've had to deal with.  The max13451 and sn65hvd=
24 have both been pretty robust with internal protections, but the max3292 =
not so much.  I have provisions on the current PCBs for a 10V TVS across th=
e coupled A and B lines, but that doesn't quite handle all the transients. =
 The soft switching I use on the 36V supply (a max5947 "breaker" with EN, t=
o not let the smoke out in a dead-short scenario) seems to be safe enough, =
but my unit test rig has a relay, and switching the relay while power is ap=
plied has resulted in some fried chips (and fried finger...).

Worse, the system will be upgraded at some point to include a TDR at the co=
ntroller, which will rely on a dead-short relay in each unit to determine r=
elative distances, so the bus will indeed be riddled with some "interesting=
" surge scenarios.  The controller can switch off the 36VDC and engage a "d=
ump" relay to clear the bus of potential before engaging the TDR, while all=
 the units have enough onboard capacitance to ride out the ~10ms measuremen=
t window.

I'll be adding a USB-style transient-protection chip to the input side (in =
addition to the TVS) in order to clamp the coupled A/B to the rails.

On Sun, 18 Aug 2013 07:40:33 -0700, Joerg <invalid@invalid.invalid>
wrote:

>omega@omegacs.net wrote:
>> On Friday, December 21, 2012 9:16:02 AM UTC-8, John Larkin wrote:
>
>

>> The max3292 has pre-emphasis, but once the pre-emph is done the base
>> drive lets the bus sag into nothing of note, and the receivers tend
>> to get badly confused.
>> 
>
>Careful with the stock situations at distributors if this is for
>production. Doesn't look too great IMHO. The SN65HVD24 looks ok though.
>
>
>>> The downstream junk is selectable line driver equalization, to
>>> partially correct for CAT5 cable losses. This runs up to 125 MHz.

CAT5 is usually used in a terminated point to point configuration with
attenuation (expressed in dB) is proportional to the square root of
frequency. This frequency dependent loss is easy to compensate with a
simple equalization, known in the cable-TV systems as "tilt".

Now we are talking about a multidrop/multiple branch system made of
"lamp cords", that simple frequency compensation is little use.

>> (fair warning: my analog skills are ... lacking)

If you are using mismatched lines that are longer about 1/10
wavelength, you really should understand transmission line issues. At
4 Mbit/s the free space wavelength is 75 m and 1/10 in a common cable
is about 5 m, thus a cable network with a total length longer than
that and you really have to understand transmission line issues.
>> 
>
>If it's any comfoert, my programming skills are ... lacking :-)
>
>
>> My thought here would be to actually take each of the 3 inverter
>> outputs and rather than bussing them together, drive different parts
>> of the EQ circuit directly from each and *then *bus* them together:
>> (ignore the values)
>> 
>> https://www.circuitlab.com/circuit/jqmsj8/screenshot/540x405/
>> 
>> Even better, if those are tri-state gates, you can drive the OE's of
>> each gate independently in order to change which chains are active.
>> The RS-485 DE function consists of turning all the OE's off.
>> 
>> AFAICT the Line_Driver.PDF circuit drives directly at all times, then
>> can switch the 2 different EQ'd forms in on top of that.  If my idea
>> above works, you'd have 8 options instead of just 3.
>> 
>> That make any sense or am I just smoking something?
>
>
>I don't have the PDF link but the stuff in your link can work. I assume
>they aren't tied together but driven from different EQ sections. It's
>hard on the drivers though because they are seeing two other active
>100ohm loads plus the cable. This is where discrete solutions can be
>better if you need more amplitude than what chips can deliver. Or
>parallel a few for each EQ section.
>
>What I don't know is how you change the EQ settings when the
>constellation of other nodes on the line changes. Something has to look
>at the transitions and the ringing and change the EQ accordingly.

While it may be possible to "train" complex equalizers between two
nodes in a multidrop network during a long preamble, but if there are
multiple Modbus style slaves all along a complex network, how do you
train _all_ equalizers so that each slave is going to be able to
extract the slave address. Apparently you would have to send the slave
address at a very slow rate, then train the equalizer on the receiver
end and then send the actual data.

Alternatively, at system startup, make a training session between the
master and each slave and memorize the master and slave equalizer
settings for each slave. Even in this case, how do you handle
broadcast messages and what about the master addressing a specific
slave, but the other hear some garbled messages and know when the
previous message is over. A slave on the RS-485 will hear the
responses from other slaves distorted by the sending slave equalizer
as well as the monitoring slave equalizer, again, how do you detect
the end of previous transmissions in order to be ready to listen for
the next message that might be addressed to your slave.

IMHO a large lamp cord multidrop network and data rates of several
megabits/second is not going to survive, if the cables are longer than
a few meters using single carrier and amplitude critical modulation.
Use some multitone modulation.

On Sun, 18 Aug 2013 07:40:33 -0700, Joerg <invalid@invalid.invalid> wrote:

>omega@omegacs.net wrote:
>> On Friday, December 21, 2012 9:16:02 AM UTC-8, John Larkin wrote:
>
>
>Don't have the old thread anymore, they roll of after two months on my
>PC. But let me try.
>
>
>>> Just use a cmos quad xor gate; two paralleled sections for one
>>> phase, two for the other, with maybe 3.3 volt supply and 30 ohm
>>> source terminations. There's no need to use discrete fets.
>> 
>> I'm working on a project that's so far not found a viable stock
>> RS-485 transceiver (max13451, sn65hvd24, and max3292 all fail in
>> various ways), so thinking about designing a discrete transmitter.
>> 
>> The quirk of my design is that (by requirement) the RS-485 rides
>> capacitively coupled over the 0-36V DC lines, and the wire isn't
>> twisted, it's just regular "lamp cord".  The baud rate (dynamic
>> 500Kbps-4Mbps in powers of 2, preamble autobauds the receiver) is
>> fast enough to avoid "sag", and the data is manchester encoded
>> anyway.  However, the more units on the bus, the funkier the
>> waveform.  My goal is to come up with something that actually works.
>> 
>> The max13451 is a pretty straight xcvr, but the waveform would start
>> to massively struggle to rise/fall, with it actually losing ground
>> and causing spurious transitions on the receiver.  The sn65hvd24 was
>> not able to compensate for that with its receive equalizer (that I
>> could tell).
>> 
>> The max3292 has pre-emphasis, but once the pre-emph is done the base
>> drive lets the bus sag into nothing of note, and the receivers tend
>> to get badly confused.
>> 
>
>Careful with the stock situations at distributors if this is for
>production. Doesn't look too great IMHO. The SN65HVD24 looks ok though.
>
>
>>> The downstream junk is selectable line driver equalization, to
>>> partially correct for CAT5 cable losses. This runs up to 125 MHz.
>> 
>> (fair warning: my analog skills are ... lacking)
>> 
>
>If it's any comfoert, my programming skills are ... lacking :-)
>
>
>> My thought here would be to actually take each of the 3 inverter
>> outputs and rather than bussing them together, drive different parts
>> of the EQ circuit directly from each and *then *bus* them together:
>> (ignore the values)
>> 
>> https://www.circuitlab.com/circuit/jqmsj8/screenshot/540x405/
>> 
>> Even better, if those are tri-state gates, you can drive the OE's of
>> each gate independently in order to change which chains are active.
>> The RS-485 DE function consists of turning all the OE's off.
>> 
>> AFAICT the Line_Driver.PDF circuit drives directly at all times, then
>> can switch the 2 different EQ'd forms in on top of that.  If my idea
>> above works, you'd have 8 options instead of just 3.
>> 
>> That make any sense or am I just smoking something?
>
>
>I don't have the PDF link but the stuff in your link can work. I assume
>they aren't tied together but driven from different EQ sections. It's
>hard on the drivers though because they are seeing two other active
>100ohm loads plus the cable. This is where discrete solutions can be
>better if you need more amplitude than what chips can deliver. Or
>parallel a few for each EQ section.
>
>What I don't know is how you change the EQ settings when the
>constellation of other nodes on the line changes. Something has to look
>at the transitions and the ringing and change the EQ accordingly.
>
>Also, mind potential *PHUT* situations. For example, what if there is
>suddenly a dead short and the line voltage goes from 36V to zero in
>nanoseconds? That puts a hard 36V across all device, with a long line
>maybe even more. This is going to be a differential transition, not
>common mode against many chips would be fairly robust.

This may be the circuit that the OP refers to:

https://dl.dropboxusercontent.com/u/53724080/Circuits/ESM/Line_Drivers.pdf

The A/B signal pairs come directly out of an FPGA as low-skew complements. The
receive end, up to 80 meters away, is a home-made receiver, fast with lots of
common-mode range. We did a *lot* of CAT5/CAT6 cable testing. I had a minor
battle with the customer over grounding; I wanted to hard-ground every board and
box locally, and his requirement document required everything to be floated,
with an R-R-C network from every board ground to case. I did it my way. We
usually take requirement documents as general suggestions.

We've shipped around 600 of these, for use in physically big systems. Seems to
work. 


-- 

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

In article <iou119h31ldueksiqec5c75h857ig8i75t@4ax.com>, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

> On Sun, 18 Aug 2013 07:40:33 -0700, Joerg <invalid@invalid.invalid> wrote:
> 
> >omega@omegacs.net wrote:
> >> On Friday, December 21, 2012 9:16:02 AM UTC-8, John Larkin wrote:
> >
> >
> >Don't have the old thread anymore, they roll of after two months on my
> >PC. But let me try.
> >
> >
> >>> Just use a cmos quad xor gate; two paralleled sections for one
> >>> phase, two for the other, with maybe 3.3 volt supply and 30 ohm
> >>> source terminations. There's no need to use discrete fets.
> >> 
> >> I'm working on a project that's so far not found a viable stock
> >> RS-485 transceiver (max13451, sn65hvd24, and max3292 all fail in
> >> various ways), so thinking about designing a discrete transmitter.
> >> 
> >> The quirk of my design is that (by requirement) the RS-485 rides
> >> capacitively coupled over the 0-36V DC lines, and the wire isn't
> >> twisted, it's just regular "lamp cord".  The baud rate (dynamic
> >> 500Kbps-4Mbps in powers of 2, preamble autobauds the receiver) is
> >> fast enough to avoid "sag", and the data is manchester encoded
> >> anyway.  However, the more units on the bus, the funkier the
> >> waveform.  My goal is to come up with something that actually works.
> >> 
> >> The max13451 is a pretty straight xcvr, but the waveform would start
> >> to massively struggle to rise/fall, with it actually losing ground
> >> and causing spurious transitions on the receiver.  The sn65hvd24 was
> >> not able to compensate for that with its receive equalizer (that I
> >> could tell).
> >> 
> >> The max3292 has pre-emphasis, but once the pre-emph is done the base
> >> drive lets the bus sag into nothing of note, and the receivers tend
> >> to get badly confused.
> >> 
> >
> >Careful with the stock situations at distributors if this is for
> >production. Doesn't look too great IMHO. The SN65HVD24 looks ok though.
> >
> >
> >>> The downstream junk is selectable line driver equalization, to
> >>> partially correct for CAT5 cable losses. This runs up to 125 MHz.
> >> 
> >> (fair warning: my analog skills are ... lacking)
> >> 
> >
> >If it's any comfoert, my programming skills are ... lacking :-)
> >
> >
> >> My thought here would be to actually take each of the 3 inverter
> >> outputs and rather than bussing them together, drive different parts
> >> of the EQ circuit directly from each and *then *bus* them together:
> >> (ignore the values)
> >> 
> >> https://www.circuitlab.com/circuit/jqmsj8/screenshot/540x405/
> >> 
> >> Even better, if those are tri-state gates, you can drive the OE's of
> >> each gate independently in order to change which chains are active.
> >> The RS-485 DE function consists of turning all the OE's off.
> >> 
> >> AFAICT the Line_Driver.PDF circuit drives directly at all times, then
> >> can switch the 2 different EQ'd forms in on top of that.  If my idea
> >> above works, you'd have 8 options instead of just 3.
> >> 
> >> That make any sense or am I just smoking something?
> >
> >
> >I don't have the PDF link but the stuff in your link can work. I assume
> >they aren't tied together but driven from different EQ sections. It's
> >hard on the drivers though because they are seeing two other active
> >100ohm loads plus the cable. This is where discrete solutions can be
> >better if you need more amplitude than what chips can deliver. Or
> >parallel a few for each EQ section.
> >
> >What I don't know is how you change the EQ settings when the
> >constellation of other nodes on the line changes. Something has to look
> >at the transitions and the ringing and change the EQ accordingly.
> >
> >Also, mind potential *PHUT* situations. For example, what if there is
> >suddenly a dead short and the line voltage goes from 36V to zero in
> >nanoseconds? That puts a hard 36V across all device, with a long line
> >maybe even more. This is going to be a differential transition, not
> >common mode against many chips would be fairly robust.
> 
> This may be the circuit that the OP refers to:
> 
> https://dl.dropboxusercontent.com/u/53724080/Circuits/ESM/Line_Drivers.pdf
> 
> The A/B signal pairs come directly out of an FPGA as low-skew complements. The
> receive end, up to 80 meters away, is a home-made receiver, fast with lots of
> common-mode range. We did a *lot* of CAT5/CAT6 cable testing. I had a minor
> battle with the customer over grounding; I wanted to hard-ground every board
> and box locally, and his requirement document required everything to be floated,
> with an R-R-C network from every board ground to case. I did it my way. We
> usually take requirement documents as general suggestions.
> 
> We've shipped around 600 of these, for use in physically big systems. Seems to
> work.

The rationale for not hard grounding everywhere is ground loops, which
can bypass even the best of shields.  What is supposed to happen is
that there is exactly one hard ground, and the receiver is
differential.

However, RF systems often require hard grounds everywhere.  In such
cases, the RF line receivers must be immune to power-frequency
ground-loop currents in the shields.  In a ship, there can be something
like seven volts of difference between bow and stern while the ship is
underway, due to various kinds of leakage from propulsion system to the
hull.

Ott goes deep into the issue of grounding and ground loops.

Joe Gwinn

omega@omegacs.net wrote:
> On Sunday, August 18, 2013 7:40:33 AM UTC-7, Joerg wrote:

[...]


>> I don't have the PDF link but the stuff in your link can work. I
>> assume they aren't tied together but driven from different EQ
>> sections. It's hard on the drivers though because they are seeing
>> two other active 100ohm loads plus the cable. This is where
>> discrete solutions can be better if you need more amplitude than
>> what chips can deliver. Or parallel a few for each EQ section.
> 
> One thing I haven't actually been able to figure out is how to
> compare discrete gates to standard 485 transceivers as far as how
> "hard" they drive the bus.  This is where my lack of analog foo
> really bites: I'm pretty sure the info is there somewhere, but I
> don't know how to translate it.  Given that some of the chips (like
> the sn65hvd53 iirc) claim to be "high-drive", it'd be really nice to
> have some concept of how to compare against e.g. a trio of 74Fxx gate
> outputs.
> 

This information would be on pages 16, figures 19 and 20:

http://www.ti.com/lit/ds/symlink/sn65hvd50.pdf

Take figure 19, for example. That's the low level side in there. If the
current goes from 25mA to 70mA the device sags off by 1V. That indicates
a source resistance of about 25ohms when pulling low.

The top of page 4 has minimum values for the differential drive
capability for 54ohms and 100ohms.


> 
>> What I don't know is how you change the EQ settings when the 
>> constellation of other nodes on the line changes. Something has to
>> look at the transitions and the ringing and change the EQ
>> accordingly.
> 
> In theory I have a backchannel: the main bus runs at 500kbps-4Mbps,
> but I also have a 'slow-mode' receiver, which is just an R/C on the
> receive line.  I'm going to be sandwiching the R/C in the middle of a
> pair of inverters in future rev's to avoid having to re-tune the R/C
> to the drive of the transceiver-of-the-day, however.
> 
> Basically, as long as the transmitter and receiver can actually send
> some approximation of a waveform, thus I can get a reasonable "PWM"
> out of the receiver, I can send e.g. 10% duty and 90% duty by just
> spamming 0x00 and 0xfe out the transmit UART.  ~50-ish cycles(bytes)
> per bit, and the result at far end of the receiver's R/C circuit is a
> very slow serial sequence.  This is the fallback mode I use to upload
> the stage-2 (fast-mode) bootloader to the units over the bus.
> 

Maybe I misunderstand this but the best is usually to remain at 50% duty
cycle and NRZ-code.


> As far as the iterative trial-and-error, my system can deal with a
> certain amount of packet loss, and I have packet counters that will
> be able to tell me if something is missing (master knows how many
> packets sent, can ask the units how many they received via
> slow-mode), and I can switch the EQ and see if it gets better or
> worse.
> 

Slow-mode can be a problem with such piggy-back schemes.


> The main complication is that units will need to hear (and
> comprehend) not only the controller, but their neighbors - they
> "follow" in sequence to optimize the bus.  That means I may end up
> having to tune each unit's *transmit* to a dumb receiver in the
> neighboring unit (since units are space-constrained), while also
> tuning the controller's receive on a continuous basis to keep up with
> the units (since the controller is bigger).
> 

If the scheme requires this much tuning I think it should either be
auto-tune or force a repeater structure where the nearest device must
re-transmit messages meant for another device down the line in that
direction.


> 
>> Also, mind potential *PHUT* situations. For example, what if there
>> is suddenly a dead short and the line voltage goes from 36V to zero
>> in nanoseconds? That puts a hard 36V across all device, with a long
>> line maybe even more. This is going to be a differential
>> transition, not common mode against many chips would be fairly
>> robust.
> 
> Yeah, definitely something I've had to deal with.  The max13451 and
> sn65hvd24 have both been pretty robust with internal protections, but
> the max3292 not so much.  I have provisions on the current PCBs for a
> 10V TVS across the coupled A and B lines, but that doesn't quite
> handle all the transients.  The soft switching I use on the 36V
> supply (a max5947 "breaker" with EN, to not let the smoke out in a
> dead-short scenario) seems to be safe enough, but my unit test rig
> has a relay, and switching the relay while power is applied has
> resulted in some fried chips (and fried finger...).
> 

TVS would require a diode in series because they have tons of
capacitance and this messes up you signals (muffles them). But better
would be some sort of temporary disconnect or series resistance
increase. Something that only reacts to changes in bus DC voltage if
they are fast and large (in either direction). Gets involved in terms of
parts count though.


> Worse, the system will be upgraded at some point to include a TDR at
> the controller, which will rely on a dead-short relay in each unit to
> determine relative distances, so the bus will indeed be riddled with
> some "interesting" surge scenarios.  The controller can switch off
> the 36VDC and engage a "dump" relay to clear the bus of potential
> before engaging the TDR, while all the units have enough onboard
> capacitance to ride out the ~10ms measurement window.
> 

That sounds like the "bus from hell" :-)


> I'll be adding a USB-style transient-protection chip to the input
> side (in addition to the TVS) in order to clamp the coupled A/B to
> the rails.


I am not sure that USB clamping will be strong enough.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Sat, 17 Aug 2013 13:39:54 -0700, omega wrote:


> https://www.circuitlab.com/circuit/jqmsj8/screenshot/540x405/
> 
> Even better, if those are tri-state gates, you can drive the OE's of
> each gate independently in order to change which chains are active.  The
> RS-485 DE function consists of turning all the OE's off.
> 
> AFAICT the Line_Driver.PDF circuit drives directly at all times, then
> can switch the 2 different EQ'd forms in on top of that.  If my idea
> above works, you'd have 8 options instead of just 3.
> 
> That make any sense or am I just smoking something?

I suspect what you have is ordinary ignorance.

Get a copy of TIA-485, it is reasonably priced at TechStreet.

There are some basic ideas to learn: differential signaling,
bit serial protocol, tri-state trnsmitters.  It is not Manchester encoded.

Give the TIA-485 lines their own twisted pair. It will save you a lot of 
trouble,

Maintain a total of about 2 to 6 standard loads.

HTH

?-)