Tag: Hardware

Computer lab break-in

Last week we received the unfortunate news that one of the computer labs we helped set up in Mekelle in Nov 2009 was broken into. Just over 20 computer terminals were taken, but fortunately none of the (LCD) monitors were also taken. Given that the terminals are relatively small, so easily portable, we had thought there was a risk of one or two going astray, especially given that thefts of portable electronic devices (laptops etc) happen at all universities and all organisations around the world.

We’re not sure if the thief (or thieves) realise that without being connected to a server to boot up from, the devices are pretty much useless and there’s going to be an extremely limited market for reselling such stolen devices in Ethiopia. So it’s a small consolation that the thief/thieves are unlikely to profit from the robbery.

It’s far more disappointing they have taken the opportunity for the students to fully use the lab, now being down to half the original number of terminals. However, most students are in the run up to their exams over the coming weeks, followed by the semester break, so they won’t be accessing the lab as much as during the rest of the semester.

This gives a few weeks to get the lab back up and running fully before the start of the next semester (probably in first weeks of March) and we very quickly managed to put plans together for how we can replace the missing terminals. We’re hoping to (at least temporarily) replace some of the missing terminals with refurbished PCs, we’d already been testing this over the past few months, so just means that we will deploy them sooner than expected. We’re also checking the costs of having some (SunRay) terminals we had in the US shipped over as replacements for those which have gone missing.

So, despite the setback, the lab should be back up and running within a couple of weeks.

Testing alternative thin-client server solutions

The thin client solution we currently have running in Mekelle is based on using OpenSolaris and we have a variety of terminals – a mixture of SunRay 1′s, SunRay 2′s and Nortech clients. Using sun ray session server, the sunray terminals are performing well, but when we have the labs full of students, the Nortech terminals are significantly less responsive. There are a number of possible reasons for this, the protocols used, the network amongst others. There is a huge range of other configurations and technologies we could use to provide a robust and scalable thin client architecture.

I’ve spent a few days this week in Barcelona with Cast-Info investigating their Desktop4All solution, which we’re looking to trial as an alternative to the OpenSolaris setup we currently have. Goitom, one of the phds students from Mekelle will spend the next few weeks based in the Cast-Info offices, learning how to install and set up the server system used for Desktop4All, with a view to installing this when back in Mekelle in a couple of months.

Desktop4All, based on Linux, is a set of integrated open source applications. It’s likely to produce a similar end result to the solution that we already have running with OpenSolaris, but the main advantage for us will be in the support and documentation available as a reference. Testing out Desktop4All will give us the opportunity to collaborate in the development and to investigate whether we get similar types of issues arising as we have had with OpenSolaris.

When we started the Digital Campus project, I think there was some concern over whether the students would need much training in how to use a non-Windows operating system, given that much (all?) of their previous experience of using computers/pcs was with Windows (usually XP). This has turned out not to be the case, given that many students have had limited time to become locked in Windows, we’ve found few issues with students being unable to navigate the interface or use applications. I suspect we don’t always give the students credit for their ability to adapt to new interfaces and systems (especially judging by how quickly they find their way to webmail, youtube and facebook).

Using smart phones for health research in rural areas

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.

Scroll to top