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.
Development builds have the latest new features but are not nearly as tested as release 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.
I just discovered that the my.local-ip.co service that the SG is using to get HTTPS certificates is broken and very likely dead I was concerned about that when I originally started to use it but I thought I shouldn’t reimplement everything. Well, here we are…
The current effect is that your browser will present you with an expired certificate warning, which you have to click through. This has been the case for over a month. It is also possible that the web UI stopped working for some SGs, I can’t quite tell. If that happened to yours please reboot or contact me for help.
I noticed because I wanted to turn the last release candidate RC15 into the V2.0.0 release but with this turn of events that’s not in the cards, so I will prepare an RC16 ASAP, which will switch the URLs to something else. Sigh.
I was building a new SG this week and i could log into it on the initial hotspot attempt but on subsequent attempts i received an incorrect SG password error. Both on my phone and laptop.
To remedy that i just included the wifi name and password in the SD card burn, rather than configure the wifi name and password after logging in through the hotspot.
I was going to dig into it a bit more but got distracted by something shiny.
That seems like a different issue. The HTTPS cert issue would produce issues with the site not being trusted by the browser and such, not a password problem. Did this happen multiple times?
Sooo, local-ip.co is working again… I had sent them an email and they responded. I think the best thing is to proceed with the V2.0.0 release as planned and then figure out what to switch to. The certificates are valid 3 months, so that gives some time, plus they’re currently still responding to issues so unlikely to discontinue the service in the very near future.
The background on all this is that browser security doesn’t offer any good solutions for local servers (not having a public IP address). The two options are:
duplicate what local-ip.co provides, which would be hostnames like https://192-168-1-34.my.sensorgnome.net
or SG-specific hostnames, like https://SG-1234RPI45678.sensorgnome.net
The latter would be more secure in that it prevents man-in-the-middle attacks but it has the downside of exposing the local IP address of all SGs, which is something some organizations don’t accept. Pick your poison
After 2+ years it’s finally time to put a stake into the ground and call it 2.0!
(Otherwise my sanity will completely disappear… )
Jokes aside, the V2.0 release is essentially unchanged from the last release candidate rc-15 (aka 2024-157) the goal being not to give me opportunities to mess it up. There are lots of thing to improve, a pile of bugs waiting to be found, and it’s not perfect by any stretch of the imagination, but a good number of Sensorgnomes have been running rc15 and they seem to have fared better than any previous ones.
I did fix one bad bug, which is that earlier this year I messed up the baud rate when connecting one of the old CTT dongles, the ones with a long cable and a big USB connector housing that actually has a USB-serial converter inside. I checked and only a very small number of online SGs use those old dongles and they were on versions prior to the bug. Also, the dongles didn’t work at all, so any testing would have surfaced the issue (and nobody installs stations without at least minimal testing, right??? ).
Anyway, the release is V2.0.1 'cause 2.0.0 got a bit messed up due to the local-ip.co scare. I would very much appreciate if some of you could give the new version a spin soon and report any issues. If you have a Sensorgnome running rc15/2024-157 I don’t recommend upgrading (don’t fix what ain’t broke) but older versions would be good to upgrade once 2.0.1 “settles in”.
. 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 
I was concerned about that when I originally started to use it but I thought I shouldn’t reimplement everything. Well, here we are…
)
).