Discrete custom design of RS485 driver

[Klaus Kragelund]

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

[Klaus Kragelund]

A rough first draft:

www.electronicsdesign.dk/tmp/RS485_Custom.pdf

[Jim Thompson]

With only a 2V supply, how do you get enough drive for the P-channel
device? Do you have a more negative supply available?

An amusing thought... I know that open drain output logic exists, at
least with an N-channel output. Does such a thing exist with a
P-channel open-drain?

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

[upsid...@downunder.com]

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

>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

This is not a Modbus specific issue, but rather RS-485 specific issue
with a twisted pair bus with characteristic impedance of 100-120 ohms.
In order to avoid reflections at the open ends of the bus cable,
termination resistors are typically used at both ends with the same
value as the cable characteristic impedance.

For DC, those two resistors are effectively in parallel and hence the
45 ohm total load.

However, those termination resistors are needed only to avoid the
reflections from voltage _transitions_. Thus, putting a capacitor in
series with the termination resistor(s) should reduce the idle power
consumption, when no data is being sent. Of course, without DC
continuity, the end to end signal ground conductor is essential.

There are application notes describing even more elaborate termination
methods, describing their advantages and disadvantages. You should
also look for various termination techniques used on CAN bus (which is
essentially RS-485).

[John Larkin]

On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
<klau...@hotmail.com> 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.

We recently did this:

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

The basic line driver is a couple of tiny-logic gates driven from complementary
FPGA outputs. The downstream junk is selectable line driver equalization, to
partially correct for CAT5 cable losses. This runs up to 125 MHz.


--

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

[Joerg]

Just a comment: Diodes are already in the FETs, in the form of body diodes.

One thought would be whether a hysteretic sync-buck IC could be pressed
into service here. I haven't needed one this low in voltage yet but they
should come for very low supply voltages (processor core supplies and such).

--
Regards, Joerg

http://www.analogconsultants.com/

[Klaus Kragelund]

On Friday, December 21, 2012 5:09:01 PM UTC+1, Jim Thompson wrote:
> On Fri, 21 Dec 2012 04:27:55 -0800 (PST), Klaus Kragelund
>
> <klau...@hotmail.com> wrote:
>
>
>
> >On Friday, December 21, 2012 12:02:40 PM UTC+1, Klaus Kragelund 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?
>
> >>
>
> >
>
> >A rough first draft:
>
> >
>
> >www.electronicsdesign.dk/tmp/RS485_Custom.pdf
>
>
>
> With only a 2V supply, how do you get enough drive for the P-channel
>
> device? Do you have a more negative supply available?
>

The voltage rail for the FET are driven by 2V and I will generate an additional supply voltage to drive the gates, about 3V.


The majority of the power goes for the bus, driving the 54ohms load (120//120//1500 ohms in parallel, that is two termination resistors and the 32 unit load impedance).

Right now the implementation is using a standard RS485 driver running at 3V supply, but with 54 ohms resistance along with the driver impedance, draws 90mW during transmission.

A low RDSon driver at 2V would reduce that to about 60mW

Regards

Klaus

[Klaus Kragelund]

On Friday, December 21, 2012 7:12:56 PM UTC+1, Joerg wrote:
> Klaus Kragelund wrote:
>
> > On Friday, December 21, 2012 12:02:40 PM UTC+1, Klaus Kragelund
>
> > 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?
>
> >>
>
> >
>
> > A rough first draft:
>
> >
>
> > www.electronicsdesign.dk/tmp/RS485_Custom.pdf
>
>
>
>
>
> Just a comment: Diodes are already in the FETs, in the form of body diodes.
>
>

Yes, I added parallel more sturdy diodes, to direct the current away from the low current body diodes.

Regards

Klaus

[Klaus Kragelund]

Yes, but to conform to the Modbus standard, the termination resistors are added without diodes

Cheers

Klaus

[Klaus Kragelund]

On Friday, December 21, 2012 6:16:02 PM UTC+1, John Larkin wrote:
> On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
>
> <klau...@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
>
>
>
>
>
> 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.
>
>
>
> We recently did this:
>
>
>
> https://dl.dropbox.com/u/53724080/Circuits/ESM/Line_Drivers.pdf
>
>
>
> The basic line driver is a couple of tiny-logic gates driven from complementary
>
> FPGA outputs. The downstream junk is selectable line driver equalization, to
>
> partially correct for CAT5 cable losses. This runs up to 125 MHz.

Maybe a good point, if I can find a logic device that has low RDSon at 2V.

The ones I have found have 10ohms RDSon (NC7SZ74), but could parallel some of those to bring down the RDSon to the 2-3 ohms range

Regards

Klaus

[Tim Williams]

"Klaus Kragelund" <klau...@hotmail.com> wrote in message
news:3a305d28-7df1-431d...@googlegroups.com...

> Yes, I added parallel more sturdy diodes, to direct the current away
> from the low current body diodes.

Are you expecting huge common mode transients? MOSFET diodes have been
rated at, or above, the channel current for ages. FDV301N says 0.29A
diode, 0.22A channel (both I'm sure depend on thermal resistance, it's
only an SOT-23). I've never used external diodes in an inductively loaded
inverter and never found any reason to: the body diodes do a fine job.
They just aren't good at hard switching (slow recovery).

Have you considered BJTs for this? They tend to be easier to drive at
lower voltages. With Vceo as low, you can easily find fast transistors
with high hFE, so even with saturated operation, you don't have to worry
about switching speed or error in the current source. You may still need
a bootstrap (using all NPNs, or a negative bootstrap for the PNP pair),
but only one at least.

The TL431 as shown clamps about 5V, which is way more than your supply --
are you sure about this? If it's for ESD, it's only clamping 100mA, and
takes a moment to respond. A zener TVS would be a bit sloppier (a 3.3V
rated device might break down at 5V and carry a heavy load at, say,
8V...), but much faster and more robust. You could also use a diode back
to the +2V supply, which is probably as transient-resistant.

Tim

--
Deep Friar: a very philosophical monk.
Website: http://seventransistorlabs.com

[Klaus Kragelund]

On Friday, December 21, 2012 9:10:45 PM UTC+1, Tim Williams wrote:
> "Klaus Kragelund" <klau...@hotmail.com> wrote in message
>
> news:3a305d28-7df1-431d...@googlegroups.com...
>
> > Yes, I added parallel more sturdy diodes, to direct the current away
>
> > from the low current body diodes.
>
>
>
> Are you expecting huge common mode transients? MOSFET diodes have been
>
> rated at, or above, the channel current for ages. FDV301N says 0.29A
>
> diode, 0.22A channel (both I'm sure depend on thermal resistance, it's
>
> only an SOT-23). I've never used external diodes in an inductively loaded
>
> inverter and never found any reason to: the body diodes do a fine job.
>
> They just aren't good at hard switching (slow recovery).
>

Yes, the RS485 line is subjected to hot swapping, termination resistors inserted "live" and must be tested against surges/bursts. I am also worried about injected DC voltages from user wrongful installation.

The big diodes is used to divert current to the clamp using the 1ohms resistor to allow for the external diodes to draw the biggest portion of the current.

>
>
> Have you considered BJTs for this? They tend to be easier to drive at
>
> lower voltages. With Vceo as low, you can easily find fast transistors
>
> with high hFE, so even with saturated operation, you don't have to worry
>
> about switching speed or error in the current source. You may still need
>
> a bootstrap (using all NPNs, or a negative bootstrap for the PNP pair),
>
> but only one at least.

Yes, could be a good idea, just need to add circuitry to draw the carriers out of the base to switch them off fast.

Regards

Klaus

[John Larkin]

On Fri, 21 Dec 2012 11:11:58 -0800 (PST), Klaus Kragelund

Right. Parallel the sections of some 10-cent TinyLogic gate.



--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

VME thermocouple, LVDT, synchro acquisition and simulation

[Joerg]

Usually they are about as sturdy as the channel in the FET, can take a
similar current.

Diverting current away from those only works (to some extent) if you
hang a Schottky of sigifnicant size in parallel. The best method would
be to steer the FET conductive while some massive surge current shows up
for some reason.

[Jim Thompson]

On Fri, 21 Dec 2012 10:12:56 -0800, Joerg <inv...@invalid.invalid>
wrote:

>Klaus Kragelund wrote:
>> On Friday, December 21, 2012 12:02:40 PM UTC+1, Klaus Kragelund
>> 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?
>>>
>>
>> A rough first draft:
>>
>> www.electronicsdesign.dk/tmp/RS485_Custom.pdf
>
>
>Just a comment: Diodes are already in the FETs, in the form of body diodes.

And generally not safe to use for repetitive pulses. Some discrete
FET's I was using at Zarlink came with a Schottky in the same package.

>
>One thought would be whether a hysteretic sync-buck IC could be pressed
>into service here. I haven't needed one this low in voltage yet but they
>should come for very low supply voltages (processor core supplies and such).

[Jim Thompson]

On Fri, 21 Dec 2012 11:11:58 -0800 (PST), Klaus Kragelund

Do you need to tri-state the driver? If so, Larkin's suggestion
doesn't work. Even with tri-state you have to watch out for "kick"
above/below rails.

[upsid...@downunder.com]

What diodes ? I was suggesting using capacitors.

What Modbus "standard" ?
The closest that I can think as electric Modbus standard is the
http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
"MODBUS over serial line specification and implementation guide V1.02"

Look at page 28

>Line termination may be a 150 ohms value ( 0.5 W ) resistor.

>A serial capacitor ( 1 nF, 10 V minimum ) with a 120 Ohms ( 0.25 W )
>resistor is a better choice when a polarization of the pair must
>be implemented (see here after).

Polarization = "Fail safe termination" in RS-485 speak.

[John Larkin]

Why not? Use tri-state tiny-logic drivers.

Even with tri-state you have to watch out for "kick"
>above/below rails.

Kick? Logic chips can't drive transmission lines? Add some protection
if you expect lightning bolts.

Logic chips have ESD diodes in both directions. Discretes usually
don't. You're being a jerk, as usual.

--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

[Joerg]

Jim Thompson wrote:
> On Fri, 21 Dec 2012 10:12:56 -0800, Joerg <inv...@invalid.invalid>
> wrote:
>
>> Klaus Kragelund wrote:
>>> On Friday, December 21, 2012 12:02:40 PM UTC+1, Klaus Kragelund
>>> 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?
>>>>
>>> A rough first draft:
>>>
>>> www.electronicsdesign.dk/tmp/RS485_Custom.pdf
>>
>> Just a comment: Diodes are already in the FETs, in the form of body diodes.
>

> And generally not safe to use for repetitive pulses. ...


Why that? They are often used as regular power current paths. The
current rating is roughly the same as the FET itself, usually.


> ... Some discrete

> FET's I was using at Zarlink came with a Schottky in the same package.
>

With RF stuff all bets are off, RF transistors can be like the princess
on the pea. 3V reverse Vbe ... poof ... gone. Or gaoan, as they'd say at
one client.

[...]

[Klaus Kragelund]

On Friday, December 21, 2012 11:04:06 PM UTC+1, upsid...@downunder.com wrote:
> On Fri, 21 Dec 2012 11:03:25 -0800 (PST), Klaus Kragelund
>
> <klau...@hotmail.com> wrote:
>
>
>
> >> However, those termination resistors are needed only to avoid the
>
> >> reflections from voltage _transitions_. Thus, putting a capacitor in
>
> >> series with the termination resistor(s) should reduce the idle power
>
> >> consumption, when no data is being sent. Of course, without DC
>
> >> continuity, the end to end signal ground conductor is essential.
>
> >>
>
> >>
>
> >>
>
> >> There are application notes describing even more elaborate termination
>
> >> methods, describing their advantages and disadvantages. You should
>
> >> also look for various termination techniques used on CAN bus (which is
>
> >> essentially RS-485).
>
> >
>
> >Yes, but to conform to the Modbus standard, the termination resistors are
>
> >added without diodes
>
>
>
> What diodes ? I was suggesting using capacitors.
>
>

I meant to write capacitor, sorry :-)

