KiwiEx is the (usually) annual field exercise of the New Zealand Red Cross (RC) IT&T Emergency Response Unit (ERU), one of five globally. The exercises simulate a deployment by taking the ERU team to an isolated area with simulated border crossing, technical challenges and generally simulated operating environment.

In both 2012 and 2013, KiwiEx was an invaluable testing ground for The Serval Project. The KiwiEx 2013 field exercise ran from 23 February to 3 March, and featured several technologies oriented around the use of succinct data.

The following functions of the Serval Mesh app for Android were tested, using a development build following the 0.90.1 release:

• Participation of non-rooted Android phones in the Serval Mesh network
• Encrypted telephony using Voice over Mesh Protocol (VoMP), focussing on short-range voice calls and assessing ease of use, as the multi-hop call routing engine is not yet mature
• short-message texting over MeshMS, particularly signed broadcast messaging to share information between field personnel during the exercise
• File distribution over Rhizome, including Equipment Requisitions
• In-field automatic software upgrade during the exercise
• Performance of Rhizome under anticipated heavier traffic than KiwiEx 2012

The smart phone specification for KiwiEx 2013 was lifted from the Huawei IDEOS U8180 to the Samsung Galaxy S-II due to the superior performance and usability of this larger and higher-powered platform.

The first prototype of the Serval Mesh Extender was tested, in the form of “radio buckets” containing a rechargeable Li-Po battery with a 12V car charger plug, an ISM band packet radio module, a Wi-Fi module providing simultaneous Ad Hoc and AP modes, and a CPU/memory module running the Commotion Wireless OpenWRT port of Serval DNA.

Field assessment data was collected by field personnel using the Serval SAM app for Android, which uses the Open Data Kit (ODK) form entry system to capture form data, and sends the data to the simulated Emergency Operations Centre (EOC) via Rhizome.

• During KiwiEx 2012 it became apparent that Equipment Requisition Forms were a good candidate for integration with the mesh network. During KiwiEx 2013, the logistics officer at the EOC received requisition forms electronically.

• The following two Field Assessment Forms received at the EOC were visualised on a publicly accessible map:
  • NZ Red Cross - Disaster Assessment Form: 1 A - People
  • NZ Red Cross - Disaster Assessment Form: 1 B - Family Needs

The Serval SAM page gives instructions for installing and configuring the Serval SAM app with these forms.

An experimental branch of the Serval Mesh (app for Android) was developed to implement Succinct Data. This technology was not ready in time for the exercise.

Various approaches for extending battery life were considered:

• larger-capacity internal batteries (2300mAh versus the 1650mAh stock ones)
• external “battery-extender” cases (2000mAh)
• thermo-electric saucepan for charging phones
• flexible solar panels for charging phones and/or mesh nodes
• car-charging phones and/or mesh nodes

Bug report: Serval crashes on opening folder If you try to open /mnt/extSdCard/LOST.DIR by using the “share files” functionality Serval crashes. (Probably an access rights issue? Phone is your bunch of Samsung Galaxy S2's)

Bug report: Serval can't access external SD card on Samsung Galaxy Duos GT-S7562 Android 4.04. Can't find neither the directory “extSdCard” nor “mnt” (and anything below that directory) when I try to “share files” - all I can see is the directory structure below of /mnt/sdcard (which is the home directory).

Feature requests:

* Progress indicator when starting Serval maps - it sometimes takes quite a while after you press the “I understand” button until the map comes up - and some kind of info if there is no map found or the GPS device is turned off

* In Serval Maps, the finest logging interval of tracks is 10 seconds, which is fine if you're walking but is not very accurate if you're driving above 40km/h. Nice would either be a setting “as fast as the device can” or a sort of adaptive algorithm that decreases logging interval as the speed increases

* In Serval Maps, if you place one marker there is no way of changing it - neither changing the GPS location nor updating the information associated with it, which limits the usability during disaster response - e.g. one day there might be no water available there, a week later there might have been installed a water tank and toilet facilities (or the camp might have vanished alltogether)

* In Serval Maps, there should be a possibility to add more than one picture to a location. Same goes for the Disaster survey forms we tested on the exercise.

* In Serval Maps, the Location description field is currently mandatory - which shouldn't be, because sometimes it just needs the tag-words to describe a location fully.

* I would think it useful to have different “user modes” for disaster mapping, since there are different roles involved: IT/Telecom is looking for e.g. repeater sites, Wat/San is looking for water sources and waste disposal possibilities, Logistics is looking for warehouses, distribution sites and road conditions and so on… Maybe each role could have Icon buttons for quick logging of data, e.g. for Logs have icons for “road is.. 2 lanes, 1.5 lanes, 1 lane, 4wd”“paved, unpaved, gravel, asphalt, mud, …”“suitable for 4wd, 2wd, light truck, heavy truck, trailer” so they can have a running log while driving. Also common hazards (washout, bridge missing, …).

* compartmentalization of information and admin possibilities: at the moment everyone can read everything, but in reality most of the data is only relevant intra-department wise and could be a risk if read/interpreted in the wrong way - so there should be the possibility of starting a group and inviting members to it, that can share information only within this group while the same data would be unreadable by non-members. Information propagation of this encrypted data could be done the usual Serval way, only the local access would be restricted to the persons with sufficient rights. Should also provide the possibility to belong to more than one group, and there should be a “everyone” group for exchange of data that is interesting to all. The same thing is for messages: this should allow forming of groups (besides the “to everyone”) - I'm not interested to read the shopping list of the kitchen team while being on the Telecoms team.