Mesh Potato Tests

We have made good progress on the Mesh Potato (MP) so far. The basic functionality (making phone calls over a Wifi Mesh network) is working OK. Over the past few weeks Elektra and I have been concentrating on several specific areas of the MP and testing them in more depth. This posts focuses on some of the tests I have performed, the bugs found, and the final results.


One simple stability test is uptime. I have left both my MP prototypes running for up to 5 days at a time with good results – Linux and Wifi stayed up, and we still had dial tone from the FXS port. This simple test says a lot: e.g no memory leaks, CPU instability, drastic over temperature problems.

Another test I like to do to all my telephony devices is hammer them with phone calls for 24 hours. Here is the test set-up:

Stability Test

Stability Test

An x86 Asterisk box acts as the call generator. It starts a new call to the MP. When the MP receives the call it starts the FXS port ringing. Another Asterisk box (an IP04 with an FXO port) answers the call, plays a prompt for a few seconds, then hangs up. The entire sequence is then repeated – make thousands of calls over a 24 hour period. The SIP call is placed over Mesh Wifi to make sure all parts of the MP system are being exercised.

This test gives the MP quite a hard time as much of the call processing load is involved in set up and tear down of calls, and unless you are my teenage daughter you can’t really make 3500 calls in 24 hours.

When I started the tests it threw up problems nearly immediately – Asterisk was seg faulting with no feedback as to why it was crashing. This led to a week of fun and games where the problem was eventually traced to thread problems in the Asterisk channel driver I had written (chan_mp). This channel driver has been a painful experience for me (even though I have written a few before), and has taken perhaps 3 weeks of part time work to write and debug. Lots of fun with threads and null pointers. Even now I still don’t quite understand all the issues around Asterisk channel drivers. I would appreciate a code review of the driver if there are any Asterisk channel driver experts out there.

Anyway I finally tracked down the source of the problem and modified the channel driver. It passed the 24 hour stability tests and made 3500 calls.

Mesh Load Test

This is a repeat of the load test from Phase 1 of the Mesh Potato Project, but this time on the actual MP hardware with the FXS driver running:

Mesh Load Test

Mesh Load Test

A big difference between the Village Telco and Cell Phone network is no base stations (Cell Phone Towers). Instead, the calls are routed via the client nodes. It’s a peer-peer network rather than a client-server architecture.

The idea of this test is to make sure that a given mesh potato node can relay 15 phone calls for other people while simultaneously making a phone call of it’s own. This scenario places significant CPU load on the router due to the number of Wifi packets that must be processed at the same time as DSP intensive code like echo cancellation and speech compression.

The set up details of this test are on the wiki and have been blogged about earlier. Speech quality was fine, and loadav about 0.71, similar to the Phase 1 results. Occasionally I could hear some packet loss but overall the call was fine. A good result considering all that processing (Linux, Wifi, mesh, Asterisk, echo cancelling, GSM speech compression, FXS driver) on that little router chip!

One interesting fact is that even with a total of 16 calls the bit rate is only around 500 kbit/s, so the bandwidth of the mesh is quite lightly loaded. However speech packets are rather short, so raising the number of phone calls would likely run into CPU load (rather than Wifi bandwidth) issues due to the per-packet processing load.

Wifi Range Test

Wifi is mainly the domain of Elektra and Jeff on this project but I was keen to get some rough idea of how well the radio was working. I had made a few calls around the house OK but noticed that the received signal level was quite low. A bit of thought led us to a static protection diode we had placed across the antenna circuit. Although a good idea for the RX side it was conducting when transmit signal was present. After removing this diode the TX level jumped right up to roughly comparable levels to a DIR-300 router that uses the same Atheros AR2317 SoC.

However using radiated signal levels it is hard to get consistent results, they bounce around all over the place. Jeff suggested connecting a combination of DIR-300 and Mesh Potatoes in A-B tests via cables and calibrated attenuators to obtain consistent measurements.

Over a few days I made several attempts at range tests. However where I live is quite flat so it’s difficult to get a good Line-Of-Sight (LOS). I did manage to make phone calls over about 250m which is pretty much what we need for a Village Telco Network.