>
> What Modbus "standard" ?
>
> The closest that I can think as electric Modbus standard is the
>
> http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
>
> "MODBUS over serial line specification and implementation guide V1.02"
>
>
>
> Look at page 28
>
>
>
> >Line termination may be a 150 ohms value ( 0.5 W ) resistor.
>
>

Yes, the Modbus standard defines that, but the widespread industry standard is 120 ohms and no capacitor. (adopted from the RS485 standard)

Cheers

Klaus

[Klaus Kragelund]

Yes, I need to tristate the driver, since it is a 2 wire system, half duplex.

Regards

Klaus

[Klaus Kragelund]

We would need to add protection in any case to reduce the currents, the driver IC would suffer from latchup problems if not.

Cheers

Klaus

[John Larkin]

On Fri, 21 Dec 2012 14:52:43 -0800 (PST), Klaus Kragelund

I've never seen a cmos chip latch up from driving a low-z load,
including a short to either rail. You can get them pretty hot. Pushing
a lot of current into an ESD diode can latch some parts. We use tiny
logic drivers in the thing I posted, and in other products that we've
sold thousands of, driving customer loads of all sorts, and haven't
had any latchup problems.

[Jim Thompson]

On Fri, 21 Dec 2012 14:45:35 -0800, Joerg <inv...@invalid.invalid>
wrote:

But resistive, since it's a current path from the back of the die.

Go ahead... I always enjoy your sound effects >:-}

>
>
>> ... Some discrete
>> FET's I was using at Zarlink came with a Schottky in the same package.
>>

I mis-spoke... make that Synaptics.

>
>With RF stuff all bets are off, RF transistors can be like the princess
>on the pea. 3V reverse Vbe ... poof ... gone. Or gaoan, as they'd say at
>one client.
>
>[...]

Here today, China tomorrow ;-)

[Tim Williams]

"Klaus Kragelund" <klau...@hotmail.com> wrote in message

news:8f642a78-2a12-40c8...@googlegroups.com...

> Yes, could be a good idea, just need to add circuitry to draw the
> carriers out of the base to switch them off fast.

And that's not even that big of a deal, really -- if you run 2N4401/3 kind
of hot (~20mA Ic, 2mA base drive, 680 ohm B-E resistor), you'll see edges
under 100ns and storage time under 300ns (storage causes skew, but it's
symmetrical in an H-bridge, so it causes shoot-through and delay).
115kbaud gives you almost 10us between edges, so there's tons of time for
switching.

The average switching transistor (like the little complementary gate drive
things, or just a plain old ZTX651 or etc.) is even beefier, maintaining
hFE > 100 at rated collector current. So, even saturated (where hFE is
lower and stored charge piles up), they don't take much drive current at
all, relative to what they're doing. They start looking like low Vgs(th)
MOSFETs, with an input diode thrown in for convenience.

[Joerg]

What's the difference? Whether 0.7V drops across a more or less
resistive path, who cares? All that counts is total dissipation and that
it's not too localized.

