More details about the Mesh Extender prototype PCBs

I have been asked if I can share the current design documents for the Mesh Extender prototypes, which of course I am happy to do.  I have also confirmed with RF Design who are our PCB design partners (they also make the nice RFD900 / RFD868 radios that we use), that we can share the current schematics as well.

Please remember that all of this information is provisional, and subject to change.

Any feedback and suggested improvements welcome.

The images below have all been uploaded at 300dpi, so click on the image to see in higher resolution.

Jumpers and headers

The first the silk-screen, showing the various connectors:

Note that the only LEDs on the unit at the moment are on the ethernet connectors, so take care in working out whether the unit has power or not. We may put an inline LED in the power cable to make it easier to see if it is powered up or not.  Adding LEDs to the injection-moulded housing would increase costs a lot, and make it harder to achieve the IP65/66 rating we are aiming for.

Going through the headers and jumers from left to right, 

1. Internet of Things / Mesh of Things Interfaces

O1 is opto-coupled input 1, O2 is opto-coupled input 2, and R is the relay-driver output.
I.e., there are two inputs and one output that have some sort of electrically protected interface for IoT/Mesh of Things type applications.

We have allowed some extra flexibility,  not just for during the development phase, on where they will actually connect, i.e., to the GPIOs on the radio module (R position), or to GPIOs on the Ath9k in the Domino Core module (D position).  For R, O1 and O2 the centre pin goes to the relay or optocoupler, and the jumper connects this to either (or possibly both if you had some strange need to do so) the radio module or Ath9k GPIO.  The final decision on which position we default to on shipped units will occur as we continue the development process.

2. Options for powering the device

VIN is for selecting the input power type as automotive (i.e. DC supply or lead acid battery connection) or solar panel input. 

Note to self #1: I'll have to check with RFDesign, if it possible for us to make this selection available on one of the external connectors, so that you don't have to open the unit to make this change.  We could, for example, lose one of CTS or RTS on the UART, in order to make this selection possible externally

For battery charging, you need to select the battery chemistry internally:
LiPO Sets the output charge voltage for charging a 2s LiPO4 battery (as there is no support on the charger IC for load balancing of the cells this type is not recommended)
LiFePO Sets the output charge voltage for charging a 2s LiFePO4 battery
Lead Sets the output charge voltage for the charging a 12V lead acid battery
We will likely make this default to LiFePO, or possibly Lead, but of course it can be easily changed by opening the unit and moving a jumper.


3. Connectivity and debugging

USB is the breakout header for the micro USB connector, in case people want to connect some other device to it.

JTAG is the programmer port for the Domino module.

By default, you need to have a cable on the DB25 connector, in order to tie the Radio and Ath9k serial ports together.  This is on purpose, as it allows for use of an external radio connected by a special cable, that can just re-route the UART from the Ath9k to the external radio.  This is how we intend to allow easy connection to HF radios, for example.  If for some reason you want to operate the device without a cable on the DB25, but still want to bridge the UART to the radio interface, there are some pads just above the DB25 connector that can be soldered to short-circuit the UART connection, so that it doesn't require a cable to complete the circuit.

Schematics

The main thing to note here are the pinouts of the DB25 and DB15 connectors.

These are subject to change! 

All six GPIOs of the RFD900 are exposed on the DB25 connector. These will be used by the radio firmware to check which regulatory domain it is in, and thus, what the allowed frequency and power level is.  It will also share this information (in the form of the 6-bit value) with the Ath9k, where it will be used to tell the firmware updater whether it is allowed to accept 3rd-party firmware or not.

As these values are supplied by the cable, it will be possible for research and development purposes to make your own cable that does not tell the firmware updater to block 3rd-party firmware, even if you received the unit with a cable for a regulatory domain where this is normally enforced.

Anyway, the current pinouts:

1. DB25 - Power and Radio connector

Going from left to right on the connector:

1 - GND

14 - GND

2 - RFD_IO2 (A GPIO from the RFD900/868 radio)

15 - RFD_IO6 (A GPIO from the RFD900/868 radio)

3 - RFD_IO3 (A GPIO from the RFD900/868 radio)

16 - RFD_IO1 (A GPIO from the RFD900/868 radio)

4 - RFD_IO4 (A GPIO from the RFD900/868 radio)

17 - RFD_IO5 (A GPIO from the RFD900/868 radio)

5 - Domino_TX_H (UART TX line on Ath9k module. Should ordinarily be connected to pin 18)

18 - RFD_TX (UART TX line on RFD900 module. Should ordinarily be connected to pin 5) 

6 - RFD_RX (UART RX line for the RFD900 module. Should ordinarily be connected to pin 19)

19 - Domino_RX_H (UART RX line on Ath9k module. Should ordinarily be connected to pin 6)

Note to self #2: Check if UART lines are around the right way here, or if we need to move them, to ensure that UART bridging can be achieved with just solder blobs between adjacent pins.

