Your opinions on CAN physical layer docs, please (2024)

#540

#541

First, there's the "draft Standard" itself:

http://openlcb.org/trunk/srpdrafts/NMRA%20S-9-x-1.pdf

There's also a companion "Technical Note" for explanations, extra information, etc:

http://openlcb.org/trunk/srpdrafts/NMRA%20TN-9-x-1.pdf

#542

Looks very good, comments below.

First, there's the "draft Standard" itself:

http://openlcb.org/trunk/srpdrafts/NMRA%20S-9-x-1.pdf

#1: Section 4: A physical pinout diagram would be good, suchas
http://t2.gstatic.com/images?q=tbn:ANd9GcQRk6BCE6edRFekHT87skisUavHS8zZ7i6LnqOXoYGkivUoUd8&t=1&usg=__8H5ey16595OtP4wZ6c3-xXOUcZk=

or, with a little cleanup, something inspired by

http://t0.gstatic.com/images?q=tbn:ANd9GcRm6YgIpQRYyrEaEEhg-0WZmJR0nRH2diT7wOL_pJNnXWbgyP8&t=1&usg=__cCqmjsDzquM6Gv0mYbYBTk2Or88=

The point is to graphically eliminate any confusion with "pairnumbering" and the like, with the aim of preventing mirror imagemistakes.

#2: Section 4 and following: End for End cable pin swaps will be aproblem if people make their own cables, and ethernet cables might wellbe "crossover" wired instead of "normal", so lines44/45 and following probably should mention that conductors 1&2 and3&6 must be able to withstand up to 27v AC or ..., just like7&8...

There's also a companion "Technical Note" for explanations,extra information, etc:

http://openlcb.org/trunk/srpdrafts/NMRA%20TN-9-x-1.pdf

#3: Section 2.1, lines 11 & 12 say
The Standard does not discuss CAN terminators because they're discussedin detail in the CAN literature. See the “Termination” section below formore discussion.

Hmmm - it won't discuss it but it will... Department of redundancydepartment strikes again... The difference between "theStanadard" and this document (a Technical Note) is subtle on firstread.... Since it *is* discussed in detail below, this thought might bebetter phrased as:

The Standard is silent on the subject of CAN terminators because they'redealt with in detail in the CAN literature. See the “Termination”section below for a summary and references.

Alternatively, a line could be added to the Standard referencing that bustermination is expected to conform to CAN requirements, with the technote providing a summary (without this disclaimer paragraph...)

#4: Line 18ff: English grammar nits:
s/Board with/A board with/
s/box with/a box with/
s/should not rule out e.g. a/should not rule out more complex scenarios,such as a/
s/, or anything else//

#5: Line 38: Is it worth providing a cite to a weblocation?

#6: Lines 41ff: What happens if a Power Providing board isconnected to another Power Providing Board? Optional switchingbetween provider and consumer? It is mentioned in passing on line81, but an explicit "plan for it to be connected wrong" notehere won't hurt.

#7: Line 47: What is the max voltage of a ringing analog phone line(common use for that pair historically...). Note that voltages over~50v are considered high voltage and move the equipment that usesthem into higher regulatory requirement ranges for safety andtesting...

#8: Section 2.4: What is normal for off the shelf CAN parts?Does the 4V/uS rate correspond to some industry standarddesignation? If so, mention it.

#9: Line 89: s/specifies using/specifies the use of/

#10: Section 4 could use a diagram/picture with labels.

#11: The paragraph at line 155 is awkward. Maybe rewriteas:

Repeaters, bridges and gateways are different methods of connecting twoor more CAN segments so that a node on one segment can communicate withnodes on any connected segment. This section provides some backgroundinformation on these three alternatives. Note that the terminology issomewhat flexible, and not all manufacturers will refer to their productsin the same way.

#12: Line 159: Nit: Instead of
Inclusion of a device in this section is not a recommendation, positiveor negative, for the device.
maybe
Inclusion of a device in this section is informational, and does notimply a recommendation, positive or negative, for the device.

