Well, after a bit over a month… It’s probably about time to release 1.0.0 officially (NOT in alpha/beta status anymore! So, the following releases with go back to the regular naming scheme, so 1.0.1, 1.0.2, etc).
Of course, quite a lot has been done and fixed in the meantime.
Do note only major changes are listed here. A lot more did change, but listing every small change is not quite possible!
Favourite pipelines (by Zbychu)
Despite the search system, finding the pipelines you use the most could be a cumbersome. Zbychu hence added a favourite system, which will work in both offline and live decoding.
NOAA SEM support (by Zbychu)
Zbychu added decoding for NOAA’s SEM instrument, on DSB, HRPT and GAC. A few others improvements to the radiation viewer came alongside it.
This also included properly decoding timestamps for HIRS and AMSU, which will provide better projections.
There were quite a few (very valid) issues with the recorder. Most of them were related to the inability to save current settings for the device, FFT etc.
Now all the following is saved :
- Device selected
- Frequency (per device)
- Device settings (gain, samplerate, etc)
- FFT Settings
Samplerate is also formatted to be more readable.
Improved Proba-1 CHRIS & HRC processing
Proba-1 CHRIS and HRC frames now go through a CRC check, to avoid bad data sneaking through. At the same time, the image’s header is now utilized to identify images that need to be interleaved back into a full-resolution CHRIS frame.
Zbychu also updated composites on CHRIS to look better.
Proba-V imager support
Proba-V’s imager has been active again recently, hence it was possible to implement decoding.
DMSP RTD Support
DMSP satellites are actually transmitting in the clear over part of the US/North pole. This was discovered by LazzSnazz while trying to monitor something else.
SDR++ Server Support
In order to support more SDRs remotely, SDR++ Server support was implemented. Do not settings HAVE to be edited in UI mode first. Once set by the UI / In SDR++, it can then be used in CLI mode as well.
I had forgotten to implement it back. So that’s done now!
Microphysics composites for AVHRR (RAD750 PR)
A few new composites!
MetOp ASCAT Projection
MetOp ASCAT can now be projected and manipulated in the viewer.
Ensure full buffers are processed on exit
As the demodulator and decoder modules are now run at the same time by default, there is an additional buffer between then. It turned out, whatever remained in the buffer when the demodulator was done would not be fed to the decoder. This did not affect anything for most satellites, but very low-rate links (such as STEREO) were affected in some situations. Now, the decoder will always process whatever remains.
Folder selection in settings
Path options in settings were not file widgets, and would not allow selecting a file using a dialog.
Merging could really mess up in some cases, resulting in a garbage projection.
Stats server segfault
The stats server (in CLI mode), could end up requesting the same thing at the same time for several users (if 2 devices were trying to get stats at the same time), leading to a race condition and crash. Things are now kept as they should be through a Mutex. (Technically, that could low performances, but we’re not dealing with thousands of users).
Map overlay on corrected imagery
Overlaying a map on a corrected image could lead to “cuts” in the overlay.
Windows CLI parsing
On Windows, for some reason, using
long long for the frequency parameters and similar would result in it wrapping around to a negative value… After a lot of debugging with @crosswalkersam, this was figured out to be the casuse. Changign to
uint64_t fixed it.
Dataset for LRPT
LRPT would not open in the viewer after processing, as it would not be writing a
dataset.json, which is what tells further processing to do something.
GOES-R EMWIN images would be corrupted
Well, a small typo lead to inserting some gargbage data in the file… Oops. Somehow this was only an issue there, so not really sure how it was missed for so long.
Viterbi would get fed 0, leading the tail sometimes being affected
Viterbi decoding makes heavy use of SIMD (using Volk’s SPIRAL kernel). This also means the data is aligned, and can’t be of arbitrary size, but must be a multiple of a specific number (16 here). Hence, the last few bits, if not matching said condition, would have to be provided anyway despite not being of any use to decoding.
The impact was pretty much none in 99.99% of cases, but sometimes, as Fred Jansen experienced, it could end up not letting the deframer sync! It was really pain to debug, but the fix was simply not feeding Viterbi 0s, but instead erased symbols (that will be ignored by decoding entirely). Do note only a few sats were affected in that way.
Though, now, RS should also behave as it used to.