Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: Testing Audioinjector Octo with RPi3

To: [email protected]
Subject: Re: LF: Testing Audioinjector Octo with RPi3
From: Wolfgang Büscher <[email protected]>
Date: Sun, 28 Jan 2018 11:38:22 +0100
In-reply-to: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
Hello Paul and all,

Thanks for the detailed analysis (even though the reason for the sampling-point jitter is still unknown). Perhaps it's time to start developing our own A/D conversion hardware. There are fantastic ARM Cortex-M microcontrollers out there, with nice fast multi-channel A/D converter, hardware timers (with the usual Capture / Compare feature) that can be clocked from an internal PLL (crystal clock frequency * N / M). Such a *hardware*-timer can capture the timer value with a resolution of a few nanoseconds (no pulse interpolation required), to synchronize everything -maybe even the CPU's own clock- to GPS, etc.

The long-term availability of development boards from manufacturers like NXP and ST may be questionable, but some of ST's very affordable evaluation boards have been around for some years.

For example, STM32F373 with a traditional 12-bit ADC (with multiplexed inputs and DMA support), plus ..

"3x 16-bit sigma-delta ADCs, with up to 21 single or 11 differential channels and seven programmable gains per channel"

Each of these high-precision ADCs samples up to 50 kS/second, which isn't spectacularly fast. But there are certainly other devices around with a bit more punch, at the expense of a higher supply current and possibly more "digital noise".

Also, an Ethernet interface instead of the dreadful USB would be nice to have..

Greetings,
  Wolf .





On 27.01.2018 22:47, Paul Nicholson wrote:

So far I haven't been able to improve the PPS jitter of the
Octo any better than 200nS.

Significantly, when I give it a PPS from the PPS bus that
supplies the three M-Audio cards used for VLF reception, it
still does no better than 200nS, while at the same time the
three VLF channels using the same PPS operate with some 30 to
50nS jitter.

The input seems clean and low noise, and I can't see anything
in the data sheet for the CS42448 that would do anything
silly with the sample rate clock, such as a PLL or anything.
It just divides down the 49.152 MHz crystal oscillator.

So for now I've run out of ideas as to the reason for the
jitter being four times what it could be.   Perhaps tomorrow
I'll hang some extra smoothing on the RPi/Octo power rails to
see if that makes a difference.

But, it is quite good enough as it stands for most natural radio
tasks except for the most demanding SID monitoring, and good
enough for all amateur radio work.  It runs 6 input channels
at 96k 24 bit samples per second, vtcard works solidly with the
Octo interface, so long as you direct its log file to RAM disk
such as the /run directory.  With the quad core Pi 3 model B,
vttime runs perfectly, using up one whole CPU to resample the
six channels to UT synchronous samples.  The total cost of
a Pi, Octo, GPS module, and a box to put it in, plus a PSU
module and a few other bits - connectors, etc, comes to less
than £150.

Software set up is simple, it takes less than an hour to install
and configure everything: ntpd, gpsd, vlfrx-tools.

You end up with a headless and perhaps remotely sited SDR, in a
small box running off 12V, which you connect to with Spectrum
Lab from Windows or vlfrx-tools from Linux and you have a five
channel GPS timestamped signal stream to play with.

--
Paul Nicholson
--



<Prev in Thread] Current Thread [Next in Thread>