#13: Line 163: "may run out of electrical drive" is potentiallyconfusing.
Does it refer to the max number of nodes on a segment, the consumption ofthe "500mA max" power on conductor pins 7&8 or the actualgate load on conductors 1&2? What is the relationship betweenthis problem and the choice of 50 nodes per segment (Std line14)?

#14: Line 168: Instead of:
typically around 30 m / 100 ft.
maybe:
typically by around 30 m / 100 ft. per repeater.

#15: Line 181: Typo: s/CAN segments.s/CAN segments./

#16: Line 183: s/by more than a bit time/by much more than a bittime/

#17: Line 259: Same comment as #12.

#18: On a second read, Lines 68ff jump out as a potential problem -if a board uses half-wave regulation circuit, then layouts that try touse a single power supply for all their nodes will have problems.Reference the Digitrax DS54/PM4 problems discussed athttp://jmri.sourceforge.net/help/en/html/hardware/loconet/DigitraxPower/

-John

#543

On Sep 13, 2010, at 11:42 PM, Bob Jacobsen <jacobsen@...> wrote:

A few of us have been working on a draft CAN physical layer spec with the NMRAnet working group. It's going through the NMRA process slowly.

The content is pretty far along, far enough that we'd appreciate the thoughts of the skilled people on this list. Have we missed anything, gone into too much or too little detail, etc?

First, there's the "draft Standard" itself:

http://openlcb.org/trunk/srpdrafts/NMRA%20S-9-x-1.pdf

There's also a companion "Technical Note" for explanations, extra information, etc:

http://openlcb.org/trunk/srpdrafts/NMRA%20TN-9-x-1.pdf

These are in the NMRA's required format. If we can't get suitable agreement in the NMRA group, we'll use the content in our own OpenLCB documents, so your thoughtful comments will be useful in any case.

Thanks in advance

Bob

--
Bob Jacobsen, UC Berkeley
jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG

------------------------------------

Yahoo! Groups Links

#544

-----Original Message-----
From: openlcb@... [mailto:openlcb@...] On Behalf Of
Paul Bender
Sent: 14 September 2010 18:04
To: openlcb@...
Subject: Re: [openlcb] Your opinions on CAN physical layer docs, please

This may just be my inexperience with CAN, but where does the requirement
for a 1ft minimum cable length come from?

Paul
On Sep 13, 2010, at 11:42 PM, Bob Jacobsen <jacobsen@...> wrote:

A few of us have been working on a draft CAN physical layer spec with the

NMRAnet working group. It's going through the NMRA process slowly.

The content is pretty far along, far enough that we'd appreciate the

thoughts of the skilled people on this list. Have we missed anything, gone
into too much or too little detail, etc?

First, there's the "draft Standard" itself:

http://openlcb.org/trunk/srpdrafts/NMRA%20S-9-x-1.pdf

There's also a companion "Technical Note" for explanations, extra

information, etc:

http://openlcb.org/trunk/srpdrafts/NMRA%20TN-9-x-1.pdf

These are in the NMRA's required format. If we can't get suitable

agreement in the NMRA group, we'll use the content in our own OpenLCB
documents, so your thoughtful comments will be useful in any case.

Thanks in advance

Bob

--
Bob Jacobsen, UC Berkeley
jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype

JacobsenRG

------------------------------------

Yahoo! Groups Links

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.445 / Virus Database: 271.1.1/3133 - Release Date: 09/13/10
18:35:00

#545

#546

#547

On Sep 14, 2010, at 10:04 AM, Paul Bender wrote:

> This may just be my inexperience with CAN, but where does the requirement for a 1ft minimum cable length come from?
>

