Michael Adeyeye

Michael Adeyeye has been a member of the Village Telco community since its earliest days.  Back then he was a graduate student at the University of Cape Town but has since gone on to earn his PhD there.  He is now a lecturer in the faculty of Informatics and Design at the Cape Peninsula University of Technology.  As a researcher, Michael has published papers on Village Telco and has volunteered his time in helping to deploy one of the first Village Telco test networks but more recently has set up his own Village Telco network in his home city in Ibadan, Nigeria..

The map shows the different Mesh Potato nodes in the network and strength of the links between them.

Working through his own company, Asmicom, Michael partnered with colleagues in Ibadan to set up the Ibadan Wireless User Group.  Asmicom’s goal is to transfer technical know-how to Nigeria and empower her youths.  Their first project was to deploy a Mesh Potato network at a housing estate in Ibadan.  The estate is home to a number of hostels for postgraduate students (studying at nearby institutions), offices and business centres. There are single family houses on the estate mostly occupied by their owners. The students, like the home owners, wanted a reliable way of communicating with one another. In addition, the organizations (which are mostly non-profit organizations) wanted an affordable communication service that could be used as an alternative to the costly GSM mobileservice.

To make matters worse, the underground cables used by the Public Switched Telephone Network (PSTN) were recently uprooted by a government contractor, when tarring the roads in the estate.  These are the primary reasons for providing a scalable, standards-based, and DIY (Do it Yourself) telephone system in the community.

Most of the Mesh Potatoes are solar powered.  Michael has been using solar power units from a UK solar power startup called BBOXX.  Their BB12 unit is ideally suited to powering a Mesh Potato in Africa as well as providing a power source for laptops and/or lighting.

To the right you can see can see the BBOXXes in action.  Those are 30W solar panels charging a 12 VDC 12AH battery.  The blue LED lights on the front of the box indicate the charge level.  And below on the left you can see the network installers in action.

Friends and colleagues of Michael’s deployed the network. Raphael Adeyeye, Samuel Adeyeye, Oluyomi Kabiawu and Olumide Alamu all worked tirelessly to get the network in place.  You can see Raphael in action on the left and more of the Mesh Potatoes deployed on the right.  Mesh Potatoes can be mounted just about anywhere.

If you’re interested in finding out more about their deployment or getting their help with a wireless mesh network, you can contact them at:

Organization: Asmic Computers

Website: www.ngportal.com/asmicom

Email: asmicom@ngportal.com

Location: Ibadan, Nigeria

We’ll check back in the coming months to find out how the network is growing.  Kudos to Michael and the Ibadan Wireless User Group for providing the housing estate with an opportunity to choose an alternative communication services.

Jorge Gomez – Colombia

Jorge is based in Fusagasugá, Colombia which is just outside of the capital Bogotá.  While there is Internet, phone and mobile services in the city itself, service in the surrounding hills is variable. Jorge has found a niche business in providing service to those whom geography has excluded from access.  Currently Jorge has deployed 50 Mesh Potatoes in one community and 30 in another.

 Jose Soto – Puerto Rico

Jose runs a small wireless ISP in Puerto Rico.  In central Puerto Rico, fixed line services are often in need of repair and mobile service is often limited due to the mountainous nature of the region.  Jose has deployed 83 Mesh Potatoes and has plans to extend services to 10 pueblos in the central Puerto Rican region.

Wayne Abroue – South Africa

Wayne lives in Kranshoek in the Eastern Cape of South Africa.  Kranshoek is not far outside Plettenburg Bay, a popular holiday destination in  South Africa, yet until recently Kranshoek had no Internet connectivity.  That was until Wayne negotiated a wireless backhaul link with an ISP and began to deploy a combination of Mesh Potatoes and Ubiquiti wireless nodes to create the Kransmesh.  He currently has over 30 nodes in the network and plans to deploy another 30 very shortly.

Click for printable PDF

This is a howto from Elektra on building an antenna reflector for your Mesh Potato. Properly attached and deployed it should more or less double the existing range of the MP.

Basic Material

190 x 240mm blank aluminium sheet, 1.5mm thick.

