Comparing energy consumption of candidate Mesh Extender components

I am trying to design the 2nd generation Mesh Extender prototypes.  These will still be prototypes, and budgetary and time constraints mean that we will need to use off-the-shelf hardware for the most part.

Two of the goals are to reduce the size from bucket sized to book-sized, and to weigh less than a kilo-gram, while still preserving at least 24 hours of run-time. A third goal is to use a much faster CPU so that verifying signatures on Rhizome bundles no longer takes tens of milliseconds.

This introduces a tension on the battery size.  The 120WH batteries we have been using would be great, if only they were smaller and lighter. We could of course go for a very small and light battery, but then the Mesh Extender wouldn't be able to run for 24 hours between recharges.

To know just how small we can make the battery, we need to know what our power budget is, and this is what I set about determining today.  You can see the test rig in the picture. Basically I measured the current consumed by the USB lead that I was using to power everything, and varied what I plugged in the end.

The display on the TV is the HDMI output of the MK808B which is plugged in out of view behind the TV.  The MK802ii is visible just to the left of the Mac, and one of the RFD900 radios connected to an FTDI USB2serial adapter is currently plugged into the USB lead that is powered by the desk supply on the left, and is consuming 0.091A @ 4.995V DC, which implies power consumption of around 0.46W at that particular instant.

I used the TP-LINK WR703N based Mesh Extender prototypes as a base-line, and compared that against MK802ii and MK808B Android "Stick PCs".  I also separately measured the power consumption of the USB to serial adapters, and tried to get an idea of the power consumption of the RFD900 radios as well.  The raw measurements I made are available here.

The summary of what I discovered is:

Device	Feature	Energy Consumption
TP-LINK WR703N	Base power consumption	0.50W - 0.55W
	Wi-Fi (Access Point Mode + Ad-Hoc Mode) + USB hub + memory stick + running servald	0.46W - 0.50W
	Base + Wi-Fi + servald	0.96W - 1.05W
MK802ii	Base + Wi-Fi Client Mode + HDMI display	1.05W - 1.5W
	Base + Wi-Fi Client Mode	1.0W - 1.50W
MK808B	Base power consumption	0.51W - 0.52W
	HDMI Display Connected	0.21W - 0.22W
	Wi-Fi (Client Mode)	0.21W - 0.25W*
	Wi-Fi (Access Point Mode)	0.21W - 0.27W*
	Base + Wi-Fi	0.73W - 0.79W
CP210x USB2Serial		0.13W - 0.14W
FTDI USB2Serial		0.11W
RFD900	TX power set to 250mW	0.09W - >0.49W*