To support long lengths, CAN is based on a transmission-line approach. The nodes along that transmission line are kept to a small perturbation, small enough that the reflections they cause are manageable. The current drawn and capacitive loads are matched to that end (that's why CAN specifies a _maximum_ impedance for a node, so that the current draw doesn't get too small to be commensurate for the capacitive loading). Putting nodes too close together messes that up. The effect is mostly a high-frequency one (because it involves the C part of the RLC), but even a 125kbps CAN signal has significant amplitude at e.g. 1MHz.

(As an aside, the slew rate limit is the CAN method to reduce the high-frequency components, but that's another discussion)

Bob

#548

#549

On Sep 14, 2010, at 12:12 PM, Archibald Campbell wrote:

> http://www.openlcb.org/trunk/documents/can/CommonPlatform.html
> suggests 0.5m rather than 1ft or 0.3m.
>

Quite correct. When I wrote that note, I was working off the SLAC/LBL experience with wiring that was somewhat different from the RJ45/UTP in the NMRA draft standard. That, along with somebody pointing out that 1ft / 0.3m UTP cables are easier to find that 1.5 ft / 0.5m ones, led to relaxing the minimum recommended length a little. It's certainly a judgement call, and perhaps it should go back. Still, that's an "informative" section of the draft standard, more of a guideline than an rule, and I expect that lots of people won't ever think about it.

Note that this really only matters when you've got a mix of long _and_ short links. The long ones make the timing critical, and the short ones mess it up. If you've only got short links, e.g. 20 nodes all a couple feet apart, it's probably not a problem.

#550

On 09/15/2010 09:08 AM, Archibald Campbell wrote:

Hi Bob

The relevance of the original query is that yesterday (I received something like 90 emails yesterday, somewhat of a record for me) someone mentioned on the MERG forum that his bus wasn't working and that all his modules were contained in one file box. Apart from the fact that I would question the choice of CBUS if all modules are in one place, it appeared that the most likely problem would be that the bus lengths between nodes might be near zero.

Last night I was trying to work out what the directions mean. Particularly the one about the minimum stub length.
My understanding is that there are a few prime directives:
a) No link between modules less than 1?ft of main core line.
b) No stub longer than 10ft - a stub is defined as a branch from the main core line longer than 1ft
c) The effective length to be less than 400m

The effective length is the overall length of the main core line plus 3m for each node plus double the length of each spur.

This means that there is no advantage in having a spur except perhaps in cable length as the spur can be replaced with a double length eliminating the spur. Moreover if all the modules on a spur were at the end the limit of having 1ft between each could result in the spur being extended beyond the 3m limit. Dual cable would give more possibility of spacing the breaks. The one advantage might be a small reduction in resistance by effectively reducing the length of the power cable by the length of the double cable used to avoid a spur, however there's no reason why the power cannot bypass the "spur" so that while the bus is all looped in the power is spurred.

The effective length may be drastically reduced by the number of nodes. Thus if a bus has the limit of 110 nodes it can only be 90m long. As each node must be separated from its neighbour by 0.3m this means that 33m of that is taken up by these minimum length connections. OK a 57m layout is pretty big so that's not much of a limitation. However CANCAN's will become necessary for layouts that exceed the limits for a single bus. I presume these will consist of two CBUS tranceivers back to back.

Another point that I have been trying to find an answer to for some months is that of voltage drop along the bus. Can the bus cope with a voltage difference between one end and the other of say 10v? If not, what is the limit?

Archie

------------------------------------------------------------------------
To: openlcb@...
From: jacobsen@...
Date: Tue, 14 Sep 2010 17:18:58 -0700
Subject: Re: [openlcb] Your opinions on CAN physical layer docs, please

On Sep 14, 2010, at 12:12 PM, Archibald Campbell wrote:

http://www.openlcb.org/trunk/documents/can/CommonPlatform.html
suggests 0.5m rather than 1ft or 0.3m.