7 - RFD_RTS

20 - RFD_CTS

8 - Ath9k CTS

21 - Ath9k RTS

Note to self #3: Do we really need CTS/RTS lines, and are they also paired the right way around?

9 - Domino Ath9k GPIO0

22 - Domino Ath9k GPIO1

10 - Battery negative (-) pole

23 - Battery centre pole for two-cell configurations (Lithium batteries only?)

11  -Battery positive (+) pole

24 - Solar/Automotive power GND

12 - Solar/Automotive power positive (+) pole

25 - GND

13 - +5V

The UART connections to the Ath9k go through a TXB0104 level converter, making them 5V tolerant.

The +5V line (on both the DB25 and DB15 connectors) can be either used to supply a modest amount of power to some external device, or to supply power to the board.  Thus a minimal DB25 power connector would simply connect the +5V and GND, e.g., from a USB cable, and short the appropriate pairs of pins to connect the UART of the radio module to the Ath9k, and optionally short pins to GND or +5V as required to encode the appropriate radio regulatory domain.

2. DB15 Utility / IoT / Mesh of Things connector

Again, from left to right.

Note that on the prototype PCBs this connector is on the opposite side of the PCB to the DB25 connector.  This is not how it will be in the production units.  I expect that we will be able to re-route the connector without changing the pinout, but nothing is certain yet.

15 - +3.3V

7 - Opto-isolated input 1

8 - Domino GPIO14 (no protection)

14 - Domino GPIO13 (no protection)

6 - Opto-isolated input 2

10 - Domino GPIO26 (no protection)

13 - GND

5 - Domino GPIO27 (no protection)

2 - GND

12 - Relay P3 (The centre-pole of the integrated 5V relay)

4 - Domino GPIO17 (no protection)

9 - Domino GPIO15 (no protection)

11 - Relay P5 (The normally disconnected pole of the integrated 5V relay)

3 - Domino GPIO16 (no protection)

1 - +5V

It should be stressed that the GPIO lines on this connector have no electrical protection whatever, and connect directly to the Ath9k on the Core Domino module.  We have exposed them to provide the maximum flexibility possible with this device.

Regarding the relay: 

The relay itself is an IMC03, which is rated up to 240V and loads of up to ~60VA, and could thus potentially directly switch low-power loads, however, we would recommend using it only as a staging relay, to something larger externally, e.g., a low-cost automotive relay if you were planning on switching low-voltage equipment.

When the relay is activated (via the XLNA pin from the Ath9k, or the IO2 line from the RFD radio module), then pins 11 and 12 will be connected, or disconnected otherwise.  This facility can be used to drive higher-voltage relays externally, e.g., to actuate controllers of various kinds.  

I'll post more information about the Mesh Extender design itself as time allows.

In the meantime, it would be great if someone were interested in starting creating a page for the Serval Mesh Extender 1.0 to the OpenWRT hardware table, so that we can collect and maintain the appropriate information there, and look at creating a relevant target in the OpenWrt DD build system, as I'd greatly prefer if we can include the Mesh Extender in OpenWRT's supported hardware.

The new Mesh Extender Prototypes have arrived!

After DHL claiming that they couldn't deliver the parcel to our address here in Germany for "technical reasons," we finally have the two prototypes of the new Mesh Extender design.

As a reminder, this design is required for our AusAID grant to pilot Serval in the Pacific.  The new board is much easier to manufacture, and is designed to fit in a custom-designed housing designed to meet the IP65 or IP66 standard.  This is all being done on a shoe-string budget, in part because hardware always costs more to design than you expect.

Here is the side that accepts an RFD900 or RFD868 packet UHF radio, if it is being optionally included, which will be the normal situation.  The round thing is a 1F super-cap, so that the unit can shut itself down gracefully if the battery/solar power supply fails.  

You can tell it's a prototype by the yellow tape over one of the ethernet connector's pins, where we hadn't thought too hard about where the antenna cables would end up.  Also, the D-Sub 15 is on the opposite side of the PCB to the D-Sub 25 connector, when they should probably be on the same side. Hopefully these will be the worst issues we have to deal with.

You can also see the internal USB connector for holding a memory stick, or something else if you want.  We actually hope to not use the USB port, because of the myriad problems we have had using USB memory sticks on battery-powered Mesh Extenders.  Basically the power consumption is too high, the performance is horrible, and the memory sticks get easily corrupted, or even die, if they lose power at the wrong time.

Below you can see both sides of the PCB.  Here the two internal ethernet jacks can be seen, which face downwards, so that cables can be routed inside the water-proof case.  We won't by default be providing external routing for those cables, as they are not normally needed in a Mesh Extender.  We figure that people will just drill holes in the cases in convenient locations if they need ethernet.  Not ideal, but given our extremely limited budget, it was the best we could manage.

