Village Telco » Mesh Potato

Using the Voice Interface to Tune MP WiFi Connection

Steve — Wed, 23 Jun 2010 19:25:04 +0000

One of the challenges in making the Mesh Potato as dead simple to use as possible is the fact that, unlike many modern Internet devices, it has no GUI. Sure, you can plug a laptop into the ethernet port or connect via WiFi to a web interface but the Mesh Potato on its own has no GUI, which presents certain challenges in designing a drop dead easy-to-use device.

However, constraint can be both a barrier and an enabler of innovation and this is certainly true of the Mesh Potato. As it turns out, we are only just beginning to discover the potential of the voice interface to the Mesh Potato to improve user experience. Here is a great example.

The first thing you want to do when you power up a Mesh Potato is make sure it has a good connection to its peers. This is easy if you have a GUI or even a command line but what if you just have a telephone handset? David Rowe developed a script for his deployment of the Dili Village Telco that continuously polled the quality of the mesh link on the MP. Elektra has taken that one further and integrated the script into a voice interface that give continuous audio feedback on link quality making it easy to tune your WiFi connection with a simple handset. Here’s a brief video of me testing out this feature.

Tuning Mesh Potato WiFi Performance with a Voice User Interface from Steve Song on Vimeo.

A simple Mesh-Potato setup using the web administration interface Current firmware images for the Mesh-Potato now feature the LUCI...

Related posts brought to you by Yet Another Related Posts Plugin.

Smoke testing the Mesh-Potato video – Part II

elektra — Fri, 19 Feb 2010 18:00:58 +0000

We have now a new over-voltage protection circuit design for the mass production Mesh-Potatos. We were not satisfied with the previous version. Ideally the over-voltage protection circuit has a snap-on characteristic that triggers the fuse and interrupts the supply voltage without a grey zone. The new circuit triggers at 43 Volts and acts as a powerful crowbar circuit. I have connected the prototype of this circuit to a Mesh-Potato and went through the robustness tests according to our test plan. You can find the test plan and the schematic in the svn respository. A little video at Vimeo.com is documenting some of the tests – thanks to Katrin Lang, who acted as editor and camera operator this time.

Mesh-Potato smoke testing with 230 Volt AC from Elektra Berlin on Vimeo.

The list of tests included a reverse DC voltage test from a unfused 36 Volt source (consisting of three powerful 12 V lead acid batteries in series), excessive DC voltage tests and finally a really scary test involving 230 Volt AC (330 Volt peak) from mains. Please don’t try this at home. Even if the Mesh-Potato survives, there is a 50% chance that you might have mains potential on ground of all components connected to the MP. Also don’t try this with your alpha or beta series Mesh-Potatos, because the previous over-voltage protection circuit is not up to that challenge.

Technically inexperienced people can easily make mistakes, so our idea was to design the Mesh-Potato as robust as possible. In 2005 I was helping to set up a large scale WLAN network in the Sylhet area in Bangladesh. The network consisted of high towers (up to 100 feet tall) and strong directional antennas, interconnecting towns and a school with wireless long shots (up to 32km). One of the trainees damaged a important wireless relay on a tower by taking the open ends of a 12 Volt cable and plugging it straight into the mains socket. Of course the equipment (a Mesh-Cube from 4G Systems) subsequently looked like a lightning strike had hit it, which was actually what I supposed first. However there had been no thunderstorm in the night before. It took me a while to find the reason. The trainee either hadn’t realized what he had done, or he didn’t want to admit it. He watched me trying to find the problem without saying anything. It is common practice in Bangladesh to plug cables into sockets without plugs. The quality of sockets and plugs is miserable, so loose contacts are the rule, not the exception. Now a important relay was down and it was hard to get a replacement. The problem wasn’t so much the financial loss. Shipping and particularly customs can take weeks in Bangladesh. So during the first Villagetelco workshop I suggested to design the MP as robust as possible.

Stress Testing the Potato I’m currently performing “Africanisation” tests on Mesh-Potato prototypes from the...
Antenna Testing Jeff and I have just had an enjoyable day outside...
Potato on the Jetty – Range testing PCB Antennas Today we made some phone calls over a 400m link...

Related posts brought to you by Yet Another Related Posts Plugin.

Potato on the Jetty – Range testing PCB Antennas

drowe — Thu, 14 Jan 2010 04:42:47 +0000

Today we made some phone calls over a 400m link using PCB antennas.

We want to use etched PCB Wifi antennas for the Mesh Potato. However we have heard that some companies have had problems with PCB antennas, such as variable results in production. So before committing to PCB antenna we wanted to do some more tests.

Joel is a local hacker here in Adelaide who happens to live at the top of a 4 story apartment block in a beach side suburb called Henley Beach. This gives him good line of sight to points on the ground several hundred meters away. Much easier than testing at my place which is on dead flat terrain and requires masts for any Wifi range testing.

Before heading out to Joel’s place I tried some tests in my backyard. I set up two MP01s about 10m apart. First I connected conventional sleeve dipole (rubber ducky) antennas and measured the signal strength. I then connected a couple of PCB antennas and repeated. To monitor signal levels I wrote a simple script to dump the Received Signal Strength Indication (RSSI) levels (in dBm) from MadWifi:
#!/bin/sh

