Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: Testing Audioinjector Octo with RPi3

To: LineOne <[email protected]>
Subject: Re: LF: Testing Audioinjector Octo with RPi3
From: Andy Talbot <[email protected]>
Date: Sun, 28 Jan 2018 11:12:50 +0000
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0uOUR+KFuUJBmNuAjvNeJtdqUOxFoFQ9KUf8YJGR434=; b=AElqqSEIUkte0LQ1mwaS+n2qw9+npQq4VKZasbgTptdKxc/Z+a0IumDhVYUjzSdOZU AA/6YghiKVtarEwSaMYpVssI8n3QfXOeblwfrRUosbV1lO6ReB0d/Nknysisj3cpWZSu 4lS6CXYPrypYoh9O6ItFLDK8EIcIqYeqPWWfCfymukfnLPU+YG/CMkMoUlC1ZYp4/DSj pHvaCNrv/QIwFN7Xb4fU4ZGwRrXfxlca/8PJLLOvsSRu1fU3mk+k2EmejVt08nGcITYe BS4UslFbN1VZ5fn7C8VnPd+BiXsYJkjRb8fwuLdFJV9WXbFxTMFvNSy/Ev7vXcWbNkum m9eA==
In-reply-to: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
Is a simple design sampling to 10 bit resolution at 80kS/s or 62.5kS/s with embedded timestamp of any interest?

I have one based on a 16F688 PIC and RS422 interface running at 2M baud.   At the PC end an FTDI RS422 converter interfaces to teh PC.
  PIC runs on a 16MHz crystal which can be locked to a reference with simple additional hardware

The 80kHz version just sends samples in two RS422 bytes.   The 62.5kHz version embeds a timestamp into the data stream derived from dividing down the clock, this is set at startup by reading from GPS.

I know it's not as fast or multi channel as RPI etc solutions, but RS422 on a twisted pair (or perhaps optical fibre) is the solution that will give one of the best noise and spurious decoupling options around.

Others in the PIC family, DsPICs have 12 bit A/D and the serial interface data format has been design with 12 bit words in mind


Andy  G4JNT

On 28 January 2018 at 10:38, Wolfgang Büscher <[email protected]> wrote:
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>