This update, unlike previous ones, includes a lot that’s more under-the-hood… So while it will appear smaller, it isn’t especially that much smaller!
Things that are still too WIP to be mentioned, or not relevant anymore will not be mentioned (eg, BlueWalker-3 being encrypted).
While the downlink themselves could already be processed down to CADUs, imagery was not yet decoded due to quite a few quirks that took a while to figure out (see https://github.com/altillimity/SatDump/issues/167).
A decoder for the imagery is now present, which will be able to decode un-encrypted imagery downlinked on LRIT and (very) ocasionally on HRIT as far as we currently know.
As of now, there are 2 IR channels as well as 1 high-resolution (10k PX) VIS channel present, though no good data from VIS was obtained yet.
Though despite the imagery now being decoded and supposeddly being classic JPEG-2000, the data seen as of now does seem slightly… Off? While it is possible this is just how it is sent, more testing has to be done. I would highly encourage anyone able to received it to collect data :-)
Thanks to @MeteoOleg providing a sample, it was possible to confirm the downlink parameters and hence the decoder(s). Things should all be ready for when some payload data gets downlinked!
Support for the nearly-identical S-Band telemetry link was also added, but no interesting data has been identified yet and likely won’t before things get started up on the satellite… And even then, chances are it will be housekeeping only.
Thanks to dumps received by @lazzsnazz, the 4 CIPS cameras onboard AIM can now be decoded. Unfortunately, you still have to be quite lucky to get some interesting imagery!
While initially only one of the 3 Végétation instruments onboard Proba-V was active, now all 3 downlink data nearly daily again. Hence, the changes necessary to support them all were made.
A lot of satellite frequencies were missing. Thanks CrossWalkerSam and OK9UWU for adding them!
It was possible for the decompression algorithm to throw an error and prevent further decoding.
@theverygaming PR-ed a fix for an extremely rare, but possible crash when a PlutoSDR would be disconnected. He also added an option to automatically reconnect when using it over IP.
It was not possible to select an OpenCL device (if you had more than one) in the GUI on Windows.
Fred Jansen and @PeterMeteor experienced a Windows-specific bug that could lead to the LimeSDR source locking up. This is now fixed! A similar fix for potential simialr bugs on some other SDRs was also applied.
Well, that would be too long to describe them all… But a bunch of details that could lead to crashes / other bugs were fixed.
All xRIT satellites share a common protocol down to a certain point. Due to how things were done in the past, a lot of this otherwise identical codebase was copy-pasted for each and every satellite… Not very easy to maintain!
Therefore, I have made the code for GOES-N/R, ELEKTRO-L, GK-2A and FY-4 common. Though, I plan on going further and making the file structure, filenames, and so on common and customizable as well, most likely to be done in the next release.
The M&M clock recovery algorithm used to demodulate most satellites was still using some taps generated a while ago. So, with @Ryzerth advice I changed them out for Nuttal taps. This resulted in slightly more stability on the clock recovery’s side.