while [ 1 ]
do
wlanconfig ath0 list | grep 56:ac:90 | awk ‘{ print $6 }’
sleep 1
done

The grep filters out the last few MAC digits of the MP we are interested in, otherwise you get RSSI measurements of all nearby Wifi devices.

However the results were inconclusive and after an hour I became frustrated:

On a good test both MPs would receive about -30dBm, however if I moved a MP 20mm a level could drop to -44dBm. Lots of multipath in my back yard!
One MP was consistently around -30dBm, whereas the other would move between -30 and -48dBm. Maybe they had different diversity antenna settings. Or maybe the RSSI measurements can’t be trusted.

I had much better (and less frustrating) results using the spectrum analyser to measure signal strengths, as explained in the previous post on PCB Wifi antennas.

In the end I figured it was sufficient to test from a system level rather than attempt more measurements of antenna performance and signal strength. The $64 dollar question is can we make phone calls over a reasonable distance with these antennas?

On the Beach

We placed one MP01 on Joel’s balcony. I then walked down to the end of Henley Jetty (Joel has previously managed to pick up his home Wifi there). There is (just) a line of site between the two points – through a gap in a couple of buildings. The distance was 375m. We used two calibrated V1.2 MP01s (same design as the Beta units). An “iwlist ath0 scan” showed 9 other Wifi networks in operation.

Google Map of Range Test - 375m

One MP01 on Joel's Balcony

I tried a bunch of antenna combinations, starting with regular sleeve dipole (rubber ducky) antennas then moving to PCB antennas first at one end, then both ends of the link. From our previous tests both the sleeve dipole and the PCB monopole antennas have an estimated gain of 2dBi.

We had a total of 4 PCB antenna samples (a mixture of the 17mm and 20mm monopoles) as we wanted to get a feel for performance spread over multiple antennas of the same design. Here are the results:

MP01 #36	MP01 #38	Call Quality
Sleeve Dipole	Sleeve Dipole	Great
Sleeve Dipole	#3 17mm PCB monopole	Great
Sleeve Dipole	#2 20mm PCB monopole	Great
Sleeve Dipole	#4 20mm PCB monopole	Great
#1 17mm PCB monopole	#4 20mm PCB monopole	Great
no antenna	#4 20mm PCB monopole	No Call

The final test was just to make sure we weren’t kidding ourselves.

MP01 on the end of Henley Jetty

At one stage a fisherman assisted in my propagation experiments by standing right in my line of site and lowering a metal net as I talked to Joel!

For each call I tried moving the MP01 (with PCB antenna attached) around. For example upside down, side to side, rotated it. No break up of signal, good audio in both directions. Only problem was wind noise. Joel suggested we add digital noise suppression but I figure there isn’t much wind noise inside village homes!

Here is the view of the far end from either side of the link. The arrow shows the location of the other end.

View of Jetty from Joel's Balcony

View of Joel's Balcony from Jetty That's him with the brown eyes.

Antenna Testing Jeff and I have just had an enjoyable day outside...
First Beta Mesh Potato Joel is helping my Village Telco presentation at the upcoming...

Related posts brought to you by Yet Another Related Posts Plugin.

First Beta Mesh Potato

drowe — Wed, 13 Jan 2010 08:08:20 +0000

Joel is helping my Village Telco presentation at the upcoming LCA 2010 conference so I took a couple of the first Beta MP01s down to his place for a test drive. They are fresh off the production line and not even calibrated as I needed them in a hurry for LCA 2010. Atcom are currently assembling, testing and calibrating the Betas which will be shipping over the next few weeks.

The first Beta Mesh Potato

These early Betas are running revision 203 firmware, which has Afrimesh as the primary GUI with Luci available for “advanced” configuration options. Thanks Elektra and Antoine for your fine work on the Mesh Potato GUI.

Here is Joel’s experience – our #1 Beta MP01 tester! Joel is pretty geeky (he has contributed for several years to the OLPC project) but has never used a Mesh Potato before. I hope this information will be useful for other Beta testers who should be getting their Mesh Potatoes over the next few weeks. I stood back through most of Joel’s beta experience – I wanted to see how other people approach the Mesh Potato.

How Joel Configured His Mesh Potato

The default Ethernet IP is 192.168.1.20. Joel plugged a cross over Ethernet cable into the MP01, although a regular cable should be OK.
He then logged in via telnet, and set the password from the command line using the “passwd” command. Setting the password activated ssh and disabled telnet. This password also becomes the web admin password.
Joel then pointed his browser at 192.168.1.20 and the Web GUI came up.
He changed the 10.130.1.20 “IP Address” to a unique IP on the mesh. Joel selected 10.130.1.123. This is the only change you need to start making phone calls between Mesh Potatoes. This IP address becomes your phone number, for example dialing 123 on the mesh will make Joel’s phone ring. Note this only changes the mesh Wifi IP – the Ethernet IP is still 192.168.1.20. The Ethernet IP can be changed via the Luci Network Menu.
Setting the Wifi IP on the Mesh Potato

Note the settings are applied automatically – there is no “save” button, although I understand that this will be present on later firmware as out of habit we all look for a save button! To apply the settings (i.e. change the actual Wifi settings) we rebooted (power cycled) our MP01.