You can use wider than 190mm, if the store sells 200mm wide this is also fine. I recommend to have a professional workshop cut the metal sheet to the outer dimensions. The store where you buy it might do this. They have the tools to easily cut it to a straight form. I did it by hand, it doesn’t look perfectly straight. Doesn’t matter for the function, though.

Tools required

• drill (a drill press preferably, as a hand-held drill tends to slide over the metal, so holes might end up not positioned accurately)
• 5.1mm drill for metal (That is the diameter required for the 5mm rivets)
• white paint
• alcohol as solvent to remove grease from the surface and some old cloth
• cable ties
• some means to cut metal sheet (metal shears might do, but working with 1.5mm aluminium sheet is quite hard)
• four 5x10mm rivets
• rivet gun
• centre punch
• hammer
• a small file
• 4 mm drill
• 2 pieces of flat metal to construct the support brackets
• box cutter / stanley knife
• double sided tape (goes between the MP and the reflector)
• optional: coping saw with metal saw blade (makes it easier to work out the 4x10mm holes)
• hose clips (instead of cable ties for the pole mount)

Steps

1. Print the plan on A4 paper and have a copy shop print it on to transparent foil.
2. Use the box cutter to cut the outer shape out of the foil.
3. Fix the foil on the metal sheet. Mark the lines to cut.
4. With the box cutter, cut the 4x10mm holes (for the cable ties) through the foil and into the metal.
5. With the centre punch and the hammer mark the location of the holes.
6. Drill holes and cut where indicated.
7. Work out the 4x10mm holes.
8. Round the outer corners with the file.
9. Removed the cutting ridges with the file.
10. Remove grease from aluminum plate.
11. Spray paint the reflector, leaving plenty of time for the paint to dry.
12. Fix the rear mounting support brackets with the rivets.
13. Apply the double sided tape between the MP and the reflector.
14. Carefully attach the MP to it. Make sure the LEDs match with the holes.

Finished MP with Antenna Reflector

Today was mesh day! Finally we had a few hours free to all get together and do some long distance mesh potato testing. There was a lot going on during the day, and we did some different tests so let me setup things by giving you details of the test environment and what we looked to get out of it.

The test we had in mind was to see how far we can throw decent signals with our stock mesh potato units. We have been playing with them in the confines of a single room for a while now and have them singing and dancing but out in the real world what kind of distances can we get. The ideal way for us to start was to challenge the god’s of wifi and set up our 3 units in a way where they had good spacing apart, and only two units could see each other at a time.

Site A was in Dee Why, being manned by Glen and Dave. This is where we started in the morning to do our testing. Site B was at Long Reef headland, manned by Geoff. Site C was in Collaroy, manned by Carlo. The idea was to get fairly equal spacing between us, but have site B as the man in the middle to mesh Collaroy and Dee Why together. We had 2meter amateur radio handhelds to use for comm’s (with Geoff acting as relay) until we had the mesh up and running for voice.

The setup was the same at each site, a Mesh Potato on a stick of some kind (Squid Poles), Analogue phones for voice and laptops for running network performance testing (iperf / jperf).

Setup

Getting setup wasn’t too painful. All three units are using slightly different methods of power connection which is good for experimentation. The only hiccup was one mesh (the one I was holding onto) had a slightly different firmware to the other units, which may or may not be the reason why it didn’t want to mesh with the other two units. Glen re-flashed my unit with the same software and that resolved the issue. In field use it would be likely that we would all have the same code so no biggie on that one. One thing that we have noticed is flashing the units from a ubuntu virtual machine (with vmware fusion) can throw some funny errors, this time around it didn’t slow us down but it seems a switch in the middle of the equation may see the flashing process work better.)

Glen and Dave had site A up and running very quick. Located at the headland car park it was also one of our most visible sites. The guys got asked a few questions by the locals, some of which jokingly asked if we were installing the NBN. We of course answered yes whilst poorly attempting to hold a deadpan face (We recently found out our suburb’s are not included in the 3 year roll out plan…).

Testing & Results

So the plan was to get the mesh up and running, and once we could ping each other run some tests. Site A and Site B were around 2.1 km apart and connected up. Site B and Site C never connected even after the power was bumped up.

