Discrete custom design of RS485 driver

high due to 3V supply, so the power budget is exceeded

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

rarther large drop voltage when loaded with the defined bus load ...

so we can reduce the supply down to 2V and still comply with minimum 1.5V differential voltage into 54ohms.

No, that is up to the system configurator/responsible

the RS-485 bus

something

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

diodes.

from the low current body diodes.

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

ly

in

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.

y diodes.

y from the low current body diodes.

an

to drift by 2%, so for 11 bits, that would be a single character drift at t he end of the bit stream of close to 25% from the ideal mid bit sampling. S o it could probably tolerate plenty of ringing after the bit transition.

s, so ringing can affect the data quality closer to the transition, but now here near the 100ns switching times as discussed

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

diodes.

from the low current body diodes.

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

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

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

?-)

rarther large drop voltage when loaded with the defined bus load for Modbus of

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

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

we can reduce the supply down to 2V and still comply with minimum 1.5V differential voltage into 54ohms.

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)

This should do what you want...

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 tran sceiver (max13451, sn65hvd24, and max3292 all fail in various ways), so thi nking about designing a discrete transmitter.

The quirk of my design is that (by requirement) the RS-485 rides capacitive ly coupled over the 0-36V DC lines, and the wire isn't twisted, it's just r egular "lamp cord". The baud rate (dynamic 500Kbps-4Mbps in powers of 2, p reamble autobauds the receiver) is fast enough to avoid "sag", and the data is manchester encoded anyway. However, the more units on the bus, the fun kier the waveform. My goal is to come up with something that actually work s.

The max13451 is a pretty straight xcvr, but the waveform would start to mas sively struggle to rise/fall, with it actually losing ground and causing sp urious transitions on the receiver. The sn65hvd24 was not able to compensa te 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.

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 an d rather than bussing them together, drive different parts of the EQ circui t directly from each and *then *bus* them together: (ignore the values)

Even better, if those are tri-state gates, you can drive the OE's of each g ate independently in order to change which chains are active. The RS-485 D E function consists of turning all the OE's off.

AFAICT the Line_Driver.PDF circuit drives directly at all times, then can s witch 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?

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

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

Don't have the old thread anymore, they roll of after two months on my PC. But let me try.

Careful with the stock situations at distributors if this is for production. Doesn't look too great IMHO. The SN65HVD24 looks ok though.

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

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.

I'm going through the google groups page I initially found, which has the w hole history:

on.

Yeah, I watch that when I select parts. At least for now Maxim has been ab le to provide parts directly when needed. But a) right now I'm just graspi ng at straws for anything that will work, and b) a discrete solution with m ulti-source parts (e.g. 74xx gates) fixes the problem ;-)

;-)

One thing I haven't actually been able to figure out is how to compare disc rete 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 th e info is there somewhere, but I don't know how to translate it. Given tha t 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.

In theory I have a backchannel: the main bus runs at 500kbps-4Mbps, but I a lso 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 i n future rev's to avoid having to re-tune the R/C to the drive of the trans ceiver-of-the-day, however.

Basically, as long as the transmitter and receiver can actually send some a pproximation of a waveform, thus I can get a reasonable "PWM" out of the re ceiver, I can send e.g. 10% duty and 90% duty by just spamming 0x00 and 0xf e 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 th e 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 opt imize the bus. That means I may end up having to tune each unit's *transmi t* to a dumb receiver in the neighboring unit (since units are space-constr ained), while also tuning the controller's receive on a continuous basis to keep up with the units (since the controller is bigger).

Yeah, definitely something I've had to deal with. The max13451 and sn65hvd

Worse, the system will be upgraded at some point to include a TDR at the co ntroller, which will rely on a dead-short relay in each unit to determine r elative distances, so the bus will indeed be riddled with some "interesting " surge scenarios. The controller can switch off the 36VDC and engage a "d ump" relay to clear the bus of potential before engaging the TDR, while all the units have enough onboard capacitance to ride out the ~10ms measuremen t 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.

CAT5 is usually used in a terminated point to point configuration with attenuation (expressed in dB) is proportional to the square root of frequency. This frequency dependent loss is easy to compensate with a simple equalization, known in the cable-TV systems as "tilt".

Now we are talking about a multidrop/multiple branch system made of "lamp cords", that simple frequency compensation is little use.

If you are using mismatched lines that are longer about 1/10 wavelength, you really should understand transmission line issues. At

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.

This may be the circuit that the OP refers to:

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.

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

This information would be on pages 16, figures 19 and 20:

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.

Maybe I misunderstand this but the best is usually to remain at 50% duty cycle and NRZ-code.

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

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.

That sounds like the "bus from hell" :-)

I am not sure that USB clamping will be strong enough.

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

?-)