This chapter is only important for phase-
and precise frequency measurements,
or for the detection of extremely weak but slow Morse code transmissions
('QRSS').
You don't the functions explained in this chapter for most 'normal' applications
like audio frequency analysis.

To improve the accuracy of frequency- and phase readings, it is possible
to reduce the influence of "drifting" soundcard sample rates by
permanently monitoring the frequency and phase of an external
reference signal.

( This is different from the 'normal' sample rate calibration table on the
audio settings screen, where the
sample rate is only calibrated once but not
permanently)

With the permanent frequency calibration, you can (almost) eliminate
the effect of a drifting VFO in an external receiver.

With the following steps, you can calibrate the sampling rate once. This
is enough for most applications.

Select a nominal sample rate which is high enough to detect the
"reference signal" of your choice. Most modern
cards seem to work better with 48000 samples/second, rather than 44100 .
These sampling rates are sufficient for most applications.

Use a relatively high FFT resolution, for example 262144 points, in the settings
for the main spectrum display.

With the peak-detecting cursor in the spectrum graph or the waterfall, measure
the frequency of the reference signal.
Move the mouse close to the peak frequency. The "peak indicator" circle in
the spectrum plot should jump to the peak.
For example, the 'cursor' function will show a value of 15623.2345 Hz (this
is an interpolated value, the resolution is much higher than the FFT bin
width ! The interpolation algorithm was suggested by DF6NM, thanks Markus
... it really does an amazing job !)

Enter the "correct" and the "measured" frequency in the calibrator fields
of the audio settings dialog. Then
click "Calibrate". The program calculates the new sampling rate and shows
it in the calibration table. If you think it's reasonable, click "Apply"
to make the new value effective.

Move the mouse to the peak of the reference signal again and check the displayed
frequency (again, in 'peak'-mode). It should be very close to the true frequency
of the reference signal, like 15625.0001 Hz for the "TV-sync" example.

Notes:

The mentioned accuracy in the sub-milliHertz-region is realistic, if the
soundcard in your PC has a crystal oscillator, and has been running for a
few hours. If the frequency of the soundcard's oscillator drifts too fast,
try the continuous calibration routine which is explained in the next chapter.
Don't calibrate immediately after powering on the system - see
soundcard frequency drift
measurements in the appendix.

The calibration table is saved in the machine-depending configuration file
MCONFIG.INI in the installation directory. It is not part of a user configuration
file (SETTINGS.INI; *.USR; etc). So, if someone sends you a test setup file
via e-mail, your calibration does not get lost.

There are different entries in the calibration table for some 'nomimal' sampling
rates (like 11025, 22050, 44100, 48000, 96000 Hz). Because it is very
likely that all rates are derived from the same clock oscillator, it's ok
to do the calibration procedure for the highest sampling rate only, divide
the calibrated result by two or four, and enter the result manually in the
table. This way you can calibrate 11025 samples/second with the 15625 Hz
TV sync 'indirectly'. But beware, some soundcards are known to be very far
off the nominal sampling rate; in recent years (2010) many soundcards work
better at 48 kHz than at 44.1 kHz .

For 'very demanding' applications like phase measurements, or spectrograms
with extreme frequency resolution (mHz or even uHz range), it may not be
sufficient to "calibrate" the soundcard's sampling rate only once. Instead,
the SR (sample rate) may have to be monitored continuously against a stable
reference, so any SR drift can be eliminated.

To achieve this, select Components ... Sampling Rate
Detector from SL's main menu, or select one of the preconfigured settings
(from the Quick Settings menu) which automatically activate
this function (for example, the Very Slow Morse modes like "QRSS600").

When selecting one of the preconfigured sources from the
Sync frequency/ Source combo, the program will automatically adjust
other parameters on this panel, as required. The screenshots above show a
typical configuration using a VLF transmitter with MSK modulation (minimum
shift keying) on the left side, and a typical configuration for a GPS receiver
(with 1-pps-sync output) on the right side.
The other controls on this panel are explained in a later chapter
(you will usually not need to modify them, at least not if you picked one of the pre-configured references
from the list).

Note

The 'Sync frequency / Source' combo is not just a drop-down list but also an edit field.
Click into the field to enter any frequency (below half the sampling rate, of course).

Don't forget to set the Enabled checkmark. It can be used to
disable the correction temporarily (in the presence of heavy noise aka QRN).
If you only want to measure your soundcard's momentary sampling rate (but
not let SpecLab adjust other processing stages based on the measured sample
rate), set the 'Measure Only' checkmark. If your receiver is
a software defined radio with quadrature output, set the checkmark I/Q input
(in that case, the Q channel will be tapped at the 'Right' input, for example
L1 = Inphase, and R1 = Quadrature phase input).

After a few seconds, the SR detector has acquired enough samples to calculate
the first 'true' sampling rate (see principle below if you're interested
to know how it works). If the reference signal is strong enough, and a few
other 'signal-valid' criteria are fulfilled, the Status field (at the bottom
of the control panel) will turn green.

