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.
FXS Interface

Low-cost Wi-Fi SoC devices are highly integrated. They have minimum hardware interfaces—just enough for their core purpose.

To support an FXS interface, we normally use a CPU that has some sort of Time Division Multiplex (TDM) bus to support one or more 64kb/s bit streams of speech samples. The TDM bus hardware then handles DMA of the speech samples, presenting them as buffers to the device driver.

Every chip I have worked on in 20 years of telephony hardware design had a TDM bus. The AR2317 has many other features we need (low cost, Wi-Fi, OpenWRT support), however, there's no TDM bus!

So, I worked out a scheme to send and receive speech samples via the RS-232 console port, using some external glue logic and a small microcontroller to buffer the speech samples. It's not elegant, but it's reasonably low cost and it works, allowing us to use a low-cost AR2317 SoC for a very different application (VoIP) than it was designed for.

As the speech samples arrive in the RS-232 port, they are buffered by the SoC serial FIFO. When the FIFO fills, it interrupts the CPU every 1ms. Now, 1ms is a very high interrupt rate. What this means is every 1ms, the CPU must stop what it's doing and run the Interrupt Service Routine (ISR). This can cause a big performance hit, as the instruction cache contents must be flushed and replaced every 1ms.

To minimise this performance hit, I rewrote the Linux drivers/serial/8250.c interrupt handler to be as small as possible (Listing 1). This is small enough to consume only a tiny amount of valuable instruction cache and is likely to stay resident in the cache between interrupts. The functions it “calls” are either macros or very short inline functions.

Small Team, Big Company and Calibration

Being a small team on a modest budget, we have experienced difficulty obtaining all the data we require from the SoC vendor, Atheros. This is a problem with some chip vendors. Unless you can pay big up-front fees or have a one-million chip order pending, it is hard to get support or even basic data. This is a pity, as I feel many chip vendors rely increasingly on the Open Source community for their firmware and build tools and hence their chip sales. Also, we are trying to design a mass-market product that will sell more of their chips.

This is not true of all chip vendors. Analog Devices has been very helpful with the IP04-based open hardware embedded IP-PBX (see Resources) that uses the Analog Devices Blackfin CPU. The company provided comprehensive data, time from many support engineers and even funded some of the IP04's development.

One particular problem area with the AR2317 has been RF calibration. Each AR2317 chip is slightly different and must be calibrated on the production line using automated test equipment. The software to perform this calibration and even the calibration registers' documentation is very closed. This has made it hard to calibrate our prototypes to obtain optimum RF performance.

However, where there is a will, there is a way. With Atcom's help, we have teamed with other Wi-Fi router vendors who have the required calibration equipment on their production lines.

Testing the Alphas

In early 2009, we started design of the actual custom Mesh Potato hardware. By the middle of 2009, we had built approximately 20 prototype Mesh Potatoes, and in July, we held the second Village Telco Workshop to test the alphas and plan the next phase of the project.

Server-less Asterisk

One nice demo was a simple Asterisk dialplan, placed on each Mesh Potato:

exten => _XX,1,Dial(SIP/4000@10.130.1.${EXTEN})

This allowed us to construct a serverless, peer-to-peer voice network. This dialplan takes a two-digit number XX and lets you dial another Mesh Potato with the IP of 10.130.1.XX. It's an instant local phone network on just a few watts/node, no server required (let alone a cell-phone tower or central office exchange). Simply switch on your potato, and you can make calls. Imagine the applications for Katrina-style disaster situations where you need instant communications.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The best Mesh / Telecoms Idea I have ever heard of...'s picture

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)

I cant wait to test some of these.

Congratulations from Spain.

PS: Please tell me how I can test some Patatas and your Dashboard Control / Provisioning System:


Bad Cyborg's picture

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.


Anonymous's picture

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!

Digital Comm on Version of Mesh Potato

Jon Roland's picture

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.

Data Comm on the Potato

Anonymous's picture

The block diagram indicated an ethernet connection. That should take care of data transport needs.