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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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
>>>>>
>>>>>

Reply via email to