A Simple Configuration User Interface (UI)

While LuCI is tremendously powerful, we have found that it can be intimidating for new users. It also doesn’t offer the VoIP configuration features that are key to Village Telco. The new configuration UI in version 1.1 offers the most important basic options including:  setting the IP address and gateway, the WiFi hotspot, and configuring your VoIP provider details. The UI is smart enough to stop you putting in a malformed IP address or from choosing a WPA key for your hotspot that is too short, etc. It can also try to guess your gateway for you.  Of course you don’t HAVE to use the web interface to configure your Mesh Potato.  You can also configure it by phone.

Easy VoIP Setup

Previously you were obliged to edit the Asterisk configuration files in order to set up a SIP account with your VoIP Service Provider.  Now all you need is the URL of the the SIP provider and your username and password.  The UI also indicates when the Mesh Potato is successfully registered to the SIP provider.   This is set to work with the most common default setting of VoIP services providers.  You can go to the Advanced setting page if you require custom VoIP options.

Simple Access Point Configuration

Setting up the Mesh Potato as a WiFi access point is a breeze.  Simply enter your preferred name for the WiFi network (the SSID) and then choose the form of encryption you prefer for the network.  By keeping the SSID the same for all of the Mesh Potatoes on your network, you can create a large, seamless hotspot.  Most WiFi-enabled devices will hand-off from access point to access point if you move around in the network allowing you limited mobility within the network.

Security Options for your Mesh Potato

Once you’ve configured your Mesh Potato, you may not wish to make it so easy to access the configuration options for your Mesh Potato.  You have to consider the fact that your Mesh Potato can be reached by anyone on the mesh network.  The new firmware offers three options for securing your Mesh Potato.

1. Encryption.  You can turn on the encrypted web interface which will secure all traffic to the Mesh Potato making it extremely difficult for anyone to intercept configuration traffic to the Mesh Potato.  This means that you would access the same web UI but using the HTTPS protocol.
2. Password.  You can require a username and password to access the UI.  This is based on the root or admin user accounts on the Mesh Potato.
3. Limit IP addresses.  You can also make the webserver accessible only through the fallback IP address.

You can also disable the web interface entirely via the phone interface.

Integrate Smartphones with your Village Telco

The Mesh Potato is entirely standards-based which means that you can connect the Mesh Potato to any SIP server whether local or international.  But what if you don’t have the luxury of an Internet connection?  Well of course Mesh Potatoes are designed to make local calls to each other with or without an Internet connection or SIP server but what about using your WiFi-enabled smartphone on a local Village Telco network with no Internet connection?  This is now possible with version 1.1.  You can designate one of the Mesh Potatoes on your network to offer both DHCP and SIP services so that any WiFi-enabled smartphone can connect to the mesh network and dial the Mesh Potatoes and vice versa.   This has relevance for rapid deployment of Mesh Potatoes where you may not have time or resources to establish an upstream connection but still wish to make maximum voice use of the network.

Wireless Status Page

There is now a Wireless Status page that shows you the other mesh nodes in the network and devices that are connected to the WiFi hotspot on the Mesh Potato.  It is still a little cryptic.  In version 2 of the Mesh Potato firmware we’ll have a less technical status page although the more detailed stats will still be available.

How to Get It

You can download version 1.1 RC2 of the SECN firmware from:

http://villagetelco.org/download/firmware/secn/unstable/mp/SECN-1.1/RC2/

If you have never flashed a Mesh Potato with a new firmware, please follow this guide.   The default IP address for the 1.1 RC2 firmware is 10.130.1.20 or you can use the fallback IP address of 172.31.255.254.  You’ll note that this release is RC2 or Release Candidate 2 which means that the feature set is stable and we are not aware of any bugs but further testing is required to confirm this.

But Wait There’s More

The SECN firmware doesn’t just run on Mesh Potatoes.  It is also available for the TP-Link WR703N and the TP-Link MR-3020 so you can mix and match devices in your network.  The devices are completely interoperable with Mesh Potatoes running this firmware.  You can download those firmwares from:

