[Hackrf-dev] short-term frequency stability requirements for the clockIN

[Kristoff]

Hallo Schneider,



On 28/03/2021 2:03 p.m., schneider wrote:
> Hi,
>
> On 27.03.21 21:43, Kristoff wrote:
>> I bought a 10 MHz GPSDO from dxpatrol, but that one seems to create a
>> sine-wave instead of a square-wave so I cannot use that one for the hackRF.
> I've recently also became interested in GPSDOs and bought one from
> dxpatrol. Mine is outputting a square wave though.
>
> If you open up your GPSDO you will find that there is a discrete low
> pass filter at the output of the OCXO (assuming that they're always
> using a square wave OCXO). If you bridge that filter you will get a
> square wave output. This is in fact the state of mine when it was delivered.

Ah nice to know.

A bit strange they didn't just add a small switch so that people can 
chose a sinewave or a squarewave signal.

I'll check if I can fix it this way, or if I just need schmitt-trigger 
to recreate my squarewave.


Did you buy another GPSDO then or did you stick with this one?


>> I also have two ublox neo8 receiver-modules that do are able to generate
>> a 10 MHz square-wave, .. but the signal seams to be very strange: 2
>> longer pulses followed by 3 shorter pulses. Also the time between the
>> pulses seems to very, so the jitter is very very bad.
> That is expected and why you need a very slow PLL behind it.

Didn't know this.

I did notice that one 12 or 24 MHz, the signal is much cleaner. (I guess 
there is some relationship with one of the core frequencies used by the 
GNSS satellites)



> I doubt the
> loop filter of the HackRF clock chip is going to like a signal directly
> from the ublox receiver.

Thinking about it, I guess that is logical.
As far as I know, the clock-in / clock-out ports of the hackRF are meant 
to be used to synchronise two hackRF devices. From that perspective, 
it's logical there is as less additional circuits on that path as possible.


Thx!

> Best
> schneider

kristoff