> Go ahead... I always enjoy your sound effects >:-}
>
>>
>>> ... Some discrete
>>> FET's I was using at Zarlink came with a Schottky in the same package.
>>>
>
> I mis-spoke... make that Synaptics.
>
>> With RF stuff all bets are off, RF transistors can be like the princess
>> on the pea. 3V reverse Vbe ... poof ... gone. Or gaoan, as they'd say at
>> one client.
>>
>> [...]
>
> Here today, China tomorrow ;-)
>

I sure hope we can at least keep high-end semiconductor engineering and
processing in the country for a while, now that Obamacare is smothering
much of the med device investment climate. We can't afford to lose such
leadership positions but obviously that doesn't sink in on the hill :-(

[Jim Thompson]

On Fri, 21 Dec 2012 15:54:37 -0800, Joerg <inv...@invalid.invalid>

Except for the expert witness stuff (3 weeks in Dallas Federal
District Court starting around January 7 :-), all of my work is now
west of Honolulu.

[rickman]

On 12/21/2012 6:54 PM, Joerg wrote:
>
> I sure hope we can at least keep high-end semiconductor engineering and
> processing in the country for a while, now that Obamacare is smothering
> much of the med device investment climate.

I would love to hear some sort of rational explanation of how that is
happening.

Rick

[Joerg]

Jim Thompson wrote:
> On Fri, 21 Dec 2012 15:54:37 -0800, Joerg <inv...@invalid.invalid>
> wrote:
>
>> Jim Thompson wrote:
>>> On Fri, 21 Dec 2012 14:45:35 -0800, Joerg <inv...@invalid.invalid>
>>> wrote:
>>>
>>>> Jim Thompson wrote:

[...]

>>>>> ... Some discrete
>>>>> FET's I was using at Zarlink came with a Schottky in the same package.
>>>>>
>>> I mis-spoke... make that Synaptics.
>>>
>>>> With RF stuff all bets are off, RF transistors can be like the princess
>>>> on the pea. 3V reverse Vbe ... poof ... gone. Or gaoan, as they'd say at
>>>> one client.
>>>>
>>>> [...]
>>> Here today, China tomorrow ;-)
>>>
>> I sure hope we can at least keep high-end semiconductor engineering and
>> processing in the country for a while, now that Obamacare is smothering
>> much of the med device investment climate. We can't afford to lose such
>> leadership positions but obviously that doesn't sink in on the hill :-(
>
> Except for the expert witness stuff (3 weeks in Dallas Federal
> District Court starting around January 7 :-), all of my work is now
> west of Honolulu.
>

Interesting. Mine is still mostly on US soil, or all of it right now.
But medical has nearly evaporated from a consulting point of view, from
>50% a few years ago down to <10%. Plenty of work here but all
industrial, oil, gas, aerospace and so on. That does not bode well for
med-tech in our country.

[Joerg]

Many reasons. A major one is the new medical device tax. This will skim
2.3% off the top. From revenue. It means that start-up companies that
typically do not turn a profit for easily the first 10 years will get
burdened with it. For others that are in the disposables business and
run on 5-10% profit margins one can easily see that it will wipe out a
huge chunk of that.

Then there's rationing that'll happen. Medical is a zero sum game, we
can't run it on hot air (a.k.a. bonds) forever. We have already seen
slashing of reimbursements. This will make certain higher end products
unprofitable, and high-end is where our country excels. So while now
everyone may be entitled to a free enema or flu shot there are likely
going to be growing waiting lists when you need help with some serious
stuff. Just like there are in Canada. This means less revenue for
manufacturers.

Next, capital gains taxes. Funding a start-up is a major risk for the
investors. So if the rewards they can reap are majorly cut down by tax
increases they will, obviously, curb their risk exposure. That's what I
am seeing the most in the med venture space, a risk-averseness that I
have not encountered ever in the past. And I am in med tech since the 80's.

I could go on and on, but hopefully this suffices to explain some of the
effects that I (and a lot of others) see coming or have already
experienced. Personally I've seen things not being funded that used to
be a sure thing 10 years ago, plus whole projects got canned that had
progressed quite far. While people like me can move to other areas in
engineering because I have kept a generalist attitude all my life that
is no so for many others. My former employer is in the process of moving
production to Costa Rica. Other companies have started layoffs:

http://www.examiner.com/article/stryker-lays-1-000-people-off-blames-obamacare-s-medical-device-tax

Where will these people find work?

[John Larkin]

On Fri, 21 Dec 2012 14:48:12 -0800 (PST), Klaus Kragelund

Can you make the whole system LVDS?


--

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

[dagmarg...@yahoo.com]

On Dec 21, 3:48 pm, Joerg <inva...@invalid.invalid> wrote:
> Klaus Kragelund wrote:
> > On Friday, December 21, 2012 7:12:56 PM UTC+1, Joerg wrote:

> >> Just a comment: Diodes are already in the FETs, in the form of body diodes.
>
> > Yes, I added parallel more sturdy diodes, to direct the current away from the low current body diodes.
>
> Usually they are about as sturdy as the channel in the FET, can take a
> similar current.

Note: I don't see a spec for the FDV304P's trr. Body diodes' trr can
be horrendously slow--at least once upon a time on power FETs they
often were...


--
Cheers,
James Arthur

[dagmarg...@yahoo.com]

On Dec 21, 6:09 pm, John Larkin wrote:

> On Fri, 21 Dec 2012 14:52:43 -0800 (PST), Klaus Kragelund wrote:
> >On Friday, December 21, 2012 11:41:12 PM UTC+1, John Larkin wrote:

> >> if you expect lightning bolts.
>
> >We would need to add protection in any case to reduce the currents, the driver IC would suffer from latchup problems if not.
>
> I've never seen a cmos chip latch up from driving a low-z load,
> including a short to either rail. You can get them pretty hot. Pushing
> a lot of current into an ESD diode can latch some parts. We use tiny
> logic drivers in the thing I posted, and in other products that we've
> sold thousands of, driving customer loads of all sorts, and haven't
> had any latchup problems.

Usually the latchup current specs are considerably larger than the
possible output currents. Therefore, neither driver nor receiver
should be able to latch from reflections.

Lightning's a different matter.

We fielded some RTUs ages ago, a new design where I tried a number of
ideas, including improved lightening protection. Annual field
failures went down from numerous to two, one of which had a several-
inch lightning hole burned thru the heavy-gauge steel enclosure, a
direct hit.

--
Cheers,
James Arthur

[dagmarg...@yahoo.com]

On Dec 21, 7:45 pm, Joerg <inva...@invalid.invalid> wrote:
> rickman wrote:
> > On 12/21/2012 6:54 PM, Joerg wrote:
>
> >> I sure hope we can at least keep high-end semiconductor engineering and
> >> processing in the country for a while, now that Obamacare is smothering
> >> much of the med device investment climate.
>
> > I would love to hear some sort of rational explanation of how that is
> > happening.
>
> Many reasons. A major one is the new medical device tax. This will skim
> 2.3% off the top. From revenue.

Right. 2.3% of sales, which, if a company's making 10%, is 23% of
their profits. Naturally, this is just the start. Rates will rise,
not fall.

> http://www.examiner.com/article/stryker-lays-1-000-people-off-blames-...

>
> Where will these people find work?

Good, concise explanation: medical device tax, cap gains, lower
reimbursements, rationing, for starters.

It's a big hit, a very big hit.

James Arthur

[k...@att.bizzz]

On Fri, 21 Dec 2012 19:06:43 -0800 (PST), dagmarg...@yahoo.com
wrote:

