<div dir="ltr">Hi Jonathan,<div><br></div><div>  As Ryan said, some kind of a tool as he described it which reads from a pipe should be straightforward.  The example you've given is a way to get started, and I'll talk with him later about getting that implemented.  It's a use case we want to support.</div><div><br></div><div>Cheers</div><div>Phil W1PJE</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 11, 2021 at 8:16 PM Jonathan <<a href="mailto:emuman100@gmail.com">emuman100@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Phil,<br>
<br>
I understand now. The same issue has been encountered in seismology with <br>
the many different formats to store seismic wave data. The current winners <br>
now seem to be SAQ and miniseed formats, where miniseed has the ability to <br>
store metadata, such as instrument type and calibration data required for <br>
that seismic instrument. Both formats and others have detailed spec <br>
documentation. (I believe you can store metadata in the SAQ format as <br>
well, but I'm not sure)<br>
<br>
In that case, since purely real streams can be supported, is there a <br>
possibility of a conversion tool becoming a reality? I cannot support <br>
writing a conversion tool, but others seem to want such a utility. If you <br>
go to the root of the vlfrx-tools site and navigate to "live streams", <br>
then on any one of the streams, click "events", a page will come up that <br>
shows whistler and chorus events (with a lot of false triggers due to <br>
motors starting up). With each event, you can download the .vt file and <br>
use it as an example file for a conversion utility.<br>
<br>
Jonathan<br>
KC3EEY<br>
<br>
<br>
On Thu, 11 Mar 2021, Phil Erickson wrote:<br>
<br>
> Date: Thu, 11 Mar 2021 19:57:54 -0500<br>
> From: Phil Erickson <<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a>><br>
> To: Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">emuman100@gmail.com</a>><br>
> Cc: TAPR TangerineSDR Modular Software Defined Radio<br>
>     <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
> Subject: Re: [TangerineSDR] VLF-RX tools<br>
> <br>
> Hi Jonathan,<br>
><br>
>  There are only a very few formats that are designed for long term and<br>
> cross-platform "survival" across many different operating systems and<br>
> languages, and which have enough embedded metadata to describe the data in<br>
> enough detail to allow applications that were not thought of at the time of<br>
> recording.  HDF5 is the product of a huge amount of work - decades of<br>
> person-years - to enable that sort of survivability.  We therefore use it<br>
> as the carrier, with DigitalRF as the particular data structure implemented<br>
> in it.<br>
><br>
>  I think Ryan's separate message is a workflow that would allow all the<br>
> good toolsets to be implemented without changing the way that the recording<br>
> happens.  Note as well that we do support purely real streams (no need to<br>
> always have I and Q) and getting a good use case which implements that is<br>
> on our list of ways we want to move forward with the format.<br>
><br>
> Cheers<br>
> Phil W1PJE<br>
><br>
> On Thu, Mar 11, 2021 at 7:47 PM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">emuman100@gmail.com</a>> wrote:<br>
><br>
>> Hi Phil,<br>
>><br>
>> When you mean "not always persistent across decades of measurements", do<br>
>> you mean sampling rate and sample length inconsistency across different<br>
>> data sources?<br>
>><br>
>> Yes, it is a purely real signal. There is a utility called vtresample that<br>
>> will resample the VLF stream and maintain timestamp alignment. And you are<br>
>> exactly right, there is a file in the source called vtlib.h which looks to<br>
>> define the timestamping format. Many of the utilities have this as an<br>
>> #include.<br>
>><br>
>> The author must not have felt a need to document the format. He's not<br>
>> affiliated with a university and I don't believe he's a licensed ham,<br>
>> however, he's an active VLF enthusiest. He must have written his tool set<br>
>> and used his format to maintain persistence in the data. I have always<br>
>> felt that his format was adequate, especially when using his stream<br>
>> manipulation utilities which align and maintain timestamping.<br>
>><br>
>> I wasn't sure about the reason for the insistance on using DigitalRF for<br>
>> VLF data analysis and storage on the TangerineSDR other than that's what<br>
>> the grants are paying for everyone to support. It's such a useful tool set<br>
>> that it seems like a waste not to utilize it.<br>
>><br>
>> Jonathan<br>
>> KC3EEY<br>
>><br>
>> On Thu, 11 Mar 2021, Phil Erickson wrote:<br>
>><br>
>>> Date: Thu, 11 Mar 2021 19:12:58 -0500<br>
>>> From: Phil Erickson <<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a>><br>
>>> To: Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">emuman100@gmail.com</a>><br>
>>> Cc: TAPR TangerineSDR Modular Software Defined Radio<br>
>>>     <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
>>> Subject: Re: [TangerineSDR] VLF-RX tools<br>
>>><br>
>>> Hi Jonathan,<br>
>>><br>
>>>  We'll take a look.  For a purely real signal (e.g. cos(\omega t)), of<br>
>>> course you would need exp(j \omega t) in I and exp(-j \omega t) in Q.  I<br>
>>> believe DigitalRF may have the ability to capture purely real signals<br>
>>> without the need to do 2X expansion into I and Q, but I'll ask.  Things<br>
>>> like PCM audio streams are unfortunately not always persistent across<br>
>>> decades of measurements (we know this sort of thing from hard experience<br>
>> at<br>
>>> Haystack), so we choose HDF5 for long term persistence.<br>
>>><br>
>>>  I don't have the time at the moment to wade through code, but if this is<br>
>>> C code, it is likely there is a header file (".h") somewhere that<br>
>> contains<br>
>>> the stream format.  You might post that here when it's found.  For this<br>
>>> application, "derived from the source code" definitely needs to be<br>
>> replaced<br>
>>> with a formal data specification and that could form the start of it.<br>
>>><br>
>>> Cheers<br>
>>> Phil W1PJE<br>
>>><br>
>>> On Thu, Mar 11, 2021 at 7:02 PM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">emuman100@gmail.com</a>> wrote:<br>
>>><br>
>>>> Hi Phil,<br>
>>>><br>
>>>> The stream format is not documented, however, it can be derived from the<br>
>>>> source code of many of the utility programs, like vtcard, vtcat, vtraw,<br>
>>>> and vtwavex to name a few. It's single-channel or multi-channel pcm with<br>
>>>> timestamping information. vtcat can combine single channel streams, say<br>
>>>> from an E-Field receiver and two B-Field receivers into a multi-channel<br>
>>>> stream and align timestamps of all channels.<br>
>>>><br>
>>>> I'm not an expert at C by any means, and I haven't really looked at<br>
>>>> understanding the stream format in the source code yet. For a conversion<br>
>>>> utility, would the stream have to be copied and phase-shifted to<br>
>> generate<br>
>>>> IQ data?<br>
>>>><br>
>>>> vlfrx-tools captures and works with data in its original form. From the<br>
>>>> soundcard, it's a pcm audio stream. There are utilities vtrtlsdr and<br>
>>>> vtsdriq that read data from a RTL dongle or SDR-IQ receiver<br>
>> respectively.<br>
>>>> vtsdriq can output either I and Q data in two channels or a single<br>
>> channel<br>
>>>> stream.<br>
>>>><br>
>>>> Jonathan<br>
>>>> KC3EEY<br>
>>>><br>
>>>> On Thu, 11 Mar 2021, Phil Erickson wrote:<br>
>>>><br>
>>>>> Date: Thu, 11 Mar 2021 04:33:08 -0500<br>
>>>>> From: Phil Erickson <<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a>><br>
>>>>> To: TAPR TangerineSDR Modular Software Defined Radio<br>
>>>>>     <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
>>>>> Cc: Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">emuman100@gmail.com</a>><br>
>>>>> Subject: Re: [TangerineSDR] VLF-RX tools<br>
>>>>><br>
>>>>> Hi Jonathan,<br>
>>>>><br>
>>>>>  I looked at the documentation (HTML page) but I cannot find a precise<br>
>>>>> definition of the stream format.  Where is that located or could you<br>
>>>>> summarize that?  It would then be possible for those of us familiar<br>
>> with<br>
>>>>> DigitalRF, and in particular the Haystack team who maintains it, to<br>
>>>> examine<br>
>>>>> the ways in which a .vt file could be translated to DigitalRF or the<br>
>>>> other<br>
>>>>> way around.<br>
>>>>><br>
>>>>> 73<br>
>>>>> Phil W1PJE<br>
>>>>><br>
>>>>> On Wed, Mar 10, 2021 at 10:46 PM Jonathan via TangerineSDR <<br>
>>>>> <a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<br>
>>>>><br>
>>>>>> Hi Tom,<br>
>>>>>><br>
>>>>>> Thank you for looking at the documentation for vlfrx-tools! I'll list<br>
>>>> some<br>
>>>>>> useful utilities included in vlfrx-tools to try to illustrate how<br>
>> useful<br>
>>>>>> they can be. A utility can be written to convert to DigitalRF/HDF5,<br>
>>>>>> however, vlfrx-tools does not normally generate IQ data.<br>
>>>>>><br>
>>>>>> For others on the list, the vlfrx-tools documentation is<br>
>>>>>> available at <a href="http://abelian.org/vlfrx-tools/" rel="noreferrer" target="_blank">http://abelian.org/vlfrx-tools/</a> and this also includes<br>
>> the<br>
>>>>>> source code. Also, for the others on the list, I'd like to make the<br>
>>>>>> argument that vlfrx-tools is advantageous because of its useful<br>
>> toolset<br>
>>>> in<br>
>>>>>> analysis and post-processing of both natural radio, amateur radio in<br>
>> the<br>
>>>>>> VLF band, and VLF transmitters. Such tools don't exist (to my<br>
>> knowledge)<br>
>>>>>> for formats like DigitalRF. Since vlfrx-tools is such a diverse and<br>
>>>>>> usefull toolset that already exists, it's advantageous to utilize it<br>
>> in<br>
>>>>>> post-processing on the PSWS database to make available SID events,<br>
>>>>>> whistler and chorus events, and lightning location data, just to name<br>
>> a<br>
>>>>>> few.<br>
>>>>>><br>
>>>>>> vtblank - an impulsive noise blanker that removes sferics and other<br>
>>>>>> impulsive noise from the VLF spectrum. It's useful in studying VLF<br>
>>>>>> transmitters and especially useful for VLF QSOs.<br>
>>>>>><br>
>>>>>> vtam - used to extract the magnitude of a non-stationary signal like a<br>
>>>>>> sferic. You can examine the timing of sferics, whistlers, and the<br>
>> edges<br>
>>>> of<br>
>>>>>> timing signals like WWVB.<br>
>>>>>><br>
>>>>>> vtpolar - generate a polar plot movie of a triple axis VLF stream.<br>
>> This<br>
>>>>>> allows you to see the bearing of incoming VLF signals like whistlers.<br>
>>>>>> Please watch the movie in the documentation!<br>
>>>>>><br>
>>>>>> vtsid - automatically  detects sudden ionospheric disturbances with<br>
>> VLF<br>
>>>>>> transmitters like NAA. It generates a plot and a data file. The<br>
>>>> extraction<br>
>>>>>> utility can extract records from that data file.<br>
>>>>>><br>
>>>>>> vtevent - automatically detects whistlers and chorus and generates a<br>
>>>>>> spectrogram plot, data file, and audio file of the event.<br>
>>>>>><br>
>>>>>> vttoga - creates time of group arrival data from sferics the incoming<br>
>>>> VLF<br>
>>>>>> stream or a file.<br>
>>>>>><br>
>>>>>> vtspot - used to generate lightning location data from vttoga data<br>
>> from<br>
>>>>>> VLF receivers around the world. The PSWS database can provide<br>
>> lightning<br>
>>>>>> location data using a network of receivers.<br>
>>>>>><br>
>>>>>> vtping - used to detect meteor ping.<br>
>>>>>><br>
>>>>>> vtwrite - writes a VLF stream, either from a ring buffer or network<br>
>>>>>> socket, to file for storage.<br>
>>>>>><br>
>>>>>> vtread - reads a .vt file into a ring buffer or network socket.<br>
>>>>>><br>
>>>>>> vtraw - extract raw audio froma VLF stream. This also removes the<br>
>>>>>> timestamping.<br>
>>>>>><br>
>>>>>> vtwavex - extract a wav file from a VLF stream. This also removes the<br>
>>>>>> timestamping.<br>
>>>>>><br>
>>>>>> These are just some examples of useful utilities of vlfrx-tools. A<br>
>>>> utility<br>
>>>>>> to convert a .vt file to DigitalRF/HDF5 can be written (however, I<br>
>>>> cannot<br>
>>>>>> support that). Also, vlfrx-tools does not generate IQ data normally.<br>
>>>> But,<br>
>>>>>> with such a toolset, so much can done. I would hope this convinces<br>
>> some<br>
>>>> of<br>
>>>>>> those who may be skeptical. In any case, I urge you to look at the<br>
>>>>>> documentation.<br>
>>>>>><br>
>>>>>> Jonathan<br>
>>>>>> KC3EEY<br>
>>>>>><br>
>>>>>> On Wed, 10 Mar 2021, Tom McDermott via TangerineSDR wrote:<br>
>>>>>><br>
>>>>>>> Date: Wed, 10 Mar 2021 12:07:26 -0800<br>
>>>>>>> From: Tom McDermott via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
>>>>>>> To: TAPR TangerineSDR Modular Software Defined Radio<br>
>>>>>>>     <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
>>>>>>> Cc: Tom McDermott <<a href="mailto:tom.n5eg@gmail.com" target="_blank">tom.n5eg@gmail.com</a>><br>
>>>>>>> Subject: [TangerineSDR] VLF-RX tools<br>
>>>>>>><br>
>>>>>>> Hi,  I don't have Jonathan Rizzo's direct email, so sending this to<br>
>> the<br>
>>>>>>> list.<br>
>>>>>>><br>
>>>>>>> We talked a bit about the VLF receiver on the last conference call,<br>
>> and<br>
>>>>>> the<br>
>>>>>>> VLFRX tools.<br>
>>>>>>> I'd like to email with Jonathan directly.   It appears those tools<br>
>> have<br>
>>>>>> the<br>
>>>>>>> ability to<br>
>>>>>>> read from a file (and thus in Linux from a named pipe).  Gnuradio can<br>
>>>>>> write<br>
>>>>>>> to a named pipe<br>
>>>>>>> as well to DigitalRF (HDF5).   Perhaps this may provide a mechanism<br>
>> to<br>
>>>>>>> hook the receiver both to the Tangerine archiving method as well as<br>
>> to<br>
>>>>>>> VLFRX.?<br>
>>>>>>><br>
>>>>>>> -- Tom, N5EG<br>
>>>>>>> <a href="mailto:n5eg@tapr.org" target="_blank">n5eg@tapr.org</a><br>
>>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> TangerineSDR mailing list<br>
>>>>>> <a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
>>>>>> <a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> ----<br>
>>>>> Phil Erickson<br>
>>>>> <a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br>
>>>>><br>
>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> ----<br>
>>> Phil Erickson<br>
>>> <a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br>
>>><br>
>><br>
><br>
><br>
> -- <br>
> ----<br>
> Phil Erickson<br>
> <a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br>
><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">----<br>Phil Erickson<br><a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br></div>