Maker Pro
Maker Pro

Discrete custom design of RS485 driver

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 whole history:

https://groups.google.com/forum/#!topic/sci.electronics.design/YZJz8Ys8KuU
Careful with the stock situations at distributors if this is for production.
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 able to provide parts directly when needed. But a) right now I'm just grasping at straws for anything that will work, and b) a discrete solution with multi-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 discrete gates to standard 485 transceivers as far as how "hard" they drive thebus. 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 trioof 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 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. Thisis the fallback mode I use to upload the stage-2 (fast-mode) bootloader tothe 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 tellme 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.

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

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 allthe units have enough onboard capacitance to ride out the ~10ms measurement 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.
 
Careful with the stock situations at distributors if this is for
production. Doesn't look too great IMHO. The SN65HVD24 looks ok though.

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.

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




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

Joerg

Jan 1, 1970
0
]

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.

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.

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

josephkk

Jan 1, 1970
0
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

?-)
 
J

josephkk

Jan 1, 1970
0
I think we have one around here, somewhere.

Wiki says

"RS-485 only specifies electrical characteristics of the generator and
the receiver. It does not specify or recommend any communications
protocol, only the physical layer. Other standards define the protocols
for communication over an RS-485 link."

http://en.wikipedia.org/wiki/RS-485

At any rate, there's no law against using an RS485 link to transmit
Manchester, or delta-sigma, or isochronous data, or anything else.

Really?

Let's see:

The Title reads:

"Electrical characteristics if generators and receivers for use in
balanced didigal multipoint systems".

So you first paragraph seems ok.

Wikipedia is while usually correct is NOT considered athoratative by
itself, nor by much of anybody else seriousily concerened with accuracy.

Having just reread both TIA-485 and the referenced document TIA-422 i
fine the following:

While the standards do support manchester encoding (my suprise), the
wording depreciates the use of it.

But i would really like to know how you conflate delta-sigma and
isochronous into the language of the standard. I could find nothing in
the standards that would support this. OTOH this it typical of the kinds
o flights of fancy you so typically take, and then claim that the
standards "support", when no such language exists within the standard.

Perhaps you are just a bully?

?-))
 
J

josephkk

Jan 1, 1970
0
It's right in this case: "485" is like "TTL" : it's about how to send 1
and 0, not about what they mean or what is encoded.


Deprecates? How so?




Exactly the point: the standard does not address coding; it talks about
logic levels. Applying *any* form in information coding or timing is
necessarily an act of design, a "flight of fancy." Since I can (and do)
push Manchester over an RS485 link, it does support it. It works.

You are deliberatly missing the point. TIA-485 does not address delta-
sigma or isochrounous. It is "out of scope" of the standard. Alleging
that it supports something out of scope is silly.
What sort of data encoding do you read the spec as allowing? Async ASCII
at 110 baud?
And you just started in on the bullying again. You put words in my mouth
of a position i never took to try to make me look the fool.
Bully? All my comments were technical. You have just gone personal.
Not at all the facts, you started the bullying. I just stood up to you.
You don't like it one bit do you?

?-))
 
J

John Devereux

Jan 1, 1970
0
josephkk said:
You are deliberatly missing the point. TIA-485 does not address delta-
sigma or isochrounous. It is "out of scope" of the standard. Alleging
that it supports something out of scope is silly.

Joseph, you are arguing about nothing, for the sake of it
apparently. JL's original wiki quote above is spot on and furthermore
you agree with it entirely from everything you have written since! The
standard does not specify encoding, encoding is outside its scope, blah
blah blah, you are both saying the same thing now but JL said it first
and then you initially contradicted it!
And you just started in on the bullying again. You put words in my mouth
of a position i never took to try to make me look the fool.
Not at all the facts, you started the bullying. I just stood up to you.
You don't like it one bit do you?

You are manufacturing a disagreement out of nothing, just to be
argumentative. Look again at the original wiki quote above. You already
say first paragraph is OK which only leaves:

What precisely is there to disagree with in that?
 
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.
Sorry for my ignorance in this area (like I said earlier, analog and me just don't get along), but how would that compare to e.g. a 74F gate drive?
Maybe I misunderstand this but the best is usually to remain at 50% duty
cycle and NRZ-code.
Generally yes, which is why I'd really like to keep the duty cycle closer to 30/70% rather than 10/90%. Putting fixed gates around the R/C will enable me to dial that in, by selecting gates where Vil and Vih are near the appropriate points for the 3.3v VCC. Right now though, it works for certain chips for a combination of reasons:

- the differential sag through the capacitive coupling is slow enough (for certain drivers, e.g. *not* the max3292) that longer low/high periods stay consistent as long as the primary bitrate is kept high enough (e.g. 4Mbaud)

- the digital R output (again *not* the max3292) through the R/C gives legitimate Vil and Vih for the microcontroller

The latter can be locked-in with surrounding gates, the former is still dependent on the driver structure.
Slow-mode can be a problem with such piggy-back schemes.
What do you mean by "piggy-back schemes"?
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 differentpossible forms:

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

- cut bus: a device with two discrete interfaces, plus heavy power decoupling (pass 36VDC via SSR but heavily block the overlaid 485 signal). Based on my high-level packet structures, it can spend most of it's time just shorting the R/D D/R lines together between the two interfaces, and only pull them apart when the protocol dictates otherwise.
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.
I have seen some variation with the presence of the TVS, but haven't quantified it yet. Do you mean diode in series with the bus itself? That would be a problem with a half-duplex bidirectional setup, right?
That sounds like the "bus from hell" :)
Yeah, that's why work on the TDR subsystem has been put off for now.
I am not sure that USB clamping will be strong enough.
I'll look for some "larger" parts and see what I can find. The theory of using that class of parts is correct though?

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

