The importance of updating boot numbers following a fresh SG installation

Announcements
1

Hello Motus collaborators,

We have an important message/ reminder regarding data processing for SensorGnomes following a fresh installation of the SG software.

As many of you will know, SensorGnomes record an incremental boot number in the name of detection data files. This boot number is used during data processing to correct for bad GPS timestamps and to link together long detection runs that are spread across multiple data uploads.

Given this, there is an assumption made during data processing that the boot number will always be incremental. In nearly every case, this is true, with the exception of when completely fresh software is installed on an SG. A fresh installation will reset the boot count to zero and, since that will then violate the assumption that the boot number will always increment, can lead to missing or false detections in some cases.

For Raspberry Pi SensorGnomes running V2 Software

If running the V2 SensorGnome software, you can manually update the boot number following a software upgrade. That option is available on the “software” tab of the web interface. There is more info on this here: Software upgrade | SensorGnome User Guide

If you are running version 2024-XXX or later, and are upgrading the software over the internet, the boot number will be correctly incremented automatically. [SG versions 2023-XXX and earlier require an extra step.

For all other SensorGnomes

If you cannot, or would prefer not to, run the V2 SensorGnome software, there is currently no method of updating the boot number following a clean installation of the SG software. However, see below regarding reruns/ reprocessing.

In ALL cases

When a receiver’s data is reprocessed (also referred to as re-running), the correct boot number sequence is restored and any spurious or missing detections resolved – assuming all tag deployment metadata is up-to-date.

There is more information about receiver data reprocessing here: Reprocessing receiver data | Motus Docs

2

I just want to make sure that I have my head around this. Here’s my situation – in the last month or so I outfitted three CTT V3 SensorStations with BluSeries receivers and 2.4GHz antenna arrays. As part of that work I updated the stations’ compute module, as outlined here…

Would that cause this incremental boot number issue? If so, what should I do now?

Thanks!

Chris Spurgeon, Pasadena Audubon

motus@pasadenaaudubon.org

3

Hi Chris, currently the only way to modify the boot number is on the V2 SG, which hasn’t yet been ported to the SensorStation (they still use the V1, which works well enough, but lacks some of these additional features).

And to confirm, this should only affect the period between the software update and the first rerun. All the boot numbers are corrected in the proper sequence when the receiver data is reprocessed, which usually happens several weeks after the data is first uploaded.

4

Hi Josh, I missed this when i installed a new SD card on SG-77BFRPI4B4A1 over a year ago, the current boot number is now 6260200032. TransAlta power does have issues at that location but I don’t think they have tripped 6 billion times. ;) Unfortunately the SG-HUB only goes back a year so I’m not sure as to what the boot number should be.

Any suggestions as to a pathforward? Perhaps the server still has the boot number from the original SD card in historical files?

Mark

5

Hi Mark, this only applies between the time the data was first uploaded and the first rerun. Once the data has been reprocessed, the proper boot number sequence is restored. So yes, the necessary details will all be on the server and you shouldn’t be affected.

6

Okay, so just leave as is? I was concerned that such a large boot# might be causing your system grief, perhaps creating a too long filename.

7

Josh, are there plans to allow users to see when receivers from other projects were rerun? It’s difficult to vet the trustworthiness of the hits if there may have been boot number issues causing mis-aligned metadata, which seems likely to occur from time to time if none of the SensorStations can have their boot numbers corrected.

8

That would be helpful, I agree. At the moment, though,.the pages to view this are only available to members of the receiver project.