[TangerineSDR] [hamsci-grape] Re: 3-Channel VLF SDR Backend System

Fri Sep 8 10:56:49 EDT 2023

Jonathan,

The I^2C interface is actually the slowest interface on the Pi - 'fast
mode' is only 400 Kbits/sec.  There is a 'HS mode' (3.4 Mbit/sec) but I
don't believe that the the Pi supports that.
And having a bi-directional bus there are turn-around times for bus
direction as well.  Add addressing to that and it ends up being kinda slow.

I^2S is the audio ping/pong data xfer version that goes up to ~2.5 Mhz clk
rate - actual rate is based on audio sample rate

The SPI interface on the Pi is much faster - I've run it at 25 Mbits/sec
without issues on a short bus. And it can communication in both directions
at the same time.

USB 1 does 12 Mbit/ sec --  USB 2  goes up to 480 Mbit/ sec  -- USB3 does
5Gbit/ sec (~500 Mbit after overhead taken into account)

The timing for the data collection on the Grape 2 is done in a hardware
logic 'data engine' I designed - if you want repeatability and reliable
timing for anything in the single digit uSec realm (or faster) you cannot
have a microprocessor involved.  The non-deterministic nature of code
running and background interrupts wreak havoc on consistent timing.
Software averaging doesn't address the basic absolute timing jitter - if
you average anything long enough you can get good numbers but the short
duration timing is still bad.  Basic measurement science...

The data engine uses the 1PPS signal to sync all of the timing aspects of
the data collection including the generation of the GPSDO'd frequencies for
running the engine.  This is accomplished via the UBLOX GPS unit.  It has a
max output frequency of 10 MHz and since that is one of the frequencies
we're monitoring I can't use it.  I compromised at an 8 MHz sample clock as
it (and the harmonics) keep me out of trouble...

The problem with using sound card sampling is multi-faceted:  The clock is
unsynchronized and uncalibrated.  If you're making frequency measurements
(like via a DFT/FFT) the sample clock directly affects this measurement (as
the FFT assumes a precise sample rate as fundamental assumption).  For
normal audio a xtal is good enough, but for the G2 measuring to 0.001 Hz
it's very bad.

The 1 PPS output has a variability of ~ +/- 50 nSec  - averaged over an 8
Mhz GPSDO clock gives a timing error of +/- 6.25 femtoSec (6.25 x 10^-15).
Crazy accuracy but "good enough"  🤔😁

The absolute time stamp is created by the data engine based on the 1PPS /
GPSDO'd freq running the engine and is included in the data stream from the
PICO to the RasPi4B.  Even if the RasPi4B is set up as a Stratum 1 clock,
the timing errors are based on a PID loop the OS is running so absolute
timings are kinda mushy (look at the dynamic stats will show you this) .
Using the OS system clock for timing gives bad results for above mentioned
reasons.

The PICO is feeding the RasPi4B with a firehose of data thru a USB2 port
and is checksummed on the fly (although it could be argued that the USB
protocol / packetization should prevent errors) and save to a file in real
time (3 x 8K words / sec for a data rate of 3x8x2= 48 Kbytes per second or
about 480Kbits/sec with overhead).  We haven't figured out the max transfer
rate between the 2 processors (especially with 1 retry packet) - stay
tuned...

Make sense?

John N8OBJ

On Thu, Aug 24, 2023 at 9:36 AM Jonathan <emuman100 at gmail.com> wrote:

