LONWorks vs. Ethernet

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,

-- 
Randall Nortman

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

Have you considered using Ethernet to serial converters?
There are plenty. You could use your TCP/IP link on your PC
and converters to serve a number of serially linked remote 
devices.

Hello Randall,

Depending on your target cost, chances are neither will be all that 
cheap. How about I2C plus one more strand for power? This bus was 
developed for in-system communication over a few feet but people have 
used it over hundreds of feet with very low clock rates. With active 
current sources you can drive it even faster over long distances. The 
nice thing about I2C is that you can get all kinds of chips for it and 
for each sensor you wouldn't need much more than that chip. Since most 
are for consumer apps they are usually low cost. Also, some uC come with 
built-in I2C and as icing on the cake they also give you C and assembler 
routines to save you lots of grunt work.

A bus like I2C solves another issue in a building. You can often simply 
string the cable as a daisy chain whereas an Ethernet must usually have 
a home run from each sensor to the central processor.

Check out the docs from a major I2C manufacturer such as Philips to see 
if this type of bus would be suitable. Whatever you do, mind the EMI 
issues. After all, you don't want the setup to error every time somebody 
flicks on a garbage disposer or an array of fluorescents.

Regards, Joerg

http://www.analogconsultants.com

On 2005-04-26, Lanarcam <lanarcam1@yahoo.fr> wrote:
>
> Have you considered using Ethernet to serial converters?
> There are plenty. You could use your TCP/IP link on your PC
> and converters to serve a number of serially linked remote 
> devices.

I haven't seen any Ethernet-serial converters for less than $100.  I'm
hoping the entire cost of each node will be around that price, or
preferrably less.

-- 
Randall Nortman

Randall Nortman wrote:
> On 2005-04-26, Lanarcam <lanarcam1@yahoo.fr> wrote:
> >
> > Have you considered using Ethernet to serial converters?
> > There are plenty. You could use your TCP/IP link on your PC
> > and converters to serve a number of serially linked remote
> > devices.
>
> I haven't seen any Ethernet-serial converters for less than $100.
I'm
> hoping the entire cost of each node will be around that price, or
> preferrably less.

Depending on your topology, you could have some converters, each
serving many devices over a RS485 local loop.

Randall Nortman wrote:

> 
> 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 have come across LONworks several times in the past, the first time being
in the late 80s when it first appeared and the last time was in the late
90s where I saw it used for an industrial control system.

At that time it was a good tool for the job, but even then the cost of
development kit, devices and licences were high. Also it had never had the
impact its creators had hoped for.

IMHO it is now out of date and has been superceded for applications like
yours by sensor network protocols. Google will help you find them.

Ian

"Randall Nortman" <usenet8189@wonderclown.com> wrote in message
news:3Cxbe.15333$go4.1654@newsread2.news.atl.earthlink.net...
> 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.

Sounds like a perfect job for a Linet network. Power and data over two
wires, no polarity issue, 20kHz sinewave carries data and power thus very
low EMI and no restriction on the topology (daisy-chain or star or a mix).
See www.linet-network.com for more info.

Meindert

The Echelon chips have 10 I/O pins for interfacing to devices. They can
be configured as 10 separate pins or they can have I/O drivers attached
to them for things like SPI, or for PWM, or pulse counting. And the I/O
pins could also be used as a bus to interface some other microprocessor
to the LONWorks network.

Back when I was using them, there were two chips: 3120 and 3150. The
former had all memory internal while the latter had an external
(program only?) memory interface. (I'm away from my Echelon books).
Motorola made the chips so you might check their (or Freescale's)
website for datasheets.

Way back when, the only way to develop was with their $20,000
LONBuilder. This provided full debug capability using emulators,
programming of LONWorks nodes, and a LONWorks network protocol
analyzer. A few years later, they came out with a cheaper development
device ($700?) but I have never seen one.

Software was written in a version of C, called Neuron C. The firmware
of the chip itself had a scheduler in it. You didn't have to worry
about network stuff much as far as programming went. You would declare
a variable as a network variable and when you (or someother node)
changed that variable, the value would get sent out on the network with
no work by your code. Code was written using "when" clauses (
when(reset){ xxxx} ). You could trigger a when clause on things like a
change in a network variable or in an I/O line.

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.

The wire capacitance probably the speed you could run over longer 
distances, but you're talking about 10bits/sec x 6 sensors = 60bps.  We 
used to push 9600bps several hundred feet, if not a couple thousand 
(imagine the distance from the ticket counter to the gate terminal). 
The limiting factor will probably be voltage drop and the volume of 
power each device will require.

Use a duplex wiring scheme (separate TX/RX) with a polled master/slave 
protocol.  The master always talks on one pair and listens on the other. 
  Vice versa for all other nodes.  Use a synchronous packet format with 
a block checksum / CRC to catch the errors.  When a node is polled, it 
answers with data or a NACK; if it doesn't answer for X cycles, it goes 
into the slow polling cycle as an offline device.

For power, supply it on two of the other wires in the sheath for 
simplicity.  You could run it over the data pair via phantom voltage, 
but the extra wires will be in the cable sheath anyway.  You'll need to 
observe power and voltage constraints to ensure a) you don't overheat 
the cable, and b) to keep it qualifying as a "low voltage" wiring 
(looser electrical code rules and cheaper installation).  Have the 
master unit limit the number of allowed nodes per cable to enforce the spec.

Wiring can be daisy-chained.  Nodes are identified by a) the cable 
they're on (i.e. port on the master), and b) their drop number, which 
can be set via eeprom (requires more address space in packets for 
guaranteed uniqueness) or dip switches (field simplicity, could be 00-FF).

There's a lot to learn from older systems that were designed to operate 
efficiently in some pretty adverse conditions.  Applying similar 
approaches can make for some pretty cheap solutions with today's technology.

HTH,
Richard

On Tue, 26 Apr 2005 21:02:26 GMT, Randall Nortman
<usenet8189@wonderclown.com> wrote:

>On 2005-04-26, Lanarcam <lanarcam1@yahoo.fr> wrote:
>>
>> Have you considered using Ethernet to serial converters?
>> There are plenty. You could use your TCP/IP link on your PC
>> and converters to serve a number of serially linked remote 
>> devices.
>
>I haven't seen any Ethernet-serial converters for less than $100.  I'm
>hoping the entire cost of each node will be around that price, or
>preferrably less.

Digi ConnectME is US$47 for single units, less in quantity. One serial
port, 10/100 Ethernet, 55 MHZ ARM, 8 MB RAM, 2 MB Flash, NetSilicon
PThread kernel, web server, ftp server, etc. etc. You can get the
Classic with write protected bootloader, or the Standard version with
all unprotected flash for Linux. The WiFi version has also been
released, but is more than twice the price. SDK includes a development
board with JTAG interface and McGraiger RAVEN debugger. There is also
a user forum on the Digi web site.

Bob McConnell
N2SPP