Hi

Is it always out in the same direction ( = broken counter) or does it
bounce back and forth to each side of “correct” ( = noise) ?

Yes and there are threads on the list about doing this. The quick wrap up is:

1. Find the clock source (oscillator or crystal) on the sound card.
2. Pull it off the card and attach a cable.
3. Synthesize the correct frequency off of your GPSDO’s output (generally
   with some sort of PLL / VCO arrangement)
4. Feed the signal into the cable to the sound card

Bob

Hi Chris,

On 10/31/2015 11:50 AM, Chris Wilson wrote:

Your assumption is wrong.

There is a +/- 1 error in counting cycles.
Also, if the start and stop does not derive from the same trigger,
differences in the triggers can result in a time-shift which bias the
value. Difference in delay for start and stop events in the counter also
produces error. Also, the white phase noise contribute.

In essence, a number of practical design limitations makes measurements
somewhat noisier and somewhat biased compared to what theory says. It's
important to understand these so that their effect can be estimated and
sometimes mitigated.

There is sound-cards you can lock to a 48 kHz clock.

Cheers,
Magnus

Chris,

I do not know which soundcard you have in mind - hope to be not totally
off-topic.
I use a KS-24361 10MHz signal at the Mutec MC-3+ reference input to feed
MC-3+ generated word clock with better (short time) stability into my
sound cards.
Sound quality improvement of course depends on the world clock handling
on the given card - works fine with both, RME AES PCI and Lynx L22.
hth
Ulli

Chris welcome to the group.
Several comments.
The 1 or 2 Hz most likely is trigger and jitter. Its somewhat odd that you
are off by 2 Hz. Typically its 1 Hz.
I suspect you are also working 136 KHz. With respect to sound cards the
internal clock could be replaced and locked if its at all accessible. With
todays integration thats hard to say.
Regards
Paul
WB8TSL

On Sat, Oct 31, 2015 at 6:50 AM, Chris Wilson chris@chriswilson.tv wrote:

Chris:

If by "purely mathematical" you mean with infinite precision and infinite
accuracy in the calculations, then the answer is "No."

The counter is using integer mathematics, in a world with propagation
delays and clock jitter, and uncontrolled phase relationships.
So resulting rounding errors and lost remainders in division processes.
If you read the specs on any counter, you will find that there is a
absolute accuracy PLUS an error window of (typically) plus or minus one
count.  Both error sources are very real.

I assume you mean 136 kHz.

But the answer to your sound card question is that you can't just GPS lock
the data converter on the sound card.  If it is running in a different
"clock domain" than the synchronous signal processing that follows it, then
you usually start having buffer underflows and buffer overflows which
introduce signal integrity problems.  The sound card sampling clock is
usually derived from some master clock in the computer, such that the sound
card is running in the same clock domain as the rest of the computer, so
you more likely need to GPS lock the whole computer.  This capability is
normally not provided for consumer grade computers, so you will be on your
own for the circuit modifications.

If you are doing signal processing in a desktop or laptop computer, they
are not "real time" operating systems, so understand the implications of
that, too.

--- Graham

==

On Sat, Oct 31, 2015 at 5:50 AM, Chris Wilson chris@chriswilson.tv wrote:

On 10/31/15 3:50 AM, Chris Wilson wrote:

you could probably get a DDS of some sort to take the high quality 10MHz
and turn it into the clock frequency of your sound card. You'd need to
figure out how to pull the XO off the board and feed an appropriate
signal in.

There's a fair number of people interested in this, so I suspect someone
has already done it.

The other approach is to replace the XO on sound card with a VCXO, and
"discipline" it against the 1pps from the GPS.  It's a matter of using a
different divisor than 10,000,000.

Am Sat, 31 Oct 2015 10:50:36 +0000
schrieb Chris Wilson chris@chriswilson.tv:

In principle yes. In practice this is a bit more involved, but still
possible. The easy way would be professional audio equipment, where
A/D-Converters quite often can be fed externally with a Master clock.
This is often used in studio arrangements, where one doesn't want
sampling clocks of different modules to drift relative to each other.
But the obvious downside is that professional audio equipment that
supports this kind of operation out of the box is "slightly" more
expensive than standard consumer stuff and usually isn't made to fit
into a computer but rather a 19 inch rack.

With Consumer sound cards, this is also possible, but requires some
hardware hacking in order to replace the onboard oscillator with
something that allows for locking to a frequency standard.

In both cases, the frequencies used there are somewhat odd compared to
what the average time nut has available: common master clock frequencies
are on the order of 16, 24, 32, 48 or 64 times the sampling frequency
for said professional equipment, consumer stuff often is clocked with
something like 6.144MHz (=128 times 48 kHz) or something similar.

That's nowhere near a clean 5 or 10 MHz a time-nut is likely to have
around... Which doesn't mean this would be difficult, in the end such a
setup is no different from usual time-nuts or lab setup, just the PLL
division ratio is different to lock the oscillator to a 1PPS signal.
But still, mod'ing consumer equipment takes some time to research the
actual circuit used and come up with a way to couple this to a known
good frequency source...

Florian

On Sat, October 31, 2015 10:03 am, Graham / KE9H wrote:

computer, so

Generally never true.  Sometimes on integrated (on motherboard) converters
the sample clock may be derived from a system clock, but that is a
convenience factor, not consequential to the design, and every add in card
(PCI or PCI Express) has an independent oscillator providing the sample
clock.  The samples are buffered and delivered asynchronously to and from
the processor over PCI or PCI Express, with bus operation not related to
the sample clock.
USB is slightly more complicated because there are multiple ways clocking
is handled.  Asynchronous isochronous mode is essentially the same as
described above.  USB adaptive isochronous mode throws some wrinkles in
that are probably not worth discussing in this context (unless it turns
out the original poster is trying to modify a USB sound interface and not
a PCI or PCIe interface).

--
Chris Caudle

Hi Chris and Bob,

On 10/31/2015 02:13 PM, Bob Camp wrote:

Does not have to be a broken counter, not at all.

For instance, the SR620 displays this kind of behavior if you have not
calibrated it correctly.

Counters measure elapsed time and elapsed events.
If you divide time with events you get average period measure.
If you divide events with time you get average frequency measure.

While the time-base tries to give you a second worth of measures, in
actual life it only delays the trigger of the "stop" in relation to the
"start" trigger that time, and then the "stop" even is recorded and the
elapsed time occurs.

If "start" and "stop" triggers does not trigger at the same phase (due
to voltage offsets or time offsets), then there will be a time-bias.
Some counters calibrate this bias out, where as others try hard to avoid
it. If you don't calibrate it properly, this bias can cause a shift up
or down in perceived frequency measure. This is not necessarily a sign
of a broken counter, it's a sign of an uncalibrated counter.

For instance, the SR620 auto-calibration does not cancel this effect,
you have to adjust the calibration manually to zero it out.

Another flaw could be missed or added cycles, as it adjust the event
count in the above formula. Those usually show themselves as larger error.

Some people is very fond of using the frequency measure of counters,
I've grown more and more sceptic to it for a number of reasons when
doing ADEV and friends, then I use TI that avoids a number of issues.
But that is a much more involved story.

Cheers,
Magnus