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: [image: image.png] With the frequency correction: [image: image.png] Do you think this is reasonable? Em qua., 24 de jun. de 2020 às 18:32, Jeff Long <willco...@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 <willco...@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.no...@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 <willco...@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 >>>> <https://github.com/gnuradio/gnuradio/blob/b76e8788687b4feef610e501c0c7d167c4f04a98/gr-digital/python/digital/gmsk.py#L165> >>>> to >>>> see how it's handled in the built-in demod. >>>> >>>> On Wed, Jun 24, 2020 at 4:10 PM Artur Nogueira <artur.no...@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: >>>>> >>>>> [image: image.png] >>>>> >>>>> 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 <willco...@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.no...@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: >>>>>>> [image: image.png] >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>>
