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 https://www.sensorgnome.net/download
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.
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:
A fresh Sensorgnome V2 software version is available! This is release candidate 15 chasing the mythical 2.0 release . 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 rtl-sdr.com 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:
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
Other:
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!
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.
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.
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…
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.
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.