It initially wasn’t planned to release 1.0.3 so soon, I still had some other plans. But with the amount of requests following JPSS-2’s VIIRS instrument now being active, APT support and so on… I guess it’s time.
As I said in my initial announcement of this feature… Ironically APT was by far one of the most requested downlinks to be supported.
Well, support has been implemented down to the ability to project the imagery like many others satellites.
Please excuse the noisy APT. My VHF ain’t great here!
It can processed either from the usual .wav audio files, or from baseband directly like any other satellite in SatDump.
The FFT and waterfall have undergone some pretty major rewrites.
First of all, the palettes can now be changed by the user. The format is identical & compatible with SDR++’s .json, so you can add/write more than the 3 ones currently included if you wish to do so.
The algorithm in itself has also been heavily modified, so the behaviour IS very different, but this comes with performance improvements, customizability and so on.
The main parameters to play with and balance will be the FFT Rate (how many are done and averaged per second), and averaging. The higher the rate and the higher the averaging, the smoother and clean it will look, at a (pretty minimal) performance cost. Less averaging is better to observe fast-changing signals, but it will not look as clean, etc.
Feedback on the FFT changes / Suggestions will be greatly appreciated :-)
Projections configurations set by the user in the viewer will now be saved, in order to not require re-entering everything everytime.
The newly-launched MATS satellite - focusing on similar observations to AIM - has started transmitting payload data.
Further processing will most likely be implemented later on.
Demodulators have a somewhat strict valid range of input samplerates, depending on the symbolrate (how wide, sort of) of the signal. If outside of this range the demodulator can perform well in, the baseband has to be resampled to match a valid input samplerate.
There was a bug in there which would only affect some rare users going outside those bounds, leading to a crash.
The librtlsdr version provided on Windows had some major bugs. Control of the 2 AGCs was also added for good measure.
Older machines / GPUs on Windows very often do not properly support OpenGL 3.x. A patch was implemented to work around the issue and start anyway with an older version, but NO guarantee can be made about the resulting usability depending on the specific hardware.
Well, turns out my “3 AM” fix last time didn’t work due to a simply and purely dumb oversight. Fixed though.
Fixed some old bugs due to Windows-specific behaviors. They affected ZIP decompression, Rice decompression (due to a bug in the Windows C++ libraries…) and some EMWIN products.
An old bug nobody had noticed until @RAD750 did. TLEs would be erased if the update failed (due to a lack of network access for example).
The SDRPlay API can sometime carry on writing buffers a bit after asking it to stop. This, when the rest of the DSP was expecting to be dropped could lead to unexpected behaviour. This was worked around by preventing any further writes once things should be stopped.
Changing composites did not lock other functions, so doing both in combination could lead to a crash.
The microphysics, and other composites such as a snow enhancement for MetOp were added. Thanks for the PRs!