LONWorks vs. Ethernet

On 2005-04-27, Richard H. <rh86@no.spam> wrote:
> Randall Nortman wrote:
>> I need to build some little devices to install throughout a small
>> building, each of which will take readings from 2-6 analog sensors
>> (10-bit resolution, 1 sample/sec is plenty).  Some of the pods will
>> also need to drive a few low-power relays.  I want the networking to
>> be all digital, with the sensor readings going back to a headless
>> Linux PC, which also sends signals back to open and close the relays.
>> The remote devices should be very cheap, and the networking should be
>> reliable and flexible in terms of topologies.  Delivering DC power and
>> communications over the same cable would be ideal.
>
> It sounds like overkill.  Go simpler.  Consider also who will be 
> installing this product, and how simple it needs to be.
>
> Why not simple serial comms for the remote devices?  For some 30+ years, 
> airline computer terminals have run over ridiculous distances with 
> multi-drop serial cables.  It can work really well, and cheap.  Over 
> 18AWG stranded wire, IIRC, and occasionally over phone wiring.  It 
> shouldn't require much but a strong serial driver.
[...]

Wiring to 40+ locations within a house is hard, error-prone work.  I
don't want to make it harder by requiring those nodes all to be
daisy-chained and properly terminated (e.g., RS-485).  I need
flexibility in the topology -- star, bus, or a mix of the two.
(LONWorks wins on this point, with their "free topology" wiring, which
lets you do whatever you like so long as total wire length is <500m.)
Point-to-point serial (RS-232, RS-422) would require me to have 40+
serial ports on the central controller.  No thanks.

