I am interested in tools and techniques that can make setting up a Village Telco network easy for a moderately geeky “guy in the Village”. This is really important for rapid adoption of the Village Telco in the developing world. People need to be able to install, debug, and tune mesh networks without resorting to 1st work Wifi experts, or learning how to be Wifi experts.
Our experience with the Mesh Potato has been encouraging. For example the team in Dili has trained many local Timorese to set up and configure Mesh Potatoes. However about 20% of the nodes have problems with mesh network links. So for the recent Village Telco Camp in Cape Town the team decided it was my role was to explore link tuning tools.
To date we have been using Linux command line tools to help set up our mesh networks. However for the past week we have been exploring the use of audio link tuning tools.
Imagine you are installing a Mesh Potato:
Typically you will be on a roof in bright sunlight with one hand aligning the Mesh Potato. Using an audio interface through the Mesh Potato telephone has several advantages:
- You don’t need to buy a laptop, or risk taking it onto a roof.
- You can listen to a single-piece phone one handed (although dialling requires two hands).
- A phone works in bright sunlight
- Anyone (even the illterate) can use a phone.
- A phone works straight away, it doesn’t take several minutes to boot.
- The phone is powered by the Mesh Potato FXS port, so it won’t run out of battery.
- Phones are much cheaper than a laptop, especially critical for people in the developing world.
- If we get it right, an audio signal will be easier and more intuitive to use than reading and interpreting.
So how can we use a phone to tune a mesh link? Well lets look at a the laptop method first. The technique Lemi (the Timorese leader of the Dili Village Telco) and I use is to connect a laptop to the Mesh Potato, telnet or ssh into the Mesh Potato and use ping:
$ ping 10.130.1.1 -s 1400 -c 100
The “-s 1400” option sends large packets (close to the MTU) which stress the Wifi link. Experience in Dili has shown that if we get a packet loss of less than about 10% the link will be OK for voice calls.
OK, so somehow we want to “hear” the ping results in a telephone handset. So we need to work out how to “visualise” or “map” the ping statistics to sounds in a handset. This is a little hard to imagine so I took the experimental approach – I hacked the iputils ping to output sound on an x86 Linux machine. Once mature, we can move the audio ping algorithm across to the Mesh Potato, where it can run as an Asterisk application.
The information I think is important is packet loss, jitter, and delay over the link. I have tried to map these quantities to an audible signal.
Here are some examples of my first pass. Click to listen.
One ping packet is sent each second. Each time a packet is sent, we make a 400Hz beep. Then when the packet returns, we emit a second beep. The frequency of the second beep is proportional to the ping time. So a high frequency beep means a long ping time. If there is no second beep, that’s a lost ping packet. A second beep that varies in frequency means jitter.
Try it yourself. You can download an x86 Linux executable version here. To enable audio ping just run it with the -Z option. Don’t forget the ./ in front of ping otherwise you will run your regular system ping.
$ wget http://rowetel.com/downloads/ping
$ chmod u+x ping
$ sudo ./ping localhost -Z
This is very much a work in progress. I would welcome feedback on the “mapping” of the ping information to sounds. Feel free to experiment with your own ideas. The simple mapping I have used is:
freq = triptime*1E-2 + 400;
tone(tone_fd, 0.9, freq, 0.2);
So the frequency is just a scaled version of the trip time. A longer ping time makes a higher frequency tone. This actually works OK, when I wander around a Wifi network with my laptop I can tell you all about the link quality by listening to my laptop. However the consensus of the Village Telco team is that we still have some work to go on the “mapping” to make this a useful tool.
Some other ideas for audio ping:
- A “missile lock” tone when the link is “good”.
- Use sampled files, e.g. drums, or explosions or music.
- Audio ping might also be useful for blind people.
There is some more information including the patch for audio ping here. If anyone is interested in helping out, I could use some help porting audio ping to an Asterisk application for the Mesh Potato. Contact me if you are interested.
Making Batman More Readable
The Mesh Potato uses the Batman mesh routing algorithm. Batman has a handy debug mode (batman -cd1) that lets you view your neighbours in the mesh. However when several nodes are present the display can get hard to read.
Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.
A.T.M.A.N. 0.3.2, MainIF/IP: wlan1/10.130.1.99, UT: 0d 0h 0m]
10.130.1.40 ( 51) 10.130.1.10 [ wlan1]: 10.130.1.40 ( 44) 10
.130.1.10 ( 51) 10.130.1.1 ( 42) 10.130.1.30 ( 40)
10.130.1.1 ( 51) 10.130.1.40 [ wlan1]: 10.130.1.1 ( 44) 10
.130.1.10 ( 50) 10.130.1.40 ( 51) 10.130.1.30 ( 48)
10.130.1.10 ( 44) 10.130.1.10 [ wlan1]: 10.130.1.10 ( 44) 10
.130.1.40 ( 37) 10.130.1.1 ( 41) 10.130.1.30 ( 43)
10.130.1.30 ( 52) 10.130.1.10 [ wlan1]: 10.130.1.30 ( 44) 10
.130.1.10 ( 52) 10.130.1.1 ( 51) 10.130.1.40 ( 48)
10.130.1.250 ( 46) 10.130.1.10 [ wlan1]: 10.130.1.40 ( 42) 10
.130.1.10 ( 46) 10.130.1.30 ( 31) 10.130.1.1 ( 39)
So I added a couple of extra debug modes, “batman -cd6”:
[B.A.T.M.A.N. 0.3.2, MainIF/IP: wlan1/10.130.1.99, UT: 0d 0h11m]
Originator (#/255) Nexthop [outgoingIF]
10.130.1.40 (245) 10.130.1.40 [ wlan1]:
10.130.1.1 (243) 10.130.1.1 [ wlan1]:
10.130.1.10 (254) 10.130.1.10 [ wlan1]:
10.130.1.30 (253) 10.130.1.30 [ wlan1]:
10.130.1.250 (234) 10.130.1.40 [ wlan1]:
and “batman -cd7”:
[B.A.T.M.A.N. 0.3.2, MainIF/IP: wlan1/10.130.1.99, UT: 0d 0h 7m]
Originator (#/255) Nexthop [outgoingIF]
0 (10) 129 [ wlan1]: 129 (10) 1 ( 9) 10 ( 9) 40 ( 9)
129 (10) 129 [ wlan1]: 129 (10) 40 ( 9) 1 ( 9) 199 ( 4)
40 ( 9) 40 [ wlan1]: 40 ( 9) 1 ( 8) 10 ( 9) 129 ( 5)
199 ( 9) 10 [ wlan1]: 199 ( 4) 40 ( 8) 1 ( 8) 129 ( 4)
1 ( 9) 1 [ wlan1]: 1 ( 9) 129 ( 5) 30 ( 8) 10 ( 9)
10 (10) 10 [ wlan1]: 10 (10) 1 ( 8) 30 ( 8) 129 ( 4)
30 ( 9) 10 [ wlan1]: 30 ( 9) 1 ( 8) 129 ( 4) 40 (8)
Steve Song suggested the features of “batman -cd7”, for example (i) just print the last octet of each node’s IP (ii) scale the metric so it is out of 10 and (iii) colour code the metrics. Unfortunately the colours don’t show up above, instead I got the smiley faces. The colours are meant to be red-blue-green depending on link quality.
More information (including the patch and an x86 executable you can try) here.
Line of Site (LOS) and interference are common reasons for poor links in the Dili Village Telco.
To debug LOS problems a measure of signal strength is useful. Elektra has developed a tool that “speaks” the received signal levels (RSSI) from the telephone. A strong signal usually indicates good link quality so this tool is very useful. However when there is strong interference it is possible to have a high signal strength but poor link quality (i.e. poor ping statistics and phone call quality).
So it would be great to have a tool to help track down interference problems. I experimented with one idea on the April Dili trip, using some scripts that could gather and plot a graph of Wifi spectrum use:
The cool thing about this tool is that it gathers the information from the Mesh Potato itself, so you see exactly what the Potato sees. So it’s more useful than doing a site survey from ground level.
This graphical tool could be integrated into the Web GUI of the Mesh Potato. It would be useful to run it for a while and plot the effect of overlapping channels. If interference is a problem, adding a directional antenna to the Mesh Potato should improve it. This should be visible on the plot – unwanted networks should be attenuated and our wanted signals amplified.