The D-Sub 25 connector has 5V in, as well as 9-26ishV input, which can come from a car or truck plug, or from a solar panel.  That is, you can connect one of these to a suitable naked solar panel, without needing any interface circuitry.  Similarly, there are three pins for connecting a 2-cell LiFePO4, LiPo or sealed lead-acid battery.  The multi-chemistry battery charger is included in the unit.  

Dealing with EU Directive 2015/53/EU and potential unhelpful FCC rules

The D-Sub 25 also has device identification pins that are intended to allow the unit to work out which countries regulations apply, to control allowed transmission frequencies, and if required by FCC rules or EU directives to prevent the installation of third party firmware, that this can be done without any DRM locks. That is, by building a "research and development cable," the device will always be able to accept 3rd-party firmware, but when used with the default cable for a country that requires it, will only accept firmware updates that we have signed.  

We have talked about this solution to mis-regulation in a few different places, and understand that it isn't perfect, however, given our pragmatic requirements, it seems the least-bad option available to us.  We are always interested to hear people's thoughts on how we can improve on this, and of course people are always free to make their own firmware that follows their own policy, instead of this one.

This issue might become more important in the near future, if low-cost wireless routers start coming firmware locked due to these counter-productive regulations.

Getting down to business

So now I need to start qualifying these boards, so that we can confirm to our design and manufacture friends when it is safe to finalise the design, and manufacture the units we need for our pilot in the pacific.

There are a number of steps that we need to cover here, and that I would welcome assistance with, including:

1. Bringing the units up for the first time

2. Making the microSD slots work

The boards have two microSDs, because we don't know which method will work with the Ath9k chipset. One is connected to an SPI bus, which would be the preferred option, but may require some careful control of that bus, as it may have other devices connected. The other is connected via GPIOs to the Core Domino module, which should be fairly easily supportable by the Linux GPIO SPI/SD card kernel driver, although performance is likely to be poor.  We are very keen to get at least one of these options working, so that we can avoid all the horrors of using USB that I have described previously.

3. Building Serval Mesh and Mesh Extender packages for the Core Domino, and testing.

4. Porting our firmware patches for the RFD900 radio to the European version, the RFD868.

5. Testing the solar and battery controller interfaces.

6. Testing the ethernet interfaces.

7. Building and testing power cables, including the region identification and regulatory satisfaction functions.

8. Adding support for the super-cap to cleanly shut the thing down when power is lost, and characterising the super-caps performance. Added bonus: Abort shut down when power is restored during the shutdown process.

9. General integration testing for the whole Mesh Extender software suite

10. Help us develop the remaining functions required for the AusAID Pacific Pilot.

Anyone who is willing and able to contribute to these efforts would be greatly appreciated.

There is the practical limitation that we have only two prototypes, and that they need to stay with me here in Darmstadt, Germany.

That said, if anyone is interested in buying their own prototypes to assist in the process, I would be happy to facilitate this, however we don't have funds to subsidise this process at the moment, and because they are being built as prototypes, we would expect that they will be relatively expensive.  However, if we get enough orders to get a batch made at once, we can look into that.

Related to that, at this stage it would seem reasonable to expect that the prototype boards will be able to fit into the final custom injection-moulded cases that we are getting designed, to allow use of the prototypes outdoors in the future -- although nothing is certain until it happens.

Exploring the legal situation of disaster communications networks

I'm currently based in Darmstadt, Germany for a few months with the nice folks in the Secure Mobile Communications laboratory (SEEMOO) at TU-Darmstadt.

One of the main things that we are looking at while I am here, is to better understand the current legal situation facing networks like Serval.

This is important, because the telecommunications laws in most countries were made before such networks were beginning to be widely considered.  As a result, the particular characteristics and requirements of these networks are typically not accommodated in the telecommunications regulations of most countries (or at least the ones we have looked at so far).

So we are hoping over the next month or so to compare the situation here in Germany with Australia, and perhaps a few other countries, to see what road-block might be there, and perhaps to propose how such legislation could be amended to better facilitate them.

As a result I have spent much of the last week reading through the EU Directive 2014/53/EU (in both English and German), as well as draft legislation to implement it in Germany and Austria.

There are some points of concern that we have, particularly that open-source development using wireless routers and SDRs would effectively be outlawed, if the legislation is not carefully worded.  This would be a very unfortunate outcome, not just for the open-source communities who volunteer their efforts and donate the results of their efforts to the common good, but to society as a whole, who would be denied the benefits of these activities (most wireless routers are based on a version one of the open-source projects, very often OpenWRT) because modifying the software on a router to patch a security fix would also be illegal, and router vendors could be required to lock down firmware on the routers to prevent it being patched, updated or replaced in the first place.

This all echoes some of the same problems that are coming up in the USA, with the FCC's proposed rules to require firmware-lockdown on routers.

As we have seen with the confusion there, including TP-LINK being fined for locking down router firmware by the FCC, the matter is not a simple one, and certainly it is one that there still seems to be an understanding gap that we need to help regulators bridge, so that they can be enabled to enact regulations that protect these important rights, while addressing other legitimate social and political concerns.