Quite correct. When I wrote that note, I was working off the SLAC/LBL experience with wiring that was somewhat different from the RJ45/UTP in the NMRA draft standard. That, along with somebody pointing out that 1ft / 0.3m UTP cables are easier to find that 1.5 ft / 0.5m ones, led to relaxing the minimum recommended length a little. It's certainly a judgement call, and perhaps it should go back. Still, that's an "informative" section of the draft standard, more of a guideline than an rule, and I expect that lots of people won't ever think about it.

Note that this really only matters when you've got a mix of long _and_ short links. The long ones make the timing critical, and the short ones mess it up. If you've only got short links, e.g. 20 nodes all a couple feet apart, it's probably not a problem.

#551

#552

#554

Hi Bob

I was trying to determine the actual effect of the recommendations. I
appreciate that failure to follow them religiously may not cause loss of
communication it merely puts it at risk.

My concern over voltage drop over the bus length is that the modules are
likely to be powered centrally with the voltage locally reduced to 5v. This
means that the voltage drop is not a concern as far as the power to the local
modules are concerned BUT the voltage drop in the return wire determines the
the voltage on the bus. The supply to the modules not only powers the 5v ics
but also powers the actuators. The original design had a 1.5A CDU recharge
current. Worse a Start of Day procedure could call all modules to reset all
points meaning that all modules would be consuming up to 1.5A during start
up.

Archie

To: openlcb@...
From: jacobsen@...
Date: Wed, 15 Sep 2010 10:38:11 -0700
Subject: Re: [openlcb] Your opinions on CAN physical layer docs, please

On Sep 15, 2010, at 6:08 AM, Archibald Campbell wrote:

The relevance of the original query is that yesterday (I received something

like 90 emails yesterday, somewhat of a record for me) someone mentioned on
the MERG forum that his bus wasn't working and that all his modules were
contained in one file box. Apart from the fact that I would question the
choice of CBUS if all modules are in one place, it appeared that the most
likely problem would be that the bus lengths between nodes might be near
zero.

I don't think that minimum-length issues are the most likely cause of a
problem there. If they really are all close together, they're effectively
looking like a lumped-component load, and there's not a lot of issue with
transmission line considerations that lead to a min-distance spec.

I suggest that he just unplug half the nodes, and try to resolve the problem
via a binary search. It's likely to be either a specific node (or nodes), or
a wiring fault.

Last night I was trying to work out what the directions mean. Particularly

the one about the minimum stub length.

My understanding is that there are a few prime directives:
a) No link between modules less than 1?ft of main core line.
b) No stub longer than 10ft - a stub is defined as a branch from the main

core line longer than 1ft

Those are both due to the transmission-line effects when the total network
length is a consideration. Short spurs look like capacitive loads so can be
included pretty easily as a length deduction. Longer ones result in
reflections at various times, and it gets complicated to work out what's OK
and what's not.

c) The effective length to be less than 400m

This limit comes from timing, and assumes large conductors. 400m of ad-hoc
twisted wire is about 4.3usec of out and back time with ad-hoc wire, which is
still well below the 8-1.2usec sample timing. 500m might be possible, it's
still in theory below the limit, but that's assuming a lot about connections,
etc.

For the NMRAnet draft standard, which uses UTP cable (24 gauge twisted), the
recommendation has been lowered to 1000 ft / 300 m due to the smaller wire
size.

The effective length is the overall length of the main core line plus 3m

for each node plus double the length of each spur.

Those deductions are an ad-hoc way of accounting for the propagation time and
loading effects of the nodes & spurs.

Another point that I have been trying to find an answer to for some months

is that of voltage drop along the bus. Can the bus cope with a voltage
difference between one end and the other of say 10v? If not, what is the
limit?

I would hope those never get that big! The CAN spec & other docs discuss
various ways of looking at common mode offsets. It's somewhat complicated
because the offsets are rarely clean DC values; anything that will create an
offset will also create common mode noise, which usually is the bigger
effect.