http://villagetelco.org/download/firmware/secn/unstable/tp-703n/SECN-1.1/factory/ http://villagetelco.org/download/firmware/secn/unstable/tp-3020/SECN-1.1/factory/

Finally, I can’t thank Terry, Elektra, and Keith enough for what they’ve accomplished.   All this progress is directly attributable to their hard work.

Coming Next

Elektra, Terry, and Keith are already working on Version 2 of the Mesh Potato firmware which will include an upgrade to OpenWRT Attitude Adjustment and to the latest and greatest version of batman-adv.  We also have plans for a simple UI for switching between mesh, client and master WiFi mode for those who want to do different things with their Mesh Potatoes.  Suggestions, requests are welcome.

One of the early mistakes we made with the Mesh Potato was not placing sufficient emphasis early on, on getting type approval for the Mesh Potato and indeed focusing on both European and U.S. type approval.  What is type approval you ask?  Type approval is the magic glue that makes unlicensed spectrum work.  Many people take the term unlicensed to mean unregulated but nothing could be further from the the truth.  Unlicensed spectrum succeeds because the devices that are permitted to use unlicensed spectrum are carefully regulated to ensure that they conform to strict standards in terms of power output and many other technical specifications that ensure that unlicensed devices “play nicely” with each other.

I am happy to say that this issued has finally been addressed in full and Mesh Potatoes now enjoy full compliance with both the standards of the Federal Communications Commission (FCC) of the United States and the European Union’s CE standard.  These are the two most common international standards for compliance and should ensure that the Mesh Potato can conform to almost any regulatory regime.

If you would like to get copies of the certification in order to apply for local type approval in your country, please get in contact with us via this website.

We headed for Tankwa Town with a full load and empty wallet and flashed & configured the Mesh Potatoes (MPs) in the desert using the good ol’ 192.168 range. The booths were different to last year: they had production MPs, new sleeves and no lighting. I set each node with a different Virtual Access Point (VAP) SSID based on the phone number because I found that using an identical VAP SSID caused SSH to die. This will be ideal in the future, when each MP owner has a WPA key on their router and both cabled and VAP connections are linked to the same account. So any device that wants to roam must either switch between VAPs or run batman itself.

Steve came up for 2 days to help set up and bring some much-needed supplies. I discovered that an Olmeca tequila bottle is not as sturdy as it looks. It broke in the trailer and softened up the Tetrapak milk until most of the cartons ruptured too. So a Nano, a few phones and other gear were swamped. Thanks for the rescue, Steve.

We set up the booths easily this year – far less wiring and better ground pegs. We put phones in the organiser’s caravan, medics and the gate, with a Nano to cover the 5km distance to the gate. However this year they had moved the gate to the end of the airstrip, so it was only 1km away.

I had brought a netbook with broken screen to act as gateway, redirecting all port 80 traffic to a phpbb3 bulletin board with the appropriate DirtyBoard2.0 skin – see http://swug.za.net/phpbb/. I also redirected port 53 to dnsmasq that spoofed the DNS of  Top Level Domains (TLDs) to the gateway IP too. These are the kinds of things that naughty people do, but I think it works well for our application. I set each router’s dns as 8.8.8.8 and SIP registration to villagetelco.org. When a mesh is connected to the Internet, DNS & SIP will work fine (once VT has a SIP server). If there is no Internet access, DNS/SIP/HTTP can be fielded by an offline gateway server. It does look a bit odd, but it works.

The spoof gateway was running fine for devices connected to the LAN but was not accessible from the WAN. In fact, no other device connected to a different MP could be seen except for the MP’s LAN address itself. This suggested that there was an issue with the dummy gateway setting on the LAN, required to allow Asterisk to run as per David & Elektra’s discussion

I was 4 days into the trip by then and it was time to party, so I left the gateway for another day – and Internet access. It was most helpful though in checking the booths. Instead of plugging in a netbook, one could just pick a nearby cosy camp, settle down and connect wirelessly. DHCP, LAN bridging, batman routing, Asterisk were all working fine.

Solar operation

