NanoLoggers #

See github for up-to-date information on this project.

This is an interdisciplinary project at the intersection of Biology and Computer Science aimed at developing sensor payloads below the weight and energy budgets of most low-energy devices – \(1g\) and \(1\mu W\) , respectively – that must survive challenging environments and collect useful data over many months. Our biology partners study the behavior and ecology of Dark-eyed Juncos, a small song-bird in the range of 20-25 grams. We are also developing data loggers for smaller birds such as the pine siskin, which is in the 12-18 gram range.

The data loggers (henceforth “tags”) are attached to subject animals with a light weight harness made from elastic thread. The tag rides under the bird’s feathers on its back and the harness loops under the bird’s legs. The tags we are developing are “archival” meaning that data are stored on the tag and can only be retrieved by recapturing the subject animal.

The small size of the subject animals necessarily constrains the size and weight of any tag that they carry. A widely accepted “weight budget” for such tags is 5% of body weight – \(1g\) and \(0.6g\) for Juncos and Pine Siskins, respectively. There is debate about this bound and it is clear that smaller is better. Designing tags at this scale using off the shelf components and commodity fabrication processes is a significant challenge – especially for smaller species. It is clear that tags should carry exactly the components (e.g. sensors) needed for a particular experiment and no more – a key project goal was to make support of custom tags “painless”. For example, our partners are currently monitoring “activity” with the goal of determining when the subjects are active.

Example Tag #

The adjacent image illustrates two sides of a “BitTag” which uses an accelerometer to determine active periods and stores activity bits/counts for up to 7500 hours (with a ( 0.45g ) battery). This tag carries a processor, real-time clock, and accelerometer. Note the array of six “test points” on the left tag – these testpoints, covered with insulation during flight, are the physical access to charge, configure, and access data. On 0.6mm thick PCB, this tag (without battery, harness, or coating) weighs 0.25g.

Data Visualization #

In addition to the tags and their support hardware and software, we have built a separate visualization tool for BitTag activity data. This tool provides various ways to explore the data collected from a tag. There are two fundamental views – a graph of the raw data, and actograms.

The raw data window provides a high level view of the activity and allows the exploration of the data through zooming and panning. The adjacent figures illustrates approximately 6 weeks of data. Various controls allow the application of smoothing filters, aggregation over longer periods, and export of both graphs and the raw data from the selected window. Additional overlays are available to display the tag battery voltage and temperature. The former is useful for evaluating the discharge rate in long experiments (the utility of temperature is tbd).

A common way for behavioral scientists to explore activity data is through an “actogram”. The actogram is organized to display multiple 48-hour periods (two days in a row), with rows beginning on successive days. Thus every 24-hour period is displayed twice – first in the left column and then in the right column. Our visualization tool provides ways to customize the view including the number of rows, data scaling, and offset from UTC time. Another feature, not displayed here, is the ability to overlay the sun angle based upon a specific location or a simulation model for indoor studies.

Data Validation #

It can be difficult to translate such a subjective idea “active” into a measurable quantity. In our work we use accelerometers to measure movements and, based upon thresholds, determine whether or not an animal is active. This raises an important experimental question – how are the thresholds selected ? We have developed two tags, one capable of storing full-bandwidth accelerometer data in an external flash for 100-200 hours and another that only stores activity “bits” in internal flash. We use the larger tag to validate, with concurrently collected video, the decision process used to to determine “activity.”

Energy #

A dominant design issue is energy – both storage and delivery (rate) – and a significant fraction of the weight budget is consummed by a battery. For example, with a (5mAh) battery and insulating coating, the “BitTag” weighs (0.6g) . Smaller or larger batteries could be used depending upon the needs of an experiment, but the fundamental limit is roughly 20mAh/gram with the LiPo (Lithium Polymer) and LiMn (Lithium Manganese) batteries we use.

As we shall see, the choice of battery depends upon the tag hardware – the BitTags operate with LiMn batteries while some tags, notably those with external flash memories, require LiPo batteries which have significantly different operating parameters. In [link] we discuss the various energy storage options and their architectural requirements. In this document we do not consider energy harvesting – at the scale we explore, the added weight and complexity of any energy harvesting devices is likely to exceed their potential benefit.

Tag Infrastructure #