The OpenLCB model uses UTP cables, with a single 24 gauge power conductor and
three ground conductors. It's meant for up to 0.5A of current over 6m / 20
ft, so that the voltage drop stays manageable. Larger power conductors can go
farther or provide more current, of course, though make be careful to
consider the resistance of both ground and supply leads.

Bob
--
Bob Jacobsen, UC Berkeley
jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype
JacobsenRG

#553

On Sep 15, 2010, at 6:08 AM, Archibald Campbell wrote:

> The relevance of the original query is that yesterday (I received something like 90 emails yesterday, somewhat of a record for me) someone mentioned on the MERG forum that his bus wasn't working and that all his modules were contained in one file box. Apart from the fact that I would question the choice of CBUS if all modules are in one place, it appeared that the most likely problem would be that the bus lengths between nodes might be near zero.

I don't think that minimum-length issues are the most likely cause of a problem there. If they really are all close together, they're effectively looking like a lumped-component load, and there's not a lot of issue with transmission line considerations that lead to a min-distance spec.

I suggest that he just unplug half the nodes, and try to resolve the problem via a binary search. It's likely to be either a specific node (or nodes), or a wiring fault.

> Last night I was trying to work out what the directions mean. Particularly the one about the minimum stub length.
> My understanding is that there are a few prime directives:
> a) No link between modules less than 1?ft of main core line.
> b) No stub longer than 10ft - a stub is defined as a branch from the main core line longer than 1ft

Those are both due to the transmission-line effects when the total network length is a consideration. Short spurs look like capacitive loads so can be included pretty easily as a length deduction. Longer ones result in reflections at various times, and it gets complicated to work out what's OK and what's not.

> c) The effective length to be less than 400m

This limit comes from timing, and assumes large conductors. 400m of ad-hoc twisted wire is about 4.3usec of out and back time with ad-hoc wire, which is still well below the 8-1.2usec sample timing. 500m might be possible, it's still in theory below the limit, but that's assuming a lot about connections, etc.

For the NMRAnet draft standard, which uses UTP cable (24 gauge twisted), the recommendation has been lowered to 1000 ft / 300 m due to the smaller wire size.

> The effective length is the overall length of the main core line plus 3m for each node plus double the length of each spur.

Those deductions are an ad-hoc way of accounting for the propagation time and loading effects of the nodes & spurs.

> Another point that I have been trying to find an answer to for some months is that of voltage drop along the bus. Can the bus cope with a voltage difference between one end and the other of say 10v? If not, what is the limit?

I would hope those never get that big! The CAN spec & other docs discuss various ways of looking at common mode offsets. It's somewhat complicated because the offsets are rarely clean DC values; anything that will create an offset will also create common mode noise, which usually is the bigger effect.

The OpenLCB model uses UTP cables, with a single 24 gauge power conductor and three ground conductors. It's meant for up to 0.5A of current over 6m / 20 ft, so that the voltage drop stays manageable. Larger power conductors can go farther or provide more current, of course, though make be careful to consider the resistance of both ground and supply leads.

Bob
--
Bob Jacobsen, UC Berkeley
jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG

#555

#556

#557

On 09/15/2010 03:18 PM, Archibald Campbell wrote:

Hi Dick

That does make sense.

My immediate reaction was that I'd put the transceiver under the baseboard but then I remembered the buttons on the CANCAB.

On the voltage point. How is it envisaged that power be supplied along the route? Not that I'd ever supply power from one end which increases resistance losses by a factor of 4 compared with power from the centre. Does this mean multiple PSUs? JJ suggested a +- power supply with a non current carrying reference neutral. This would also allow a larger voltage to be available for CDUs - but not using present module designs.

To: openlcb@...
From: dick@...
Date: Wed, 15 Sep 2010 10:59:50 -0400
Subject: Re: [openlcb] Your opinions on CAN physical layer docs, please

Archie,
Just a comment on the use of stubs. The intent here is to make
allowances for hand held devices that you would not normally want to
connect with dual cables. (one coming, and the other going) For layout
mounted nodes the normal connections would not use any stubs at all if
possible.

