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.

SPUD is a PHP based dashboard that communicates with the BATMAN visualization server and displays real time wireless link status. The software is written in CakePHP (a PHP-based MVC framework) and uses Google Maps API 1.3 for visualization.

SPUD is designed to be as simple as possible to use, and to enable teams, that have installed large amount of mesh nodes, to visualize their networks quickly.

Some of the core features of SPUD are:

• Client management: Bulk import of clients from CSV file, Edit client position with Google Maps, Tracking of new clients
• Link monitoring: Easy overview of active wireless links, Mesh quality in each direction of a wireless link
• Customization: Colours and threshold values for link quality

See above and below for screenshots that shows some of the functionality of SPUD.  The source code is available via SVN at

svn co http://dev.villagetelco.org/svn/villagetelco/spud/trunk/

and the default configuration will monitor our demo site in Bo Kaap (Cape Town)

Detailed installation instructions are available at

http://spud.it46.se/spud/install (user: vt-admin pass: ouagadougou) or http://dev.villagetelco.org/trac/wiki/spud_install

We have set up a demo site of SPUD that visualizes the Bo Kaap network. The demo is available at: http://spud.it46.se/spud . Please feel free to play with it, and provide us your feedback!

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

Setting “smart defaults” is a key to masking complexity and lowering the barrier to uptake.  Think of Google’s search minimalism after Altavista et al or Apple’s simplification of so many applications that were filled with twiddly knobs, checkboxes, and radio buttons in other operating systems that shall remain nameless.    Wordpress is another great example of an application that is capable of impressive sophistication for “blogging software” yet pretty much “just works” after completely a bare minimum of setup information. Terry has taken us one giant step closer towards WordPress-like usability with his Small Enterprise – Campus Network (SECN) setup for Mesh Potatoes.

His goal to be able to serve a local network of modest size offering seamless voice and data.  He wanted any Mesh Potato to pick up Internet connectivity via the ethernet port, if it could find it, and for each Mesh Potato to offer a local WiFi access point.  After experimenting a little bit, he chose to install the BATMAN-ADV mesh protocol instead of BATMAN protocol we currently use.  The big difference between the two protocols is that BATMAN-ADV runs at Layer 2 and BATMAN at Layer 3 of the OSI layer model.  What does that mean?  Well the simplest explanation is that BATMAN-ADV makes Mesh Potatoes behave as if they were all part of one big network switch which means that IP addressing and routing for the network is dramatically simplified as each Mesh Potato is effectively transparent to the IP network.  This effectively removes the hassle of figuring out network addressing and Network Address Translation for Mesh Potatoes.  Everything is just one flat network which means that devices can easily communicate with each other on the network.  The flip side of this is that you have to be careful about what you put on the network because a poorly configured or worse infected computer can generate a lot of local network traffic.  This is something we’re exploring but for a small network, BATMAN-ADV seems to work exceedingly well.

With Terry’s modifications, an SECN configured Mesh Potato network will now:

• offer an encrypted, WPA-enabled, wireless access point as well as a peer-to-peer wireless connection on each mesh Potato.  This is done by creating a Virtual Access Point (VAP) on the same radio interface as the mesh.  Initially we chose not to enable this by default on the core Mesh Potato distribution because we were concerned about network data load have an impact on voice quality but Terry’s work makes me think that this was a mistake.  Much better to encourage use and solve the problem of over-use rather than ensure a functional but underused network;
• pick up a network connection from any DHCP-enabled Internet-connected device it is connected to the ethernet port on the Mesh Potato;
• transparently carry DHCP requests over the network to devices connected to Mesh Potatoes whether by ethernet or WiFi; and,
• offer simple on-network and also VoIP service provider configurable phone calling.  Local phones can be dialed simply by entering the last 3 digits of the IP address of the Mesh Potato you want to call or the Mesh Potatoes can be registered with any VoIP service provider.

The long and short of this is that if you plug in a bunch of SECN-configured Mesh Potatoes and make sure at least one is connected to something simple like a DHCP-enabled ADSL router, then you have a transparent, highly-adaptable technology for creating a robust local telephone and data network with no wires.