> Hi John,
>
> How does the PPS trigger the sampling?
>
> It's my understanding that the Pico captures data from the A/D converters
> and then sends it over high speed serial uart over USB, so the capture
> software will read the data over a USB UART? The USB UART controller has a
> limited amount of throughput. Other than encapsulating data synchronously
> over USB, the next highest throughput interface in the Pi is the I2S
> interface, I believe.
>
> Are there any facilities in the Pico or the capture software that adds
> timestamp metadata to each sample? vlfrx-tools will not only realign
> samples to the UT second like the Grape 2 will, but it adds timestamp
> metadata to each sample. To use the Grape 2 interface as a VLF receiver,
> the signal will have to be injected after the mixer, and the sample
> alignment accuracy is still very close to what vlfrx-tools can achieve.
>
> Jonathan
> KC3EEY
>
> On Mon, Aug 21, 2023 at 8:47 PM John Gibbons <jcg66 at case.edu> wrote:
>
>> Jonathan,
>>
>> The 1PPS is what starts the block of A/D sampling every second - one of
>> my self imposed requirements is that the real time 1PPS re-syncs the data
>> collection engine every second in real time.
>>
>> Since the RasPi4B (really the OS) cannot tolerate the rigid timing
>> requirements of collecting a sample set every 125 uSec (8.000KHz sample
>> rate - we proved it misses between 3 and 300 sample sets per second!) I've
>> added a dedicated RasPi PICO to do that (it has no OS).
>> The RasPi PICO collects the data under the rigid timing requirements and
>> then sends the 8K x 3 channels of 16 bit A/D data (total of 48K Bytes/sec)
>> to the RasPi4B over a dedicated USB comm port and the RasPi4B (and OS) has
>> to swallow that firehose of data continuously without missing
>> any data (including performing a continuous write to a SSD file - ~10.5
>> GBytes / day).  We are going to push this channel until it breaks to know
>> where the limit is, but I suspect that 96 KHz x 3 channels x 16bit data
>> (for a whopping 576 Kbytes/sec) will probably overwhelm the OS (which I
>> suspect is the weak link here - TBD)
>>
>> The A/D's I'm using can do 100K Samples/sec and is pin compatible with a
>> 500K sample/sec big brother, but that's not the limiting factor in the data
>> collection chain.
>>
>> John N8OBJ
>>
>> p.s. The full 3 channel radio is coming to life for the first time
>> tonight!  Entire RF deck (3 radios, 3 A/D's, Vref) only pulls 71mA @
>> 12VDC.  Stay tuned... (pun intended....)
>>
>> On Mon, Aug 21, 2023 at 1:10 PM Jonathan <emuman100 at gmail.com> wrote:
>>
>>> John,
>>>
>>> Right, TP1 and TP2 are not synchronous on the M8T. You use TP2 for the
>>> sample clock, but how exactly do you utilize the PPS?
>>>
>>> How are you interfacing the A/D converters? Does it have the bandwidth
>>> for 96 kHz sampling or higher?
>>>
>>> It looks like both the Grape 2 and the VLF system have equivalent
>>> timestamping accuracy.
>>>
>>> Jonathan
>>> KC3EEY
>>>
>>> On Mon, Aug 21, 2023 at 9:58 AM John Gibbons <jcg66 at case.edu> wrote:
>>>
>>>> Jonathan,
>>>>
>>>> 1&2 - I'm using the UBLOX M8T freq out and the 1PPS out - but with the
>>>> [(A/B)+C] non integer freq synthesis in the UBLOX the clock domains are no
>>>> longer in sync - they walk wrt each other hence creating 2 seperate clock
>>>> domains (you can see this on a scope with infinite persistence turned on
>>>> looking at 1PPS wrt the freq out) hence the need to sync the clock domains.
>>>>
>>>> 3 - I am capturing ~30Hz to 4KHz audio bandwidth
>>>>
>>>> John N8OBJ
>>>>
>>>>
>>>> On Wed, Aug 16, 2023 at 1:26 PM Jonathan <emuman100 at gmail.com> wrote:
>>>>
>>>>> John,
>>>>>
>>>>> Do you have a time domain plot showing the clock domains?
>>>>>
>>>>> Do you synthesize it from the timepulse2 output on the M8T or do you
>>>>> utilize a DDS with a holdover oscillator?
>>>>>
>>>>> Also, do you capture bandwidth in the audio range or even less?
>>>>>
>>>>> Jonathan
>>>>> KC3EEY
>>>>>
>>>>> On Wed, Aug 16, 2023 at 12:58 PM John Gibbons <jcg66 at case.edu> wrote:
>>>>>
>>>>>> Jonathan,
>>>>>>
>>>>>> Yes - the 1PPS is spot on and the 8KHz A/D sample timing is
>>>>>> synthesized directly from the UBLOX 8MHz GPSDO'd output that runs the
>>>>>> entire data collection engine.
>>>>>>
>>>>>> John N8OBJ
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 15, 2023 at 12:50 PM Jonathan <emuman100 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi John,
>>>>>>>
>>>>>>> Did you take measurements of the PPS  and clock accuracy? How is the
>>>>>>> 8 kHz sample clock synthesized?
>>>>>>>
>>>>>>> The Audio Injector Octo uses a crystal oscillator, but like in the
>>>>>>> previous email thread about timing, vlfrx-tools is constantly making
>>>>>>> measurements and calibrating out the delay, then realigning each sample
>>>>>>> according to that series of calibrations and alignment of the centroid of
>>>>>>> an RC network-shaped PPS. I manually insert a calibration value consisting
>>>>>>> of the time between the rising edge of the rectangular pulse and the
>>>>>>> centroid of the RC network-shaped pulse, giving me similar PPS accuracy as
>>>>>>> you have achieved.
>>>>>>>
>>>>>>> Jonathan
>>>>>>> KC3EEY
>>>>>>>
>>>>>>> On Mon, Aug 14, 2023 at 2:44 PM John Gibbons <jcg66 at case.edu> wrote:
>>>>>>>
>>>>>>>> Jonathan,
>>>>>>>>
>>>>>>>> The absolute accuracy of the 1PPS synchronization lies exactly
>>>>>>>> between 1-2 sync clock cycles (crossing over clock domains requires this to
>>>>>>>> prevent metastability - you must do this as well!)
>>>>>>>> so my 1PPS is always between 125-250 nSec (8 MHz clk) from the 50
>>>>>>>> nSec window that the UBLOX gives me for absolute timing of the 1PPS signal.
>>>>>>>>
>>>>>>>> The derived sample clock, however, is deadly accurate as it is also
>>>>>>>> derived from the UBLOX freq output so it will easily hold 1x10^-10 accuracy
>>>>>>>> and on an 8 KHz sample clock it guarantees me to be within 12.5 aSec (yes
>>>>>>>> 10^-15 sec).  Since I presume you're using the on board clock for your A/D
>>>>>>>> card you will be at least 4 orders of magnitude worse as quartz xtals (or
>>>>>>>> even worse a resonator!) are not so good (not to mention temp drift that
>>>>>>>> will eat you alive...).
>>>>>>>>
>>>>>>>> The sample clock is very important as it determines your A/D sample
>>>>>>>> freq hence directly affects any timing / frequency measurements you extract
>>>>>>>> from your data.
>>>>>>>> For us it directly affects the freq measurement of the carrier freq
>>>>>>>> and needs to be pretty darn good (12.5 aSec is pretty respectable).
>>>>>>>>
>>>>>>>> What is your freq ref standard for the A/D sample clock?  Is it GPS
>>>>>>>> DO'd?  Is it synced to the 1PPS?
>>>>>>>>
>>>>>>>> John N8OBJ
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 14, 2023 at 12:13 PM Jonathan <emuman100 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> Did you take measurements of the sampling and timestamping
>>>>>>>>> accuracy of the Grape 2? I don't believe you included it in the other email.
>>>>>>>>>
>>>>>>>>> Jonathan
>>>>>>>>> KC3EEY
>>>>>>>>>
>>>>>>>>> On Mon, Aug 14, 2023 at 11:21 AM John Gibbons <jcg66 at case.edu>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> That has already been designed and built and hardware tested
>>>>>>>>>> (with better timing for data sampling) - it's called the Grape 2
>>>>>>>>>>
>>>>>>>>>> John N8OBJ
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 14, 2023 at 9:57 AM Jonathan <emuman100 at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> My apologies, the pictures did not attach inline. The
>>>>>>>>>>> attachments are all in order of what I describe.
>>>>>>>>>>>
>>>>>>>>>>> Jonathan
>>>>>>>>>>> KC3EEY
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 14, 2023 at 6:20 AM Jonathan <emuman100 at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I have been working on a 3-channel VLF backend system similar
>>>>>>>>>>>> to the single channel system I built in 2020. It's based on a Raspberry Pi
>>>>>>>>>>>> 3, Audio Injector Octo Soundcard, Trimble Resolution SMTx GPS timing
>>>>>>>>>>>> receiver, and VLF preamp interface board and power distribution. It's
>>>>>>>>>>>> designed to capture VLF spectrum from an E-field receiver and an orthogonal
>>>>>>>>>>>> loop dual channel H-field receiver for triple axis reception of the VLF
>>>>>>>>>>>> band. With it, bearing can be determined and the loops can be synthesized
>>>>>>>>>>>> for any bearing based on how the loop signals are mixed. This provides
>>>>>>>>>>>> additional analysis of VLF signals using the powerful vlfrx-tools software.
>>>>>>>>>>>> Everything in mounted in a Hammond dicast aluminum enclosure. In the center
>>>>>>>>>>>> is the Raspberry Pi 3B, Audio Injector Octo Soundcard with audio breakout
>>>>>>>>>>>> board, and TTL<>RS232 adapter for the serial console. On the left are
>>>>>>>>>>>> power, capture, and timing status indicator LEDs as well as a safe shutdown
>>>>>>>>>>>> button to safely unmount the data USB drive. On the right is the Trimble
>>>>>>>>>>>> Resolution SMTx and interface board. On the bottom is the VLF receiver
>>>>>>>>>>>> interface board.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is the Pi 3B with Audio Injector Octo soundcard. It has 6
>>>>>>>>>>>> audio inputs and can sample up to 96 kHz. The audio breakout board breaks
>>>>>>>>>>>> out the audio inputs to RCA jacks, which I removed, for a direct solder
>>>>>>>>>>>> connection. The PPS from the GPS gets get through a potentiometer for
>>>>>>>>>>>> adjustment to 80% of the soundcard’s full scale. I will be feeding it
>>>>>>>>>>>> through an RC network to shape the 125 us pulse. The PPS is also connected
>>>>>>>>>>>> to a GPIO pin for use with the ppsgpio driver, GPS Daemon, and ntp and
>>>>>>>>>>>> functions as a networked stratum 1 time server as well. Data is stored on a
>>>>>>>>>>>> 512 MB USB drive. The console port is accessible via TTL<>RS232 adapter (in
>>>>>>>>>>>> blue heat shrink) for complete headless operation, especially when the
>>>>>>>>>>>> network is not available. Both the Ethernet and RS232 are connected to RJ45
>>>>>>>>>>>> bulkhead couplers for panel jack connection. The indicator LEDs, shutdown
>>>>>>>>>>>> button, console port, and GPIO PPS all connect through a 40-pin female
>>>>>>>>>>>> header.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The GPS is a Trimble Resolution SMTx GPS timing receiver. I
>>>>>>>>>>>> used it because it was cheap and what I had on hand, but still performs
>>>>>>>>>>>> well for an older model of the Trimble/Protempis GNSS timing receiver line.
>>>>>>>>>>>> The PPS time pulse width is 125 us. It’s powered using the handy PPS Piggy
>>>>>>>>>>>> interface board for Trimble/Protempis receivers. The antenna is connected
>>>>>>>>>>>> through an SMA to SMB pigtail with bulkhead SMA jack. The other hole in the
>>>>>>>>>>>> enclosure is for the Raspberry Pi WiFi antenna jack which I will add later.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The indicator LEDs are panel mounted as well as the safe
>>>>>>>>>>>> shutdown button. These provide an indicator for power, soundcard capture,
>>>>>>>>>>>> and GPS timing, with the later two controlled by GPIO pins and series
>>>>>>>>>>>> resistors. The safe shutdown button will issue “shutdown -h now” when
>>>>>>>>>>>> pressed for longer than 3 seconds to safely unmount the USB drive if no
>>>>>>>>>>>> network or console access is available. Data will constantly be written to
>>>>>>>>>>>> the USB drive during normal operation in bursts. The USB drive is ext2
>>>>>>>>>>>> fornated. The LED indicators and safe shutdown button are monitored via
>>>>>>>>>>>> script.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Lastly, this is the VLF receiver interface board. It provides
>>>>>>>>>>>> power to the Pi and GPS receiver using an adjustable 3A DC-DC converter set
>>>>>>>>>>>> to 5.1V. Power to the E-field and H-field VLF receiver channels is through
>>>>>>>>>>>> 24V isolated DC-DC converters. Main power comes in via 12V unregulated
>>>>>>>>>>>> wallwart and drives both the adjustable DC-DC converter and the isolated
>>>>>>>>>>>> DC-DC converters. The VLF receiver channels also have audio isolation
>>>>>>>>>>>> transformers to maintain isolation between the backend system and VLF
>>>>>>>>>>>> preamp and connect to the audio inputs on the audio breakout board. Both
>>>>>>>>>>>> the power and signal paths have 10M bleeder resistors to bleed off any
>>>>>>>>>>>> excess charge on the feedline as well as gas discharge arrestors for surge
>>>>>>>>>>>> protection. The feedline is shielded cat5 or cat 6 cable pairs and connect
>>>>>>>>>>>> to the green screw terminals. The isolated DC-DC converters are plugged
>>>>>>>>>>>> into pin sockets and are removable in case the feedline is too long and 48V
>>>>>>>>>>>> DC-DC converters are used to maintain the voltage at the end of the
>>>>>>>>>>>> feedline due to the voltage drop of a long feedline. The board also
>>>>>>>>>>>> provides a connection to power LED indicator as well.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> My next step is to fine tune the shaped PPS pulse for more
>>>>>>>>>>>> accurate timing. Once complete, I will start work on the dual channel
>>>>>>>>>>>> H-field receiver.
>>>>>>>>>>>>
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>> KC3EEY
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>> Google Groups "hamsci-grape" group.
>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>> it, send an email to hamsci-grape+unsubscribe at googlegroups.com.
>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>> https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB1oFMEHL2-ph5Re%3DOBnBBz%2Bv7aKhZiYnvH5gFTS0L4K-g%40mail.gmail.com
>>>>>>>>>>> <https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB1oFMEHL2-ph5Re%3DOBnBBz%2Bv7aKhZiYnvH5gFTS0L4K-g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20230908/add08d42/attachment-0001.html>