It’s exactly one week since the “rework”, or 1.0.0 was released publicly as an Alpha. As promised, today a new official release is being released. This release is for 1.0.0 Beta, or the second (and normally) last test public release until an official 1.0.0 release is made, most likely again in about a week.
Making it an Alpha release initially had the sole intent to make it clear that despite all the work that has been put into it, things have not gone through public scrutiny yet - and users are good at finding bugs that ain’t as obvious during development! Quite a few oversights and other bugs have been found and addressed. However, as some things may not be fully resolved yet, we’ve decided to keep this week’s release as experimental, hence the Beta status.
This article aims at covering the changes that were made - so let’s get started!
For compatbility with other software (as raw and custom formats are really only usable easily in SDR# or GNU Radio), a contribution by Blobtoe now allows SatDump (both in the UI and CLI) to record directly to .wav file.
I can’t guarantee this is perfectly functional for everyone yet - there may be a bug in the library utilized. But this allows using HTTPS for your map tile server, which previously had to be HTTP. Some other changes made by Zbychu allow customizing the URL further to support using different servers (which often use different url format), such as satellite/aerial image tiles.
Alongside that change, tiles in JPEG format are also supported now.
As of now, SatDump could exclusively load .png images (such as in the projection system) or export in PNG format when using some save function. That is not longer the case after some requests from Dario.
From now on, when saving an image you can change the extension to .jpg/.jpeg and JPEG will be utilized instead of PNG. No other format is current supported - but depending on requests it surely could be considered.
During the rework generation of .hpt/.C10 files had been removed, and honestly until it was pointed out it’s something I had entirely forgotten about it. After requests by Serge, this was added back as an option.
It turns out I made an oopsie when re-implementing RTL-SDR support… Forgot to multiply the gain by 10 (as it takes 10th of a dB). Hence, max gain would barely be 4.9db instead of 49!
Despite more than 4 years old, Ubuntu 18.04 and similar systems are still widely used. It turned out that some of the newer code had to be slightly modified to still compile on those older systems. That’s fixed thanks to K4KDR pointing it out!
A rather funny bug as Zbychu would say : It has made Brussels wide.
It turned out that I had fogotten that when both the map overlay and curvature correction were combined (which results in the image stretched on the sides), the actual map overlay and cities labels would get stretched as well! Oopsie.
But anyway - it’s fixed.
On older hardware or boards like RPIs, launching the UI could be a challenge due to OpenGL support. Now, several versions are tried and a patch has been implemented for the Raspberry Pi (3b+, the 4 is not affected).
All projections and map overlay rely on timestamps the satellite provides alongside the data. The downside is, there’s no easy way to “check” them at all for corrupted bits on many satellites… And applying what could do so on others may significantly impact decoding at lower SNR.
Accurate timestamps are key to a proper projection (unless the old algorithm is utilized. That one will not be as affected) or map overlay, as a single bad timestamp might (depends…) kill it entirely. To get around this issue and perform some filtering, I have a (rather) basic algorithm checking through timestamps and discarding inacurate ones. It’s not perfect, but has performed rather well as of now.
Before, it was only applied on satellites that lacked error-correction. Now, it’s systematically done all the time (tuned for each instrument of course) to ensure things won’t go bad on an otherwise nice pass due to an unfortunate corrupted bit! (Though, at low SNR, still do not expect something perfect of course)
It turned out that in some cases I had not been able to test (or forgot), the MetOp and FengYun-3 decoder may end up getting stuck in a bad state. Egor UB1QBL and Serge reported the issue, and from testing on my side things now appear to be fine (and should be). This did not impact decoding performances.
I did lower the locking thresold slightly on FengYun though. Not a huge difference but may help in some cases!
Some instruments, especially Aqua/Terra MODIS and FengYun-3 MERSI have several channels at different resolutions. It turned out I had forgotten to resize them before feeding the rest of the algorithm leading to funny results… Fixed as well of course!
Due to the heavy changes to the projection system, configurations I had previously for most satellites (METEOR-M, NOAA, etc) were no longer accurate and needed to be re-tuned manually. This has been partially done, and I will continue to do so along the way and whenever I have the data to tune it.
Thanks to reports of that, it is now fixed. Please report such issues (on any satellite / instrument) and I will work on it shortly! Though most HRPT satellites should be mostly OK. X-Band has not been fine-tuned for the main imagers (MODIS / MERSI) yet.
ZIQ will now be enabled by default - if the dependencies are present of course! So don’t be scared of any extra steps if you do not need that functionality..
A bug popping up on some images (that had 0s, or total black) could make the merging process mess up… Fixed. (It’d cause weird colors in some places!)