JavaScript is disabled or not working. Turn On JavaScript and get awesome text here with every click.

Project WBTV: Embedded publish/subscribe protocol

This project is still not finalized, by here it is. in some ways it is the sucessor to Gazebo, correcting a lot of the mistakes that were made. The basic idea is this: an open source serial communication protocol that allows any number of devices to communicate over a single bus(Either a single wire with a pullup, or using CAN signalling levels), with no central node and no polling required. If you have a message to send, you send it. If someone else talks over you, you both stop and you wait and retry after a random time, just like the original Ethernet.

WBTV is channel based rather than address based. You don't send a message to device 4, you send it to channel 76. This might seem limiting, but in WBTV, channels are arbitrary length binary strings. You could have a UUID channel "Owned" by a specific device, and know that whenever you recieved data on that channel it was a temperature reading or whatever that channel was for.

Devices don't need you to set their adresses, they just send and receive on the channels they own. Because they are UUIDs, anyone can define a reserved channel. Channels with less than 6 characters are reserved, and the specification defines several reserved channels, including one for time synchronization. Messages include the estimated precision so devices can ignore all but the best time source.

WBTV can easily run 50 feet using simple TTL signaling and a 4.7k pullup at 9600 baud. Python and C implementations both exist, and the protocol is defined for both shared buses and dedicated full duplex links. Performance is pretty good even with UUIDs because there is no polling required which is a major use of bandwidth in other protocols.

WBTV has several "reserved channels". In fact every channel name less than 6 bytes is reserved. Single byte channels are reserved for manual assignment as in other protocols. This means that certain common features can be much more intercompatible

For example, the TIME channel is for time broadcasts in a specific format. Time broadcasts are UTC, they have 64 bits of resolution plus a 32 bit fractional part. Typical accuracy can easily be within milliseconds or even less. Time broadcasts contain an estimated maximum error so that if multiple devices are sending TIME messages devices can listen to the most accurate one.

WBTV Also supports things like device discovery and identification natively. WBTV device ID's are 16 byte UUIDs so you do not need to buy a vendor ID or a EUI to create a device. The concept of a "Service Channel" is defined, which is a channel owned by a device that acts as an interface according to a specification. For example, a plant monitor could implement a "Soil Moisture Sensing Service", or just a generic "Analog Sensor Service", on channel XYZ. The sensor could then periodically broadcast messages on that channel according to the format specified by that service.

Services are also identified by UUIDs, meaning anyone can define and publish a new service. A device providing a service can announce it on the special SERV channel when it is first powered up making device discovery pretty simple.

Services also have what are called "Modifier Bytes" that allow a device to provide additional information about it's services. For example, a device providing a "Generic Analog Sensor" service could use the modifier bytes to describe what exactly it was sensing. Modifier bytes are sent along with the service UUID in the SERV announcement

For daylight savings time handling the special TZOS channel is provided which contains the current offset between a specified time zone and UTC, and the TZRQ channel allows a device to request the offset of a particular zone.

The RAND channel is for HW random number generators, but was mostly included in the spec for testing and should be used with care. Messages must be strings of high quality random bytes such as would be generated by a properly processed noise diode or such.

And of course, for short pieces of non-machine-readable data, the INFO channel is provided for things like printing a copyright notice on powerup, or a company URL

The C++ Arduino reference library will automatically keep track of the current time in UTC based on time broadcasts on the network, and is tuned for best accuracy, and also contains an XORSHIFT RNG that is automatically reseeded continually based on the exact timing of incoming packets or(on request), the internal temperature sensor. The internal RNG is not good enough for cryptography(Unless you reseed from the temp sensor before every byte generated), but tends to pass pretty much all statistical tests very well.

WBTV Supports error detection via the very simple two's complement Fletcher checksum. Packets begin with an exclamation point, then comes the channel name, then a tilde, then the data, then the checksum, and then a newline, meaning if you view it on a serial terminal, each message will be on it's own line.

WBTV works well as an interface between the computer and the Arduino, and the reference library for both Arduino and Python can be found on github

You can also download an early draft PDF here: link. Even though this is an early draft a few projects already use it so it is unlikely to change, but no guarantees are made