I had expected connectivity problems, but they have been far worse. I am reminded of one of those laws, like Murphy’s Law, that says “jobs always take longer then you plan even after taking into account this law“.
On my iPhone with an O2 SIM, I have rarely seen more than two bars of GSM and only twice seen a 3G signal, one on the train in Bangor, and once at Aberystwyth railway station (but not elsewhere in Aber).
My Android phone is on Vodafone and it has usually been less good, and never good enough to support a tethered data connection.
I was told that Orange (now EE) had best connectivity on Offa’s Dyke, but don’t know if it is any better on the coast. In did try to get an EE SIM for another device before I set off, but failed (a long story). However, from the diffculty I saw others having, it does not look like any network is particularly good.
I can understand mobile signal being difficult in deep valleys. I am also aware that coastal mobile signal is focused towards the sea, or to be precise I think, towards the yacht folk, who have money. However, it was surprising that one of the worst spots was the campsite at Tal-y-Bont, which is on the flat coastal plain between Harlech and Barmouth. Being on the flat it should have line of sight to many points along the coast including Porthmadog across the bay.
Not infrequently along the West Coast and Lleyn my phone has popped up a message about European roaming, the signal from Ireland miles away across the Irish Sea, was strong than the UK signal.
Given the Government’s belief that 4G will be the solution to rural broadband, this is not encouraging.
Many hotels and B&Bs say they have WiFi, but often it is unreliable, as one would expect in rural areas, or the owner does not know how to give you access. A frequent experience is WiFi that connects fine for a short while, but then when you try to reconnect after a break fails. This is not purely a rural problem as I’ve seen exactly the same behaviour in city hotels.
In fact, in the week when I was on my ‘off path’ excursion CHI in Paris, I stayed in the main hotel of the Palais de Congress. WiFi was reliable and high bandwidth if you work early, say at 6am, or if I went back to my room mid-morning, but virtually unusable once propel woke around 7am or in the evenings, even after midnight.
In general it is the unreliability of connections that is more problematic than low bandwidth. It is just possible to use websites by clicking a link, then doing something for a few minutes while the page loads, another click, wait again, etc. However, if the connectivity is unreliable, you cannot rely on being able to check weather, or find a B&B at your next destination.
Software and Connectivity
To some extent I can understand the problems of providing universal connectivity; there is a 90:10 rule with the large majority of the population occupying a very small proportion of the land area. Providing coverage for the last 5% of population, quite likely requires 90% of the land area, and will always cost a disproportionate amount.
I have less sympathy with software. There is still a 90:10 rule: the costs of making software work properly rise as one caters for the ‘tail’, but the ramp up is not as steep, catering for the last 5% of people or situations may require 20 % of the overall effort, but not 80%
On the phone, it is only email that has had any reasonable reliability at low signal strength. This is presumably because it is essentially 1970s technology, so developed in the days when the fastest networks would feel like carrier pigeon to us now. Emails are big now, often with substantial HTML bloat, but the underlying protocols deal with slowness.
The web can be accessible on low signal, so long as it doesn’t drop out completely. Typically I find myself using a click, then go off to do something else and, with luck, on my return a few minutes later there may be a page to look at.
Apps are often little better despite their code and major assets being pre-installed.
Twitter is one of the most surprising culprits. Being based on 140 character messages, it feels as if mobile web site and apps should work well with low network capacity, but in fact the Twitter app will often ‘white screen’ (well white screen with blue stripe on top) on low signal. I assume the reason is that it is asking for a substantial number of status updates (perhaps latest 20 or even 50) from the server, and does not layout the page until these have been returned. Often the data structures returned from API calls are quite bloated XML, further slowing down any response. Often the reason for trying to use Twitter is to send a status update, which of course does not need to wait for the feed to update.
To be fair on Twitter’s mobile app, at least when you post a status update, it either does it or saves it in ‘drafts’. Both the other client I use (Echofon) and the Twitter mobile site, simply discard messages that they fail to post.
Problematic behaviour is not restricted to phone-based applications; Flickr Uploader has been especially problematic. Slow roundtrip or low bandwidth are not a problem, it simply works more slowly. However if network connectivity drops even for a few moments, the Uploader freezes, and does not resume when connectivity is restored. These momentary drops are common in public access points and indeed in domestic broadband in rural areas (not to mention expensive Paris hotels!).
There seems to be at least three main issues:
(1) Development and testing environments clearly do not include poor connectivity, most of the problems emerge rapidly. To be fair this may be hard to come by when developing in Silicon Valley!
(2) There is a lack of robust engineering across current consumer software. This often means that ‘typical’ cases work, but when stressed, for example by network latency or capacity, then race conditions and other defects emerge.
(3) The dominant model of mobile development is thin client, whereas in areas of poor connectivity a distributed system with the same sorts of data integrity care at client end as used server-side.
(4) Companies simply do not care as it is only hitting a small segment of the market.
Having technology around also takes yet more time. A typical day involves the following:
(i) Before setting off from van/B&B — making sure all required devices are in rucsack or body (camera at belt, recorder in pocket, others in or on rucksack); if leaving computers in the van ensuring they are in out-of-sight cupboards and locked spaces; packing charging wires, external battery, sometimes USB charging plug (these are used overnight, so have to repacked each day).
(ii) When starting the walk for the day (which may be sometime after (i) if using pubic transport or taxi), turning on all GPS devices
(iii) Part way through day — make sure phone charge level is sufficient and if not plug in external battery.
(iv) At end of day — plug everything into chargers
(v) at end of most days (some times can put this off) — transfer camera photos, audio files and sensor data to Mac, down sample photos to 800 width, run cod to generate JSON meta data for audio files
(vi) Every second day — load data from ECG sensor into PC, transfer to Mac using USB stick, wait for ECG sensor to charge, ‘programme’ sensor for next few days
(vii) When there is WiFi — upload low-res photos to Flickr (Flickr now has huge limit so could store full res, but upload would take too long), sync Dropbox (making audio files and sensor data available), upload JSON meta data, upload blogs and insert images, formatting, links.
Many of these activities take little absolute time, but need ‘tending’, waiting for things to finish. If only more could be plug in and forget – but as a research question why not?
The above factors have had a major impact on technology use.
I had intended to frequently tweet on the move, but found it virtually impossible. The tendency to discard messages was particularly distressing when one had crafted a 140 character message. Any thoughts of Haiku-like running poetry were dashed in the first few attempts.
Battery-life has also been a problem, both with phone-based apps and also a special device as part of a collaborative project. The problem seems to be two fold:
(i) GPS itself is power hungry, especially on phones. However, the SPOT device I use last 14 days on three AAA batteries, so it does not seam impossible to design low power GPS. Maybe it is simply a price-performance balance or maybe a size-performance one.
(ii) The devices are trying to use mobile connections to transit data. Sending data uses some power, but in areas of low connectivity this increases as the phone is ‘shouting’ louder’ to get heard by the distant mast.
The latter could be dealt with my ‘backing off’ when signal is poor and waiting to send/receive opportunistically when there is strong signal. However this would require:
(a) Transparent infrastructure that makes appropriate information available for contextual adaptation.
(b) Appropriate visualisations and user interactions to deal with the tentative/ in-between nature of not yet synchronised data.
Use on the move is also made problematic by wet weather, lack of time, and then simply not having the habit of using the phone.
I do make heavy use of camera and audio recorder. The latter is very low-impact on the walking experience as it can be used on the move.
I asked one walker about what technology he used, his answer was “a map”. However Rosie Unsworth, who was walking the opposite direction at the same time as me, used the ViewRanger app on her phone almost exclusively for navigation. This is probably OK near the coast, but reliance on electronic GPS devices has been the cause of multiple call outs for the Snowdonia Mountain rescue acrid to a recent article on BBC News “Man rescued in Snowdonia after smashing map device“. The spokesman for Mountain rescue was reported as saying:
“People should have a paper map of the correct area, and by all means use the electronic equipment to check your co-ordinates, but don’t depend on it because if you are out on the mountain for hours at a time batteries go flat,”
The best technology
One of my aims was to investigate technology for the walker: what technology would make it easier / better for me as a walker, and for other walkers. I recall asking one walker, “what technology do you use?”; “a map,” was his immediate answer.
Not everyone is like this and an increasing number of people are using dedicated GPS devices or phone apps as their primary navigation. Indeed when I talked to Rosie Unsworth, who was walking the Wales Coast Path in the opposite direction, she told me that she had exclusively used her phone, in particular using ViewRanger [Vi13], which enabled her to download all the OS maps for the path which would otherwise have been very voluminous.
I don’t know the overall balance of technology use, as the nature of coast paths is that you only occasionally need any sort of navigation except when the path, for reasons of topography or legal access, has to branch inland. However, where I did observe others using navigation aids, it was exclusively a paper map or using maps and instructions in guidebooks.
This said, clearly the trend, especially among younger hikers, is to use more technology, which is beginning to cause headaches for rescue services, who are increasingly being called out to help people who have only a GPS device or phone and have either dropped and broken it, or found its battery has run out.
In a recent survey in the White Mountain National Forest in the USA, less than a half of hikers had a compass with them, although 60% had some from of GPS [MS13]. However, the paper notes that of the GPS users, the vast majority were using phone-based service that failed in the park, and that even dedicated GPS devices had black spots in the park.
To be honest, while I was wired up with biosensors (see next section) and had a ‘Spot’ device broadcasting my location to satellite to appear on a real-time map, I very rarely consulted navigation technology or other apps on the way. This was partly due to battery problems; my phone was most often in the rucksack charging on an external battery pack. It was also due to the difficulty of using the phone in slightly damp conditions. Some days, if I went into a cafe during the day or got to bed and breakfast at the end, it would be several minutes before the touch screen would respond to gestures, despite wiping both screen and fingers to dry them. There were also connectivity-related issues with many apps as mentioned earlier.
After my camera, the most heavily used piece of technology that I had with me was an Olympus voice recorder. This had a number of advantages:
- Physicality– it had real buttons, and so it worked with damp fingers, and could be navigated by touch alone when cupped in one’s fingers or held inside one’s hood to protect it from rain
- Non-visual – while there was an LCD screen, common functions could be operated without consulting this. I wear reading glasses and so using a screen involved getting glasses out, and trying to de-mist them, before being able to do anything. To be fair also a problem with maps.
- On-the move – the combination of the above, with the fact that, when the ground is not too rough, you can speak while talking, meant I did not have to stop to use it; important when timing got tight.
Technology of the extended experience
In fact, although I rarely saw people actively using technology for navigation, it is likely that many will have been carrying mobile phones, or consulted an online weather forecast before starting. Technology can be used in several ways during and around walking as an activity:
- Actively used on the move – navigation apps, infrequent Twitter, camera, voice recorder, wrist-watch-style heart-rate devices (for consulting while moving), iPods and MP3 players.
- Passively gathering/transmitting data – SPOT and ViewRanger transmitted my location to online maps, biosensors, many now wear Nike Bands, or similar devices.
- There for emergencies / occasional use – mobile phone there in case of need, or maybe to be available to others if they need to contact you, the SPOT device had an SOS button, which would call emergency services if needed.
- Used during breaks – often this may be in places with better connectivity and under cover, for example, I used an iPad mini extensively for writing if I stopped in a cafe. People may use mobile Internet (where available) to book accommodation, or may use a rest gap to post statuses to social networks (signal allowing).
- Used outwith the walk – some technology is used before walking for planning, or afterwards for reminiscing, uploading photos, etc.
When I asked the question “what technology do you use?”, and when I said that I rarely used technology, it was the first of these which was the focus of the negative response, but all of the above are important aspects of technology use.
(see also the data section of the site for access to raw data and meta information files and “Sensing the Miles” video describing the data itself and research challenges arising from it.)
I collected the following quantitative data:
- GPS traces from both ViewRanger and Garmin — but these will need editing to remove occasional digital spikes, remove times when turned off to late and include bus journeys, and add portions that were missed (when power ran out, or I forgot to turn on at beginning of day :-()
- GSR and skin temperature (using Affectiv Q sensor) — continual but not every day, probably 2/3 of walking days
- Full ECG trace – as above, approx 2/3 of time
- GPS and ambient temperature from dot.rural sensor, but partial due to battery problems
In addition the following quantitative data
- photographs – between 250 and 450 a day (one day 643!)
- audio logs – from half a dozen to 30 a day
- very occasional Tweets –I had thought this would be a major activity, but I have found Twitter very problematic
- blog/diary — approx 2000-3000 words per day
Also live feeds:
- ViewRanger Buddy Beacon (mobile network) — feeds ViewRanger and SocialHiking maps
- SPOT device (satellite) – feeds SPOT map
I had Pulsar (live heart rate) from Lancaster project, but it has proved unreliable. This may simply be long-term use draining battery too fast.