[TangerineSDR] VLF Audio Interface for Tangerine SDR

[Jonathan]

Hi Bill,

Some amazing work was described in that paper! It is very thorough and 
covers everything from receiver design to post processing. Thank you for 
providing me this information. I have wondered what ever became of the 
data from the early VLF work, especially done at Stanford. I appreciate 
these great resources! I hope that my module can enable such great work 
with the Tangerine SDR.

Scotty, Tom,

Here are some rough data rate calculations:

16-bit samples * 192k samples per second * 4 channels = 12.288M bits per 
second

24-bit samples * 192k samples per second * 4 channels = 18.432M bits per 
second

Can this be supported on the leaf interface or will the higher speed 
interface be required? Let me know if you think I'm overlooking something. 
I'll have to look at the datasheet further to determine the maximum bit 
clock frequency. I forget if it was mentioned, but was it the maximum 
clock frequency of the programmable frequency output of the GPSDO?

Depending on what interface is used, do you have finalized pinouts or 
available voltage buses on the connector?

Also, what connector will be used and do you have any mechanical 
dimensions finalized yet? If not, I'll continue working on the 
circuit and schematic.

Thanks again.

Jonathan
KC3EEY

On Wed, 15 Jul 2020, Bill Liles wrote:

> Date: Wed, 15 Jul 2020 13:01:55 -0400
> From: Bill Liles <lilesw at gmail.com>
> To: Jonathan <emuman100 at gmail.com>
> Cc: TAPR TangerineSDR Modular Software Defined Radio
>     <tangerinesdr at lists.tapr.org>, Tom McDermott <tom.n5eg at gmail.com>
> Subject: Re: [TangerineSDR] VLF Audio Interface for Tangerine SDR
> 
> Jonathan, thanks for the info.
>
> You can read about the AWESOME receive equipment at
> M. B. Cohen, U. S. Inan and E. W. Paschal, "Sensitive Broadband ELF/VLF
> Radio Reception With the AWESOME Instrument," in IEEE Transactions on
> Geoscience and Remote Sensing, vol. 48, no. 1, pp. 3-17, Jan. 2010, doi:
> 10.1109/TGRS.2009.2028334.
>
> A site you might find interesting is the Low Frequency Research Group at
> Georgia Tech at http://lf.gatech.edu.
>
> There is also a database of VLF and lower data know was the Worldwide
> Archive of Low-Frequency Data and Observations (http://lf.gatech.edu). This
> database has data from the mid 1970s till now.
>
> Bill, NQ6Z
>
> On Wed, Jul 15, 2020 at 12:47 PM Jonathan <emuman100 at gmail.com> wrote:
>
>> Hi Bill,
>>
>> I appreciate all of the support from everyone!
>>
>> Yes, the plan is to have at least three to four input channels, depending
>> on the limitation of board space. Each channel requires an analog input
>> stage that is outlined in the data sheet, so I?ll try to utilize quad op
>> amps. One channel will be for the E-Field probe receiver and the other two
>> for the North-South and East-West B-Field loop receivers. With triple axis
>> reception, bearings can be calculated for signals of interest. I invite you
>> to take a look at the amazing visualization of the utility program called
>> vtpolar in vlfrx-tools on the documentation page at
>> http://www.abelian.org/vlfrx-tools/notes.html and click on ?Polar
>> Displays?. Click on the example video to show you a live polar plot of a
>> three channel stream (E-Field, N-S B-Field, E-W B-Field) containing a bunch
>> of sferics and whistlers. It plots the bearing and amplitude in real time
>> with audio! It?s so cool! A network of these receivers can be used for not
>> only lightning location, but other VLF event location, like locating the
>> exit point of a whistler.
>>
>> The user will receive a stream of direct samples with an added timestamp
>> on each sample. I?m not sure how it would be implemented, but I do also
>> believe I/Q data can be generated in the FPGA. This can also open more
>> doors in signal analysis. This would be something worthwhile to investigate
>> after the milestones have been reached.
>>
>> I have not heart of the Awesome project. Do you have some information on
>> it?
>>
>> Jonathan
>> KC3EEY
>>
>> On Jul 14, 2020, at 5:35 AM, Bill Liles <lilesw at gmail.com> wrote:
>>
>> Jonathan, sounds really good. I would just like to clarify some things.
>>
>> 1) The board will have multiple inputs so that one can do things such as
>> connect two loop antennas to get lines of bearings to the signals of
>> interest. Is this true?
>>
>> 2) At the user level, will the use receive just a real stream of sample
>> data or with the user receive I/Q data? I realize that the CS5364 (great
>> selection) only outputs real data but additional FPGA processing could
>> produce I/Q data.
>>
>> Thanks for doing this.
>>
>> Are you familiar with the Awesome project out of Georgia Tech?
>>
>> Bill, NQ6Z
>>
>>
>> On Tue, Jul 14, 2020 at 1:06 AM Jonathan via TangerineSDR <
>> tangerinesdr at lists.tapr.org> wrote:
>>
>>> Hi Tom, All,
>>>
>>> I agree, I think the CS5364 is a great choice. I also agree that the
>>> sampling rate ranges don't seem conventional, but I believe one reason
>>> for this is to make a hardware or standalone mode functional. This
>>> ADC, like many other Cirrus audio ICs have both hardware and software
>>> control modes which can make it very versatile.
>>>
>>> I will be working on the design of this board. I know everyone is busy
>>> with various tasks, so I'd like to contribute. No other SDR has this
>>> sort of option, so I think this will prove valuable in the long run to
>>> allow for VLF natural radio study and dreamers band (8.720 kHz) QSOs
>>> on the TangerineSDR. My plan is to do a layout that will include the
>>> ADC, analog input stages, clock routing, and digital audio interface.
>>> I'll need help with the FPGA hardware description and low noise layout
>>> practice.
>>>
>>> I believe for this application, software control is the best approach,
>>> and can be either
>>> SPI or I2C. For configuration of the board from the data engine, I'd
>>> like to have:
>>> 16 or 24-bit sample lengths
>>> 48/96/192 kHz sampling rates
>>> 1/2/3/4 channels for audio capturing, so I believe TDM mode is best
>>> whether two or more than two channels are selected for capture. I2S
>>> only allows for transmission of up to two channels at a time.
>>>
>>> The reason why I chose the CS5364 is because a high end audio
>>> interface used for music and audio recording utilizes a similar IC
>>> from Cirrus, and it happens to be utilized by many in the VLF
>>> community as a VLF SDR. It's the Behringer UMC404HD. (it's product
>>> page is https://behringer.com/product.html?modelCode=P0BK1)
>>> It utilizes the CS4272 stereo audio codec (datasheet at
>>> https://statics.cirrus.com/pubs/proDatasheet/CS4272_F1.pdf). Codecs
>>> contains audio inputs and outputs which is unnecessary for this
>>> application and also has the limitation of using only its internal
>>> clock and no MCLK input. Some people in the VLF community also use the
>>> UMC202HD which has two inputs instead of four.
>>>
>>> The purpose for my board will be to replace the soundcard,
>>> computer/Raspberry Pi, and GNSS receiver completely and integrate
>>> everything into my board and the Tangerine SDR. This way, the stream
>>> can be sent over the network to any host for later processing using
>>> either Spectrum lab (Windows) or vlftx-tools (Linux/BSD/Solaris).
>>>
>>> An example of a permanent VLF receiver installation is Mike Smith's
>>> setup. You can see from his site
>>> (https://www.n4vlf.net/efield-current.html) a schematic/block diagram
>>> of his receiving system that includes a VLF E-Field receiver,
>>> amplitude modulated optical audio feedline (eliminates the need for
>>> isolation transformers), and PC/soundcard/GPS setup.
>>>
>>> On his PCs, one of them uses a 192 kHz soundcard to capture the VLF
>>> signal and GPS PPS. He uses Linux with vlfrx-tools. The utility
>>> program that captures audio from the soundcard, vtcard, captures audio
>>> from the soundcard at a sample rate and sample length of your choosing
>>> specified by runtime options. Timestamping is done by vtcard, but
>>> using the soundcard's clock. The utility program vttime samples the
>>> audio stream for the GPS PPS pulse and produces an offset value to
>>> adjust the timestamps to align with GPS time. With the Tangerine SDR,
>>> the ADC will be clocked with the GPSDO, so because of its stability,
>>> the timestamping should not need to be adjusted.
>>>
>>> Lastly, Mike also has a block diagram
>>> (https://www.n4vlf.net/vlfrx.html) of all the utility programs in
>>> vlfrx-tools used on his PCs. The audio is hum filtered, resampled, and
>>> sent to event detectors for detecting whistlers, chorus, and sudden
>>> ionospheric disturbances, as well as streamed for live listening,
>>> storage, and retrieval.
>>>
>>> vlfrx-tools is written by Paul Nicholson, one of my personal idols.
>>> His work in VLF is absolutely amazing and myself and the rest of the
>>> VLF community are absolutely indebted to him. I invite all of you to
>>> look at his page (www.abelian.org) and be sure to look at his
>>> vlfrx-tools software.
>>>
>>> David McGaw,
>>>
>>> The reason for choosing the extended audio range is to focus on
>>> natural radio events in the VLF band, primarily occurring in the lower
>>> VLF band and upper ULF band. Also, can you give some more detail on
>>> understanding the dynamic range using 16-bit samples?
>>>
>>> Jonathan
>>> KC3EEY
>>>
>>>
>>>
>>> On 7/13/20, Tom McDermott <tom.n5eg at gmail.com> wrote:
>>>> Hi Jonathan,  this looks like a good addition to the receivers available
>>>> for TangerineSDR.
>>>> The CS5364 IC has some nice specifications, and the ability to receive
>>> an
>>>> external clock,
>>>> so it looks like a good potential choice.
>>>>
>>>> I notice that the frequency selectable input range is interesting (I've
>>> not
>>>> seen a similar mode
>>>> selection of operation on other components):
>>>> * 2 khz - 54 khz  or
>>>> * 54 kHz - 108 kHz  or
>>>> * 108 kHz - 216 kHz
>>>>
>>>> -- Tom, N5EG
>>>>
>>>>
>>>> On Sun, Jul 12, 2020 at 10:14 PM Jonathan via TangerineSDR <
>>>> tangerinesdr at lists.tapr.org> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> For those who don't know me, I'm Jonathan, KC3EEY, a natural radio VLF
>>>>> enthusiast. I'm also a senior EE student at the University of Scranton
>>>>> with Nathaniel, W2NAF. When Nathaniel and I first met, we both
>>>>> discussed our projects, interests, and work. He talked about the
>>>>> possibility of adding VLF capability to the PSWS and since then I was
>>>>> always thinking about how to implement it.
>>>>>
>>>>> VLF receivers are often homebrew and consist of an input stage
>>>>> interfacing an H-field loop or E-field probe to a gain or driver stage
>>>>> with the end result an audio output. It's convenient that  most of the
>>>>> VLF band is within the audio range which means no downconversion is
>>>>> needed and can be recorded directly as audio. Some examples of E-Field
>>>>> receivers are Steve McGreevy's WR-3 and BBB-4, as well as the NASA
>>>>> Project INSPIRE VLF3 receiver. Most of these receivers are intended
>>>>> for portable use but can be used in permanent installations. For the
>>>>> PSWS, VLF receivers will be used in a permanent installation, like the
>>>>> HF antenna. The intended setup for this purpose will consist of an
>>>>> E-field receiver and two H-field receivers with orthogonal loops for
>>>>> triple axial reception. This allows for distance and bearing
>>>>> calculations of VLF signals.
>>>>>
>>>>> The VLF receivers will be setup in a location with minimal power line
>>>>> interference so as not to overload the input or gain stage of the
>>>>> receiver. Rural areas are ideal locations, but sometimes suburban
>>>>> locations can be suitable. The receivers can be powered by batteries
>>>>> or through isolating DC-DC converters operating at a high switching
>>>>> frequency above VLF. The audio output from the receivers must also
>>>>> have an audio isolation transformer on  the audio output on the
>>>>> receiver. The audio (and sometimes power) is fed through a feedline of
>>>>> cat5/6 cable or coax, and on the other end it connects to the
>>>>> soundcard of a computer for audio capture. An audio isolution
>>>>> transformer is also needed on the soundcard end as well (and an
>>>>> isolating DC-DC converter if powered by the feedline). The reason
>>>>> isolation is required is because power line interference can be
>>>>> coupled into the receiver, often through earth and chassis grounds
>>>>> like the chassis of a computer.
>>>>>
>>>>> For the Tangerine SDR, I wanted to offer to design a plug in module
>>>>> for one of the interfaces on the data engine. A soundcard is often an
>>>>> ideal SDR for VLF, so I had a "soundcard interface" module in mind. I
>>>>> wanted 192 kHz sampling with 16-bit samples and a high dynamic range,
>>>>> at least 100 dB. After some research, I decoded to use the CS5364
>>>>> 4-channel audio analog to digital converter. Digital audio output is
>>>>> accomplished with TDM or I2S which is clocked into the FPGA of the
>>>>> data engine. From there, the samples are GNSS time-stamped and made
>>>>> available via a TCP socket over the ethernet port.
>>>>>
>>>>> As discussed with Tom and Scotty in the Tangerine SDR Zoom, the GPSDO
>>>>> will provide the A/D master clock and time-stamping will be done in
>>>>> the FPGA. The CS5364 has both hardware and software configuration mode
>>>>> and looks fairly easy to use. I plan on looking into the evaluation
>>>>> board and starting the design of the input stages. This is a little
>>>>> new to me, but I have dabbled in digital audio in the past,
>>>>> specifically with Cirrus Logic audio ICs. I plan on laying out the
>>>>> board in Kicad. Details on the timestamping, possibility of hardware
>>>>> or software control, and network availability will come soon.
>>>>>
>>>>> Thanks again.
>>>>>
>>>>> Jonathan
>>>>> KC3EEY
>>>>>
>>>>> --
>>>>> TangerineSDR mailing list
>>>>> TangerineSDR at lists.tapr.org
>>>>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>>>>
>>>>
>>>
>>> --
>>> TangerineSDR mailing list
>>> TangerineSDR at lists.tapr.org
>>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>>
>>
>