Site A and Site B were able to chat away on the analogue phones with a little crackle and line quality issues. Glen being the resident voice comms guru tried a few different codec’s to see if he could improve the voice quality, but it seems most of the issue was the underlying link quality.

The link speed bounced around a little too. It didn’t like TCP packets much, but could handle UDP packets much nicer.

Between Site A and Site B the maximum throughput was around 1Meg, but as you can see with the first image below it was short lived. The average generally was closer to between 250 – 500 KBit’s. Remember this is over a 2.1KM link with 2 standard mesh potatos with no external antennas etc etc. For the test Site A was connected to the Mesh Potato via Ethernet, but Site B was connected via wifi.

Dave did some other testing, here you can see ping results from his mac to Geoff’s PC. Not a bad response time when both computers where connected to their respective Mesh Potato’s via wifi. Dave’s Mac could also see Site B’s Mesh Potato in its wireless list, but he couldn’t connect to it.

Glen noticed a failure of the link at one stage during the testing, after looking up he quickly established a potential cause. This little guy really wasn’t too interested in giving up his vantage point.

So what did we learn?

That these things are great radios, and we took them to the edge of their performance today. 2.1km out of a little wifi AP is a great result, and we are very happy with the results. The main lessons learned could be summarised as

1. When operating in the field make sure all your units are on the same code.
2. 2.1KM is a great result, but ideally these units would be placed closer together or have external antenna’s to improve gain.
3. Field operation probably takes a little more preparation on the testing we where going to run. Next time we do a prep hour or so indoors in ideal conditions testing the commands we are going to run and how we are going to record the results.

Things to try / improve

1. Run some more controlled area tests to figure out the max throughput of these units.
2. Make a prepared list of commands to run directly from the mesh. (Ie, Horst for wifi noise and wlan connection speeds between mesh units)
3. Same test as last time, but place Site C in the middle of Site A and Site B. That way we can see how the units mesh, and if they choose the faster path correctly.
4. Create a cheat sheet of commands, numbers, IP’s and passwords.
5. Figure out if we can write some scripts to query the units and dump results.
6. Do a debrief immediately after the tests to get it all down.

Lab Results

Glen ran some tests between his two units across his apartment and found that he could move 15mbit of traffic, so the hardware it self is great.

Here you can see the results Glen got when he did some two way tests between two computers connected to individual mesh potatos that had meshed together. As you can see they can get a very decent throughput, this is 15MBits both way with minimal jitter. Obviously they are in the same room but it shows the hardware is capable of nice things.

Anyway it was a great day out, we had a lot of fun and it was great to nerd it up in the sun.

http://nerdpolytechnic.org/2012/04/meshed-potatoes/

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.

After testing different low power solutions based on commodity laptops, we discovered the FitPC¹. The Fitpc2i comes with two Gigabit network interfaces and the CompuLab SBC-FITPC2 series board that uses a fanless Atom Z550 32bits CPU.

In most of the scenarios the VT server will sit behind a village telco super-node and the Internet. Although we have tested commodity laptops using a USB-Ethernet converter as second interface, we have seen very bad performance in the data transfers of some USB dongles (USB 1.1). So if you plan to provide also Internet access from the mesh nodes, consider a solution with two built-in network interfaces.

Installing Ubuntu 10.04 in the fitpc2i² was as easy as installing Ubuntu in any other computer. Use a bootable USB image or attach an external USB-CD Drive. Just make sure that you choose a 32 bits image as the Atom CPU runs 32 bits.

In our laboratory we have tested the Fitpc2i with a Intel(R) Atom(TM) CPU Z550@ 2.00GHz³ and 2 GB of RAM. The unit runs at 35-40 C when idle so make sure that you do not forget it under a pile of books as I did. There are at least two revisions of this hardware but the process of installation should be the same.

CompuLab, the company behind the FiTVT provides support for Linux Mint as the hardware seems to be targeted to those that want to run a nice multimedia station at home (i.e. stream audio/video obtained from good friends to a television). We warned that the unit does not come with VGA output and has a DVI Digital output up to 1920 x 1200 through HDMI connector instead, so you will need a LCD/TV screen with HDMI or DVI input to connect the FitPC.

There are two useful accessories that you can consider, an analog VGA converter is powered from the DVI port and requires no external power source and the external heat-sink.

