Discrete custom design of RS485 driver

omega@omegacs.net wrote:
> 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.
> 

It has to do with the IC process. If they make the devices the same size
they will be different in on-resistance because one of them is
p-channel. They could upsize to make it equal but chip real estate is a
cost factor.

One thing to note is that many gate drivers cannot be put into a hi-Z
state on their outputs which makes then not so attractive for RS485.


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

That's an advantage of being a consultant. I just roll up the sleeves
and build it :-)


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

To be honest, I do not see any gradual decay. I'd be surprised if it
happened because normally what matters is the parasitic device
capacitance and that should be independent of any receive enable.

I like this one here:

http://colo.omegacs.net/

:-)


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

It can work. The trick is to high-pass the feedback so only the sluggish
transitions get spiffed up but the remainder of each high or low phase
remains largely untouched. It requires brief current injections from a
circuit that goes hi-Z after each injection. Use a blazingly fast buffer
to keep the latency down.

Keeping all that from going berserk (oscillations, chain-bucking,
stampeding) isn't a small feat but if it works you are the hero of them
month.

Much of this can be simulated in SPICE but it will take time. It's not
something you can draw up on a napkin while wolfing down a burger and be
done with it.


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

It would need to run at several MHz at the least if you need 1Mbit/sec.
That can become tedious if you must run that inside a uC with rather
limited horsepower.

It doesn't even have to be PLL. You can send, for example, two
frequencies around 10MHz but at least 4MHz apart. Lowpass and Schmitt
this, then run the RX signal into a timer which counts the number of uC
master clock cycles between transitions. Average a little for noise
reduction and signal an error if this changes too often. The timer count
would say whether a one or a zero was received.


