[Hackrf-dev] HackRF Jawbreaker Bugs

[Jared Boone]

On Aug 6, 2013, at 1:25 PM, Russell Hande <zefie at persona.cc> wrote:


> For example, a local ham repeater tower here is at 147.210mhz, however

> to tune where the carrier is directly centered, I have to tune to

> 147.2109mhz. (+900hz offset)

> Shortwave station 15.610mhz is centered on the carrier at 15.6101mhz.

> (+100hz offset)


According to my math, it sounds like the clock reference (crystal-derived) is only 6ppm off, which is pretty good. The ppm error in Hz will scale with the carrier frequency, so what you're seeing is expected, as far as increased Hz offsets at higher carrier frequencies.


> If I had to guess it would be a mathematical problem in the firmware,

> since the manufacture of the clockgen chip claims 'precise 0ppm

> accuracy' . But this is speculation.


What you're seeing is not an error in the firmware, but an expected lack of accuracy in the reference clock oscillator.

As for the Si5351C's claim of 0ppm accuracy, that accuracy is relative to the reference clock that it is given. If the reference clock is off (which it will be to some extent), so will all the outputs of the Si5351C. The best way to address this is to use a more precise clock -- you can get sub-ppm crystals, but they're expensive, or you can use the external clock input to feed in a clock disciplined by some other source (GPS, WWVB, atomic clocks). But on a <$300 software radio, 20ppm is what I'd consider decent performance.

The reference frequency error will likely be consistent once the hardware has stabilized temperature-wise, so you could compensate for the offset by multiplying by 0.999994.

	- Jared