The 'History' in the lower part of the panel shows the sample rate's deviation
(in ppm) from the nominal value, intended as an aid to compare the stability
of different soundcards (the ppm values can be copied and pasted somewhere
else through the windows clipboard, remember CTRL-C and CTRL-V..) . If the
history shows a very 'jumpy' behaviour, the clock crystal of your soundcard
may be too close to a heat source, or near a cooling fan. This may render
the soundcard useless for some applications - also see
soundcard drift measurements
at the end of this document (it contains an example of a 'good' (low-drift)
and a 'poor' (rapidly drifting) soundcard.

The proper operation of the SR detector can be monitored on the integrated
'Scope' window (not to be confused with SL's input monitors, and the time
domain scope). For example, if a 'healthy' MSK signal
is being received, the Scope will show something like this:

If the reference is an MSK signal, the scope shows the spectrum of the squared
baseband signal. There should be two peaks in the spectrum, symmetrically
around the (invisible) 'carrier frequency', spaced by the bit frequency.
For example, an MSK broadcaster transmitting 200 bits per second will produce
a line 100 Hz below the center frequency, and another line 100 Hz above the
center. Both lines (peaks) are labelled in the scope display; one with the
offset from the center, the other with the difference between both peaks
in bits/second. This indicator is typically very close to the nominal bitrate
(see screenshot); if not, you may be tuned to a false signal.

If the reference is a coherent 'carrier'
(like the AM carrier of a time signal transmitter, or a longwave
broadcaster), the scope will look simpler - ideally, it only shows the carrier,
way above the noise level:

Depeding on the type of the reference signal, the sample rate calibrator
uses ...

a numerical controlled oscillator (NCO) with two outputs, 90° phase
difference ("I/Q output"),
a complex multiplier ("I/Q" mixer), the reference signal is multiplied with
the NCO's outputs like in an "image cancelling zero-IF receiver",
and a chain of low-pass filters and decimators, with adjustable bandwidths.

a bank of Goertzel filters, each filter observes
a narrow frequency band,
and emits a complex frequency bin every 10 to 30 seconds which is then processed
as in the old algorithm (see details in the appendix).

a phase meter for the decimated I/Q-samples (or the Goertzel filter with
the maximum output).
By comparing the phase in the current and the previous complex sample, the
momentary frequency can be calculated with a much higher resolution than
the measuring time (a few seconds) would allow in a simple 'frequency counter'.

An interpolating detector for the sync pulse from a GPS receiver (typically
with a one-pulse-per-second output, aka '1 PPS'), described in
a later chapter.

The phase meter produces a new reading every second (or, for the
Goertzel filters, every 10 seconds). From the difference
of phase values, the new deviation of the sampling rate is calculated, and
the 'calibrated' sampling rate (which is an input parameter for some other
function blocks) will be is slowly adjusted. Many (but not all) function
blocks in SpecLab will benefit from this 'measured' sampling rate. For example,
if the main spectrum analyser uses extremely long FFTs (with decimation)
to achieve a milli-Hertz resolution, you will need this continuous calibration.
A test showed that the clock frequency of the audio device in a notebook
PC could be 'shifted' by 1.5 ppm within half an hour, just by cooling the
notebook's underside with a fan (a 10 kHz signal was off by 15 mHz - see
soundcard clock drift in
the appendix). In many cases the permanently running sampling rate 'calibrator'
eliminates the need for an external
A/D converter (clocked with an oven-controlled or GPS-disciplined oscillator)
!
Another example: With an E-MU 0202 (external audio device capable of 192
kSamples/second), it was possible to compare the carrier phases of several
VLF transmitters, using the German DCF 77 (time signal transmitter on 77.5
kHz) as an ultra-stable frequency reference.

There are some additional function blocks in the frequency calibrator which
detect the presence and the quality of the reference signal. This prevents
the 'calibrated' sample rate from running away if the reference signal is
bad or even missing. The 'pulling range' for the calibrated sampling rate
can be adjusted by the user.

Some parts of the calibration algorithm
are explained in the appendix. The monitoring display (to check if the SR
detector operates properly) is explained
here .

There is a special control window for the sample rate detector ( / compensator
) in Spectrum Lab. To get there, select "View/Windows".."Sample Rate
Calibrator" from Spectrum Lab's main menu, or click on the "SR calib" function
block in the circuit diagram. It's not really a 'calibration', but this function
allows to compensate the soundcard's sample rate drift permanently.

The upper part of this tabsheet controls the sampling rate detector,
selects reference frequencies, source (left or right "audio" channel),
and a few options on the right side of the panel shown below.

Screenshot of a part of the 'Sampling Rate Detector' panel in SL,
here configured for a GPS receiver with NMEA decoded via soundcard.

Sync Frequency (Hz) / Reference Source :

The known frequency of the reference signal (as it should be).
Please note that the sample rate detector uses audio, or "baseband" frequencies
but not "radio" frequency. A number of predefined
frequency references can be picked from this list, too. Picking one of
the references from the list may automatically change some other parameters
(like the mode/algorithm field) . For example, selecting "GPS, 1 pps" from
the list will automatically set the 'Mode/algorithm' to 'GPS sync with NMEA
decoder' (see below).

Input Channel

Defines where the reference signal is taken from. Choices are 'LEFT input'
or 'RIGHT input' if the program runs in stereo mode. For I/Q input, the
'quadrature' component (Q) will be the complementary channel, for example
I=L1, Q=R1, etc.

Synchronized Resampling

If this option is activated, the SR detector will be closely tied
to Spectrum Lab's Input Preprocessor:
The SR detector continuously measures the current sampling rate from the input device ("soundcard"),
and the preprocessor's resampler converts the stream into a sequence with exactly
the nominal sampling rate. For example, even if the soundcard's sampling rate drifts around
between 47990 and 48001 samples per second, the output (from the preprocessor to labels 'L1' and/or 'R1'
in the circuit window) will be 48000.000 samples / second, depending on the quality
of the reference.
If there are two active input channels (labelled L0/R0 in the circuit diagram),
the combination of 'Input Channel' and 'Synchronized Resampling' affects which of the two
channels is routed from L0/R0
to L1/R1 :

R0 (right audio channel) delivers NMEA and sync pulse from the GPS.
L0 (left audio channel) delivers, for example, a VLF signal.
This is the combination used when the screenshot of the circuit window (below) was made;
and it's the method of choice for the amateur VLF-BPSK experiments in 2015.

Screenshot of the A/D converter block connected to SL's input preprocessor.
'L0' = left channel, directly from the soundcard, here approximately 192 kSamples/second;
'R0' = right channel, directly from the soundcard, feeds GPS sync+NMEA into the calibrator.
'L1' = output from preprocessor to the rest of the circuit with exactly 48 kS/s;
'R1': not connected due to the configuration of the Sampling Rate Detector (!)

Both inputs (L0 and R0) run through the resampler
to bring their sampling to the nominal value. Quite useless for GPS-sync,
but makes perfect sense for other references (like MSK transmitters on
'the same band' or 'on the same antenna' as the measured signal).

Both inputs (L0 and R0) run through the resampler
to bring their sampling to the nominal value (routed to L1 and R1).
Quite useless for GPS-sync, but makes perfect sense for other references
(like MSK transmitters on 'the same band' or 'on the same antenna' as the measured signal).

L0 is directly connected to L1, and R0 is directly connected to R1,
because nothing is resampled (at least not within the preprocessor).
The sampling rate is continuously measured but not corrected by resampling.

Mode / algorithm

Allows to switch between the 'old' algorithm (which is basically a phase
meter for the reference signal), the Goertzel filters,
the MSK demodulator, and the
GPS sync pulse /
NMEA decoder. The 'mode' setting
also affects the Scope display.

Used during development or for "testing purposes". If this checkbox is marked,
the sample rate is measured, but the other components in Spectrum Lab are
not affected (they keep using the constant 'calibrated' sample rate from
the table on the audio settings panel).

I/Q Input

May only be set if the signal source uses in-phase and quadrature, which
is often the case with software defined radios and similar downconverters
with complex output.