This year I invested in a 90W monocrystalline solar panel and regulator for the camp – 90 watts when the sun is shining for the next 25-50 years. It will be part of my home solar office in a few weeks. I had 4 105AH tractor batteries from last year and connected the gateway netbook and the fixed one (20-40W each), plus about 20W of lighting and didn’t have a power problem for the whole week.

We used the 10W flexible solar panels and 12AH batteries on the booths as with last year, but this time there was no lighting in the booths. 10W kept the booth MPs up throughout the week, but the batteries drained progressively. I put this down to the number of phone calls being made – nearly all the time, day & night. One booth’s phone was left off-hook providing dialtone for a few hours. I disconnected it for a charge back at camp and it was sorted. Perhaps a dialtone hangup can be written into Asterisk for such events on battery-powered phones.

I also installed a phone in a friend’s art car, connected to the cigarette lighter adapter. It was great to be able to phone the art car from anywhere and ask for a pick-up. However next year, I’ll bring along some battery clips so that the phone stays on when the car is off – see whether the MP can “survive the crank”.

Conclusion

This year was tougher with just Steve and I setting up, but easier because of the work we could build on from last year. The most promising result from this year were that the phones worked and worked hard. It gave me some time to work towards the 4093-node, no-NAT VAP firmware I long for. Although the VAP was not feeding into the gateway, every person with a wifi-enabled laptop or phone saw hotspots – so hopefully they’ll be better prepared next time too. Comments from participants were different this year too. Last year the phones were a novelty; this year people were more interested in and supportive of the technology behind the phones.

This year I met some important people for next year. Adriaan Wessels is the technical chap on the organising committee. For next year, we’ll be able to plan carefully regarding gate link and possibly organiser car links. Organiser confidence in the network will mean that they will be able to pre-announce a “Tankwanet” and its services so that participants can be better prepared to take advantage. There are a lot of IT geeks at Afrikaburn. Perhaps some of them could be persuaded to offer services on the network.

Rod Bracher runs the Tankwa Town post office, Burning Mail. They have some old rotary-dialling phones that they connect with carrier but without dialling. I tried to coordinate with him to hook his phones up to the network, but ran out of time. We had a chat about doing so at this burn, so pulse-dialling is definitely on for next year.

The streaming services company antfarm.co.za were at AfrikaBurn this year. I couldn’t spot their VSAT dish, but made brief contact. They were streaming the burns live, which led me to figure a rule at AfrikaBurn: the isolation is an important part of the event, but the isolation need only exist one way – incoming. So theoretically, participants should be able to send SMSs, update their twitter accounts and post on a forum on the Internet – as long as they don’t see any response from outside the burn. Antfarm’s ISP only allows Internet connection on port 80, so a little port jiggling and a helpful Internet server should squeeze whatever we need through, except for multiport SIP.

Lastly and simply, Isigidimi was at AB2011. The continuity will help us attract more participants next year, and perhaps more of the VT-dev community. You can set up an Asterisk service, website, jabberd, tinker with pulse-dialling, or just sip on the Kool Aid and be inspired ;^)

Here are some more images from Afrikaburn 2011

In terms of a place to pilot a Village Telco, it sits above the demographic we intended the Village Telco for but it seemed a good choice for a number of reasons:

1. There is a really strong community.  There are strong social bonds linking everyone in the Bo-kaap and strong social bonds means a strong desire to communicate locally.  This was the strongest motivator for choosing the Bo-kaap
2. We’re still learning and don’t want to create a dependency on something that is still evolving. The fact that Bo-kaap community is a little wealthier on average than our target community means that although they may value the Village Telco, they won’t be completely stuffed up if something goes wrong as we perfect the network.
3. It’s convenient.  Tempting as it is to set up a rural Village Telco right away, the Bo-kaap is not many minutes away for me so easy to get to and work on.

At the right you can see a screenshot from the Afrimesh software that we use to monitor the mesh.  Right now we’re up to about 50 nodes in the mesh and the increasing density continues to make things easier and easier.  In the beginning we had to be very careful about long links and used some Ubiquity Nanostation IIs to make some of the long shots.  We also had to be very careful about getting the Mesh Potatoes into a strategic position to pick-up other Mesh Potatoes.  Now, once I get up on someone’s roof, I can usually see a Mesh Potato in some direction so installation is as simple as finding something to attach the Mesh Potato to.  TV antenna’s have proven to be very convenient in this regard.