Define "slow". This is the one I'm currently using (Trr=40ns) for a
power supply. I'm going to have to go to a 60V device, though.

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

[miso]

Is it possible the VC is going to stupid internet social media garbage?
Ya think?

Why build a market for a hardware device, which hey, is work, when you
can sell nonsense. The current mania is photographs that disappear, when
it used in sexting. Hey, I know of a few congressmen who could have used
such a service.

[miso]

If supply voltage is the only issue, have you investigated using a DC/DC
plus an off the shelf 485?

[upsid...@downunder.com]

I still think that you are trying to solve the wrong problem.

By using some add-hoc driver design, you are most likely going to
create much more compatibility issues with devices from various
vendors.

Since the RS-485 standard requires a +/-200 mV swing between the
receiver terminal, with 54 ohm total load, the driver must be able to
supply _at_lest_ +/-3.7 mA.

With +/- 2V Tx voltage swing, the total loop resistance should be
below 540 ohms, i.e 240 ohms in a single conductor, so at least 0.3 mm
wire diameter is required for 1000 m.

The power dissipation issue is worse in point-to-point RS-422
connections, in which the transmitters are constantly on and must be
able to supply 2 mA to the termination resistor at the opposite end,
even when the line is idle.

However, Modbus over RS-485 is a half duplex protocol with at most one
transmitter in the active state feeding the termination, while all the
other are in the tri-state. Thus the total system consumption is quite
low. Due to the request/response nature of Modbus, the master Tx duty
cycle would be around 50 %, while in a multidrop system, the duty
cycle for the Tx is much lower, perhaps a few percent, keeping the
total energy consumed at a low value for each device.

By using 120 /120 /1500 ohms, it appears that you do not intend to use
polarization a.k.a pullup/pulldown resistors. While no data is being
transmitted, no transmitter is active the bus in a high impedance
state, with only the receiver leakages as a load. That 1500 ohms was
for 32 slaves, but with only a few slaves, the impedance is quite high
and sensitive to electrostatically connected interference (typically
false start bits).

In Modbus standard, this has been accounted for, by requiring that the
pause between individual bytes must not be greater than 1.5 character
times and that when the transmitter is turned from tri-state to
active, it must send the idle (Mark, "1") state for at least 3.5
character times. This will allow any reflections to die out and during
this period, any receiver will flush any spurious line noise (the 1.5
character time rule). Then the actual message transmission is
performed, followed by the Tx driven actively to idle (Mark, "1")
state for an additional 3.5 character times. This allows reliable end
of frame detection, by suppressing any reflections etc. immediately
after the data frame.


However, in a multivendor environment, it is not clear how well these
timing rules are followed, especially at high speeds, thus to ensure
maximum interoperability, I would definitively recommend using those
pullup/pulldon resistors on the bus to lower the impedance levels
while all transmitters are in the tri-state.

Regarding the 1 nF+120 ohm termination, the RC time constant is 0.12
us, hence after a few RC time constants, say 0.5 us after the last
signal transition, practically no power is delivered to the
termination resistance. At 115k2 with bit times of 9 us, power is
dissipated during 6 % of the bit time. Since there can be consecutive
"00..." or "11..." sequences in a message, without state changes
between bits (NRZ), the actual duty cycle is even less.

So I really do not understand, why you want to design a custom driver
to reduce power dissipation.

[upsid...@downunder.com]

On Fri, 21 Dec 2012 14:41:12 -0800, John Larkin
<jla...@highlandtechnology.com> wrote:

>>Do you need to tri-state the driver? If so, Larkin's suggestion
>>doesn't work.
>
>Why not? Use tri-state tiny-logic drivers.
>
>
>Even with tri-state you have to watch out for "kick"
>>above/below rails.
>
>Kick? Logic chips can't drive transmission lines? Add some protection
>if you expect lightning bolts.
>
>Logic chips have ESD diodes in both directions. Discretes usually
>don't. You're being a jerk, as usual.

Please remember, that the RS-485 specification requires -7 .. +12 V
common mode voltage range, well above and below the usual 0, +5 V
power supply range.

Since the driver is constantly connected to the bus, so while two
other devices are communicating with each other, the common mode
voltage can vary greatly. I hope that your ad hoc driver will not go
into some latch-up or high protection diode leaking mode, disrupting
the communication between other stations.

I really hope that I will not encounter such substandard ad hoc
drivers on RS-485 systems that I am responsible of.

[John Devereux]

upsid...@downunder.com writes:

> On Fri, 21 Dec 2012 14:46:15 -0800 (PST), Klaus Kragelund
> <klau...@hotmail.com> wrote:
>
>>> What Modbus "standard" ?
>>>
>>> The closest that I can think as electric Modbus standard is the
>>> http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
>>> "MODBUS over serial line specification and implementation guide V1.02"
>>>
>>> Look at page 28
>>>
>>> >Line termination may be a 150 ohms value ( 0.5 W ) resistor.
>
>
>>Yes, the Modbus standard defines that, but the widespread industry
>>standard is 120 ohms and no capacitor. (adopted from the RS485 standard)

[...]

>
> In Modbus standard, this has been accounted for, by requiring that the
> pause between individual bytes must not be greater than 1.5 character
> times and that when the transmitter is turned from tri-state to
> active, it must send the idle (Mark, "1") state for at least 3.5
> character times. This will allow any reflections to die out and during
> this period, any receiver will flush any spurious line noise (the 1.5
> character time rule). Then the actual message transmission is
> performed, followed by the Tx driven actively to idle (Mark, "1")
> state for an additional 3.5 character times. This allows reliable end
> of frame detection, by suppressing any reflections etc. immediately
> after the data frame.
>

[...]

Thanks for such an informative post - I have been using/implementing
modbus, on occasion, for 15 years. And have never seen this stuff
spelled out before.


--

John Devereux

[Klaus Kragelund]

On Saturday, December 22, 2012 9:28:05 AM UTC+1, upsid...@downunder.com wrote:
> On Fri, 21 Dec 2012 14:46:15 -0800 (PST), Klaus Kragelund
>
> <klau...@hotmail.com> wrote:
>
>
>
> >> What Modbus "standard" ?
>
> >>
>
> >> The closest that I can think as electric Modbus standard is the
>
> >> http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
>
> >> "MODBUS over serial line specification and implementation guide V1.02"
>
> >>
>
> >> Look at page 28
>
> >>
>
> >> >Line termination may be a 150 ohms value ( 0.5 W ) resistor.
>
>
>
>
>
> >Yes, the Modbus standard defines that, but the widespread industry
>
> >standard is 120 ohms and no capacitor. (adopted from the RS485 standard)
>
>
>
> I still think that you are trying to solve the wrong problem.
>
>
>
> By using some add-hoc driver design, you are most likely going to
>
> create much more compatibility issues with devices from various
>
> vendors.
>
>
>
> Since the RS-485 standard requires a +/-200 mV swing between the
>
> receiver terminal, with 54 ohm total load, the driver must be able to
>
> supply _at_lest_ +/-3.7 mA.
>
>

The standard defines minimum 1.5V into 54ohms. I need to comply to that to be caompatible to other devices. The difference from 1.5V to 200mV is the noise and attenuation margin.

>
> With +/- 2V Tx voltage swing, the total loop resistance should be
>
> below 540 ohms, i.e 240 ohms in a single conductor, so at least 0.3 mm
>
> wire diameter is required for 1000 m.
>
>

Modbus defines 1200m maximum length

