Discrete custom design of RS485 driver

upsidedown@downunder.com wrote:
> On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), omega@omegacs.net wrote:
> 
>>> 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.
>> Auto-tune is what I propose above, using failure counters to find the best option.  A repeater is another method I'm thinking of, but in two different possible forms:
> 
> Auto-tune is typically implemented either by special known "training"
> messages or having a long preamble in front of each message. Relying
> on just message CRC checks will take a _very_ long time to auto-tune.
> 

You can do it by looking at transitions and reflection spikes on the
data. Mainly because the OP is using an NRZ scheme where you have a
transition in each data bit.


> On a shared (Modbus style) half duplex network in a master to
> multidrop slave configuration, you have to be very careful that each
> slave knows, when the master speaks or when some slave responds. You
> really have to use heavy protected data direction and slave addresses,
> so that the wrong slave does not respond (garbling all traffic).
> 
> How many retries are you going to do, in order to get the message
> through ?
> 
> Anyway, auto-tune is usually implemented at each receiver and require
> an ADC and some DSP processing (e.g. "56k" phone modems, 8VSB US
> digital-TV).
> 

Yup. There is almost no way around that, except maybe analog circuitry
with RF parts in there. I've done one with a uC and analog but it was
highly unorthodox.


> Trying to use master transmit side auto-tune with some slow speed
> feedback would require a large number of "training" packets in the
> beginning and the slave would have to respond, how many of the bits
> get through OK, not just go/no go.
>  
>> - uncut bus: if a packet from the master is received properly by the first N units on the bus, but not after that, the theory would be that unit N would be able to retransmit, and that would provide something the rest of the bus can hear, then repeat the answers back.  However, while that makes perfect sense in a "wireless" scenario where N+1 can't hear the master because of low signal, I'm not sure the coupled 485 bus will behave similarly.  I would expect there to either be relatively little difference between the received signal at each point on the bus, *or* there to be various standing waves and all kinds of ACK/NAK patterns along the length.
> 
> At a constant bit rate in a not properly matched network, the
> reflection could quite well kill the reception at the first slave for
> certain bit patterns.
> 

That could be handled by a versatile auto-controlled matching network.
But there are limits, like when there is an almost total signal-cancel
because the line length happens to create an exact notch filter. Then
one needs to have at least one other data rate available which is not an
exact multiple of the original rate.


> As I said previously, you are banging your head against the wall, when
> trying to use some base band or single carrier system in an unknown
> network, in which the branches are longer than 1/10 of the wavelength.
> Instead of looking at individual "RS-485" like chip characteristics,
> you really should consider some multitone method to transfer the data
> in that hostile environment.
>  

I'll second that, multi-tone really wins in such situations.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Sat, 31 Aug 2013 09:41:48 -0700, Joerg <invalid@invalid.invalid>
wrote:

>upsidedown@downunder.com wrote:
>> On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), omega@omegacs.net wrote:
>> 
>>>> 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.
>>> Auto-tune is what I propose above, using failure counters to find the best option.  A repeater is another method I'm thinking of, but in two different possible forms:
>> 
>> Auto-tune is typically implemented either by special known "training"
>> messages or having a long preamble in front of each message. Relying
>> on just message CRC checks will take a _very_ long time to auto-tune.
>> 
>
>You can do it by looking at transitions and reflection spikes on the
>data. Mainly because the OP is using an NRZ scheme where you have a
>transition in each data bit.

NRZ = Non-Return to Zero

This does not have a guarantied transition at each bit.

With asynchronous communication with 8 data bits, one stop bit, no
parity bit, you have only one known transition at the beginning of the
start bit. Look what happens when you send 00 and FFh

00: idle(1), start(0), 8 x data(0), stop(1), idle(1)..., next start(0)
FF: idle(1), start(0), 8 x data(1), stop(1), idle(1)..., next start(0)

The length of the idle period can be anything from zero (back to back
characters) to infinity and the time is not a multiple of the bit
clock. Thus only one known transition in 10 bits.

Other methods, such as biphase (e,g, Manchester) will have more
frequent transitions. Bit stuffing (e.g. SDLC/HDLC, CANbus) will
automatically insert one extra opposite polarity after five
consecutive 1's or 0's  thus having at least some edges to
resynchronize.

On Friday, August 30, 2013 9:15:29 AM UTC-7, om...@omegacs.net wrote:

[about differential RS-485 signaling)