We also changed the Wifi channel and BSSID to match the mesh settings of a couple of earlier Potatoes. This is not really necessary, the default Wifi channel and BSSID are probably OK for you.

That’s it – the main step is just change the mesh Wifi IP to something other than 10.130.20. Then reboot and you can start making calls between Mesh potatoes.

Easier Configuration

A slightly easier way is:

Point your web browser at 192.168.1.20, login with user/password root/admin.
Simply change the Wifi IP from 10.130.1.x to 10.130.1.yourchoice.
Power cycle your potato.

Configuration without a Web browser

Power up your Potato and connect a phone, after about 1 minute you will get dial tone.
Dial CONF (2663) and you will hear HAL 9000 talking to you!
Enter the new Wifi IP, e.g. 10*130*1*123

Joel asked a good question – what do all the LEDs mean? They are not labeled although from memory it’s power/Ethernet/Wifi activity etc. I asked Edwin@Atcom about this and the reason was the vinyl labels hadn’t arrived when the first few betas shipped. The rest of the Betas will have these labels for the LEDs.

A simple Mesh-Potato setup using the web administration interface Current firmware images for the Mesh-Potato now feature the LUCI...
Antenna Testing Jeff and I have just had an enjoyable day outside...

Related posts brought to you by Yet Another Related Posts Plugin.

Antenna Testing

drowe — Mon, 21 Dec 2009 20:28:56 +0000

Jeff and I have just had an enjoyable day outside testing candidate antennas for the Mesh Potato. Our goal was to evaluate candidates for the internal antenna of the production Mesh Potato.

Jeff designed three types of antennas which I laid out on PCB and had fabricated locally. The three designs were a dipole, a monopole, and a biquad (single loop). We made three versions of each PCB antenna with slightly different dimensions.

I also made a some wire antennas, a monopole, a biquad (dual loop), and a quad (single loop).

Our PCB and wire antennas

PCB biquad design

PCB Monopole Design

Checking the Antenna Impedance

When the PCBs came back the first step was to check the impedance of each antenna. We want roughly 50 ohms impedance to ensure the maximum amount of power is transferred from the Mesh Potato transmitter to the antenna.

A Standing Wave Ratio (SWR) bridge can be used to measure the SWR. I used a version of the design by Erwin Gijzen, a radio Ham and Wifi experimenter. I constructed the SWR head, and measured the DC voltage from the bridge using a multimeter. The bridge compares the impedance of the antennas to a known 50 ohms impedance. If they are equal then the DC output from the bridge should be 0V. Various degrees of mis-match give different output voltages.

SWR head, microwave PCB made with a Dremel tool

I constructed the bridge from double sided PCB and cut the microstrip (3mm wide on 1.6mm thick FR4) with a Dremel tool to save time. When tested it gave sensible results once I fitted a decent microwave detector diode. Unlike Erwin I couldn’t null it down to 0V with a reference 50 ohm load but it did give indicative readings that enabled me to compare our antennas to reference antennas and determine if they had a reasonable match to 50 ohms.

Here are some results:

Load	SWR bridge output (VDC)
50 ohm dummy	0.5
short circuit	1.3
off the shelf router antenna	0.5
17mm PCB monopole	0.5
20mm PCB monopole	0.7
34mm PCB dipole	1.3
64mm PCB biquad dual loop	1.3
68mm PCB biquad dual loop	1.4
72mm PCB biquad dual loop	1.5
wire biquad dual loop	0.8
wire monopole	0.6

The 17mm and 20mm monopoles look good, close to the reference 50 ohm load and commercial off the shelf router antennas (which have sleeve dipole construction internally). The wire antennas also look good. The PCB dipole and PCB biquads don’t look so great.

I tuned the wire monopole to a low SWR by snipping off bits of wire, 0.5mm at a time. I started with a length of 31mm (free space quarter wavelength at 2.4 GHz) but found a good SWR at 26mm. This is probably due to the dielectric constant of the insulation on the wire affecting the wavelength.

Antenna Test Range

I constructed a test range in my back yard, along the lines discussed by Erwin. I used a Nanostation 2 at the transmitter, sending continuous 802.11b broadcast pings as described here. The antenna under test was placed about 6m away and a spectrum analyser used as the receiver. It wasn’t a very good antenna range but after some experimentation we did get surprisingly repeatable results when we compared our antennas to several control antennas.

I fashioned a clamp on a tripod to hold the antennas:

Tripod and clamp

However the tripod and clamp didn’t work very well. When I swapped antennas the results differed wildly in exactly the same position. It’s hard to place a 17mm printed monopole in the same position as a 80cm colinear antenna as their sizes are so different.

So instead I moved each antenna around by hand until I found the peak amplitude, which was captured by the “max hold” function of the spectrum analyser. Sounds a bit rough but gave good repeatable results, and Jeff and I achieved similar results when testing.

Path Loss

The 802.11b signal peaked at about -30dBm on the spec an. Using the Wifi power measurement method described here this means a total received power of -20dBm.

The expected received signal is:

Pr = Tx power + Tx antenna gain – path loss + Rx antenna gain – coax loss

So we plug in the numbers from the Nanostation 2, a 6m path loss and the 8dBi gain Superpass omni reference antenna we get:

Pr = 16 + 12 – 56 + 8 -1 = -19dBm

