Alex Little

I recently became the owner of an unlocked HTC Dream smartphone (running Android 1.6). Smart phones are still quite a rarity in Mekelle (and I’d guess in much of the rest of Ethiopia), so despite this not being the most recent model, everyone who sees me using it asks me to have a look & play around. I have seen a few people with Nokia E71 phones, but when you look closer they’re actually Nokla E71′s (yes, that’s Nokia with an L instead of an i).

In a couple of days I will be heading out to some rural areas with a colleague doing his doctorate in public health. He’s testing different smartphones and applications for data collection whilst he’s interviewing Health Extension Workers (HEWs). I’m joining him to see what some of the issues are with using these types of phones and applications in this context, with a view to spending some time over the coming months seeing how these devices may be used to deliver training.

I’ve only really been using the phone for the past week or so and there are a couple of areas where I can already see we may run into problems.

Firstly, the battery life. With my usage, not particularly heavy, the battery usually only lasts just over a day. Given that we’ll be using these devices for data collection, then they’re likely to be having heavy use in areas with little or no mains power. We are testing out some small solar power chargers.

Secondly, the GPRS coverage. GPRS is not used widely here and coverage in extremely patchy (even in large city like Mekelle) and it’s not yet been rolled out to other more rural areas (or even large towns). Sim cards need to be specifically enabled to use GPRS – it’s not turned on by default. The applications we’re testing out (EpiSurveyor and Sana) will both allow data to stored until an area with coverage is reached, but unless the user visits Mekelle on a regular basis then the data will never get uploaded.

I’m sure that improvements in the phones and the phone network infrastructure will eventually make both of my concerns invalid – it’s just a question of when they will be addressed.

The other questions and areas I’d like to look at include:

1) How easy is inputting the data on such a small screen? Might a tablet or netbook PC be more appropriate? Perhaps they’ll work well for short, relatively simple surveys, but not for others?
2) Do any of the HEW’s already have java enabled phones? If so, this would enable them to use the EpiSurveyor application without any new phones.
3) Do any of the phones support input using ge’ez (the alphabet used for Amharic and Tigrinian)? I can’t see how to input these characters on my phone (if anyone knows how I’d be pleased to hear from you), but I can display the characters.
4) How long do the phones take to get a GPS signal? For each record input we can automatically attach the location coordinates – but I’ve noticed that sometimes the phones can take a long time getting a GPS fix. With the power issues it’s unlikely they’d want to leave the GPS on all the time.
5) Would they really be used? Getting reliable data in these areas (even just for the number of births/deaths) is extremely difficult – reporting processes are often unreliable or just not used. Using these phones could help with gathering this info – but obviously only if they are used.
5) What are the other uses for the phones? E.g. providing remote diagnostic support, clinical support, training content/activities or reference, or perhaps for fun/social activities.

Plus I’m sure many other questions and possibilities will arise over the coming days.

Since I’ve been back in the UK, although I’ve been pretty much tied to the house, with Amazon now back available to me, I’m able to spend money again. One of the items I bought was a GPS. Originally I was going to be borrowing one from someone in Addis to be able to do some mapping of Mekelle, but since I’m in the UK it seemed to make sense to get hold of my own whilst I was here. I eventually opted for the very basic Garmin eTrex H, thinking that it does everything I would want and I’m unlikely to spend money buying maps to download onto it – the main reason for buying it was to contribute to the OpenStreetMap project.

Once it had arrived my first challenge was getting it hooked up to my Asus EeePC (running Ubuntu) and installing the right bits of software.

For up & downloading to the GPS I installed QLandkarte, which only started recognising my device once I’d also installed the gpsbabel package.

Next I needed a desktop program for editing OpenStreetMap – using the online Potlatch application wouldn’t be a great option for me once back in Ethiopia with no decent internet connection.

I started off by installing Merkaartor but quickly ran into problems. When I tried connecting to the OpenStreetMap (OSM) server to download a map to edit, I kept getting “403: Forbidden” messages. The problem was that the particular version of Merkaartor the Ubuntu package manager installs doesn’t work with OSM Protocol v0.6. I think there may be a version of Merkaartor which works with v0.6, but I’m not generally very keen on installing software outside the Ubuntu Add/Remove Applications

I then tried Java OpenStreetMap (JOSM), again installing from the Add/Remove Apps and I was getting similar problems in being unable to connect to the OSM server. Again the problem was the protocol version.

Merkaartor and JOSM appeared to be the only programs available for editing OSM on Ubuntu (please let me know if there are others), so I had to resign myself to manually installing one of them. I opted for JOSM as it was quite easy to run manually and once installed all seems to be working relatively well.

I do however had a few gripes about the user interface, especially on the small screen of the Asus EeePC. For example some of the dialog boxes are fiddly to expand to get the OK/Cancel buttons to appear. Also, the drop down list of “presets” (the different map features, places of interest, amenities etc which can be added) is too long to appear on the screen, but there’s no way of navigating down to the bottom of the list to see which options are available.

Apart from that, I feel like I’ve got the hang of OSM editing (a little at least) and I’ve managed to add a few new roads. Hopefully once I get back to Mekelle, I’ll be much more productive, especially since I’ll be starting on a blank canvas.

This morning I received an invitation to join Fire Eagle – Yahoo’s location sharing application, so I’ve just been having a little play. I’d actually forgotten all about it since I saw a presentation about it at the FOWA last October and must’ve asked for a beta account then.

On it’s own Fire Eagle isn’t much use – but the idea is that you allow Fire Eagle compatible applications and devices to read and/or update your location, so you only have to update your location once for all the applications to know where you are at any time (subject to all the privacy settings available). So to actually try it out I downloaded the Loki toolbar – which can automatically update your Fire Eagle location based on your (wireless) network connection. Though I’ve installed it on my desktop PC so my location is unlikely to change much (I’ve not moved my desktop PC for nearly 2 years!) – but it did pick up my location reasonably accurately for what I assume is an IP based lookup (I’m actually about a mile from where it autodetects).

The privacy with an application such as Fire Eagle is a high priority (as I remember being mentioned in the FOWA presentation) and there are plenty of ways you can allow different applications different levels of privacy (e.g. how exact the locations are) – but then each application (as with Loki) has it’s own set of location sharing privacy options. All of which seems to make for a mind-boggling array of confusing options (in my mind anyway!).

My main reason in looking at Fire Eagle initially was to see whether we could hook MSG up to it, so your MSG location was auto-updated, so I’ll have a look into the Fire Eagle developer section and see how feasible and quick this will be to get set up.