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.

    |filename|images/2013_04_08_bcamp_600.jpg

    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.

    |filename|images/2013_04_08_wifi_600.jpg

    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.

    |filename|images/2013_04_08_vhf_600.jpg

    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. NASA xGDS Analysis Notebook Built on iPython Notebook

    Fri 2013-03-15 17:09

    The NASA xGDS Analysis Notebook is a new tool I'm developing that I'm really excited about. It's built on the iPython Notebook [1], an interactive MATLAB-like shell within a web browser that lets you do all kinds of numerical analysis and data visualization with just a few lines of Python code. I'm extending it with hooks to our live database and to simple customized plotting functions so our science teams can get right into analyzing their data.

    The way the notebook works is pretty simple. It's split up into cells. You enter a command into a cell and it immediately displays the result below, then gives you a new cell.

    Here's an example using NASA RESOLVE rover data where I quickly wrote a plotting function that queries records from two different database tables (neutron spectrometer data and position data), resamples both data sets to the same time frequency, aligns them by timestamp, and plots the result as a colored trail on a map. Even if you're not familiar with the functions we're calling, you can see these tools let us work quickly at a high level without sweating the details.

    RESOLVE neutron spectrometer signal plotted as a colored rover trail on a map.

    RESOLVE neutron spectrometer signal plotted as a colored rover trail on a map.

    I'll have a lot to say about the analysis notebook going forward, but I thought I would start by putting it in context with the rest of the xGDS project.

    xGDS develops software to support science operations, ranging from pre-mission planning to in-mission monitoring to post-mission data analysis. Until now, the data analysis part has been pretty thin. We had pre-configured displays that let you plot and map and search data, but no way to really process it.

    The analysis notebook tool will give us a lot more depth in that area. You get a very flexible numerical toolkit and you can look for unexpected correlations between different data sets, check for agreement between measurements and numerical models, whatever you want.

    We can compare the analysis notebook to our old approach of providing bulk data export to the science team in simple formats like CSV files, so they can import and analyze the data in familiar tools like Excel or MATLAB or IDL, and use specialized analysis tools developed for their discipline (like spectroscopy). We will absolutely continue supporting that and we believe it's vital, but it shouldn't be the whole story. Using the analysis notebook has some important advantages:

    • Sharing. Sharing is on by default. If you make a new plot, everyone on the science team can see it right away, and if you update it they always see the latest version.
    • Accessibility. You don't have to install expensive specialized commercial software to use the analysis notebook. Or, in fact, any software, except a web browser. That also means it's not restricted to any particular operating system. Cross-disciplinary collaboration is easier if the different disciplines can use the same tools.
    • Self-documenting. Using the notebook encourages you to document your work processes. Anyone who can read your notebook sees not just your results, but also the techniques you used to generate them, so we can all improve our process by example. At its best, a notebook is not just a plot but a kind of scientific essay about what you're trying to understand and why you needed to process the data in the way you did. This relates to some important modern progress in the philosophy of science, as embodied in the reproducible research and literate programming movements.
    • No export/import overhead. The notebook environment has "native" access to the live database, reducing the overhead of exporting data then importing into a new tool.
    • Science/engineering collaboration. Especially important to us on the xGDS team, the notebook can be a way for us to work more closely with the science team. The scientists are experts on their instruments and on data interpretation, whereas we are experts in numerical data analysis and how the database is organized. Using the notebook collaborative environment, we should be able to do better data analysis together. (Plus, scientists are cool.)

    Beyond post-mission data analysis, the other place the analysis notebook can help is as a prototyping tool for live console displays. We can work with a science team to try out lots of visualizations, pick out our favorites, then package them up for operational use as console displays that can update based on real-time data and handle the load from lots of users.

    I also got some good initial feedback--this week I showed the analysis notebook to Tony Colaprete and Rick Elphic. Rick's top comment was that we need to connect the notebook to Google Earth so we can plot things in context with other map data. C'mon, Rick, don't throw me in that briar patch!

    [1]There's actually a whole stack of libraries we're building on: iPython Notebook for the web-based shell, pandas for structured data analysis, matplotlib for plotting, and SciPy and NumPy for general numerical analysis.
  4. NASA Exploration Ground Data System (xGDS) at Google Tech Talk

    Fri 2013-03-15 16:53

    Matt Deans gave a Google Tech Talk about our NASA Exploration Ground Data Systems (xGDS) project on Tuesday. Matt is the xGDS project lead and I think this is the best overview presentation I've seen yet.

    To support the talk I finally got around to making an xGDS project web page. We've done so many interesting interfaces and supported so many cool science teams that the page really doesn't do the project justice, but it's a start...

  5. 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.