>
> The power dissipation issue is worse in point-to-point RS-422
>
> connections, in which the transmitters are constantly on and must be
>
> able to supply 2 mA to the termination resistor at the opposite end,
>
> even when the line is idle.
>
>
>
> However, Modbus over RS-485 is a half duplex protocol with at most one
>
> transmitter in the active state feeding the termination, while all the
>
> other are in the tri-state. Thus the total system consumption is quite
>
> low. Due to the request/response nature of Modbus, the master Tx duty
>
> cycle would be around 50 %, while in a multidrop system, the duty
>
> cycle for the Tx is much lower, perhaps a few percent, keeping the
>
> total energy consumed at a low value for each device.
>
>
>

We cannot know if we are in a multidrop system or if the user uses a point-to-point system (1 device). So the duty cycle can approach 50% and to avoid storage capacitors we would need to supply the full TX current (low baud rate constraint)

> By using 120 /120 /1500 ohms, it appears that you do not intend to use
>
> polarization a.k.a pullup/pulldown resistors. While no data is being
>
> transmitted, no transmitter is active the bus in a high impedance
>
> state, with only the receiver leakages as a load. That 1500 ohms was
>
> for 32 slaves, but with only a few slaves, the impedance is quite high
>
> and sensitive to electrostatically connected interference (typically
>
> false start bits).
>
>

We have failsafe resistors, to put the bus in known state if the wires are open circuit

>
> In Modbus standard, this has been accounted for, by requiring that the
>
> pause between individual bytes must not be greater than 1.5 character
>
> times and that when the transmitter is turned from tri-state to
>
> active, it must send the idle (Mark, "1") state for at least 3.5
>
> character times. This will allow any reflections to die out and during
>
> this period, any receiver will flush any spurious line noise (the 1.5
>
> character time rule). Then the actual message transmission is
>
> performed, followed by the Tx driven actively to idle (Mark, "1")
>
> state for an additional 3.5 character times. This allows reliable end
>
> of frame detection, by suppressing any reflections etc. immediately
>
> after the data frame.
>
>

We use the 3.5c to our advantage, since that prolongs the low current RX state

>
>
>
> However, in a multivendor environment, it is not clear how well these
>
> timing rules are followed, especially at high speeds, thus to ensure
>
> maximum interoperability, I would definitively recommend using those
>
> pullup/pulldon resistors on the bus to lower the impedance levels
>
> while all transmitters are in the tri-state.
>
>

Modbus is funny, the standard has contracteditions, and the industry users has invented their own semistandard. We have scanned the usergroups to be sure we cover the "funny" cases

>
> Regarding the 1 nF+120 ohm termination, the RC time constant is 0.12
>
> us, hence after a few RC time constants, say 0.5 us after the last
>
> signal transition, practically no power is delivered to the
>
> termination resistance. At 115k2 with bit times of 9 us, power is
>
> dissipated during 6 % of the bit time. Since there can be consecutive
>
> "00..." or "11..." sequences in a message, without state changes
>
> between bits (NRZ), the actual duty cycle is even less.
>
>
>
> So I really do not understand, why you want to design a custom driver
>
> to reduce power dissipation.

We have not found any drivers below 3V supply that can drive 54 ohms, and that 3V drive is beyond our power budget.

Thank you for your valuable comments :-)

Regards

Klaus

[Klaus Kragelund]

Our device is one out of many Modbus device from other suppliers, so we cannot do other than comply to RS485/Modbus standard

Cheers

Klaus

[Klaus Kragelund]

On Saturday, December 22, 2012 7:43:22 AM UTC+1, miso wrote:
> If supply voltage is the only issue, have you investigated using a DC/DC
>
> plus an off the shelf 485?

Yes, currently we are using off the shelf RS485, but the bus voltage is high due to 3V supply, so the power budget is exceeded

We have seen no devices below 3V that can drive 54 ohms

Regards

Klaus

[upsid...@downunder.com]

On Sat, 22 Dec 2012 02:07:12 -0800 (PST), Klaus Kragelund
<klau...@hotmail.com> wrote:

>On Saturday, December 22, 2012 9:28:05 AM UTC+1, upsid...@downunder.com wrote:
>> >> The closest that I can think as electric Modbus standard is the
>> >> http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
>> >> "MODBUS over serial line specification and implementation guide V1.02"

>> With +/- 2V Tx voltage swing, the total loop resistance should be
>> below 540 ohms, i.e 240 ohms in a single conductor, so at least 0.3 mm
>> wire diameter is required for 1000 m.

>Modbus defines 1200m maximum length

That referenced Modbus.org document states on page 27,

>For a maximum 9600 Baud Rate and AWG26 (or wider) gauge,
>the maximum length is 1000m.

I am fully aware that the RS-485 specifies maximum 1200 m or to be
pedantic 4000 ft.

>Modbus is funny, the standard has contracteditions,
>and the industry users has invented their own semistandard.
>We have scanned the usergroups to be sure we cover the "funny" cases

The Modbus was developed by Modicon to be used in their PLCs in the
1970's. By studying the various Modicon PLC documentations, there were
already some differences. When other vendors tried to create
compatible products, the number of variations grew significantly.

By creating the Modbus.org organization, there was an attempt to
standardize the situation to ensure interoperability.

I still do not understand, why that referenced document uses
conventions different from the RS-485 standard, such as 1000 m vs.
1200 m. or why they call the serial lines D0 and D1 instead of
RS/EIA/TIA-485 lines A and B.

To make situation worse, some manufacturers call those lines D+ and D-
and different manufacturers can't even decide which is Plus and which
is Minus, so you may have to connect D+ from one vendor to D- of an
other manufacturer and vice versa. One manufacturer uses the driver
chip manufacturer convention, while other use established
practices:-).

The original Modbus protocol only specified binaries (coil/binary
input) and 16 bit scalars (register/input registers), Since there are
needs to transfer 32 bit integers and 32 bit IEEE floats, most
manufacturers have elected to use consecutive 16 bit registers to
carry those beasts and the receiver then has to concatenate these two
registers into a single value. Unfortunately, one manufacturer puts
the most significant part into the lower numbered register, while the
other into the higher numbered register :-).

If this would not be enough to create confusion, some "Modbus
compatible" device when reading registers 5001 to 5002 might return 8
bytes (two 32 long ints/floats). To read two registers at 1001 will
return 4 bytes (two 16 bit registers).

There are enough interoperability problems without adding your own ad
hoc serial line drivers :-). For interoperability, it might be better
to solve the power issues than trying to invent something special of
your own.

[Tim Williams]

<k...@att.bizzz> wrote in message
news:m4gad85lueriqmjs5...@4ax.com...

>>Note: I don't see a spec for the FDV304P's trr. Body diodes' trr can
>>be horrendously slow--at least once upon a time on power FETs they
>>often were...
>
> Define "slow". This is the one I'm currently using (Trr=40ns) for a
> power supply. I'm going to have to go to a 60V device, though.
>
> http://www.ti.com/lit/ds/symlink/csd18501q5a.pdf

FYI, note their switching speed measurements specify "RG=0", which really
just means the figures they give are utterly meaningless.

My experience is, t_rr is roughly proportional to Vds(max), and usually
about 2-3 times the rating of the fastest junction diode of comparable
ratings.

Example:
- The above does 60V and 100A, and the body diode is specified at 25A.
There aren't any junction diodes available to compare with that, they're
all schottky. (A plain old UF4001 is rated 50V, 1A, and 50ns, but it's in
the same bracket as UF4004, which ought to be 50ns. A true, optimized
UF4001 should be quite fast indeed, basically 3-4 x 1N914 in parallel.)
- A better comparison would be made between, say, 200V, 600V and 1200V
devices. Offhand, I think the ratings for something like a 200V, 10A
MOSFET will be maybe 100ns, and a 200V, 10A diode, 50ns; at 600V 10A, more
like 250ns and 100ns; and at 1200V 10A, around 350ns and 150ns.