> I was also thinking about higher-voltage protection, either from lightnin=
g or significant ground potentials (this bus will be strung out over 100's =
or maybe 1000's [if it works] of feet in outdoor environs), and ran across =
an email showing some very tiny gas-discharge tubes that might do the trick=
 there.

There's the possibility, if you use a self-clocked serial scheme (MFM, Manc=
hester,
FM1, FM2, NRZ... there's lots of 'em) of transformer-coupling.  The old App=
leTalk
scheme used RS-485-like  drivers and worked that way, on cheap telephone wi=
ring.
With proper attention to termination, it was good for about a kilometer.

upsidedown@downunder.com wrote:
> On Sat, 31 Aug 2013 09:41:48 -0700, Joerg <invalid@invalid.invalid>
> wrote:
> 
>> upsidedown@downunder.com wrote:
>>> On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), omega@omegacs.net wrote:
>>>
>>>>> 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.
>>>> Auto-tune is what I propose above, using failure counters to find the best option.  A repeater is another method I'm thinking of, but in two different possible forms:
>>> Auto-tune is typically implemented either by special known "training"
>>> messages or having a long preamble in front of each message. Relying
>>> on just message CRC checks will take a _very_ long time to auto-tune.
>>>
>> You can do it by looking at transitions and reflection spikes on the
>> data. Mainly because the OP is using an NRZ scheme where you have a
>> transition in each data bit.
> 
> NRZ = Non-Return to Zero
> 
> This does not have a guarantied transition at each bit.
> 

True. Sorry, I was still in the med tech corner of my world because I
just did an interface. There we use NRZ a lot. In the OP's case it has
to be Manchester code.


> With asynchronous communication with 8 data bits, one stop bit, no
> parity bit, you have only one known transition at the beginning of the
> start bit. Look what happens when you send 00 and FFh
> 
> 00: idle(1), start(0), 8 x data(0), stop(1), idle(1)..., next start(0)
> FF: idle(1), start(0), 8 x data(1), stop(1), idle(1)..., next start(0)
> 
> The length of the idle period can be anything from zero (back to back
> characters) to infinity and the time is not a multiple of the bit
> clock. Thus only one known transition in 10 bits.
> 
> Other methods, such as biphase (e,g, Manchester) will have more
> frequent transitions. Bit stuffing (e.g. SDLC/HDLC, CANbus) will
> automatically insert one extra opposite polarity after five
> consecutive 1's or 0's  thus having at least some edges to
> resynchronize.
> 

Yes, got to do Manchester here. Otherwise the auto-tune could take too long.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Friday, August 30, 2013 1:12:22 PM UTC-7, Joerg wrote:
> If you need the ultimate in drive power I suggest to look at FET gate
> drivers. Those are in the single digit ohms.

Yeah, that seems like the best bet, although I'd potentially lose the multi=
-bit tunability based on increased footprint (I've got a fixed, very small =
space to work in)


> The driver could be made almost as low in impedance as you want to. But
> it will be "home-brew", in other works not all in one chip.

At this point I'll look into anything that might possibly work.  I'm pushin=
g to build a testbed where I can back up and do some experiments without th=
e constraints I'm currently working under, so a home-brew transmitter would=
 be possible to play with.


> Sorry, what I meant was when you can have a plethora of transceivers in
> a fairly random order, in other words where your system must be tolerant
> to ghastly and a priori unknown reflections on the line.

I was under the impression that for the most part reflections were caused b=
y branches, which my system doesn't really have in the sense that I've seen=
 them defined.  The units on the bus have maybe 3/4" or less between the va=
mpire tap point and the transceiver.

> Can work but I have sometimes replaced such digital methods with analog
> ones. Where the circuit really looks at some waveform patterns and
> adjusts those.

Not really sure how I'd do that in any kind of automated way with the syste=
m I've got.  It's all driven by AVR Xmega parts at 32MHz, there's really no=
 way to get enough oomph to analyze the signal in any meaningful way at run=
time.

> Then you'd have to cook up your own "more-tolerant" protocol. That might
> make this solution unpalatable.

Yeah, that's really not my idea of a fun project.  I'd much rather go with =
the cut-wire repeater arrangement, especially given the massive bandwidth h=
it I'd take.


> > Yeah, that's why work on the TDR subsystem has been put off for now.
> But it's fun :-)

I spent a few months on that project, and pretty much spun my wheels.  When=
 the time comes I really want to find somebody else to do it...

> Gas-discharge is good but the voltage at which they come on is too high
> for semiconductors.

Yeah, it would be in addition to lower-voltage protection.
=20
> With a clean NRZ method there is also another option, signal
> transformers. They won't let any DC bother you. This is what I do for
> defibrillator-proof medical gear which is tested with a slow and very
> powerful (as in many amps) 5kV surge. Those are real whoppers and it has
> heppened that a server of PBX system at clients had to be reset after
> the test.