The physical design of tags is just a small part of the system design problem. To be useful, the tags require a support “ecosystem” that enables tag configuration, battery charging, and data recovery. This ecosystem includes both software (tag firmware, configuration software, data processing), and support hardware. For example, we have developed a “standard” hardware base to which tags are attached for configuration and charging. Variations in battery chemistry necessitate (small) hardware differences in the bases – we use two distinct types of batteries NiMn and LiPo. Fortunately, these hardware differences are opaque to the system software.

Of course different tags will have variations in geometry, thus our base architecture includes a 3D printed adapter that is tag specific. The adjacent image illustrates one such adapter along with the hand tools used to finish the commercially printed component. The tags carry a small array of “test points” (covered with insulation during flight) through which all base/tag communication occurs.

It is worth noting that we face a scale problem – supporting experiments with dozens of tags is considerably different than configuring and testing single tags. For example, consider that our partners need to prepare groups of 20-100 tags for flight simultaneously. Simply charging the tag batteries takes many hours (e.g. overnight), thus we have also developed chargers that can be “ganged” together and connected by a single USB connection.

The adjacent image illustrates three such chargers (only one USB connector is used per ‘gang’). These chargers can be built relatively inexpensively (under $50/each in small quantities).

Tag Configuration #

The tags that we build are highly configurable. For example, the BitTags can be configured with various “thresholds” for determining when the animal is active, different data aggregation choices (from 1 bit/second to active second counts per 5-minutes), and complex schedules including hibernation periods.

The primary tool that we have developed for configuring tags is the “Avian Tag Monitor”. This tool organizes Tag information as a set of tabs. The first tab, illustrated on the right, provides information about the specific tag including its current state, battery voltage, and clock error as well as details about the hardware and software on the tag.
This tab also provides various control actions and provides for data download.

As mentioned, the tags provide the ability to create complex schedules including start and end times for data collection as well as “hibernation periods” when data collection should be suspended.

Modern sensors provide many possible configuration options. For the BitTag, the accelerometer can be configured with various scales, sample rates, and thresholds for activity detection.
The Tag Monitor provides access to these configuration options.

The Tag Monitor software is highly configurable and is designed so that it can be extended to support additional types of sensors and data storage strategies. The specific options shown are automatically customized to the tag being configured. In addition, we provide support for batch testing and configuration of tags through separate command-line tools.

Flexible System Architecture #

The design of the tag hardware is really only a small piece of the system design problem – indeed, we can develop the hardware for a new tag (e.g. one with a different sensor) in a few hours. Integrating the new tag into the larger system consisting of the tag firmware, programming bases, and host software is the most significant challenge for customization. Thus, it is helpful to step back and consider a “generic tag” in the context of a larger system as illustrated below. The overall (hardware) system consists of a tag, a base, and a host computer. We assume that a tag has a a processor, sensors, (real-time) clock, storage, and power management. The base provides host access to program and configure the tag and download data, as well as (chemistry specific) battery charging.

In any such system, the most important architectural aspect is the definition of the interfaces between the major components. Standardizing these interfaces enables component reuse. For example, the tag/base (physical) interface utilizes
the ARM standard SWD (serial wire debug) protocol for communication. By utilizing this interface, our architecture can, in principle, support tags built with any ARM Cortex embedded processor. The physical host/base communication utilizes the ST Microelectronics stlink protocol over USB. By leveraging these existing interfaces, we can exploit off-the-shelf tools to program and debug tags. For example, we use openocd, an open source package that supports the stlink protocol, for programming and debugging the tag firmware. The only host device driver required is libusb, which is supported on large number of operating systems including linux, windows, and OS X.

Our system architecture leverages these physical and link-layer protocols (swd/stlink/usb) to support host-tag communication.
Host-tag communication is implemented with a simple remote procedure call (RPC) protocol that communicates through the SWD debugger interface with the tag processor and utilizes a feature of Cortex-M3 and Cortex-M4 based processors that supports “debug monitor” interrupts. The RPC messages are encoded with the Google Protocol Buffers message format. Leveraging Google Protocol Buffers enables the use of significant existing software libraries for communicating with the tag firmware. Furthermore, the protocol buffers standard enables (relatively) easy extension to support features of new tags. For example, to support configuration of a new sensor, it is only necessary to extend the configuration message with new data fields. By following Google design recommendations, it is possible to extend message formats while remaining backwards compatible. Thus, our tag firmware architecture limits the software fallout from adding or removing sensors and storage devices, and from creating experiment specific data collection protocols.