which is pretty close to what we are measuring using the spectrum analyser. If only all my calculations came out this close!

Antenna Gain Results

We used the 8dBi Superpass as a reference. We would first measure the signals from the Superpass, then save that on the screen as signal A. We would then measure the test antennas and calculate the antenna gain based on the known Superpass gain. We moved each antenna around by hand until a peak was found (the max hold function made this straight forward).

We repeated these tests several times over the day, and while the absolute levels would change 1-2dB the relative levels were always similar.

The antennas are listed in order of gain, and I would estimate the measurements have a tolerance of +/- 1dB. The RF level is the peak of the 802.11b signal on the spectrum analyser.

Antenna	Rx Level (dBm)	Gain (dBi)
15dB grid antenna	-24	14
wire (two loop) biquad with reflector	-26	12
8dB Superpass	-30	8
wire (two loop) biquad	-34	4
wire (one loop) quad	-35	3
wire monopole	-36	2
17mm PCB monopole	-36	2
20mm PCB monopole	-36	2
commercial router antennas	-36	2
72mm PCB biquad dual loop	-40	-2

Discussion

The location of the physical position where peak received signal was found was quite “sharp”. This may have been due to lobes in the signal from the Nanostation 2 or multipath.

Several commercial router antennas were tested (sleeve dipole construction), they all measured about the same. The internal design of these antennas is discussed here.

The results from the control antennas (15dB grid, 8dB Superpass, and nominal 2dB sleeve dipole commercial router antennas) are consistent with what we would expect, which gives us some confidence in the other test results.

The impedance match and gain results from the PCB biquad are poor, which suggests the antenna is not resonant at 2.4GHz. It would be nice to test this antenna on a network analyser to find out where they are resonant (please contact me if you have one – I will ship an antenna to you!) Jeff is working up a simulation of the PCB biquad to test the design. We aren’t pursuing the PCB dipole as we have a bunch of antenna candidates that perform just as well (2dBi).

The wire biquad performance with a reflector was remarkable, nearly as good as the grid antenna which is a much larger antenna. The measured gain (12dBi) is consistent with other peoples results for this antenna.

Jeff and I really liked the wire antennas due to their performance and simplicity. They are easy to make: in production they could be bent up on a jig on 10 seconds from stiff copper wire then soldered to the Mesh Potato motherboard. One small problem with the dual loop biquad wire antennas is a feed arrangement – a small piece of coax would be needed to reach the central feed point. We don’t want the antenna wire directly over the PCB, as this would affect performance. The single loop wire quad is simpler in this regard, as it could be attached at one corner to the PCB.

The PCB monopoles perform well and are very simple, just a 17mm x 3mm track on the PCB next to a good chunk of ground plane. Virtually zero cost to add to the Mesh Potato motherboard. Both the 17mm and 20mm versions worked well, which suggests a relatively wide bandwidth and a high tolerance to small variations in manufacture like dieletric constant of the PCB substrate. Antennas fabricated on PCB are physically smaller than their wire cousins as the signals travel slower which means a smaller wavelength for a given frequency.

Wire single and dual loop biquad/quad antennas had above average gain and some directivity, with both peaks and nulls evident as they were rotated. Is directivity a good thing for a mesh router? You might enhance the signal of one node but null out the signal from another. I am not sure.

The higher gains of some antennas look attractive but may not be useful in practical mesh networks. To achieve the highest gain required careful adjustment of the antenna position. This is fine in a traditional point-point Wifi link, but in a mesh network their are multiple nodes we want to talk to. So if you peak the response to one node, you may dip the response to another. I guess it depends on how many nodes you want to talk to.

The reflector was a piece of blank PCB about 20cm x 20cm. It was moved back and forth behind the antenna until a peak was found (usually at around 15-20mm). All antennas improved by at least 4dB with the reflector, the wire biquad improved by 6-8dB. David C has suggested a slide-in reflector arrangement to give a choice between omni and directional antennas. These tests confirm David’s suggestion is a good one, if a precise way to mounting the reflector can be found.

Here are some of the antennas tested grouped by gain.

Antennas grouped by gain, highest gain on the left

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Stress Testing the Potato

elektra — Sat, 05 Dec 2009 14:21:02 +0000

I’m currently performing “Africanisation” tests on Mesh-Potato prototypes from the alpha and beta production run. “Africanisation” means that a Mesh Potato is supposed to survive even if you accidentally feed reversed DC polarity or AC to the DC jack, to any pin of the Ethernet port or FXS port. For a couple of weeks before the Capetown workshop I had only one Mesh Potato to perform software development, radio performance and hardware tests. I was therefore quite nervous to break one of these devices, so I didn’t do any – possibly destructive – tests. The first sample of the MP 1.2 units has arrived at my home this week. Now I have three MPs – time to take them and put the design goals to a smoke test! In the little video linked here I’m connecting a – unfused – DC cable with reversed polarity straight from a lead-acid battery to a MP. Don’t try this at home with your equipment, folks! Never operate with unfused DC wiring, particularly if you connect it to a lead-acid battery, since it can feed up to several hundred Amps into your circuit and cause a fire!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

A simple Mesh-Potato setup using the web administration interface

elektra — Fri, 04 Dec 2009 19:47:27 +0000

