Tuesday, February 2, 2016

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

Tuesday, January 19, 2016

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.

Sunday, December 13, 2015

Getting rid of the Offers4U ad-ware track-ware on Mac

Offers4U is an annoying ad-inserting thing for browsers that pops up large annoying "offer suggestions" and other junk when browsing the web (which also implies that it is taking a bit too close a look at your browsing activities..).

There is plenty of information about how to get rid of it on Windows, however there wasn't any clear information on how to get rid of it from Chrome on a Mac.

After a little exploration I found that it is part of the seemingly-unrelated "SafeFrom.Net helper" that claims only to be a tool to make it easier to download videos from youtube and other streaming sites.

To get rid of it, open chrome://extensions/ in chrome, and then disable the SaveFrom.net helper extension.  I guess if you still want to be able download from youtube and other places (e.g., if you lost the original of a video you uploaded some time ago), then you can turn the extension on, open a new tab, and then disable it again after completing the download.

Thursday, December 10, 2015

Working on Mesh Extender firmware

I've been working on various aspects of the Mesh Extender firmware lately.

There are now a bunch of configuration options you can set by putting text files on the FAT partition of the USB memory stick.  This makes it fairly easy to set the configuration in the field, but putting the USB stick into almost any computer.  Gory details for them are on github, but I'll introduce a couple of fun ones now.

otabid.txt lets you specify a Rhizome Bundle ID (BID) that will be assumed to contain over-the-air updates.  Together with the over-the-air-updates/bootstrap program in the mesh-extender-builder repository linked above, this creates a nice easy way to update the main Serval binaries and configuration files on a Mesh Extender.  While this facility was designed to help with the development process, it will also come in handy for general software updates.  By setting the BID to a BID of your own choice, it is possible to have separate groups of Mesh Extenders that get updated separately, so that you can, for example, maintain separate development and production devices.

The second file is monitor.sid, and works with the above so that you can get a Mesh Extender to send a MeshMS message to someone whenever they apply an over-the-air update.  The message contains the GIT commit of the mesh-extender-builder repository that built the over-the-air update, thus providing you with a nice easy way to keep track of which Mesh Extenders have which version of what.

Sending the MeshMS was pretty easy, as we have a nice command line interface for doing so. The only real magic is getting the SID of the Mesh Extender, which we do with a nested shell command to get the SID out of Serval's keyring structure.  Here is the complete bit of code that sends the MeshMS, if monitor.sid exists.

# Now send a MeshMS to whoever cares about this mesh extender
if [ -e /dos/monitor.sid ]; then
  RECIPIENT=`cat /dos/monitor.sid`
  COMMIT="GITCOMMITSTUFF"
  /serval/servald meshms send message `/serval/servald keyring list | tail -1 | cut -f1 -d:` ${RECIPIENT} "Over-the-air-update installed on this mesh extender: git ${COMMIT}"

fi

What was really nice was that this worked first time.  Once I got the SID out of my phone, and put it on the Mesh Extender, and pushed out an OTA update, I had a MeshMS within a minute or so that looked like this:


Note that the timestamp is the creation time of the OTA update, not the time it was applied.

Also, note that these OTA updates are pushed out over the Serval Mesh itself -- the Mesh Extender has no internet access.  In other words, we now have a nice facility that allows us to update Mesh Extenders in the field, without any supporting infrastructure, and with enough feedback so that we know which devices have been updated to what version.

Wednesday, November 25, 2015

RFD900+ now supported by flash-rfd900 utility

We have a bunch of the newer RFD900+ radios, which have 1 - 2 dB better receive sensitivity than the older RFD900/900a (no plus) versions of the radio.

However, we were previously unable to use these in Mesh Extenders, because we couldn't flash them using our little C utility that we wrote for flashing them on Mesh Extenders.

Using the officially supported flash utility was not an attractive option for us for a couple of reasons: (1) it requires all sorts of dependencies, like python, that ended up adding something like 200MB to the Mesh Extender image, which is normally ~50MB; and (2) it wasn't as fast as we would like.

Our flash-rfd900 utility (https://github.com/servalproject/flash-rfd900) worked fine on the old RFD900 / RFD900a radios, but seemed to brick the 900+ radios.  Some very helpful insights from the folks at RFDesign revealed that the new radio uses 24-bit addresses in the bootloader, instead of 16-bit ones.   The intel hex program file can also contain type-04 records in addition to the usual type-00 records that contain the actual data. Type-04 records indicate which 64KB bank is being addressed, and are necessary for the RFD900+ which has an upgraded micro-controller that has 128KB of program flash, and twice the RAM resources of the older radios.

Adding support for these two features was fairly simple, and after that flash-rfd900 is now working for the RFD900+ radios, so we can finish getting the Mesh Extender firmware image to work with that model of radio.

Wednesday, October 21, 2015

Debugging RFD900 Ad-Hoc UHF behaviour

So I am getting closer to having working ad-hoc UHF communications between Mesh Extenders with RFD900 family radios running our custom CSMA firmware (not that for now you need a spectrum license from your local regulator to do this at >3mW in most countries).

Now I am debugging why MeshMS messages are not being delivered in reasonable time. It seems that lbard is not making the most sensible choices in terms of which piece of which bundle to transmit.

However, I need a nice way to see what it thinks it is transmitting, without having to stop lbard and run it in debug mode, which of course loses the accumulated state in lbard, and thus might cause the bug to disappear.

To address this, I am implementing a function to dump the current state of lbard in HTML so that it can be read wirelessly using the web server on the Mesh Extender to serve it up.  This will show the calculated priority of the bundles on each node, as well as their information about neighbours and in-progress transfers from neighbours.  Hopefully with that I will be able to track down the remaining priority bugs quite quickly.

Sunday, September 20, 2015

Shaking the bugs down with ad-hoc communications via RFD900

Last week I was up at Arkaroola again working on getting the Mesh Extenders to communicate via the RFD900 radios running my new CSMA firmware using our new spectrum license that allows us to avoid frequency hopping at (relatively) high power levels.

The CSMA firmware itself had very few problems to be solved.  The main change I made was introduce a couple of escape sequences to allow setting the power level of each packet to either low (requiring no spectrum license) or high (requiring a spectrum license).

This was part of a general effort to make the power level easily controllable so that I could set the Mesh Extenders to either "normal" or "Arkaroola" mode, without having to reflash them.

In the end, I implemented two tests that the Mesh Extenders perform before sending a packet at high power: First, the file "HIPOWER.EN" must exist on the USB memory stick on the FAT32 partition, and second, the slider switch on the MR3020 PCB must be set to the middle position. If either of those are not set correctly, then packets will be transmitted at low power.  Thus I can either replace the contents of the USB memory stick, or slide the switch to disable hi-power mode when I return from Arkaroola.  Ideally I should modify the lid design of the 3D-printed case so that I can access the slider switch without unscrewing it, but that's really just a matter of convenience.

So after fixing that, and having a frustrating day while I realised I was using the wrong binary for the RFD900 radios, I managed to send a MeshMS message between a pair of Mesh Extenders operating in this way.  There are still some scheduling bugs in LBARD that prevented the confirmation reply from getting back to the sending phone. I also have a list of other relatively minor issues to work through to get it all operating stably, all of which I hope to work through this week ready for the next trip to Arkaroola, where I hope to be able to operate 8 or more Mesh Extenders together using the RFD900 in this ad-hoc mode, and to be able to send and receive MeshMS messages over a fairly large area.  This will be very satisfying and a significant step forward if I can achieve it.