[Klaus Kragelund]

In the documents from Modbus.org they have contradictions in the same document. A lot of weak statements like "shall" and possibility to add power on the RJ45 connector, which seems almost non-existant in the industry

>
> I still do not understand, why that referenced document uses
>
> conventions different from the RS-485 standard, such as 1000 m vs.
>
> 1200 m. or why they call the serial lines D0 and D1 instead of
>
> RS/EIA/TIA-485 lines A and B.
>
>
>
> To make situation worse, some manufacturers call those lines D+ and D-
>
> and different manufacturers can't even decide which is Plus and which
>
> is Minus, so you may have to connect D+ from one vendor to D- of an
>
> other manufacturer and vice versa. One manufacturer uses the driver
>
> chip manufacturer convention, while other use established
>
> practices:-).
>

We have observed the same. We have a setup where we have tried different modules and in some cases we need to switch A and B

>
>
> The original Modbus protocol only specified binaries (coil/binary
>
> input) and 16 bit scalars (register/input registers), Since there are
>
> needs to transfer 32 bit integers and 32 bit IEEE floats, most
>
> manufacturers have elected to use consecutive 16 bit registers to
>
> carry those beasts and the receiver then has to concatenate these two
>
> registers into a single value. Unfortunately, one manufacturer puts
>
> the most significant part into the lower numbered register, while the
>
> other into the higher numbered register :-).
>
>

We are new to this, so we have leaned against an experienced consultanty house, to use the sensible modbus function codes. We discussed the broadcast code, but did not implement it since no error checking is possible (no response)

>
> If this would not be enough to create confusion, some "Modbus
>
> compatible" device when reading registers 5001 to 5002 might return 8
>
> bytes (two 32 long ints/floats). To read two registers at 1001 will
>
> return 4 bytes (two 16 bit registers).
>
>

During our tech scan we found a common PLC, that even did not comply to 3.5c. Users simply made workarounds for that, since it was from a major supplier.

>
> There are enough interoperability problems without adding your own ad
>
> hoc serial line drivers :-). For interoperability, it might be better
>
> to solve the power issues than trying to invent something special of
>
> your own.

We will design it to comply with the standard, supplying 1.5V during TX and 200mV trigger level during RX. We will simply use better (lower RDSon) transistors to allow for lower supply voltage.

The receiving circuit could be done just by a standard IC (only with RX functionality), so we don't need to worry to much about that part of the design

Regards

Klaus

[Klaus Kragelund]

On Saturday, December 22, 2012 9:41:35 AM UTC+1, upsid...@downunder.com wrote:
> On Fri, 21 Dec 2012 14:41:12 -0800, John Larkin
>
> <jla...@highlandtechnology.com> wrote:
>
>
>
> >>Do you need to tri-state the driver? If so, Larkin's suggestion
>
> >>doesn't work.
>
> >
>
> >Why not? Use tri-state tiny-logic drivers.
>
> >
>
> >
>
> >Even with tri-state you have to watch out for "kick"
>
> >>above/below rails.
>
> >
>
> >Kick? Logic chips can't drive transmission lines? Add some protection
>
> >if you expect lightning bolts.
>
> >
>
> >Logic chips have ESD diodes in both directions. Discretes usually
>
> >don't. You're being a jerk, as usual.
>
>
>
> Please remember, that the RS-485 specification requires -7 .. +12 V
>
> common mode voltage range, well above and below the usual 0, +5 V
>
> power supply range.
>
>
>

[snip]

We have galvanic isolation to combat common mode issues.

Regards

Klaus

[Klaus Kragelund]

I am afraid not, LVDS has to low voltage levels and common mode compliance to conform to RS485

Cheers

Klaus

[upsid...@downunder.com]

>We have galvanic isolation to combat common mode issues.

Excellent, that is what I have recommended for my customers for
decades (and most adhere to this recommendation :-).

However, since you do not have full control of the network, there
might still be large potential differences between signal line(s),
signal ground and protective ground.

Now, putting my system integrator hat on :-)

I am trying not to be un polite, but while it is a bad thing if a
point-to-point connection fails due to driver latchups, it is
_completely_unacceptable_ if such problems will stall the traffic on a
multivendor RS-485 bus !!

Please consider twice, before you are going to implement your own
discrete driver designs. As a system integrator, I would promptly
throw out such designs, or at least allocate an own serial line (with
extra cost) for such devices.

[lang...@fonz.dk]

On Dec 21, 8:11 pm, Klaus Kragelund <klausk...@hotmail.com> wrote:
> On Friday, December 21, 2012 6:16:02 PM UTC+1, John Larkin wrote:
> > On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
>

> > <klausk...@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
>
> > 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.
>
> > We recently did this:
>
> >https://dl.dropbox.com/u/53724080/Circuits/ESM/Line_Drivers.pdf
>
> > The basic line driver is a couple of tiny-logic gates driven from complementary
>
> > FPGA outputs. The downstream junk is selectable line driver equalization, to
>
> > partially correct for CAT5 cable losses. This runs up to 125 MHz.
>
> Maybe a good point, if I can find a logic device that has low RDSon at 2V.
>
> The ones I have found have 10ohms RDSon (NC7SZ74), but could parallel some of those to bring down the RDSon to the 2-3 ohms range
>
> Regards
>
> Klaus

how about something like this?

http://www.analog.com/static/imported-files/data_sheets/ADG811_812_813.pdf

-Lasse

[Jim Thompson]

On Sat, 22 Dec 2012 10:28:05 +0200, upsid...@downunder.com wrote:

>On Fri, 21 Dec 2012 14:46:15 -0800 (PST), Klaus Kragelund
><klau...@hotmail.com> wrote:
>
>>> What Modbus "standard" ?
>>>
>>> The closest that I can think as electric Modbus standard is the
>>> http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
>>> "MODBUS over serial line specification and implementation guide V1.02"
>>>
>>> Look at page 28
>>>
>>> >Line termination may be a 150 ohms value ( 0.5 W ) resistor.
>
>
>>Yes, the Modbus standard defines that, but the widespread industry
>>standard is 120 ohms and no capacitor. (adopted from the RS485 standard)
>
>I still think that you are trying to solve the wrong problem.
>
>By using some add-hoc driver design, you are most likely going to
>create much more compatibility issues with devices from various
>vendors.
>
>Since the RS-485 standard requires a +/-200 mV swing between the
>receiver terminal, with 54 ohm total load, the driver must be able to
>supply _at_lest_ +/-3.7 mA.
>
>With +/- 2V Tx voltage swing, the total loop resistance should be
>below 540 ohms, i.e 240 ohms in a single conductor, so at least 0.3 mm
>wire diameter is required for 1000 m.
>

[snip]

Which reminds me... somewhere in the basement of my mind I remember
working on a bus driver which was CURRENT-drive.

Upsidedown's comments suggest doing just that plus adding a voltage
limiter.

[John Larkin]

On Sat, 22 Dec 2012 10:41:35 +0200, upsid...@downunder.com wrote:

>On Fri, 21 Dec 2012 14:41:12 -0800, John Larkin
><jla...@highlandtechnology.com> wrote:
>
>>>Do you need to tri-state the driver? If so, Larkin's suggestion
>>>doesn't work.
>>
>>Why not? Use tri-state tiny-logic drivers.
>>
>>
>>Even with tri-state you have to watch out for "kick"
>>>above/below rails.
>>
>>Kick? Logic chips can't drive transmission lines? Add some protection
>>if you expect lightning bolts.
>>
>>Logic chips have ESD diodes in both directions. Discretes usually
>>don't. You're being a jerk, as usual.
>
>Please remember, that the RS-485 specification requires -7 .. +12 V
>common mode voltage range, well above and below the usual 0, +5 V
>power supply range.

Whether a specific system needs that much common-mode tolerance is another
issue.

>
>Since the driver is constantly connected to the bus, so while two
>other devices are communicating with each other, the common mode
>voltage can vary greatly. I hope that your ad hoc driver will not go
>into some latch-up or high protection diode leaking mode, disrupting
>the communication between other stations.
>
>I really hope that I will not encounter such substandard ad hoc
>drivers on RS-485 systems that I am responsible of.
>

At 125 MHz, 250 Mbps, it's unlikely you will.

[upsid...@downunder.com]

I usually try to analyze a point-to-point RS-422 circuit as a bipolar
current loop with at least +/- 1.7 mA loop current through the 120 ohm
receiver termination resistance. Compare this to the unipolar 0..20 mA
(or even 0..60 mA) Teletype era unipolar current loops. RS-485
multidrop circuits are a bit more complicated.

At higher data rates, the bus must be analyzed as a section of (more
or less) matched transmission line.

[upsid...@downunder.com]

On Sat, 22 Dec 2012 07:51:27 -0800, John Larkin
<jjla...@highNOTlandTHIStechnologyPART.com> wrote:

>>Please remember, that the RS-485 specification requires -7 .. +12 V
>>common mode voltage range, well above and below the usual 0, +5 V
>>power supply range.
>
>Whether a specific system needs that much common-mode tolerance is another
>issue.
>

In countries using the IEC TN-C or TN-C-S mains wiring conventions,
this is a day to day issue.

If there is a 4 Vrms voltage drop in the neutral conductor, the
potential difference between grounded sockets ground terminal can be
more than 7 Vpeak, thus causing harm to data transfer.

[Joerg]

miso wrote:
> Is it possible the VC is going to stupid internet social media garbage?
> Ya think?
>

In part, yes. Med has become less attractive, social media is all the
rage. Different investors though but that's where the money flows to.
Well, the money that's not kept piled in money market funds.

> Why build a market for a hardware device, which hey, is work, when you
> can sell nonsense. The current mania is photographs that disappear, when
> it used in sexting. Hey, I know of a few congressmen who could have used
> such a service.
>

Social media is the next bubble that will go *KABLAM* on the financial
markets.

I herewith predict that :-)

[Joerg]

Datasheets aren't what they used to be, lots of specs lacking. The
question that needs to be pondered though is, does trr really matter in
Klaus' case? RS485 isn't exactly like a Maserati so even if ringing
pings the body diodes a little it probably won't matter.

[Joerg]

There could be hope:

http://www.electronicsweekly.com/Articles/13/07/2012/54115/intersil-has-rs-485-transceiver-running-off-1.8v.htm

Maybe give them a ring but then I'd also check for availability.

[whit3rd]

On Friday, December 21, 2012 3:02:40 AM UTC-8, Klaus Kragelund wrote:

> The standard RS485 drivers available has a minimum voltage of 3V and a rarther large drop voltage when loaded with the defined bus load ...

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

RS-485 is a multidrop bus, with termination resistors; do you control
the termination resistors, or are they external to your design?

Your 'supply down to 2V' circuitry will have to be capable of safely handling the RS-485 bus
signal range, -7V to +12V, or you can discard the standard entirely, and use something
more appropriate to low-power implementation.

[Klaus Kragelund]

Yes, I have been down that road. The one you refer to here, has very good latchup properties (over 300mA), and that sure beats what I have found sofar :-)


Regards

Klaus

[upsid...@downunder.com]

On Sat, 22 Dec 2012 09:08:51 -0800, Joerg <inv...@invalid.invalid>
wrote:

I must say, I am really impressed by those specs.

However, you have to play the Devil's advocate to select a usable
product.

A quick look suggests that you have to use at least Vcc > 3.0 V to be
within RS-485 common mode range. I have not looked at other
parameters.

[Klaus Kragelund]

Very likely not, like Tim pointed out.

Our max speed is 115k, which corresponds to 9us. The drivers are allowed to drift by 2%, so for 11 bits, that would be a single character drift at the end of the bit stream of close to 25% from the ideal mid bit sampling. So it could probably tolerate plenty of ringing after the bit transition.

Some UARTS today implement averaging, oversampling the RX by 8 to 16 times, so ringing can affect the data quality closer to the transition, but nowhere near the 100ns switching times as discussed

Regards

Klaus

[Klaus Kragelund]

Actually the device we are using now is an Intersil part and we have had the FAE visit and in direct contact with the design engineers. They suggested that part, but it only works at 1.8V with no load (no termination resistors)

Cheers

Klaus

[Klaus Kragelund]

On Saturday, December 22, 2012 8:58:39 PM UTC+1, whit3rd wrote:
> On Friday, December 21, 2012 3:02:40 AM UTC-8, Klaus Kragelund wrote:
>
>
>
> > The standard RS485 drivers available has a minimum voltage of 3V and a rarther large drop voltage when loaded with the defined bus load ...
>
> > 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.
>
>
>
> RS-485 is a multidrop bus, with termination resistors; do you control
>
> the termination resistors, or are they external to your design?
>

No, that is up to the system configurator/responsible

>
>
> Your 'supply down to 2V' circuitry will have to be capable of safely handling the RS-485 bus
>
> signal range, -7V to +12V, or you can discard the standard entirely, and use something
>
> more appropriate to low-power implementation.

As long as I supply minimum 1.5V (A-B or B-A) within the compliance range, I should be ok.

Since I have galvanic isolation the output (TX) should be well behaved. As for the RX I will use a commercial part for the detection that has the required compliance.

Cheers

Klaus

[dagmarg...@yahoo.com]

On Dec 22, 12:15 am, k...@att.bizzz wrote:
> On Fri, 21 Dec 2012 19:06:43 -0800 (PST), dagmargoodb...@yahoo.com

> wrote:
>
> >On Dec 21, 3:48 pm, Joerg <inva...@invalid.invalid> wrote:
> >> Klaus Kragelund wrote:
> >> > On Friday, December 21, 2012 7:12:56 PM UTC+1, Joerg wrote:
>
> >> >> Just a comment: Diodes are already in the FETs, in the form of body diodes.
>
> >> > Yes, I added parallel more sturdy diodes, to direct the current away from the low current body diodes.
>
> >> Usually they are about as sturdy as the channel in the FET, can take a
> >> similar current.
>
> >Note: I don't see a spec for the FDV304P's trr.  Body diodes' trr can
> >be horrendously slow--at least once upon a time on power FETs they
> >often were...
>

> Define "slow".  This is the one I'm currently using (Trr=40ns) for a
> power supply.  I'm going to have to go to a 60V device, though.
>
> http://www.ti.com/lit/ds/symlink/csd18501q5a.pdf

40nS is fast. Slow? Well, if they don't specify, you've got to
measure. I don't remember the figure, but I got burned on a proto
trying to use a body diode as a flyback rectifier once upon a time.
It worked, but it got HOT and wasted a lot of power. A schottky fixed
it.

--
Cheers,
James Arthur

[dagmarg...@yahoo.com]

On Dec 22, 1:37 am, miso <m...@sushi.com> wrote:
> Is it possible the VC is going to stupid internet social media garbage?
> Ya think?
>