Current firmware images for the Mesh-Potato now feature the LUCI 0.8.8 administration web interface. The LUCI project, mainly driven by developers from the Freifunk communities in Leipzig and Halle, has developed a web interface for embedded devices that are running the Openwrt Kamikaze firmware. LuCI was founded in March 2008 as “FFLuCI” (Freifunk LUA Configuration Interface) as part of the efforts to create a port of the Freifunk-Firmware from OpenWrt Whiterussian (which supported only Broadcom-based devices like the Linksys WRT54GL) to Openwrt Kamikaze (and thus creating support for a huge variety of new embedded WiFi devices). It is now a official part of the Openwrt project.

Most embedded web configuration interfaces make heavy use of shell-scripting. LuCI takes a different approach and uses the LUA programming language.

Let me show you how to quickly set up a new Mesh-Potato, so you can make your first phone call. Configure your workstation/laptop to use a IP address like 192.168.1.1 on the Ethernet interface. Power up the MP and connect it to your workstation with a Ethernet cable. If this is the first boot after flashing a new firmware it will take roughly three minutes for the MP to boot. It needs to perform all the steps needed during first boot (generating SSH keys, formatting and mounting the free flash space with the overlay file-system). Now open your browser and point it at 192.168.1.20. Note that you should click on the “Save & Apply” button after making changes in each window.

You can re-flash the firmware image from your browser, while retaining the individual configuration. LUCI supports configuration backups, uploading SSH public keys and so on and so on…

In the next post about the web interface development we are going to introduce you to Afrimesh – the amazing B.A.T.M.A.N. mesh management web interface for the Potato! Stay tuned!

The Second Village Telco Workshop It is just a little over a year since...

Related posts brought to you by Yet Another Related Posts Plugin.

800m Phone Call

drowe — Fri, 04 Dec 2009 03:02:23 +0000

I just made some test phone calls between two Mesh Potatoes 800m apart. Quite a nice result as both MPs were using just their little 12cm omni whip antennas.

One MP (a V1.1) was placed on a mast on the roof of my house. The other MP (a V1.2) was “portable” – strapped to the aluminium handle of our pool vacuum! This was a cool mast as aluminium is very light and one section slid inside the other for transport. I strapped this temporary mast to a playground at a local park. Watching me make phones calls into a 6m pool vacuum handle with wires hanging off it was highly puzzling for the little kids and other parents at the park! Total height of one antenna was 11m, the other 8m. I would guess that the antennas had line of sight (just) but not a free Fresnel zone. The terrain where I live is dead flat so their are no hills or valleys to take advantage of. Masts are needed to get above the houses and trees.

This test actually took a few days part time work to prepare. I had to put the MPs into boxes and fashion a bracket to clamp the MPs to the poles. Working out how to get them high enough at either end took some thought. I built a power over telephone line injector for one end – so I only needed one cable up to the MP on the roof for phone and power. This works OK but the ohmic losses of the little phone cable conductors means the MP01 needs a 20V power supply, it wouldn’t boot off 12V with a 30m phone cable. At one end I connected the MP FXS port to an IP04 to automatically answer the call, play a prompt, then run the “Echo” Asterisk application so I could hear my voice coming back to me. I was manning the park end of the link, and the home end was answered automatically.

First I tested the link in my back yard then at 800m. The call quality at 800m was usable but not perfect. When the other end answered I would miss a few seconds of the prompt being played by the IP04 – I imagined a flurry of WiFi rate-adaption over these few seconds as the algorithms tried to work out what bit rate was acceptable for the call. However by the time the Echo application started I could hear my own voice just fine. Occasionally I could hear the call breaking up (a packet getting repeated) but not too often. I was using the ulaw codec. This result highlights the needs for some work on improving call quality on marginal links, the sort of ideas Alex has been talking about. It also shows the need for good line of sight links when setting up a Village Telco network.

I eventually killed the link by pressing a DTMF key. This started both ends sending continuous DTMFs in some sort of loop and the IP04 wouldn’t hang up! So time to climb off the playground equipment and head home.

A “iwlist ath0 scan” on the roof-mounted MP showed 22 signals, so it’s likely there was some interference. A bit of height sure does help with Wifi links.

This was a nice test to back up our other results that show the Wifi & RF side of the MP01 is working OK. One of the MPs was a V1.1 which used the prototype MP PCB design. Although the PCB design has been refined on the V1.2 boards, I suspect the frequency offset problem (along with calibration) was probably the biggest issue with the earlier MP boards – it caused packet error rate problems at the low bit rates which get selected for long distance links.

Sorry no pictures, my wife is out of town with our digital camera. I have some snaps on my phone but can’t work out how to upload them without a teenager nearby (also out of town). Maybe later.

Factors Affecting Village Telco Performance This post discusses the factors that affect the quality of...
First Beta Mesh Potato Joel is helping my Village Telco presentation at the upcoming...

Related posts brought to you by Yet Another Related Posts Plugin.

Factors Affecting Village Telco Performance

drowe — Fri, 27 Nov 2009 12:31:24 +0000

This post discusses the factors that affect the quality of Village Telco phone calls, in particular under marginal conditions like heavy mesh load and self-interference. This information was gathered from VOIP over Mesh papers (e.g. [1]) and discussion threads on the Village Telco Google Group in October and November 2009.

