To: rsgb_lf_group@blacksheep.org
References: <ef4e8b01-c6c2-6456-1e5d-6daddc963302@abelian.org>
 <58A38C76.9060406@posteo.de>
 <5a6be489-1da5-50d8-b5a1-9ada319703c9@abelian.org>
 <945d5f49-3fc4-d7c1-fecc-196e7c3ac8dd@abelian.org>
 <02e201d287e6$a1386060$e3a92120$@comcast.net> <58A581D3.4080706@posteo.de>
From: Paul Nicholson <vlf0403@abelian.org>
Message-ID: <b8d60422-050c-752f-97fc-9dabca2436fc@abelian.org>
Date: Fri, 17 Feb 2017 21:23:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <58A581D3.4080706@posteo.de>
Subject: Re: LF: Raspberry Pi sound interface that works
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: RO


In three days of testing EbSynth on the Audio Injector and RPi
2 there has been two sound card input overruns.  These occur
when the program cannot read the input buffer fast enough and
it fills up.   The input buffer is 680mS long when running
at 96k/sec.

One of the overruns occurred when it was running with real
time scheduling.    Perhaps the program was blocked while
writing the log file or updating the display.  The RPi is
headless and the screen displays over X11 to my workstation
so it could potentially block long enough du to a dropped
LAN packet.

I've uploaded a v0.7b which splits the program into two threads:
one RT thread runs the synthesizer and keyer, the other normal
thread drives the display and log file.  Now the only thing
the RT thread will block on is the sound device.  It'll need
several days testing to see if this fixes the overruns.  I hope
so, otherwise the Audio Injector will not be good enough to
run EbSynth.

When used for VLF reception with vtcard and vttime, the
occasional input overrun wont be a problem - vttime will
recover back to the proper timing after a few seconds.

The new version needs a -lpthread option at the end of the
gcc command line.

Apart from the overruns, 0.7a ran for 30 hours and drifted
by no more than 0.3 degrees.

Stefan wrote:

 > ...they are available again,
 > https://www.amazon.co.uk/gp/product/B01HBC8CJ0/

That's good to see.  If testing continues to go well I'll
order a couple more next week.

Jim wrote:

 > I saw your message indicating disinclination toward RPi 3
 > power dissipation

Perhaps the unused features can be powered down if not required?
There might be an option for that in /boot/config.txt ?

 > what type of interface would be used between an outdoor RPi 2
 > and an indoor laptop

Maybe the WiFi would carry the downlink.  I don't know if you
can connect a Yagi antenna to it.  I would probably use cat5
cable to uplink power and downlink the LAN.   The RPi, AI, and
GPS would have to be sited some distance from the VLF antenna
and front end anyway, with the usual DC isolation separating
the two.

 > should I be thinking of Audio Injector plus  RPi 2as an
 > unattended datalogger rather than a real-time interface
 > between VLF loop and laptop?

I would use it as a real time interface.  I wouldn't try
to cache the signal on the RPi storage.  A short (~30 sec)
lock-free buffer will isolate vttime from any temporary
network hold-ups.
--
Paul Nicholson
--