MIME-Version: 1.0
In-Reply-To: <52dea779-7aae-aff8-1072-ad24cdcd007c@freenet.de>
References: <dca12b9c-c401-1338-38ff-feed1f7088db@abelian.org>
 <a54b5744-244a-59c2-cc43-b553635714b2@abelian.org> <52dea779-7aae-aff8-1072-ad24cdcd007c@freenet.de>
From: Andy Talbot <andy.g4jnt@gmail.com>
Date: Sun, 28 Jan 2018 11:12:50 +0000
Message-ID: <CAA8k23T1s6w8y8A1dGEnnezQju6pEAEkbGLcCwy_ThG7NkwAcw@mail.gmail.com>
To: LineOne <rsgb_lf_group@blacksheep.org>
Subject: Re: LF: Testing Audioinjector Octo with RPi3
Content-Type: multipart/alternative; boundary="f403045c3d6ad4348d0563d435b0"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

--f403045c3d6ad4348d0563d435b0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=BCscher <dl4yhf@freenet.de> wrot=
e:

> 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 fa=
st
> 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 evaluati=
on
> 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 b=
it
> 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 =C2=A3150.
>>
>> 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
>> --
>>
>>
>
>

--f403045c3d6ad4348d0563d435b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is a simple design sampling to 10 bit resolution at 80kS/s=
 or 62.5kS/s with embedded timestamp of any interest?<div><br></div><div>I =
have one based on a 16F688 PIC and RS422 interface running at 2M baud.=C2=
=A0 =C2=A0At the PC end an FTDI RS422 converter interfaces to teh PC.</div>=
<div>=C2=A0 PIC runs on a 16MHz crystal which can be locked to a reference =
with simple additional hardware</div><div><br></div><div>The 80kHz version =
just sends samples in two RS422 bytes.=C2=A0 =C2=A0The 62.5kHz version embe=
ds a timestamp into the data stream derived from dividing down the clock, t=
his is set at startup by reading from GPS.</div><div><br></div><div>I know =
it&#39;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.</div><div><br></d=
iv><div>Others in the PIC family, DsPICs have 12 bit A/D and the serial int=
erface data format has been design with 12 bit words in mind</div><div><br>=
</div><div><br></div><div>Andy=C2=A0 G4JNT</div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On 28 January 2018 at 10:38, Wolfgang =
B=C3=BCscher <span dir=3D"ltr">&lt;<a href=3D"mailto:dl4yhf@freenet.de" tar=
get=3D"_blank">dl4yhf@freenet.de</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Hello Paul and all,<br>
<br>
Thanks for the detailed analysis (even though the reason for the sampling-p=
oint jitter is still unknown).<br>
Perhaps it&#39;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 / Com=
pare feature) that can be clocked from an internal PLL (crystal clock frequ=
ency * N / M). Such a *hardware*-timer can capture the timer value with a r=
esolution of a few nanoseconds (no pulse interpolation required), to synchr=
onize everything -maybe even the CPU&#39;s own clock- to GPS, etc.<br>
<br>
The long-term availability of development boards from manufacturers like NX=
P and ST may be questionable, but some of ST&#39;s very affordable evaluati=
on boards have been around for some years.<br>
<br>
For example, STM32F373 with a traditional 12-bit ADC (with multiplexed inpu=
ts and DMA support), plus ..<br>
<br>
&quot;3x 16-bit sigma-delta ADCs, with up to 21 single or 11 differential c=
hannels and seven programmable gains per channel&quot;<br>
<br>
Each of these high-precision ADCs samples up to 50 kS/second, which isn&#39=
;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=
 &quot;digital noise&quot;.<br>
<br>
Also, an Ethernet interface instead of the dreadful USB would be nice to ha=
ve..<br>
<br>
Greetings,<br>
=C2=A0 Wolf .<br>
<br>
<br>
<br>
<br>
<br>
On 27.01.2018 22:47, Paul Nicholson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
So far I haven&#39;t been able to improve the PPS jitter of the<br>
Octo any better than 200nS.<br>
<br>
Significantly, when I give it a PPS from the PPS bus that<br>
supplies the three M-Audio cards used for VLF reception, it<br>
still does no better than 200nS, while at the same time the<br>
three VLF channels using the same PPS operate with some 30 to<br>
50nS jitter.<br>
<br>
The input seems clean and low noise, and I can&#39;t see anything<br>
in the data sheet for the CS42448 that would do anything<br>
silly with the sample rate clock, such as a PLL or anything.<br>
It just divides down the 49.152 MHz crystal oscillator.<br>
<br>
So for now I&#39;ve run out of ideas as to the reason for the<br>
jitter being four times what it could be.=C2=A0=C2=A0 Perhaps tomorrow<br>
I&#39;ll hang some extra smoothing on the RPi/Octo power rails to<br>
see if that makes a difference.<br>
<br>
But, it is quite good enough as it stands for most natural radio<br>
tasks except for the most demanding SID monitoring, and good<br>
enough for all amateur radio work.=C2=A0 It runs 6 input channels<br>
at 96k 24 bit samples per second, vtcard works solidly with the<br>
Octo interface, so long as you direct its log file to RAM disk<br>
such as the /run directory.=C2=A0 With the quad core Pi 3 model B,<br>
vttime runs perfectly, using up one whole CPU to resample the<br>
six channels to UT synchronous samples.=C2=A0 The total cost of<br>
a Pi, Octo, GPS module, and a box to put it in, plus a PSU<br>
module and a few other bits - connectors, etc, comes to less<br>
than =C2=A3150.<br>
<br>
Software set up is simple, it takes less than an hour to install<br>
and configure everything: ntpd, gpsd, vlfrx-tools.<br>
<br>
You end up with a headless and perhaps remotely sited SDR, in a<br>
small box running off 12V, which you connect to with Spectrum<br>
Lab from Windows or vlfrx-tools from Linux and you have a five<br>
channel GPS timestamped signal stream to play with.<span class=3D"HOEnZb"><=
font color=3D"#888888"><br>
<br>
-- <br>
Paul Nicholson<br>
-- <br>
<br>
</font></span></blockquote>
<br>
<br>
</blockquote></div><br></div>

--f403045c3d6ad4348d0563d435b0--