Each node in the Village Telco mesh will be a Mesh Potato (MP) or similar device such as a Nanostation 2 with similar processing power and Wifi performance.

In the typical Use Case a Mesh Potato (MP) is mounted on a short mast 1m above a metallic roof of a dwelling in a village or town ship. A secondary use case may see the MP mounted inside the dwelling. Other MPs will be located a few 100m away to form the mesh. The MPs will often have line of site, but are unlikely to have a free Fresnel zone. Signal strengths from adjacent nodes will be relatively high however there will be significant multipath.

In this environment:

Multipath effects will have a similar effect to increasing transmitter power and receiver sensitivity. For example moving the antenna a few cm up and down on the mast may increase or decrease the signal strength several dB due to signal re enforcement and annulment in the multipath environment.
Antenna directivity could be a useful to remove the effects of directional interference. However by definition a mesh network needs to be able to detect nodes in many directions so at least in the centre of the mesh a roughly omnidirectional pattern is desirable (Note there is strong debate on this point on the mailing list).
Surprisingly the speech codec and channel bit rate have a fairly small effect on mesh capacity for VOIP traffic. This is because of large overheads in (i) VOIP packet structure and (ii) the 802.11 MAC protocol. This is explained in the next section.

Packet and 802.11 MAC Overheads: Packet Rate is Key

VOIP packets are very small compared to other traffic on a Wifi network. Consider a 33 byte GSM codec packet compared to a packet of web traffic that may be up to 1500 bytes. To transmit this GSM codec packet using VOIP we must add a RTP header (12 bytes), a UDP header (8 bytes) and an IP header (20 bytes), giving a total IP packet size of 73 bytes. To send one GSM codec payload packet every 20ms (13.2 kbit/s) therefore requires an IP level bit stream of 29.2 kbit/s.

There are futher overheads due to the 802.11 MAC headers and protocol used to reliably transmit data over the Wifi channel. These are optimised for larger packets (1500 bytes). The time required to send 73 bytes at 11 Mbit/s is just 53 uS, however in practice around 800-1000 uS is required before the next packet can be sent. This time is consumed by MAC data, ACKs, physical layer synchronisation and various programmed delays and timers.

The Wifi channel capacity for VOIP is therefore dominated by 802.11 MAC layer overhead. This sets an upper limit on the number of packets/second we can send over the channel, and hence the number of VOIP calls that can be supported.

Packet rate (measured in packets/s) is the key factor for VOIP over Wifi capacity.

The channel bit rate has a relatively small effect as it only affects the small amount of time spent transmitting the payload IP packet. The speech codec bit rate has an even smaller effect as it only affects the size of a small part of the IP packet.

Using an x86 PC with built-in Wifi hardware Elektra has measured the maximum packet rate for 802.11b as 1350 packets/s and 802.11g as 3510 packets/s. This was measured using 100 byte packets with a small amount of ambient Wifi interference. Alex managed over 4000 packets/s on 802.11g. The use of x86 PCs ensures the tests were not CPU limited, i.e. the limits are likely to be the 802.11 MAC protocol.

The inefficiency of the VOIP over Wifi channel can be measured by comparing the throughput compared to the channel bit rate. The throughput at 11 Mbit/s (100 byte packets at 1350 packet/s) is 1.08 Mbit/s. The though put at 54 Mbit/s (100 byte packets at 3510 packet/s) is 2.81 Mbit/s.

For comparison with larger packets (1500 bytes) the Wifi protocols achieve throughputs of around half the channel bit rate, for example 5 Mbit/s over an 11 Mbit/s 802.11b link.

One way to improve throughput is to send multiple codec packets in every Wifi packet. In the literature this is known as source aggregation. We have been experimenting with 4 GSM codec packets per Wifi Packet. This effectively increases the VOIP call capacity by a factor of 4, at the expense of increased delay and possibly robustness under packet loss conditions.

Given the higher potential packet rates of 802.11g Elektra has suggested we configure the nodes to run 802.11g only – in 802.11bg compatibility mode the 802.11g packet rates are limited to 802.11b levels.

Self Interference and a Model for Mesh Capacity

In the use case above we assume good physical layer links. In this case the main interference source will be other nodes on our own mesh. The Wifi protocols arbitrate use of the channel between nodes, but clearly the capacity of the link must decrease if multiple nearby nodes all wish to transmit on the same channel.

The purpose of a mesh network is to relay data between distant nodes, e.g. node A sends data to C via B as A and C cannot send data directly. However only one node can transmit at any one time. Sending a single packet between A & C requires two packet transmissions, consuming 2 packets from the channel capacity.

Therefore the number of VOIP calls the mesh can support depends on the number of hops between nodes. In practice calls will span different numbers of hops. However we can model the number of calls as the (packet capacity)/(average number of hops).

Here is an example:

For a full duplex call using GSM codec we require 50 codec packets/s in each direction or a total of 100 packets/s. We aggregate 4 codec packets in each Wifi packet which reduces the mesh load to 100/4 = 25 packet/s for each call.

In this example we assume we have measured our mesh capacity as 1000 packets/s. Therefore the call capacity is 1000/25 = 40 calls for single hop links. If the average number of hops is 3, we have a call capacity of 1000/(25*3) = 13 calls.

CPU Load and Test Mesh Results

