Observation 142796: FOX-1B (43017) Y no decode?

Regarding Observation 142796 I’m wondering what needs to change in the decoder to get more decodes.

Any thoughts? 73s C

1 Like

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…

1 Like

Hi Patrick.

That means there is a decoder for DUV implemented in Satnogs? How can I activate it? And: What does LPF mean?

Yeap :slight_smile: Version 1.3.0 onwards for gr-satnogs has this.

Update to latest client and gr-satnogs! https://wiki.satnogs.org/SatNOGS_Client_Ansible#Updating_SatNOGS_Client_software

1 Like

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

@surligas can answer on that one :slight_smile:

1 Like

Yes, it’s the first one!
You could also use this one:

1 Like

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.

2 Likes

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 :wink:

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

1 Like

The observation should be centered between the two lines in the signal.