Bridging Rhizome over HF

I'm currently up at Pacific Endeavour in Brisbane, which is a multi-national defence and civilian humanitarian and disaster response interoperability exercise, attended by, among others, the military of 22 nations around the Pacific basin.

We have been talking with Codan for a while about integrating Serval with their HF radios to allow Rhizome-based services over HF distances.  The goal is to allow MeshMS and our (still being written) Mesh-based social media applications to be carried over HF-distances (kilometres to hundreds of kilometres) between more localised concentrations of Mesh Extenders equiped with Wi-Fi and UHF packet radios.

This is of direct interest for our AusAID/DFAT grant to pilot Serval in the Pacific, where the beneficiary nations typically have small populations on islands separated by tens to hundreds of kilometres.   If we can link distant islands, then we can provide national and regional level communications, subject to the limitations of HF radio bandwidth (typically in the bytes to tens of bytes per second, although hundreds of bytes per second is possible in principle).

As part of the Pacific Endeavour, exercise the folks from Codan, Barrett and the other HF radio vendors are here.  The folks from Codan and Barrett in particular have been super helpful and enthusiastic as I have been explaining to them what we are trying to do, and how, to me at least, it seems to create the potential for new markets for HF radios.

They have kindly provided me with access to radios and documentation that they have with them, so that I can attempt a code sprint to establish two-way packet communications between their radios. That is, my goal is not just to prove that Serval Rhizome can run over HF radio, but that we can do it between what I understand are the two largest vendors in the humanitarian and disaster HF radio space.  Here is my setup with the Barrett radio (the black one on the desk) and the Codan radio (on the floor next to me):

After some false starts with having the correct firmware on one of the radios, I was pleasantly surprised to find that I was able to establish basic packet communications after only about ten hours of work.  Here you can see a packet being received, and a peer being detected by LBARD (the Serval Mesh program for handling slow radio links):

As the messages above show, LBARD knows what brand the radios are.  

This is partly out of necessity, because the serial control interface is quite different on the two radios, but also because we know if we are linking radios produced by the same vendor, that we have the potential to use higher-speed communications options.  

But between vendors, we currently have to use only inter-operable standards, which when it comes to HF radio means the older version of the Automatic Link Establishment protocol.  This is a bit unfortunate, because the interoperable ALE 2G standard is really slow.  The native data rate of ALE 2G is only 375 bits per second to begin with.  There is some protocol overhead, which reduces that somewhat.  Then we discovered that some radios don't support the full ASCII-64 restricted character set specified by the ALE 2G standard, and as their documentation claims. In particular, most of the punctuation characters in the ASCII-64 character set actually cause the message to be truncated on some of the radios.  This means that we can only use hex encoding, which means that we are consuming 2x 6-bit characters to encode each byte, i.e., 12 bits per byte. This reduced bandwidth by a further third.  Then there are a number of other losses relating to slow turn-around from TX to RX and back again, the need to fragment messages into 43 byte pieces to fit into the short ALE 2G AMD message limitations, all of which together reduce the effective bandwidth to perhaps 10 bytes per second.  Fortunately LBARD was designed to handle such slow links.

