NLnet Foundation has provided financial and other support for the progress of the mesh helper device concept. The following details the work blocks and major tasks that are supported under that project, along with notes regarding their progress.
A preliminary port of ServalD to OpenWRT has recently been accomplished, therefore this task is not anticipated to be onerous. The focus will be on familiarising ourselves with the Dragrove hardware, and unit tests to confirm correct operation, and documentation of the build and installation process.
An customised OpenWRT distribution has been created that includes servald as part of the base firmware. This is available at http://github.com/servalproject/dragino. The build process is identical as for any OpenWRT distribution. See building on openwrt for more detailed information.
WiFi interfaces on the Dragrove are now automatically configured, including random self-allocation of IP address for the mesh interface.
The servald process is automatically configured and starts on boot.
Remaining tasks include:
Integrate the hardware of the prototype concept. The core of this will be the physical connection of the Dragrove, a LiFe or LiPo battery, charger circuit, UHF radio module and antenna in a small weather-proof package. It will accept power from mains, a 12v car adapter, or possibly a 10W solar panel depending on the sophistication of the charging circuit used. Particular attention will be given to documenting the parts, circuit diagrams, assembly and sources of the parts used so that others can replicate the prototype hardware.
We have ordered:
These will be used to create the first prototype, with a focus on minimising risk and time expended, so that we rapidly obtain a demonstrable prototype unit. The result will be relatively higher cost (perhaps AUD500 - AUD1,000). The assembly information and part list for this will be very simple for replication by others, and there should be good stability in the supply of parts.
We are also exploring a lower-cost solution based around a 9.6V LiFePO4 battery pack that could be charged from a 12v supply without an up/down DC:DC converter, for an overall lower cost. This would be based on low-cost devices obtainable from ebay, for a total build cost of AUD100 - AUD300. Quality will be uncertain, and the resulting system will probably require more end-user work. Stability of supply of parts is less predictable.
Part lists and assembly instructions will be collated on the building a prototype page.
Of course, all of the above is based on prototyping around the Dragrove/Dragino device, which has a power consumption of around 4W, which results in substantially higher costs all round. The end goal is mobile-phone derived hardware with power consumption between 0.4W and 1W, which will substantially reduce the battery requirements as well as the size and capacity of the charging solutions. We still anticipate that a final solution (minus solar charging option) could cost under AUD100.
We have assembled a prototype, minus the HopeRF 23BP radio module, which we are still waiting on. We are also waiting on the LiFePO4 battery packs, and have substituted a sealed lead acid (SLA) battery as a perfectly functional option.
Once we have the RFM23BP modules, we can complete the preliminary wiring, and make any necessary adaptor and fit it.
(We could have used a BEE interface RF module, but none compare with the HopeRFM 23BP in terms of output power or overall performance and flexibility.)
The current model Dragrove units do not support any mass storage, and have only limited internal memory. As a result the Rhizome store-and-forward system will only be able to hold limited amounts of data. It is anticipated that somewhere between 1MB – 4MB will be available for Rhizome storage, which will be sufficient for MeshMS traffic and a few phone camera photographs, sufficient for demonstration purposes. Some remedial work on Rhizome may be necessary to ensure that it can contain the Rhizome database size, and properly prioritise replacement of content in that limited space.
Three solutions exist to this limitation: Short-term, Block F will introduce a Rhizome relay service that will by-pass the Dragroves when forwarding Rhizome bundles. Medium-term, it will be possible to use the 2nd generation Dragrove device, which we understand is being developed, and will feature a USB port that can host mass storage, e.g., a USB flash drive, suitable for holding a large Rhizome database. Long-term, the plan to create custom mobile-telephone derived mesh helper hardware, that will have the necessary mass-storage capabilities designed in.
servald is able to run on the Dragino/Dragrove devices, which is the first step to testing Rhizome performance. Once we have two Draginos meshing, we will test Rhizome transfers between them, which will satisfy the requirements of this work unit. This will occur following the preliminary work of work unit B.4, described below.
We have not resolved the no-unicast issue, but we have implemented Rhizome over MDP, which allows Rhizome to operate using only broadcast packets at the IP layer. We have seen this allow file transfers via Rhizome between two Draginos, including photos and MeshMS messages.
Out-of-order packet arrival and dropped packets are now handled effectively, with data transfer rates around the 150KB/second for larger files when the rhizome database is memory resident (the FLASH is too slow to be practical, reducing transfer speeds to less than 10KB/sec under typical conditions).
This work unit is complete.
This will require ServalD to operate successfully with multiple network interfaces, which has been tested in limited conditions. Task will consist primarily of configuration of servald and testing of resulting configuration, documenting the process.
Rhizome will have limited storage capacity on the Dragrove device due to the lack of mass storage, but is anticipated to be sufficient for relaying MeshMS messages. A more general solution to Rhizome connectivity via Dragrove is covered in a later item.
We have WiFi interface of the Dragino devices operating simultaneously in ahdemo mode (a variant of adhoc mode) and virtual access point (VAP) mode.
DHCP has been configured on the VAP interface.
Automatic selection of IP address for adhoc mode is complete. A problem remains where unicast IP traffic is not being delivered on the adhoc interface.
Broadcast packets deliver fine, so mdp ping etc works, but Rhizome synchronisation via HTTP fails. Rhizome via MDP works fine, as does Rhizome via HTTP to access point clients.
VoMP uses MDP, so that works as well, although there are bandwidth issues due to the limited broadcast bandwidth combined with the fairly naive VoMP retransmission regime, which is probably resulting in up to 10x the necessary bandwidth consumption. Work is being undertaken to address the VoMP issues.
We have demonstrated rhizome transfers from one phone on one Dragino as a WiFi client to another phone as a WiFi client on another Dragino unit, so the overall system is functioning. This has included small bundles such as MeshMS, as well as larger bundles such as a 600KB file.
We have moved the Rhizome database from flash to RAM, as the FLASH performance is abysmal on the Dragino. For comparison, the 600KB photo transfers in about 5 seconds to RAM, but takes close to two minutes if the Rhizome database is on flash.
There are some unrelated issues with Rhizome and invalid bundles that cause network congestion and failure of delivery, which we have scheduled to correct, but are outside the scope of this work unit, and are broader in issue than the Dragino.
Similarly, Rhizome transfer speeds are sub-optimal when using broadcast/MDP, in part because the Dragino units are very slow (180MHz MIPS), in part due to the unreliable nature of broadcast WiFi, in part due to sub-optimal packet transmission behaviour of Rhizome over MDP. Optimisation of Rhizome over MDP is outside of the scope of this work unit.
Significant improvement is expected if unicast traffic can be made to work, which will be explored, perhaps by using the Commotion OpenWRT distribution for the Dragino in place of the stock Dragino one, since they will have presumably solved (or avoided) this unicast traffic problem. This is outside of the scope of this work unit.
VoMP calls work, but with significant quality issues, similar to using a GSM phone with marginal signal. This are due to a combination of packet loss, bugs in the jitter buffer logic and that we are using raw audio which greatly increases the bandwidth requirements, and as a result is preventing us from using VoMP's preemptive retransmission capability. This will be remedied by implementing one or more compressed audio codecs in VoMP to reduce the bandwidth requirement, and thus allow preemptive retransmission of audio to cover packet loss. The alternative remedy is to fix the unicast traffic issue, which we intend to do. All of that work is outside of the scope of this work unit.
Thus overall, we are satisfied that we have accomplished this work unit, with the understanding that we intend to fix the unicast traffic problem under Block A.
Implemented using RFD900 radios and FTDI 3.3v TTL USB:serial adaptors and OpenWRT running on TP-Link WR703N devices, as described on the prototyping page.
Tested at KiwiEx 2013, and shown to mesh over >3km with good line of sight and low noise floor.
Work unit complete.