1. Ad Hoc Wireless Networking for Science in the Field

    Mon 2013-04-08 14:55

    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.


    Typical base camp network

    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.


    User 1 can send data to user 2 with multiple hops

    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.

    VHF Hacking

    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.


    Small backpackable unit for bridging a tablet to a VHF network

    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.

  2. Digital Field Assistant: The Context Around TrailScribe

    Sun 2013-04-07 18:00

    Yesterday Kurt posted some ideas for improving TrailScribe. I really like the ideas and I may talk more about them in future posts.

    They also reminded me of similar themes from my "Digital Field Assistant" concept that TrailScribe grew out of, and I realized I never shared my write-ups on that from back in 2011.

    So to complement the discussion... here's an old presentation that basically frames the core (TrailScribe) mobile device as part of a broader "field data system" that includes helmet cams, specialized sensors like Bluetooth weather gauges, VHF handheld radios, and an information sharing server in base camp.

    Click the gear and "Open speaker notes" to get the full content.

    You can think of the TrailScribe concept video as a down-sized version of this initial vision, focusing on the low-hanging fruit: What can you do if all you can afford is some tablet computers and cheap accessories like bluetooth headsets and ruggedized cases?

  3. TrailScribe tablet for field science

    Tue 2013-02-26 16:44

    TrailScribe is a concept design for how scientists could use tablet computers as enhanced field notebooks to improve their workflow.

    TrailScribe is one piece of the "Digital Field Assistant" concept I first started talking about in 2011. The idea is to organize field science data collection and sharing with a combination of phones, tablets, sensors, laptop servers, and the software to make them work together.

    Youngwook Jung, a very talented Ph.D. design student from KAIST, worked with me in Fall 2012 to develop interface wireframes and artwork and produce this video.

    TrailScribe tablets have three main uses:

    • Data collection. A scientist collecting a data set in the field can define the format of the data records they want to collect, including timestamps, GPS position, photos, bar codes identifying sample bags, and voice or touch data entry. TrailScribe can fill some of these fields automatically and simplifies others. The objective is to reduce data collection effort and produce a richer and better organized data set.
    • Situation awareness. With overnight synchronization through a laptop server in the field, all members of the science team get up-to-date access to all the data collected so far, even while they are offline in the field.
    • Field safety. By daily sharing of digital traverse plans and tracking check-ins with an automated roster, the team can keep better tabs on each other, improving field safety.

    Young and I had so many ideas for TrailScribe that it was a real challenge to focus on just a few so we could produce a short video. One guiding principle was to look for low-hanging fruit: it's easier to change workflow than develop software, and it's easier to develop software than to develop hardware. All of the functionalities illustrated in the concept video can be implemented with off-the-shelf hardware components.

    Another way of looking at TrailScribe is that it merges the field test support features we developed on the Exploration Ground Data Systems Project with our experience supporting field operations using mobile apps on the NASA GeoCam Project. This background puts us in a great position to implement the TrailScribe system.

    Going forward, we're looking for a field science operation to collaborate with on a funding proposal, so we can take this past the concept design stage.