So, did Terry do this all by himself?  Without Terry’s interest and hard work at testing, reconfiguring, debugging the SECN version might never have happened but one of the great things about Open Source is that one is rarely starting from scratch.  He was able to build on the configuration that Elektra built for the Mesh Potato which in turn built on great Open Source initiatives like OpenWRT, Asterisk, and others.  And at least a dozen people in the Village Telco community were there to help him solve problems and answer questions.  Better still his work inspired others to try out new configurations with the Mesh Potato and Elektra was inspired to take the set of instructions that he had developed and embed them in a new Mesh Potato firmware distribution that people can use to set up smaller Village Telco networks to serve both voice and data.

If you’re interested in trying this out yourself, you’ll need a few Mesh Potatoes to start and then you’ll want to download the latest SECN firmware and flash the Mesh Potatoes with this new firmware.  Terry has been developing the documentation for the SECN, the latest version of which is here.  Because this is still at an early stage, that URL may change.  Best to check in with the Village Telco google group to find the latest version.

Comments welcome.

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.

You can see the final design of the Mesh Potato at the right.  Those of you are familiar with the Ubiquiti Nanostation II will know that we borrowed wholesale from their excellent enclosure design.  They say imitation is the sincerest form of flattery.  In this case, it is certainly true.  We love Ubiquiti gear.

What we’ve borrowed from Ubiquiti is the sealed-unit design which makes for a sturdy weather-proof enclosure.  What’s a little bit different is the back mounting which has a slip-on piece that can be screwed to a wall.  Without the screw-on piece there is a similar mounting to the Nanostation for mounting on a pole.

The best news of all is that Mesh Potatoes are now available for purchase by anyone.  Simply click on the Products link above to buy them from our webstore.  The cost of each Mesh Potato is USD 119 but for the next two weeks we’re making them available at the wholesale price of USD 89 per unit.  In order get that price, enter “afinemesh” as a coupon code on the Checkout page after you have selected the number of Mesh Potatoes that you’d like.  Shipping is calculated via DHL from Atcom in China.  Please contact us if you’d like to make other shipping arrangements.  Orders placed now will ship by the end of September.

Finally, I would just like to express ongoing amazement and appreciation of the many, many people who have contributed to making the Mesh Potato a reality in small ways and in big earth-shaking ways.  You know who you are.  You all seriously rock.  Open Software, Open Hardware refreshes the parts that other intellectual property regimes can’t reach.  Thank you.

Test call by HAFOTI Director. HAFOTI is an NGO working on Womens issues in Timor Leste

Links

1. More photos of the Dili Village Telco roll out.
2. The Dili Village Telco Wiki.
3. Other blog posts in the Dili Village Telco series.

Testing at Atcom in June

In June I was visiting Atcom in Shenzhen, China. The first 1.3′s were calibrated and ready for testing so we headed out to a nearby open area with some MP01 V1.2 and V1.3 prototypes.

We taped a V1.2 and a V1.3 back to back on a length of PVC pipe to compare results at roughly the same height. Lead-acid batteries were used for portable power.

MP01 V1.2 and V1.3 back to back

We did some A-B comparison tests, e.g. a V1.3 to V1.3 call then a V1.3 to V1.2 call and V1.2 to V1.2 call. As well as making calls we measured the rx signal strength using the node_tune.sh script. We wandered about and tested at various ranges.

Edwin and Alen seemed happy that the two antennas (V1.2 omni and V1.3 printed antenna) worked about the same. This is consistent with the tests Jeff and I performed last December.

The node_tune.sh script reports rx signal strengths to a laptop. It’s hard to be precise as the levels bounce around by several dB. Also we must remember the signal strength indicator on a AR2317 SoC is not a calibrated instrument, it’s just a rough estimate. Typical result might be -70 +/- 3 dBm over 10 signal strength samples. As near as we could tell, the results were about the same for the V1.2 and V1.3.

