Wednesday, September 13, 2017

Second visit to Vanuatu

We are getting to the end of our third trip to Vanuatu, so I figured I really ought to post about our second visit.

This visit was shorter than the first, as it was primarily focused around the UN World Food Programme's regional Emergency Telecommunications Cluster (ETC) meeting, which has representatives from Vanuatu, Samoa, Solomon Islands, Fiji and Tonga.  The purpose of this meeting is to help the relevant folks from each country to get to know one another, as well as to learn more about what is happening globally, and to find solutions to the problems that they are facing in their region and specific countries.  This is the second time I have attended this regional meeting.

Together with Andrew Bate we spoke about the Serval Mesh and our pilot here in Vanuatu.


There was strong interest with plenty of people handling the Mesh Extender prototypes:


And then giving the Serval Mesh a try.  In the Pacific where telecommunications is almost always a challenge, there was no need to convince people of the need: Rather they wanted to know when the Mesh Extenders were available for purchase, and at least one asked why we weren't running the pilot in their country instead!


The interactive demo was lots of fun, with many people around the room trying it out.


But what I really love are situations like that captured in the following photo, where people start showing each other how to use it:


After the indoor demo, we later had a session with other presenters where we went outside to let people have a further hands-on of the various technologies being discussed. So I soldered up the correct connector onto a solar panel to power a Mesh Extender directly from that, without even a battery, using the built-in solar regulator in the Mesh Extender:


Then found a suitable coconut palm to attach it to (this is the tropics, after all):


Held firmly in place with an octopus-strap, i.e., bungie cord for those of you not from Australia:





Then it was open-season for the Mesh Extender.  Again, it was great to see a wide variety of folks from different countries and organisations in the Pacific trying it out:




Again, I just love it when people start showing each other how to use it, without any involvement from me. At that point we have victory!



Also, we discovered that the Mesh Extender is approximately one hand in size:


Then later in the week we had an impromptu meeting with the Vanuatu Ministry of Health, where we repeated the hand-on test, but this time all I did was supply the equipment: They did the temporary installation themselves: 









Then it was another encouraging session where everyone was trying it out and showing each other how it worked.  There were also some folks from the UN World Health Organisation there, who were very interested in how it could be used to help with disease and public health data collection.



One of the other great things is seeing not just men using Serval, but women as well, and women showing other women how to use it.  This is important because the more that a technology is used by all kinds of people in a community, the more likely it is to succeed.





Monday, August 28, 2017

Assembling 50 Mesh Extenders ready for Vanuatu

Tomorrow we fly out to Vanuatu for our third visit. 

This means we need to have several dozen Mesh Extenders ready to take with us, to hopefully begin deploying in Port Vila between various government and NGO sites, and assuming we get the final authorities through, to also connect a couple of outlying villages.

From a practical stand point, this means flashing 50 Mesh Extender boards, 50 RFD900+ radios, 50 boot loaders, and pre-formatting and putting the default files on 50 USB memory sticks, and then assembling the boards in their cases.

Flashing the radios is fairly simple, and can be done using an FTDI USB serial cable in about a minute.  I did those last night while sitting at the computer after the kids went to bed.

For the boot loaders and OpenWRT firmware, I wrote a simple program today that listens on a serial port for the uboot boot loader, and then directly issues the commands to flash first the boot loader, and then the firmware.  When it has finished, it runs vlc and plays an MP3 file to alert me that it is ready for the next board, thus saving lots of dead time between flashing boards.  It went smoother with the team in the lab when I stopped playing the music from Wizball, and switched to Greensleves.

Apart from some niggly problems with the USB serial adapter drivers causing the port to stop reading data, the while process takes only a minute or two.  This is allowing us to plough through flashing the boards much faster than expected, which is good (I have been interrupted by VLC playing Greensleves at me several times while writing this post).

