Re: Osmocom Source (frequency deviation)

[Artur Nogueira]

Just one more comment: there is an additional low-pass filter when I use the mixer. The goal is to eliminate one of the frequencies resulting from this process (i.e. 2 x f_offset).

Em qui., 25 de jun. de 2020 às 10:35, Artur Nogueira <artur.nogsj@gmail.com> escreveu:

Yes, you're right: 2000 samples is too much. I made measurements with different numbers of samples (2, 500 and 2000) because I was afraid a very slow number (e.g. 2) could cause aliasing in the base-band.

Regarding the offset, it is indeed constant and for experimentation.

I had not realized before this correction field on the Osmocom block - I'll take a look at it; thanks.

What I'm trying to do is to apply a mixer tuned to the offset frequency after the Osmocom Source block. The result seems to be ok:

Without the frequency correction:

With the frequency correction:

Do you think this is reasonable?

Em qua., 24 de jun. de 2020 às 18:32, Jeff Long <willcode4@gmail.com> escreveu:

By the way, 2000 samples per symbol is kind of high. It's usually something like 4.

Also, if the frequency offset is constant and this is just for experimentation, you can use a frequency translating filter, or possibly the frequency correction field on the osmocomm blocks (can't remember if it's passed through to the hackrf code).

On Wed, Jun 24, 2020 at 5:21 PM Jeff Long <willcode4@gmail.com> wrote:

Depending on the bandwidth of your signal, that could be a lot of offset, and you might need a PLL to do frequency correction. That's 130 ppm, which is a little more than you should see between two HackRFs.

On Wed, Jun 24, 2020 at 5:13 PM Artur Nogueira <artur.nogsj@gmail.com> wrote:

Thanks a lot.

I'll read the block specifications.

And yes, the offset is small (120 kHz).

Em qua., 24 de jun. de 2020 às 17:53, Jeff Long <willcode4@gmail.com> escreveu:

Assuming the difference is small enough, this is a normal RX problem that a GMSK demod should be able to handle. The labels on your frequency plot do not say what the offset is, but hint that it is small. Take a look at gmsk.py to see how it's handled in the built-in demod.

On Wed, Jun 24, 2020 at 4:10 PM Artur Nogueira <artur.nogsj@gmail.com> wrote:

Hi Jeff,

Thanks for the feedback.

I'm using GNU Radio Version 3.7.13.5 and two Great Scott Gadgets HackRF units for the transmission/reception.

My workflow looks like this:

Do you usually use any artifact to compensate for this frequency shift?

I'm afraid this could affect demodulation and therefore the BER.

Best regards,

Artur 

Em qua., 24 de jun. de 2020 às 16:31, Jeff Long <willcode4@gmail.com> escreveu:

Artur,

You haven't mentioned what software you are using, how you have it configured, or what your flowgraph looks like.

If you are using two SDRs and the frequency difference is a few kHz, then that is just oscillator differences.

On Wed, Jun 24, 2020 at 3:12 PM Artur Nogueira <artur.nogsj@gmail.com> wrote:

Hi everyone,

I'm comparing the spectra of a pair of transmitted/received GMSK signals (carrier frequency = 923 MHz).

As expected, there is a certain channel attenuation.

Nevertheless, there is this frequency deviation at the Osmocom Source output:

I suppose this is something related to the receiver hardware.

Do you have a suggestion on how to compensate for this effect at a software level?

Best regards,

Artur