SakeTami
sondehub
sondehub

patreon


Why and how we block old software versions

Summary

If you are using rdz_ttgo_sonde software - upgrade to 20230427 /  0.9.3  or beyond ASAP. Failure to do so may prevent uploads to SondeHub.

Why and how we block old software versions

Blocking uploads from old versions is not something we like doing. We try to avoid it where possible. However in certain cases bugs in decoders and software result in incorrect data being uploaded to SondeHub. This can take the form of:

As decoders are based on reverse engineering and written by many people in the community these bugs and decoder quirks are very easy to end up in software and cause inconsistent data to end up in SondeHub. We try our best to reach out to developers to get these fixed up (and thank you to all the developers who work with us!). It's hard to test across the shear number of different radiosonde types so it's easy for mistakes to happen.

Here's an example DFM temperatures being decoded differently between auto-rx and rdz_ttgo_sonde.

When we detect issues with a various version we give some time for developers to debug, fix and release a new version. We then also wait a period of time for users to upgrade. This is why it's important that you try to keep your software up to date!

Next we try to identify if the issue only impacts a certain radiosonde type. If the issue is only with a specific type of radiosonde we limit the version blocking to that type.

Why don't we decode radiosondes on the backend?

We've looked into the possibility of decoding radiosondes in the backend. The idea behind this is that a basic demodulator would decode the bits in a radiosonde frame and then upload it SondeHub to perform the decoding. Doing this would mean consistent decoding of the data. This type of decoding would likely work for some radiosonde types like the RS41 where most of the data is encapsulated in a single frame of data.

However for other radiosonde types it would require keeping state between frames - this would require some amount of time sync to work with multiple stations and processing of messages in order. Something that's a little tricker to arrange at our scale. Maybe one solution might be to upload long overlapping bitstreams.

This becomes a much harder and complex task than the current process. Something we haven't given up on, but it's not something we are actively working on due to the complexity.

rdz_ttgo_sonde 0.9.2

That brings us to rdz_ttgo_sonde 0.9.2. This version of rdz_ttgo_sonde misidentifies DFMs causing the PTU data to be incorrectly calculated. The issue has been fixed since April however a large number of users are still on the old version.

If you are using rdz_ttgo_sonde 0.9.2 please upgrade. If you know of people using rdz_ttgo_sonde 0.9.2 please ask them to upgrade. We will eventually be blocking uploads of DFM radiosondes on 0.9.2. This post has been made public so you may share it with other users.

There are still a large number of users on 0.9.2 and we'd like to see the number drop.

Comments

Right after I upgraded :) thank you for all your hard work!

Patrick van Staveren

We did end up blocking DFM sondes on 0.9.2 about 3 weeks ago - https://github.com/projecthorus/sondehub-infra/commit/3e849d26062e90778d25a6244ccc35039d68b0e7 ~ Michaela.

SondeHub

I ran 0.9.2 for many months after this was found and never noticed my telemetry getting blocked. I've updated now :) Did you end up blocking 0.9.2? The Software Versions chart still shows a hefty amount of 0.9.2 out there.

Patrick van Staveren


More Creators