Re: LF: Adaptive variable resampling

[Andy Talbot <andy.g4jnt@gmail.com>]

I made a custom LF receiver and digitiser, then send the I/Q sampled at 1kHz to the PC on an RS422 interface.

It's described here http://www.g4jnt.com/Coherent_LF_Receiver.pdf

As the sampling is at 1kHz I had to write my own software to decimate and generate the .WAV files that Ebnaut requires.  But do remember I successfully decoded some Ebnaut tests on 137kHz.   The A/D converter is only 10 bits, but the way the I/Q sampling is done itself elevates that to 12 bits then decimation further down the line does the rest.

Like you, I distrust sound cards, and all this over-complex injection of calibration signals to make a silk purse out of a sow's ear seems the wrong route.    Other people have made digitisers, and I believe G3PLX or some associates of his did manage to come up with a proper coherent locked digitiser that emulated a soundcard.

Andy  G4JNT 

On 24 March 2018 at 08:14, Chris Wilson <dead.fets@gmail.com> wrote:

Hello  LF'ers,

I  am  taking  more of an interest in Ebnauat, and was wondering about
hardware  versus  software  locking  of the PC clock to the sound card
clock.  Firstly, are there motherboards and sound cards available that
will  take  a  common  external  reference? Are they very expensive if
available?

Secondly, does Spectrum Lab allow software "locking" and is it similar
to  this  latest  addition  to  HPSDR  that's just been announced? the
explanation just posted on the Apache radios forum states:

"Monitoring and optimization is a nice benefit; however, it’s not the
primary function of this feature.



Digital transfer of data between radio and computer is desirable
because it introduces NO noise or distortion (unlike analog
interfaces); it’s also simpler hardware-wise. However, there’s a
problem. The SDR hardware has a clock and the computer/sound-card also
has a clock. Even if both those clocks are supposedly creating, for
example, a 48Khz sample-rate to interchange data between radio and
computer, they are not locked together. Therefore, for example, the
radio might be generating samples at 48.0001Khz and the sound-card
might be absorbing them at 47.9999Khz, or something like that. With
such scenarios, there will eventually be buffer under-runs or
over-runs because samples are not being generated at the same rate
they are being consumed. When such an under-run/over-run occurs, there
will be a discontinuity/glitch/drop-out in the data stream. If those
don’t happen too often, they aren’t terribly noticeable. However, for
those who expect pure audio and digital emissions, they aren’t very
acceptable. There is a hardware solution: One of our developers has
purchased a computer sound card that can be locked to an external
clock reference, as can the radio. So, when both are locked to the
same reference, the problem goes away. However, that turns out to
require additional hardware and to be a rather expensive solution.



The Adaptive Resampler continually compares the rates at which samples
are being produced and consumed and it calculates a resampling ratio.
The incoming samples are then, mathematically, used to recreate a
continuous waveform and then samples with a slightly different
spacing, corresponding to the output rate, are taken from that
continuous waveform. Thus, the waveform has been resampled. This
matches the two different sample rates.



There are some open-source software solutions out there for variable
or adaptive resampling. However, our solution has an EXTREMELY low
spur level, making it suitable for I-Q data as well as audio. For
audio, most would say if the spurs are 60dB+ down, that’s plenty good
enough. We do MUCH better than that, perhaps a couple hundred dB down,
more than you need. There are also some other somewhat unique features
of this implementation.



Hope that helps.



73,

Warren  NR0V"


Thanks!





--
Best regards,
 Chris                          mailto:dead.fets@gmail.com