But I do appreciate the alternative viewpoint.  I have been rethinking
Ethernet since my previous post, because it does seem to be overkill,
and only supports star topologies (unless you can still find BNC
Ethernet transceivers, which I don't think you really can).  Wiring
seems to be a breeze with LONWorks, though I don't like having to pay
for development tools, protocol analyzers, PC interfaces, and who
knows what else.

Any other options for low-bandwidth networking with very flexible
topologies and cheap, readily available transceivers?

-- 
Randall

"Randall Nortman" <usenet8189@wonderclown.com> wrote in message 
news:0wDbe.15513$go4.247@newsread2.news.atl.earthlink.net...
> On 2005-04-27, Richard H. <rh86@no.spam> wrote:

[snip]

> (LONWorks wins on this point, with their "free topology" wiring, which
> lets you do whatever you like so long as total wire length is <500m.)
> Point-to-point serial (RS-232, RS-422) would require me to have 40+
> serial ports on the central controller.  No thanks.

Multi-drop RS-422 or RS-485, one master, one 2 or 4 wire cable connected to 
slaves.

Gunnar. 

Randall Nortman wrote:
> On 2005-04-27, Richard H. <rh86@no.spam> wrote:
> Wiring to 40+ locations within a house is hard, error-prone work.  I
> don't want to make it harder by requiring those nodes all to be
> daisy-chained and properly terminated (e.g., RS-485).  I need
> flexibility in the topology -- star, bus, or a mix of the two.

Reflecting on the serial dumb terminal setup... the serial line can be 
wired in star or bus (we often used a tree topology), and no termination 
was used (unless it was all at one end in the master) - probably because 
the speed was very low.  I suspect this is a key difference compared to 
some of the higher-speed topologies you're looking at.

Star topology is much harder than bus to wire (but easier to debug). 
And you can always star wire and then tie them all together at the 
head-end, with one master connection (again, if not drawing too much 
power from the one connection).  And the master can be connected 
anywhere by just swapping its TX & RX pins on the PCB (i.e., DCE vs DTE 
pinout).


> (unless you can still find BNC
> Ethernet transceivers, which I don't think you really can).

Yes, but they will significantly add to your cost, and they need to be 
powered by the AUI port, not the other way around.  (There are still 
some commercial products that use them.)


In short, the stuff you're looking at is designed for higher-speed 
comms, when you could probably make do with something simple, cheap, and 
old / tried & true.  Especially if you're trying to make a commercial 
offering out of it.

Cheers,
Richard

On Wed, 27 Apr 2005 03:18:20 +0000, Randall Nortman wrote:


> Wiring to 40+ locations within a house is hard, error-prone work.  I
> don't want to make it harder by requiring those nodes all to be
> daisy-chained and properly terminated (e.g., RS-485).  I need
> flexibility in the topology -- star, bus, or a mix of the two.
> (LONWorks wins on this point, with their "free topology" wiring, which
> lets you do whatever you like so long as total wire length is <500m.)
> Point-to-point serial (RS-232, RS-422) would require me to have 40+
> serial ports on the central controller.  No thanks.
> 

No termination - I wonder how they do that? You need to match at the end
of the line to avoid reflections, unless slew rate is controlled so that
it is unecessary. I think the rule of thumb is slew-rate < cable
propagation delay * 10 - something like that anyway. A rough calculation
based on 5ns per metre, 30 metres of cable - max slew rate would be 10 * 5
* 30 ns. If you can live with the data rate that gives you then you don't
need termination, irrespective of the network topology, star, bus or
combination of both.

> But I do appreciate the alternative viewpoint.  I have been rethinking
> Ethernet since my previous post, because it does seem to be overkill,

Ethernet sounds like a massive overkill.

> and only supports star topologies (unless you can still find BNC
> Ethernet transceivers, which I don't think you really can).  Wiring
> seems to be a breeze with LONWorks, though I don't like having to pay
> for development tools, protocol analyzers, PC interfaces, and who
> knows what else.
>

If you don't want to pay for dev tools you don't have to - H8 and gcc will
do you. Also there is Atmel AVR + gcc, which I haven't used, but someone
else may be able to post on suitability. There are other alternatives, but
if the remote units need to be cheap, then H8 or Atmel AFAIK are the
cheapest processors that gcc supports.

> Any other options for low-bandwidth networking with very flexible
> topologies and cheap, readily available transceivers?

I think I would consider a single ended interface to start with in
a master slave arrangement. Have a drive circuit that slew rate limits
the signal onto the cable, and have a receiver that has some hysteresis
built into it. Have an enable signal for the drive circuit so that
master and slaves can communicate over the same wire. Using this
method you can supply power on a third cable, but of course you would need
to pay attention to voltage drops because of the single ended nature of
the comms protocol. 

HTH,

Paul.

-- 
Remove _rem_ before replying by email.

On Tue, 26 Apr 2005 20:35:11 GMT, Randall Nortman
<usenet8189@wonderclown.com> wrote:

>I need to build some little devices to install throughout a small
>building, each of which will take readings from 2-6 analog sensors
>(10-bit resolution, 1 sample/sec is plenty).  Some of the pods will
>also need to drive a few low-power relays.  I want the networking to
>be all digital, with the sensor readings going back to a headless
>Linux PC, which also sends signals back to open and close the relays.
>The remote devices should be very cheap, and the networking should be
>reliable and flexible in terms of topologies.  Delivering DC power and
>communications over the same cable would be ideal.
>
>I know squat about Echelon/LONWorks, beyond the little I've been able
>to figure out from reading their website, which buries the technical
>stuff I need to know in mountains of marketing propaganda.  But still,
>it seems like it could do the job.  They have a version that can do
>the communications over the same two wires that provide DC power,
>which is convenient.  What I don't know is how I would interface ADC
>chips and relay drivers to the Neuron chip, how I program the thing,
>and how much the chips, transceivers, and external components cost
>(ballpark, quantity 100 or so).  And if the development tools are
>commercial (and I hate commercial development environments), how much
>do they cost, and do they run on Linux?  Also, is the thing really
>reliable and tolerant of less-than-perfect wiring?
>
>The alternative is to bring out the big guns and run an embedded Linux
>on an SOC/SBC and just use Ethernet (preferrably with Power over
>Ethernet) and TCP/IP.  This is appealing because I know Linux very
>well, and I can develop for it using free tools.  I suspect the
>downside is the cost.  I think it's worth paying a little more for the
>convenience of using something I know, and which is widely supported
>in all sorts of industries.  But without knowing how cheap LONWorks
>can be, I don't know how much of a premium I'm paying for the
>convenience of Linux.
>
>I should also say that I've considered using an 8-bit microcontroller
>(eg Atmel AVR) and RS-485, but then I have to write and debug an RTOS
>and network protocol, plus my experience with RS-485 has been that
>it's far too sensitive to wiring imperfections, and the network
>topology is too limited.
>
>So, any thoughts?  Can anybody with LONWorks experience give me some
>advice on whether that's a good option, and how much cost I should
>expect to save vs. Ethernet?  Any suggestions of very cheap SOCs/SBCs
>if I want to go the Linux route?
>
>Thanks very much,

I can't comment much about embedded linux since there are so many
different boards from different vendors with different levels of
support.  Generally it looks like an expesive option.  The other issue
is that if you want to service the network in the future, the SBCs may
go obsolete, and you probably can't use the same application image.  I
don't know if service support is an issue for you.

I have a bit of experience with Lonworks, and it would be a good
solution if you want very good comms reliability for a reasonable cost
per device.  But you should only consider starting it if you are very
serious about getting into the buidling controls industry as a volume
manufacturer.  One issue is that Lonworks is not really an open
protocol.  The software development tools are aimed at the LSN network
plugin environment which means using you must create device profiles
that allow you device to be installed using the standard network
management tools.  These tools are proprietary to Echelon corporation,
and you need to pay a license fee every time you install a device
using their tools.  Apart from this there is quite a steep learning
curve to create LNS based applications, and you will need to check the
cost of the development tools.  

The AVR is a far superior device to the Neuron chip as far performance
is concerned.  The neuron chip scheduler is just a joke.  It is
horribly slow and non-deterministic being a co-operative scheduler
without any way to service real time tasks.  The main problem is that
the Neuron chip does not support interrupts so this makes it
impossible to write applications have reasonable IO latancies.

Personally, I would look at the AVR with RS-485 as the first option.

regards,
Johnny.

All of the topologies you've listed, RS485,Lon,Enet...suffer from the same
bad problem.When the wire gets shorted or opened your entire network is
down.
You should consider another another way . I have a system,mind you it's
almost 30 years old,that will communicate over 1 wire has error detection
and it hacker proof.If you run 2 wires you get the ability to isolate the
'bad' chunk of wire or a 'dead' unit.
Cost per remote is about $1, for the host, $3...plus code cutting.....
This system has been in use in banks,high end stores,etc as well as remote
energy control.

jay

On Tue, 26 Apr 2005 20:35:11 GMT, Randall Nortman
<usenet8189@wonderclown.com> wrote:

>I need to build some little devices to install throughout a small
>building, each of which will take readings from 2-6 analog sensors
>(10-bit resolution, 1 sample/sec is plenty).  Some of the pods will
>also need to drive a few low-power relays.  I want the networking to
>be all digital, with the sensor readings going back to a headless
>Linux PC, which also sends signals back to open and close the relays.
>The remote devices should be very cheap, and the networking should be
>reliable and flexible in terms of topologies.  Delivering DC power and
>communications over the same cable would be ideal.

Have you considered CAN? It's a 2-wire (+ Gnd) bus like RS485, but with the
added bonus of intelligent controller chips that will do checksumming, error
control etc for you. Bus speed ranges from 10 kbps to 1 MBps, bus length is
40m for 1 MBps and 1 km for 50 kbps. There are many cheap microcontrollers
like AVR 90CAN128 (a Mega128 with CAN) or Microchip PIC18FXX8. CAN
controllers are used in automotive in huge quantities, so the chips are
cheap.

CAN doesn't carry power over the data lines. You should add an 48V DC supply
for this.

Mit freundlichen Gr&#4294967295;&#4294967295;en

Frank-Christian Kr&#4294967295;gel

Randall Nortman wrote:

> I should also say that I've considered using an 8-bit microcontroller
> (eg Atmel AVR) and RS-485, but then I have to write and debug an RTOS
> and network protocol, plus my experience with RS-485 has been that
> it's far too sensitive to wiring imperfections, and the network
> topology is too limited.


Ethernet on Linux is a different pair of shoes than an
AVR with RS485. The RS485 has little problems once you
get rid of the potential GND differences. There are these
rather fast magnetic couplers from Analog devices that
isolate 2kV or such at speeds of up too 1, 10 or 100MBit.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

On 2005-04-27, Paul Taylor <pault_rem_.ngea@virgin.net> wrote:
> On Wed, 27 Apr 2005 03:18:20 +0000, Randall Nortman wrote:
>
>
>> Wiring to 40+ locations within a house is hard, error-prone work.  I
>> don't want to make it harder by requiring those nodes all to be
>> daisy-chained and properly terminated (e.g., RS-485).  I need
>> flexibility in the topology -- star, bus, or a mix of the two.
>> (LONWorks wins on this point, with their "free topology" wiring, which
>> lets you do whatever you like so long as total wire length is <500m.)
>> Point-to-point serial (RS-232, RS-422) would require me to have 40+
>> serial ports on the central controller.  No thanks.
>> 
>
> No termination - I wonder how they do that? You need to match at the end
> of the line to avoid reflections, unless slew rate is controlled so that
> it is unecessary. I think the rule of thumb is slew-rate < cable
> propagation delay * 10 - something like that anyway. A rough calculation
> based on 5ns per metre, 30 metres of cable - max slew rate would be 10 * 5
> * 30 ns. If you can live with the data rate that gives you then you don't
> need termination, irrespective of the network topology, star, bus or
> combination of both.
[...]

I think they avoid reflection problems by riding the data on a sine
wave carrier of 5-40MHz, depending on which transceivers you use and
how they are configured.  I'm not sure exactly what sort of modulation
they use, but the effective communication rate is 78kbps.  I'm not an
electrical engineer, but I think sine waves are pretty immune to
reflections, right?  This stuff is getting into black magic territory
for me -- I don't want to have to understand wave propagation, I just
want a reliable network.

Speaking of which, I think Echelon will sell you transceivers without
the "Neuron chip" (the processor which handles runs protocol and
application code).  So in theory I could use their nice, reliable
free-topology transceivers without paying for their proprietary
protocol and development tools.  I could just plug it into an AVR and
write my own protocol.  This is seeming like an attractive option.

On the other hand, I could probably live with a data rate of around
28.8kbps.  At that sort of rate, if I have a slew-rate-limited RS-485
transceiver, I can probably get away with unterminated, mixed-topology
wiring, right?

-- 
Randall

On Wed, 27 Apr 2005 15:00:26 GMT, Randall Nortman
<usenet8189@wonderclown.com> wrote:

>On 2005-04-27, Paul Taylor <pault_rem_.ngea@virgin.net> wrote:
>> On Wed, 27 Apr 2005 03:18:20 +0000, Randall Nortman wrote:
>>
>>
>>> Wiring to 40+ locations within a house is hard, error-prone work.  I
>>> don't want to make it harder by requiring those nodes all to be
>>> daisy-chained and properly terminated (e.g., RS-485).  I need
>>> flexibility in the topology -- star, bus, or a mix of the two.
>>> (LONWorks wins on this point, with their "free topology" wiring, which
>>> lets you do whatever you like so long as total wire length is <500m.)
>>> Point-to-point serial (RS-232, RS-422) would require me to have 40+
>>> serial ports on the central controller.  No thanks.
>>> 
>>
>> No termination - I wonder how they do that? You need to match at the end
>> of the line to avoid reflections, unless slew rate is controlled so that
>> it is unecessary. I think the rule of thumb is slew-rate < cable
>> propagation delay * 10 - something like that anyway. A rough calculation
>> based on 5ns per metre, 30 metres of cable - max slew rate would be 10 * 5
>> * 30 ns. If you can live with the data rate that gives you then you don't
>> need termination, irrespective of the network topology, star, bus or
>> combination of both.
>[...]
>
>I think they avoid reflection problems by riding the data on a sine
>wave carrier of 5-40MHz, depending on which transceivers you use and
>how they are configured.  I'm not sure exactly what sort of modulation
>they use, but the effective communication rate is 78kbps.  I'm not an
>electrical engineer, but I think sine waves are pretty immune to
>reflections, right?  This stuff is getting into black magic territory
>for me -- I don't want to have to understand wave propagation, I just
>want a reliable network.
>
>Speaking of which, I think Echelon will sell you transceivers without
>the "Neuron chip" (the processor which handles runs protocol and
>application code).  So in theory I could use their nice, reliable
>free-topology transceivers without paying for their proprietary
>protocol and development tools.  I could just plug it into an AVR and
>write my own protocol.  This is seeming like an attractive option.
>
>On the other hand, I could probably live with a data rate of around
>28.8kbps.  At that sort of rate, if I have a slew-rate-limited RS-485
>transceiver, I can probably get away with unterminated, mixed-topology
>wiring, right?

The standard 78kbps lonworks transceiver is called FTT-10A.  There are
a couple of different modes of the Lonworks Transceiver interface that
is supported by the Neuron chip.   It is possible that it coud work
with the RS-485, but you should investigate that yourself.  

You won't be able to match the reliability of lonworks unless you
implment protocol that supports the various media access schemes,
error detection, and service types that lonworks does.  One of the
best features of lonworks protocol stack is that it supports remote
firmware update to flash via the network. 

regards,
Johnny.