[Hackrf-dev] HackRF Jawbreaker Bugs

[Russell Hande]

Okay I'll have to get back to everyone when I figure out what is going
on, maybe my clockgen is defective or something. At 1300mhz it
glitches up even at 2msps. And at 2293.474 I am picking up noaa wx
radio (162.525).

On Tue, Aug 6, 2013 at 9:26 PM, Russell Hande <zefie at persona.cc> wrote:

> Thank you for the response, I guess it makes sense. Maybe a workaround

> could be calculated in firmware then?

>

> Here are some images further illustrating my point about lower sample

> rates. The first image is at 16msps, the second at 2msps, same center

> frequency. This clearly explains why I find the higher sample rates

> completely unusable.

>

> 16msps: http://i.imgur.com/ViRFFRv.png

> 2msps: http://i.imgur.com/PhQwfTv.png

>

> On Tue, Aug 6, 2013 at 6:53 PM, Jared Boone <jared at sharebrained.com> wrote:

>> 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