Joerg

Jan 1, 1970
0
Sorry for my ignorance in this area (like I said earlier, analog and
me just don't get along), but how would that compare to e.g. a 74F
gate drive?

If you take the 74F245 bus driver you can see under high-level output
voltage (top of page 3) that it is weaker when pulling up:

http://www.nxp.com/documents/data_sheet/74F245.pdf

Most of all, these are bipolar technology devices and those typically
don't have much oomph pulling up, only pulling down they have some
muscle. They can never pull all the way to the upper rail even for low
currents. Usually you are better off with a CMOS device.

If you need the ultimate in drive power I suggest to look at FET gate
drivers. Those are in the single digit ohms.

Generally yes, which is why I'd really like to keep the duty cycle
closer to 30/70% rather than 10/90%. Putting fixed gates around the
R/C will enable me to dial that in, by selecting gates where Vil and
Vih are near the appropriate points for the 3.3v VCC. Right now
though, it works for certain chips for a combination of reasons:

- the differential sag through the capacitive coupling is slow enough
(for certain drivers, e.g. *not* the max3292) that longer low/high
periods stay consistent as long as the primary bitrate is kept high
enough (e.g. 4Mbaud)

- the digital R output (again *not* the max3292) through the R/C
gives legitimate Vil and Vih for the microcontroller

The latter can be locked-in with surrounding gates, the former is
still dependent on the driver structure.

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.

What do you mean by "piggy-back schemes"?

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.

Auto-tune is what I propose above, using failure counters to find the
best option. ...


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.

... A repeater is another method I'm thinking of, but in
two different possible forms:

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

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

- cut bus: a device with two discrete interfaces, plus heavy power
decoupling (pass 36VDC via SSR but heavily block the overlaid 485
signal). Based on my high-level packet structures, it can spend most
of it's time just shorting the R/D D/R lines together between the two
interfaces, and only pull them apart when the protocol dictates
otherwise.

I have seen some variation with the presence of the TVS, but haven't
quantified it yet. Do you mean diode in series with the bus itself?
That would be a problem with a half-duplex bidirectional setup,
right?

I means bus to ground and between lines A and B. If you hang a TVS there
it will greatly muffle the data signal. There has to be a small signal
diode in series with each TVS. Then the TVS's capacitance charges up and
after that not much more current flows. Unless the 36V whopper transient
comes along, then you may lose a few bits in data but that is better
than seeing smoke coming out of TSSOP packages.

Yeah, that's why work on the TDR subsystem has been put off for now.

But it's fun :)

I'll look for some "larger" parts and see what I can find. The
theory of using that class of parts is correct though?

Yes, but it must be able to stomach whatever max current spike you are
expecting.

I was also thinking about higher-voltage protection, either from
lightning 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.


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

There are two ways of protection, opening or shunting. Opening tolerant
to several hundred volt (untill the gas-discharge comes on) gets
involved, lots of parts. Shunting usually is very reliable but will
dissipate any surge energy and must be respectively beefy.

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

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

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.

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

Joerg

Jan 1, 1970
0
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.


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

whit3rd

Jan 1, 1970
0
On Friday, August 30, 2013 9:15:29 AM UTC-7, [email protected] wrote:

[about differential RS-485 signaling)
I was also thinking about higher-voltage protection, either from lightning 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 trickthere.

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

Joerg

Jan 1, 1970
0
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.
 
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 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 wouldbe 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 by branches, which my system doesn't really have in the sense that I've seenthem defined. The units on the bus have maybe 3/4" or less between the vampire 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 system I've got. It's all driven by AVR Xmega parts at 32MHz, there's really noway to get enough oomph to analyze the signal in any meaningful way at runtime.
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.

But it's fun :)

I spent a few months on that project, and pretty much spun my wheels. Whenthe 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.
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.

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.
 
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 onlya few combinations of transmitter/receiver that I care about. The controller can broadcast a pseudorandom set of all the various possibilities with their parameters built into the packets, then slow-query all the units on the bus for their received packet counts, split into each transmit arrangement. Find the "best" bin for each unit that has a 99+% receive rate for that 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 there except in dealing with timeouts for situations when e.g. one unit speaks 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 shipping a terminator "unit"), invalid branches (mine are maybe 3/4" *max* from the 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, and datarate budgets. If there's a reasonable way to implement OOK or FSK at1Mbps or better using the existing UART pins and packet protocols I've got, I'd be all over that.
 
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 either250ns or 500ns highs and lows, nothing more. The start/stop bits aid in that of course.

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

I have encoding options built in, so that *if* the bus is happy with just the start/stop transitions (e.g. it doesn't sag too fast between edges) I can also transmit un-encoded data, although the preamble and header is *always* Manchester. The control bits for the modes are in the Manchester-encoded packet header, so it switches on a per-packet basis as received.
 
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).
 
J

Joerg

Jan 1, 1970
0
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.
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.
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 :)

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.

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

Yeah, it would be in addition to lower-voltage protection.


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