So I thought about that, but wouldn't the coil resistance of dozens of tran=
sformers on the line blow things out of the water?  Or would the transforme=
rs be capacitively coupled to the line themselves?  I've seen that arrangem=
ent in the very few schematics I've seen of power-line systems.

The biggest problem there (so to speak) is the size of such transformers.  =
They're getting crazy-small, but I've got a *tiny* space to work in.  I've =
got a 3mm max height limit, and the biggest open space I've got is *maybe* =
a centimeter square.

On Saturday, August 31, 2013 12:10:54 AM UTC-7, upsid...@downunder.com wrot=
e:
> Auto-tune is typically implemented either by special known "training"
> messages or having a long preamble in front of each message. Relying
> on just message CRC checks will take a _very_ long time to auto-tune.

In my case I think I can keep it mostly constrained, because there are only=
 a few combinations of transmitter/receiver that I care about.  The control=
ler can broadcast a pseudorandom set of all the various possibilities with =
their parameters built into the packets, then slow-query all the units on t=
he bus for their received packet counts, split into each transmit arrangeme=
nt.  Find the "best" bin for each unit that has a 99+% receive rate for tha=
t batch, go with that.  Rinse/repeat for each unit on the bus transmitting =
back to the master.  In theory I can take several minutes to do this.

> On a shared (Modbus style) half duplex network in a master to
> multidrop slave configuration, you have to be very careful that each
> slave knows, when the master speaks or when some slave responds. You
> really have to use heavy protected data direction and slave addresses,
> so that the wrong slave does not respond (garbling all traffic).

The protocol very clearly dictates who speaks when so there are no issues t=
here except in dealing with timeouts for situations when e.g. one unit spea=
ks and the next one hears it but the controller doesn't, etc.

> How many retries are you going to do, in order to get the message
> through ?

Depends on how far I can get the hardware in terms of low PHY error rates.

> Anyway, auto-tune is usually implemented at each receiver and require
> an ADC and some DSP processing (e.g. "56k" phone modems, 8VSB US
> digital-TV).

Yeah, would love to have that but don't have that option at this point.

> At a constant bit rate in a not properly matched network, the
> reflection could quite well kill the reception at the first slave for
> certain bit patterns.

By "not properly matched" do you mean improper termination (I'll be shippin=
g a terminator "unit"), invalid branches (mine are maybe 3/4" *max* from th=
e wire to the chip), or something more involved?

> As I said previously, you are banging your head against the wall,

