The Mesh Potato

What do you call an 802.11bg mesh router with a single FXS port that automatically forms a peer-to-peer network and relays telephone calls without landlines or cell-phone towers? A Mesh Potato, of course.

Key Features

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.

Technical Overview

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 Story

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).

CPU Load

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.

Stuck Beacons and Ad Hoc Wi-Fi

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.

Have been installing some Open-Mesh networks in low income areas as well as local small network groups and this combined Mesh CPE and Voip ATA is the best invention I have seen since the Meraki Mini. (or OM1 - lol)

Since the analog signals from the phones are digitized, is there any encryption to at least keep the casual evesdroppers at bay?

Also is there any way that one could buy an unpopulated PC board, any proprietary chips and a parts list for the rest to make one at home? This looks like a really interesting way to establish a small, localized phone system.

Also, IIRC there was an ethernet block on the system diagram. Does that mean this thing could function as an RF LAN/WAN? If that were so secure comm could be handled by encrypting VOIP on a laptop.

This is a very cool device, kudos! I just got to wondering though...what would it be like to use ultrawideband? From what I've read, it's possible to get a lot more data throughput with a lot less power. The FCC doesn't allow it in the U.S. but maybe in the third world that won't be an issue...and it would be nice if they paved the way for us!

Mesh networking for analog phones is a good concept, but to be broadly useful it also needs to support digital communications, with computers or smart phones as the client devices. It would seem what while developing them, you ought to go ahead and enable them for broader uses.

My concern is emergency disaster situations, and here in the U.S., as elsewhere, emergency response will require the conveyance of data as well as voice. I have been involved in some disasters and data communications proved to actually be more important than voice communication. From maps to inventories, logistic control to medical imaging, ground-penetrating radar to biometric identification. The list goes on. We can use CB or handheld shortwave for voice. Data is the main need.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.