Regarding Observation 142796 I’m wondering what needs to change in the decoder to get more decodes.
Any thoughts? 73s C
Regarding Observation 142796 I’m wondering what needs to change in the decoder to get more decodes.
Any thoughts? 73s C
To get the decoder somehow more sensitive, I just changed the “Gain” setting of the LPF from 100 to 10. That does not help to decode every frame, but gets up to 80%.
I’m still working in this…
Hi Patrick.
That means there is a decoder for DUV implemented in Satnogs? How can I activate it? And: What does LPF mean?
Yeap Version 1.3.0 onwards for gr-satnogs has this.
Update to latest client and gr-satnogs! SatNOGS Client Ansible - SatNOGS Wiki
Understood - I have found the file I believe:
gr-satnogs/apps/flowgraphs/satellites/satnogs_amsat_fox_duv_decoder.py
And the code has two LPFs:
self.low_pass_filter_1 = filter.fir_filter_fff(100, firdes.low_pass(
100, audio_samp_rate, 195, 10, firdes.WIN_HAMMING, 6.76))
self.low_pass_filter_0 = filter.fir_filter_ccf(1, firdes.low_pass(1, audio_samp_rate, deviation+max_modulation_freq, 3000, firdes.WIN_HAMMING, 6.76))
Can you confirm it’s the first filter please?
Changing the DC blocker to a lower/higher gain (notch filtering) makes sense for better symbol recovery. I’ll have to check the .grc file too and see if there’s anything obvious there.
73s C
Yes, it’s the first one!
You could also use this one:
Hi @drchrisbridges,
the notch filtering should be quite steep, so the processing overhead may be larger. On the other hand, DC block is quite cheap and at the same time removed the DC offset of the quadrature demodulator that may caused by a frequency offset.
Theoretically speaking, playing with the filter gain should not affect the decoder due to the fact that it actually produces a scaled version of the signal. This should not have great impact as the float resolution is large enough. The RF performance remains the same as the analog gain does not change.
Unfortunately, there are some “absolute” thresholds so that’s way I suspect the gain affects the decoder.
Also, as I can see, the observation you mentioned has a frequency offset of some KHz. I will check if moving the DC blocker prior the second LPF increases the performance.
Hey @surligas,
Could you give a bit more explanation on the whole DUV Decoder?
I tried to modify a bunch of stuff to get it more sensitive, but reducing the gain was the only thing that made a change! I am still not able to decode every frame, but it’s a lot more than in the release.
I would really like to understand why things are realised the way they are.
There was a description that “Gain” should match “Decimation”, but from my little experience I have, this is not true.
Please switch on the lights
So changing the gain as suggested increased by packets collected from 1-3 to above 10. An improvement! But there are still passes that are not decoded properly.
@surligas I’m confused a little by your message but also agree too with the absolute thresholds in the decoder. The DC notch filter will affect the response as we’re taking ‘energy’ out of the system - to never be returned. This could use normalising afterwards for symbol recovery.
In Observation #142796 - it looks spot on to me with no freq error. Or am I reading this wrong?
Thanks! and 73s! C
The observation should be centered between the two lines in the signal.