This highly experimental option can only be used if the reference (source)
is a GPS receiver with sync pulse output (pps). When checked, all oscillators,
sinewave generators, etc inside the software don't use the number of samples
acquired from the soundcard as argument, but the precise time of day from
the GPS receiver's NMEA- and sync output. The phases of most oscillator outputs
will then be phase-locked to the GPS sync pulse. At midnight (precisely,
at 00:00:00.0000 'GPS time', which is close to UTC), all circuit components
which can be 'locked' to GPS this way (see list below) will reset their phase
angles (or sine wave arguments) to zero. Such phase jumps do not occurr if
the oscillator frequency is an integer multiple of 1 Hz / ( 24 * 60 * 60
) . If the frequency is an integer value (i.e. a multiple of 1.0 Hz),
there will be no phase jump, and the phase noise may be slightly less than
at arbitrary frequencies.
Circuit components affected by this option are :

Most (but unfortunately not all yet) of the digimode encoders (PSK, FSK, ASK,..)

GPS 1s late ("GPS / NMEA output one second late")

Only has an effect in mode 'GPS sync with NMEA decoder'. If the GPS-based timestamps
are one second late, set this option.
For details, see Checking the GPS NMEA timing'.

Min. Reference Amplitude

If the strength of the reference signal is less than this value, the sample
rate calibration will be temporarily disabled (important if you use 15625
Hz as reference and someone turns the TV off !). A typical value is -80 dBfs,
wich means "80 dB below the maximum level which can be handled by the ADC).
Keep the amplitude of the reference signal as low as possible (typically
about -60 dBfs) to leave enough headroom for other signals you want to
measure.
The current (measured) signal strength is displayed in the lower part of
the control window.

Rarely used, and only works with the Goertzel option. The only known use
was for the Russian 'Alpha' VLF transmitters,
which do not send a continuous signal but a periodic sequence which repeats
0.2777777 times each seconds.
This periodicity causes multiple spectral lines (separated 0.2777777 Hz from
each other), which the calibrator must know to avoid 'locking' on the false
line (because the strongest 'Alpha' line is not always the one with the nominal
frequency). If you pick one of the 'Alpha' frequencies in the Reference Frequency
list, the Periodicity field (in
Hz) will be automatically filled. For normal (continuous wave) reference
signals, leave this field empty.
If the mode is set to GPS sync / NMEA, the periodicy field is used to enter
the serial bitrate of the GPS receiver's NMEA output, which is important
for decoding the GPS time.

Number of seconds per measuring interval. Longer intervals (10 or even 30
seconds) are preferred because they allow frequency measurements with better
accuracy. On the other hand, if the soundcard's sampling rate drifts rapidly
(as can often be seen with internal soundcards), shorter intervals (less
than 10 seconds) can give better results, because even "short excursions"
of the sampling rate will be compensated.

Observed Bandwidth

Defines the width of the frequency window for the sample rate. A typical
value is 0.5 Hz (for a 15625 Hz reference). If the bandwidth is too low,
the phase meter may not "see" the reference signal if the sample rate is
too far off. If the bandwidth is set too high, the phase meter gets less
immune to noise. If a the calibrator uses a bank of Goertzel filters (to
observe the band), the CPU load depends on the observed bandwidth, because
the larger the bandwidth, the more Goertzel filters must run in parallel
(each Goertzel filter has a bandwidth of approximately 0.1 Hz).

Max. offset (from calibrated sample rate)

The initial value for the ADC's sample rate is taken from a table in SpecLab's
'audio settings'. The deviation
between the sample rate in the table and the result of the calibration procedure
must not exceed a certain value, like this:
Sample Rate from calibration table in the 'audio settings': 44103 Hz
Max Deviation: 5 ppm -> true calibrated sample rate = 44103 Hz +/-
5 ppm = 44103 +/- 0.2 Hz = 44102.8 .. .44103.2 Hz.
(Note: this has nothing to do with the 'nominal sample rate' 44100 Hz, so
you should do a first 'coarse' calibration for your soundcard before activating
this function. The reason why only a small 'deviation' range should be used
is to have a good starting value for the narrow-band phase meter. )
A typical soundcard oscillator drift, after booting up a "cold" PC, can be
found in the appendix .
For PCs operated indoors, or at a relatively 'constant' temperature, 5 ppm
should be sufficient.

Current sample rate

Displays the currently calculated sample rate. You cannot edit this field,
but copy its contents into the clipboard. Mark the text with the mouse and
press CTRL-C to copy into the windows clipboard. You can then insert the
copied value as a "very good starting point" into the calibration table in
SpecLab's audio settings screen.

If the 'simple phase meter' is used, this line shows the signal strength
after narrow-band filtering and the signal to signal-plus-noise ratio ( "S/(S+N)"
). The S/(S+N) value compares the amplitude of the narrow-band filtered value
against a medium-bandwidth value, usually ten times the narrow-band value.
If the Goertzel filters (DFT) is used, this line shows the frequency of the
reference signal (i.e. the "strongest peak" in the observed frequency range),
and the signal strength in dBfs (dB "over full scale", thus always
negative).

Error Integral (only active when using the Goertzel filters) :

Shows the summed-up products of frequency difference ("measured" sampling
rate minus "predicted" sampling rate) from each measuring cycle, multiplied
by the measuring interval time in seconds. Thus the unit of this 'integral'
has no unit (it can be considered Hertz * seconds, though). If the sampling
rate doesn't drift at all, or drifts at a constant, linear rate, the "predicted"
sample rate (for the end of the next measuring cycle) will be equal to the
"measured" sampling rate, and the SR Error Integral will be zero.
Note: Long-term phase observations (for ionospheric studies, etc; using the
pam function) only make sense if
the error integral stays almost zero; i.e. the drift must be very low
or at least predictable. Internal soundcards are usually not suited
for such long-term phase measurements, but some external audio devices
(especially USB devices in "large boxes") are.
Internally, the a fraction of the error integral is used to steer the 'predicted
sampling rate' (until the end of the next measuring cycle) to minimize slow
drifting effects in long-term phase measurements. The error integral can
be reset (cleared) by clicking the 'Apply' button on the Sample Rate Detector
panel - it simply restarts the detector, which includes "forgetting" old
values.

Shows the scheme how the high audio sample rate and ADC bandwidth (like 44100
samples/second and 22050 Hz bandwidth) is reduced in chain of decimator stages
down to the phase meter's sample rate and bandwidth (like 1 sample/second
and 0.5 Hz bandwidth). Every decimator stage can reduce sample rate and bandwidth
either by 2 or by 3, the total decimation ratio is also shown here. With
a large decimation ratio, you can use signals buried in the noise as reference
!

Phase angle (only displayed when the calibrator measures the phase of a reference signal) :

Shows the actual value of the phase meter (reference
signal - oscillator). The displayed value should be constant, only
a small phase jitter is unavoidable (usually below 0.5 °).