(We also found that some versions of firmware on some of the radios wouldn't receive ALE AMD messages sent by the opposite vendor, although we think that particular problem has been corrected in the latest version of firmware, so the problem is manageable.)

Naturally, we would much prefer to have higher speed connections, including the ALE 3G standard, that allows for up to 1KB/sec under ideal conditions, and without the need to fragment packets, which further saves on the TX/RX/TX turnaround cycle.  Unfortunately not all HF radios support ALE 3G.  That said, we will add support for radios that have it, and thus need to know if the remote radio also supports it -- thus another reason to know the vendor and model of the remote radio.

Higher-speed HF modems are also available, but are rather expensive.  Thus we are contemplating designing a low-cost HF radio using a cheap Spartan 3 or 6 FPGA for DSP, and attempt to implement something compatible with one of the existing HF modem standards (since they have done the hard work of knowing which modulation schemes are actually sensible on HF), that can be part of a Serval Mesh Extender HF adapter, to allow similar practical performance to the way that we are using the RFD900 UHF packet radios.    The RFD900 is actually much faster natively, but we are using it in an ad-hoc manner to allow many radios to be in range of each other, thus limiting each transmitter to ~0.25 - 1KB/sec.  For HF links, we are using 1:1 direct links, so that the best channel and modulation can be used, and thus we can use a simple TDM or equivalent scheme, that allows us to utilise a channel fully.

After getting everything working on ALE 2G, here is our Codan / Rhizome gateway (running from my laptop), and using this Codan "manpack" radio:

And the Barrett / Rhizome gateway, which I have yet to setup for the demo, will use this radio, a Barrett 2050:

So now I just need to update the version of OSX on the 2nd-hand Mac I just bought down the street, so that I can run this updated version of LBARD on it, and show it all running during the demo session this afternoon.  

But in the end, we have reached a significant milestone in that we have a proof-of-concept of near-real-time Serval communications over hundreds of kilometres, by using HF radios.

Prototype replica bush-telegraph insulators

A little side project we have been looking at is using Serval to support tourism activities in regional and remote Australia.

The idea is that we want to create infrastructure-independent communications nodes at points of interest around Australia, that together we would call "The New Bush Telegraph" or "The New Overland Telegraph."  

Each station would consist of a replica bush telegraph pole, preferably manufactured in regional Australia (more on that in a moment), that has a variant of the Mesh Extender that can serve tourist information via Wi-Fi, and be itself updated via the Serval Mesh, so that the maintenance of the system is as simple as possible.

We had a student work on part of this earlier this year, working out what dimensions we would need for the replica insulator, so that it could fit the necessary electronics (Mesh Extender + batteries) inside, to keep them out of the weather.

We then contracted the Pilliga Pottery to make the prototype earthenware insulators.  The Pilliga Pottery are themselves a regional/remote Australian business, and are also the largest pottery in Australia -- so they were a natural choice for us to work with.  I had also seen some of their work during a family holiday last year, so I knew that they could do the kind of work that we were looking for.

Anyway, while I was away in Samoa and Arkaroola on work trips, the prototype insulators have arrived!

Here are our two nice boxes direct from the Pilliga Scrub (fortunately the dingrel didn't get them):

You can tell it has come from regional Australia, because it is tied with bailing twine:

And padded with egg cartons from Coonabarabran:

Finally we got down to where our new insulators were hiding:

We had told the pottery to choose whatever colours and painting they wished, so it was a moment of surprise to see what colours they had chosen:

Well, it looks like they have given us three quite different and interesting colours.  This is really nice, because we want each station to be distinctive, to add a further bit of interest to the stations.  Here they all are lined up on our bench:

So the next step is to get some poles, hopefully made by Arrium Steelworks in Whyalla, solar panels and electronics, so that we can make complete prototype units. This will be much easier once we have the new Mesh Extender prototypes, that should include solar regulators and LiFePO4 battery charger circuits (more on that in another blog post), and might need to wait until we have a student to continue to drive the project forward.

Mesh Extender Mark-II design progress

Again a rather short post, just to say that we are working with our contractors on the PCB and case design for the new generation of Mesh Extender prototypes that we will use in the Pacific next year, and likely in a variety of other places as well.

Together with everything else, this has me rather busy at the moment, so apologies for the lack of pictures and detailed information just yet.

Hopefully in a couple of weeks I will be able to share some of our design notes, to give you an idea of what we are hoping to build.

One big challenge is to make something that is both cheap, and sufficiently rugged to endure tropical maritime conditions in the pacific, and the boiling hot / freezing cold and very dusty conditions of the Australian Outback.

Another challenge is working around the short-comings of the USB mass storage capability of the Atheros 9311 SoC, for devices like the Mesh Extender, where power could be cut at any moment without notice.  This rather upsets some brands of USB memory sticks, potentially causing them to go read-only forever.

MeshMS over 4km via UHF

Another short post as I try to get on top of everything at the moment to say that on our last trip to Arkaroola we successfully tested the UHF packet radio functionality over a distance of about 4km.  This was from the observatory ridge to Coulthard's Lookout.

With the setup we were using, we had about 50% packet loss, and jet LBARD kept persevering, and delivering MeshMS messages within a minute or so.

We did see a recurrence of a bug affecting a corner case of LBARD operation, where sometimes you have to send a 2nd message to flush out a stuck first message.  However, this should not be too hard to fix.

This weekend I fly out to Samoa to meet some folks there to talk about our AusAID / Pacific Humanitarian Challenge grant to run a pilot using Mesh Extenders there, and it will be nice to show off the UHF functionality while there.

Rhizome over ad-hoc UHF is FINALLY working

 As many of you will already know, we have been working away in the background on getting the RFD900 radios working in something that approximates ad-hoc mode on Wi-Fi, but using the ISM 915 MHz band, so that we can have Mesh Extenders communicate over long distance, without any limit on the number of Mesh Extenders, and without them having to be in specially paired groups.

FINALLY at 4am this morning I fixed the remaining bugs that were stopping this from working in most cases.  There are still a few little niggly issues of course, but it is now working.

Together with some work-experience students, we have tested the units in and around the lab today.

First, we set one unit up on the bench in our lab on the fourth floor, together with an Android tablet running Serval Mesh that could receive MeshMS messages, and therefore cause automatic delivery acknowledgements to be pushed back to the message sender.

We then went for a wander with another Mesh Extender and a phone, and sent messages to the tablet, and waited for delivery confirmation to come through.  This typically took a couple of minutes, although in many cases the MeshMS text message itself is delivered in about 15 seconds.

Here we are one floor down from the lab:

And then two floors down.  Note that our building has 1/2 metre thick concrete floor decks.

And yet another floor down:

 And a bit closer in on the same floor:

And then down on the first floor -- with three thick floor decks between us and the Mesh Extender.

We also went outside on the ground floor under the metal main assembly building roof, and saw radio packets, and the units attempting to transfer messages, but no messages came through.  We think that the bundle synchronisation process needs a bit of help when faced with >50% packet loss.  This should be quite possible to achieve.

Then we went to a local supermarket to buy lunch, and took the Mesh Extenders with us.  One stayed in the car in the underground car park, and the other we took with us into the shopping centre.  Here is our Mesh Extender in its special shopping centre disguise vehicle:

This was quite nice, with one of our work experience students sending text messages down to the car park, and receiving delivery confirmations in the supermarket.

So, in other words, it lives!  Hopefully we will have more updates soon, as we start testing the resulting capabilities more thoroughly and in different contexts, particularly outdoors.

Mesh Extenders for the Pacific

Recently we were named a winner in the Pacific Humanitarian Challenge, receiving a grant from the Australian Department of Foreign Affairs to undertake a pilot of the Serval Mesh in one or more Pacific nations.

We're now starting to get underway in our planning for this, in particular, how we can make the Mesh Extender easily manufacturable in reasonable quantities (we need about 100 for the pilot), and as robust and reliable as possible, without making it too expensive.  Of course, we know that at these small quantities, the cost will still be much higher than we would like.

We have begun talking with our good friends at RFDesign about making an all-in-one Mesh Extender PCB, including both RFD900X + Atheros 9k based embedded Linux computer.  I think we have some good ideas about how we can go about that within the budget constraints of this project.  In many ways, this is the most important part, because it simply isn't realistic to hand-build 100+ Mesh Extenders the way that we have been prototyping them so far.

A picture of an injection moulding machine (Cjp24 CC-BY-SA 3.0), because this post was too boring with just text.

One of the really interesting ideas we are exploring is including a solar and battery controller in the unit, so that you can just plug in a solar panel, car battery or other supply to run the unit, in addition to the normal 5V USB supply.  You would then also be able to connect two LiFePO4 cells, that the unit would charge from the supply, and use to operate when there is no power supply available.  We have yet to work out what impact this will have on the cost, although at this stage, the RFD900 radio is by far the single most expensive component, so we are hopeful that we can make it fit.

I have also been introduced to the world of injection moulding through a helpful colleague here in the department.  Together with a local injection moulding company, we think we have found a way to get full-custom polycarbonate injection-moulded cases designed and manufactured at a relatively affordable price.  We are currently aiming for IP65 or IP66 rating for the case, so that it can be safely used in dusty outback conditions, as well as in tropical maritime climates.

However, injection moulding is not cheap, so "relatively affordable" is still code for "will stretch our budget to the very limit".  Our current estimate is that it will take at least AUD$30,000 for us to get the tools designed, built, and then squeeze out several hundred complete cases.  Given that it was previously looking like $50,000 to just get the tools made, and then only being able to do large production runs, this is a huge step forward. Also, with the injection moulding company being within easy riding distance, and being able to do very small production runs, and pick them up in beloved my cargo bike, this all spells good news for the Mesh Extender being able to be turned into a real, purchasable product, with some very nice characteristics and capabilities.

There are some other hurdles to jump through before we would be able to offer it as a complete product, including regulatory certification from the FCC and our Australian equivalent, and ideally, also EC approval from Europe.  Given the current shenanigans with the FCC, TP-LINK and locking down router firmware to prevent undesired 3rd-party access, we are thinking very carefully about how we can avoid that whole problem, but still have common hardware between the totally incompatible US/Australia/New Zealand/Canada versus Europe radio bands that we need to use for the UHF radio.

One approach that we are thinking about is having the power/data cable that feeds the Mesh Extender be wired differently for each regulatory domain.  That way, the firmware and everything can be completely common, and the radio firmware can simply probe the cable to work out which bands it should be operating on.  Given that owners of Mesh Extenders are likely in many cases to be internationally mobile, especially when trying to respond to disaster events, we think that this is a sensible approach.

We would also likely have another cable wiring that would tell the unit to accept unsigned firmware, so that people who wish to replace the firmware and experiment can do so, but there would be no risk of someone accidentally flashing the unit with firmware that would make it operate outside of authorised bands.

We understand that this whole area is a rather sensitive one for all of us in the open-source community, so we invite your feedback on whether what we are proposing in this regard, and whether there might be any better ways of doing it, without risking the FCC of EC folks refusing certification.

Also, I'll be picking the brains of some other folks who have created open-source consumer products to try to find out about and avoid any likely hazards along the way.  If you have any wisdom or experience to offer here, it would also be very welcome.

Paul.

Serval Mesh 0.93 Released

After much too long, the next official release of the Serval Mesh app for Android has been released on Google Play.

This includes many, many bug fixes incorporated during that time, and also the following major improvements:

• Greatly reduced power usage, particularly when no peers are present. In previous versions of the software, a CPU lock would be held whenever the software was enabled and connected to a viable Wi-Fi network. This would completely prevent the CPU from suspending, draining the battery in a matter of hours. In this release, Android alarms are used to wake up the CPU, holding a CPU lock for only a short time. While there are still improvements to be made in this area, the software may be able to remain enabled and connected to a Wi-Fi network without significantly impacting battery life.
• Bluetooth has been added as a usable network transport. The addition of bluetooth support has the potential to greatly simplify the process of discovering and connecting to other phones.
• Better support for more recent versions of Android. Android 5.0 requires that native binaries are compiled in a way that isn't supported on version before 4.1. So we must now include 2 sets of compiled binaries.
• Improved user feedback while networks are turning on and off.

You can read full release notes at:

 https://github.com/servalproject/batphone/blob/master/CURRENT-RELEASE.md,

and get the app itself at:

 https://play.google.com/store/apps/details?id=org.servalproject

The Australian Prime Minister used Serval this morning

Today we had a surprise visit from our Prime Minister to the University to make some announcements of local importance in the lead up to the election.  He also made a brief tour of a couple of research labs, including ours, at the suggestion of the University.  The end result: The Prime Minister and I had a short exchange using MeshMS on the Serval app:

And the result:

Not how I was expecting this morning to be, but very nice all the same.

Pacific Pilot is Go!

[Deutsch unten]

The announcement was made today by the Australian Minister for Foreign Affairs and Trade, that together with our long-time partners in New Zealand Red Cross, and our collaborators in Germany at TU-Darmstadt and Philips University in Marburg, our submission was one of the five grand winners of the challenge, and we now have funding and mandate to undertake a pilot in one or more pacific nations over the coming year:

http://foreignminister.gov.au/releases/Pages/2016/jb_mr_160506d.aspx?w=tb1CaGpkPX%2FlS0K%2Bg9ZKEg%3D%3D

Together with our existing grants from Radio Free Asia, and the NLnet Foundation, this means we have a busy few months ahead as we implement a number of technical and user-interface improvements, so that we are ready for the pilot, beginning most probably in the new year.

This is needless to say a very existing development, and it would not have been possible for us to reach this point without the continuing and generous support of so many people and organisations.

Und auf Deutsch...

Endlich war es angekündigt bei unsere Ministerin des Außenpolitik und Handel, dass zusammen mit NZ Rote Kreuz und TU-Darmstadt und Philips Universität Marburg, wir sind einer der fünf Gewinner des „Pacific Humanitarian Challenge.“ Das heißt, dass wir haben Geld für eine Pilotstudie in ein Pazifik Land.  Wahrscheinlich wird das früh 2017 sein.  Die Pressemitteilung ist hier:

http://foreignminister.gov.au/releases/Pages/2016/jb_mr_160506d.aspx?w=tb1CaGpkPX%2FlS0K%2Bg9ZKEg%3D%3D

Wir haben schon Zuschüsse von NLnet Foundation und Radio Free Asia.  Ingesamt heißt das, dass wir haben dieses Jahr viel zu machen! Wir werden beide Technische und UI Verbesserungen und auch mehr Arbeit auf unsere iOS Fassung.

Natürlich haben wir hier nicht allein bekommen. Sondern sind wir hier nur durch die Hilfe von viele Leute und Organisationen.

Making self-updating APKs

Serval Mesh is designed to operate without infrastructure.  This makes over-the-air updates for it "interesting," because we cannot rely on the internet and Google Play being available, either because the network is broken, or because Naughty People are preventing others from accessing Google Play or installing Serval Mesh specifically.

We have had a solution for this for a while, where we attach the signed manifest to the end of the Serval Mesh APK, so that it can certify to other phones running Serval Mesh, that it is indeed a legitimate update.  That way, the APK can distribute via Rhizome, and each phone receiving it will announce "update available," which then allows the update to be install.

The trouble is, that sometime before Android 5.1.1, Google have stopped allowing APKs to have random stuff attached to the end, presumably for security reasons. After all, we have been bending the ZIP file specification to do this.  Also, we can't just include the manifest inside the APK, because that would change the signature required for the manifest, and so it would never be valid.

Fortunately, ZIP files support the inclusion of comments, which are not included in the Jar signing signature -- so we can put our manifest in as a comment, without it upsetting the signature.  That is, the APK will install on a phone, whether or not the manifest is in there.  Once installed, we can then pull out the manifest, so that the APK can be inserted into Rhizome with the manifest that certifies it is a genuine update of Serval Mesh.

In short, we now have a nicer solution than we had before, and which follows the ZIP file standard completely. Needless to say, we are very happy about this.

... and Serval is a first-round winner of the Pacific Humanitarian Challenge

See: http://pacifichumanitarianchallenge.org/announcing-top-10-first-round-winners

This is a challenge posed by AusAID, the Australian International Aid agency to help Pacific Nations following disaster and emergency situations.

Together with NZ Red Cross our proposal looks at making Serval operationally ready and in use in Pacific Nations to help people stay connected when cyclones and other disaster strikes.

Succinct Data pilot in Fiji

While we have been quiet lately, we haven't been idle.  Quite the opposite. The last few weeks we have been working on getting Succinct Data operationally ready for use by NZ Red Cross, which we have now succeeded in doing, as explained in the press release with Magpi below.

http://home.magpi.com/media-room/magpi-satellite-communication-integration/?utm_content=bufferb8735&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

This has only been possible because of the generous support a grant from USAID, and the assistance of the folks at both Magpi and VasTerra.

TP-Link Firmware Lockdown and Alternative (Better!) Hardware for Mesh Extenders

TP-LINK are starting to lock down the firmware on their routers.  This is a bad idea, because it means that there will be more and more routers out there that have horribly out of date and vulnerable firmware, that cannot be updated and secured by end-users, or in our case, re-purposed to meet their individual and/or humanitarian needs.  This is rather sad.

Fortunately, there are manufacturers making what are basically souped up clones of the cheap TP-LINK routers, such as the WR703N and MR3020 that we have been using for the Mesh Extender prototypes.

One that has caught our eye is this one:

https://wiki.openwrt.org/toh/gl-inet/gl-ar150

Which you can buy from places like this:

http://www.aliexpress.com/item/GL-iNet-6416A-150Mbps-802-11g-b-n-SMART-Mini-WiFi-Wireless-Router-OPENWRT-ENGLISH-Firmware/32273181856.html
http://www.aliexpress.com/item/GL-iNet-AR-150-150Mbps-OPENWRT-Firmware-Mini-Routers-Wi-Fi-Router-WiFi-Repeater-Booster-Extender/32464052719.html

It comes with OpenWRT DD 14.07 pre-installed, has 64MB RAM (instead of 32MB in the MR3020) and 16MB FLASH (instead of the tiny 4MB on the MR3020), has the serial port already with a header on it (unlike the fiddly soldering process on the MR3020), and also has a few GPIOs on the same header (none on the MR3020), and has two ethernet ports (instead of one on the MR3020).   Oh yes, and if you don't mind paying an extra US$5, which still brings the price to only almost what an MR3020 costs), you can have an external Wi-Fi antenna, which will be sure to increase the range compared with the PCB antennae on the MR3020 (which we hope to verify soon).

In short, it is at least as good, if not better, on every technical measure when compared with the MR3020 and WR703N, and they are also cheaper! In fact, we can get the external antenna version express international couriered via DHL from China for less than we have to pay for an MR3020 via ebay in Australia!

Further, with the extra flash, we should be able to make a Mesh Extender install package set that can just be installed on it, because there is actually enough room in the flash for servald, lbard and the various scripts and things we need. Combine that with the fact that we have a real physical header that we can use to connect between the RFD900 radio and the router PCB, avoiding the need for any soldering at all*, the physical assembly process is now greatly simplified. This makes us very happy about the prospect of making Mesh Extenders easier to build and provision, including for people who aren't big on soldering.

All we will need to have is some special little cable made that goes between the headers on the PCB, and the RFD900 radio, and an updated case design.

Now, about that little * about "no soldering", the only problem we have remaining is that the headers which come on the board don't have a 5V line populated, so we will still need to solder a header on, assuming that the Power-Over-Ethernet header has access to the 5V rail, which seems like a reasonable prospect.  We will take a look at this when the 5 units that we have ordered have arrived. In any case, soldering on just a header is not a big problem, and we might even be able to ask the manufacturer to prepare a batch with the header fully populated.  Likewise, we can probably ask some company in China to make up the little adapter cables that we will want to go between the radio and PCB.

We wouldn't have found these units if TP-LINK weren't being unhelpful with their firmware lockdown policy, so in this particular case it is a clear example where being unfriendly to the open-source will result in

Running Serval in the Core Network Simulator

I've just been visiting the NICER project folks in Darmstadt and Marburg in Germany, where they are starting to use Serval for various parts of their research.  They have a really nice approach to the work, which is quite complementary to what we are doing.  One of the things that they have done recently is to work on simulating various Serval networks.  In the linked post below, the describe how to simulate Serval using the Core network simulator.

http://otg-living.blogspot.com.au/2016/01/running-serval-in-core-network-simulator.html

autoconf AC_PROG_JAVAC possibly undefined macro

Some folks are occassionally hitting a problem where they receive an error similar to the following when they try to run autoconf on the serval-dna repository (or indeed other software):

autoconf AC_PROG_JAVAC possibly undefined macro

This is extremely annoying, and doesn't really give any clues as to the cause.  A bit of googling reveals that this can be fixed in most cases by running:

autoreconf -i

Then autoconf should be able to be run without further problems.