M-o-a-T bus

The MoaT bus

MoaT devices are small(ish) embedded computers.

They want to talk to each other, and/or to some central controller … but not too central, as we'd like to avoid single points of failure.

The problem

First we need some way to send messages between our devices. So, wires or radio?

The MoaT bus obviously doesn't use radio, it's a bus after all, for multiple reasons:

  • Some older homes have thick walls which shield some rooms quite effectively

  • Mesh topology requires always-on RF receivers

  • Batteries need frequent replacement or charging

  • RF interference may cause annoying delays

  • Good RF hardware isn't free

So, wires. MoaT won't touch the wall power wires, though:

  • line voltage is dangerous and not recommended for hobbyists

  • data transfer on top of power lines is not trivial

  • air gaps required on circuit boards

  • The hardware required to transmit over line voltage is even more expensive

So, low-voltage wires. The next question: how many wires? The minimum would be two, but multiplexing data onto power again requires more silicon and isn't too efficient over longer distances.

One good example of a 3-wire protocol is 1wire. (You can use it with only two wires, but parasitically powering more than one microcontroller is out of the question.) Unfortunately, 1wire is not suitable because the protocol does not allow multi-master operation and its timing is too critical for reliable implementation.

Another standard protocol using just two wires is KNX. Again, the interface IC isn't free and the protocol is somewhat convoluted. Also, 9600 bits/second might be too low. On the other hand, it's reliable, and the interface is not prohibitively expensive and can supply 3.3V to the controller.

4-wire buses

Common 4-wire buses include I²C and CAN.

For home automation, CAN is a less than optimal choice:

  • it's supposed to be a strict bus topology

  • bus wires are supposed to be balanced twisted-pair

  • messages are very short, requiring additional software effort

  • It really wants a pair of twisted wires. Not every cable has them.

While it's possible to run the CAN protocol on a single open-collector wire, there's still significant overhead and tight timing requirements. There's also no good way to scale up to multiple wires unless we're using software implementations – and if we do that, we're not bound by CAN's restrictions anyway.

I²C is also not quite useful. A single wire just for the bus clock seems excessive. Also, most µC implementations have severe problems when the data isn't clean. This can't be guaranteed in a heterogenous environment with long wires.

The solution

The central observation MoaTbus is built on is that on a multi-wire system, every transition on any wire can carry information. Thus, using a n-wire bus, we can transmit log2(2^n-1) bits of information per clock tick.

We still need to transmit binary data. The optimal message size on a two-wire system ends up as 7 transitions which carry 11.094 bits of information (log2(3^7)). Using three wires, we can send 14.036 bits with 5 transitions. This seems rather optimal. Four wires already show diminishing returns, so MoaTbus selects 11 bits again (log2(15^3) = 11.7).

In theory it's possible to further increase the bit rate by e.g. sending one or two 2^n signals after every 2^n-1 signal, but the math shows that the added complexity isn't worth the effort.

Since a message can contain excess bits, we can use an "illegal" sequence to terminate the message. Our messages thus don't need a length byte and can be generated on the fly if necessary. Residual bits can also be transmitted this way, thus compensating for signalling whether a fill byte inserted at the message's end is "real".

Other physical layers

MoaTbus as a protocol is reasonably independent from the 2…4-wire protocol described here. Obviously there are other ways to transport these messages.

Serial

Not a bus, so there's no address assignment. However, packetization is required.

All bytes not sent as part of a packet are assumed to be console data (ASCII or UTF-8).

For further details, see moat-serial.

I²C

Bus addresses are assigned by the master, based on free addresses found when bus scanning.

For further details, see moat-i2c.

KNX

KNX hardware may already be present, so why not recycle it …

For further details, see moat-knx.

Air

TBD.

Data layer

MoaTbus is a master/slave system. There is a provision for intermediate systems which can forward data with minimal internal state.

Slave systems do not talk directly to each other, except when they do (or rather, are told to).

For further details, see moat-protocol.