From: =?UTF-8?Q?Wolfgang_B=c3=bcscher?= <dl4yhf@freenet.de>
To: rsgb_lf_group@blacksheep.org
References: <dca12b9c-c401-1338-38ff-feed1f7088db@abelian.org>
 <a54b5744-244a-59c2-cc43-b553635714b2@abelian.org>
Message-ID: <52dea779-7aae-aff8-1072-ad24cdcd007c@freenet.de>
Date: Sun, 28 Jan 2018 11:38:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <a54b5744-244a-59c2-cc43-b553635714b2@abelian.org>
Content-Language: en-US
Subject: Re: LF: Testing Audioinjector Octo with RPi3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

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
> -- 
>