Discrete custom design of RS485 driver

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.

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

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:

formatting link

:-)

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.

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.

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:

formatting link

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:

formatting link

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.

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/
Reply to
Joerg
Loading thread data ...

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.

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

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

Sounds rather scary...

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.

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

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

formatting link

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.

Reply to
omega

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.

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

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.

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:

formatting link

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

formatting link

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

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.

Sometimes they aren't very versatile or fast though.

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.

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/
Reply to
Joerg

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.

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.

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.

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 to
Klaus Kragelund

Two reasons:

- the "sag" at the edges gets worse, and longer. My target is more like 25-50 units, not 6.

Reply to
omega

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.

n.

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.

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.

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?

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

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 to
omega
[...]

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

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

Yes, but not nearly as well as FSK would.

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.

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 to
Joerg

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 to
Joerg

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.

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

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.

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 to
omega
[...]

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.

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.

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

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

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

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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.

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.

If they can be arranged to work properly, sure ;-)

Reply to
omega

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:

formatting link

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.