> Why build a market for a hardware device, which hey, is work, when you
> can sell nonsense. The current mania is photographs that disappear, when
> it used in sexting. Hey, I know of a few congressmen who could have used
> such a service.

Sounds like a weiner^H^H^H^Hinner!

--
Cheers,
James Arthur

[dagmarg...@yahoo.com]

My basic assumption is that if a MOSFET's trr isn't spec'd, it's
probably not good. If they do spec it, then there's nothing to worry
about.

I've seen they're making lots of the big FETs' body diodes fast these
days, I'm just not sure about the little guys, like Klaus' FDV30P.
Anyway, he's got clamp diodes; my point was that he might well need
them.

--
Cheers,
James Arthur

[dagmarg...@yahoo.com]

On Dec 22, 3:53 pm, Klaus Kragelund <klausk...@hotmail.com> wrote:
> On Saturday, December 22, 2012 5:48:56 PM UTC+1, Joerg wrote:

Good point. Agreed. So, if you forge ahead, you might be able to
save a few clamp diodes.

--
Cheers,
James Arthur

[k...@att.bizzz]

On Sun, 23 Dec 2012 06:33:31 -0800 (PST), dagmarg...@yahoo.com
wrote:

Well, the body diode is a Si P-N junction so it's going to be .7-1V,
vs the .3-.5ish for the Schottky. The Schottky saves energy? Well,
yeah. So does turning on the FET (Vf*Id < Rds(on) * Id^2). ;-)

[eat...@dropdead.com]

On Fri, 21 Dec 2012 18:57:52 +0200, upsid...@downunder.com wrote:

>On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
><klau...@hotmail.com> wrote:
>
>>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
>

>This is not a Modbus specific issue, but rather RS-485 specific issue
>with a twisted pair bus with characteristic impedance of 100-120 ohms.
>In order to avoid reflections at the open ends of the bus cable,
>termination resistors are typically used at both ends with the same
>value as the cable characteristic impedance.
>
>For DC, those two resistors are effectively in parallel and hence the
>45 ohm total load.
>
>However, those termination resistors are needed only to avoid the
>reflections from voltage _transitions_. Thus, putting a capacitor in
>series with the termination resistor(s) should reduce the idle power
>consumption, when no data is being sent. Of course, without DC
>continuity, the end to end signal ground conductor is essential.
>
>There are application notes describing even more elaborate termination
>methods, describing their advantages and disadvantages. You should
>also look for various termination techniques used on CAN bus (which is
>essentially RS-485).
>

I will get back to you after i reread some of my TIA-485 standard. I
don't think you understand it properly.

?-)

[John S]

The reason that you do not understand it is that you eat too much shit.

[Jim Thompson]

On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
<klau...@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

[om...@omegacs.net]

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

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

[upsid...@downunder.com]

On Sat, 17 Aug 2013 13:39:54 -0700 (PDT), om...@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.

[Joerg]

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

[om...@omegacs.net]

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

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

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.

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

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

[upsid...@downunder.com]

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

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

[John Larkin]

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

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.

[Joe Gwinn]

In article <iou119h31ldueksiq...@4ax.com>, John Larkin

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

[Joerg]

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

[josephkk]

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

?-)

[John Larkin]

On 19 Aug 2013 00:33:03 GMT, josephkk <joseph_...@sbcglobal.net> wrote:

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

485 is an electrical logic-level spec; it says nothing about encoding or
protocols.

[josephkk]

On Sun, 18 Aug 2013 20:21:01 -0700, John Larkin wrote:


>>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.
>
> 485 is an electrical logic-level spec; it says nothing about encoding or
> protocols.
>

Do you have a copy, I do.

?-)

[John Larkin]

On 19 Aug 2013 20:18:55 GMT, josephkk <joseph_...@sbcglobal.net>
wrote:

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.


--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

VME thermocouple, LVDT, synchro acquisition and simulation

[josephkk]

On Mon, 19 Aug 2013 13:50:30 -0700, John Larkin wrote:

> On 19 Aug 2013 20:18:55 GMT, josephkk <joseph_...@sbcglobal.net>
> wrote:
>
>>On Sun, 18 Aug 2013 20:21:01 -0700, John Larkin wrote:
>>
>>
>>>>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.
>>>
>>> 485 is an electrical logic-level spec; it says nothing about encoding
>>> or protocols.
>>>
>>>
>>Do you have a copy, I do.
>>
>>?-)
>
> 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?

?-))

[John Larkin]

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.

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

Deprecates? How so?

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

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.

What sort of data encoding do you read the spec as allowing? Async ASCII at 110
baud?

>
>Perhaps you are just a bully?
>

Bully? All my comments were technical. You have just gone personal.

--

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

[josephkk]

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.

>
>>Perhaps you are just a bully?
>>
>>
> 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?

?-))

[John Devereux]

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!

>> 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.
>>
>>>Perhaps you are just a bully?
>>>
>>>
>> 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?

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:

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

What precisely is there to disagree with in that?


--

John Devereux

[om...@omegacs.net]

On Sunday, August 18, 2013 1:20:57 PM UTC-7, Joerg wrote:
> 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 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.

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

[Joerg]

om...@omegacs.net wrote:
> On Sunday, August 18, 2013 1:20:57 PM UTC-7, Joerg wrote:
>> 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?
>

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.

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

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.

>> Slow-mode can be a problem with such piggy-back schemes.
> 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.

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


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

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.

>> That sounds like the "bus from hell" :-)
> Yeah, that's why work on the TDR subsystem has been put off for now.
>

But it's fun :-)

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

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.

[upsid...@downunder.com]

On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), om...@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.

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.

[Joerg]

upsid...@downunder.com wrote:
> On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), om...@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.

[upsid...@downunder.com]

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

>upsid...@downunder.com wrote:
>> On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), om...@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.

[whit3rd]

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

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.

[Joerg]

upsid...@downunder.com wrote:
> On Sat, 31 Aug 2013 09:41:48 -0700, Joerg <inv...@invalid.invalid>
> wrote:
>
>> upsid...@downunder.com wrote:
>>> On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), om...@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.

[om...@omegacs.net]

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

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

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

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

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

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

[om...@omegacs.net]

On Saturday, August 31, 2013 12:10:54 AM UTC-7, upsid...@downunder.com wrote:
> 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 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 at 1Mbps or better using the existing UART pins and packet protocols I've got, I'd be all over that.

[om...@omegacs.net]

On Saturday, August 31, 2013 12:59:28 PM UTC-7, upsid...@downunder.com wrote:
> 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 that 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 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.

[upsid...@downunder.com]

On Tue, 3 Sep 2013 20:57:17 -0700 (PDT), om...@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).

[Joerg]

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

[om...@omegacs.net]

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 and sink values for the high and low sides, you'd think the two FET pairs would be the same. OTOH I guess that difference could be used to my advantage.

> Best way to go on a project like this.

Yeah, I just have to convince them that even though it looks like a step backward, 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 that 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 driver's RE in turn to increase the number of stations listening. All 6 units 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 unacceptable pretty quickly. I think the point where packet loss became significant 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 the signal and have units automatically loop it back. Seems to me the problem is a) there'd be too much latency between the receive and re-transmit, and b) the retransmitted signal might end up causing feedback all over the place.

> 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 currently unused, but I could use that to drive and sync a multitone protocol if there'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,
> 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 ;-(

> 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' LED to one side of that, and 2x 2x7 0.5mm connectors on the bottom opposite sides. The rest of the board is free for all this stuff, albeit with serious height restrictions. 3mm up and maybe 1.5mm against the parts on the bottom side board.