> [possibly dupe response, not sure if my first attempt actually posted]
>
> On Wednesday, September 4, 2013 4:14:04 PM UTC-7, Joerg wrote:
>> 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.
>
> But it's handy ;-) Although if I end up using a CPLD I'd probably use the PLL as a master clock and generate from there, since that would remove the need to change anything on the existing microcontroller PCB.
>
>> 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.
>
> Problem is, there really isn't. There are frequency-counter modes available, but stuff still has to go through the registers. I'd have to have a second timer fire an ISR to read and reset the edge counter, threshold it, and output it to a pin (looped back into the UART). To do that for 1Mbaud with 8x oversampling I'd have 4 clock cycles to do that in, which is how much time it takes just to *start* running an ISR.
>
>> Yep, but if the port already has counters why not use them?
>
> If they can be arranged to work properly, sure ;-)
That looks like the usual scenario. A uC has all the bells and whistles
but they can only be linked to over here, not over yonder. And not on
Sundays.
That would leave the sledge hammer method, pressing some sort of PLL
chip into service. For example, if you feed it 8.5MHz or so from a
counter (any counter) in the uC on the clock input and then the bus
signal on the RF input you could use 5MHz for space and 12MHz for mark.
Or something like that. The old 74HC4046 usually goes to around 15MHz
but only at 5V supply. But there are better ones.
Figure 14 here has another interesting method:
http://www.ti.com/lit/an/scha002a/scha002a.pdf
--
Regards, Joerg
http://www.analogconsultants.com/
Reply by ●September 4, 20132013-09-04
[possibly dupe response, not sure if my first attempt actually posted]
On Wednesday, September 4, 2013 4:14:04 PM UTC-7, Joerg wrote:
> 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.
But it's handy ;-) Although if I end up using a CPLD I'd probably use the =
PLL as a master clock and generate from there, since that would remove the =
need to change anything on the existing microcontroller PCB.
> 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 th=
at.
Problem is, there really isn't. There are frequency-counter modes availabl=
e, but stuff still has to go through the registers. I'd have to have a sec=
ond timer fire an ISR to read and reset the edge counter, threshold it, and=
output it to a pin (looped back into the UART). To do that for 1Mbaud wit=
h 8x oversampling I'd have 4 clock cycles to do that in, which is how much =
time it takes just to *start* running an ISR.
> Yep, but if the port already has counters why not use them?
If they can be arranged to work properly, sure ;-)
Reply by Joerg●September 4, 20132013-09-04
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.
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.
Reply by Joerg●September 4, 20132013-09-04
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/
Reply by Joerg●September 4, 20132013-09-04
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/
Reply by ●September 4, 20132013-09-04
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.
Reply by ●September 4, 20132013-09-04
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.
Reply by Klaus Kragelund●September 4, 20132013-09-04
On Wednesday, September 4, 2013 5:54:40 PM UTC+2, om...@omegacs.net wrote:
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
Reply by Joerg●September 4, 20132013-09-04
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/