Enabling Communications, Anywhere, Anytime

Software Developer Contracts Available!

2012-02-15T14:24:00.000-08:00

Do you thrive on contributing to something that has the potential to positively impact millions, if not billions of people the world over?

Do you slay pointers in your sleep, dream about data-flow diagrams, or cross-compile kernel drivers for fun?

Can you think in C (or Java)? Do you know how to use mmap() instead of malloc()?

Have you ever written your own compiler, interpretor or network stack for the fun of it (or all three)?

If you can answer yes to at least some of the above, the Serval Project Inc. has the following contract opportunities that it is seeking to engage, so that we are able to accelerate our software development programme:

1. Java/Android/C Software Developer (full-time NOW through to 31 August)

2. Java/Android/C Software Developer (two days per week NOW through to 31 August)

(or possibly some mix-and-match for the total 1.4 full-time-equivalent.)

The purpose of these roles is to get us to our 1.0 public release in August 2012. Future opportunities may develop over time, dependent on successful software outputs.

For both of these roles we are looking for people who can quickly pick up Java and/or C code, and make rapid and sustained contributions to the Serval Project's software base in preparation for major software releases during 2012.

Being a Java/C polymath will definitely work in your favour, as will having some experience with Android software development. General Linux/UNIX admin and scripting awareness and skills are also a plus, as is demonstrated experience contributing to FLOSS software projects.

But most of all, we need people who are passionate about what the Serval Project is doing, and who want to change the world for the better. Prior engagement with the Serval Project is a great way to prove this to us, both for these and any future openings.

These openings are available immediately, are based in Adelaide, Australia (sorry, not negotiable for these openings due to the intensity of software development we have scheduled), and interested parties are strongly encouraged to put together:

1. A CV listing (providing links is great) any FLOSS, C, Java, Android and humanitarian experience;

2. A covering letter; and

3. About 250 words explaining why you think it is vital that the Serval Project succeed.

Then send it all to jobs@servalproject.org. ODT and PDF are our preferred formats.

If we like what we read we will get in touch, and get into more of the nitty-gritty.

If we find more great people that we can offer work to, we will keep you on file for when we next have openings.

Serval has made the Netexplo 2012 Top-100 Most Promising Projects

2012-02-08T02:22:00.000-08:00

We seemed to have reached the point with the Serval Project were we no longer have to enter competitions to start getting short-listed for things. This is almost as amusing as it is humbling.

So it is that today I discovered that we made the Nexexplo top-100 list of the latest and most proming projects.

From their website, this is how they describe Netexplo:

The most promising uses of digital technology

Every year the Netexplo global observatory of digital innovations identifies the latest and most promising projects and experiments on every continent through its international network of more than 200 spotters. This initial material, comprised of several hundred projects, companies and technologies, is then analyzed in greater depth. A college of international experts next selects the 100 most interesting cases, forming the annual Netexplo 100.
Finally, a jury comprised of independent personalities from the academic world, research and international organisations elect the Grand Prix from those 10 award winners. The Grand Prix trophy is announced and given out at the Netexplo Forum.
From new uses of the Web to groundbreaking technologies from research labs, as well as associations, NGOs or businesses that are transforming markets, every aspect of the ongoing digital revolution is covered. That’s why research that is still at the lab stage but has positive potential impact on lifestyles or an application that is already available can generate the same interest. Similarly, the Netexplo 100 lists futuristic applications on the verge of science-fiction alongside original, low-tech innovations using widely available technologies that deliver a socially useful function to a given audience.

So thank you to the Netexplo college for thinking that we are one of the most promising projects and experiments underway in 2012. Now all we have to do is to live up to their expectations!

Developing Challenges of Multi-Hop Mesh Telephony on Android

2012-02-06T02:48:00.000-08:00

If you are reading this blog, you probably know that the Serval Project is all about making mesh telephony practical, so that people can communicate anywhere, any time.

For regular Android software development, it is often practical to use the Android emulator to reduce the time between updating source code and seeing the effect of the change.

For Serval, this isn't really an option, because we work below the Android API layer, and much of the software development challenge is related to making the WiFi chipsets do what we want. We also have a fair amount of native code to do the mesh routing and telephony functions. In fact, we currently have an entire distribution of Asterisk in the Serval Mesh software, which must be decompressed and installed when the Serval Mesh APK is installed or updated.

Together, these contribute to an update process that can take several minutes to between modifying a line of code and seeing it on an Android device, especially on the low-cost devices that are our primary targets, and when using the debug option in eclipse.

Those minutes add up over time, and so I decided to minimise the install time as much as possible, and also address another problem with developing our software, that is detecting when you have an actual multi-hop network.

To reduce the install time, I started looking at the Asterisk installation to see what we could safely throw out. I managed to get rid of about half of the loadable modules, several utilities and all of the speech files that Asterisk comes bundled with. This reduced the size of the APK by a little over 1MB, down to just under 5MB, and cut down the install time by about 15%. Further savings came from removing unused audio codecs in our SIPDroid-derived SIP client, saving another 0.4MB, and getting the whole thing down to less than 4.5MB and installing about 25% faster than previously.

The bulk of the remaining time is about evenly split between installing Asterisk and testing that the WiFi control works properly. For development, it probably makes sense to separate out the Asterisk installation from the other files we need to deploy on installation, as we really don't modify the Asterisk files between builds. This shouldn't be too hard to do, but I have run out of time tonight.

Also, for our target handsets, we really don't need to test the WiFi control every time we update, so we should be able to set a flag to tell the software that we are in development mode, and just assume that the WiFi control works. This now works by checking if a file called /sdcard/serval/developer-mode/fast-wifi exists, and if so, bypassing those tests, and thus saving about 15 seconds.

So over all the minimum time from hitting "run" in Eclipse to getting the software ready has been reduced from 85 seconds down to 48 seconds (without debugging).

The over significant development convenience task I have worked on in the last few days is one that is probably of more general interest. The peer list now shows the number of hops to each of the nodes that your phone knows about, as shown in the image below. This was produced by having two phones at opposite ends of my house, and having the phone shown here with me out on the street.

Each row of the peer list now shows the telephone number, e.g., 5550344, the batman link score, e.g., 243, the ping time to the peer, e.g., 19 milli-seconds, and either "direct" for nodes we can reach directly, or the number of hops to reach the node, e.g., 2 hop.

Importantly for debugging, this displays doesn't ask BATMAN how far to the node in question, but actually enquires of the time-to-live (TTL) field in the IP header, and thus returns the true distance from your phone to the phone in question (the return path might be a different length, though).

Actually, because of limitations with the Java UDP programming interface, the TTL field is read by the Serval DNA daemon (which is written in C), and included in the returned UDP packet to the requesting client.

This means that we can just look at the interface on the screen (and so can all of you who have been asking us for this feature) and see what is happening to routes, instead of having to connect to the phone with a USB cable and enter all sorts of commands to ask BATMAN and the operating system what might be happening.

So all in all we now have a slightly faster and easier development process, that I am sure will more than save the couple of person days of effort that they took to develop, and thus enable us to work faster instead of harder.

At LCA 2012 (Linux Conf AU)

2012-01-19T17:46:00.000-08:00

This year I was not expecting to beheading to Linux Conference Australia (LCA), as two of the ServalProject team were expecting to be there, and I am already looking atthe likelihood of somewhere north of six bouts of internationaltravel this year, on top of a very full itinerary for myself in oursoftware development program, especially in the first half of theyear.

However, circumstances changed justbefore LCA2012 with one of our team unable to travel due to health, andanother being overseas at an IEEE 802.11 meeting as part of oureffort to get the ad-hoc WiFi standard improved. So I found myselfflying in for just over 24 hours to present one of the talks.

The two Serval Project talks this yearwere covering Serval Rhizome, our store-and-forward message and filedistribution system, and the Serval Mapping Service, aninfrastructure-free map and crowd-sourced information gathering andvisualisation platform that is something like a cross between GoogleMaps, Ushahidi and Twitter.

Update: Here are the videos of the talks. The authorships are wrong way around, however:

The talks were well attended and manypeople asked a wide variety of questions. Several themes thatemerged in the question time were that we should think about how wemight interface our work with that of the ham radio community, and ageneral discussion of the Open Street Maps project that we use tosupply the cacheable maps for the Serval Mapping Service. Questionswere also asked about whether we were looking to branch out fromAndroid to other platforms, including low-cost “feature phones”,which are common in the developing world. We have been targeting theSymbian/Belle S60 platform for a long time now. We also explainedhow we intend to seek the manufacture of custom feature and smartphones that contain a pluggable extra radio for mesh communications.

This goal received a substantial boostwhen we discovered that Andrew Tridgell (of SAMBA fame) has alreadywritten frequency-hopping firmware for HopeRF radio modules similar to the ones we are intending to use. This will likely save us months of effort,and also enabled us to learn from Andrew's experience about what therealistic capabilities of the modules are. The firmware and adapterboards that Andrew has created will also make it much easier for usto quantify the transmission range that we can achieve with thesedevices in practise, rather than relying on fairly simplisticlink-budget calculations.

Also from talking with Andrew we havebegun to look more seriously about using small model drone aircraftto loft mesh repeaters (possibly just mesh-enabled Android phones)and have them loiter over an area to provide significant coveragewhere it would otherwise be possible.

The combination of the longer-rangeradios and an established ability to loft mesh devices each have thepotential to greatly increase the utility of our technology in avariety of settings, including disaster response and in both built-upareas and open country where either obstacles or low populationdensity make WiFi meshing difficult.

It was also great to hear about DavidRowe's continuing progress on his open-source codec, called Codec2,which while still alpha, already is able to demonstrate veryacceptable performance at 2500bps and 1400bps, i.e., as low as 175bytes per second for speech of a quality that is more than acceptablefor a phone call, and is substantially better than the now ratheraged GSM codec that requires almost 10x the bandwidth. The challengeis how to make effective use of such a low bit-rate coded, since asDavid pointed out during his talk, the IP, UDP and RTP headers in atypical VoIP application would consume probably 5x more bandwidththan the voice stream itself.