Given it was an inner city site there were other networks on the same channel so ping times bounced about a bit. Despite that the guys managed to make OK phone calls up to about 350m, with the V1.3 only a few metres above the ground. At that height 350m between omni antennas is actually better than I have achieved in Dili or Adelaide. Not bad considering we were in the middle of a city of 12M people.

Time to introduce some of the Atcom guys. From the left we have Nick and HeZhong. Alen (the MP01 hardware engineer) is in the blue shirt, and Edwin is on the far right holding the potato stick.

Atcom Guys

It was about 30C and 95% humidity but still nice to be outside. Everyone seemed to enjoy themselves, and it was good training for Atcom in antenna testing. For example when we walked behind a tree the phone call dropped right out, a few steps to one side and the call came back up. I have also used the “potato on a stick” training method with great success in East Timor. Quick and fun education in Wifi propagation.

Testing on the Jetty

By July I was back in Adelaide. Time for some more potato testing. Joel and I repeated the tests on the Jetty with the V1.3. The site and path (400m Line of Site) was the same as the January tests.

The call quality was fine with the MP in any orientation (I rotated it during a call), even kicking it around on the surface of the jetty with my feet. Pretty similar to January’s results with the prototype PCB antennas. The audio would drop out when Joel stepped in front of his MP but seemed to come back up after a few seconds. Perhaps the Wifi bit rate automatically dropped to account for the extra path loss of Joel!

Checking the Antenna Impedance

Next I hooked up my Standing Wave Ratio (SWR) bridge to the MP V1.3 antenna. The SWR bridge is described in this earlier post.

SWR head, microwave PCB made with a Dremel tool

The SWR bridge lets me test if an antenna is resonant. If it is resonant the antenna impedance will look like a 50 ohm load at 2.4GHz. The SWR bridge can also be used to compare the V1.3 PCB antenna with other Wifi antennas. As described in the earlier post the SWR bridge produces a DC voltage that indicates the mis-match in the antenna impedance from the desired 50 ohms. A low voltage from the SWR head is a good result. Here are the results:

The MP V1.3 PCB antenna is very close to the “ideal” 50 ohm resistive load. Although with this rough home-made kit a fairer conclusion is that the V1.3 antenna is in the same ball park as the others.

The SWR head & V1.3 antenna was driven from another Mesh potato sending ping floods. A 2.4GHz signal generator would make this testing easier. Using a Wifi transmitter as a signal source means bursty TX signals which makes these measurements tricky. A 2.4GHz sig-gen I could sweep (even manually) would also be great to determine exactly where the antenna is resonant.

Testing the V1.3 Antenna SWR

The V1.3 has a group of three 0-ohm resistors that can be used to change the antenna configuration. The resistors simply act as shorting links, they could be replaced by blobs of solder:

PCB Antenna and Mode Select Resistors

Close up of Mode Select Resistors and J4

The normal configuration is R406 and R404 loaded. This connects the AR2317 SoC to the PCB antenna. To use an external antenna, R406 and R402 is loaded. This connects the AR2317 to J4, where a pigtail can be used to connect J4 to the external antenna.

A third possibility is R402 and R404 loaded. This removes the AR2317 from the circuit, and allows the PCB antenna to be connected to J4 for testing. This is the configuration I used for testing with the SWR bridge in the photo above.

A 2.1km Test between Jetties

On 3 August we made phone calls over a 2.1km path using two V1.3 MP01s with the built in omnidirectional PCB antenna. The phone calls were of excellent quality (no pops or clicks).

Thanks very much to my friend Angelo (a local Electronic Engineer) who helped out on the day. These tests take hours to set and perform and it’s great to have a friend to help.

Angelo on Grange Jetty

Angelo is an IT Sys Admin by day and loves trouble shooting. During the Wifi test set up we (quite accidentally) stumbled across a previously unknown but serious bug in the Power over telephone Line (PoTL) part of the power supply. Just in time to prevent the bug being repeated 500 times in the first production run! Thanks Angelo for helping us track this bug down.

For the Wifi tests we used two local jetties (Grange and Henley) which extend 500m out to sea. This reduces interference from nearby Wifi networks and gives good height above ground (sea) level.

