Open source CANbus alternative/pubsub over uart/message passing project

Projects Networking, Protocols, and Devices
1

So, about a year ago I spent about a month designing a protocol called Gazebo, which had automatic device discovery and a whole bunch of other crazy features. But it had a few fairly major issues that annoyed me, largely that it was bloated and hard to use.

But that didn't change the fact that when you do interactive art, communication between devices is pretty much essential. So, I took what I learned from Gazebo(Namely, bloated==bad), and started from scratch with a new project called(for now) WBTV.

The basic idea is to take the CANbus concept, where you just blast out messages into the aether tagged with a message ID, and extend it to a true publish-subscribe system. Devices can send messages containing an arbitrary length 8 bit piece of data, associated with an arbitrary length 8 bit channel name.

So, for instance, you might have a channel "outsideTemperature", and a device constantly sending the temperature on that channel.

The physical hardware is pretty easy, it's just UART+ a diode to make it act like open collector and a pullup like you would use for i2c, or, I'm pretty sure you can use canbus trancievers, as CAN is wired or too.

There's no master node, devices talk when they want and back off for random amounts of time(There's a built in xorshift-32 RNG that gets seeded from various places, and the library provides user access to it.)

Some channels are reserved, like an channel with <6 chars in the name. There is one channel, TIME, that is reserved for synchronizing clocks. TIME broadcasts have an error estimate in them, and the library will ignore broadcasts that are less accurate than the current internal estimate.

Time broadcasts are of course handled automatically by the library.

You can have multiple interfaces on a board if you have multiple UARTs, and a point-to-point version is defined that doesn't use the wired or arbitration stuff, so you can use it to communicate between the arduino and the PC(There's a python lib in the works but it isn't currently very well documented)

Right now the example sketch that broadcasts the value of an analog pin compiles to 3,242 bytes for the duemilenove, so it's definately low-flash use.

I'm also working on a standard way for a device to choose a UUID as a channel randomly, then broadcast the format of the data it plans to send via another reserved channel.

Everything is up on github but it's still alpha quality and may or may not compile at any given time, and everything is subject to change especially if I get some feedback.

2

WBTV...just rolls off the tongue eh? :slight_smile:

Do you have any specs as to the latencies involved, it seems that a frame/packet would be pretty large what with the UUIDs and (I gather) the ASCII format.

Rob

3

Well, base packet overhead is about 1-3 bytes random waiting time, 1 start of header byte, 1 start of data byte, 2 bytes of checksum, and 1 byte that marks the end.

If you just use it as a hobbyist/low grade replacement for CANbus, with one byte channel names and a few bytes of data the performance will be a little less than canbus.

If you use UUID channels, then you add 16 bytes(plus a few more if any of the bytes in the uuid are a control character needing escaping), and with an eight byte payload you would be up to 35 bytes, a little more than twice the length of a modbus read request you get about 35 bytes.

Its not an actual ascii protocol, it just requires escaping your control bytes which only adds a few percent in the average case
Compared to doubling the message like sending data in hex would.

The advantage comes when you have user inputs that rarely change, you can send the "button pressed" signal only when needed, and the "knob turned" signal only when the knob is turning.

But for sending commands to devices quickly it is much slower. Bulk data transfer speeds are slightly better than can and comprable to i2c because you can have packets with 100+ data bytes.

The UUID channels are a huge speed penalty, so there needs to be a standard way of assigning one byte channels to devices.