This is a welcome problem we have beenanticipating for some time now, and have some thoughts on how wemight address it. First, once we get our new overlay mesh operating,we will use packet aggregation to defray some of the headers. Second, we will setup pseudo virtual circuits between nodes that willallow the voice to be directed using one-byte channel identifiersthat are local to each node-pair. Third, we can build more efficienttransport structures once we branch out to custom radio interfaces,such as in the ISM915 band building on the work that Andrew Tridgelldescribed earlier in this post.

For example, we could use a one-bytepacket type identifier plus the one-byte channel identifier describedto provide an overall header size of just two bytes. Add to this perhaps 2 more bytes of synchronisation data for the cryptographylayer, and the total overhead is 4 bytes per 40ms, for a total of 100bytes of overhead, and a total data requirement in each direction of275 bytes per second, or just under 2400bps. Allowing for guardbands and the like on the radio interface, we should be able toeasily accommodate a full duplex voice call over a 5kbs – 10kbsradio channel, and multi-hop voice calls over perhaps 20kbs –30kbs*. Such a low bit rate, as I have explained previously, offersthe potential of very long range compared with WiFi, probablyhundreds of metres per hop in built-up urban areas, and perhaps a fewkilo-metres in open country, and even better with an elevatedtransmitter. We do hope to quantify these range figures in somerealistic situations over coming months.