Oh you have no idea ;-(

> when
> trying to use some base band or single carrier system in an unknown
> network, in which the branches are longer than 1/10 of the wavelength.
> Instead of looking at individual "RS-485" like chip characteristics,
> you really should consider some multitone method to transfer the data
> in that hostile environment.

I'd love to, but I haven't found any solutions that fit my power, space, an=
d datarate budgets.  If there's a reasonable way to implement OOK or FSK at=
 1Mbps or better using the existing UART pins and packet protocols I've got=
, I'd be all over that.

On Saturday, August 31, 2013 12:59:28 PM UTC-7, upsid...@downunder.com wrot=
e:
> Other methods, such as biphase (e,g, Manchester) will have more
> frequent transitions. Bit stuffing (e.g. SDLC/HDLC, CANbus) will
> automatically insert one extra opposite polarity after five
> consecutive 1's or 0's  thus having at least some edges to
> resynchronize.

I'm using Manchester throughout, so when the bus is active there are either=
 250ns or 500ns highs and lows, nothing more.  The start/stop bits aid in t=
hat of course.

I have hand-written transmit and receive ISRs that take the raw packets and=
 handle preamble, header, data, and CRC with ISR-time lookups from a Manche=
ster table, etc.  Takes 50-60 cycles out of the 80 cycles I have per UART b=
yte (4Mbps vs. 32MHz), but the Xmega has 3 priority levels so I can do othe=
r stuff in lower priority interrupts and at this point I never lose an inte=
rrupt (afaict).

I have encoding options built in, so that *if* the bus is happy with just t=
he start/stop transitions (e.g. it doesn't sag too fast between edges) I ca=
n also transmit un-encoded data, although the preamble and header is *alway=
s* Manchester.  The control bits for the modes are in the Manchester-encode=
d packet header, so it switches on a per-packet basis as received.

On Tue, 3 Sep 2013 20:57:17 -0700 (PDT), omega@omegacs.net wrote:

>> At a constant bit rate in a not properly matched network, the
>> reflection could quite well kill the reception at the first slave for
>> certain bit patterns.
>
>By "not properly matched" do you mean improper termination (I'll be shipping a terminator "unit"), invalid branches (mine are maybe 3/4" *max* from the wire to the chip), or something more involved?

So you have a T-connector, with the branch less than 20 mm long, but
the real question is how the main wire is routed.

If it is a single bus structure with

terminator - Station_A  - B  - C - ..... - Station_Z - terminator

Things are OK. 

The 20 mm branch length from main bus at 4 Mbit/s compares well with
other cabling system. At 10 Mbit/s, the Vampire tap in 10Base5 Thick
Ethernet and the BNC T-connector 10Base2 coaxial bus has similar
branch length. In Profibus DP (RS-485 on well specified twisted pair
cable) at 12 Mbit/s and up to 100 m that 20 mm is too much, at 1.5
Mbit/s short wire branches (well below a meter) from the main bus may
be used.  




However, if you have a random cable segment mess (fixed pitch font)

terminator -- A -- B --+-- C -- D -- E -- terminator
                       !
                       +-- F -- G --+-- H -- terminator
                                    !
             terminator -- J -- I --+--- K -- L -- terminator

you are going to have problems, if the segment lengths are more than 5
m at 4 Mbit/s.

Some passive star coupled topology with ferrites placed at strategic
places might work, as used in some CANbus installations (essentially
RS-485 up to 1 Mbit/s).

omega@omegacs.net wrote:
> On Friday, August 30, 2013 1:12:22 PM UTC-7, Joerg wrote:
>> If you need the ultimate in drive power I suggest to look at FET
>> gate drivers. Those are in the single digit ohms.
> 
> Yeah, that seems like the best bet, although I'd potentially lose the
> multi-bit tunability based on increased footprint (I've got a fixed,
> very small space to work in)
> 

You don't have to lose that because many drivers come in quads and
amazingly small packages, such as this one:

http://www.irf.com/product-info/datasheets/data/pb-ir3598.pdf.

> 
>> The driver could be made almost as low in impedance as you want to.
>> But it will be "home-brew", in other works not all in one chip.
> 
> At this point I'll look into anything that might possibly work.  I'm
> pushing to build a testbed where I can back up and do some
> experiments without the constraints I'm currently working under, so a
> home-brew transmitter would be possible to play with.
> 

Best way to go on a project like this.

> 
>> Sorry, what I meant was when you can have a plethora of
>> transceivers in a fairly random order, in other words where your
>> system must be tolerant to ghastly and a priori unknown reflections
>> on the line.
> 
> I was under the impression that for the most part reflections were
> caused by branches, which my system doesn't really have in the sense
> that I've seen them defined.  The units on the bus have maybe 3/4" or
> less between the vampire tap point and the transceiver.
> 

Understood, but it's not just branches that reflect RF on a line. Any
time you hang a capacitance to a transmission line you have created a
reflection point. The impedance is no longer a clean 100ohms or whatever
at that point.

One of the tasks at hand is to minimize this added capacitance. What I
did on clock lines was to tap in via a hotrod RF transistor instead of
directly with a logic input. That dropped it down from 5pF a pop to
under 1pF. With the driver part that gets to be more difficult. The
output devices will inevitably have more capacitance even when off. Same
for a series mux if you go that route.

Neutralizing that capacitance by a regenerative trick might work. If
you do that and it works hand out barf bags before you start the design
review :-)


>> Can work but I have sometimes replaced such digital methods with
>> analog ones. Where the circuit really looks at some waveform
>> patterns and adjusts those.
> 
> Not really sure how I'd do that in any kind of automated way with the
> system I've got.  It's all driven by AVR Xmega parts at 32MHz,
> there's really no way to get enough oomph to analyze the signal in
> any meaningful way at runtime.
> 

Without enough computing horsepower and ADC you can't do it. But
something has got to set the ratios for any equalization scheme. At
least if there can be ad hoc changes in the bus configuration.


>> Then you'd have to cook up your own "more-tolerant" protocol. That
>> might make this solution unpalatable.
> 
> Yeah, that's really not my idea of a fun project.  I'd much rather go
> with the cut-wire repeater arrangement, especially given the massive
> bandwidth hit I'd take.
> 

Or, as I believe someone suggested, a multitone RF protocol. However,
then you need "micro-modems" at each node.

> 
>>> Yeah, that's why work on the TDR subsystem has been put off for
>>> now.
>> But it's fun :-)
> 
> I spent a few months on that project, and pretty much spun my wheels.
> When the time comes I really want to find somebody else to do it...
> 

Nah, solve it and you'll be da hero :-)


>> Gas-discharge is good but the voltage at which they come on is too
>> high for semiconductors.
> 
> Yeah, it would be in addition to lower-voltage protection.
> 
>> With a clean NRZ method there is also another option, signal 
>> transformers. They won't let any DC bother you. This is what I do
>> for defibrillator-proof medical gear which is tested with a slow
>> and very powerful (as in many amps) 5kV surge. Those are real
>> whoppers and it has heppened that a server of PBX system at clients
>> had to be reset after the test.
> 
> So I thought about that, but wouldn't the coil resistance of dozens
> of transformers on the line blow things out of the water?  Or would
> the transformers be capacitively coupled to the line themselves?
> I've seen that arrangement in the very few schematics I've seen of
> power-line systems.
> 

If you get too many of them clustered too close together, yes, they will
load down the line. One trick is to make the transformers wideband,
meaning that they present a very high impedance when not loaded on the
tap-off side yet reach to 5MHz or wherever you need them to go up to. On
a typical transformer the rule-of-thumb is to have the open inductive
reactance at least 4x the cable impedance at the lowest frequency to be
transmitted or received. Here you'd need a lot more.

You can capacitively couple them to the line but if there is not need to
have a differential DC signal you wouldn't have to.


> The biggest problem there (so to speak) is the size of such
> transformers.  They're getting crazy-small, but I've got a *tiny*
> space to work in.  I've got a 3mm max height limit, and the biggest
> open space I've got is *maybe* a centimeter square.


That's enough space for a signal transformer. If that 1cm^2 has to
contain the whole transceiver that is a tall order. Almost calls for a
custom IC design.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Wednesday, September 4, 2013 7:26:22 AM UTC-7, Joerg wrote:
> http://www.irf.com/product-info/datasheets/data/pb-ir3598.pdf.

Looks promising, though I'm confused as to why they give different source a=
nd sink values for the high and low sides, you'd think the two FET pairs wo=
uld be the same.  OTOH I guess that difference could be used to my advantag=
e.

> Best way to go on a project like this.

Yeah, I just have to convince them that even though it looks like a step ba=
ckward, it'll get us forward faster, since I can build test boards that don=
't have the insane density and collection of hard-to-hand-assemble parts th=
at I have to work with now.

> One of the tasks at hand is to minimize this added capacitance.

Yeah, I can clearly watch the effects as I add more units to the bus:

http://colo.omegacs.net/~omega/misc/disable-0to6-stations.gif

In this case I believe the test actually involved simply turning on each dr=
iver's RE in turn to increase the number of stations listening.  All 6 unit=
s were connected and powered on the line during each capture, just the RE's=
 were different.  You can see the leading edge of the waveform becoming una=
cceptable pretty quickly.  I think the point where packet loss became signi=
ficant was about 7-8 units.

IIRC that was with the max13451.

> Neutralizing that capacitance by a regenerative trick might work. If
> you do that and it works hand out barf bags before you start the design
> review :-)

My boss suggested that without any details, implying that I could receive t=
he signal and have units automatically loop it back.  Seems to me the probl=
em is a) there'd be too much latency between the receive and re-transmit, a=
nd b) the retransmitted signal might end up causing feedback all over the p=
lace.

