LONWorks vs. Ethernet

and

still,

Linux

the

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

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

I'm

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

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

for more info.

Meindert

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

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.

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

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

[...]

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

[snip]

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

Gunnar.

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

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

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.

Ethernet sounds like a massive overkill.

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.

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.

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

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üßen

Frank-Christian Krügel

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

[...]

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

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.