Entries marked with an asterisk probably underestimate the peak power consumption, because the bench top supply I was using did not have (or probably I didn't know how to use) hold peak current mode that would let me see what the peak current consumption was.  Instead, I sat and watched the display and tried to read the lowest and highest numbers off to provide estimated power consumption ranges.

This was mostly a problem with the RFD900 radios where RX and TX power consumption differ significantly, compounded by the radio switching rapidly between the modes.

The results were a pleasant surprise over all, because I had been led to believe that the MK808B used somewhat more than 1W when idle, so to find that it used only about three-quarters of a watt was a pleasing.  A significant contributor of this efficiency seems to come from the ability of the MK8080B ROM that I used to disable the HDMI output, saving a fifth of a watt.  This doesn't seem to be part of the ROM on the MK802ii that I have here.

When booting or doing heavy CPU load the power consumption of all three devices was substantially higher, as these embedded platform all use a variety of tricks to minimise power consumption.

I was surprised to discover that the MK808B might in fact use less energy than the WR703N, provided that running servald on it doesn't use more than a quarter of a watt.  The cores in the MK808B apparently throttle down to 265MHz when there is nothing to do, which should be enough to run servald, so it might be that the energy consumption increases only very slightly under typical loads.

I started to look into measuring servald's power consumption on the MK808B, but ran out of time when I hit an odd problem with the serial connect to the radio on the MK808B, perhaps related to the CP210x adapter.  I will revisit this in the next week or so.

So provided the servald energy consumption comes in okay, it looks like the MK808B is a good contender for the next model of Mesh Extender prototype. The main caveat is the lack of simultaneous access point and ad-hoc Wi-Fi, which means that the Mesh Extenders will only be able to talk to each other via packet radio, instead of being able to use Wi-Fi when in close proximity.

All up, it looks like our continuous energy budget, averaging out RFD900 RX and TX consumption @ 250mW (+20dBm) will probably be around 1.3W or so.  Allowing for an 80% efficient supply from battery, this means we need 1.65W * 24 hours = 40Wh battery capacity.  Allow an extra 10Wh or so for charging a smart phone, and we need a battery of somewhere around 50Wh to meet our needs.

So even though there are a few uncertainties around actual averaged RFD900 power consumption and the power consumption that running servald will introduce, we have a ball-park battery size, and one which is much smaller than the 120Wh monsters we have been using to date.  I have ordered a 50Wh battery pack from dealextreme so that I can test the run-time in the next week or two.

"Access is Denied" when attempting to install drivers on Windows 7

This is just a quick post to share a problem I had while trying to update the firmware on an MK808B recently, and the solution I came up with.  The problem was trivial, but none of the suggested solutions that I found online were appropriate, so I am sharing what happened here to save other people the same issue.

I downloaded the USB drivers for a device, connected the device, and waited for Windows to ask about drivers for it. I had the drivers downloaded and extracted ready for installation.

When I selected the folder with the drivers, Windows proceeded to try to install the drivers, but then very quickly reported "Access is denied".

The same happened if I tried to update driver from in Device Manager.

The problem was caused by the folder containing the drivers being read-only, and I think, encrypted (but I am a bit fuzzy on what the Encrypted attribute really does on Windows 7).

I solved the problem by right-clicking on the folder, and unticking "read-only" and "encrypted" and applying that to the entire folder and its contents.  This took a few seconds for Windows to fix the attributes on all the files.

After that I was able to install the driver without incident.

Hopefully this helps save someone else some hassle.

[Update: If you are running Windows 8.1 there is a related problem where you basically can't use unsigned drivers anymore.  That's a separate issue.]

Talks from Linux Conf AU 2013

For convenience, here are direct links to four of the five talks we gave at LCA2013 in Canberra:

http://mirror.linux.org.au/linux.conf.au/2013/mp4/Making_Mobile_Communications_Secure.mp4
http://mirror.linux.org.au/linux.conf.au/2013/mp4/Serval_Maps.mp4
http://mirror.linux.org.au/linux.conf.au/2013/mp4/Serval_Project_Technology_Stack.mp4
http://mirror.linux.org.au/linux.conf.au/2013/mp4/Field_Trialling_the_Serval_Project_with_New_Zealand_Red_Cross.mp4

We can't find what happened to the other one, oh well.

Root-free operation of the Serval Mesh

We have known from the beginning that expecting people to root their Android phones to use the mesh was not the ideal solution.  This is why we have put effort into liaising with the IEEE 802.11 committee, as well as encouraging Google to fix bug 82.

Bug 82 is the bug that describes the lack of ad-hoc Wi-Fi support in Android, and was filed back in January 2008, and at the time of writing is the fourth most starred bug in the Android bug tracker.  You can see it and vote for it here.  To vote for it, just click on the star next to the issue.

While we hope that this will be fixed one day, and ad-hoc Wi-Fi will be easily available on all Android phones, we have put considerable effort into a work-around.

That work-around is to alternate Wi-Fi on a phone between Access Point and Client modes. Combined with the Serval Rhizome store-and-forward protocol, this allows data to move from phone to phone.  The downside is that you can't have an end-to-end connection over many hops. Nonetheless, we have created text messaging and file sharing applications, amongst others, over Rhizome and using this step-by-step approach to moving data by Wi-Fi.

More recently, we have sought to mature this ability to operate without root access so that the Serval Mesh software assumes that there is no root access, and to operate as best it can in that situation. This functionality is now more or less complete, and is expected to appear in Serval Mesh 0.91 in the next while.  You can try it out by downloading and building the development branch of the Serval Mesh at http://github.com/servalproject/batphone.

To give an idea of how this works in practice, I made a few screenshots of a nightly build of Serval Mesh 0.91-pre:

First, here is the new home screen.  The main difference is that the "Switch on/Switch off" button is now called "Connect".  This name might change before 0.91 is released.

Instead of just starting or stopping the mesh, it now takes you to a list of available networks:

The operation of the mesh software on the phone itself is now controlled by ticking or unticking "Enable Services". Again, the label may change and indeed we expect to make this whole display much more visually appealing. 

The Wi-Fi networks that are available or might be available are listed below.  Selecting "Auto Cycle" is still an option to get the mostly-automatic behaviour of previous versions.  But it is now much easier to pick a particular Wi-Fi network.

Note also that ad-hoc shows up, even though this is on an unrooted phone.  However, it won't be used without user intervention.  

To attempt to use ad-hoc mode you touch the "Adhoc" item.  It then asks if you would like to try to setup ad-hoc mode, and reminds you that this requires root access, and might not be supported on all phones.

If you respond with "Test", then it tries to get root access and enable ad-hoc Wi-Fi:

In the case of this phone, it fails of course, because it is not rooted.  But I can of course choose to join another Wi-Fi network, or just enable Auto Cycle mode, and any collection of phones running the Serval Mesh should then connect to one another or other networks when available:

So while there is some refinement to go, the Serval Mesh software is now able to work easily without root access, and does not try to get root access without asking the user first.

"Multi-threaded radio" for the ISM915 band for fun and profit

This is some ideas that I plan to implement that I wanted to capture somewhere public before I forget.  I plan to implement this in the RFD900 firmware for the Mesh Extenders.

---

The ISM915 band requires frequency hopping in most countries where it is proclaimed.

This is a bit of a pain, because the frequency hopping means that we need to synchronise all the nodes in a mesh such that they are all listening and talking on the same frequency at the same time. That is, they need to be on the same "virtual channel".

The virtual channel is really just a hopping pattern, and knowing your position in the pattern.

It occurred to me some time ago that this imposition actually creates some interesting opportunities that we might not have otherwise considered for cooperative shared use of a block of spectrum.

The first step is to use a fairly fast frequency hopping pattern, hopping perhaps every 1ms - 2ms.

This hopping time is purposely shorter than the time it takes to send a whole packet.

The second step is to have each station only listen on a fraction of slots.  For example:

1. Define a bundle to be a fixed number of, say, 10 consecutive slots.
2. Each station listens on exactly one of those slots, based, for example, on the last three bits of its' network address.
3. The remaining two slots are a double-sized slot for broadcast packets. All stations should listen during this slot.
4. This means that while the logical hopping rate might be 1000Hz, the effective rate for each station is reduced to two hops per slot bundle, i.e., twice every 100Hz, i.e., 200Hz.

This reduces the number of hopping actions for each station, and to some extent allows for a little slop in the synchronisation. 

When a station sends a packet to another station, it can predict which time slot to send in, because the receiving stations listen slots can be determined from its network address.  

The sender then switches to the appropriate channel at the appropriate time, and sends the entire packet, even though it might take many slots to do so.

In effect, the transmitter and receiver switch from the shared virtual channel to another channel.  

This means that each packet transfer "forks" off from the main channel, hence my calling it "multi-threaded radio".

This means that as many packets can be in flight as there are real channels in the hopping pattern, and that they can all be used at the same time, but not by the same stations. That is, it has an intrinsic fair-share mechanism built in.

In terms of aggregate bandwidth, the result is potentially very pleasing.  

A 50 channel 128kbit hopping scheme such as we use on the RFD900 radio goes from being 128kbit/second throughput to potentially 50x128kbit = 6.4Mbit/second!

Yet, without the range reduction and increased receiver power consumption that Wi-Fi suffers by trying to make all that bandwidth available to a single station.

Anyway, I need to implement it to see how it works in reality, and whether the accurate synchronisation is possible on a completely distributed network with no external clock.

Serval versus Infrastructure

Today I needed to charge our Mesh Helper prototypes (which we are thinking of calling Mesh Extenders instead -- anyone with suggestions for better names is invited to poke me with them).  This is to get them ready for the Adelaide Mini Maker Faire

The trouble was I forgot to bring our mains charger for the LiFePO4 battery packs in the Extenders.

That left our solar charging system as the only way to charge the batteries.  Fortunately this is South Australia, and we get a lot of good sunshine, even in Autumn.  The declination of the sun is enough though, that finding a nice 30 degree angle for the solar panel to sit on is a good idea.  Fortunately we have such a slope just outside the lab.  It is even North-facing.  So I hopped outside and setup our 40W panel with the two Mesh Extenders.  They each have a 120W hour battery, so 240W hours total is needed, which should take about 6 hours, but the batteries are already partly charged, so they should be charged enough by the end of the day.

Here they are charging happily without relying on any fixed infrastructure at all -- not even for energy.  A very Serval moment.

Stepping back after I took the photo, I realised that I had inadvertently captured a great contrast between infrastructure and the low-cost, portable resilience that we are championing: In the background of the photo you can see the 250KW generator (including its perimeter fence to keep it and its fuel safe) and one of the University's data centres, together costing millions of dollars, and our few hundred dollars worth of resilience mobile communications gear lost in the vista.

Of course, the University data centre does much more than what our little buckets of radio can do, but sometimes you only need a little, and can't afford or sustain the big alternative.