> Or, as I believe someone suggested, a multitone RF protocol. However,
> then you need "micro-modems" at each node.

I've got a PLL-driven clock line dedicated to the interface circuit current=
ly unused, but I could use that to drive and sync a multitone protocol if t=
here's any way to get 1+Mbps out of it and fit it on the board.

> Nah, solve it and you'll be da hero :-)

Would be nice.

> If you get too many of them clustered too close together, yes, they will
> load down the line. One trick is to make the transformers wideband,=20
> meaning that they present a very high impedance when not loaded on the
> tap-off side yet reach to 5MHz or wherever you need them to go up to. On
> a typical transformer the rule-of-thumb is to have the open inductive
> reactance at least 4x the cable impedance at the lowest frequency to be
> transmitted or received. Here you'd need a lot more.

You just started speaking alien ;-( =20

> That's enough space for a signal transformer. If that 1cm^2 has to
> contain the whole transceiver that is a tall order. Almost calls for a
> custom IC design.

No, that's just the biggest single space.  The board is ~1.13" round with a=
 2x10 2mm connector on top center, the area equivalent of WS2812 'smart' LE=
D to one side of that, and 2x 2x7 0.5mm connectors on the bottom opposite s=
ides.  The rest of the board is free for all this stuff, albeit with seriou=
s height restrictions.  3mm up and maybe 1.5mm against the parts on the bot=
tom side board.