Discrete custom design of RS485 driver

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
> 
> <klauskvik@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

On Saturday, December 22, 2012 3:47:47 AM UTC+1, John Larkin wrote:
> On Fri, 21 Dec 2012 14:48:12 -0800 (PST), Klaus Kragelund
>=20
> <klauskvik@hotmail.com> wrote:
>=20
>=20
>=20
> >On Friday, December 21, 2012 10:17:44 PM UTC+1, Jim Thompson wrote:
>=20
> >> On Fri, 21 Dec 2012 11:11:58 -0800 (PST), Klaus Kragelund
>=20
> >>=20
>=20
> >> <klauskvik@hotmail.com> wrote:
>=20
> >>=20
>=20
> >>=20
>=20
> >>=20
>=20
> >> >On Friday, December 21, 2012 6:16:02 PM UTC+1, John Larkin wrote:
>=20
> >>=20
>=20
> >> >> On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> <klauskvik@hotmail.com> wrote:
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Hi
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >The standard RS485 drivers available has a minimum voltage of 3V a=
nd a rarther large drop voltage when loaded with the defined bus load for M=
odbus of 54ohms, and this causes problems for our design since we have limi=
ted power available for driving the bus
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >So, we are thinking about designing our own driver in discrete com=
ponents, so we can reduce the supply down to 2V and still comply with minim=
um 1.5V differential voltage into 54ohms.
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >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 limi=
t circuit along with a low value supply capacitance (to reduce peak power i=
n the FETs)
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Backfeed would need to be solved with a beefy diode to a defined c=
lamp voltage.
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >So, anyone been down this road, designing your own RS485 driver?
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Cheers
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Klaus
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> Just use a cmos quad xor gate; two paralleled sections for one phas=
e, two for
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> the other, with maybe 3.3 volt supply and 30 ohm source termination=
s. There's no
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> need to use discrete fets.
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> We recently did this:
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> https://dl.dropbox.com/u/53724080/Circuits/ESM/Line_Drivers.pdf
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> The basic line driver is a couple of tiny-logic gates driven from c=
omplementary
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> FPGA outputs. The downstream junk is selectable line driver equaliz=
ation, to
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> partially correct for CAT5 cable losses. This runs up to 125 MHz.
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >Maybe a good point, if I can find a logic device that has low RDSon a=
t 2V.=20
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >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
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >Regards
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >Klaus
>=20
> >>=20
>=20
> >>=20
>=20
> >>=20
>=20
> >> Do you need to tri-state the driver?  If so, Larkin's suggestion
>=20
> >>=20
>=20
> >> doesn't work.  Even with tri-state you have to watch out for "kick"
>=20
> >>=20
>=20
> >> above/below rails.
>=20
> >>=20
>=20
> >
>=20
> >Yes, I need to tristate the driver, since it is a 2 wire system, half du=
plex.
>=20
> >
>=20
> >Regards
>=20
> >
>=20
> >Klaus
>=20
>=20
>=20
> Can you make the whole system LVDS?
>=20
>

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

Cheers

Klaus

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

On Sat, 22 Dec 2012 02:07:12 -0800 (PST), Klaus Kragelund
<klauskvik@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.
 

<krw@att.bizzz> wrote in message 
news:m4gad85lueriqmjs5qj7im8caa8uvk6ih3@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.

Tim

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

On Saturday, December 22, 2012 12:10:38 PM UTC+1, upsid...@downunder.com wrote:
> On Sat, 22 Dec 2012 02:07:12 -0800 (PST), Klaus Kragelund
> 
> <klauskvik@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.
> 
> 

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

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
> 
> <jlarkin@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

On Saturday, December 22, 2012 3:47:47 AM UTC+1, John Larkin wrote:
> On Fri, 21 Dec 2012 14:48:12 -0800 (PST), Klaus Kragelund
>=20
> <klauskvik@hotmail.com> wrote:
>=20
>=20
>=20
> >On Friday, December 21, 2012 10:17:44 PM UTC+1, Jim Thompson wrote:
>=20
> >> On Fri, 21 Dec 2012 11:11:58 -0800 (PST), Klaus Kragelund
>=20
> >>=20
>=20
> >> <klauskvik@hotmail.com> wrote:
>=20
> >>=20
>=20
> >>=20
>=20
> >>=20
>=20
> >> >On Friday, December 21, 2012 6:16:02 PM UTC+1, John Larkin wrote:
>=20
> >>=20
>=20
> >> >> On Fri, 21 Dec 2012 03:02:40 -0800 (PST), Klaus Kragelund
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> <klauskvik@hotmail.com> wrote:
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Hi
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >The standard RS485 drivers available has a minimum voltage of 3V a=
nd a rarther large drop voltage when loaded with the defined bus load for M=
odbus of 54ohms, and this causes problems for our design since we have limi=
ted power available for driving the bus
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >So, we are thinking about designing our own driver in discrete com=
ponents, so we can reduce the supply down to 2V and still comply with minim=
um 1.5V differential voltage into 54ohms.
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >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 limi=
t circuit along with a low value supply capacitance (to reduce peak power i=
n the FETs)
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Backfeed would need to be solved with a beefy diode to a defined c=
lamp voltage.
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >So, anyone been down this road, designing your own RS485 driver?
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Cheers
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> >Klaus
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> Just use a cmos quad xor gate; two paralleled sections for one phas=
e, two for
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> the other, with maybe 3.3 volt supply and 30 ohm source termination=
s. There's no
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> need to use discrete fets.
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> We recently did this:
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> https://dl.dropbox.com/u/53724080/Circuits/ESM/Line_Drivers.pdf
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> The basic line driver is a couple of tiny-logic gates driven from c=
omplementary
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> FPGA outputs. The downstream junk is selectable line driver equaliz=
ation, to
>=20
> >>=20
>=20
> >> >>=20
>=20
> >>=20
>=20
> >> >> partially correct for CAT5 cable losses. This runs up to 125 MHz.
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >Maybe a good point, if I can find a logic device that has low RDSon a=
t 2V.=20
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >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
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >Regards
>=20
> >>=20
>=20
> >> >
>=20
> >>=20
>=20
> >> >Klaus
>=20
> >>=20
>=20
> >>=20
>=20
> >>=20
>=20
> >> Do you need to tri-state the driver?  If so, Larkin's suggestion
>=20
> >>=20
>=20
> >> doesn't work.  Even with tri-state you have to watch out for "kick"
>=20
> >>=20
>=20
> >> above/below rails.
>=20
> >>=20
>=20
> >
>=20
> >Yes, I need to tristate the driver, since it is a 2 wire system, half du=
plex.
>=20
> >
>=20
> >Regards
>=20
> >
>=20
> >Klaus
>=20
>=20
>=20
> Can you make the whole system LVDS?
>=20

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

Cheers

Klaus

On Sat, 22 Dec 2012 03:31:58 -0800 (PST), Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>On Saturday, December 22, 2012 9:41:35 AM UTC+1, upsid...@downunder.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.

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

On Dec 21, 8:11=A0pm, 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 Modbu=
s 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 compone=
nts, 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 ci=
rcuit along with a low value supply capacitance (to reduce peak power in th=
e 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, t=
wo for
>
> > the other, with maybe 3.3 volt supply and 30 ohm source terminations. T=
here'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 compl=
ementary
>
> > FPGA outputs. The downstream junk is selectable line driver equalizatio=
n, 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 som=
e 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