The intent with power is that it is supplied along the bus as needed,
not all from just one end. That should reduce the amount of ground
voltage difference due to current induced drops. The maximum ground
offset would be much less than 10V because there are multiple ground
lines, and the +V to ground voltage drop is limited to 1.5V over any

one

section of the cable. (9V minimum supplied, 7.5V minimum provided)

Dick :)

On 09/15/2010 09:08 AM, Archibald Campbell wrote:

Hi Bob

The relevance of the original query is that yesterday (I received
something like 90 emails yesterday, somewhat of a record for me)
someone mentioned on the MERG forum that his bus wasn't working and
that all his modules were contained in one file box. Apart from the
fact that I would question the choice of CBUS if all modules are in
one place, it appeared that the most likely problem would be that the
bus lengths between nodes might be near zero.

Last night I was trying to work out what the directions mean.
Particularly the one about the minimum stub length.
My understanding is that there are a few prime directives:
a) No link between modules less than 1?ft of main core line.
b) No stub longer than 10ft - a stub is defined as a branch from the
main core line longer than 1ft
c) The effective length to be less than 400m

The effective length is the overall length of the main core line plus
3m for each node plus double the length of each spur.

This means that there is no advantage in having a spur except perhaps
in cable length as the spur can be replaced with a double length
eliminating the spur. Moreover if all the modules on a spur were at
the end the limit of having 1ft between each could result in the spur
being extended beyond the 3m limit. Dual cable would give more
possibility of spacing the breaks. The one advantage might be a small
reduction in resistance by effectively reducing the length of the
power cable by the length of the double cable used to avoid a spur,
however there's no reason why the power cannot bypass the "spur" so
that while the bus is all looped in the power is spurred.

The effective length may be drastically reduced by the number of
nodes. Thus if a bus has the limit of 110 nodes it can only be 90m
long. As each node must be separated from its neighbour by 0.3m this
means that 33m of that is taken up by these minimum length
connections. OK a 57m layout is pretty big so that's not much of a
limitation. However CANCAN's will become necessary for layouts that
exceed the limits for a single bus. I presume these will consist of
two CBUS tranceivers back to back.

Another point that I have been trying to find an answer to for some
months is that of voltage drop along the bus. Can the bus cope with a
voltage difference between one end and the other of say 10v? If not,
what is the limit?

#558

-----Original Message-----
From: openlcb@... [mailto:openlcb@...] On Behalf Of Archibald Campbell
Sent: 15 September 2010 22:50
To: openlcb@...
Subject: RE: [openlcb] Your opinions on CAN physical layer docs, please

Hi David

Not confusing, just practical, in that it is sensible to use modules that already exist rather than reinventing the wheel unless absolutely necessary. Separating the supplies makes good sense although itis liable toincrease costs as it requires relay outputs or similar.

The Start of Day messages are inherently necessary in many layouts to ensure that the status is as required. There are exceptions such as route selection schemes where turnout position is immaterial unless a route is selected and all routes would need to be reselected after power down.

Archie

To: openlcb@...
From: dpharris@...
Date: Wed, 15 Sep 2010 11:04:16 -0700
Subject: RE: [openlcb] Your opinions on CAN physical layer docs, please

Archie--

I am confused. You seem to be mixing OpenLCB and CBUS concepts.

The power though RJ45/CAT5 proposed is meant only to supply the driver chips
and possibly other low power electronics, such as the mpu. Local power should
be supplied for power hungry applications, such as CDUs.

In addition, OpenLCB has not defined a Start-of-day message.

David

Quoting Archibald Campbell <fdonmedway@...>:

>
> Hi Bob
>
>
>
> I was trying to determine the actual effect of the recommendations. I
> appreciate that failure to follow them religiously may not cause loss of
> communication it merely puts it at risk.
>
>
>
> My concern over voltage drop over the bus length is that the modules are
> likely to be powered centrally with the voltage locally reduced to 5v. This
> means that the voltage drop is not a concern as far as the power to the local
> modules are concerned BUT the voltage drop in the return wire determines the
> the voltage on the bus. The supply to the modules not only powers the 5v ics
> but also powers the actuators. The original design had a 1.5A CDU recharge
> current. Worse a Start of Day procedure could call all modules to reset all
> points meaning that all modules would be consuming up to 1.5A during start
> up.
>
>
>
> Archie
>
>
>
>
>
>
>
>
> To: openlcb@...
> From: jacobsen@...
> Date: Wed, 15 Sep 2010 10:38:11 -0700
> Subject: Re: [openlcb] Your opinions on CAN physical layer docs, please
>
>
>
>
>
>
>
> On Sep 15, 2010, at 6:08 AM, Archibald Campbell wrote:
>
> > The relevance of the original query is that yesterday (I received something
> like 90 emails yesterday, somewhat of a record for me) someone mentioned on
> the MERG forum that his bus wasn't working and that all his modules were
> contained in one file box. Apart from the fact that I would question the
> choice of CBUS if all modules are in one place, it appeared that the most
> likely problem would be that the bus lengths between nodes might be near
> zero.
>
> I don't think that minimum-length issues are the most likely cause of a
> problem there. If they really are all close together, they're effectively
> looking like a lumped-component load, and there's not a lot of issue with
> transmission line considerations that lead to a min-distance spec.
>
> I suggest that he just unplug half the nodes, and try to resolve the problem
> via a binary search. It's likely to be either a specific node (or nodes), or
> a wiring fault.
>
> > Last night I was trying to work out what the directions mean. Particularly
> the one about the minimum stub length.
> > My understanding is that there are a few prime directives:
> > a) No link between modules less than 1?ft of main core line.
> > b) No stub longer than 10ft - a stub is defined as a branch from the main
> core line longer than 1ft
>
> Those are both due to the transmission-line effects when the total network
> length is a consideration. Short spurs look like capacitive loads so can be
> included pretty easily as a length deduction. Longer ones result in
> reflections at various times, and it gets complicated to work out what's OK
> and what's not.
>
> > c) The effective length to be less than 400m
>
> This limit comes from timing, and assumes large conductors. 400m of ad-hoc
> twisted wire is about 4.3usec of out and back time with ad-hoc wire, which is
> still well below the 8-1.2usec sample timing. 500m might be possible, it's
> still in theory below the limit, but that's assuming a lot about connections,
> etc.
>
> For the NMRAnet draft standard, which uses UTP cable (24 gauge twisted), the
> recommendation has been lowered to 1000 ft / 300 m due to the smaller wire
> size.
>
> > The effective length is the overall length of the main core line plus 3m
> for each node plus double the length of each spur.
>
> Those deductions are an ad-hoc way of accounting for the propagation time and
> loading effects of the nodes & spurs.
>
> > Another point that I have been trying to find an answer to for some months
> is that of voltage drop along the bus. Can the bus cope with a voltage
> difference between one end and the other of say 10v? If not, what is the
> limit?
>
> I would hope those never get that big! The CAN spec & other docs discuss
> various ways of looking at common mode offsets. It's somewhat complicated
> because the offsets are rarely clean DC values; anything that will create an
> offset will also create common mode noise, which usually is the bigger
> effect.
>
> The OpenLCB model uses UTP cables, with a single 24 gauge power conductor and
> three ground conductors. It's meant for up to 0.5A of current over 6m / 20
> ft, so that the voltage drop stays manageable. Larger power conductors can go
> farther or provide more current, of course, though make be careful to
> consider the resistance of both ground and supply leads.
>
> Bob
> --
> Bob Jacobsen, UC Berkeley
> jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype
> JacobsenRG
>
>
>
>
>

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.445 / Virus Database: 271.1.1/3135 - Release Date: 09/14/10 18:34:00

#559