Is the sampling frequency being generated by the same oscillator as the carrier frequency?

[radio-satellites]

What would you like to know?

Hi!

I'm working to debug a communications issue using the HackRF. The current theory is that the sampling frequency and the carrier frequency are not generated by the same reference oscillator, causing issues. Is this true in the case of the HackRF?

Best,

Sasha

[martinling]

On HackRF One, the sampling clocks and the local oscillators for the mixers are all derived from the same clock reference, which is either the onboard 25MHz crystal or the external 10MHz reference if one is connected.

The clocking is illustrated in the block diagram below. The r9 clock arrangement is a little different but follows the same principle.

[martinling]

Hope that answered your question - if you're having trouble with frequency accuracy / stability then connecting an external 10MHz TCXO or GPSDO is usually the best solution.

I'll close this for now but feel free to reopen if we can help further.

[radio-satellites]

Hi @martinling !

Thanks for your reply!

Stability is not my main issue right now. I opened this issue as an attempt to answer tapparelj/gr-lora_sdr#79. The RTL-SDR can receive all packets fine, whereas the HackRF tends to only receive the shorter packets and gives a wrong CRC on the longer ones.

[martinling]

Which RTL-SDR device do you have? Some of them include a TCXO, so you might have a more stable frequency reference on the RTL-SDR than you do on the HackRF. The fact that short packets work but longer ones don't would seem consistent with that.

I'm not that familiar with LoRA, although I understand it uses a fairly wideband chirp modulation.

[radio-satellites]

@martinling Yep, I am using a TCXO.

Would you say that stability might affect things? I know that the HackRF is more unstable, but I wouldn't expect it would be so unstable as to mess up digital modulation.

However, LoRa does use a map algorithm (I think), so frequency stability over the course of longer packets might be an issue! I'll ask the author of the GNURadio package.