New field bus, expressions of interest

Hi All,

For several months now I have been designing a microcontroller network (field bus), originally for monitoring and control of devices in an RV (motorhome, campervan, caravan etc.) but now I see it as being useful in any environment. It started as a small project for my own use but has grown into something probably too large to fully implement as a one-off just for myself.

The reason for this post then is to gauge interest from other developers. The project would be open (I would propose a similar model to Arduino whereby designs/code etc are freely available but PCBs, made-up hardware etc are for sale) but I would like to know if at least a few people are interested enough to comment on the design, add ideas, build Nodes or an interface shield, or write PC-based control software.

The network is currently called "BUSnet" and some of the main features are itemised below.

Yes I know there are dozens of existing field busses around, everything from diode mixing to Lonworks and Profibus. But I feel that they are either too simple with no defined protocol or too complex and expensive. BUSnet will be released under some combination of CC/GNU license (yet to be figured out) so the designs will be available for free. And the hardware basically boils down to a LIN transceiver available for $2 from just about anywhere. And yet BUSnet is well enough defined up to a high level API for a Node made by me to talk to a Node made by you.

Note that the feature list is pretty long, however it is envisaged that most of this will be transparent to Node designers should they wish to interface with one of the pre-programmed ICs. Thus an Arduino, a Picaxe, an ARM or any other processor could talk to BUSnet with just a few ASYNC commands and a single line-driver chip.

Also pre-programmed IO chips are defined so a simple Node can be built with no programming at all.

Main features.

  • Open standard, no royalties, licencing fees or costs for intellectual property. Creative Commons and/or GNU licenses will apply.

  • Small Nodes, a Node can be implemented with as little as four components and fit on a PCB less than 12mm square.

  • Develop your own Nodes using just 4-5 components and a few commands over a 4800bps ASYNC connection

  • Suitable for retrofitting to older vehicles.

  • One master control processor (MCU) that controls a network of slave nodes.

  • Provision for multiple control units (NCNs).

  • 58 physical addresses each with up to 255 IO Points giving a theoretical total of 14,790 Points.

  • Implements a "publishing and subscribing" model with 192 logical addresses for common objects and events such as holding tank levels, battery bank voltages etc.

  • Very fault-tolerant physical level (uses LIN transceivers).

  • High level of error detection for reliability.

  • High level of safety with “interlocks”, “feedbacks”, “timeouts”, four security levels and optional hardware to stop rogue Nodes hanging the bus.

  • Three-wire network cable includes power and data signals.

  • Provision for Nodes to be connected with two wires (or even one wire) using existing cabling and/or body frame.

  • Flexible wiring topology, “anything goes”.

  • Plug-n-play, automatic allocation of addresses when a new node is plugged into the network.

  • Usable at a basic level with NO programming, just plug in hardware.

  • Scaling and non-linear transforms can be applied to sensor readings.

  • Direct Memory Transfer (DMT) of data into a Node's or MCU's memory.

  • Event logging with 100mS resolution.

  • Points can read/display metric or imperial values.

  • Peer-to-peer communications allowed under MCU supervision.

  • Vendor-defined commands.

  • Three energy-saving modes.

  • Bit rate sensing so Nodes can use cheap processors with no crystal.

  • Hard reset of Nodes possible with no special equipment.

  • Uses off-the-shelf standard electronic components.

  • Human-perceptible real time operation using interrupts.

  • Expandable, start with an MCU, an LCD display and a single NCN, then add features over time.

  • Use the processor of your choice; AVR, PIC, Picaxe, ARM, 8051 etc.

Any and all interest appreciated.

Regards
Rob

Hi again,

Couldn't add a live link to my original post because it was my first post to this forum, however you can visit www.robgray.com/busnet/index.php for more detailed information and to download spec PDFs.

Rob

My network experience is mostly with larger networks than your "field bus", but here are some comments:

  • Bit rate sensing so Nodes can use cheap processors with no crystal.

That sorta nice. Are you talking about the 4800bps async connection between the MCU and the hypothetical network controller HW, or on the fieldbus itself?

  • High level of error detection for reliability.

I didn't see anything in the summary about retransmission/etc. An 8bit CRC is a "high level of error detection" ??

  • Scaling and non-linear transforms can be applied to sensor readings.
  • Points can read/display metric or imperial values.
  • Use the processor of your choice; AVR, PIC, Picaxe, ARM, 8051 etc.
  • Suitable for retrofitting to older vehicles.

IMO, these are not things that belong in the definition of a network, or they go without saying.

  • Human-perceptible real time operation using interrupts.

What you describe in the summary is NOT "real time" as used in the industry. Real Time means deterministic and predictable, even if it's not really "fast" by modern standards. You want a term like "low latency operation using interrupts" or something. Calling it "real time" will get you laughed at.

  • Usable at a basic level with NO programming, just plug in hardware.
  • Direct Memory Transfer (DMT) of data into a Node's or MCU's memory.

These both assume existence of certain hardware that may or may not be available. The first is dependent on having basic "off the shelf" node chips for certain functions. The latter is dependent on the MCU used; I don't see how you'll get DMT (DMA?) on PIC, PICAxe, or most AVRs, for instance.

Hi westfw,

Thanks for taking the time to have a look and comment.

  • Bit rate sensing so Nodes can use cheap processors with no crystal.
    That sorta nice. Are you talking about the 4800bps async connection between the MCU and the hypothetical network controller HW, or on the fieldbus itself?

The first byte of any command frame sent by the MCU (which is crystal controlled) is 0x40 which allows time for a node to wake up then time the last few bits to get the baud rate.

I didn't see anything in the summary about retransmission/etc. An 8bit CRC is a "high level of error detection" ??

True, there will be retries by the MCU but I admit that's not been defined well so far. As for the "high level of error detection" that probably should have had "for the intended application" added. As you say by normal standards an 8-bit CRC (actually it's really just a check sum) is not fantastic, but for the intended use I think it's reasonable.

  • Scaling and non-linear transforms can be applied to sensor readings.
  • Points can read/display metric or imperial values.
    IMO, these are not things that belong in the definition of a network, or they go without saying.

True, there's probably a lot of things I define that aren't technically part of a "network", I'm really defining higher levels, even up to the application level, and PCB sizes in an attempt to have a level standardization not common in simple networks. The idea is that a Node designer doesn't have to know about conversions, just define what kind of data the Node wants.

Suitable for retrofitting to older vehicles.

This refers to using existing wiring, you don't have to run new coax around a 30-year-old bus.

Use the processor of your choice; AVR, PIC, Picaxe, ARM, 8051 etc.

Just want to spell it out I guess.

What you describe in the summary is NOT "real time" as used in the industry. Real Time means deterministic and predictable, even if it's not really "fast" by modern standards. You want a term like "low latency operation using interrupts" or something. Calling it "real time" will get you laughed at.

Good point, in fact this network is relatively non-deterministic and non-predictable although responses should happen within 100mS or so. I'll think about rephrasing this.

  • Usable at a basic level with NO programming, just plug in hardware.
  • Direct Memory Transfer (DMT) of data into a Node's or MCU's memory.
    These both assume existence of certain hardware that may or may not be available. The first is dependent on having basic "off the shelf" node chips for certain functions. The latter is dependent on the MCU used; I don't see how you'll get DMT (DMA?) on PIC, PICAxe, or most AVRs, for instance.

You're right and I plan to have at least two pre-defined IO chips to start with. As for the DMT, it's really more a bulk data transfer that a Node can place where it likes (hence my not using the term DMA). Once again possibly a new term would be better.

Regards
Rob