[Hackrf-dev] HackRF Jawbreaker Bugs

[Jared Boone]

On Aug 6, 2013, at 18:26, 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?


It certainly could, though there is no accurate reference on HackRF that could be used to calibrate the reference clock. You'd have to do it against some sort of external reference (another clock, or a stable tuned carrier), and it would change depending on temperature, and between HackRF units. (Each unit's crystal will have different behavior.) I think this calibration work is better done in the client software. I do not have experience with SDR#, and little experience with GQRX, but I imagine they'd support such a calibration adjustment.


> 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


I was recently looking at the tuning code, and do have some concerns about the math done there. I have seen spurs move in peculiar ways I'm certain bands. So I think there is work to be done there. But my first thought is that you have the gain set too high, and the distortion products (from nearby FM or TV stations) in the first IF or LNA are mixing with other signals, and this is why you're seeing NOAA (162MHz) showing up at 2GHz. Try without the LNA amplifier checkbox and lower gain, and see if you see the same ridiculous number of spurs.

        - Jared