Elektra and I feel the radio performance could probably be improved with some adjustment of the RF circuit components and possibly PCB layout. Elektra has access to a RF test lab later this week so we will get some more concrete information of Wifi performance.

One area we really need more information on is radio calibration data and the Hardware Design Guide document for the AR2317, however we have been unable to obtain this important information from Atheros.

More blogging to come from Elektra on Wifi radio and power supply performance.

Tags: , , ,

7 Responses to «Mesh Potato Tests»

  1. July 02, 2009 at 6:38 pm, Fowl said:
    With such low utilisation of the WiFi, would it be possible to reduce the xmit speed to increase reliability. I know when I force my little home AP to 11mbps I get much better range.

  2. July 03, 2009 at 11:51 pm, Beer, Coffee, and a little DSP » Blog Archive » Mesh Potato Testing and Free Potatoes said:
    [...] and I have been busy testing our Mesh Potato prototypes. I have been working on Asterisk stability and mesh load testing, while Elektra has been focusing on the power supply efficiency and [...]

  3. July 06, 2009 at 11:24 am, David Rowe said:
    #Fowl - yes good idea, it would be worth testing a lower bit rate to increase range. One possible trade off is collisions, with a high bit rate the chances of two packets colliding is low. - David

  4. July 06, 2009 at 12:50 pm, elektra said:
    We are using the Ministrel rate control algorithm - there should be no need to override the automatic rate control by hand. Ministrel can choose from all available data rates in 802.11b/g (1,2,5.5,6,11,12,18,24,36,48,54 Megabit) and it will determine the best speed for each neighbor node that it can talk to. Lower rates have better receiver sensitivity and more transmit power. Hence fixing the speed to a certain data rate is not recommended for the overall performance of the network.

  5. January 08, 2010 at 8:20 am, paolo del bene said:
    Pleasure to contact you Elektra, we saw to the Ninux Day in November to the Defrag_ i have any query for you : how telco such Telecom generate the signal necessary to phone ? our trunks in italy are from 2040 to 2400 Hz if they generate a signal, i suppose is necessary to have a generator of signal correct or wrong ? the interest is to bypass the Telecom, classic TELCO and generate the signal which is necessary to phone, then i would like to know how they provide to shift from classic line to ADSL or to any other request of service. this could be interesting don't pay anymore the service to TISCALI. Other thing: router wi-fi can't distribute internet service, to work they need to be in combination with router or modem wi-fi, or to sniff the service of any other person, or to be connected to an network that is intentioned to offer internet for free and gratis, why is interest is the sharing, help the neighbour and why internet is a cultural heritage which belongs to the hackers. so a router wi-fi can't be connected directly to a line ADSL, is possible to work on layers ? or is totally impossible ? Have a GNU Year 2010 from Paolo

  6. January 08, 2010 at 5:38 pm, Elektra said:
    Hello Paolo - I'm not sure I got your first question right. Do you mean the dialtone? It is generated by Asterisk AFAIK and can be customized to match the dialtone in your country. By default we use the US dialtone. Regarding ADSL and Internet sharing: A Mesh-Potato does not contain a ADSL modem. But a Mesh-Potato can be connected to the LAN port of a ADSL modem. The MP can be configured as mesh Internet gateway, so people in the mesh can share Internet access. Given that you don't want to do things like advanced traffic shaping, as the MP doesn't have much CPU power. The MP can also be configured to provide Internet access to a LAN segment connected to the Ethernet port, using the mesh as Internet uplink. Cheers, Elektra

  7. January 09, 2010 at 3:46 pm, paolo del bene-iw0fzw said:
    thanks a lot ! Paolo p.s: a question for you but i don't know if you can help me I have a box of liquorice, since it is metal, I wanted to use it to put forward a few watts who has the USB Side Up Band and LSB Low Side Band and operating on the frequency of 7 MHz, would be nice to put a GNU DSP can i find something in internet? you have any news for me?

Leave a Reply