Works but only with specific sample rate

[marrem]

Hi Tim,

I have run the project with a SDR RSPdx via Soapy remote.

With the default sample rate of 1M I get:

... and ...

... which look good.

But when I lower the sample rate to 384k, which should be more than enough to receive on TETRA channel I get:

... and ...

The 'coarse' looks OK, but the constellation doesn't.

I have looked at the tetra_demod block. It seems to calculate all the ratios from the input sample rate. So changing the sample rate shouldn't make any difference, as long as the bandwidth is enough.

Do you have any idea what explains the difference.

One further question, what can I do with the data coming from the udp sink?

[Tim---]

Hi !

Good remark, the block does all the sample rate calculations indeed but... it turns out that in the main flowgraph, the "samp_rate" parameter of the block was hardcoded. Oops. This is fixed in f1f7d7c.

I have one question by the way, did you have to mess around with the grc files to work with your version of Gnuradio ? This repo is kind of old, I will probably take the occasion to update it if it doesn't break GR versions still in use.

Finally, with the bits extracted from the flowgraph, I think you can feed them to tetra-rx from osmo-tetra which was updated the most recently. It will decode the protocol and you can pipe it to Wireshark. I also implemented parts of the protocol in https://github.com/Tim---/pytetra, but it looks like old Python2 code.

[marrem]

Hi Tim,

You're right, I missed that. I have changed to value on the demod block from 1e6 to samp_rate. Now it also works with 384kHz sample rate.

I use grc 3.10.6.0. I had to replace some blocks by their gnuradio 3.10 equivalents. I also changed osmosdr to SoapySource (Remote SDRPlay RSPdx).

I had to change:

• blocks_udp_sink: replaced by UDP Sink
• fractional_resampler_xx: replaced by Fractional Resampler
• filter taps: window: firdes.WIN_HAMMING: replaced by: Hamming

That was it. So not too many things changed.

One more question:

Shouldn't the dots be at [1+1j, -1+1j, 1-1j, -1-1j] rather than 0.5+0.5j, etc.

[Tim---]

Thanks for your inputs, I updated the code (bffde3b).

You're right on the amplitude, it should be properly normalized. I don't know if it affects the other blocks, but at the very least DSP teachers won't try to beat me on my way home.

Apparently the "Feed-Forward AGC" was the culprit ; it scales the values so that they do not exceed 1 in a moving window of N samples. I replaced it with the "AGC" block in 9836a4a. I set the rate so that it can calibrate over a timeslot, but the exact value should not matter.

(note that the dots are not on ±1±1j though, but on the unit circle)

[marrem]

I have pulled in your changes and:

That looks better, and easier to decode by the constellation decoder.

(note that the dots are not on ±1±1j though, but on the unit circle)

So 0.707 + 0.707j, etc. But why has the constellation object used by the decoder the 'constellation points': "[1+1j, -1+1j, 1-1j, -1-1j]" ?

[Tim---]

Apparently that's the default constellation for QPSK in Gnuradio.

But it turns out the scaling doesn't matter for the Constellation Decoder block used with *PSK. For each sample, it will try to match against the closest point in the constellation. So even if you set your constellation to [±1000±1000j], the samples in the top-right quadrant will still match the symbol 0, etc. It would be different for QAM modulation where the magnitudes should match properly.