Sensorgnome V2 status & releases

This thread is intended to capture announcements about the Sensorgnome V2 software and I will try to keep this first post updated to reflect the latest status. For questions/comments please feel free to reply to this thread.

Latest Release Candidate

The latest RC version can be downloaded from
It currently is RC15 produced June 6th 2024.
The post with the releas

Latest development build

Development builds have the latest new features but are not nearly as tested as RC versions. I cannot recommend the installation of dev builds on stations that are not closely monitored or cannot easily be upgraded to fix an issue. The primary purpose of publishing development builds is so others can test the new features.

The latest development build is 2024-157 and can be downloaded from (it is identical to RC15)

The major new features since RC15 are:

  • identical to RC15

Installation pointers

Please connect your Sensorgnome to the Internet (ethernet, wifi, or cellular): it provides a wealth of monitoring data and makes troubleshooting and helping you sooo much easier!

Upgrading from 2023-XXX or RC12-or-earlier

Before being able to upgrade the software repository key needs to be updated: SSH into the SG (user gnome) and run the following command (all one line), after that the upgrade button in the Web UI will work as usual:

sudo curl -L -o /etc/apt/trusted.gpg.d/sensorgnome.gpg

Sensorgnome V2.0-rc15 release (2024-157)

A fresh Sensorgnome V2 software version is available! This is release candidate 15 chasing the mythical 2.0 release :laughing:. This release has significant improvements over previous versions for stations with 3 or more FUNcubes in terms of monitoring their sample rate and restarting them if there is an issue. On the RTL-SDR side this release brings improvements as well, in particular to increase sensitivity, to support the V4 version, and to fix issues with E4000-based versions (NESDR XTR). It also has usability improvements for showing the signal strength of Lotek detections. The complete list of changes:

FUNcube reliability:

RTL-SDR support:

  • support (“blog”) V4 dongle
  • changed pulse detection for rtlsdr to 6dB to match FCD (this may increase noise pulses, TBD)
  • support turning on bias-tee in acquisition.json for RTL-SDR (was already supported for FCD)
  • for RTL-SDR E4000 tuner pick the next higher tuner_gain if an invalid value is set in acquisition.json (it was using a low default gain)
  • add IF (intermediate frequency) gains for RTL-SDR E4000 tuner to acquisition.json (this improves the tuner’s sensitivity)
  • added experimental AGC for rtlsdr, disabled by default, display current gain


  • fix for Pi3 for Adafruit/MTK GPS
  • make timeseries on radio page more robust to time jumps
  • display SNR for Lotek pulses and tags (text pane and new chart)
  • add toggle to hide pulses from tags&pulses panel
  • upgrade to RaspberryOS 2024-03-12 base image
  • display cell IMEI
  • add serial output feed capability

If you have a test station or readily accessible station in your back yard I would very much appreciate if you could install this RC or upgrade to it and keep an eye out for things that don’t work. Thank you!

Please download from and see installation pointers in the first post of this thread.

Thanks Thorsten, I was very much looking forward to this Release Candidate and it’s SNR information!

Upgraded via the local user interface (UI) and also by burning a new image. Both worked well. As expected the UI method left about 108 system files that needed upgrading while the new image with its updated RaspberryOS 2024-03-12 base image had zero files needing update. Nice to be up to date.

The SNR plot looks very useful (as does the new SNR information in the “Tags and Pulses” text.

Now to find time to test some prefilters and a homemade J pole antenna.

Thanks again!


1 Like

First two SG_Ugrade’s went well. The first station has two Lotek antennas on a 4 port USB hub. The second station has three Lotek antenna’s on a 4 port USB hub

Third station now has an error message I haven’t seen before.

when I click on the red “ERROR” button I get

This station is RPi 4B, using two 4 port USB hubs: 1-4 Lotek, 5-8 CTT.

Any ideas?

1 Like

Yup! Please read about the FCD issues and my rPi recommendations: FUNcube sample rate dropping and disconnecting - FIXED. The new software is highlighting problems that went unnoticed before (at least that’s what it’s looking like). You may have better luck if you spread the FCDs across the two hubs. But it may also be a different issue. I’ll take a look at the logs when I have a moment.

Update, looking at syslog:

Jun 16 00:01:53 localhost kernel: [4174395.837152] usb 1-1.1.4: reset full-speed USB device number 16 using xhci_hcd
Jun 16 00:01:53 localhost kernel: [4174396.010931] usb 1-1.1.4: 1:1: cannot get freq at ep 0x81
Jun 16 00:01:53 localhost kernel: [4174396.011196] usb 1-1.1.4: Not enough bandwidth for new device state.
Jun 16 00:01:53 localhost kernel: [4174396.011214] usb 1-1.1.4: Not enough bandwidth for altsetting 1

First line is reset of the FCD, second is a normal “error” message, third and fourth tell the story. I haven’t tried 4x FCDs on Pi4B, you may be able to get it to work by placing 2 on each hub if they actually are Multi-TT hubs. If they aren’t, each hub can only take one FCD, see that other thread I linked to.

All this is why I’m trying to make the RTL-SDRs work as well as the FCDs…

Thanks for that Thorsten. An interesting read. Good work you guys.

Lol, those FunCubes are pretty expensive tech to be using the very old USB 1 standard.

Rebooted, and so far no more errors! However the sample rate for port 4 now shows zero. Sigh.

The next time I’m out at the station, I’ll try a few things (and bring along an
RTL-SDR or two).

Update: Just checked the R files for that station… indeed positive and false positive Lotek tags have been seen only on ports 1 thru 3, none seen on port 4. Looks like this station has had this port 4 issue for a while and the new software has made the issue obvious enough for me to notice. Thanks.

I have a couple questions about the upgrade process, specifically as it relates to over-the-air upgrades on cell or other metered networks.

  • When updating over-the-air, is this more of a patch applied to the existing image or a completely new image? I’m assuming the former given the size of the image (1 gb compressed) but perhaps that’s not the case.
  • There is a train option in the UI to select whether the stable or testing versions should be downloaded. But I don’t see an option whether or not to download updates over the air in the first place. This obviously relates to the first question, and if the upgrade is only a minimal patch, it’s sort of a non-issue, but if the download might be substantial in size, it could cause issues on a cell or metered network. I don’t think I’ve noticed many or any version changes on cell connected stations so maybe OTA upgrades don’t occur on cell networks to begin with.
1 Like

There currently are no automatic upgrades. Upgrades only happen when a user clicks on the “check” and “upgrade” buttons. And the upgrade entails downloading the debian packages that are to be upgraded, there’s nothing proactive that downloads them ahead of time. The image remains the same and unfortunately there are subtle differences between a fresh install of a new version vs. upgrading to a new version. I try to minimize those, but sometimes it’s not simple, especially when something users can change gets upgraded.