Shows the current difference between the PC's internal system time and the time extracted
from the GPS data (sync pulse and NMEA if possible).
If only the GPS sync pulse ("PPS" signal) is connected, but not the NMEA data output,
the integer part of the time difference is meaningless because in that case,
Spectrum Lab can only "guess" the GPS time.
If only the PPS signal is connected, the fractional part of the time difference
must be well below 500 milliseconds. The same value can be retrieved via interpreter
function sr_cal.systimediff .

Status:

If this panel is green, everything is ok; otherwise the text shows what may
be wrong, for example:
"SR range exceeded"
"S/(S+N) ratio too bad"
"Reference signal too weak", etc.

The frequency offset detector works similar like the sample rate detector
(see previous chapter). The result from the frequency measurement is not
used to determine the (corrected) sample rate. Instead, the frequency difference
(deviation) between a reference frequency and the measured
frequency is calculated. This can be used to...

compensate a slowly drifting oscillator in an external receiver

measure small changes in the frequency between a well-known
"reference" signal and an unknown "received" signal

steer the VFO (in SpecLab's test circuit)
to compensate the offset in the time domain

(Note: The detection of the soundcard's sampling rate AND the frequency offset
detector can run simultaneously, but you need two different reference
signals then. For example: one reference signal at 15.625 kHz to "calibrate"
the sampling rate, and another like 1000 Hz to detect the frequency drift
in your shortwave receiver. To calibrate your receiver, the 2nd reference
signal must be produced in your receiver, of course. Details below).

To activate the frequency offset detector from SpecLab's main menu, select

"View/Windows" ... "Frequency Offset Detector".

A small control window opens, where the following parameters can be set:

Enabled:

Must be checked to start the F.O. calibrator.

Source channel:

Select the LEFT or RIGHT input channel of the soundcard (unlike other function
blocks in SpecLab, this one cannot be connected to any signal in the
signal processing chain !).
If the input (into SpecLab) is a complex aka "I/Q"-signal, set the source
to "BOTH inputs (complex)". In that case the frequency offset detector can
process positive as well as negative input frequencies.

Reference Frequency (Hz):

The known frequency of the reference signal (as it should be).
Please note that the frequency offset detector uses audio, or "baseband"
frequencies but not "radio" frequency. So, in this field, enter the AUDIO
(or "downconverted") frequency. A number of
predefined frequency references can be picked
from this list, too. Picking one of the references from the list may
automatically change some other parameters (like the mode/algorithm field)
.

Min Reference Amplitude (dB):

The detector will be passive if the amplitude of the reference signal is
below this value. This prevents "running away" if the reference fails.

Max Offset (Hz):

This is the maximum "pulling range" for the detector. In most cases, this
field will be set to the same value as the "observed bandwidth" below.

Observed bandwidth (Hz):

This is the bandwidth of phase meter (which is used internally used to measure
the frequency offset; unless the Goertzel filters are in use). If your receiver
may be "off" by +/-0.5 Hz, set the 'observed bandwidth' to 1.0 (!) Hz. Otherwise
the detector may not be able to "see" the initial frequency of the reference
signal and never lock on it.

Actual Peak Frequency:

Shows the "main peak frequency" within the detector's bandwidth. Can be used
for high-precision frequency measurements, but depends a bit on the signal/noise
ratio (within the detector's bandwidth).

Averages:

Can be used to suppress unstable reference signals, and reduce the effect
of pulse-type noise. "50" means, the "average offset value" is calculated
from the last 50 values from the phase meter. Practical values are 50...200.
If the displayed average frequency offset appears to be "too noisy" (see
below), increase the number of averages. If the detector reacts too slow,
reduce this number.

Avrg Offset:

Shows the current output of the detector, which can optionally be used to
enhance the accuracy of the main spectrum analyser (when running in "complex
FFT mode with frequency shift"), and in the time domain scope (when used
as a "phase meter"). The frequency error measured with the frequency offset
detector can be "subtracted" by the local oscillator which sets the "center
frequency" of the FFT and the scope's phase meter.

In the lower part of the window, some other values are displayed which were
used during program development. One of them is the "signal / (signal+noise)"
ratio, which is a crude indicator for the reference signal's quality. If
the quality is very poor, the "result" of the frequency offset detector freezes,
and the detector's "status" indicator turns yellow or even red (which can
also be seem on the circuit window).

RED = "Reference signal too weak"

YELLOW = "Signal to noise ratio of reference signal too bad"

To calibrate a drifting receiver, you must find a way to feed a add a weak
but very stable reference signal to the antenna input, which produces a suitable
audio tone in the output. Use your imagination - and an oven controlled crystal
oscillator, and a chain of dividers/multipliers, or a programmable DDS generator.

The following list contains a few frequency reference sources
which can be used by SL to measure the sample rate. Some of them are
listed in the 'Reference Frequency' combo
of the sample rate calibrator, so you don't need to type in the frequencies yourself.

The 1-pulse-per-second output of a good GPS receiver (jitter less than a
microsecond). Since SL V2.76, receivers with 1 pps are directly supported
(no need to lock to a 'harmonic' for these signals anymore). Details on using
a GPS receiver with pps output follows in a later
chapter. BTW, using a GPS receiver (especially such a sensitive one like
the Garmin GPS18x LVC) is now the author's first choice.

The output from an ovenned crystal oscillator (OCXO), divided down into the
audio frequency range. Such 'large canned oscillators' can be found on hamfests
or auctions, since they are widely used in wireless communication equipment.
5 or 10 MHz are common frequencies for such oscillators.

The divided-down carrier frequency of a longwave time-code transmitter like
MSF (60kHz),
DCF77 (77.5kHz), or similar.
Use a PLL cuircuit to recover a 'clean' carrier signal, then (for example)
divide 77.5kHz by 31 or 60kHz by 24. The result should be a very stable 2500
Hz signal which can be fed into the soundcard. If you have a soundcard which
supports 192 kHz sampling, you don't need any hardware because the soundcard
should be able to receive 77.5 kHz directly with a few meters of wire.

Some Navy transmitters in the VLF spectrum (17 to 24 kHz, or up to 90
kHz if the soundcard permits) can be used as a reference signal, if they
use MSK modulation (minimum shift keying), and
don't insert more-or-less arbitrary phase jumps in the transmitted signal.
At least some of those "broadcasters" seem to have their carriers locked
to atomic clocks or GPS standards. In that case, and if they are not too
far away (i.e. within "groundwave distance"), they can be used as references
for the soundcard sampling rate correction. Most of the European transmitters
can be picked from the 'Reference' combo list on the 'Sampling Rate Detector'
control panel. So far, the system was only tested with
DHO38 (MSK200 on 23.4 kHz), because that transmitter
was close enough for groundwave reception (even during nighttime). Beware,
DHO38 used to be off air once or twice a day, and the frequency
is not exactly 23.4 kHz.

Some longwave broadcasters (like the BBC's Droitwich transmitter on 198 kHz)
use Rubidium standards for their carrier signal. In western europe, use a
simple PLL oscillator, and divide the signal down with a cheap CMOS circuit
(only required if you don't use a software defined radio like SDR-IQ or Perseus,
which can be tuned to any frequency in the LF, MF, or HF spectrum).

Any of the Russian 'Alpha' (aka RSDN-20) VLF transmitters on 11
to 14 kHz; their exact frequencies can be picked from the 'reference frequencies'
combo. When doing that, the 'Periodicity' field will automatically be set
to 0.277777 Hz (= the repetition frequency of the "beeps", 1 / 3.6 seconds).
Some details on using the Alpha beacons as a frequency reference can be found
in the chapter about the Goertzel-filter-based
calibrator.

The line sync signal of some TV broadcasting stations.
In EUROPE (and, most likely, countries with 50 Hz AC mains): Frequency exactly
15625 Hz. While we still had terrestrial "analog" TV transmitters, the german
"ZDF" derived their TV sync signals from a high-precision standard clock.
In the US (and other countries using 60 Hz AC mains), the line sync frequency
is ideally 15734.2657343 Hz (for NTSC, colour, 4.5 MHz sound subcarrier divided
by 286).
Update: It is questionable if the TV sync frequency still has this precision,
now that everything (in Europe, even terrestrial transmissions) are digital.
The sync frequencies *may* be generated by a cheap computer-grade crystal
in the set-top box of your TV, so in case of doubt use one of the other
sources... preferrably a GPS receiver with PPS output.

The stereo pilot tone of a few FM broadcasting stations.
Not many FM stations have their 19 kHz pilot tone locked to an atomic clock,
at least not in Germany.

Any other reference can be used, as long as it can be processed with the
audio card. If the ADC supports a sample rate of 44100 Hz, the reference
signal can be everything between 16 Hz ... 22 kHz.

Depending on the checkmark 'use Goertzel'
on the configuration tab, a bank of Goertzel filters is used to calculate
a complex DFT (discrete fourier transform) over a narrow frequency range.
Each filter measures a frequency for 30 seconds, with a frequency bin width
of approximately 0.033 Hz (the effective bandwidth is a bit more due to the
Hann window).

One of the Goertzel filters will (hopefully) catch the 'peak' of the reference
signal - ideally in the center frequency bin. The phase angle in the output
of the filter with the maximum amplitude will be compared with the previous
value (from the same frequency bin). This phase difference (between the most
recent and the previous complex value) is used to measure the intantaneous frequency
of the reference signal, with a much higher resolution than the
DFT's frequency bin width (which, as noted above, is about 0.1 Hz). Along
with the phase angle, the program can determine the frequency to a few
micro-Hertz (!) even though the measuring interval is only 10 seconds.

The result of this calculation, along with the narrow-band spectrum of the
observed frequency range, is displayed on the 'Scope' tab in the Sample Rate
Calibrator window.
Displaying the 'measured' frequency with so many digits is usually 'overkill',
but it helps to check devices with oven-controlled or temperature compensated
oscillators. But the reference signal must have a very good SNR (like the
signal in the screenshot below) for the micro-Hertz digit to be useful. The
device under test was an E-MU 0202 at 48000 samples/s
.

Depending on how the calibrator is configured, it may cause a significant
extra CPU load on your system. For example, if the
sample rate calibrator shall
observe a 1.5 Hz wide band with 33 mHz resolution (per frequency bin), there
will be 45 (!) Goertzel filters running in parallel, each at 48 kSamples/second.
On a 1.6 GHz Centrino CPU, this example used 12 % CPU time (from one CPU).

Fortunately, in a normal environment, the soundcard's oscillator will drift
less than one ppm (parts per million) after warm-up, so you will get along
with a much smaller 'observed bandwidth' - which reduces the CPU load caused
by the Goertzel algorithm. See the
soundcard drift tests in
the appendix to get an idea about the really required bandwidth : If the
soundcard's sampling rate has been properly
pre-calibrated, the observed bandwidth only
needs to be a few ppm (parts per million) of the reference frequency.

For certain reference sources (see next
chapter), it is necessary to use very narrow bandwidth for each filter
(DFT frequency bin). For example, the Russian VLF
'Alpha' navigation beacons (or RSDN-20) send
short 'beeps' every 3.6 seconds, which results in a spectrum of individual
lines spaced 0.277777 Hz, as explained in an article at
www.vlf.it by Trond
Jacobsen. With a 10-second measuring interval it is just possible to see
the individual lines in the spectrum, but a larger measuring interval is
recommended - especially when looking at a typical 'onboard' audio device's
clock frequency drift (see appendix:
soundcard clock drift
measurements ).

For that reason, if you select one of the three active Alpha frequencies
in the list, the program will automatically adjust some other parameters
.. including the 'Periodicity' field because the
decoder needs to know that, in this case, the reference signal is not a
continuous wave, and the output of the Goertzel filters will produce multiple
lines in the spectrum which all belong to the same signal. But the SNR may
be poor, and the signals may suffer from phase changes caused by Ionospheric
reflection, so don't expect too much accuracy (in comparison with a local,
continuous wave reference).

The algorithm will first scan the spectrum for the largest peak, and -starting
there- looks for other peaks which match the periodicity criterium (0.277777
Hz spacing for the Alpha VLF transmitters). The result may look like this
on the scope panel:

The main peak is marked with the measured frequency (under the assumption
that the soundcard still runs at the initial sampling rate), all weaker peaks
which obviously belong to the reference signal are marked with relative
frequencies as multiples of the nominal periodicity ('spacing' in frequency).
For example, '-3.9994' shown in the graphics means 'this peak is 3.9994 times
0.2777777 Hz below the strongest peak', etc. Only peaks which are spaced
at (almost) integer multiples of the periodicity are involved in further
processing. Peaks below the threshold amplitude
(*) are discarded, as well as peaks
on obviously 'wrong' frequencies, or peaks which are 10 dB weaker than the
main peak. If none of the peaks is close enough to the expected reference
frequency, the program uses the measured periodicity value (if 'close enough'
to 0.277777 Hz) to find out which peak is the right one. Unfortunately, at
the moment this requires a very good SNR (signal to noise ratio) ... so it's
more or less a wild guess at the moment ... but this may be improved by
'intelligent averaging' in a future release of the software.

(*) the threshold amplitude, in dBfs,
is indicated as a green horizontal line in the scope display

Besides GPS disciplined frequency standards, or even Rubidium or Caesium
standards (atomic clocks), some modern GPS receivers are equipped with a
PPS output which can be used as a reference signal. Beware, some models are
accurate but not precise, others may be precise
but not accurate. The author of SpecLab even encountered one unit
(btw, not a Garmin) which appeared to be precise (almost
no jitter when observing the PPS output on a fast digital storage oscilloscope)
but turned out to be not accurate at all - in fact, the PPS output
was present on that particular receiver even when no GPS reception was possible
- the accuracy was only up to a cheap computer-grade crystal oscillator.

A Garmin GPS 18x LVC(!) receiver gave good results, when used in
combination with an E-MU 0202 audio device running at 192 kSamples/second,
using the ASIO driver. Most of the GPS-related measurements shown in this
document were made with this 'passive' combiner / voltage divider for the
PPS- and the NMEA-signal :

If the NMEA output, or the PPS/NMEA combiner shown above is not available,
the program can optionally use the PC's system time instead of date and time
decoded from the NMEA output. In that case, only the PPS signal (sync pulse)
needs to be routed from the GPS receiver into the soundcard, using a simple
voltage divider. But this only works if the system time is sufficiently
accurate, with a difference between system time and UTC well below 500 milliseconds.
More about the two different GPS-sync modes (with or without NMEA)
in a later chapter.

Keep the leads between the GPS output (especially the PPS signal), the voltage
divider, and the input to the soundcard as short as possible. The PPS rise
time must be as short as possible - ideally in the range of a few ten
nanoseconds, even if the soundcard's sampling interval may be as large as
5 microseconds ! Without a 'steep' rise, the pulse location cannot be located
accurately by the software. You can tell that by the waveform of the
interpolated pulse.

The PPS signal must be routed to the soundcard 'line' input, using a voltage
divider close to the soundcard's analog 'line' input to avoid overloading
it. It may be possible to feed the GPS receiver's serial NMEA data stream
into the same soundcard. This allows to retrieve also the calendar date and
time from the GPS receiver, not just the time sync pulse (beware, an ancient
GPS receiver -not a Garmin- only emitted the UTC time, but not the
date). To use the same input line for both PPS + serial NMEA data, both signals
must not 'overlap' in time, see sample oscillogram below. The Garmin GPS
18x LVC(!) fulfils this requirement, after setting the baudrate for the NMEA
output to 19200 bits per second. This can be achieved with Garmin's 'Sensor
Configuration Software', SNSRCFG_320.exe or later. Lower bitrates like 9600
bits/second are be possible if you can manage to turn off all 'unnecessary'
NMEA sentences like $GPRMC, $GPGSV, etc. With the GPS 18x LVC configured
for GPRMC + GPGGA only (which is sufficient for this purpose), 9k6 serial
ouput was ok, and was error-free decodable with a soundcard running at 32000
samples/second (to reduce CPU load for a timestamped VLF 'live' stream).

If a combined PPS+NMEA signal
shall be used, the amplitude of the PPS signal must be at least two times
larger than the NMEA signal - see the example below, from the GPS 18x LVC,
with NMEA output at 19200 bits/second. The 'single large pulse' on the left
is the PPS signal, the 'data burst' in the center are the NMEA sentences,
emitted each second. Note the absence of overlap between the sync pulse (PPS
signal) and NMEA data burst, and the significantly lower amplitude of the
NMEA signal, which is essential for the software to work properly:

With certain receivers (or receiver configurations), the NMEA data burst
may be critically close to the 1-second pulse. Here are two examples from
a Garmin GPS 18 LVC, the 1st with a 'less ideal' configuration (more on that
in another document) :

Note:

It's impossible to feed the PPS signal through a serial port into the program.
It must be fed into the same soundcard (or similar A/D conversion
device) which also digitizes the analysed analog signal, because otherwise
there would be an unpredictable latency between the clock reference and the
analysed signal.

If the CPU power permits, run the soundcard at the largest supported sampling
rate (SR). For example, a soundcard which truly supports 192 kSamples/seconds
(*) delivers one
sample point every 5.2 microseconds. But with some DSP tricks, the software
is able to locate the position of the digitized PPS signal up to a resolution
(not a precision) of a few dozen nanoseconds. Only this allows measuring
the SR to fractions of a Hertz once every second .

Example: If the PPS signal was 'off' by 5.2 microseconds (= one audio sample
time) between two pulses, the measured SR would be off by one Hertz
(!) :

192000 Hz * ( 1 + 5.2*10^-6 ) = 192001 Hz . See notes
on the standard deviation of the measured SR at the end of the next chapter.

----

(*) Beware, some crappy audio cards claim to support
192 kS/s, but remove all signals above 24 kHz. It doesn't make much sense
to run them at sampling rates above 48 kS/s !

On the 'Sampling Rate Detector' tab, open the 'Reference freq.' combo, and
pick '1 Hz (GPS 1pps)'.
The program will automatically adjust a few other settings then, most notably:
The field 'Mode / algorithm' will be set to 'GPS sync w/ NMEA decoder' .

Select the source channel. This usually 'R1' (= the right input channel from
the soundcard); because the left channel ('L1') is already occupied by the
analog source.

(A) If you built the PPS+NMEA combiner, and want to let the program decode the
NMEA stream via soundcard, enter your receiver's serial bitrate ("baudrate")
for the NMEA output. This is usually 9600 bit/second if you can turn off
all 'unnecessary' NMEA telegrams (possible with the
Garmin GPS 18 LVC). 4800
is usually too slow, because in that case, the NMEA signal would overlap
with the PPS signal as mentioned in the previous chapter.
Make sure that 'Mode / algorithm' is set to GPS sync with NMEA decoder'.

or

(B) Without the PPS+NMEA combiner, only the GPS sync pulse ("PPS") can be fed
into the soundcard. For this mode, set
'Mode / algorithm' on the Sampling Rate Detector panel to GPS sync without NMEA.
Caution: Method B is only possible if the PC's system time is accurately set (difference between
the PC's system time and the GPS second way below 500 milliseconds) !
The difference between the PC's system time and (minus) the GPS timestamp can be examined
as described here.

Set the 'Enabled' checkmark if not already
done. Uncheck the 'Measure Only' option (otherwise the soundcard's sampling
rate will be measured and displayed, but not taken into account by the rest
of Spectrum Lab's components).

Switch to the 'Scope' tab (within the calibration
control window) and make sure the PPS pulse is visible there. See chapter
'Checking the GPS PPS signal'.
The PPS signal amplitude must exceed 10 % of the audio input's clipping level,
but shouldn't exceed 80 % of the clipping level.
The NMEA signal amplitude must not exceed half the amplitude of
the PPS signal, but shouldn't be less than 10 % of the clipping level. See
details in the previous chapter, titled GPS
sync hardware.

After two seconds(!), the SR detector status (indicator near the bottom of
the 'Sampling Rate Detector' tab) should turn green, and the sample rate
deviation gets dumped into the 'History' window (numeric value in ppm). The
proper function of the GPS receiver, and the SR detector can be monitored
on the same tab. Example:

The parameters shown on the SR Detector tab are (..subject to change..) :

A standard deviation of approximately 30 nanoseconds per second (one
PPS interval) was measured with a Garmin GPS 18x VLC, connected to an E-MU
0202 running at 192 kSamples/second for a few hours in a thermally 'stable'
environment. Don't be fooled by this, it's not the accuracy of the
system, since the GPS 18x datasheet specifies an accuracy of the PPS output
of +/- 1 microsecond at rising edge of the pulse. Fortunately, the Garmin's PPS
output jitter was way below 1 us, and the sync pulses from two receivers
were less than 40ns apart (with 12 satellites in view).

Note: The EMU-0202 and a few other cards inverted the pulse polarity !
The software automatically corrects this, by examining the PPS signal's
duty cycle: If the time between rising and falling edge of the PPS signal
exceeds half the cycle time (i.e. 0.5 seconds in most cases), the signal
is inverted. Thus the 'interpolated PPS signal', displayed on the SR calibrator's
scope tab as explained in the next chapter, always shows the 'important'
rising edge.

The waveform of the interpolated GPS pulse
can be observed on the calibrator's scope panel.
A 'good' pulse rises within a few microseconds (limited by the soundcard),
as in the following screenshot on the right. Some GPSes emit very short pulses (e.g. Trimble Thunderbolt E : 10 us),
which should look as shown on the left screenshot below.
The standard deviation in the recent 60 sync pulses is also shown here ("SD"),
because it's a good quality- and jitter indicator.

Again: You don't need to have the NMEA output if the GPS receiver shall 'only'
be used to improve the accuracy of the soundcard's sampling rate. But with
a GPS receiver with a PPS- and a serial NMEA-output, the latter
can be decoded through the soundcard (and you will have a reliable
time source for free, even when not connected to the internet). First check the
recommended signal levels on
the scope, as explained above. If the combined waveform (PPS plus
NMEA) looks ok, open the GPS (NMEA) Decoder
Window through SL's main menu, or click on the 'Show GPS' button in the
Sample Rate Detector control panel.

The position (latitude, longitude, and height above sea level) is displayed
on the 'Position' tab. The
display format can be changed on the decoder's
'Configuration' panel. The 'raw'
NMEA sentences can be examined on the
'Diagnostics' panel.

Notes:

As long as the GPS / NMEA decoder (parser) is occupied by the 'calibrator',
it is always fed from the soundcard - regardless of the (serial) port selected
in the GPS window. In earlier versions, the 'port' had to be set to 'soundcard'
instead of a 'COM' port. This is not required anymore.

Some ancient GPS receivers only send the time of date, but neither the current
year, month, nor day. Too bad.

The number of satellites (shown in the lower part of the GPS decoder window),
and the HDOP value are important quality indicators.
Don't trust the presence of a sync pulse (pps) alone - see notes at the begin
of this chapter.

The soundcard's sample rate must be at leat 2.5 times the serial baudrate.
For example, to decode a 19.2 kBit NMEA stream, the soundcard's sampling
rate must be set to 48 kSamples/second or more. The sample rate can be modified
in SL's audio settings if necessary.

The decoder will detect the polarity of the NMEA stream automatically. It
doesn't matter if the signal is inverted somewhere on the way, and if your
receiver uses a 'positive' or 'negative' logic output.

The timing relation between the GPS's receiver's NMEA- and Sync Pulse (PPS) output
seems to vary between different manufacturers. Some seem to send the NMEA message
shortly before, others shortly after the associated sync pulse.
An 'automatic' detection didn't work reliable (in 2015), thus the option
'GPS 1 second late' was added as a checkmark on the Sampling Rate Detector tab.
The next chapter describes how to test if this option has been properly set.

In 2015-01, a problem was noticed with the timing between a GPS receiver's NMEA- and Sync Pulse output
(see previous chapter).
To defeat the problem described there, the new option 'GPS one second late' was added
on the Sampling Rate Detector tab.

Screenshot of a part of the 'Sampling Rate Detector' panel in SL.
Note the checkmark 'GPS 1 second late' in the lower right corner.

When the GPS-based timestamps are 'one second late', check this option, otherwise uncheck it.
To test if the GPS (NMEA-) based timestamps are ok, a second (well-known) time signal is required.
Here, for example, DCF77 (the German time signal transmitter on 77.5 kHz) on a fast-running
spectrogram with correct timestamps.
The signal can be picked up in Europe with a piece of wire
connected to the input of a soundcard with 192 kSamples/second.
The missing amplitude gap in the 59th second
of each minute confirms that the option 'GPS 1s late' has been properly set (or, in this case, cleared).

Fast running DCF77 spectrogram with missing amplitude gap in the 59th second of the minute.
The pseudo-random noise is interrupted each second, but the carrier is not reduced.

If your PC's system time is sufficiently accurate (for example controlled via ridiculously simple NTP client),
you can also check the GPS pulse / NMEA timing on the SR calibrator status panel:

If the difference between 'System time' minus 'GPS time' is well below 500 milliseconds,
the current setting of the 'GPS one second late' option is ok.

Left side: Coherent reference signal (10 kHz),
Goertzel filters running, graph on the 'Scope' window
shows the narrow-band spectrum around the reference signal. The last result
of the frequency measurement, and the magnitude of the reference signal are
shown near the peak in the graph.

Right side: One pulse-per-second signal from a GPS
receiver, graph showing the interpolated rising edge of the sync signal.

Other display modes can be selected on the "Sampling Rate Detector" tab,
and a few options can be modified through the scope's context menu. Click
into the graph area, or drag a rectangular marker to zoom in / out.

By default, the old graphs (from previous spectrograms) slowly fade out on
the display. This is not a bug but a feature ;-) ... it helps to discover
intermittent noise, dropouts, or "slowly drifting" signals without the need
for a spectrogram display. The most recent curve is yellow; older curves
fade to brown, and finally disappear after a couple of minutes. Peaks which
look 'smeared' on the display are not stable in amplitude or frequency (or,
for the GPS sync pulse, suffer from jitter). The 'slow fade' option can be
turned off through the context menu, too.

To zoom into the graph, move the mouse pointer into the upper left corner
of the 'region of interest', press and hold the left button, while moving
to the lower right corner. Then release the mouse, and select 'Zoom in' in
the menu. 'Zoom out' zooms out by about 50 percent. 'Reset zoom' zooms out
completely.

The 'Debug' tab in the frequency- and sample rate calibrator window is only used
for troubleshooting and software tests.
During normal operation (with a 'good' input signal), the message list should
remain almost empty. Whenever the sample rate calibrator (or frequency calibrator)
encounters a problem, it will append an error message (unless the error display
is paused). Most of the error messages and warnings should speak for themselves,
thus only a few of the possible messages are listed below.

PulseDet: Excessive SR drift (-0.400 Hz²)
The sample rate drifts faster than expected (more than +/- 0.025 Hz per second).
If this warning only occurs once, it's just a subsequent error of 'noise' that can be ignored.

fo_cal.xxxx = commands and functions for
the frequency offset calibrator:

fo_cal.avrg
Average frequency offset (difference between "measured" frequency and "known
reference" frequency ).
A positive offset means "the measured frequency is TOO HIGH". So to correct
a "measured" frequency, subtract fo_cal.avrg from the measured value before
you display it (but beware: Do NOT subtract fo_cal.avrg if the FFT frequency
bins have already been corrected as explained
here ).

fo_cal.delta_phi
Phase angle difference between to consecutive phase calculations. Should
ideally be zero. Mainly used for program development.

fo_cal.fc
Current center frequency which has been measured by the frequency offset
calibrator. Should ideally be the same value as the "known reference frequency".
You may (ab-)use this function for a precise measurement of a single frequency.
Example: To measure the exact mains frequency ("hum"), set the "Reference
audio frequency" to 50.000 Hz, the "observed bandwidth" to 0.5 Hz, and the
max. offset also to 0.5 Hz (all these values on the control panel of the
Frequency Offset Detector).

sr_cal.xxxx = commands and functions for
the sampling rate calibrator:

sr_cal.avrg
Averaged measured sampling rate. This value is also displayed
in the calibrator's control window. You may use it for
your own application.

sr_cal.ampl
Measured amplitude of the reference signal, converted into dBfs (decibel
over full scale, thus always a negative value).

sr_cal.delta_phi
Phase angle difference between to consecutive calculations. Should ideally
be zero. Mainly used for program development.

sr_cal.fc
Measured reference signal frequency. Calculated by the sampling rate calibrator,
under the assumption that the sampling rate was constant
since the calibrator was started. Should ideally be the same value as the
"known reference frequency". Useful for plotting the audio device's
oscillator drift, if a
drift-free frequency reference (OCXO, GPS) is available.

sr_cal.systimediff
Returns the difference, in seconds, between the PC's system time and the
time decoded by the sampling rate calibrator (for example, from the GPS/NMEA decoder).
The same value is displayed as 'System time minus GPS time' on the
SR calibrator control panel.

Appendix

The following drift rate (red graph in the diagram below) and frequency offset
(green) graphs were made with an internal audio device in a notebook
PC (Thinkpad Z61m, internal "SoundMax HD Audio"). The graph starts a few
minutes after booting the PC. Before that, the PC had cooled off for several
hours. The reference signal (10 MHz OCXO divided down to 10 kHz) had been
running for a couple of days. The soundcard's final sampling rate was calibrated
earlier (in the calibration table).

Sampling rate drift test (Thinkpad, internal audio device)

Each horizontal division is 15 minutes wide. At 09:10, the notebook's cooling
fan started to run, causing the 'bent' curve. The green graph shows the deviation
of the sampling rate; vertical scale range for this channel is +/- 0.5 ppm
(parts per million - see formula at the end of this chapter). The same order
of clock deviation can be expected when measuring frequencies
without the continuous sampling rate calibrator.

Next test candidate: An E-MU 0202 USB (external
audio device in a quite large box). The initial sampling rate deviated
from the final value by over 2 ppm, so during the 'early' warm-up phase,
the trend is only visible on a broader scale (in cyan colour). 5 minutes
after start, the calibrator's tracking algorithm was able to measure and
eliminate the drift (because of the large initial drift rate, and the 30-second
frequency measuring intervals for the Goertzel filters). It's obvious that
the curves are less 'jumpy' than with the internal soundcard, thanks to the
absence of a cooling fan in the box.

Sampling rate drift test (E-MU 0202, USB audio device)

To measure and plot the soundcard
oscillator's drift, the interpreter function
"sr_cal.fc" were used, and SL's
plot window . The expression
1E6*(sr_cal.fc-sr_cal.fr)/sr_cal.fr calculates the current frequency
deviation in ppm (parts per million).
To measure the drift rate (in ppm per minute), calculate the drift
(frequency error in ppm) periodically, and subtract the previous result from
the current result every minute. This can be achieved in the
Conditional Actions table ("DriftRate
= Drift - OldDrift", which is not true maths but it works for this purpose).
The 60 second timebase is provided by one of SL's programmable
timers. Example (copied from the
conditional actions in the configuration 'SoundcardDriftTest.usr') :

To detect the 'carrier phase' of an MSK signal (without demodulating or decoding
it), the complex, downconverted (analytic or "baseband") signal is squared.
This produces two discrete lines in the spectrum, symmetrically around the
carrier frequency.

For example, DHO38 is first multiplied with an complex NCO (numerically
controlled oscillator, with sine- and cosine output) at 23400 Hz, then decimated
until the sampling rate is about 1.5 to 3 times the bitrate. In the decimated,
complex (analytic) signal, the two lines appear like 'sidebands', separated
-100 Hz and +100 Hz from the carrier signal (which is now at 0 Hz, ideally).

The squared baseband signal is then passed through a DFT (discrete fourier
transform, possibly an FFT = Fast Fourier Transform). To avoid locking on
false signals, the amplitudes in the complex frequency bins (at the two
"expected" baseband frequencies) are compared with their neighbours, and
the phases in the complex bins are compared with the previous DFT (in reality,
this step is a bit more complicated because the signals are not perfectly
centered in their FFT bins.. some phase angle fiddling is required for this
reason).

Compared to a continuous wave signal, the MSK carrier phase detection requires
a larger SNR (go figure..) because the observed signal bandwidth (or, the
equivalent receiver bandwidth) is larger. For comparison, measuring the carrier
phase of DHO38 requires approximately a 300 (!) Hz filter bandwidth. For
phase coherent time signal transmitters like DCF77,
the observed bandwidth may be less than 1 Hz.