RAD2 (Research Activity Detector version 2)

The data collection is going well!  We built 5 devices and placed them in mouse cages for the last week.  There is a nice circadian rhythm in behavior (mice are more active at night).  Check it out here!

Example activity trace:

There's a lot we can look at in this data but for now our next goals will be validation/calibration experiments for the sensors, and scaling up to more devices.

We made a quick 3D housing for RAD2.  Our primary application is in rodent caging, and we found that they chewed the device up pretty quick when we taped it in the cage without a housing.

So we made a housing, let's see how it holds up!

RAD2 has onboard datalogging capabilities, so it can be used as a very low power device.  However, it is often convenient to access data in real-time.  As RAD2 is Feather compatible, it can be used with any WIFI, BLE or other wireless Feather. 

We have been using it with the MCCI 4610, a Feather compatible LoRaWan radio board. 

We send the data from each device to the Things Network through a gateway, where it is stored in an InfluxDB database, queried by NodeRed, and visualized with Grafana.  Instructions on how this works are here.


Example interactive dashboard can be found at www.mouserat.org:

Some excellent thoughts on timekeeping by Terry Moore!

Timekeeping is a thorny topic for scientific investigations, because one day is not exactly 86,400 seconds long. Obviously, the difference between two instants, measured in seconds, is independent of calendar system, but converting the time of each instant into ISO date and time is not independent of the calendar. Worse is that catena-message-port1-format-22.md 10/19/2019 computing systems (e.g. POSIX-based systems) focus more on easy, deterministic conversion, and so assume that there are exactly 86400 seconds/day. In UTC time, the solar calendar date is paramount; leap-seconds are inserted or deleted as needed to keep UTC mean solar noon aligned with astronomical mean solar noon.

In effect, the computer observes a sequence of seconds. We need to correlate them to calendar time, and we need to interpret know the interval between instances. Let's call the sequence of seconds interval time, as opposed to calendar time. Let's also define an important property of sequences of seconds -- "interval-preserving" sequences are those in which, if T1 and T2 are interval second numbers, (T2 - T1) is equal to the number of ITU seconds between the times T1 and T2. Since the RTC runs in calendar time, but we do all our work with interval time, we must consider this.

1. 1. Keep interval time interval-preserving, and convert to calendar time as if days were exactly 86,400 seconds long. (GPS is such a time scale.) Differences between instants (in seconds) are in ITU seconds.
2.  Keep interval time interval-preserving, but convert to calendar time accounting for leap seconds (most days are 86,400 seconds long, but some days are 86,399 seconds long, others are 86,401 seconds long). (UTC is such a time scale.) Differences between instants (in seconds) are in ITU seconds.
3.  Make interval time not interval-preserving by considering leap seconds. A day with 86,401 ITU seconds will have two seconds numbered 86,399; a day with 86,399 ITU seconds will not have a second numbered 86,399. Convert to date/time as if days were exactly 86,400 seconds long. The difference between two instants (in interval time) is not guaranteed to be accurate in ITU seconds.

Steve Allen's website has a number of good discussions, including:

1. Issues involved in computer time stamps and leap seconds

2. Two kinds of Time, Two kinds of Time Scales

The onboard real-time clock counts in "calendar" time, and will be set by people (again in "calendar" time) from watches etc. that run from UTC or a derivative. We will assume that the user can input the time in UTC and that the battery-backed RTC is recording time in UTC. Therefore, we use a timescale that simply states that days have 86,400 seconds. In this application, we think that this will be good enough. If we ever start to use LoRaWAN ("GPS") time, we assume that the network will be able to send us the information needed to convert to calendar time as needed. This may add a little complication but it's future complication and we'll deal with all this if the need arises.

We have been testing the latest build of our RAD2 with a Feather-compatible LoRaWAN board from MCCI (the 4610).  This board contains a LoRaWAN radio for streaming data as well as three built-in environmental sensors (temp/humidity, light, and pressure).  All functions appear working!  To recap that's:

1. PIR motion sensing
2. RTC set and functioning
3. Datalogging to microSD card
4. All 3 signal LEDs lighting up
5. In addition, because we're using the 4610 we get light, temp, and humidity measurements built in

Here is a ~24 hour sample of temperature data (peaks are me picking up and holding the device):

And some activity data from the PIR (this device was placed on my desk, note when I came in to work at ~9am): 

Stay tuned for some longer datastreams!