The main glitch in the installation process is that the stock kernel that ships with Ubuntu 10.04 has buggy R8169 network driver that has broken auto-negotation. In my case, only one of the interfaces was able to negotiate the speed, while the other interface required the ethtool to force the speed to 10 Mbps. Fixing the speed of the second card to 10 Mbps was the only solution so as you can upgrade your kernel.

Once you upgrade the kernel from version 2.6.32-33 to 2.6.32-38 you will discover that the DADHI drivers that are used Asterisk are now broken and you will have to rebuild them. The DADHI drivers depend on kernel version (i.e. wrong symbols). In a nutshell, in order to get the network cards to work you will have to (1) upgrade your kernel and (2) rebuild DADHI Asterisk drivers.

In the second part of this article we will describe how to get the Village Telco software bundle installed.

My interest started with the use of amateur radio for emergency services and disaster relief where I saw the potential benefit of having portable Mesh Potato (MP) systems to augment emergency services team communications. The more I thought about it, it occurred to me that there are many other usage scenarios for such portable telephony networks. Some of those are amateur radio field-day operations, jeep jamborees, motorcycle touring groups… essentially any large groups of people who temporarily camp out together in remote locations. This would also be of interest to what are called “preppers” here in the U.S..people who believe in being prepared for any sort of disaster (whether natural, economic, political, etc). With the advent of the SECN approach, it was apparent that any of the WiFi-enabled smartphones (which are becoming quite ubiquitous) could be quickly configured to be able to call into and take calls from such a network of MPs. The advantage of this approach is that such a network could be built with as little as a single portable MP. Without the inclusion of smartphones, netbooks, or WiFi SIP phones, the Mesh Potato isn’t very useful unless everyone in a group has one.

In amateur radio, many of us put together “go boxes” which are composed of portable transceivers, battery power systems, portable quick-setup antennas, etc. So I started looking at how the MPs could be packaged as “go boxes” and how other people who have a smartphone but don’t have such a “go box”, could participate in the network. The “administrator” for the MP (or network of MPs) could secure the network but provide the WiFi security credentials/passwords to any person with a smartphone, etc they deem as a valid member of the group. Such a usage scenario as described above yields useability requirements that have been somewhat implicit in my emails over the past weeks (months?). A core requirement is at least one MP with DHCP services for the non-MP devices. Generally, an Internet uplink won’t be available but I’d like to allow for a somewhat painless addtition of one (e.g satellite uplink provided by emergency services team). I’ve tried cellular routers but in the US, at least, the cellular providers don’t forward SIP requests (party poopers) so I really don’t see many remote area opportunities for Internet access. That said, I don’t see Internet connectivity as a core requirement anyway. The network’s main function is to provide local telephony with a secondary, optional function of providing access to a portable information server (something else I’m working on).

For the “go box”, I’ve built two prototypes of what I’ll call the Mesh Potato “take-out” (not really). It’s based on a waterproof Pelican 1200 case, includes a quick-release bracket to hold the MP, a rechargeable Li-Ion or Li-Poly battery, a telephone handset, and a junction box to tie everything together and provide an on/off switch and convenient access to the charging ports, telephone jack, and a USB convenience port for charging a smartphone. Between the first proto and second proto, I changed the battery from a Lenmar external laptop battery to a Tekkeon MP3450i instrument battery. I also made a bunch of changes to enhance manufacturability and lower component costs (with the exception of the battery). The third proto I’m about to build (when I’m not busy with my pesky day job) will incorporate a few more tweaks to manufacturability. The unit can be operated with the MP docked in it’s bracket for short-range environment or unlatched and extended into a tree or antenna tower for longer range. The battery can be charged using a solar panel with as little as 10W (using a “solar booster adaper”) but really needs a 20 to 30W panel to be charged effectively and in a timely manner. It can also be charged from a car battery via alligator clips or cigarette lighter jack. It can also be charged from an a AC power brick connected to a generator. I need to do quite a bit of study on the solar charging aspects and also need to look into whether I need to incorporate a low-voltage cutoff to prevent over discharge of the battery.

Keith is a Systems Engineer in Arizona

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.villagetelco.org/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.villagatelco.org. 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