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]