[time-nuts] Noise of digital frequency circuits (was: Programmable clock for BFO use....noise)

Poul-Henning Kamp phk at phk.freebsd.dk
Wed Oct 10 11:20:56 EDT 2018


--------
In message <20181010165425.df6d24aa3825ca765f301c0d at kinali.ch>, Attila Kinali w
rites:

>> >"A Physical Sine-to-Square Converter Noise Model,"
>> > by Kinali, 2018
>> 
>[...]
>Hence the first gain stage already aliases the noise from its whole
>bandwidth, which can be a lot of noise if the BW is large.

Some years ago I spent a lot of time trying to find a way to
"oversample" single-shots of the 3rd zero-crossing of Loran-C
signals.

My finding was that of all the technologies available, the simple
comparator was the worst, because it only "looks" at a very tiny
time-slice around the actual zero-crossing, and thus is needlessly
sensitive to noise.

To make matters worse, the window is always late, it cannot be
symmetric, because at least some electrons have to move in the
opposite direction before the comparator changes state.  HP has
interesting info about this in an old app-note on TI counters.

If the incoming curve-shape is unknown, that is the only thing one
can do, but when the curve-shape is known to be a sine or a loran-C,
better results can be had with a wider time window.

The final version of my code (This was SDR with an ADC directly on
the antenna) found the optimal least-square match between the sampled
signal and the theoretical signal for a configurable time-window,
produced the zero crossing from the theoretical signal.

Best performance was around 1/6-th period, which I'm sure there was
a reason for, but I gave up looking for it.

I have not found a way to implement it in the analog domain.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



More information about the time-nuts mailing list