Here is my bench setup, as I flash a board.  Firmware and boot loader updates are loaded via ethernet from a tftp server on my laptop. Commands are via serial through an adapter on the radio/power connector on the Mesh Extender, and power for the Mesh Extender comes via the micro-USB connector on the Mesh Extender board which exists for that single purpose (it doesn't actually provide an USB data signals):


The harder part is the assembly.  You can see three of our great students who are helping with the assembly:



Ryan is checking that the boards have correctly flashed and boot and begin transmitting via the UHF packet radio.

Then we have to get the boards into their cases. This is the fun part, because this revision of the PCBs has the wrong D-SUB 25 connector compared to what we wanted, but due to time constraints we are stuck with them for this batch.  The problem is that the D-SUB connectors have holes for screws, but are not threaded.  This means we have to put washers and nuts on the back of the connectors, which are frustratingly located in rather awkward locations, as shown here marked by the yellow arrows. 


Those locations are right in the bottom of the shell, about 55mm down. For the one on the left, the super-capacitor is in the way, all making it rather difficult to get in there to install the washer and nut on each.  Very annoying. Our current least-bad solution is to use some seizers.

So that's our afternoon today, basically getting enough of these assembled, ready to go, as well as getting everything packed in the big case ready to fly out tomorrow.

Tuesday, August 22, 2017

Migrating between EFM32 parts in Simplicity Studio

One of our projects at the moment involves the EFM32 Pearl Gecko low-power microcontroller.  These are really nice, and capable of very low power consumption.

At the last minute, our supplier could only source us the Jade Gecko instead of Pearl Gecko chips. The only difference is the lack of FPU, so far as I know. Our project doesn't do any floating point, so there wasn't a problem there, or at least, so I thought.

However, when I tried to change the part in Simplicity Studio I hit endless problems, largely due to a lack of understanding about how Simplicity Studio works.

Because we were basing our project on a standard kit board, and had made our PCB pin-compatible, we were continuing to use the Board Support Package (BSP) for that kit. The new part, however, was not an option in that kit, so I had to tell Simplicity Studio that I was not using that kit anymore.  This was the source of all my pain, but it took me several hours of frustration to figure that out.  This is because the error messages that were being generated were not particularly helpful.

It would complain about strange missing include files, like redirectserialconfig.h during the build process. This makes sense as I now understand that such files are provided by the BSP -- although the particular magic by which it provides them I still don't fully understand.

This was because those files are provided from kit-specific include directories.

This meant I was faced with either: (1) keeping the kit, and having the wrong MCU set, which might or might not work through binary compatibility, or (2) having to build a BSP myself, which I really wanted to avoid, as I still don't have enough low-level understanding of what is going on.

A bit of digging around and I discovered that the properties dialog of Simplicity studio which lets you choose among the supported parts on a given kit in reality just sets some #defines and include directories.  Thus, all I needed was:

1.  Go into Properties -> C/C++ Build -> Settings and for each build target modify GNU ARM C Compiler -> Symbols do delete the EFM32PG1B200F256GM48=1 line, and replace it with EFM32JG1B200F256GM48=1 (your part names may naturally be different)

2. Go into Properties -> C/C++ Build -> Settings and for each build target modify GNU ARM C Compiler -> Includes and change  "${StudioSdkPath}/Device/SiliconLabs/EFM32PG1B/Include" to "${StudioSdkPath}/Device/SiliconLabs/EFM32JG1B/Include" (again, adjust part families according to your project).

Then, finally, I could get the build to succeed again.  This is probably all well known to just about everyone, but it tripped me up, so I figured I would document it in case it was useful for others (and also so that I can remember better how to do it in the future).

For those like myself who are more command-line oriented, here is the diff for my project (which unfortunately I cannot share the complete thing with you):

diff --git a/.cproject b/.cproject
index 75fdb6d..7ed84db 100644
--- a/.cproject
+++ b/.cproject
@@ -35,7 +35,7 @@
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols.56412088" name="Defined symbols (-D)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols" valueType="definedSymbols">
  <listOptionValue builtIn="false" value="DEBUG_EFM=1"/>
  <listOptionValue builtIn="false" value="DEBUG=1"/>
- <listOptionValue builtIn="false" value="EFM32PG1B200F256GM48=1"/>
+ <listOptionValue builtIn="false" value="EFM32JG1B200F256GM48=1"/>
  </option>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin.59744490" name="Always branch to builtin functions (-fno-builtin)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin" value="true" valueType="boolean"/>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog.2095193964" name="Generate debugger-friendly prologs (-mno-sched-prolog)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog" value="true" valueType="boolean"/>
@@ -47,7 +47,7 @@
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/emlib/inc&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/kits/common/drivers&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/CMSIS/Include&quot;"/>
- <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32PG1B/Include&quot;"/>
+ <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32JG1B/Include&quot;"/>
  </option>
  <inputType id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input.1259106684" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input"/>
  </tool>
@@ -121,7 +121,7 @@
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols.1906527140" name="Defined symbols (-D)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols" valueType="definedSymbols">
  <listOptionValue builtIn="false" value="DEBUG_EFM=1"/>
  <listOptionValue builtIn="false" value="NDEBUG=1"/>
- <listOptionValue builtIn="false" value="EFM32PG1B200F256GM48=1"/>
+ <listOptionValue builtIn="false" value="EFM32JG1B200F256GM48=1"/>
  </option>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin.1881027154" name="Always branch to builtin functions (-fno-builtin)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin" value="false" valueType="boolean"/>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog.1759032162" name="Generate debugger-friendly prologs (-mno-sched-prolog)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog"/>
@@ -133,7 +133,7 @@
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/emlib/inc&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/kits/common/drivers&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/CMSIS/Include&quot;"/>
- <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32PG1B/Include&quot;"/>
+ <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32JG1B/Include&quot;"/>
  </option>
  <inputType id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input.2098567682" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input"/>
  </tool>
@@ -206,7 +206,7 @@
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols.1801462641" name="Defined symbols (-D)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols" valueType="definedSymbols">
  <listOptionValue builtIn="false" value="DEBUG_EFM=1"/>
  <listOptionValue builtIn="false" value="DEBUG=1"/>
- <listOptionValue builtIn="false" value="EFM32PG1B200F256GM48=1"/>
+ <listOptionValue builtIn="false" value="EFM32JG1B200F256GM48=1"/>
  </option>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin.711105496" name="Always branch to builtin functions (-fno-builtin)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin" value="true" valueType="boolean"/>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog.1497848589" name="Generate debugger-friendly prologs (-mno-sched-prolog)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog" value="true" valueType="boolean"/>
@@ -218,7 +218,7 @@
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/emlib/inc&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/kits/common/drivers&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/CMSIS/Include&quot;"/>
- <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32PG1B/Include&quot;"/>
+ <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32JG1B/Include&quot;"/>
  </option>
  <inputType id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input.462471232" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input"/>
  </tool>
@@ -292,7 +292,7 @@
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols.227214347" name="Defined symbols (-D)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.def.symbols" valueType="definedSymbols">
  <listOptionValue builtIn="false" value="DEBUG_EFM=1"/>
  <listOptionValue builtIn="false" value="NDEBUG=1"/>
- <listOptionValue builtIn="false" value="EFM32PG1B200F256GM48=1"/>
+ <listOptionValue builtIn="false" value="EFM32JG1B200F256GM48=1"/>
  </option>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin.856642787" name="Always branch to builtin functions (-fno-builtin)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.builtin" value="false" valueType="boolean"/>
  <option id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog.2116127698" name="Generate debugger-friendly prologs (-mno-sched-prolog)" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.debug.prolog"/>
@@ -304,7 +304,7 @@
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/emlib/inc&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/kits/common/drivers&quot;"/>
  <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/CMSIS/Include&quot;"/>
- <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32PG1B/Include&quot;"/>
+ <listOptionValue builtIn="false" value="&quot;${StudioSdkPath}/Device/SiliconLabs/EFM32JG1B/Include&quot;"/>
  </option>
  <inputType id="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input.686138013" superClass="com.silabs.ide.si32.gcc.cdt.managedbuild.tool.gnu.c.compiler.input"/>
  </tool>

Monday, August 21, 2017

Power/radio cables with over-moulding


I thought some folks might be interested to know how we are getting our cables fabricated, so here are some photos of the tool used for the low-pressure injection over-moulding that adds the red rubbery plastic over the connector and circuitry in the cable head.

First, here you can see a finished cable and the tool, which was designed and machined for us.  Unlike high-pressure injection moulding, where you can turn out multiple parts per minute, but the tool cost is tens of thousands of dollars, the complete tool design and manufacture cost here was only about AU$3,000 with our friends at Innovation Engineering.  The trade-off is that each part takes minutes to produce, instead of seconds. For now at least, that isn't a big problem.

t

Looking closer at the tool, you can see the big fat guide pins that hold it in proper alignment when assembled:


Then on the other half you can see this funny bar with the two brass pins.  This is removable, and held in with a couple of magnets.  It ensures that there are holes through the moulded body for the thumb-screws.  It needs to be removable, as you need to get the cable in and out of the tool.


Here is that same tool without it in place:


And here is the removable part itself. You can see here that it has the recess that fits snugly around the D-SUB25 connector, so that it doesn't get encased in plastic during moulding, but continues to stick out the end, as it needs to do, in order to be a useful cable:

Then finally, here it is all assembled (but without a cable inside):



As I have said before, it is so much easier to work with a company who is only a few minutes away, so that if there are problems, they can be quickly inspected and dealt with, and so that communications can be free flowing, so that everything goes well.

Now we are just waiting on the delivery of our next 45 of these cables, ready for our third trip to Vanuatu.

Monday, August 14, 2017

Assembling injection moulded Mesh Extenders

After various delays on various fronts, we now have in our possession enough components to assemble 40 Mesh Extenders, sufficient for the remaining activities for the Vanuatu Pilot.

Yesterday, the RFD900+ radios, antennae and Mesh Extender PCBs arrived:



 We already had the injection-moulded housings on hand (in the boxes behind the radios and PCBs):


First step of assembly is to fit the reverse SMA bulk-head connectors to the cases, and also install the o-rings.  While not particularly glamorous, this represents some number of hours of work to do.  Karthik, a work placement student, has been placed with us over the next few months, and gets to be the lucky one to do this task:


 The first afternoon's work, we have 16 units with seals and 2 of the 3 RSMA leads in place:


After these have been all prepared, we will then proceed with getting the firmware  on the PCBs, and radios and bulk storage fitted.

Our original plan was to use microSD cards, as they are lower power consumption than USB memory sticks, and probably handle power loss better than memory sticks.  However, there is a problem with the kernel driver for the microSD card interface, which we have yet to resolve, so we are probably going to stick with USB memory sticks for now. 

Fortunately we were able to get the USB port working in the Mesh Extenders, after a bunch of earlier problems with signal integrity of the USB data traces.

The only side effect is that we probably won't be able to reliably run these units on solar without a battery connected -- we'll find out for sure as we proceed with testing.

Thursday, August 3, 2017

Education in Emergencies challenge

Just a quick post to say that we have been short-listed in this challenge to find solutions for sustaining education during emergencies:

https://challenges.openideo.com/challenge/education-emergencies/refinement/interactive-and-integrated-on-line-education-off-the-grid

We feel that Serval is an ideal match for this use-case, especially if an online education system, like Moodle, were extended to support mesh delivery and interaction.

Please feel free to take a look at our entry, and hit the "love it" button, to help raise the profile of our entry.

Sunday, July 30, 2017

OpenWRT firmware building/installing problem

I'm currently working on the firmware for the Mesh Extenders, and have hit an unexpected problem:

Whereas we have previously been able to easily build and flash OpenWRT firmware images onto the Domino Core modules (Atheros 71xx based, Chaos Chalmer derived firmware), it has suddenly stopped working with nasty errors from uboot, like this:

uboot> boot
Booting image at: 0x9F050000

   Image name:   MIPS OpenWrt Linux-3.18.45
   Created:      2017-07-10  23:59:50 UTC
   Image type:   MIPS Linux Kernel Image (lzma compressed)
   Data size:    5328879 Bytes = 5.1 MB
   Load address: 0x80060000
   Entry point:  0x80060000

Uncompressing kernel image... ## Error: LZMA error num: 1
uboot>

Anyone who can provide some assistance or suggestions as to how to go about tracking the problem down and fixing it would be greatly appreciated.

Some clues so far:

1. The firmware file from http://www.gl-inet.com/firmware/domino/v1/openwrt-domino-2.261.bin, and that works, so I presume that both uboot and the hardware are working.

2. We used to build and flash firmware from an Ubuntu VM in a Mac.  This problem has come about since moving to a native Ubuntu 16.04 based machine.

3. Firmware built on the Mac, which we believe used to work, doesn't seem to worrk now.

4. When this first occurred, it looked like we might have had a problem with a USB power plug, so we have ditched that, and are now running the boards from a USB port on the laptop.  It is in this configuration that we have successfully installed the firmware file mentioned in (1).

5. I *did* manage to build some working firmware images on Friday with the Linux laptop, and apart from using old versions of Serval packages, they seemed to work, before putting updated versions on stopped working.

I'll likely update this post with progress of things as I try them.

UPDATE 01AUG17: It looks like the problem is that we can't flash from uboot while a microSD card is inserted.

Works

1. gl-inet openwrt-domino-2.261.bin installed from Linux laptop via "run lf" + tftp

2. Freshly built openwrt image built from Linux laptop without Mesh Extender package, and on an older test board, that was never powered by the presumed faulty USB power plug, and with no microSD card inserted. [01AUG17]

3. Freshly built openwrt image built from Linux laptop without Mesh Extender package, on one previously powered by the presumed faulty USB power plug, and without a microSD card inserted. [01AUG17]

Doesn't Work

1. openwrt-ar71xx-generic-uImage-initramfs-lzma.bin built on Ubuntu 16.04 laptop from github.com/servalproject/openwrt

2. Freshly built openwrt image built from Linux laptop without Mesh Extender package, on one previously powered by the presumed faulty USB power plug, and with a microSD card inserted. [01AUG17]

Thursday, July 6, 2017

First visit to Vanuatu

It has been a rather busy couple of months, so I am only just catching up with sharing what we have been up to. All going well, there will be a burst of posts describing our recent activities.

But first in this post, I want to talk about our first visit to Vanuatu as part of our Pacific Humanitarian Challenge (PHC) award from the Australian Department of Foreign Affairs and Trade (DFAT).

Basically, DFAT have commissioned us to run a pilot of the Serval Mesh in Vanuatu, to be concluded and reported on by the end of 2017. I can assure you, that that timeline is feeling very tight right now.

The lead up to the first visit was busy with getting the very first prototype Mesh Extenders built.  The circuit boards were still under active development, as we tried to fix a few niggling issues around the USB port and power/radio port pinout. We were also waiting on the first injection-moulded shells for the Mesh Extenders.

Part of the busy-ness was also that we had timed our first visit to Vanuatu to coincide with the Pacific ICT Days, which gave us a very firm deadline.

Part of our motivation in being there for the ICT days, was that I would be able to present to representatives from a number of nations in the region, to raise awareness and seek input from them on what we are doing.  This broader socialisation of Serval is one of the goals of the PHC award, to help gauge the regional interest and demand for our work.

Another motivation in being there for the ICT days was to be able to see what other initiatives are underway in Vanuatu, and work out who we could partner with for the pilot project.

We also arranged to stay for about a week after, to allow plenty of time to meet with various stake-holders.  Some meetings were pre-arranged, but the majority were arranged once in country, as this is still the easiest way.  I really can't emphasise how important it is to allow time in-country when working in Pacific island nations.  You can often achieve in a week or so, what would otherwise take a month or more to try to arrange remotely. Finally, the time in country gave us the chance to better understand the local context, and begin to understand the local culture first-hand.

Now to follow the visit in pictures:


 First, it was presentations at the Pacific ICT Days.  Matthew Lloyd, who has been our key contact in NZ Red Cross for almost seven years has resigned and is now a volunteer with NZ Red Cross, and an independent consultant offering his considerable humanitarian, innovation and related experience.  Matthew accompanied me on this trip to assist with the project, and will also help out on upcoming visits to Vanuatu as well.  If you are looking for someone with considerable experience and insight into the region, I'd suggest getting in touch with him (poke me for contact details).

Matthew also presented on behalf of NZ Red Cross while there with us, talking about Succinct Data, another of our joint projects:


Then it was my turn to present about Serval and the PHC pilot in Vanuatu:


We had some of the freshly-minted new Mesh Extenders with us to pass around for the audience to look at and interact with.  Having a professionally designed and manufactured injection-moulded case makes a massive difference to first impressions: Suddenly people think of it as a product and want to know how much they cost! It might have been expensive to do the tooling, but it is already paying dividends, by removing psychological barriers.


Then it was a visit to the National Disaster Management Organisation (NDMO) as part of the ICT Days activities.  This was convenient, as the NDMO one of the organisations on our list to visit.  We are arranging with NDMO to put a Mesh Extender on their building as part of a local network in Port Vila as part of the project.  Here I am outside the door waiting to go in:



Then back at the convention centre it was time to speak as part of a panel looking at the role of ICT and telecommunications in facilitating opportunity and growth.  Two places to the right of me is Salma Farouque, who has been based in the UN World Food Programme (UNWFP) in Fiji, and has also been a huge help in connecting us in with various folks in the region:


After the ICT Days were over, it was time to start meeting with other people.  One of the first visits was to the Telecommunications & Radiocommunications Regulator (TRR), the Vanuatu equivalent of the FCC in the US, or ACMA in Australia.

I cannot overstate just how supportive they have been of us, and the practical assistance that they have given us already.  The regulator staff clearly understand the communications and social challenges facing Vanuatu, and see that we have a missing piece that can help in ways that complement the existing mobile carriers and other initiatives in Vanuatu.

In particular, the regulator sees that technologies like the Serval Mesh have the potential to provide at least basic telecommunications services in locations where conventional cellular communications will never be cost-effective to provide, because of the small, low-income isolated communities living in hilly, mountainous and/or remote locations.   So it was lovely to finally give them the opportunity to try out the Serval Mesh, and see the Serval Mesh Extenders for themselves:



Speaking of the Mesh Extenders, time was so tight before I flew out (my lovely wife even had to help me cut out the holes to pack the Mesh Extenders in the foam blocks in our shipping crate in the hours before I flew out), that I didn't have time to make up the power cables for them.  So this had to happen in Vanuatu.  Sadly my old soldering iron is no longer really up to the job, so this ended up being much more of a hassle than it should have been:


(I have since bought a really nice little AA-battery powered soldering iron, so that for future visits, including to Maewo where there is very limited mains power, I don't have a repeat of this problem.)

TRR also helped us choose a couple of Villages on the same island as Port Vila where we could conduct the pilot, and then made us the necessary introduction to the chief of the first of those villages, and came out with us and helped translate into Bislama (the local Vanuatu pidgin language that almost everyone speaks):


Speaking of Bislama, here is the crate of water we bought.  Translation: "Number #1 water / Good water, good life":



Back to the village, once they understood what we were offering, they were very interested, understanding the value of communications, and given the reality of the lack of cellular coverage in most of the village.

In this particular village, most of the buildings are still rather informal structures, and the surrounding vegetation is quite thick jungle:



Speaking of the jungle and vegetation, there are some quite impressive trees around.  The canopy typically is 10m -- 20m once you get away from the road.  This means that UHF packet radio will really only work if the Mesh Extenders are lofted high enough to clear the vegetation.  This will be one of the challenges going forward.  I expect that a lot of traffic will still deliver using store-and-forward transport in people's phones.


The main highway around Efate island has been sealed, but there are still interesting features, like this wooden bridge. One presumes that a more permanent structure doesn't exist because it would be (or has been) washed away following flooding.


Below, there are number of edible plants visible, primarily bananas and taro (I think) plants.  It seemed like days before we saw any banana trees with fruit on them, and then suddenly we saw them everywhere, so I assume it just took my eye a while to get in the zone.


I have an interest in bananas, because I grow them at home in Adelaide, where the climate really is very marginal for them.  This has come in handy before when we needed a shot showing how Mesh Extenders might be installed in the tropics, but while I was at home. Having the banana plants at home came in handy for taking the following shot:

Not in Vanuatu
But bananas aren't the only fruit on hand.  From a road-side stall we were able to buy 20 large and yummy passion for a total of A$1.20:


Then it was around to the next village, who helpfully have a nice map painted on the side of a building:


This village also has a presence from the US Peace Corp, and generally seems to have more built infrastructure than the first village we visited.  There are apparently a lot of families that are spread between these two villages, which is part of why we are looking at them for the pilot, as we will have intra-village and inter-village communications.  The villages are about 10km apart -- too far for a single Mesh Extender UHF hop, so the inter-village communications will most likely be store-and-forward by people's phones for the most part.

Disaster awareness is something that is taken seriously in Vanuatu:


Then it was back to our accommodation to do some paper work and organise more meetings, with the help of the resident cat in the accommodation.  The cat was very happy to have some extra people around


Next stop was the Office of the Government Chief Information Officer (OGCIO) to keep them informed of what we were planning, and to ask for their assistance to finalise our human ethics approval acceptance in Vanuatu.  This process is still continuing, while we wait for the final sign-off from the Vanuatuan side. This is one of many processes that would have been much harder and taken even longer if we had not been able to spend time in country to talk with the appropriate people.


Then it was time to meet with representatives from the local mobile telephone carriers with the TRR.  This was a really interesting and productive meeting. We communicated our belief that in Vanuatu it makes a lot of sense for the carriers to leverage Serval to improve customer satisfaction (and that of the TRR!) by finding low-cost ways to plug coverage holes, and having an additional capacity that can be used to support communications when towers fail following cyclone or other adverse events.




In particular, we spoke with them about the possibility of creating a two-way SMS/MeshMS gateway, that would enable them to generate revenue from traffic that is delivered between their existing networks and Serval Mesh networks.  We might not be able to achieve anything by the end of the year in the immediate pilot, however we will keep exploring this, as it has considerable potential to help remote communities in Vanuatu and elsewhere.

Speaking of telecommunications service, where we were staying was about 15km out of Port Vila.  Voice calls were easy enough by mobile phone, but getting a usable 3G data signal was not easy.  We had to resort to putting my phone out in a plastic tub to keep out the rain and slobber (see below), in a vantage point where it had clear line of sight back across the bay to Port Vila. However, even then we were at the mercy of various atmospheric effectcs.  Internet would come and go on a minute by minute basis. In the end, we had to spend a lot of time camping in the offices of the lovely people at the TRR to make use of their reliable internet.



The box could stop the slobber of wet noses, but not being knocked about.


Here is a bit more context. The fruit on the tree are pawpaw.  Most mornings we had fresh pawpaw with our breakfast, very yum.


Here is the view from the house we stayed in down to the coast.  Port Vila is out of frame to the left.


And closer down to the coast:


The private stretch of coast was rocky, with lots of interesting little critters to see in the rock pools. There are many worse places to have to work.


Back up by the house, we setup one of the Mesh Extenders with a solar panel to do some testing, and took this little shot to give an idea of just how simple an independent Mesh Extender installation can be:


Then more meetings! This time with the organisers of the Smart ICT Sistas programme. We hope to involve this group that helps young ni-Vanuatu women to learn ICT skills in the deployment of the pilot, as part of our knowledge-transfer objectives.


Then it was time to meet with some folks we met through the Pacific ICT Days, who are planning to roll out a small telecommunications network on Maewo island.  This is one of those connections that could only happen because we were in-country.  They are already planning to put in a couple of 10m high masts, so have the ideal solution for mounting a Mesh Extender clear of the jungle canopy.

Alexis (far left) has been a real gem, helping us with all sorts of further connections, including the Ministry of Health, as well as being a key driver in this Maewo part of the pilot.  Here she is with myself, and a couple of the other folks who are part of that project. The mast sections in the background will be installed on the island, and were built largely with volunteer effort by someone who builds them for one of the local mobile operators.



A quick fit-test with a Mesh Extender revealed a (totally coincidental) perfect fit!