RS485 chip LTC491; optocoupler MOC5007

On Feb 18, 7:54=A0pm, Tauno Voipio <tauno.voi...@notused.fi.invalid>
wrote:
> On 18.2.11 7:57 , Shane williams wrote:
>
>
>
> > Thanks. =A0The tests I did were with termination - a 150 ohm resistor
> > across the A B terminals, plus a 47K resistor from A to VCC (I think
> > this was for biasing, whatever that is).
>
> A single 47k is not enough to guarantee a mark signal
> on an idle line. You need neough bleed current from
> both lines, one to voltage supply and another to ground,
> to create a guaranteed differential signal across the
> termination.
>
> > The optocoupler datasheet says "high data rate 1MHz typical NRZ".
> >http://pdf1.alldatasheet.com/datasheet-pdf/view/5043/MOTOROLA/MOC5007...
> > We use the 68302 DDCMP mode. =A0The error rate at 250 Kbps over 1000 M
> > non twisted cable was very small / negligible.
>
> For the speeds you're aiming at, the wavelength is below the
> 1000 m cable length, and you have to have a decent transmission
> line. Using a non-twisted pair and/or unknown insulation is
> inviting trouble.
>

The non twisted cable was just what I was testing with because we have
1000 M of it here.  We can specify whatever kind of cable we like for
use in a real system.

In article <4d5e0a6d$0$10361$607ed4bc@cv.net>, 
NeilKurzm@worldnet.att.net says...
> On 2/17/2011 5:46 AM, Shane williams wrote:
> > Hi
> >
> > I'm a software engineer wondering about some hardware.  We have a
> > circuit board with RS485 circuitry and Motorola 68302 processor using
> > an LTC491 RS485 chip and MOC5007 optocoupler for electrical
> > isolation.  The RS485 circuit is arranged to run as either 4 wire
> > multidrop (with contention detection circuitry) or as two by 2 channel
> > half duplex point to point, with each channel 2 wires.
> >
> > The contention circuitry seems to cause some complications, so
> > assuming that it's not there, what is the fastest speed I could expect
> > to run 2 wire point to point RS485 with these chips over 1000 metres
> > using reasonable cable?
> >
> > On two boards, I've been able to do 250 Kbps with no problems and 200
> > Kbps over 1400 metres.  A fellow hardware engineer tells me that the
> > RS485 chip and optocoupler may vary significantly from chip to chip
> > and also over time/ temperature so that predicting a reliable baud
> > rate is difficult.  Currently we use 57600 bps.  I would like to go at
> > twice that.
> >
> > Does the fact that 250 Kbps worked indicate that 115200 bps should be
> > reliable?
> >
> > TIA
> 
> You Know they Make RS-485 Transceivers with the Isolation built-in.
> 
Yes.
http://www.linear.com/product/LTM2881
I'm sure there are more
I just googled "rs485 isolated transceiver" and found that one.

In article <ijl52h$25e$1@news.eternal-september.org>, 
tauno.voipio@notused.fi.invalid says...
> 
> > Thanks.  The tests I did were with termination - a 150 ohm resistor
> > across the A B terminals, plus a 47K resistor from A to VCC (I think
> > this was for biasing, whatever that is).
> 
> A single 47k is not enough to guarantee a mark signal
> on an idle line. You need neough bleed current from
> both lines, one to voltage supply and another to ground,
> to create a guaranteed differential signal across the
> termination.

True.
A 680 to Vcc on 'A' a 680 to Vss on 'B' and a 150 terminating is a lot 
better.

On 18/02/2011 08:24, Oliver Betz wrote:
> Steve at fivetrees wrote:
>
> [...]
>
>> >"Correct termination" is a can of worms. Almost all current RS485
>> >devices have the A/B circuits reversed re the spec. Also, simply
>> >terminating across the A/B lines will result in an indeterminate state.
> That's why I consider EIA-485 broken by design.

Nothing wrong with the spec. Plenty wrong with the devices which followed.

Although - I presume your point is that, with termination and no bleeds, 
there's that indeterminate state. Yes, the specs could have been clearer 
about this. But it's not *that* hard. I've been using RS485 without 
problems (apart from those danged chips) for nearly 30 years now... 
(Eeeeep.)

>
>> >You need some bleed current in there to ensure a MARK state when idle.
>> >Hint: AC-coupling the termination often helps with the bleed current.
> Do you have a working real world example?
>
> I can't imagine that AC termination works if the bit rate is not way
> beyond the propagation time. Either it's time constant is too short
> for long cables, or it's too long for very biasing patterns.
>

I fear you misunderstand me. Given the lowish value of the terminator, 
the bleed to/from rails results in fairly high DC current. A 
transmission line is only an issue with AC ;). So, AC-coupling the 
terminator resolves the termination issue, while resolving the DC 
current issue.

There was an app note from my old company detailing this online, but 
they're rebuilding their site, and it's now "under construction"... gah...

Steve

-- 
http://www.fivetrees.com

Steve at fivetrees wrote:

>>> >"Correct termination" is a can of worms. Almost all current RS485
>>> >devices have the A/B circuits reversed re the spec. Also, simply
>>> >terminating across the A/B lines will result in an indeterminate state.
>> That's why I consider EIA-485 broken by design.
>
>Nothing wrong with the spec. Plenty wrong with the devices which followed.

I disagree. Requesting a DC bias was the wrong way IMNSHO. The better
design choice is to make 0V a defined state, as CAN does.

Then I can use passive terminations at the ends of the bus and I don't
need to select a bus node to provide DC bias.

[...]

>>> >You need some bleed current in there to ensure a MARK state when idle.
>>> >Hint: AC-coupling the termination often helps with the bleed current.
>> Do you have a working real world example?
>>
>> I can't imagine that AC termination works if the bit rate is not way
>> beyond the propagation time. Either it's time constant is too short
>> for long cables, or it's too long for very biasing patterns.
>
>I fear you misunderstand me. Given the lowish value of the terminator, 
>the bleed to/from rails results in fairly high DC current. A 
>transmission line is only an issue with AC ;). So, AC-coupling the 
>terminator resolves the termination issue, while resolving the DC 
>current issue.

That's what I understood. I think it doesn't work under the conditions
I pointed out.

Oliver
-- 
Oliver Betz, Muenchen (oliverbetz.de)