The VOIP over Wifi channel is characterised by many small packets, rather than a smaller number of large packets found in other forms of Internet traffic (e.g. fetching Web pages).

Just like the 802.11 protocols, low speed commodity router CPUs are designed to effectively handle large packets. Many small packets create many interrupts and context switches inside the router CPU which increases the CPU load. Data throughput at high packet rates tends to drop.

In addition to routing Mesh Wifi packets, each Mesh Potato must perform CPU-intensive operations such as echo cancellation, DTMF detection, and speech compression (the speech codec).

Some real world tests were performed using a two hop mesh. Two of the nodes were Nanostation 2s, the third node was a V1.1 Mesh Potato. All of the CPUs are Atheros AR231x variants, of approximately the same CPU performance (180 MHz). The nodes were all in the same room giving a good physical layer links, presumably 802.11g at a high bit rate. The mesh was loaded using iperf in UDP mode. This allowed a variable number of packets/s to be sent over the 2 hop mesh.

It was found that a throughput of around 900 packet/s (at < 1% packet loss, 200 byte packets) was possible over the two hop mesh with the Mesh Potato in the on-hook (inactive) state. Over a single hop around 1900 packets/s was possible with a 1% packet loss. For comparison the 802.11g x86 Wifi tests performed above achieved around 3500 packets/s.

During the two-hop tests the CPU load of the Mesh Potato was measured as 85% (all in the kernel). This suggests that receiving, routing, and re-transmitting mesh Wifi packets consumes a considerable amount of CPU on the Mesh Potato.

These tests suggest that the VOIP capacity of the Village Telco using 802.11g is currently constrained by CPU. This could be improved by optimising the kernel code responsible for receiving, routing, and transmitting the Wifi packets, possible via kernel compilation options.

When we try to send more packets than the mesh network can support we experience packet loss. To test the effect of packet loss we loaded the two-mesh network at 900 packet/s, then placed a VOIP test call across the mesh. The quality of the call could be monitored at variable packet loss rates. At 2% packet loss some click and pops started to become noticeable, however the call was still intelligible at 5-10% packet loss.

This is a fortunate result – call quality degrades gracefully in the presence packet loss rather than all calls on the mesh falling over. Adding a few more calls to a heavily loaded mesh should not cause a drastic drop in quality.

Consider a typical Village Telco mesh containing 150 nodes. We estimate a 10% activity factor, so we shall design the networks such that 15 calls may be operating at any one time. As the number of nodes (150) is much greater than the capacity of the mesh (15 calls) some control mechanism may be necessary to prevent a large number of calls being made at the same time. This could be achieved via scripts running on the Village Telco’s Asterisk server.

Conclusions

In the typical Village Telco Use Case we assume good physical layer links between mesh nodes. We have therefore not considered weak signal performance of performance in the presence of interfering signals from other services. After the initial deployments we should revisit these areas based on practical experience.

The throughput the mesh network can support is about 10% of the channel bit rate due to the effects of short VOIP packets.

For VOIP over mesh the maximum packet rate that the mesh can support is key. This is constrained by the 802.11 MAC algorithms to be around 3500 packets/s for 802.11g and around 1350 packets/s for 802.11b.

In our Use Case self-interference from other nodes on our mesh causes limits call capacity. A model for estimating the number of simultaneous calls possible on a mesh network is given above.

In practice the low end routers we are using are CPU-limited which further limits the packet rate to around 1900 packets/s for a single hop link (900 packets/s for a two-hop link).

VOIP signals are reasonably robust to packet loss when under high load, but it is advisable to limit the total number of active calls to avoid overload of the mesh.

In the next post we will discuss various ways to improve Village Telco performance.

References

[1] There are many papers discussing Voip of Mesh network performance, a good starting point is the list of publications published as a comment by Saritha Kalyanam on my blog. The list includes the following papers:

Performance Optimizations for Deploying VoIP Services in Mesh Networks
http://www.cs.sunysb.edu/~samir/Pubs/jsac-mesh-06.pdf

VoIP over WLAN 802.11b simulations for infrastructure and ad-hoc networks
http://www.it.uc3m.es/~acuevasr/publicaciones/LCS06.pdf

10 things you should know about VoIP over wireless
http://blogs.techrepublic.com.com/10things/?p=205

Simultaneous VoIP Calls Capacity Over an 802.11 Ad Hoc Network
http://ww1.ucmss.com/books/LFS/CSREA2006/ICW5018.pdf

Analysis of UDP, TCP and Voice Performance in IEEE 802.11b Multihop Networks
http://www.ew2007.org/papers/1569014366.pdf

The Second Village Telco Workshop It is just a little over a year since...
The Second Village Telco Workshop – The David Report For myself and Elektra the workshop was spread across two...

Related posts brought to you by Yet Another Related Posts Plugin.

RF Hacking

drowe — Mon, 16 Nov 2009 15:27:47 +0000

Since the 2nd Village Telco Workshop in July we have been working on the Beta release of the Mesh Potatoes. Progress slowed immediately after the workshop – I think we all needed a break and some time to organise the resources (e.g. test equipment, prototype manufacture and people) required for the next phase of the project. However we are back in the thick of it now.

