Wanted to share some observations on my obtaining Hunity decodes of late. My standard approach to obtain satellite telemetry decodes is to use gr-satellites from @EA4GPZ in combination with a YAML satellite definition file. IMO, this is fantastic software! Thanks Dani. GitHub - daniestevez/gr-satellites: GNU Radio decoder for Amateur satellites
During satellite passes, I often record an IQ (CF32) file for further review and analysis. In the case of Hunity, this works well and allows for real-time decoding and results uploading to the Satnogs database.
For those interested in an alternative albeit more hands on approach, there is the Peter Horvath / smogcli2 · GitLab repository. This offers companion tools specific for the Budapest University of Technology and Economics family of satellites. This repository has now been updated to include tools for Hunity.
In the specific case of Hunity, I have observed that by using the hunity_decode (linux) executable more 126 byte frames may be extracted from the CF32 file. For example from a recent pass, 24 using hunity_decode versus 9 using gr-satellites were obtained. This may be due to differences in the algorithms or specific settings. Not quite sure. Perhaps @hodlemil, @ea4gpz or someone else can explain?
Frames obtained this way may then be uploaded to the Hunity telemetry server using the hunity_upload_from_file.py tool.
To upload additional frames obtained when using hunity_decode tool to the SatNOGS server, the file format has to be modified. To extract only the 126 byte frames and create companion hex and kiss files, a simple tool (shamelessly created with a lot of help from ChatGPT) called hunity_extract_frames_N6RFM.py may be found here - 457.8 MB folder on MEGA
Little doubt this can be greatly impoved upon!
Such an output frames kiss file may then be used to upload frames using the gr-satellites Telemetry Submit block. When doing so, be sure to verify the NORAD ID number being used, Currently 98537 for Hunity. Be sure that when doing so the timestamp is also correct. TKS K4KDR for gentle reminder.
Can you share the IQ then I will have a look if the deviation value(s) are correct, this could explain why the real time obs produce less frames, but as you suggested it also possible there differences in the algorithms.
It would be even better if someone from the team can provide the deviation values.
It is quite likely that there are some demodulator parameters that can be optimized in gr-satellites for this satellite via command line arguments (besides the deviation, which @PE0SAT mentioned). I don’t remember if smogcli does closed loop clock recovery or if it relies on syncword detection. If it does closed loop clock recovery (which is the same as gr-satellites does), then it should be possible to configure gr-satellites to perform similarly. If it does syncword detection then I can imagine some cases in which that approach would work better. In any case, as far as I know both gr-satellites and smogcli use the same FEC decoder, so the different is probably caused by the demodulator.
The smogcli decoder utility can actually use a viterbi demodulator (and it does by default for 50 ksps input ). You can disable it if you want, but comparing results with/without, it perform much better than the non-viterbi demod. ( > 4x more packets decoded properly ).
AFAICT what it does is look for constant tones ( preamble ), then use that to estimate the frequency offset and compensate for it, then, looks for sync and once that’s found and aligned, run virterbi soft demod.