The installation process for the Bo-kaap has been slow, partly because it took a long time to get production Mesh Potatoes into our hand but also because the Bo-kaap is an old community and the houses in it have evolved more than they have been planned.  Each house is a little exercise in complexity in terms of getting to the roof, finding a cable path down from the roof, finding power near the desire location of the phone, etc.  I’ve got it down to a routine now though.  Having the right tools like a long concrete drill bit for going through walls are simple things that make life a lot easier.

We’re learning a lot as we install the Bo-kaap Village Telco.  We decided to offer 100 Mesh Potatoes to the community in exchange for user feedback on the Village Telco.  In order to build the most useful network possible, we built connections by following social ties, a bit like snowball sampling in research.  We started with a family that ran a cafe and followed their social ties, brothers, sisters, friends, neighbours.  Each new person is at liberty to suggest others.  By following existing strong social ties, the Village Telco immediately begins to delivery high-value connections.  An older mother-in-law that wants to stay in touch with her family who are only a few doors away but it is hard for her to get around.  A mother who recently became a grandmother wants to stay in touch with her daughter.  In each of these cases, they could use a mobile phone to call but like the majority of people in South Africa they are conscious of what time spent on the phone costs them.  A local Village Telco call is free.

Mesh Potatoes can be gateway-ed to other telecom networks and can also offer Internet services but for the time being we are just offering local voice because the devices do that on their own at no additional cost.  Once the community is ready to take over the network themselves and manage external voice and Internet charges, we’ll enable those other features.  Stand by for more from the Bo-kaap Village Telco.

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.

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.

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

1. 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.
2. 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.
3. Joel then pointed his browser at 192.168.1.20 and the Web GUI came up.
4. 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:

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

Configuration without a Web browser

1. Power up your Potato and connect a phone, after about 1 minute you will get dial tone.
2. Dial CONF (2663) and you will hear HAL 9000 talking to you!
3. 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.

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:

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.

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

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.

Last year a bold and creative group of geeks conceived of an Open Hardware / Open Software device that would both simplify and lower the cost of deploying wireless mesh voice networks.  We called it the Mesh Potato which is a mashup of Mesh + POTS + ATA.  Well , it works in Spanish at least.  A year later we had working Mesh Potato prototypes to hack at the workshop. And that is what the workshop focused on, getting the Mesh Potato into production and helping it go to scale.  The rest of this post is a summary of the key elements of the workshop.

Technical Design Trade-offs

One of the first conversations we had at the workshop was to review the technical design decisions to date and discuss the pros and cons of each decision.  From the beginning we have tried to balance a desire to make the Mesh Potato as hard-to-break (or brick for that matter) as possible with a need to keep it affordable.

Antenna Type

Based on her experience in Bangladesh, Elektra proposed the more robust N-type antenna for the Mesh Potato as opposed to the smaller but less rugged Reverse-SMA antenna typically found on low cost wireless APs.  Because the N-type was more expensive there was some discussion as to which was the best option.  This debate was rendered somewhat moot when we realised that we could both save money and increase robustness by going with an internal antenna etched on the motherboard of the Mesh Potato.  That was a big design step for us as it rule out the flexibility of attaching different types of antennae to the device but it seemed like a reasonable trade-off.  Even now though a connector for an external antenna may find its way onto the motherboard somewhere.

FXS Interface

In the design of the Mesh Potato, we have opted for a compromise of speed in getting the Mesh Potato to market and optimal cost-effective design.  David pointed out in the workshop that with another month or so of design work, he would be able to bring the cost of the FXS module by over 50%.  Clearly, this is something to prioritise for the next generation of Mesh Potatoes in terms of producing a very affordable device.

AC Adaptor

A surprise for me in the discussions was recognising what a weak point the AC adaptors are in the context of the whole system.  We have gone the extra mile to harden the ports on the Mesh Potatoes to handle variable power sources, lightning strikes, etc but we haven’t discussed the AC adaptors at all.  These are obviously the first things to go when plugged into an unstable or incorrect power source.  While designing a custom AC adaptor would possibly turn out to be too expensive, it is possible that we will be able to get a higher rated power supply for the Mesh Potato.  David and Edwin are looking into this.