Below is Grange Jetty as viewed from Henly Jetty. Sorry about the grainy image below. Grange Jetty is so distant it is hard to image with the camera I have. Angelo is the guy with the brown eyes standing just behind the canopy at the end of the jetty.

Grange Jetty viewed from Henley Jetty, 2.1km away

Angelo suggested we could have gone much further. I think I agree, as doubling the distance again is a only a further 6dB power loss. But we have run out of convenient jetties for now.

These results, like the earlier results above, show that the V1.3 PCB antenna is working very well. I would like to take this opportunity to thank Jeff Wojtiuk for doing an excellent job in designing this antenna. Thanks Jeff! I would also like to thank Alen Chen from Atcom who has done a fine job on the PCB layout and hardware engineering for the MP01.

Some test data and results, gathered from the Henley end of the link:

• Height at Grange Jetty was 8m+4m mast
• Height at Henley Jetty was 8m+2m mast
• ping -s 1400 -c 100 21% loss 29/42/76 ms
• ping -c 100 7% loss 3/6/12 ms
• Batman metric 240-250
• “iwlist ath0 scan” detected 6 networks, between -81 and -95dBm

I used the node_tune.sh script to measure received signal strength while rotating the Henley end MP01. The signal strength varied between -90 and -86dBm over 360 degrees, with a peak (-86) being reached with the front of the MP01 at 90 degrees to Grange Jetty, i.e. the PCB antenna was edge on. This is an unexpected result.

We tried rotating the MP01 at the Grange end. In this case the maximum signal strength was reached with the MP01 facing Henley jetty. This is the expected result. The difference between the two sites makes me wonder of other factors were involved. For example multipath due to reflections from the sea or nearby metal objects.

Rotating could also have induced a Wifi bit rate rate shift (e.g. from 5.5 to 1 Mbit/s). The AR2317 transmit power varies betwen 15 and 20dBm between 54 and 1 Mbit/s. A rate shift over the link would cause lower lower tx and hence rx power but a higher bit rate. I performed the rotation tests during a regular phone call. Perhaps using broadcast packets would have been a better idea, IIRC they are transmitted at a fixed bit rate and hence fixed power level.

It is important to remember that the AR2317 RSSI indicator is not a calibrated measuring instrument. It is probably not very logarithmic, and no doubt drifts all over the place with temperature and varies from unit to unit. Burst Wifi and interfering signals make power measurements difficult. So we can treat the received signal levels as indicative only. For example I assume an error of +/- 3dB on any RSSI measurements in this system. A much better way to measure RX signal power is to use a spectrum analyser as the receiver.

Using a Wifi calculator I checked the free space path loss and Fresnel zone clearance. The expected power at the receiver is:

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

Plugging in the numbers we get:

Pr = 17 + 2 – 106 + 2 = -85dBm

The driver reported the received power as -86dBm, which is a reasonable match if you trust the received power measurement (which I don’t). Still, it’s fair to say we are in the ball park, and that both the antenna and MP01 radio are performing well. Crystal clear VOIP over a 2100m Wifi link with just Omni antennas and 50-100mW is an exceptional result.

I plugged in 17dBm for the tx power above as I was unsure of the bit rate, unfortunately I don’t know how to read the current bit rate of the Wifi driver in ad-hoc mode. The actual tx power could be between 15 and 20dBm, depending on the bit rate.

The 1st Fresnel zone was 8m which we should clear OK with our masts and the jetty height above sea level. However I am not sure what effect the sea has on Wifi. Being slightly conductive it’s probably more reflective than a path over land.

These results show us how important interference and Line of sight (LOS) are to Wifi. In Dili we couldn’t set up a 300m link between MPs equipped with Omni-directional antennas due to massive interference. Even to obtain that range with directional antennas we needed huge, free standing masts (up to 25m) to clear obstacles like trees. However “on the beach” we can achieve an impressive 2.1km with omnidirectional antennas and modest power levels.

Links

