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.no...@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: > [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 >>>>>>>> >>>>>>>>