(* Each channel into and out of eachnode requires about 2400bps. In a multi-hop network, we do not wantany two adjacent, two-hop or three-hop neighbours transmitting at thesame, as they will cause interference to each others (theinterference range is typically about double the effectivetransmission range, so one node talking can be heard by its immediateneighbours, and cause interference to it's two-hop neighbours). Also, we have two voice streams, one each way, so we need to schedulethis in an appropriate manner. Let us explore how this might work ifwe have four nodes, A, B, C and D, involved as successive hops in amulti-hop call.

At time 0 transmits to B (A → B), soB must be listening, and C cannot talk, else it would interfere withB's reception of A's transmission. In fact, even D cannot talk, forfear of interfering with B's reception of A's transmission, as B maybe in the interference range of D. Thus in this entire system of fournodes to maximise range we need to have only one of the four nodestalking at any time. As it takes three hops to carry the audio ineach direction, we need six time slices. Some savings can, however,be gained by having B talk to A and C at the same time with adouble-length frame, and similarly C talk to B and D with a doublelength frame, thus saving two guard bands. Thus we need two 2400bpschannels and two 4800bps channels (a total of 14400bps), plus fourguard bands. At 20kps this would leave approximately 25% of air timeavailable, including for use guard bands, or to allow for theoccasional carriage of additional data.

At 30kps fully half of air time wouldbe available, which would also allow for some forward errorcorrection, and a more realistic allowance for additional data,especially if some creative time slicing and signalling is employed.For calls with more than four hops, additional bandwidth is notrequired, as nodes more than three hops from one another havereasonable prognosis (though no guarantee) of not interfering withone another.)

Meanwhile, also at LCA, we have beendemonstrating the ability of the Serval software to share itself viabluetooth and WiFi to other phones, thus simulating deployment in adisaster zone or rural/remote context where internet access is notavailable. While there have been some issues, it has been tremendousto see many people install and try our software. It seems thatpractically everyone at LCA this year is aware of Serval and what weare trying to do.

As part of my talking about the ServalMapping Service, Jeremy and I setup a “scavenger hunt” using theServal Mapping Service to place geotagged pins on the map and ServalRhizome to distribute photographs of the location of each small 2.5cmsquare cardboard token that we hid around the sprawling BallaratUniversity Campus. Similar to geocaching, the tokens were placed soas to be near impossible to find without knowing their location. LCAattendees can use the Mapping and Rhizome software to locate thetokens and return them to Jeremy. Each token is redeemable for twofree coffee vouchers to help encourage participation. Apart from abit of fun, we hope that this will provide us with some real-lifeexperience and feedback on the use of these technologies.

Jeremy also succeeded in setting up anconfiguration-free gateway between Serval Mesh phones and a free SIPto PSTN service that is running at the conference, and left somevoice mail on my cell phone to prove it.

We also had some interesting contactwith several businesses that may be able to make use of ourtechnology.

Much credit must go to Jeremy forgetting the software together, and engaging in many of theconversations that have enabled us to have such a successful time atLCA so far. Also Rob Thomas has been a tireless advocate of Servalat LCA and elsewhere, and together with Jeremy have helped manypeople to install our software on their phones at the conference thisyear.

Thus, while I was not expecting toattend LCA this year, I am very glad that I managed to get there.

Nokia Symbian/Belle Here To Stay

2012-01-02T10:09:00.000-08:00

This is a post I should have made months ago when it would have been a prediction, rather than a commentary. Oh well.

Nokia is in a most fascinating position. Much has been said about the shift to Windows Phone 7 from Symbian, and thus how Symbian is dead.

This was never going to be the case, and the reasons are simple:

1. Most of Nokia's sales are of low-cost phones.
2. Windows Phone 7 can't run on low-cost phones.

And the supplementary reason:

3. Windows Phone 7 relies on a lot of mobile data for a satisfactory experience, which the people who buy low-cost phones in developing countries cannot afford.

It is also worth noting that Symbian phones typically have longer battery life than other smart-phone platforms, which gives them a strong advantage in developing markets where reliable power supply may not be available. This is especially true for the S40 phones, which can browse the web and last a week or more between recharging, whereas I think I am doing well if I can get 2-3 days out of the Android phones I have here, and daily charging is a reality for many.

Symbian is still the most used phone OS for web browsing. In fact, Symbian might even have gained a little bit of (mobile web browsing) market share recently (those stats lump the S40, S60 and S80 platforms together, which is a little confounding, but it still shows a clear overall picture for the overall Symbian family).

All of these reasons (and more) are why, from the outset, it Symbian has been high on the list of mobile operating systems to port Serval's mesh telephony platform to.

It seems that Stephen Elop has now realised the reality of Nokia's continuing need for Symbian: Symbian which was previously being thrown out, has suddenly got a new name, Nokia Belle.

The renaming should be interpreted as a spin-doctored retreat from the abandonment of Symbian: you don't rename a platform you have already killed, you rename a platform you want to do better in future.

Nokia will continue to support Symbian/Belle for some time yet, because it has to.

What is interesting as well, is that getting Serval onto Symbian/Belle and also onto the Nokia S40 platform could make a significant difference for Nokia in protecting the low-cost phone market by providing a compelling market differentiator (everyone loves a free call) for Nokia in that space, where they are under heavy competition from a plethora of cheap Indian and Chinese handsets. Remember, this is the main revenue source for Nokia.

Of course, it has taken Nokia a year to realise that they need to keep Symbian/Belle, so I am not holding my breath for sudden engagement from Nokia --- although we would gladly work with them to get our software onto Symbian, where it can help hundreds of millions of people communicate, and help Nokia's future prospects along the way.

Misleading "Out of Memory" Error in SQLite3

2011-12-19T17:57:00.000-08:00

The following is recorded in the hope that it may save someone else the hassle of tracking down this kind of error.

While working on Serval 0.08 I have been working with SQLite3 for the first time.

I had the following fairly innocent query causing SQLite to report an "out of memory" error:

int count=sqlite_exec_int64("SELECT COUNT(*) FROM FILES WHERE id='%s' AND datavalid<>0;",hash);

After spending a bit of time hunting everywhere to find where I could possibly have leaked enough RAM for SQLite3 to get upset, I finally realised that the column datavalid did not exist in the FILES table. I had meant to update the CREATE TABLE statement, but obviously hadn't gotten around to it.

I updated the CREATE TABLE statement to include a definition for the datavalid column, and the "out of memory" errors are now a thing of the past.

I can only guess that somewhere in SQLite3 when it tries to find the column, it gets a NULL pointer returned, which some other part of itself then interprets as a failure to allocate memory to retrieve the column, rather than the failure of the column itself to exist.

Shopping Serval Style

2011-12-19T13:07:00.000-08:00

We are currently preparing to provide the latest Serval mesh telephony technology for use in a disaster response training exercise with a major relief agency in late February 2012 -- about two months from now. In that time we need to not only get our prototype Field Communications Unit (FCU) kit together, but also finish some software development that is key for making the technology useful for the relief agency. You can watch a demo of one of the features we are working on in the video below, where I send a photo from one phone to another, without infrastructure. This is the same technology we have used to send an SMS more than 10,000km without infrastructure.

On the hardware side, we have ordered 50 Huawei IDEOS X1 phones for AUD$71.10 each -- pretty cheap for a fully featured Android smart phone, complete with digital compass, GPS, accelerometers, a capacitive screen and enough CPU and RAM to meet our needs. These phones are network locked, but that doesn't worry us as we won't ever be putting a SIM card in them, because they will be used solely as mesh communications devices.

It turns out that buying 50 phones at a time is an interesting exercise. People want to know that you are not planning to resell them or export them. Some shops will even try to limit you to buying five or less at a time. Those tactics are legal in some places, but not here in sunny South Australia, where we have an excellent Fair Trading Act that correctly classifies such terms of trade as discriminatory, or in some cases as tantamount to bait-and-switch.

In fact, until quite recently the South Australian consumer protection and gambling laws were so strong that cereal-packet competitions could not require a South Australian resident to purchase a product to participate in a trade promotion lottery, because it would be considered gambling, i.e., pay for chance to win. So when I was growing up it was quite common to see terms and conditions looking quite normal, and then have sections specially for South Australians, that would often say something along the lines of:

"10. To enter, cut the bar code from a packet of XYZ and include it in your entry as proof-of-purchase. Residents of South Australia are permitted to submit a hand drawn facsimile of the proof-of-purchase.

...

17. Only one entry per household per day. Residents of South Australia may enter more than once per day."

There were certainly occasions in my childhood when we would go to the effort of getting the coloured pencils out to draw a barcode by hand to get the chance to win a prize. I think we sometimes did it just because we could. Sadly, with the introduction of poker machines (Australia has fully 21% of the worlds poker or slot machines --- a statistic that is disturbing given that Australia has only about 1% of the developed-world population) and the general liberalisation of gambling in South Australia the situation has changed, and I believe we have lost our little parochialism.

Anyway, I digress.

After the difficulties I encountered initially in sourcing 50 mobile phones, I eventually went to our local post office to see if they would order me 50, since they had the model I wanted in their catalog. Not only were they willing to order them (I promised to pay up-front, since it was a large purchase), they also kindly sliced 10% off the price. So I now have a box of 44 phones in my lounge room, with the remaining 6 on back order:

At this price, the phones don't come with SD cards, which we do need for the Serval Rhizome software to do anything useful, as store-and-forward requires somewhere to store! So I hunted around, and after some luke-warm experiences with suppliers either being unwilling to give me a decent price for what is clearly a wholesale quantity, or failing to stock enough, I tried OfficeWorks. They had enough in stock, but were charging $16 for 4GB cards, which I had quotes from other local stores for $7. So I loaded my basket with 50 memory cards, and proceeded to try their price-matching policy:

However, the large price difference and quantity did trigger concern from their store manager. He was very friendly and amiable, but did point out that to get the price matched, I had to find a local supplier with the quantity I wanted actually in stock. But that wasn't easy to arrange, as most of the cheaper suppliers only had a few on hand. There is of course a silliness in their rule, as I could have bought them in small batches such that each batch was small enough that the cheaper shop held sufficient stock. But in the end I did manage to find a cheap supplier on eBay who had plenty in stock at $5.80 a piece for SANDisk 4GB class 4 microSD memory cards. Now we just have to see if they will arrive.

So that covered the phones and memory cards. The next challenge was to come up with a way to easily charge 50 phones. Not only did it need to work in my home, but it also had to have the potential to work in a real disaster zone, and one which might not be in Australia. Having enough power boards to plug 50 little USB charger bricks was not an attractive option, especially since I need to fit all of this into my 23kg luggage limit when I fly, and 50 phones alone are not that light.

What I have decided to do is to chop up a pile of USB leads and wire them up to some automotive 5v accessory power supplies that are commonly used to power portable DVD players and the like. Apart from being the cheapest 5v high-current power supplies I could find (AUD$40 for 5A), they have the benefit of running on 12v, or in the case of some models, on 12v-24v, so that they can even work in a truck. This means that in-vehicle mass-charging is possible when the power grid is off. It also means that they can all be charged using a single cheap 13.8v power supply, which are also quite cheap; you could even use an old computer power-supply. You can see my prototype here:

So now I just need to get back to writing the software that needs to go on these phones ...

Serval Developer Release 0.07, and our Roadmap for 2012

2011-12-15T13:07:00.001-08:00

It has been some time since our last developer release, and so it is with great pleasure that I am able to announce that Serval BatPhone Developer Release 0.07 is now available for download from the Android Market.

This version offers compatibility with many more models of Android handsets, fixes to a large number of bugs, and some general usability improvements. Full functionality still requires root permissions on your phone, but it does its' best to work on phones without root access.

Personally, what I am most happy about is that we have substantially improved our software development and release process, which has already resulted in a much better quality in the current release, and I am confident will result in increasing quality in future releases.

In the longer-term this is the first of several planned releases that will hopefully bring us to a 1.00 public release around September 2012. The planned intervening releases and their headline improvements, subject to resourcing, slippages and all the other usual hazards of software development are:

0.08 - Serval Rhizome/MeshMS store-and-forward file distribution core technology. Automatic update of Serval software over the mesh.

0.09 - Revamped and consolidated MeshMS API and functionality. Integrated UI for sending and receiving MeshMS messages, including using the Rhizome store-and-forward facility.The underlying technology has already been demonstrated by sending an SMS between Africa and Australia without reliance on infrastructure.

0.10 - Revamped UI for entire Serval Mesh application. Voicemail and Push-to-talk group communications.

0.11 - Serval Mapping Integrated (using Rhizome to get map tiles without internet access). Voice calls moving from SIP+RTP via SipDroid and Asterisk to Serval MSIP and MDP, which will improve performance on lossy wireless networks, allowing clear calls over multi-hop links each with 50% packet loss, and greatly reducing the APK size by removing the full Asterisk deployment it currently contains.

0.12 - Consolidate existing work, and address outstanding issues for first public release. 0.12 will become 1.00RC1 when accepted.

Together, these releases will culminate in a software package that will let you do most mobile-phone type things (voice calls, SMS/MMS, voice mail, push-to-talk) when there is no infrastructure, or for free when infrastructure is available, such as transferring and sharing data among friends and community without having to pay up to $2/MB for SMS traffic or $2/MB for cellular data services.

This is good news for people with very low purchasing power, such as large portions of the population in developing countries as well as for those living in more developed countries such as Australia, where infrastructure is not universally present, especially for those living in rural and remote areas.

But for now, it is back to working on Serval Mesh release 0.08 ...

Shuttleworth Foundation Intro Video

2011-12-01T09:56:00.001-08:00

As many readers will know, my work on the Serval Project is substantially funded by the Shuttleworth Foundation. They provide my income, thus freeing my time, co-investment in the project, and loads of support in a variety of ways, including a great team of other fellows and support staff.

Without their support the Serval Project wouldn't be what it is.

The foundation are always on the look out for other people with world changing ideas, and have released a new explanatory video that describes how their fellowship model works.

So if you have an idea that might change the world given half a chance, then I would recommend getting in touch with them, and possibly applying for a fellowship.

TEDx Adelaide Talk Is Now On Youtube

2011-11-23T22:52:00.000-08:00

As I mentioned in a previous post, I recently presented at TEDx Adelaide, which had the theme "On The Edge". They have now put the videos up on YouTube, so here it is:

The bottom line?

Just as MP3 files and digital music distribution has changed the market place for the recording industry, so to decentralised digital mobile communications is on the verge of similarly disrupting the mobile telecommunications industry, by similarly adding value to the everyday experience of many people.

The question is, will the mobile carriers see the opportunities that change brings, or will they work against their own interests by failing to embrace the change?

Only time will tell.

Demonstrating the Serval Rhizome Store-and-Forward MeshMS SMS Service

2011-11-22T04:53:00.000-08:00

SMS messages on a cellular network get delivered via the cell towers and message centre infrastructure.

On a mesh, it is possible for us to deliver messages to other phones that are reachable on the mesh at the same time. This works great, and we have had this capability in the Serval BatPhone software for a while now.

However, it does have some limitations, in particular, if there is no link all the way from the sender to the receiver on the mesh at the instant the message is sent. This is rather unfortunate, as we usually think of SMS as being the most reliable fall-back on a mobile communications network.

So we set about replicating this resilience by creating a store-and-forward SMS-like service on top of the Serval Rhizome mesh file distribution framework. We call this MeshMS, for Mesh Message Service.

This service uses direct mesh links if they are available by making use of the existing SMS capability in the Serval BatPhone software. However, if there is no direct link, then it uses a store-and-forward scheme, that asks any passing phones to copy the message and distribute it to other phones on the mesh, until it (hopefully) eventually reaches its intended destination. The cartoon below shows how this works.

The man wishes to send the message "Prepare the Zeppelin" to his hench-person, but there is no direct mesh link at that time due to the challenging topology. The message gets picked up (stored) by the compatible phone in the pram, without any action on the part of the woman. The woman then keeps walking along, and eventually the phone in the pram is able to automatically deliver (forward) the message to the ultimate destination, whereupon the minion knows to ready his master's zeppelin, to do the weekly grocery shopping, one trusts. Of course, there could be many intermediate steps, instead of just the one shown here.

The great thing about this approach is that it doesn't require a complete path to the destination at the time of sending, but can propagate progressively across the mesh as it is able, and can make use of nodes that move between otherwise isolated mesh networks, creating an asynchronous link between them where it would not otherwise be possible.

While the delay in such a service is huge, the bandwidth is also great, as potentially gigabytes of data can be transferred between nodes. One side use of this protocol that we intend to exploit is to provide an efficient means of distributing updates to the Serval software suite, so that field updates can occur without dependence on infrastructure, and with much greater aggregate bandwidth than any single-cast cellular or wireless approach. In fact, this will even allow the update of software, maps and other resources during a disaster.

We have even demonstrated it to deliver an SMS message between South Africa and Australia, using nothing but compatible phones to carry the message more than 10,000km:

This feature has profound utility in allowing the exchange of messages, files, and all manner of data in what are otherwise very difficult settings.

It also provides the capabilities required to enable disadvantaged communities, perhaps in remote locations, war zones or informal settlements, to create their own infrastructure, carrier and cost-free SMS networks using compatible handsets, so that they can enjoy the benefits of digital communications that many of us take for granted.

Building The Serval BatPhone Software

2011-11-21T17:04:00.000-08:00

We have been putting some significant effort into making the Serval BatPhone software easier to build from scratch, especially first time around.

The procedure for Mac/Linux has now been reduced to (assuming you want the wifi-autodetect branch, which for now you probably do):

1. git clone git://github.com/servalproject/batphone.git -b wifi-autodetect
2. cd batphone
3. ./BUILD.txt

After that, you should be able to compile the software from in Eclipse without difficulty, as all the messy stuff has been taken care of (git sub-modules, JNI/NDK compilation, NaCl preparation, among others).

This easy build process will be pushed up to the master branch fairly soon, but for now, it is only available with the wifi-autodetect branch.

Note that building on Windows remains unsupported, as end of line markers in files get messed up if great care is not taken. If you want to build on Windows, we recommend you install a Linux virtual machine, e.g., using the free VirtualBox software, and run the build process from in there.

A Serval Project Progress Report

2011-11-20T22:57:00.000-08:00

It is time to reflect on the past six months of Serval, and where we intend to head in the next six months.

Six months ago we did not have a developer software offering, or even a single Android application that contained all the components for Serval. Today we do.

On-site in South Africa after testing the Serval MeshMS store-and-forward SMS Service, delivering files and SMS messages up to 11,000km without infrastructure, or a continuously connected mesh.

Six months ago we did not have MeshMS (Mesh SMS service), interactive mapping, Rhizome file distribution or store-and-forward SMS working. Today, we do, and have even sent photos and SMS messages more then 10,000km between Australia and South Africa using mobile phones as the only infrastructure (more on this in a blog post and video in the next few days). See this blog entry for an infographic and video showing the sending and receiving of this first inter-continental mesh SMS message.

Demonstration of the Serval Rhizome Mesh-Based Infrastructure-Free File Distribution System, which is also the basis of the store-and-forward MeshMS/SMS service.

Six months ago we had a number of legal issues to work through with regard to giving Flinders University an appropriate holding in the Serval Project's commercial arm, and the Shuttleworth Foundation had not yet come on board. Today, we have just about finalised the details for these arrangements, with the final execution to occur in the coming weeks. It will be fantastic to get this settled.

TEDxAdelaide Presentation November 2011. (Video coming soon) “The democratisation of online music is one example where the internet has eroded the monopoly power of music labels returning some portion of that power to the general public, without bankrupting those enterprises.” Paul will explore what is essentially a Napster equivalent that will compete with the mobile telecommunication giants. He believes that the advent of powerful, programmable, portable digital devices (e.g. smartphones) are a key factor in this eventual democratisation of mobile telecommunications.

Six months ago we were not greatly recognised internationally for our work on mesh communications. Today, we are increasingly recognised as the leaders internationally in this space, which is a tremendous honour and also acts to spur us along to deliver on all the potential that mesh networking offers. Recognition has included support by the Shuttleworth Foundation (South Africa), reaching the finals of the World Embedded Software Competition for University students (South Korea), strong engagement by and with the IEEE 802.11 standards process (USA and international), presenting at the Adelaide Festival of Ideas and TEDx Adelaide (Australia), and also reaching the finals of the Ashoka Foundation World Changer's Citizen Media competition (international) from a field of more than 400 entrants. We are also seeing university and other partnership opportunities in Australia, Europe, the Middle East, Africa, the Americas, and Asia begin to take shape. Now all we need is to be able to clone ourselves a few times over so that we can engage fully with the various opportunities!

Our plans for the next six months are to fill out the feature set that we have generated (voice, SMS, MMS, interactive mapping, file and software distribution), and add in the missing pieces, primarily the security and authenticity components that we have planned from the outset. This will take us to mid-2012 when we hope to focus on maturing all of this into a general public release, as compared to the early-access developer software we have released to date.

Adelaide Festival of Ideas, 2011, JIM BETTISON ORATION: KICKING THE INFRASTRUCTURE HABIT: [listen to MP3] "Modern communications systems use extensive and expensive infrastructure to deliver services we could only dream of a few decades ago. This works for those who enjoy peace and sufficient wealth, but fails to reach the last billion people in poorer countries, as well as those in remote, emergency or disaster situations. Now modern mobile phones have the potential to communicate directly, to form networks without reliance on any infrastructure. The Serval Project based at Flinders University is turning this dream into a reality. It is working to make communications available to everyone, anywhere, any time especially to those who need it most."

We are also looking seriously about getting advanced mesh support built into one or more models of mobile phone to offer energy efficiency and/or range improvements over the basic service.

Simultaneously, we are beginning to explore appropriate trials of the technology that if they go ahead will gain us valuable feedback, and refine the software to maximise it's utility for the general community, including in South Africa (assisting in the distribution of educational material without cost or dependence on cellular or school IT infrastructure), North America and Australia.

So all in all, the next six months should keep us fairly busy.

Serval is in finals for the Ashoka Foundation Change Makers Citizen Media Competition!

2011-11-09T14:41:00.000-08:00

It seems that this last month has been one of the Serval Project gaining international recognition as leading the mesh communications space. First some thoughts on that, and then some of the exciting things that have been happening.

This is incredibly gratifying and humbling, and I think also says something about the value of the open development and free software model, and also about the value of pragmatism and choosing the right applications and approach. Ultimately it must spur us onto continuing to advance not only the technology, but also its use.

We are quite aware that there are other more experienced players in this space, who have in some cases invested many millions of dollars into mesh networking. However, the closed-handed commercial approach that many such group have taken means that many innovations in the mesh networking space do not get well known, and that people feel isolated from what is happening in this space -- which is quite counterproductive, since mesh is by it's nature a word-of-mouth and peer-to-peer technology, and that character bleeds over into how it is best used, valued, evangelised and adopted.

We are also quite aware that there have been significant efforts put into making robust mesh routing protocols and standards, for example 802.11s, and yet in a short space of time we seem to be accelerating our traction at a much faster rate. I think that there are a few interrelated causes for this. First, we are extremely pragmatic in our approach, and this is partly enabled by us driving a vision forward, rather than seeking consensus to generate a moderated output.

The unfortunate reality for mesh networking is that it is still in such infancy that the various components have to be well matched to perform well, and thus the traditional compromise approach to standards generation, without an working example to inform the standard, is prone to produce a sub-optimal result, and take a very long time to produce.

This is also related to the lack of clear commercial application (or more specifically, of commercial return) of mesh networking in the eyes of many companies. This is because when viewed as a traditional network, mesh networks are very poor cousins; they have poor reliability, poor bandwidth, poor quality of service, limited range and so on. All these make it very difficult to layer existing commercial models over a mesh network. For example, adapting Google's advertising model onto a mesh network has trouble getting the advertisements over the mesh to each device, let alone the search data.

It takes a fresh approach to mesh networking to understand where the substantial commercial opportunities are hiding. This requires gaining an understanding of the strengths of mesh networks, rather than their weaknesses. The natural broadcast nature of wireless networks actually works well for broad dissemination of data. The ability of these networks to operate without supporting infrastructure allows the provision of services when not ordinarily possible.

These services do not need to be data-poor services, either. Serval has already created a prototype mapping application that could easily support navigation, geotagged advertising by businesses, crowd sourcing of points of interest and a variety of other features -- and would continue to be available when infrastructure is not available.

In this kind of setting, the limitations of mesh networking become strengths. The limited range of mesh networks means that locally relevant data is available where it is relevant, and doesn't flood the rest of the world or distant parts of the mesh. The broadcast nature of wireless communications allows multiple receivers to receive these locally relevant data, whether it be advertisements, maps, communications between nearby friends or otherwise. Also, by focussing on hop-by-hop dissemination of data, the traditional bandwidth degradation of mesh networks can be significantly avoided -- at the extreme it is single-hop communications which can be performed at the order of 100mbit between nearby WiFi enabled devices, which is way faster than my home ADSL internet connection.

But back to some of the recent successes we have had in our work and leadership being recognised, including the headline of this post:

The Serval Project is one of 11 finalists from a field of around 500 entries in the Ashoka Foundation's Change Maker Citizen Media competition. This is tremendous recognition of the value of our work in the citizen empowerment space, and we are delighted to engage with this community, and with the other amazing finalists. We'd also love you to vote for us if you think we should be one of the winners. You can see the other finalists and vote using the links below:

We have also made it to the finals of the World Embedded Software Competition in Korea, for the second year running.

Meanwhile, we have begun to engage with the IEEE 802.11 standards process, with Romana in Atlanta at their meeting as I type. It continues to amaze me the generally positive reception and voice that we are granted at events such as this, and we are hopeful that we can effect positive change in the standards to better support mesh networking.

We are also beginning to form partnerships with Universities, companies, not-for-profit and other entities, not just in Australia, but around the world. More on some of those as they mature, but it is exciting for me to see our efforts multiplied as we gain partners. As I have previously mentioned, we are keen to not only create resilient software, but produce it in a resilient manner, and that means with multiple teams in multiple countries around the world. While this process has begun, we would love to expand this even further, so if you are interested, drop me a line.

Closer to home, but from my perspective very satisfying is that two of our students won their sections of the departmental end of term student expo. Congratulations to both Swapna Palaniswamy and Corey Wallis for your great work. Swapna's work has also resulted in an upcoming publication at the International Conference on Wireless Technology for Humanitarian Relief later this year, which is an unusual achievement for a student in her course. Corey has similarly had a presentation based on his work accepted at Linux Conference Australia in January (we also have another talk at LCA on our Rhizome mesh file distribution protocol).

So it is a tremendously exciting time, and we are incredibly grateful to the Shuttleworth Foundation, Flinders University, NLnet and the Awesome Foundation for their enabling support of our activities.

So now it is back to driving the technology side of our activities so that we can deliver on the promise.

We have two primary areas of activity on this front at present. First, we are working to consolidate the existing software to make it generally more usable and stable. Second, we are working on incorporating the Rhizome file and messaging system so that we can provide what we think will be a very powerful mesh messaging service, that will even make possible the delivery of messages when there is no path immediately available through the mesh, and for the sender to receive confirmation when the message has been received. But more on that when we have something concrete to show.

A Simple Illustration of A Multi-Hop Telephone Call

2011-11-08T19:01:00.000-08:00

From time to time I get asked to provide a simple explanation of what the Serval Project actually does.

It allows you to make multi-hop phone calls using only phones, with the signal bouncing from phone to phone

What does a multi-hop mobile mesh telephone call look like?

Well, it can look a bit like this:

Of course this photo is a bit staged, and in reality the people in the middle of the call don't have to have their phones out, or do anything -- the mesh routing software automatically works out how to get the call between the parties.

The only limitation is that their be a path between the calling parties.

Also, the phones can be quite a bit further apart than shown here, around 100 - 200m with line of sight at present, and potentially kilometres apart once we get the ISM915 band meshing happening in the future.

In a future post I will explain how we can enable SMS type services, even when there isn't a reliable path.

Early Prototype of the Serval Mesh File Distribution System, the Rhizome Retriever

2011-10-25T07:05:00.000-07:00

Romain one of our team has been working hard to get the Rhizome Retriever together as part of our work in supporting citizen journalism in a community in Nigeria, that I have blogged about previously.

They are already using our software in that community to make free mesh telephone calls, but from the outset the plan has been to enable them to be citizen journalists, and to share news and information in their community.

To enable this, we are making our Rhizome Retriever (Serval RR), which basically lets you pick files on your phone, and put them up on the mesh, from where they will be automatically distributed to other phones on the mesh.

Mass file distribution on a mesh is usually fraught with difficulties, not the least of which is that the available bandwidth on a mesh halves (or worse) for each extra hop that you try to traverse.

So you can often get decent bandwidth to nearby nodes, but poor or intermittent connection to more distant nodes.

Also, the more people trying to transfer things many hops across the network reduces the available bandwidth for everyone.

So we decided to make the Serval RR only ever send data one hop to the nearest neighbours. They can then in turn send data to their neighbours later on at their convenience.

As a result, Serval RR can already distribute even relatively large files, certainly into the several mega-byte range, without great difficulty, and without making the network unusable for everyone else.

Here is a quick demo of the initial prototype of the Serval RR software in action:

The importance of communications during emergencies

2011-10-23T20:52:00.000-07:00

Early 2011 saw the worst floods in Queensland, Australia in 40 years.

Not surprisingly, this placed significant stresses on response efforts, and for a variety of reasons, the Queensland Government has issued an interim report on the event and what responses should be made.

You can read the interim report here.

I have been reading through this from a telecommunications perspective, and found the following items:

2.24 Seqwater should give consideration to posting information about current and future releases on its website during flood events as one method of ensuring accurate and timely information is available to the public.

This may seem like a small matter, but by making the information available somewhere where someone in the community could access it, and possibly disseminate it further, perhaps by word of mouth, or perhaps by feeding it into a crowd-source incident reporting system such as Ushahidi or the Serval Rhizome/Mapping combination, where it could be made available to others who need it. Indeed, this process could be automated, providing a very valuable community service. However, if the information is not shared in the first instance, then such broad and means of distribution will be troublesome to implement, and potentially disadvantage many.

In short, putting information out where the public can get to it, and make further use of it supports resilience.

5.21 The Queensland Fire and Rescue Service should ensure that rescue technicians on deployment are provided with individual radios, rather than sharing a communications pack

Presumably the sharing of communications packs is related to their cost and bulk.
Using off-the-shelf meshing mobile phones would allow all rescue technicians to have a personal means of communications that makes use of the shared communications pack, relaying traffic back through that resource.

5.29 The Queensland Fire and Rescue Service should consider isolating repeaters during a large scale emergency response. If this solution is found to be feasible, it should be implemented as protocol as soon as possible. If it is not, the Queensland Fire and Rescue Service should explore other solutions to the issue of the fire communications network being overloaded and firefighters resorting to localised networks during large scale emergency response situation.

This seems to be responding to the issue of excessive traffic being relayed across the region, congesting the system and preventing it being of effective use. The Serval Mesh system has the potential to localise message delivery to the local teams that need it (whether or not they are locally based), and still retaining the ability to broadcast messages over the whole region when suitably addressed.

This is not a particular mode we had considered greatly in the past, so this is a helpful thing for us to discover.

7.2 Lockyer Valley Regional Council should investigate the feasibility of installing alarm-activating gauges in the creeks at Spring Bluff, Murphys Creek and other communities where communication systems are poor and there is a risk of rapid and unexpected water rise.

This is interesting for us to read, as we are already contemplating creating a very similar system for use in the Mekong River Basin on conjunction with a Lao doctoral student here in the department. The characteristics of the system are having a local mesh broadcast an alarm to all mesh nodes when one or more mesh-equipped sensors indicates a high water level.

It is possible that those sensors could be low-cost mobile telephones connected to a device such as the IOIO, creating a very simple and low-cost solution, provided the device can be powered, perhaps using a solar panel and modest storage battery, such as an old car battery no longer able to supply the peak load required to start a car, but more than sufficient for the couple of watts required to run a phone and sensor.

"SMS alerts are also not a reliable method of providing flood warnings in parts of Queensland which experience problems with telephone coverage. That difficulty is compounded during a flood, when telephone reception can be affected by flood related power outages and congested telecommunications networks."

This is precisely the kind of short coming with cellular networks that Serval has sought to find and create solutions for, that complement the existing infrastructure. In particular, the ability of the Serval Rhizome mesh file/message distribution system to work asynchronously, and automatically share information carried in phones as they more from region to region has particular value in these sorts of situations.

Also, the ability place local calls on the mesh, and where possible, setup connections from the mesh to the outside world offers a significant capability that is otherwise a considerable liability in these situations.

The ability for Serval technology to allow the rapid setup of a local mobile telephone network, and then connect it to the global telecommunications network using the nearest functional mobile phone tower was demonstrated in Brisbane in late January 2011, just a couple of weeks after the flooding had subsided.

We did this by placing a phone running the Serval software at a high vantage point where it could communicate with the nearest functional mobile phone tower (we used a helium balloon, but a roof top, or even a long fishing pole gaffer taped to a car would suffice). This then allowed the phones on the ground that were also running our software to relay calls out to the world. Here is the video we took of us doing exactly this, and watching people use it:

Serval is going to Atlanta

2011-10-22T19:29:00.000-07:00

Well, Romana (co-founder of Serval Project) is. And that is because she will be representing the Serval Project's interests at the IEEE 802 plenary meeting there in just a couple of weeks (November 2011).

Romana will be putting forward use cases that reveal deficiencies in the current 802.11 family of WiFi standards for mesh and ad-hoc communications.

If all goes well, we may have the opportunity to input into a process of looking to address these issues, which is tremendously exciting for us.

It could mean much longer range mesh hops using ordinary mobile phones, by using the cellular radio to implement some kind of WiFi in the ISM 915MHz band.

It could also spell the end of frustrating incompatibilities in the 802.11 ad-hoc WiFi standard, including the bizarre lack of specification of ad-hoc in 802.11n, preventing standards conforming devices from using the higher speeds and other benefits that 802.11n brings.

Either or both of these have the potential to make citizen generated infrastructure-free communications systems mainstream, thus our excitement.

So Atlanta will be the official first turning of clod in a process that could extend up to four years, and represents a huge personal investment on the part of Romana, as well as a substantial financial investment on the part of the Serval Project, and thus the Shuttleworth Foundation whose support makes this possible.

We would invite any other open efforts that have concerns with aspects or omissions of the IEEE 802.11 WiFi standards to get in touch with us, so that we can do our best to represent the needs of more than just ourselves.

Oh the fun of the Android linker

2011-10-18T06:33:00.000-07:00

So this week I decided that I would finally do the initial integration of the excellent NaCl crypto library into DNA, but with the view of making it available from Android so that it can be used as part of our forthcoming Rhizome browser (this is for browsing Rhizome offerings, not the web -- more on this thing in a future post).

My main objective was to have only one copy of the NaCl library in our Android application so that the APK stays as small as possible, and so that we don't waste any more memory than we need to.

The first challenge is that we want to access NaCl from Java, as well as the command-line dna utility.

The second challenge is that the crypto code should be inseperable from the dna code, so that it is impossible, for example, to use linker tricks to switch the NaCl library for something insecure.

We can't do this perfectly because it needs to be accessible from Java, which can only load native shared libraries, but it seems that we should do what we can.

So I put all of dna and NaCl into a single shared library, libdnalib.so, using the Android NDK to build it, so that we can load it into Java and use the NaCl (and possibly dna) functions directly from in Java.
This even means that dna's main() function is in there, and so we can run dna queries and actions from in Java as though we were using the command line tool.

Great.

Then I tried a bit of good old fashion linker skullduggery, by making an empty C file, and compiling it linked against libdnalib.so, so that it gets dna's main() from that library, by doing (in effect):

echo >null.c
gcc -o dna null.c -ldnalib

However, the linker on Android doesn't look in the host applications lib directory when linking an executable. The Android linker also doesn't support the -Wl,-rpath= option for specifying where to find a library.

This is a real pain, and probably qualifies as a bug. I should probably file the bug, but I wanted an immediate solution, since my past attempts at getting the Android folks to fix things have not met with much success. Besides, I needed a solution that works with existing handsets, not future ones. So in the words of Marvin the Martian, it was back to the old drawing board.

So my solution was to create a wrapper that just dlopen()'s libdnalib.so, and then finds and runs the main() function from in there:

#include <dlfcn.h>
#include <stdio.h>

int main(int argc,char **argv)
{
void *h = dlopen("/data/data/org.servalproject/lib/libdnalib.so",RTLD_LAZY);
int (*dnamain)(int,char **) = dlsym(h,"main");
if (!dnamain) return fprintf(stderr,"Could not load libdnalib.so\n");
return (*dnamain)(argc,argv);

}

The downside is that it assumes that /data/data/org.servalproject is where the application will get installed, which the Android people tell us we should not assume.

Thus I will probably be about as popular with them as I am when I tell people to root their phones to get ad-hoc mode WiFi instead of waiting for an API to turn up in some future release of Android.

But, when necessity beckons, one must do what one must do.

And so I now have a solution that works and I can move onto more pressing problems.

Deploying a Phone Tower, Serval Style (The Day In Pictures)

2011-10-13T04:44:00.000-07:00

So yesterday we went to beautiful Normanville with the goal of testing the maximum range between phones running our mesh telephony software.

We didn't get particularly far on that front, but we did discover some very interesting things about the unique requirements of mesh routing between mobile telephones, which will likely be the subject of a upcoming blog post.

But what we did do was deploy a mobile phone tower of a different kind. Romana has wanted to make her wheel chair into a mobile phone tower for some time, and yesterday was her chance, as the pictures show.

Romana in her chair with Lyn beginning to attach the 7 metre long squid pole we use as the mast.

Further attaching of the mast.

Beginning to raise the mast. The blob on the top is a Huawei IDEOS U8150 mobile phone running our software and acting as the "repeater".

The raising of the mast:

Victory! Romana's wheel chair is now a mobile phone tower.

But it wasn't all hard work. The weather was glorious, and the views most excellent, and others were out and about enjoying the day ...

Or hoping for a chip.

Meanwhile, we moved to the jetty so that we could place our mobile phone tower (including blanket for the cool sea breeze).

The pole really does stand up quite high. It gets the phone about 6m above the deck of the jetty:

... which is a little higher than even the lamp post

Then we started walking along the beach towards Carrickallinga, slowly deploying a 6-hop mesh, and making multiple simultaneous voice calls amongst the nodes.

Corey and Romana did a great job standing on the jetty and talking to us via our impromptu phone network, while locals and visitors enjoyed the day:

This was also the first time that my son Caleb came along on a Serval expedition. Little did he know that his pram was soon to become a phone tower as well.

Here I am with Lyn deploying a node some distance from the jetty:

Then it was Jeremy's turn:

Then the pram:

And all the while we were able to make calls among the various nodes.

We did encounter some serious mesh routing issues, which as I mentioned I will talk about soon, but for now I just wanted to let you all enjoy the pictures.

Kicking The Infrastructure Habit

2011-10-12T14:11:00.000-07:00

Last weekend I delivered the inaugural Jim Bettison Memorial Oration at the biannual Adelaide Festival of Ideas. This was a great honour, and my presentation was well received by the audience, as was evidenced by the poignancy of their questions.

Here is the abstract of my oration:

Modern communications systems use extensive and expensive infrastructure to deliver services we could only dream of a few decades ago. This works for those who enjoy peace and sufficient wealth, but fails to reach the last billion people in poorer countries, as well as those in remote, emergency or disaster situations. Now modern mobile phones have the potential to communicate directly, to form networks without reliance on any infrastructure. The Serval Project based at Flinders University is turning this dream into a reality. It is working to make communications available to everyone, anywhere, any time especially to those who need it most.

You can listen to the oration by downloading the MP3 from the Radio Adelaide website.

You can also listen to an ABC Bush Telegraph interview about the oration that I recorded a few days prior to the oration.

Photos and Update from Nigeria - and introduction to Rhizome

2011-10-05T16:32:00.000-07:00

We have a partner organisation working in Nigeria looking at citizen-sourced journalism and using our mesh network as the connectivity among a number of camera-equipped cell phones, so that citizen journalists there can make a short video or news piece and then have it distribute automatically over the mesh using our Rhizome protocol.

Rhizome is our mesh file distribution protocol that allows user-created content and software updates to spread hop-by-hop over the mesh. This hop-by-hop approach elegantly solves many of the problems with mesh-wide file transfer, in particular bandwidth starvation and instability of long links.

We have called it rhizome because it is like the vegetable reproductive process of the same name, because we think it is a good analogy for the way that Rhizome allows data to spread by small hops, but such that over time it can spread over great distances.

We are busy working on making Rhizome do all that the team in Nigeria needs, but in the meantime, the team in Nigeria have sent us some photos showing the mesh in action.

First, they sent photographic evidence of 10 IDEOS U8150 phones forming a mesh with our software:

10 Serval BatPhones on the mesh (and a call in progress!)

They also sent us this picture which I really love, because it shows a community getting started with out technology thousands of kilometres from where we are writing the software here in Australia. This is what it is all about, people using and benefiting from the software that we are creating and releasing.

Finally, just a week after they got 10 phones on the mesh, they sent this shot showing 15 phones on the mesh. This was just a case of them getting 15 phones within range, as the underlying BATMAN mesh protocol should be able to handle a couple of hundred devices without any difficulty:

One of the challenges we are looking at solving with this group is auto-update of the mesh software, over the mesh. That is, we want to be able to load a signed software update onto any one of the phones on the mesh, and have the phones on the mesh share it automatically with one another.

This is a great idea, and the Rhizome protocol will allow us to do this, however it introduces some security challenges.

In particular, we don't want someone or some party seizing or cracking our signing key, and then being able to spread a trojan update that destroys the Serval mesh.

One approach we are looking at is making the update require that the new version be signed by a majority of keys from a pool, where each key would be held by a different mesh-friendly organisation. The pool of trusted keys could then be similarly updated by a majority vote of existing trusted keys.

This will allow us to spread the keys among countries and jurisdictions and provide the kind of distributed resilience that the Serval Project is predicated on, and even allows the software to continue to be refined and distributed if the Serval Project as an organisation ceases to exist.

If you think that your organisation might like to be one of our key custodians, let me know.

More than we expected at the IEEE

2011-09-22T07:39:00.000-07:00

If you have been reading this blog you will know that we sent Romana over to Okinawa to present our desire to see ad-hoc mode wifi improved, and also to consider how to use the baseband radio in mobile phones to support wifi on very low cost phones, and also to provide much longer range meshing using the ISM915/868 bands that offer very useful link budget advantages over the 2.4GHz band used by regular WiFi.

Well, we have been absolutely gobsmacked by the interest and positive response that Romana experienced at the meeting, and have the opportunity of taking up the baton to champion proposing these enhancements through the formal IEEE 802 standards process.

This is a great privilege, and also an opportunity that cannot be accepted without serious and solemn consideration, because it will basically require someone's effort, full time, for perhaps three years or more.

We are convinced that we want to, and that we should engage with this standards process, but just need to work out whether we have the resources to do it, without drawing all of our available resources away from progressing the development of the Serval mesh telephony software.

More news as we have it.

Why Serval is getting involved in the 802.11ah standards process

2011-09-13T17:23:00.000-07:00

Serval is getting involved in the IEEE 802.11ah (WiFi on ISM bands below 1GHz) to try to make sure that it is well suited to infrastructure-independent ad-hoc and mesh networking at the IEEE meeting in Okinawa next week.

Here is our submission:

https://mentor.ieee.org/802.11/dcn/11/11-11-1138-00-00ah-packet-radio-mode-for-802-11ah-a-b-g-n.ppt

Basically we are asking for two things:

1. Improvements to ad-hoc mode (or provision of a new "packet radio" mode) that remove some of the problems currently faced when creating wifi-based ad-hoc mesh networks.

and

2. That the 802.11ah standard consider speeds below 1mbit and using cell phone baseband radios as a supported transport so that even cheap cell phones can form relatively long range mesh networks without any supporting hardware.

This second point is really important, because compared with 2.4GHz WiFi a mesh running in the ISM 915MHz band gains about +9db just from the change in frequency, which alone improves range by almost 3x. If it supports lower bit rates, then further significant gains are possible, e.g., allowing 100kbit communications gives another +10db, for a total of 8x range versus WiFi.

There are some significant protocol challenges to be addressed, but if the standard doesn't support the use-case, then there will be no hardware and no chance.

These measures have the potential to push the indoor range up from WiFi's "about one house wide" to "about a block wide" and clear line-of-sight range up to a few km, which suddenly makes the formation of suburban ad-hoc mesh networks possible, which has profound impact for creating resilient infrastructure-independent communications solutions, for example for sustaining communications during disaster or enabling communications for rural and remote or developing populations.

We admit that we are very green to this process which we frankly find to be daunting.

But we feel compelled to try, regardless of what we perceive to be the odds of success.

More progress on the overlay mesh network

2011-09-12T13:53:00.000-07:00

It is 5:58am and dawn is just beginning.

I have been up all night making the best of the need of an overnight sleep study for our son, which requires an adult to perform a specific function every 15 minutes throughout the night.

Programming in these little pieces feels a bit like the software development version of watching commercial television; just as you think you are about to witness something really interesting there is an interruption.

Nonetheless, I have made significant progress getting the overlay mesh to send and receive advertisements of a different kind; notices by one node that they can reach another node.

There are plenty of bugs that I know about, without even thinking about the ones that I don't know about, and also some code that is still plain old missing. But even so, I have got the code forming a multi-hop mesh and keeping track of the routes to them.

I ran two nodes connected to two separate dummy networks, so that they couldn't see each other. Then I connected an extra node in the middle that bridged the two networks, and after a short delay, viola, the nodes could all see each other. The image shows the routing table from one of the nodes with only one network interface.

The 0000000* addresses in the neighbour table are clear evidence of some of those bugs I mentioned, as is the crazily large age field for one of those.

The FDB3BA1*, D64CEB4* and B167503* addresses are nodes that I had temporarily added to the mesh, and then removed again fairly recently, so the routes were (correctly) still hanging around with their link scores steadily dropping.

The important part is the route to D6850E3*, the node on the other network, for which the current route is via 30464E5*, which is the node bridging the two networks. 30464E5* was a node that I had previously bridging the networks just a short while earlier, and we can see the lingering route as it decays.

B167503* is the node currently bridging the link, and it's score is still climbing, and is about to overtake the recently removed node and become the route of choice.

So while I have a lot more work to do, the basic function of the mesh to discover multi-hop paths and switch routes based on appropriately calculated scores.

But right now, I am going to bed.

Why User-Land Mesh Networks Are Necessary For Heterogeneous WiFi Mesh Networks

2011-09-12T07:01:00.000-07:00

The normal approach to creating a mesh network is to write a program that does some tricky stuff to work out how to get from node A to node Z via whatever nodes might be in the middle, and then tell this to the operating system so that packets get routed according to these instructions.

We are doing something different for Serval, in that we are having the program that does all that tricky stuff carry the messages between nodes, instead of asking the operating system to help out.

This has some disadvantages and some advantages.

First, the disadvantages, and why we think that they aren't such a problem for our application.

1. Such "user-land" overlay networks suffer from an inefficiency known as "double-copy", where every packet sent or received ends up getting copied not once by the kernel, but twice, once by the kernel, and once by the overlay program. This is bad if you are processing lots of data. But on a mesh network the actual throughput of data tends to be fairly low (it is one of the well known problems with mesh networks). So this problem is kept under control.

2. Programs that want to know about the mesh network need to know about the overlay and have to use special calls to talk to the mesh. This is bad if your primary goal is allowing people to run BitTorrent, SSH, for example, because you need to modify each of those programs to support the new network, and without operating system cooperation that can get a little messier than you might like.

However, for a mesh telephony platform, and where we know that bandwidth starvation is one of the greatest potential problems, there is actually merit in requiring people to go to some effort before they enable their application to consume the limited resources of the mesh. We will be adding the support to the initial core applications we intend to run over the mesh, so this isn't really a big deal.

Now for some advantages:

1. We don't need operating system cooperation. This makes it easier to port the mesh to all operating systems, both desktop and mobile. It is especially important because the need to fiddle with routing tables requires root/administrative access on most platforms.

For mobile platforms, this is certainly true on Android, and I believe iOS, with together constitute the majority of smart phones. This alone means that we have to take this path.

But it also gives us some additional upside here, in that it means we could make a USB key loaded with Serval mesh software that could be run on any desktop computer, and without administrative access or being "installed" could enable that computer to participate in the mesh. In fact, it could probably even be an HTML5 application running in a web browser.

2. It separates us from the underlying network addressing. Many devices and networks only support IPv4, but there aren't enough IPv4 addresses to go around. But by pushing our mesh network addressing into a dedicated addressing layer we can solve this problem.

We use 256bit Elliptic Curve cryptography keys as the basis for our address

In fact, using this approach it is possible for every single Serval enabled device on a mesh to all have the same IPv4 address, provided we use only broadcast traffic, which we do for a very important reason:

Broadcast traffic is the only traffic which WiFi ad-hoc can reliably carry between devices with incompatible or buggy ad-hoc implementations. For example, we cannot get unicast traffic to flow reliably between Mesh Potatoes and Huawei IDEOS U8150/U8180 phones. However, we can get unicast traffic to flow between Mesh Potatoes and the original Android G1 developer phones, and between the G1 and the U8150/U8180 phones.

Unfortunately mesh routing protocols all tend to use broadcast traffic to discover available routes, and thus the routes choose the impossible Mesh Potato-U8150/U8180 links, which is very bad indeed. But by making the mesh traffic itself broadcast we ensure that what the mesh routing protocol and what we are trying to do is the same, instead of merely similar.

Taking this a little further, by transporting the mesh topology management information in the same packets as the data we can directly measure the performance of the mesh delivering the traffic we really care about, rather than using different packets as an indirect measure -- especially since the distribution of packet sizes can otherwise be very different, and WiFi packet losses are not insensitive to packet length or differentiation between broadcast and unicast traffic.

Implementing this is of course a significant undertaking, and I have already spent a few weeks programming away. But the effort is beginning to yield results. Today for the first time I have the new overlay mesh detecting nodes and building the in-memory route table. You can see a screen grab here:

So here you can see some debug output from a Serval DNA node running in overlay mode using a file called dummy0 as a dummy network interface.

I realised early in the development of the overlay network that I would need some convenient simulation tools to make it easier to debug the behaviour of the mesh. I decided the best way to do this was to make the software itself also a network simulator. So I added support to pretend an ordinary file is a network interface. Any instances of the overlay pointed to the same file would all append their "packets" to the end of the file, and remember where they had got up to reading from the file, and keep an eye out for any packets deposited by other nodes.

Each packet also has a header that has space for location information, transmission power, time, node velocity and heading and a whole pile of other information that can be used to drop packets that are deemed to have been sent from too far away, or suffering collision during reception and so on.

The file then also represent a log of all activity on the mesh which has already proven very helpful for debugging. I will also create a tool that allows for the creation of visualisations of the mesh in action to help understand why things go wrong, and to explain the operation of the mesh. I will post such animations here once I get that far.

Back to the trace, the error messages are mostly information for me for development (although there is on link-list bug that I can see I will need to fix to avoid a memory leak).

There are a few 256bit addresses that can be seen. The all-f's is the mesh broadcast address, while the one that starts with 9d5f is the address of a node on the mesh.

These addresses are really big, and so I have already implemented a variety of mechanisms for abbreviating the addresses.

For example, the broadcast address is used so often, that it has a one-byte abbreviation (0x0f). For other addresses, we only need to transmit as much of the address is required for the receiver to discriminate it from all other nodes. The birthday paradox comes into play here, and means that we typically need about twice the number of bits as the base-2 log of the number of nodes on the network. For a small network of a few hundred nodes 24 bits (3 bytes) of address is a pleasant over-kill. Even at a global scale, we need to accomodate around 10 billion addresses = ~2^34 addresses, and so about 70 bits (7 bytes) should be enough.

We also have abbreviation strategies where neighbouring nodes that talk with each other a lot can allocate a one-byte short code for each other, however, as you might be able to guess from the trace that abbreviation method is temporarily disabled in the code to keep my life a little simpler at present -- which is a good move because of the density of new features in the code.

At the end of the trace we see a summary of the overlay routing table which shows 7-digit address prefixes for all know nodes on this network, and the link-scores to each via the various routes known to each.

The scores have two components. The first being a BATMAN-like score derived from beacon counting, although we take into account that the remote node might have different interfaces running at different beacon rates. The second part is the number of Serval gateways that are on the path.

This gateway count is there to prevent routing loops and other nasties in meshes where the overlay has managed to infer some hierarchy, or where inter-mesh links have been purposely provisioned.

I'll talk about inferred hierarchy in another post, but it is one of several measures we are taking to ensure that a Serval mesh can scale beyond the normal bandwidth-starvation limit imposed by all nodes trying to know about all other nodes all of the time.

Our premise is that you need frequent information for nearby nodes because their "bearing" can change wildly over short time frames, but that for more distant nodes their "bearing" on the mesh should change much more slowly, and so we should be able to cope with less frequent updates about the position of such distant nodes.

But meanwhile, as you can see we are making good progress, and the Serval DNA overlay mesh is beginning to come together.

A Thermo-Electric Saucepan?

2011-09-08T00:42:00.000-07:00

Today we received our thermo-electric saucepan from TES New Energy. You can see some pictures of it below.

This amazing device provides a full-powered USB port when placed on a fire by using thermo-electric generation.

The interesting innovation is that by incorporating the thermo-couples into a saucepan the water in the pot keeps one side of the junction cool to maximise the power output, while ensuring that the about 98% of heat that the thermo-couple cannot turn into electricity heats your water.

This also means that they can use different types of thermo-couples that work better at different temperatures. The hot-side of the pan uses lower-efficiency thermo-couples that can tolerate the higher temperatures, and the "cold" side of that is joined to the hot side of the lower-temperature thermo-couple which is also a little more efficient, and the water in the pan helps to make sure that this lower-temperature thermo-couple does not over heat. Together, they avoid the complications that would normally be present if using only one of the thermo-couples, either lower yield, or the potential to be damaged by higher-temperature fires.

The saucepan approach is also an elegant way to circumvent the atrocious inefficiency that typically plagues thermo-electric generators, since in a diaster or remote location you probably need hot water, anyway, a realisation that TES NewEnergy had following the mega earthquake that struck Japan recently.

So this saucepan is about enough to charge a phone if you are in the middle of nowhere, and solar isn't an option for whatever reason -- perhaps because the power is out due to storm, volcano, or just during bad weather.

Anyway, we are looking forward to some fun testing Serval mesh phones powered by a high-tech saucepan on a campfire.

Day 1 of Shuttleworth Foundation Fellowship

2011-08-31T22:39:00.000-07:00

So today I have commenced a telecommunications fellowship with the Shuttleworth Foundation, which will be undertaken here at Flinders University where with the University's generous support we have based the Serval Project.

This is an amazing support for our work on the Serval Project, as not only does it free up my salary so that we can employ a project manager, but it also provides access to a very helpful operational budget, and a great team of dedicated open-technologists working on a variety of projects. Check out their list of past and current fellows to get a feel for what they are supporting.

This support builds on that already provided by The Awesome Foundation, Flinders University and NLnet, as well as that of many students, volunteers and my family, which has enabled us to reach this point.

The particular mandate of my work under the fellowship is to:

- Build on existing trials, which include remote, in-motion, underground and
indoor tests by linking with partner organisations to deploy the
technology in an escalating series of situations;– Increasing the breadth of applications for the technology, and the usability
of the technology in disaster, by governments, and in remote locations;
and– Improving the maximum range between handsets beyond what is
possible using WiFi, but without altering the hardware in existing mobile telephones (the “Focus Area Objectives”).

What this means is that we will be pursuing a simultaneous software improvement and testing program that will, hopefully, get us to the point of a quality public release within a year.

The greatest challenge comes from the range extension, which we know is possible using the baseband radio in mobile phones. However, it is extremely difficult to get the programming information to enable modification of the firmware loaded into the radio's baseband processor.

We will be exploring multiple angles to achieve this, ranging from engaging with the IEEE 802.11 standardisation process, to seeking to open channels with cell phone chipset manufacturers, through to, building custom cell phones that contain friendlier baseband or other radio chipsets that we can more easily reprogram, and where legal and appropriate, reverse-engineering the information we require.

The potential gains over using WiFi to build the mesh (perhaps 300m between phones indoors and 10km or more between phones outdoors in open country) are so great that we must engage with this process, regardless of the difficulty.

Making Mesh Networks Scale

2011-08-28T03:25:00.000-07:00

Mesh networks have great potential to create sustainable, resilient and low-cost communications capabilities. This is why we are passionate about mesh networking at Serval Project.

However, the mesh routing protocols that I have seen to date almost all have a scalability ceiling. This is because if you have 10 devices all talking to each other you get 100 messages, but if you have 1,000 devices all talking to each other you get 1,000,000 messages in the same time. In computer science we would say that a mesh network has a complexity of O(N^2), because the mesh traffic scales with the square of the number of devices.

Eventually, not matter how fast the links on the mesh, the capacity gets used up.

Even on a "quiet" mesh where most of the devices aren't saying much, they still have to share O(N^2) information, and so the mesh just existing eventually causes it to collapse under its own weight.

What would be nice is a more graceful degradation, so that even in a mesh of say, 7 billion devices, that each local pool of devices could talk to one another, even though it would be impossible to allow all 7 billion to talk to each other.

It might seem pointless to allow a device to see only a few thousand nearby devices, as that represents only about 0.00001% of the devices on such a global mesh.

However, for telephony at least, it turns out that most phone calls are at most a few kilo-metres away, and thus would be possible over such a "local patch" on the global mesh.

So this is something that Serval is planning to do over the next few months.

We are going to take the BATMAN mesh routing protocol and modify it so that it can keep track of "near by" devices on the mesh without being swamped by location information from devices on the other side of the world (which from my perspective is probably you, because I live in Australia, which is on the other side of the world from most other places ;).

Opening Mobile Hardware

2011-08-22T07:34:00.000-07:00

Over the last few years we have seen the impact and innovation that opening the software on smart phones has enabled.

The key is that the barrier to entry is now so low, that innovation can prosper without significant drag or hindrance.

So why don't we open the hardware on smart phones, by offering a "geek port" that some nice simple interfaces and a really cheap common connector, like a female .156" DIP header?

The port could have some analog and digital input and output lines, and maybe a serial interface or two, perhaps the common SPI interface, and a 3.3v power rail (that the phone can turn on and off to control power consumption).

Such a simple port would be trivial in cost to add to smart phone, probably costing less than $1 in marginal hardware cost, plus a once-of cost developing some nice APIs to access the port.

Creating such a simple interface would allow the creation of cheap dumb devices that can plug into the port.

Really boring stuff, like, say, a digital thermometer, an LED and sensor that can be used to collect pulse oximetry data, and relay it on an infrastructure-independent mesh network like servalproject.org, to a local care provider. Or maybe it might be a cheap ultrasound transponder to allow mid-wives and maternal health workers to acquire cheap ultrasound imagery.

Each of these plug-ons could probably be made for $5 or less, and yet each has the potential to save many lives in the developing world, and save many billions of dollars in the developed world.

And that is just in one application domain. Who knows what else people might come up with.

After all, no one anticipated the myriad applications that have been enabled by making smart phones programmable.

I reckon that for perhaps $100,000 it would be possible to get a phone designed and a small manufacture run of such phones to demonstrate the idea. Anyone want to make a significant impact on the world?

On the ground at Chaos Communication Camp 2011

2011-08-10T04:42:00.000-07:00

As in 2007, CCC is being held at Luftfarht Museum Finowfurt, Germany. So, I am writing this from in my tent next to a soviet-era air field in former East Germany, surrounded by old MiG fighter jets and other remnants of the era.

The talks are being held in several of the earth-clad bunker/hangers, like this one:

CCC has an incredible 3,500 attendees from 45 countries this year, setting up a temporary tent city with more than 170 themed villages. I am camped in the lee of a large tent in the Blackout Resilient Technologies Village.

This village targets those working on technology that keeps power and communications up when faced with disaster. The charter of the village recognises that natural disasters and government "kill switches" are both forms of infrastructure deprivation, and that similar technologies are required to enable communications and social function whatever the cause of infrastructure deprivation may be.

For me, I am planning to work on a few things.

First, I will work with people from the Radio Village to further integrate OpenBTS and Serval, and hopefully expose OpenBTS users to the Serval Distributed Numbering Architecture (DNA), which will allow Serval mesh phones to call ordinary GSM handsets that are connected to an OpenBTS open-source mobile phone base station.

Serval DNA is a very simple protocol that I sometimes describe as "ARP for telephone numbers". It allows a phone on a mesh to ask "who has this phone number?" and get back a network address that can be used to connect to that telephone. This protocol is what allows the Serval mesh to seem just like an ordinary telephone network to end users, by completely distributing and hiding the complexity of call resolution.

I also hope to work with some of the people from the OTI/Commotion project to demonstrate a "mobile phone network in a backpack" by doing the final integration of a Village Telco Mesh Potato, a wideye BGAN satellite modem and some android phones with the Serval mesh software installed.

This will be an important step as it will demonstrate a low-cost and highly portable communications solution that can be used, for example, in disaster relief, for remote work forces and humanitarian organisations.

Finally, in any spare time I get I will work on what we are calling the "non-privileged mesh" for Serval. This will remove the main reason for needing "root" or "jailbreaking" your phone to get the full benefit of the Serval mesh software, and will also allow us to port to more types of mobile phone easier. So this is pretty important. It also sets the stage for us to do some preliminary work on setting up mesh networking using the ISM915 band, but more on that in a future post.

Solar Flare Triggers Geomagnetic Storm

2011-08-06T04:24:00.000-07:00

Earlier today (Australian time) two coronal mass ejections from the sun travelling at different speeds towards hit our planet at around the same time, triggering a very strong geomagnetic storm.

For reference, this was measured to trigger a Kp=8 storm, where the Kp values are on a scale from 0 to 9, so it was pretty big. In fact, it was big enough that spaceweather.com reported that it triggered auroras so extensive they were visible from mid-latitude locations such as England and Germany.

Spaceweather.com also mention that it was big enough that it might have squashed the Earth's protective magnetic field enough to expose geostationary satellites to the solar wind and interplanetary medium. In short words, this means that some satellites risk getting fried due to this storm. We'll find out in a few days.

Geomagnetic storms of this magnitude happen from time to time, and usually don't cause big problems. However, larger events can occur that can cause considerable problems for our big-infrastructure oriented civilisation.

Another big geomagnetic storm hit in March 1989 and caused considerable damage to electricity distribution in Canada as the changing magnetic field induced current flows in the long-distance electricity distribution cables, causing some really big transformers to melt, and causing havoc with satellites.

This event showed how our modern infrastructure is prone to damage by solar events. Indeed, there are now measures taken to reduce this kind of damage by shutting power distribution down during intense geomagnetic storms so that no transformers melt. However, damage to satellites is difficult to prevent.

However, the 1989 storm was small in comparison to what the sun can throw at us.

In 1859 the most intense geomagnetic storm ever recorded occurred and has become known as the Carrington Event.

That solar storm was so intense that aurorae were observed in such low latitudes as the Caribbean, and were so bright in the Rocky Mountains in America that gold miners got up and began to prepare breakfast.

The electric currents induced by the magnetic flux were so intense that they enabled inter-continental telegraph lines (the Internet of the 19th century) to keep working with out their power source, while others gave operators shocks.

We have since discovered that events the size of the Carrington Event occur about every 500 years.

Both the 1989 and Carrington events would create havoc with our vast number of communications and location satellites such as GPS and geostationary satellite telephone systems if they occurred today.

Even low-earth-orbit systems like Iridium and Globalstar would not be immune as the radio interference would potentially prevent their operation by interfering with satellite-ground and satellite-satellite communications. There are also more sinister problems for low-earth-orbit satellites. First, the outer parts of the atmosphere heat up and increase the pressure, and thus drag, which can cause the satellites to lose altitude, which is bad for all sorts of reasons. Second, the Van Allen radiation belts become more active, which can cause problems for satellites.

A repeat of the Carrington Event today would likely damage or destroy a significant number of satellite, as well as causing wide-spread blackouts.

In short, that part of our infrastructure which we like to consider to be immune to disaster, i.e., satellite communications and location services, are in fact prone, and science informs us that it is only a matter of time before such an event occurs.

My point in all this is that infrastructure is fragile in various ways, and forms a single point of failure.

This is why the Serval Project is working to enable existing cell phones to keep communicating when deprived of their supporting infrastructure, so that at least local communications will remain possible in the face of almost any situation, without the capability placing a cost-burden on society.

Australian Humanitarian Engineering Summit

2011-08-05T14:41:00.000-07:00

Last week I attended the Humanitarian Engineering Summit in Brisbane, Australia.

You can read about it and watch a TV news report here at the Engineers Australia web site.

This was an interesting event. First, the attendees were an almost even spread across all age ranges, perhaps with a bias to the younger end. All of these people were exploring what it means to be a humanitarian engineer, and what they and the engineering profession as a whole can do to address many of the challenges in the world.

It was extremely encouraging to see the passion and dedication of many of the younger delegates -- including many current Engineering students -- because one day soon they will be the generation of engineers ultimately defining by example what it means to be an engineer.

Perhaps one of the greatest themes of the day was that in trying to help communities in need, it is not sufficient or indeed appropriate to simply turn up with a "first world solution" set it going, and then leave. The almost inevitable result is that the intervention fails, essentially because of lack of ownership and appropriateness -- both of which stem from the fundamental need for better consultation and inclusion of the community the intervention is serving. I think that they are spot on.

For Serval, this means that we need to continue to engage with the potential target audiences of our technology, which we are already committed to doing. Otherwise, we stand the risk of becoming irrelevant and useless for the very people we want to help, in which case we may as well pack up and go back to our old jobs.

Another semester begins ...

2011-08-04T00:54:00.000-07:00

It is the beginning of the second semester here in Australia, and we have five new students starting with the project. We had seven last semester, and two have finished. That means that we now have ten students -- with is both daunting and exciting. Daunting, because it means that I will have ten more projects to guide and manage, and exciting because I will have ten more excellent people working on aspects of the Serval Project.

The new students will be looking into cryptography, smart ways to use GPS when there is no infrastructure, and the first steps towards long-range ISM915 mesh communications as well as initial explorations towards porting from Android to iOS and Symbian.

These students will build on the great work which students, staff and volunteers have put in over the last six months.

We now have substantial progress towards infrastructure-free SMS and mapping services, as well as a really simple installation procedure, and some great ground work to make it easier to port to new Android phones as they come out.

So, I find my self rather much in a tremendously exciting and amazing place as we make the Serval Project's vision of universal communications, anywhere, any time, a reality.