Coincidentally a couple of friends sent me this link on PCB antenna design while I was writing this post.

Pilatus PC12 at Aldinga Airport

Flying to Arkaroola

One hour and 20 minutes later we were guests of the Arkaroola Sanctuary who delivered us via bus, 4WD and helicopter to various locations for trials of the Serval technology. The Arkaroola people were very excited and very helpful. One thing I love about the Village Telco is the good will it generates. Once the project is explained people go out of their way to help you. Projects with social rather than commercial aims are so much more satisfying to work on.

The silence at Arkaroola is amazing. Remote and sparsely populated wilderness. Nice terrain for Wifi too – lots of hills and no trees.

Helicopter from Sillers Lookout

Serval is a system for rapid deployment of phone networks in disaster relief scenarios. Serval uses Village Telco technology (mesh telephone networks) combined with several new innovations. One is Distributed Numbering Architecture (DNA), a way to assign existing cell phone numbers to your phone on the mesh network. The Serval team has hacked Android mobile phones so they work as mesh telephony devices. This involved porting Batman and Asterisk to Android. Very impressive and very cool.

Dany Testing at Flinders University

The result (so far) is a cool numbering scheme where you can assign phone numbers in the field without a server and the worlds 2nd mesh telephony devices (and first mobile mesh telephony devices). The “Serval Batphones” integrate seamlessly with Mesh Potatoes. The DNA software can also run on Mesh Potatoes. Future work will involve using OpenBTS to integrate GSM connectivity.

The Serval team is lead by Dr. Paul Gardner-Stephen from Flinders University. Paul, Romana Challans and Dany Rakotopara (a talented French exchange student) have been working crazy hours to get everything coded, integrated, and to organise the amazing 1-day field trip we had yesterday.

Paul and Dany developing Serval

Serval is partially supported by Flinders University (thanks for funding this demo trip) with large chunks of volunteer effort by the Serval team. The story was exciting enough to attract a local ABC TV crew to join us. I was really impressed with the way Paul, Romana, and the University media department coordinated the media side. Serval and the Village Telco is a great story. This is a point I often miss. I freely admit I am “too much of an engineer” and don’t appreciate the strong media value of our project and the leverage it can provide.

The demos involved three scenarios for rapid deployment of telephone networks; (i) disaster relief, (ii) search and rescue, and (iii) deploying networks in difficult terrain.

I learnt a lot yesterday by talking to Paul and the team:

Wifi and Android penetration in handsets is growing rapidly. This means that in a few years all phones could have mesh telephony built in. Every cell phone could be a “Batphone”. Mesh Potatoes in fixed locations can be deployed quickly in strategic locations to relay the phone calls and blanket areas with a mesh network. You can then use your existing phone handset to make calls on an ad-hoc Wifi mesh network.

Serval Bat Phone at Arkaroola

This is a first world twist on the developing world focus of the Village Telco. In the developing world the Mesh Potato will be the telephony device and it’s low cost is an important factor. However in the first world everyone already has a handset. So it makes sense to use them in a disaster relief scenario.

Key points here are high mobile phone handset penetration (everyone carries one) and the low cost of mesh Wifi networks. The demos yesterday used less than $2000 worth of equipment (Android phones from eBay and Mesh Potatoes) to form a phone network covering 1 square km.

Eye of the Potato: A Mesh Potato overlooking Arkaroola Village

I find it very satisfying that Village Telco technology can be quickly combined with other technologies like Serval. Try forking GSM and you will see what I mean. Accelerated, unencumbered development using Village Telco tech is possible because it is is fully open and uses unlicensed spectrum. Derivative projects like Serval are just the beginning. As I flitted over the beautiful arid landscape in a small helicopter the thought “What hath Steve wrought” (apologies to Samuel Morse and Steve Song) flashed through my mind.

Helicopter at Sillers Lookout

Testing in the bush

Bus to Arkaroola Village

Romana being interviewed for the Serval documentary

Dany enjoying the helicopter

Paul and The ABC TV crew

Potato Tree - 4AH Lipo battery is a great idea

4WD trip to the Observatory