Power Supply Chipset

We had a good discussion about the trade-offs of between a high quality power supply chipset which would give us a 10% savings on the power consumption versus the cost of the chipset which was almost an order of magnitude more expensive than the cheaper option.    One insight for me was that the big win on power for the Mesh Potato is simply that of combining an AP and an ATA in a single device.  That halves the typical power consumption right there.  A 10% savings on top of that is desirable but has to be balanced against overall cost.  There was also a discuss about handling unexpected high voltages such as from an unregulated solar panel and here I have to defer to David and Elektra to chime in as it was beyond my modest capacity to fully grok.  The bottom line is that we are opting for the cheaper power chipset but some additional design is required for this chipset to cope with the high voltage scenario.

PoE and PoTL Injectors

The discussion around PoE (Power of Ethernet) an PoTL (Power over Telephone Line) injectors was pretty wide ranging.  We’d like to create the most flexible scenario possible for the Mesh Potatoes so that they can be powered by standard power cable or PoE using a single ethernet cable or PoTL using a standard telephone line.  We even discussed putting power and ethernet and telephone line through a single cable but the consensus at the end was to be as standard as possible to avoid misconfiguration.  PoTL in particular is a little hazardous because of the comparatively high voltage going over the phone wires.

Rael had a very innovative solution in which the Mesh Potato ports could be snapped on or off the Mesh Potato and extended via PoE.  This would make the Mesh Potato ideal for indoor or outdoor installation but we decided that it was going to add a level of complexity to the design that would slow getting the MPs to market.  Something to look at seriously for the next iteration though.

Case Design

Another significant topic of discussion was the case design.  We all agreed that we wanted the following:

• a water resistant case that can withstand a rain storm;
• UV resistant plastic that will work for years under an African sun;
• white or beige case to keep the device as cool as possible;
• ports should be covered inside the device;
• an LED display to aid configuration; and,
• fittings for both pole and wall mountings as well as possibly a desktop mounting.

In the end it transpired that what we were talking about would look remarkably like an Ubiquiti Nanostation Loco.  Hopefully we may even improve on Ubiquiti’s mounting bracket design.  After seeing some Vodacom payphone units in Khayelitsha we also discussed possibly replacing the LEDs with an LCD display that would open up possibilities for innovation in terms of debugging, configuration, payment status, etc.  We’re still investigating this possibility.

Software Development

I’ll break the software discussion down into the Mesh Potato, Afrimesh on the Mesh Potato, Server Configuration, and Miscellaneous.  Needless to say the conversation was not that structured. 

Mesh Potato Initialisation

We all agreed that to the extent it is possible, we’d like the Mesh Potatoes to work as a telephone network right out of the box.  This applies both to the scenario where they are working in peer mode i.e. not connected to an upstream server and when they are connected to an upstream asterisk server which could be on the local network, at an ISP, or even in the cloud.  Key to making that work is to ensure that each Mesh Potato that comes off the production line has a unique IP address.  Type wireless AP devices have a standard default IP address.  This would not work for us because Mesh Potatoes would then need to be individually configured by the user.  Thus, each MP needs to begin its life with a unique IP address.  Jeff Wishnie proposed a similar strategy to that used by Meraki which is to generate an IP address from a hash of the MAC address of the devices.  We decided that each MP should not only have a unique IP address but also a unique phone number which would be derived from the last 9 digits of the IP address.  We even came up with an unused country code (+288) which might be used to give the Mesh Potatoes a fully addressable unique DID at some point in the future. More about this on the wiki.

We also established that it would be desirable to be to switch any Mesh Potato into a ” voice master” mode so that other Mesh Potatoes on the local mesh would automatically recognise a configured Asterisk server on the network.  Elektra suggested that this could be achieved by having the “voice master” node announce a voice gateway class to the network in a very similar manner to how the mesh network announces upstream gateways via a class.  [Need a link to more info on this]

