Kurt recently posted some ideas for improving TrailScribe. In this post I want to discuss his first main idea: using an ad hoc wireless network to transmit data between TrailScribe units in the field.
I think this is a great idea, so let's dig in and think about how you could do that and how you would decide whether it's practical for a given field deployment.
In current practice, a typical base camp in a remote area off the cell network might have a BGAN satellite antenna (quick setup, ~ $10/MB Internet connection for web browsing and email) and a single WiFi access point that provides a data network within a few hundred feet of camp. They'll also be using walkie-talkies to stay in touch during the day.
Suppose we'd like to extend the data network to cover the whole field operation so people can get updates on their TrailScribes. Partly they want to share data with each other and partly they want to get updates from the outside world through the satellite connection (for example, check the latest weather forecast during the day).
Ideally, any changes we propose should piggyback on the time and money our users have already invested in their equipment, and not create more work for them in the field.
Given that context, let's explore a few natural approaches to extending the data network outside camp.
WiFi Ad Hoc Networking
The base camp network uses WiFi and our users are familiar with it. Why not use it for the extended network? This is a pretty good approach.
Companies like Tropos provide off-the-shelf WiFi ad hoc networking gear. If you get multiple WiFi repeaters you can spread them out in whatever pattern you like and clients at any point in the network can send data to each other. The repeaters detect link quality and configure multi-hop routes automatically.
There are two main challenges here. The first is that even off-the-shelf ad hoc networking equipment requires a reasonably experienced network admin in the field, and we find that physical setup (transceiver + battery + tripod mount) and debugging network problems can take a lot of time.
The second is coverage. Because WiFi equipment operates in unlicensed spectrum, the U.S. FCC and similar agencies elsewhere put fairly strict limits on how much power you can use, to avoid interference with other users. The maximum range is pretty short. If you need to cover a lot of ground you need a lot of repeaters, and the problem gets worse if there's interesting terrain in the way because repeaters need line of sight to talk.
Another thing to think about is the last-mile issue. Modern tablets have built-in WiFi, but with a low-power transceiver and low-gain antenna that reduces their range. To reduce the number of fixed repeaters you need, users may end up carrying a backpackable repeater with a bit more range.
This is an area I know less about, and I would love to hear more from experts.
VHF radios operate at lower frequencies than WiFi and typically use parts of the spectrum where the team needs to get a license but then is allowed to use more power. VHF comm links sometimes work in near-line-of-sight conditions where one of the radios is out of sight of the other one (slightly over the horizon). What all this boils down to is VHF usually provides less bandwidth but you can cover more ground with a single repeater.
Many field teams use VHF walkie-talkies, and they may already be planning to cover the operational area with VHF repeaters to carry voice traffic. Can we piggyback small amounts of data on this network? What problems do we need to think about?
First, we need to check that data transmission is not prohibited on the frequency the team is using. That will depend on the conditions in the license and I'm not sure how common a problem it is.
Next, we need to figure out how to connect a tablet to the VHF network in the field. In an ideal world, we could pair the tablet and the user's walkie-talkie with a wireless connection (like WiFi or bluetooth). That would allow users to use both the tablet and the walkie-talkie with no encumbering wires and no extra radio equipment. I'm not currently aware of any walkie-talkies that can do that, but that could change any day now. (Tell Mark it would be a good weekend project.)
A compromise approach I think might work ok is putting together a small backpackable unit that includes a IOIO board with a bluetooth dongle to pair wirelessly with the tablet, and a TNC that connects it to the audio port of a dedicated VHF transceiver. The user would still need to carry a separate VHF handheld, but no need for wires running to the tablet.
Beyond the pairing problem, data going over the VHF network is going to be pretty slow and may need to share the channel with voice traffic, so we're probably in the realm of passing short messages rather than viewing media-rich web pages, and our applications need to be designed accordingly.
How I Learned To Stop Worrying and Love Dedicated Hardware
Coming from a computer science background, I find the idea of dedicated comms hardware (like voice-only radios) really painful. It seems blindingly obvious that we should have a general-purpose computer attached to the radio, it should be able to send arbitrary bits down the pipe, and applications like voice comms should be managed by software you can change.
If you're trying to do novel research by writing brand-new apps, figuring out general-purpose data comms is important. But if you just want to get the job done, dedicated hardware still wins pretty often at the moment.
Here's one example: If all you really need is position tracking, you can use a dedicated unit like the Garmin Rino. Rinos are combined GPS / walkie-talkies that exchange position updates so you can see where your team-mates are. We've had great luck with these on the Planetary Lake Lander project, and we've started looking into ways to better integrate them with other data, like using a base station to log position updates.
Rinos have all kinds of problems--we can't change how they work, they can't send position updates over a repeater, and their tiny map screens leave a lot to be desired. But they can replace a GPS and a walkie-talkie, they're cheap, small, and rugged, and they don't need expert admins. It will take a lot of work before we can match that kind of ease of use with a tablet-based solution.