Audio Ping and Tuning Mesh Networks

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:

  1. You don’t need to buy a laptop, or risk taking it onto a roof.
  2. You can listen to a single-piece phone one handed (although dialling requires two hands).
  3. A phone works in bright sunlight
  4. Anyone (even the illterate) can use a phone.
  5. A phone works straight away, it doesn’t take several minutes to boot.
  6. The phone is powered by the Mesh Potato FXS port, so it won’t run out of battery.
  7. Phones are much cheaper than a laptop, especially critical for people in the developing world.
  8. If we get it right, an audio signal will be easier and more intuitive to use than reading and interpreting.

Audio Ping

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.

  1. normal
  2. no link (100% packet loss)
  3. variable latency, some packet loss

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:

  1. A “missile lock” tone when the link is “good”.
  2. Use sampled files, e.g. drums, or explosions or music.
  3. 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.

Further Work

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.

11 thoughts on “Audio Ping and Tuning Mesh Networks”

  1. Stupid idea:
    Some refinements for a tuning application:

    We have four auditory indicators for the user:
    1. Beeps => successful pings to other parts of the mesh
    2. Beep volume => trip time of the ping: louder == shorter trip
    3. Two different beeps: a single tone beep == not suitable. A two tone (low => high) == suitable.
    4. Static => interference / signal strength: more static == weaker signal.

    At this point, tuning a MP is as simple as dialing the app, listening to the sounds it plays as you move the MP around, aiming to hear strong beeps over low static, just like tuning a radio. And you know the link is fairly good when you hear the low high beeps.

    A useful enhancement might be to be able to change the station to be pinged (by getting a list of potential next hops from BATMAN) or the channel using the phone keys.

    I have no idea how practical or feasible these ideas are, but they could make a good user interface for tuning a link – and I would guess that obtaining static and generating tones should be a fairly simple proposition on limited hardware.

    Implementation is (sadly) left as an exercise for the reader =)

    Thanks,

    Julian Calaby

    1. Hi Julian, on the MP the extension could be 999100 to ping 10.130.1.100 or 999101 to ping 10.130.1.101.

  2. Oh, I forgot one thing:

    I’m guessing that it’d be super-useful to know if there is *any* link there, so maybe it should send pings at two different packet sizes: a small one to check whether any link exists and a large one to check it’s quality.

    Thanks,

    Julian Calaby

    1. Hi Bruce,

      I don’t think RTS/CTS is enabled on the Mesh Potato Wifi. I don’t know much about it (Elektra is our Wifi protocol expert) but IIRC there are issues with RTS/CTS and mesh networks.

      Cheers,

      David

  3. David,

    Audio Ping – its a brilliant idea.

    this straight away led me to “add on” functionality that could be extended to other useful purposes:

    1. Use it for “antenna alignment” when you are using point to point WiFi
    – Output a high pitch for good/strong signal/low packet loss, but output a low pitch for bad/weak signal/high packet loss. Similar to tuning in radio station, using your dial. As you pan/tilt the antenna, you should be able to hear the pitch get higher or lower – this makes it easier for the common man to align antennas.

    2. Another thing you might want to do is have an 3.5mm audio out right on the mesh potato box itself, so you can avoid using a telephone. – Use a GPIO output to do PWM audio output.

    3. Instead of dialing up, maybe a “button” you press on the mesh potato to invoke the ping test. (You could possibly use one of your analog inputs off your microcontroller)

    Cheers
    Dazza

    1. Good ideas Dazza. Re (1) yes I have heard of some Wifi kit that has this sort of audio output with directional antennas. I would like to use similar ideas to make wifi network deployment really easy in the developing world. Lower the skill level.

  4. Audio ping, great idea.
    My 2cents, if I may, is in regard to the tone. If I had more coding experience I would hash this out, but from a listening perspective I have an idea I think will help,

    ) packet sent:
    The 400Hz ping packet I would suggest set to 261Hz, or Middle C (C4), as a ticking base line for each packet sent (ie 1 per second).

    ) return packet:
    Now for the ms return time, this tone would be constant, and rise/ramp or fall on each successive return. Most people have fairly good relative pitch when they hear, so the drop or rise in the constant tone would be easier to distinguish. I would also invert the time -to- tone scale, so a smaller ms time would result in a higher pitch to, say a max of ~+0ms (not likely) is around
    4186Hz (C8), and start at around 440Hz (A4). So a high ms threshold (~500ms?) would cut off at 440Hz, and low ms approaching 0 would peak at (C8). Jitter may be a little more complex, but could add a timbre to the constant tone, which people can easily recognize like a distinct instrument or voice.

    I played around (midi wise) with this, it can be a little annoying to hear the constant tone, but it gets the information across more cleanly. And a higher tone is easily recognized as a better ping time.

    Hope this may help, Keep up with all the great work, and I enjoy following your success and bumps along the way.

  5. David is the code available somewhere? It’s a nice application and it could be nice to try and implement suggestions as the one latest one from Harlan above. :)

Comments are closed.