EasyTAG UI

Finally, because the Mesh Potatoes will have effectively random IP addresses out of the box, which will allow them to work as a network from power-on, the Village Telco entrepreneur is likely to want tools for mass configuration of the network, e.g. putting all the nodes on a single subnet, re-numbering the phone numbers, etc.  The whole mass-reconfiguration thing made me think of my music collection and the elegant simplicity of tools like EasyTag which allow you to batch edit an individual attribute of a single mp3 file or a thousand.  Having an EasyTag-like editor to edit the attributes of the Mesh Potatoes on your network would make network configuration a breeze.

ToDo:  Develop all of the above.

Afrimesh

Over the course of the workshop, Antoine managed to get his very elegant Afrimesh software running on the Mesh Potatoes.  He has posted some instructions on how to install Afrimesh on a fresh OpenWRT install.   Afrimesh on the Mesh Potato will serve three core functions.

1. Default GUI:  Afrimesh will be the  default web GUI for the Mesh Potato.  If you plug your laptop into the Mesh Potato via the ethernet port and point your browser at the MP,  Afrimesh is what you should see.  Any other software should be accessible via Afrimesh.
2. Network performance: Afrimesh provides the user with a dynamic map which shows the active mesh nodes on the network and their relative health.
3. Basic configuration: Afrimesh should allow the user to configure basic things like network name, IP address, etc.  For more sophisticated configuration, Afrimesh provides a link to Luci which can open a Pandora’s box of configuration options for the more intrepid user.

ToDo:

• Develop an Afrimesh package is easily installable on OpenWRT and which is also part of a Mesh Potato “target” firmware for OpenWRT
• Develop the network monitoring aspect of the Afrimesh software to include visual monitoring of network performance over time

Interactive Voice Response (IVR) Configuration

Naturally we don’t wnat to just have one way to configure the Mesh Potatoes, there should be several.  In particular, the Mesh Potatoes should be configurable without a web interface i.e. just by picking up a handset.  David made some initial progress in setting up IVR to be able to configure the IP address of the Mesh Potatoes, even working in a 2001 Space Odyssey clip to catch the attention…. “What are you doing, Dave?”  The goal is ultimately to have a suite of commands that could be issued via the phone keypad to be able to both diagnose and configure the Mesh Potatoes.

Default Asterisk Configuration

In order to make it as easy as possible for people testing out the Mesh Potatoes to set up their own VoIP networks, we need to develop some basic Asterisk configuration instructions, files, snippets and even bootable ISOs for Mesh Potato networks.  Work on that has begun on the VT wiki.

Points of Pain

It seems worthwhile ending off this workshop summary with a review of a sessions we called “points of pain”.  That is, what do we need to work on on the Mesh Potato and the Village Telco that will have the biggest impact on both the ease and cost of installing an MP network.  Here are what we came with:

• From a cost perspective “ease of installation” as just important as driving down the purchase price of the Mesh Potato.  A Mesh Potato that is difficult or simply complex to install can add as much as USD 50 to the total cost of the device.  A reminder to make the Mesh Potato blindingly easy to install, monitor, and debug.
• Less to do translates into lower error rates.  Pre-configure as much as possible and anticipate  as many scenarios as possible.
• Investment in software affects the hardware cost.  In this case we are talking about things like have David re-design the FXS interface.  In the spirit of hardware is the new software, smarter software/firmware can allow us to use less expensive (but not lower quality) components in the Mesh Potato.
• Scalability is critical.  What does an MP network look like at 10, 100, 100, 100 000 devices?  All software and design choices need to scale.
• Distinguish between technical infrastructure and payment infrastructure (I actually can’t remember exactly what we meant by this… other than the obvious)
• Protection is key.  Ensure that the Mesh Potatoes are as invulnerable as possible to natural (accidents, lightning, surges, brown-outs, etc) and un-natural (misconfigurations, theft, etc) events.

That’s about as much as I am able to capture from the event.  I hope participants will chip in the comments to flesh out and/or correct memory blips on my part in the post.  It was amazing (again) having such creative and brilliant minds crafting a future for the Mesh Potato and the Village Telco.

-Steve