The Mesh Potato is a mix of many different technologies: embedded Linux, telephony hardware, VOIP and Wifi. The Radio Frequency (RF) side of the Mesh Potato is a loose end we need to tie up. Unfortunately, data on the RF side is nearly impossible to obtain. To get the full support package from Atheros costs USD$100k. That is beyond our budget and sits uncomfortably with the open source nature of the Village Telco project.

Each AR2317 chip is a little different and consequently each chips requires individual RF calibration on the production line. This calibration ensures each AR2317 product has uniform transmit power and meets certain performance criteria. The calibration data is stored at the end of the SPI flash chip and loaded by the WiFi driver at boot time. Calibration is performed on the production line using a bunch of expensive RF test equipment connected via GPIB to a host computer running special software.

The calibration procedure and most of the data relating to the AR2317 RF section is part of the Atheros “secret sauce”.

On our prototype Mesh Potatoes we were lucky enough to have the WiFi fire up first time. We just copied the calibration data from another AR2317 based product as a starting point. The Wifi worked, but without calibration Wifi performance is likely to be poor. As we had no RF test equipment our visibility was limited – it was hard to even measure the RF performance.

Elektra managed to hook a V1.0 MP01 up to a borrowed spectrum analyser, thanks to kind guys at the CSIR in South Africa. A spectrum analyser graphs the power at each frequency. Here is what the spectrum of a calibrated DIR-300 looks like:

DIR-300 1Mbit Channel 11 spectrum

And here is the output from our uncalibrated V1.0 Mesh Potato:

MP01 1Mbit Channel 11 spectrum

So after the 2nd Village Telco workshop we decided to tackle Calibration. Fortunately, our friends at Atcom found some friends in Shenzhen who have the production line equipment for AR2317 calibration. Here in Adelaide I bought some basic test equipment – an old Tek 492 spectrum analyser from e-bay and a frequency counter. The Tek 492 is an analogue spectrum analyser (with some digital storage ability) from the early 1980′s. In their day they cost $30,000 but are available 2nd hand for around $2,000. Microwave hacking on a budget! The following photo is courtesy of Ben (see below):

In early October we made our first attempt at calibration on one the V1.1 Betas. The automatic test equipment in Shenzhen “failed” us. There were several bugs including low output power (10dB down) and a large frequency offset (60ppm instead of 20ppm). Another concern was that several Mesh Potatoes tested gave different results. Great. Just what we need when we are trying to get 100 Betas out the door for eager developers.

Thus began a two week frenzy of RF debugging, with Mesh Potatoes being couriered back and forth between Shenzhen and Adelaide and much soldering of tiny 0402 size parts under the microscope. These parts appear the size of a small crumb to the naked eye (about 1mm by 0.4mm), but surprisingly you can hand solder them under a microscope with a little patience.

None of the core team are experienced in Wifi or 2.4GHz RF, and we are working without 95% of the data and test equipment we need for proper RF development. So we had a few challenges.

After about two weeks of hard work we made some progress. I managed to bring 3 out of 4 betas up to our target power of 17dBm (the 4th I blew up accidentally). We discovered some areas where the PCB layout could be improved to get even more power (perhaps 20dBm) out of the MP. The system clock was a few kHz off 40.0 MHz which when multiplied up to 2.4 GHz caused the 60 ppm frequency offset. This was actually the largest problem – it caused packet errors at the low data rates which messed up long range performance. Once this was fixed the packet error rate performance started to look as good as the reference DIR-300 unit we were testing against.

The variable power output of different MPs had a simple reason – some of the tiny 0402 parts were loaded in the wrong place. This is very easy to do as the parts have no writing on them. I only spotted this when I noticed two parts with the same value looked slightly different in colour. Usually all parts from the same reel look identical.

With our new-found experience, Atcom decided to make another revision of the PCB (V1.2) to tighten up the RF side. That should be ready for testing in November. If calibration checks out on V1.2 we will then kick off a Beta run.

Given our lack of RF experience, lack of AR2317 data, lack of support from the chip vendor, and very basic test equipment I feel pretty happy with our progress in RF performance over those two hard weeks. The %$%^ Asterisk channel driver for the Mesh Potato took me three weeks to get stable and I am meant to know something about Asterisk driver development!

As well at the core team of Elektra, myself, the Atcom team (Edwin, Alen, Mr. Lee, Peter), their Shenzhen friends and of course Steve, we had some help from Jeff (our RF consultant) and two other people who were especially kind:

I found Ben Johnson while looking for information on the Tek 492. Ben had posted a page on how he repaired his Tek 492. I emailed Ben to ask if he thought it was suitable for Wifi. Ben was kind enough to actually test his Tek 492 on some Wifi signals and email me the results! This gave me the confidence to bid for a used 492 on ebay here in Australia.

I met Dieter through an article I published on Low cost Electric Cars in Renew magazine. He just happened to email me on a day I was messing with the Tek 492 and I found out he was a microwave engineer working in Melbourne. Throughout the RF debugging process Dieter emailed me virtually every day and gave much needed advice and moral support. He even sent over some semi-rigid RF cable with an N-connector to help with the testing.

The Internet is amazing place. I am constantly bowled over by the kindness of people – especially when you are working on open projects.

Links

[1] Measuring Wifi Transmit Power – An in-depth look on how I used the Tek 492 to measure Wifi transmit power.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.