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.

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>

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.

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.

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.