The Mesh Potato

The Mesh Potato runs B.A.T.M.A.N. (see Resources) mesh routing software, Asterisk, the Speex voice codec and Oslec echo cancellation. No cell-phone towers, no landlines, no big Telcos are required. Local entrepreneurs can roll out their own Village Telco system using a modest server and a bunch of Mesh Potatoes—community-owned telephony.

The mesh network is self-organising and self-healing. If a node goes down, B.A.T.M.A.N. automatically re-routes the calls. We are building custom hardware specifically for developing communities using open hardware and software principles. I am intrigued by the idea of developing custom open hardware devices—no need to accept whatever is available off the shelf. Most of the value in any router-type product is delivered by the software, which these days is usually Linux. The idea of relying on closed, proprietary, not-quite-right hardware is obsolete.

The Mesh Potato is as open as we can make it. We have minimised binary blobs and deliberately chosen open over proprietary software. The Mesh Potato is Atheros-based, as this allowed the use of the MadWifi open-source WLAN driver. We use the Speex and GSM codecs instead of g729 and Oslec instead of a proprietary echo canceler. The hardware schematics are available on-line.

The Mesh Potato will be mass-produced in large numbers. Open projects like this will start to exert influence over future telephony systems. For example, if 1,000 Village Telco operators are trunking calls encoded in Speex, VoIP trunk operators will need to support Speex. This represents an important paradigm shift. The Open community now has a chance to set standards, rather than have to play along with “standards” based on closed hardware and software.

I have developed open hardware telephony products in the past, including the IP04, which is manufactured by Atcom (see Resources). So it was natural that we team with Atcom for the board-level PCB layout and volume manufacture of the Mesh Potato. Atcom is a VoIP hardware company from Shenzhen, China, that understands and embraces open hardware and open software. Atcom is handling the board-level PCB layout and volume manufacture of the Mesh Potato.

Figure 5 is a mud map of the Mesh Potato hardware. The Mesh Potato uses an Atheros AR2317 System-on-a-Chip (SoC), which is a very low-cost router chip that combines an MIPS processor running at about 200MHz with 802.11bg Wi-Fi. It has built-in interfaces for LEDs, SDRAM and serial Flash. Best of all, it is well supported by OpenWRT and MadWifi. The FXS hardware, drivers and other firmware we have developed are generic. It is possible to port them to other router architectures. In very high volumes, it would make sense to integrate the FXS chipset functionality onto the SoC.

Figure 5. Mesh Potato Hardware Architecture

Development of the Mesh Potato kicked off in September 2008. Along the way, we had a few design issues and many challenging bugs to fix. As part of the open design philosophy, we have documented the design and even some of the “bug hunts” on the Village Telco blog (see Resources).

A key question was CPU load. Could a humble router CPU support Asterisk, a speech codec, an echo canceller and route several other phone calls over the mesh at the same time? To answer this question, we designed a test with all of these software modules running at the same time. As this was in the early days, and we didn't have any FXS hardware, we simulated the speech samples coming from the FXS port.

To model the maximum load of the system, we thought about a worst-case scenario of one mesh node routing 15 phone calls for its peers. This means the node would have to receive, then re-transmit, voice packets for 15 simultaneous phone calls. At the same time, the node had a phone call of its own, which meant the speech codec, echo canceller and Asterisk were all running. To test this scenario, we set up some Asterisk boxes to generate calls and used commodity Atheros Wi-Fi hardware to run the prototype Mesh Potato firmware.

The test passed. Call quality was maintained, provided we used 80ms voice packets to reduce the overhead of many small VoIP packets.

The MadWifi driver had a nasty “stuck beacon” problem that was specific to ad hoc mode, which is required for mesh networking. Nodes attempt to adjust their internal clocks based on reception of beacons from other nodes. Under certain situations, this caused a race condition, which locked up the driver's transmit queue. This means the driver would stop working for about 30 seconds.

Elektra worked hard with the MadWifi developers to establish and test a workaround. The driver is started in access-point (rather than ad hoc) mode, and then we create a virtual ad hoc access point that does not transmit beacons:

$ wlanconfig ath0 create wlandev wifi0 wlanmode adhoc nosbeacon

Beacons are unnecessary for our mesh network, and B.A.T.M.A.N. broadcasts its own packets at regular intervals. In access-point mode, there is no attempt to adjust the MAC clock, so the race condition is avoided.