>> 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 ;-(
> 

This is kind of hard to explain. An open transformer has a certain
primary inductance, which results in:

   Z  =  2 * Pi * f * L

where f is the lowest frequency you Manchester code presents to it. The
old rule of thumb for point-to-point transmission is that you want Z to
be 400ohms or higher for a 100ohm line. In you case you'd rather want it
to be 10k or so. That isn't easy but may be possible. One way to start
is to browse

For example, this series fulfills your 3mm height limit and gets you to
about 1k at 1MHz or (theoretically) 10k at 10MHz:

http://www.tdk.co.jp/tefe02/trans_alt_en.pdf

Now the rather high interwidning capacitance might spoil the broth here
but you could buy a few different kinds of such transformers and just
try. It allows you to keep things as differential as possible.

LAN transformers might also work but you'd have to try it out:

http://productfinder.pulseeng.com/products/datasheets/H504.pdf

Just an example, and this is a wider 4-channel. So you'd have to call
them and ask for something smaller. Often you can latch on to a custom
run. I have sometimes done that for the ferrite cores, sort of hitching
a ride.


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


I don't see the height restriction being an obstacle here, as long as
you can sprinkle parts around.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Wednesday, September 4, 2013 10:26:28 AM UTC-7, Joerg wrote:
> One thing to note is that many gate drivers cannot be put into a hi-Z
> state on their outputs which makes then not so attractive for RS485.

Right, and I'm assuming putting a silicon switch of any sort in front of it=
 really won't be of much help on the signal-integrity side.

> To be honest, I do not see any gradual decay. I'd be surprised if it
> happened because normally what matters is the parasitic device
> capacitance and that should be independent of any receive enable.

You're letting it animate?  Each frame is an additional receiver.  The test=
 was to determine if the loading of the receive circuit was what caused the=
 problem, or the power draw of the units.  At least for the max13451, it do=
es indeed reduce bus loading by having RE disabled.

Then again that's why I designed my theoretical testbed so I can separate p=
ower and data loading...

> I like this one here:
> http://colo.omegacs.net/

Yeah, it's just kindof a dump space for me, though it does run some other v=
irtual sites.

> It can work. The trick is to high-pass the feedback so only the sluggish=
=20
> transitions get spiffed up but the remainder of each high or low phase
> remains largely untouched. It requires brief current injections from a
> circuit that goes hi-Z after each injection. Use a blazingly fast buffer
> to keep the latency down.

Sounds rather scary...

> Much of this can be simulated in SPICE but it will take time. It's not
> something you can draw up on a napkin while wolfing down a burger and be
> done with it.

I *really* want a SPICE simulation of the bus and transceivers, but haven't=
 been able to get anywhere near something that seems to actually simulate r=
eality. ;-(  One of the bigger problems is a lack of any RS-485 transceiver=
 simulations that I can find.

> It doesn't even have to be PLL.

I only mention the PLL because it's already there and can give me whatever =
frequency I ask for.  It's already driving the MCU and the main ADC, and ha=
d extra outputs...

> It would need to run at several MHz at the least if you need 1Mbit/sec.
> That can become tedious if you must run that inside a uC with rather
> limited horsepower.

> You can send, for example, two
> frequencies around 10MHz but at least 4MHz apart. Lowpass and Schmitt
> this, then run the RX signal into a timer which counts the number of uC
> master clock cycles between transitions. Average a little for noise
> reduction and signal an error if this changes too often. The timer count
> would say whether a one or a zero was received.

Did some digging around, actually think I could fairly easily do OOK with a=
 simple receiver, as per:

http://www.maximintegrated.com/app-notes/index.mvp/id/4439

Would need a differential-to-singleended buffer between the bus and that, b=
ut if I can drive a 10-50MHz signal in OOK mode and get a viable digital ou=
tput from the above, I think I'd be done.  Transmit wouldn't have to be com=
plicated, just be filtered enough so it doesn't have square-wave generated =
nasties.

The trick is I'm already pretty much locked into a UART on the microcontrol=
ler board, so doing pulse-counting and such isn't really an option without =
adding a dedicated microcontroller on the interface PCB.

omega@omegacs.net wrote:
> On Wednesday, September 4, 2013 10:26:28 AM UTC-7, Joerg wrote:
>> One thing to note is that many gate drivers cannot be put into a
>> hi-Z state on their outputs which makes then not so attractive for
>> RS485.
> 
> Right, and I'm assuming putting a silicon switch of any sort in front
> of it really won't be of much help on the signal-integrity side.
> 

Oh, it will be. But now you need another device with low on-resistances
and thus lots of parasitic capacitance, plus the space for it. So maybe
some big fat bus drivers with lots of the channels parallele are better
because those can be tri-stated. That would at least get you under
10ohms foer four in parallel, and maybe for the upper two equalizer
stages you only need two each.


>> To be honest, I do not see any gradual decay. I'd be surprised if
>> it happened because normally what matters is the parasitic device 
>> capacitance and that should be independent of any receive enable.
> 
> You're letting it animate?  Each frame is an additional receiver.


Ah, didn't know it animated. In the browser it won't do that but now I
stored it on the PC and ... tada!


> The test was to determine if the loading of the receive circuit was
> what caused the problem, or the power draw of the units.  At least
> for the max13451, it does indeed reduce bus loading by having RE
> disabled.
> 

Interesting, normally RE only controls the receiver output towards the
system side. The MAX13451 datasheet is not very helpful, doesn't even
mention capacitance.

Unfortunately A and B for RX and TX are tied together on the chip. If
you had one where the bus sides are piped out independently you could
hang RF transistors in front in order to get the bus load capacitance down.


> Then again that's why I designed my theoretical testbed so I can
> separate power and data loading...
> 
>> I like this one here: http://colo.omegacs.net/
> 
> Yeah, it's just kindof a dump space for me, though it does run some
> other virtual sites.
> 
>> It can work. The trick is to high-pass the feedback so only the
>> sluggish transitions get spiffed up but the remainder of each high
>> or low phase remains largely untouched. It requires brief current
>> injections from a circuit that goes hi-Z after each injection. Use
>> a blazingly fast buffer to keep the latency down.
> 
> Sounds rather scary...
> 

All the good stuff sounds scary in the beginning. A good friend of mine
(and also a client) said once, "The best projects are those where,
immediately after making a claim, you get a serious knot in the stomach".

The MAX13451 is a bit sluggish for this with its 200nsec RX prop delay.
Don't know what else they have since I never use Maxim chips. But, just
as an example, this one is already twice as fast:

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

These are blazingly fast and have very low input capacitance, I'd try
something like that:

http://www.linear.com/docs/1001

Here's where your test bed would come in real handy.


>> Much of this can be simulated in SPICE but it will take time. It's
>> not something you can draw up on a napkin while wolfing down a
>> burger and be done with it.
> 
> I *really* want a SPICE simulation of the bus and transceivers, but
> haven't been able to get anywhere near something that seems to
> actually simulate reality. ;-(  One of the bigger problems is a lack
> of any RS-485 transceiver simulations that I can find.
> 

Ask Linear Technology if they have a model or even a jig for one of
their fast RS485 chips. They also got 60V fault-tolerant ones. Sometimes
only IBIS models though :-(

Else you could just take the capacitances and see if you can find
similar FETs to drive it. As soon as you can corroborate the effect in
your animated scope plots you are in business. Then you can try the
various measures, see how much each buys you.


>> It doesn't even have to be PLL.
> 
> I only mention the PLL because it's already there and can give me
> whatever frequency I ask for.  It's already driving the MCU and the
> main ADC, and had extra outputs...
> 

Sometimes they aren't very versatile or fast though.


>> It would need to run at several MHz at the least if you need
>> 1Mbit/sec. That can become tedious if you must run that inside a uC
>> with rather limited horsepower.
> 
>> You can send, for example, two frequencies around 10MHz but at
>> least 4MHz apart. Lowpass and Schmitt this, then run the RX signal
>> into a timer which counts the number of uC master clock cycles
>> between transitions. Average a little for noise reduction and
>> signal an error if this changes too often. The timer count would
>> say whether a one or a zero was received.
> 
> Did some digging around, actually think I could fairly easily do OOK
> with a simple receiver, as per:
> 
> http://www.maximintegrated.com/app-notes/index.mvp/id/4439
> 
> Would need a differential-to-singleended buffer between the bus and
> that, but if I can drive a 10-50MHz signal in OOK mode and get a
> viable digital output from the above, I think I'd be done.  Transmit
> wouldn't have to be complicated, just be filtered enough so it
> doesn't have square-wave generated nasties.
> 

I'd be careful. OOK is very prone to distrubance by noise, spikes and
transients. If you use a nice bandpass filter and can make sure that it
will always be quiet within the range of that bandpass it can work ok.
Tough to find off-the-shelf ones in the 30-80MHz range anymore, on
account of TV sets having gone digital.


> The trick is I'm already pretty much locked into a UART on the
> microcontroller board, so doing pulse-counting and such isn't really
> an option without adding a dedicated microcontroller on the interface
> PCB.


Ok, that rules out nearly all unorthodox stuff.

I'd first try with some of the more modern (as in faster) RS485 driver
chips.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Wednesday, September 4, 2013 5:54:40 PM UTC+2, om...@omegacs.net wrote:
> On Wednesday, September 4, 2013 7:26:22 AM UTC-7, Joerg wrote:
>=20
> > http://www.irf.com/product-info/datasheets/data/pb-ir3598.pdf.
>=20
>=20
>=20
> 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 advant=
age.
>=20
>=20
>=20
> > Best way to go on a project like this.
>=20
>=20
>=20
> 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 d=
on't have the insane density and collection of hard-to-hand-assemble parts =
that I have to work with now.
>=20
>=20
>=20
> > One of the tasks at hand is to minimize this added capacitance.
>=20
>=20
>=20
> Yeah, I can clearly watch the effects as I add more units to the bus:
>=20
>=20
>=20
> http://colo.omegacs.net/~omega/misc/disable-0to6-stations.gif
>=20
>=20
>=20
> 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 un=
its 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 u=
nacceptable pretty quickly.  I think the point where packet loss became sig=
nificant was about 7-8 units.
>=20
>=20

Very nice animation. But, I cannot see why you are worried that is looks "u=
gly". As long as you have minimum 200mV A-B with additional margin, you are=
 within bounds

Cheers

Klaus

On Wednesday, September 4, 2013 12:59:34 PM UTC-7, Klaus Kragelund wrote:

> Very nice animation. But, I cannot see why you are worried that is looks "ugly". As long as you have minimum 200mV A-B with additional margin, you are within bounds

Two reasons:

- the "sag" at the edges gets worse, and longer.  My target is more like 25-50 units, not 6.  <200mV is only a few units further along.

- at least with the transceiver that was done with (iirc max13451), those sags turn into spurious transitions, which blows the UART out of the water.

On Wednesday, September 4, 2013 12:41:46 PM UTC-7, Joerg wrote:
> Oh, it will be. But now you need another device with low on-resistances
> and thus lots of parasitic capacitance, plus the space for it. So maybe
> some big fat bus drivers with lots of the channels parallele are better
> because those can be tri-stated. That would at least get you under
> 10ohms foer four in parallel, and maybe for the upper two equalizer
> stages you only need two each.

Yeah, and that gets back to my original idea of being able to filter each o=
f the stages separately and mix&match as needed.

> Unfortunately A and B for RX and TX are tied together on the chip. If
> you had one where the bus sides are piped out independently you could
> hang RF transistors in front in order to get the bus load capacitance dow=
n.
> Here's where your test bed would come in real handy.

I've got a board designed for standard RS-485 testing with 2 half-duplex 75=
176 sites, 1 full-duplex SOIC-8 site, and a 75180 SOIC-14 full-duplex site.=
  Each transmit and receive chain can have its own separate capacitive coup=
ling or be tied to a single bus, and I can zerohm any combination of transm=
it and receive I can come up with.

> Sometimes they aren't very versatile or fast though.

This one's a TI CDCE949 packaged with a matching crystal (sadly no longer i=
n production, so I've got to go discrete soon).  I can spit just about any =
frequency I could possibly want up to 230MHz, and one of the 4 PLLs is enti=
rely dedicated to interface.

> I'd be careful. OOK is very prone to distrubance by noise, spikes and
> transients. If you use a nice bandpass filter and can make sure that it
> will always be quiet within the range of that bandpass it can work ok.
> Tough to find off-the-shelf ones in the 30-80MHz range anymore, on
> account of TV sets having gone digital.

The appnote also mentioned ASK, which is just a different threshold for the=
 power detector.  That would eliminate some of the issues wouldn't it?

> Ok, that rules out nearly all unorthodox stuff.

I guess I should be more specific: I'm stuck with a UART, but I've got the =
rest of the 'port' plus a shared I2C bus to work with.  An Xmega port has 8=
 bits, 2 timers with 6 PWM/capture, 2 UARTs, 1 SPI, and sometimes an I2C (d=
epending on which port it is).

> I'd first try with some of the more modern (as in faster) RS485 driver
> chips.

My boss's theory was that the faster the edge, the more likely it was to "b=
ounce" and produce the sag seen in the animation.

omega@omegacs.net wrote:
> On Wednesday, September 4, 2013 12:41:46 PM UTC-7, Joerg wrote:

[...]


>> Unfortunately A and B for RX and TX are tied together on the chip.
>> If you had one where the bus sides are piped out independently you
>> could hang RF transistors in front in order to get the bus load
>> capacitance down. Here's where your test bed would come in real
>> handy.
> 
> I've got a board designed for standard RS-485 testing with 2
> half-duplex 75176 sites, 1 full-duplex SOIC-8 site, and a 75180
> SOIC-14 full-duplex site.  Each transmit and receive chain can have
> its own separate capacitive coupling or be tied to a single bus, and
> I can zerohm any combination of transmit and receive I can come up
> with.
> 

Then you can also try and see how it looks with two emitter followers in
front of the RX. Just for a test.


>> Sometimes they aren't very versatile or fast though.
> 
> This one's a TI CDCE949 packaged with a matching crystal (sadly no
> longer in production, so I've got to go discrete soon).  I can spit
> just about any frequency I could possibly want up to 230MHz, and one
> of the 4 PLLs is entirely dedicated to interface.
> 

That is, of course, the deluxe method. Sure it's discontinued? Doesn't
says so on the datasheet or Digikey.


>> I'd be careful. OOK is very prone to distrubance by noise, spikes
>> and transients. If you use a nice bandpass filter and can make sure
>> that it will always be quiet within the range of that bandpass it
>> can work ok. Tough to find off-the-shelf ones in the 30-80MHz range
>> anymore, on account of TV sets having gone digital.
> 
> The appnote also mentioned ASK, which is just a different threshold
> for the power detector.  That would eliminate some of the issues
> wouldn't it?
> 

Yes, but not nearly as well as FSK would.


>> Ok, that rules out nearly all unorthodox stuff.
> 
> I guess I should be more specific: I'm stuck with a UART, but I've
> got the rest of the 'port' plus a shared I2C bus to work with.  An
> Xmega port has 8 bits, 2 timers with 6 PWM/capture, 2 UARTs, 1 SPI,
> and sometimes an I2C (depending on which port it is).
> 

Each port? So then we do have a timer to work with. That could open up
an FSK option provided an XMega is fast enough. All I know so far are
ATMega, I am not really a uC guy.


>> I'd first try with some of the more modern (as in faster) RS485
>> driver chips.
> 
> My boss's theory was that the faster the edge, the more likely it was
> to "bounce" and produce the sag seen in the animation.


He is correct. But one could, for example, make sure that the signal
gets filtered at the end of each high or low phase. What this requires
is a clock recovery by the XMega so it knows where to sample.

Looking again at your animated scope plot it becomes apparent that
capacitance is the problem. There is a break in the middle and as more
devices come online you can see the slope increase in that stretch,
where the purple signal is low. If you could reduce the input
capacitance that should improve things a lot.

-- 
Regards, Joerg

http://www.analogconsultants.com/

omega@omegacs.net wrote:
> On Wednesday, September 4, 2013 12:59:34 PM UTC-7, Klaus Kragelund
> wrote:
> 
>> Very nice animation. But, I cannot see why you are worried that is
>> looks "ugly". As long as you have minimum 200mV A-B with additional
>> margin, you are within bounds
> 
> Two reasons:
> 
> - the "sag" at the edges gets worse, and longer.  My target is more
> like 25-50 units, not 6.  <200mV is only a few units further along.
> 
> - at least with the transceiver that was done with (iirc max13451),
> those sags turn into spurious transitions, which blows the UART out
> of the water.


Another idea. I know it's nashty nashty:

Place inductors in series with A and B to each transceiver. They'll
resonate a bit with the parasitic capacitances and can act as a
"peaker". Start with 2.2uH each. Go higher if not enough but watch that
no abs max values get exceeded, especially if something comes off.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Wednesday, September 4, 2013 2:37:05 PM UTC-7, Joerg wrote:
> That is, of course, the deluxe method. Sure it's discontinued? Doesn't
> says so on the datasheet or Digikey.

It's the combined package, the Pletronics FD77T that's discontinued.  I get=
 to try to fit the chip and a crystal on the next rev of board, and hope I =
can find a crystal that actually gives me the pull range I get from the mat=
ched part.

> Yes, but not nearly as well as FSK would.

But FSK would require discriminators for both frequencies.  If that can be =
done in a small space, it seems reasonable.  In particular the PLL is capab=
le of switching its config registers on an external input, so I could tie t=
he UART Tx to that control and have the PLL switch between two frequencies =
easily enough. (albeit with a rev of the other boards in the stack...)

> Each port? So then we do have a timer to work with. That could open up
> an FSK option provided an XMega is fast enough. All I know so far are
> ATMega, I am not really a uC guy.

If I ran a counter from a peak detector, I'd still have to sample it at som=
e useful point, which could be hard to track down.  Otherwise I'd have to p=
erform the frequency-counter work at a reasonable UART oversampling rate, e=
.g. 8x or 16x.  That would very severely limit the functional baud rate.

I suppose a CLPD could be programmed with a similar arrangement, counting c=
ycles between peaks and setting its output based on a threshold (1/f), capa=
ble of directly feeding the UART.

> Looking again at your animated scope plot it becomes apparent that
> capacitance is the problem. There is a break in the middle and as more
> devices come online you can see the slope increase in that stretch,
> where the purple signal is low. If you could reduce the input
> capacitance that should improve things a lot.

To what degree does the value of the series coupling caps matter?

I'll look into the ltc1685 you mentioned before, since you said it looks to=
 have lower input loading characteristics.

omega@omegacs.net wrote:
> On Wednesday, September 4, 2013 2:37:05 PM UTC-7, Joerg wrote:

[...]

> 
>> Yes, but not nearly as well as FSK would.
> 
> But FSK would require discriminators for both frequencies.  If that
> can be done in a small space, it seems reasonable.  In particular the
> PLL is capable of switching its config registers on an external
> input, so I could tie the UART Tx to that control and have the PLL
> switch between two frequencies easily enough. (albeit with a rev of
> the other boards in the stack...)
> 

That would take care of the TX side. Although it can be done simpler by
using a counter. The frequency doesn't have to be very exact.


>> Each port? So then we do have a timer to work with. That could open
>> up an FSK option provided an XMega is fast enough. All I know so
>> far are ATMega, I am not really a uC guy.
> 
> If I ran a counter from a peak detector, I'd still have to sample it
> at some useful point, which could be hard to track down.  Otherwise
> I'd have to perform the frequency-counter work at a reasonable UART
> oversampling rate, e.g. 8x or 16x.  That would very severely limit
> the functional baud rate.
> 

The sampling would be the counter output at each peak. Say, the counter
ran at 32MHz or whatever you have. When the signal sits at 5MHz you'd
see 6-7 counts between detected peaks. Assume the other signal is 12MHz,
there you'd only see 2-4 counts. One represents high, the other low.
Sort of a poor-man's FSK decoder. The uC would have to stuff the result
of this determination back into the UART, hoping there is a path to do that.

It would be good to lowpass the signal somewhere, maybe 20MHz, so that
odd reflections won't produce any extra counts. Even simple RC filtering
might work.


> I suppose a CLPD could be programmed with a similar arrangement,
> counting cycles between peaks and setting its output based on a
> threshold (1/f), capable of directly feeding the UART.
> 

Yep, but if the port already has counters why not use them?


>> Looking again at your animated scope plot it becomes apparent that 
>> capacitance is the problem. There is a break in the middle and as
>> more devices come online you can see the slope increase in that
>> stretch, where the purple signal is low. If you could reduce the
>> input capacitance that should improve things a lot.
> 
> To what degree does the value of the series coupling caps matter?
> 

This seems to be the capacitive load between A and B that increases with
the number of stations. It's not in series.


> I'll look into the ltc1685 you mentioned before, since you said it
> looks to have lower input loading characteristics.


Yeah, would be nice to have a simple solution if possible.

-- 
Regards, Joerg

http://www.analogconsultants.com/