New hamsci.org Grape PSWS Pages

[Gary Mikitin, AF8A]

If you or anyone you know is interested in the Grape Personal Weather Station (PSWS), new project web pages are available:  Begin at hamsci.org/grape. 

Included are details on building the Grape 1 (version 1.12) and some pre-release information on the three-channel Grape 2.  Most significant is the survey for those interested in hosting a Grape 2 (hamsci.org/grape2).  (We have about 20 people who've already expressed interest in the Grape 2 - no need to re-enter your information on the survey, though if you do so, we'll figure it out.)

The Grape 1.11 (the 'original grape') has its own archival page (hamsci.org/grape111-archive).

73 de Gary, AF8A

[Gary Mikitin, AF8A]

Greetings, Grape Enthusiasts - I thought it worthwhile to update my posting of 16 May.

The multi-frequency Grape 2 is a bigger development project than anticipated, so it is unlikely to be available for the Oct 2023 North American Solar Eclipse.  Not to worry:  The venerable single frequency Grape 1.12 is riding to the rescue (hamsci.org/grape1).  I have comments for two audiences:

If you are currently hosting a Grape 1:

Chances are that the Raspberry Pi is running fldigi software.  That's great - please keep that Grape active.  There are research projects underway (solar flare studies) which are planning to use that data.  So please don't unplug it!

Please consider adding a second Grape 1, but with different software, which will log data in the Digital RF format (DRF).  You'll need another Grape 'receiver' circuit board, another Raspberry Pi, but you can use your Leo Bodnar GPSDO to drive both Grapes, lowering  the system cost considerable.  You'll need an SMA Y-cable (or something similar) to split the Bodnar signal between two Grapes.  The Bodnar has adequate drive capacity (in theory, it could drive 3 or 4 Grapes).

The DRF Pi image isn't available for distribution just yet.  Even so, if you received a couple of extra blanks from Osh Park and extra parts from DigiKey or wherever, you may be able to put them to use.

The best scenario will be putting both of your Grapes on the same frequency (a given if you split one GPSDO signal into two Grapes).  In fact, HamSCI may, in the future, request all Grape usesr to use a common frequency (likely to be 5 or 10 MHz) so comparisons can be made between formats (fldigi and DRF) and across various locations.  Stay tuned for more info!

If you've not yet taken the 'Grape leap':

Now is a good time to consider doing so.   If you have already filled out the interest survey at hamsci.org/grape2 (yes, that's on the Grape 2 page) you're all set.  Chances are, we'll be in touch very soon.  If you haven't filled out the survey, please consider doing so, either before or after you build a Grape 1!

73 de Gary, AF8A

HamSCI Amateur Radio Community Coordinator

[Dave Hinerman]

Gary,

Do you know if the DRF software would run on a Raspberry Pi 2B? My Pi 4 is occupied with my current Grape1 node and new ones are hard to come by right now, but I have a 2B I can use. I have a couple more Grape 1 mixer boards built up so the computer is the bottleneck here.

Dave, WD8CIV

[Christopher Prosser]

Hi Gary,

Thanks for the update. I'm just getting my Grape 1.12 up and running, first 24 hours look good (I think).

But I have the similar question about compute device. In my case I have an Orange Pi 4B available. Will you be distributing anything other than an image given the difficulty in sourcing Raspberry Pi?

thanks, 

Chris

[Bill Owens]

Gary,

As I mentioned last week in the group, I'm working on expanding the number of frequencies I can monitor here, thinking that would be of value. Conveniently, I have a dual-port Bodnar GPSDO for that purpose, as well as two more original Grape boards and two Pis. Would it be more valuable in the current scenario for me to focus on adding DRF rather than covering more frequencies?

Thanks,

Bill N2RKL

On Friday, June 30, 2023 at 3:37:51 PM UTC-4 gmikit...@gmail.com wrote:

[Jonathan]

Dave,

Digital RF requires GNU Radio and a newer version of Debian, so no, an older Pi won't run it.

Chris,

All the Grape team has is a Pi, so that's the image they will distribute.

Bill,

The Digital RF setup for the Grape 1 will just produce the data products in another format, Digital RF data of the carrier baseband and carrier spectrograms instead of time series amplitude and frequency data in csv format. You can set up the other Grapes now on other frequencies and when the digital RF version is available, just use the new image and set it up.

All,

An alternative that may work is the Libre, which you can read about here. It won't boot a Pi image natively. I remember seeing documentation on how to convert a Pi image to boot on a Libre, but I cannot find it. You'll have to try it out as it was never done before. If it works, it'll be a great thing because they are cheap right now and available. I encourage others to try to get it working and write a guide on how to do it.

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/66d4a4c4-15aa-408c-a55a-9710ce098388n%40googlegroups.com.

[Jonathan]

Hi Graham,

More than likely not. The digital RF version could easily do that with the appropriate GNU Radio graph running on a Linux PC with soundcard and associated software to generate and upload the data products, but I don't believe that will be a mainstream option. In the interest of ensuring the software of multiple stations is working the same way and correctly, a preconfigured image is distributed.

Jonathan

KC3EEY

On Sat, Jul 1, 2023 at 10:36 AM Graham c <colonel...@gmail.com> wrote:

Will there be a version that can be run on a PC based LINUX installation  ( 32 bit )?

cheers, Graham ve3gtc

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB28injEzG%3D_1Mhs1fga_be-1UyKXxXhvFkqBCBJm2FCoQ%40mail.gmail.com.

[Graham c]

Hi Jonathan,

That is unfortunate.  I do understand the desire to make such endeavours as easily accessible as possible such as through the use of Raspberry Pi platform but unfortunately recent events has made these very difficult if not impossible to obtain for many.  I have a handful of PC boxes sitting around and currently unused but no Raspberry Pi's and what Pi's I can find are commanding high prices whereas used PC's can be had for free or for only a few $.  Unfortunately there is no one solution for all.

I would like to contribute in an easy manner but the stumbling block is the Raspberry Pi and unless I am able to beg, borrow, or steal one which for now seems unlikely. PC's I have aplenty.

cheers, Graham ve3gtc

[Jonathan]

Hi Graham,

I believe if you ask, you can obtain the modified source code for FLDigi and build and set it up yourself using a Pi as an reference on a PC, but I don't know if you'll get any support or tutorials. You'll just have to experiment on your own. For the Digital RF version, that should be easier like I mentioned above, but the same lack of support or tutorials apply. If you are willing to get it working and document it, it would be of great help to the community.

When this system was envisioned, the pandemic and global chip shortage was not even in the vernacular, so these are the challenges now. Again, development and documentation for a standard PC would be of great help to the community.

Jonathan

KC3EEY

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAJ2gCDvGpWVLpZ2fwG-1zbnQete-y-azPyY4qrxqL%3D8KvLqY2g%40mail.gmail.com.

[Dave Hinerman]

Jonathan,

I have a Libre "Le Potato" on the way. From what I've seen so far it should boot from a Raspbian micro SD card after the card image has been modified while running in a Raspberry Pi. I have a Pi 2B available, so with a little luck I'll be able to do that. If it works I'll see if I can do the same with a Grape  1 image.

I'll report back to the group when I know more.

Dave, WD8CIV

On Saturday, July 1, 2023 at 9:54:13 AM UTC-4 emum...@gmail.com wrote:

All,

An alternative that may work is the Libre, which you can read about here. It won't boot a Pi image natively. I remember seeing documentation on how to convert a Pi image to boot on a Libre, but I cannot find it. You'll have to try it out as it was never done before. If it works, it'll be a great thing because they are cheap right now and available. I encourage others to try to get it working and write a guide on how to do it.

Jonathan

KC3EEY

[Robert Tiller]

https://rpilocator.com/

will change day to day but right now, Pi 4B with 8GB RAM can be found from

https://www.pishop.ca/product/raspberry-pi-4-model-b-8gb/

Robert

AE5YG

[Gary Mikitin, AF8A]

Bill - There will definitely be value in host location such as yours running two Grapes, monitoring the same frequency, one running fldigi and the other, Digital RF.  That will allow the science community to compare the output of both modes over time, with many stations uploading the two formats.  The expectation will be that both data formats produce similar results, identifying the same phenomena - but you never know until it is verified across large data sets.

As for monitoring other frequencies, I'm sure there are interesting things to be learned, but that's a better question for the science community.  Let's see who comments.

73,

Gary

[Bill Owens]

Gary,

I haven't been following the details of the project very well - work keeps me from attending the Thursday morning Zoom calls, and not much of the discussion seems to filter through to this list - so I don't know what setup is required for DigitalRF. But if it can share the GPSDO then I'm assuming it is still using the 1 kHz offset, and without modifying the second Grape board I would expect to see the same audio signal output (more or less, depending on component values for the level). Is there a reason why a single Grape audio output can't drive two Pi, one with fldigi and one with gnu radio?

And assuming two Pi are needed for CPU reasons, could the fldigi instance run on an older 3B board? I was doing that for a while and it seemed to be fine. I have one of those idle and can lay my hands on another pretty easily.

Thanks,

Bill N2RKL

[Jonathan]

Bill,

The driver on the Grape 1 mixer board may not drive more than one soundcard input without significant loss in level. You may be able to run it through a line level distribution amplifier, but that is not tested, so if you'd like to do it, please report your results if you do.

A 3B should be fine, but the supplied image is for a 4, so that may or may not work. You'll have to test that too. Two Pi's are required because one will run fldigi and the other GNU radio. The audio input can't be shared to both programs.

The only thing that will be required for Digital RF would be to use the Digital RF image on your Pi. Instead of running fldigi, it runs GNU Radio instead to generate carrier baseband signals in Digital RF format. That is the only difference.

Jonathan 

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/d5c70025-467e-4279-9bfc-af659a8d1c72n%40googlegroups.com.

[Bill Owens]

Jonathan,

That's fair, I will give it a try once there's an image for the GNU Radio setup, or any notes about how to do it. I assume JACK has too much latency to do the audio split within the system?

In any case I ordered boards and parts for a trio of new Grapes, so I should have enough boards no matter how it works out. I haven't had any luck troubleshooting my third original Grape and I'd like to be able to try 20 MHz WWV, so having the new boards will be good.

Thanks,

Bill N2RKL

[Jonathan]

Bill,

The audio is not timestamped, so there is already some latency, so I’m not sure if the latency by Jack will really make that much of a difference. In my VLF system, tens of nanosecond accuracy is required, but for the Grape 1, microsecond accuracy might be sufficient. I’m not really sure because I never investigated this in the past and neither did anyone else. So, the only way to know is to do another experiment and compare your Jack-induced latency data with others. 

Gary,

Did Nathaniel or someone else say they wanted to both fldigi and Digital RF deployments to compare? The Digital RF setup will produce the same data as the fldigi version, just in Digital RF format. The modified fldigi version John wrote adds the metadata to the data files and some other small stuff, but Digital RF has built in programmable metadata. Software that Bill wrote generates spectrograms as well as Grape 1-style time domain amplitude and frequency data from Digital RF data. 

Jonathan 

KC3EEY 

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/5f48fd0a-cb77-416f-944f-ccf5faf04774n%40googlegroups.com.

[John Gibbons]

nsec latency on audio - surely you're joking.

 

You'll be luck to get 10's of uSec on an audio stream thru an OS.  And timestamps will only make it worse.

John

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB0LWg34cMSEkxq_Q_2q9KRW%3DoPUFH1O1oM%3D%2BpQQKur_iQ%40mail.gmail.com.

[Jonathan]

John,

vlfrx-tools has the capability to utilise a PPS pulse on one audio channel. It finds whatever pulse edge you set it to use and then resamples the audio stream aligned to the PPS as well as realigns timestamps to the PPS. You can also set a calibration offset to make it even more accurate. This is useful when timing sferics, VLF amateur transmissions, and VLF transmitter absolute phase measurements.

I'm not sure how much error is introduced into the Grape data products by adding another source of latency, like with Jack, because much of the data is averaged.

Jonathan

KC3EEY

[John Gibbons]

Jonathan,

Have you done any timing accuracy testing to verify you're getting what you're expecting?  

John

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB1uuT96nd%3DYHW4Sm4L2uQrWG44W7vnzkq8X4_UC2HsMEw%40mail.gmail.com.

[John Gibbons]

Bill,

The Grape 1.12 board will not receive WWV 20MHz - the input resonant filter will kill the signal completely (by design)

Your options are just 2.5, 5.0, 10.0 and 15.0 MHz for WWV

John N8OBJ

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/5f48fd0a-cb77-416f-944f-ccf5faf04774n%40googlegroups.com.

[Bill Owens]

Well, that shows my inexperience with analog filters :) I had looked at the schematic, and without really understanding what kind of filter you were building, observed that the inductance gets lower as the frequency gets higher - that seemed to make some kind of sense - and figured that paralleling the inductances would move the filter higher still. I don't know what equation to use to calculate the effect, but it seemed that paralleling the inductors on one of my existing original Grape boards improved performance on 15 MHz, so I figured that with the 15 MHz option on the new board plus the others in parallel, I might be able to make it work on 20. I think the resulting inductance would be around 285-290 nH?

Or I suppose I could do the smart thing and actually ask you how the filter was designed, so I could take one of the unused spots and substitute the right inductors to just have it work at 20...

Thanks,

Bill N2RKL

[Gary Mikitin, AF8A]

All - Some interesting developments have come to light regarding a 'Dual Grape System', many from discussions here in this thread, which have proven to be quite interesting.  It is good to see the community is willing to contribute thoughts, solutions and the occasional 'What if...' , which keeps things moving forward.  The Thursday morning Grape Zoom discussions help pull all of that together.  Please consider joining the calls or watching the recordings on YouTube (search on Grape Low-Cost Personal Space Weather Station).

Attached is a diagram for those who currently have a functioning Grape 1, running the standard fldigi image, and whose node is uploading data to the WWVARC-provided FTP site.  The assumption is that you have, in place, an antenna, GPSDO, R Pi, power supply(s), cabling, a node number, Web connection, etc.  That's shown, with minimal detail, in green (the upper half of the digram).

Below, in gray, is a suggested method for 'doubling'  your system, for creating/uploading data in the Digital RF Format.  The big news is that your existing Grape should be able to drive two audio adapters/Raspberry Pi's - your current Pi and one added (a 4B with 4GB (or better) memory to run GNU radio and generate DRF data).

Not shown are the details on building or obtaining a GNU radio SD card image, second node number, connection to the U of A server, etc. for the second Pi.  Those details are being worked out.

A few of you have created your own GNU Radio images. It would be FANTASTIC if you could attempt this configuration and report your results here.  Again, this should work (in theory) but the proof is in the running.

73 de Gary, AF8A

[Jonathan]

Hi John,

I didn't have a chance to measure it before I installed the system, but from looking at sferics, timestamp accuracy is in the 100s of nanoseconds and is determined by the quality of the GPS PPS. By determining a calibration offset and measuring receiver group delay, I can get that to below 100ns. I'm currently working on a calibration method.

Jonathan

KC3EEY

[John Gibbons]

Jonathan,

Is the A./D clock running off of the GPSDO freq or is it free-running?

John N8OBJ

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB3Cxt1kpxRbgvDT7RQEdJdSkva2xkLVL6%3DoyNvz3znUFA%40mail.gmail.com.

[Jonathan]

Hi Kristina,

I understand now. That clears everything up. I believe Bill was creating some Python tools to generate the same frequency and amplitude data products as fldigi creates from Digital RF data from data.

Hi John,

The soundcard's clock is free-running, but the crystal is kept at a fairly stable temperature. How is works is pretty clever. Data is read from the soundcard and the sample rate is continuously monitored and compared to the system clock. The data is then timestamped against the system clock (must be disciplined by ntpd) and corrected by a latency factor reported by the soundcard driver. As long as the soundcard clock is kept stable (and therefore sample rate), the loop can always make these corrections. 

From there, the pulse property of the PPS (I use rising edge) is detected using FFT. It looks at where it detected the rising edge and compares it to the system clock. From there, it calculates a correction offset that is resamples to, so the samples are aligned to the PPS and adjusts the timestamps as well to align with the aligned samples. With a stable soundcard clock and GPS PPS, these corrections are always made, keeping the samples and timestamps aligned to the GPS PPS. 

Jonathan

KC3EEY 

[John Gibbons]

Jonathon,

Sounds like it's headed in the right direction but I would strongly suggest that you devise an experiment to test and verify it really works.

It comes down to are these "marketing specs" or "engineering specs".  Usually decades apart (after you read the fine print).

Without dedicated hardware for timing control (i.e. no software involved) I've never seen the timing accuracy and precision your system is claiming it does.

100 nSec timing is difficult in any system.  And a PID loop in the middle of it is a major red flag.

As President Regan used to say "Trust but verify"...

John N8OBJ

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB0-z8Qd%2B-hbqPRfZj2R4es3tMctV323sdq0Zo%3D1T7HLYw%40mail.gmail.com.

[John K]

Gentleman,

GPS disciplined receivers designed for the DIY enthusiast that target 'beacon' frequencies such as WWV and CHU to measure Doppler-effect of the ionosphere caused by the Sun

Receiver1 ... https://hamsci.org/grape1
Receiver2... K4BSE_Grape 1.12 Document v1-2.pdf

! !  With exception of GPSDO note the similarity to kits already in my shack

Receiver3... Neophyte QST Feb1988 pg16
Receiver4... SWLabs RockMite
Receiver5... SWLabs Phaser 
Receiver6...TEN-TEC 1056 (not just frontend but 'other' simular circuits to Grape1 and Grape 1.12

I am also tooling up for these events
my fldigi input is 1000 Hertz (audio on a win10) and writes csv to a data file at one second intervals to be analyzed at a later time

 ... So I must ask...

...Why all this concern about " sub-second timing accuracy" ?

Sincerely
John
N3AAZ

[John Gibbons]

John,

The Grape1 measures the WWV carrier to within 0.001 Hz (1 mHz) looking for doppler shift due to ionospheric TID's and other 

phenomenon causing frequency shifts.

BUT the sampling time is controlled by the RasPi OS and the free running A/D 'clock' (usually a resonator and not even a crystal)

in the USB sound card so it's absolute 1PPS accuracy is in the 100's of uSec at best - much more likely worse than that.  

Grape 2 will be using a GPSDO for the system and A/D clocks and will also have the 1 mHz resolution for both freq and timing.  

Actual sampling will have a 125-250 nSec offset from the absolute 1PPS, but that's as good as the logic can get with synchronizing 

between 2 asynchronous time domains (1PPS and GPSDO - even though the GPSDO is derived from the 1PPS signal, the 

PLL division rate is not an nice integer and as such they walk wrt to each other in time - unless you play some 

fancy games in the setup of the UBLOX GPSDO receiver).

Having done this for many years, the numbers being thrown around raise some red flags and unless you can demonstrate (via

a test setup) that you are meeting these numbers more often than not they are not even close to what you are expecting. 

Measurement science in Academia in way too idealized (textbook) and based on assumptions that are usually violated by the actual setup

causing unexpected timing problems.  Been here waaaaaay too many times to ignore this famaliar fingerprint...

Bottom line is "OK - prove me wrong..." and I will gladly admit defeat if proven so; but I have not had to admit it yet in 40+ years...

John N8OBJ

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/0a8cfee6-2105-4d79-b1a1-37e5ff17c185n%40googlegroups.com.

[John K]

Hi John n8obj es tnx

"""Bottom line is "OK - prove me wrong..." and I will gladly admit defeat if proven so; but I have not had to admit it yet in 40+ years...John N8OBJ"""

John I am not trying to prove anything
Got a few years under my belt too (retired 1997 EE)

I am trying to understand the tight specks on your timing system and why my win10 running fldigi in either Analyzer   and/or  FM  (Frequency Measure) mode may be an issue

Certainly the frontend of my receiver and filters (RF and AF) are equal to or better than Grape1
My  GPSDO/LO  (local  oscillator) may be an issue and reason for this dialog

TNX AGN
John
N3AAZ

[John Gibbons]

John,

I apologize - that was NOT directed at you (but looking back at it it does - my bad)...   remove foot from mouth... sigh...

If you are using a LB GPSDO or equivalent then your freq ref should meet the 10^-11 error window we need

for the Grape 1 doppler shift measurements.

And your receiver has MUCH better filters but it comes at a timing cost - especially if they are DSP based

(almost all new receivers are).

See attached testing I did per this topic

John N8OBJ

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/8550f69d-859e-4169-ad7b-99da2025b7b8n%40googlegroups.com.

[John Gibbons]

Bill,

20 MHz is not being used for the research effort at this time -  and having just 1 node doing that, while interesting, doesn't really help the effort.

The data base also won't know what to do with it as well.  Probably not worth pursuing at this point in time.  Sorry.

John N8OBJ

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/bff8ceea-c489-485f-a9bd-00f18d8108a6n%40googlegroups.com.

[Jonathan]

John K,

This discussion is not related to the Grape system but pertains to a VLF system that I am currently running. John was referring to me, so I apologize for the confusion. Eventually, I plan on making it a partial kit with documentation like the Grape to build up a network of VLF receivers that people can construct and install in their rural backyards. Precision timing is required for many applications in VLF, including lightning location, absolute phase measurements of VLF transmitters, multichannel correlation, correlation between VLF receivers at different locations, and VLF amateur transmission and reception of both carrier integration and the EbNaut coherent BPSK mode. 

John,

The key to the timing precision is the loops that both vtcard (the application that reads from the soundcard) and vttime (the application that detects the PPS and resamples according to PPS alignment and aligns timestamps) run, both in the initial setup state and then a running state. In the setup state, vtcard determines the sample rate drift and latency and uses these as calibration parameters, but ntpd must be running to continuously steer the system clock. If there is too much drift in the system clock, vtcard cannot leave the setup state. If there is too much variation in the sound card clock due to rapid temperature variations, it falls back into a setup state from a run state to obtain calibration over again and will go into a run state once the clock is stable. Here is a sample output from vtcard's log. The "offs" is the is the variation between the soundcard's clock and system clock:

2023/07/12 15:47:26 run -5.944e-08 sr 96003.692 tadj -5.080e-09 rr 96003.7 offs -0.001mS r=0.00
2023/07/12 15:47:36 run -7.857e-06 sr 96003.654 tadj -6.715e-07 rr 96002.9 offs -0.079mS r=0.03
2023/07/12 15:47:46 run +2.364e-07 sr 96003.655 tadj +2.020e-08 rr 96003.7 offs +0.002mS r=0.00
2023/07/12 15:47:56 run +7.825e-06 sr 96003.693 tadj +6.688e-07 rr 96004.4 offs +0.078mS r=0.03
2023/07/12 15:48:06 run -7.567e-06 sr 96003.657 tadj -6.524e-07 rr 96003.0 offs -0.076mS r=0.02
2023/07/12 15:48:16 run +2.312e-06 sr 96003.668 tadj +1.976e-07 rr 96003.9 offs +0.023mS r=0.01
2023/07/12 15:48:26 run -3.040e-07 sr 96003.666 tadj -2.598e-08 rr 96003.6 offs -0.003mS r=0.00
2023/07/12 15:48:36 run +5.912e-06 sr 96003.695 tadj +5.052e-07 rr 96004.2 offs +0.059mS r=0.02
2023/07/12 15:48:46 run -1.084e-06 sr 96003.689 tadj -9.268e-08 rr 96003.6 offs -0.011mS r=0.00
2023/07/12 15:48:56 run -2.930e-06 sr 96003.675 tadj -2.504e-07 rr 96003.4 offs -0.029mS r=0.01

This offset is measured and used as calibration information. This performance can be plotted over time. Here is a plot of the sample rate variation and the offset. You can see, the trend in sample rate variation roughly follows temperature in Nathaniel's shack:

Next, the stream is fed into vttime. In the setup state, it looks for the rising edge of the PPS and takes some calibration measurements. Here is the log output:

2023/07/12 16:11:23 st2 PPSpmr 65.9 PPSmad 1.422uS in 2.965158mS out  -0.002uS rate_err  0.001 inrate 96003.6801 int 96003.7718 tc 0.000
2023/07/12 16:11:24 st2 PPSpmr 62.3 PPSmad 1.435uS in 2.960555mS out  -0.005uS rate_err -0.000 inrate 96003.6798 int 96003.5832 tc 0.001
2023/07/12 16:11:25 st2 PPSpmr 65.0 PPSmad 1.414uS in 2.955984mS out  -0.013uS rate_err -0.001 inrate 96003.6792 int 96003.6376 tc 0.001
2023/07/12 16:11:26 st2 PPSpmr 66.1 PPSmad 1.421uS in 2.951257mS out  -0.006uS rate_err  0.001 inrate 96003.6798 int 96003.8032 tc 0.001
2023/07/12 16:11:27 st2 PPSpmr 62.6 PPSmad 1.424uS in 2.946953mS out  -0.003uS rate_err  0.000 inrate 96003.6800 int 96003.6564 tc 0.000
2023/07/12 16:11:28 st2 PPSpmr 65.2 PPSmad 1.408uS in 2.946224mS out  -0.010uS rate_err -0.001 inrate 96003.6794 int 96003.5824 tc 0.001
2023/07/12 16:11:29 st2 PPSpmr 67.1 PPSmad 1.400uS in 2.946736mS out  -0.016uS rate_err -0.000 inrate 96003.6789 int 96003.6878 tc 0.001
2023/07/12 16:11:30 st2 PPSpmr 63.5 PPSmad 1.387uS in 2.947304mS out  -0.028uS rate_err -0.001 inrate 96003.6779 int 96003.6066 tc 0.003
2023/07/12 16:11:31 st2 PPSpmr 64.0 PPSmad 1.406uS in 2.947634mS out  -0.024uS rate_err  0.000 inrate 96003.6783 int 96003.8145 tc 0.002
2023/07/12 16:11:32 st2 PPSpmr 66.5 PPSmad 1.398uS in 2.948002mS out  -0.018uS rate_err  0.001 inrate 96003.6789 int 96003.7080 tc 0.002

In the log you see "in 2.965158mS out  -0.002uS" showing both the PPS offset (in) and the sample realigned offset (out). It also continuously measures the PPS mad, or the mean absolute distribution. This shows the distribution of the PPS falling within a sample window and the variation is due to the sample rate variation. You can plot this performance against sample rate variation:

You can see the variation of sample rate roughly follows the temperature of Nathaniel's shack again but this plot indicates performance before correction. After correction, timestamp accuracy is within hundreds of ns of the PPS edge but it varies within that range due to continuous correction. 

The following is a stacked spectrogram of a VLF receiver using a GPS PPS located in Forest, VA (top) and my VLF receiver in Pennsylvania showing dawn chorus emissions with timestamps aligned. Without the PPS alignment performed by vttime, it would not be aligned like it is:

Another good test is with sferics. Here is a sferic from a lighting stroke that occurred in Puerto Rico that generated a red sprite. On the top is the same VLF receiver in Forrest, VA and on the bottom is mine:

You can see both receivers detected the same sferic and the dominant difference in timing is the propagation delay between both locations. The error is the timestamping error in both mine and the receiver in Forrest, VA, but that is still within hundreds of ns.

Lastly, VLF amateurs use GPS-locked carriers and GPS-locked coherent BPSK to send either an unmodulated carrier or a message via the EbNaut mode. In VLF, due to practical antenna sizes, microwatts of power are generated at the antenna at most. For carrier detection (QSO of the transmitting carrier at the other location), the signal has to be integrated over a period of an hour or more. Without a GPS-locked carrier and timestamping precision at the receiving end, the peak of the carrier would never be detected in the integration. Here is a QSO made with my VLF receiver with a VLF amateur DL3JMM at 8270.03Hz, showing the coherent narrowband power spectrum integration:

Following this transmission, he made a sequence of transmissions with EbNaut modulation. Here is an integration of the power spectrum of one of his transmissions:

On the transmitter end, three loops are used to synchronize the carrier frequency with GPS PSS using the same Audio Injector Stereo soundcard, also with its clock free-running, but using the same continuous correction. Without this correction to maintain accuracy both on the transmitting and receiving end, my power spectrum integrations would have shown noise.

This is all made possible by the open-source vlfrx-tools software toolkit. It contains over 30 utilities for full signal processing, from capture to analysis, including vtcard and vttime. The above are a few examples of its capability. The author wrote it in his free time (not retired) and created everything from scratch without any external funding. He spent quite a bit of time on attaining timestamping accuracy to make everything work and spent over 20 years in the study of VLF and using off-the-shelf hardware for data acquisition. You can read about it here, including the soundcard and timing sections. He is also the creator of the VLF amateur EbNaut digital mode and wrote all the software and tools for it, including EbSynth that uses a GPS PPS and soundcard to generate a carrier or a carrier with EbNaut modulation. 

Using the author's sferic processing tools, he helped build the Indian Lightning Detection Network, a collaboration between many Indian universities, using the same capture and timing method with vtcard and vttime. It uses a network of VLF receivers and base stations (same Audio Injector soundcard and uBlox GPS) to generate geographical lightning stroke solutions with very good accuracy. He built the VLF receiver kit as well as the aggregation server with the database that stores the sferic's TOGA and geographical solution from multiple receivers. Students went out and installed the receivers at various locations, and the network produces stroke solutions daily. I invite you to take a look at not only the maps, but the about and status sections as it is quite impressive and very cool.

vlfrx-tools would be an alternative to fldigi, too, in the Grape application. Using a good I2S soundcard, a GPSDO that outputs both a reference and PPS, vlfrx-tools can capture timestamped carrier data and generate both carrier spectrograms as well as plots and numerical data of frequency and amplitude. The only thing is, scripts would need to be written to put in the metadata and perform the uploading. It does not have a waterfall display utility, but Spectrum Lab can connect to its stream and generate one. Plus, everything would have accurate timestamps as well, but it's not as critical in the Grape application.

Jonathan

KC3EEY

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAGzvW%3Dy%3DoPjz3e9%3Dq4pO1Rfx8D1daT1bAYR1Mvbxq34jFpwy4w%40mail.gmail.com.

[Jonathan]

John, 

One thing I forgot to mention related to your test results is group delay calibration of the VLF system components. A GPSDO is used to generate calibration tones and is fed to a driver and small antenna and placed near the VLF receiver antenna. Once the calibration is performed, the group delay measurement is calculated and put in as an offset into vttime to remove the group delay incurred with the VLF receiver, feedline, and interface to the soundcard, further increasing the timestamp accuracy. I'm currently working on building a VLF system calibrator.

Jonathan

KC3EEY

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAGzvW%3DzAx%2BywmNo-723%2BKYB0VitotTiJs3LRC4Ob6A4e5KBHSA%40mail.gmail.com.

[John K]

""John K, This discussion is not related to the Grape system but pertains to a VLF system  .... Jonathan kc3eey"""

Thanks
73 es dit dit
John K
N3AAZ

[John Gibbons]

Jonathan,

So if I'm understanding the graphical data (in vttime.log) you are seeing an offset from the 1PPS of 1000 nSec +/- 500 nSec (roughly.)

That is quite impressive for being a software loop and has the variability a lot tighter than I expected.  WOW!  NICE!

And the need for the tight timing is for distance calculation and/or phase measurements? 

I presume this is being done at the freq of 8270 Hz.

So a thumbnail calculation - in order  to resolve 1 deg of phase movement you would need to maintain a [1 / 8270] / 360 = ~ 336 nSec absolute accuracy from 1PPS.

So from your numbers (500 / 336)  you'd expect about a +/- 1.5 degree phase msmt error due to system timing constraints.

Or a distance msmt systematic error of about (3 ^8) * 336 nSec or ~ 100 Meters.  Not shabby!

Am I completely off base here or am I at least headed in the right direction?

John  N8OBJ

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB0peV2rO_1%3D9v%2Bpvn2Vg9E0CR4cEjq6xVGH_LMib2B6cw%40mail.gmail.com.

[Bill Owens]

John,

I naively assumed that since the software supported WWV20 and WWV25 there was interest in having nodes on those frequencies as well, but if that's not the case I won't pursue it. 

With my current indoor antenna setup I can receive 10 and 15 MHz reasonably well; 5 and 2.5 are probably out of reach unless I relocate the station and move to an outdoor antenna (or antennas). I'm just 240 km almost due south from CHU so probably not going to see anything interesting there.

I'll work on getting the 15 MHz station fully checked out and submitting data, and then wait until someone is ready to talk about GNU radio and Digital RF.

Thanks,

Bill N2RKL

[Jonathan]

John,

Yes, that's pretty much what it is, but averaged. It indicates jitter performance. For example:

2023/07/12 16:11:23 st2 PPSpmr 65.9 PPSmad 1.422uS in 2.965158mS out  -0.002uS rate_err  0.001 inrate 96003.6801 int 96003.7718 tc 0.000

2023/07/12 16:11:24 st2 PPSpmr 62.3 PPSmad 1.435uS in 2.960555mS out  -0.005uS rate_err -0.000 inrate 96003.6798 int 96003.5832 tc 0.001
2023/07/12 16:11:25 st2 PPSpmr 65.0 PPSmad 1.414uS in 2.955984mS out  -0.013uS rate_err -0.001 inrate 96003.6792 int 96003.6376 tc 0.001
2023/07/12 16:11:26 st2 PPSpmr 66.1 PPSmad 1.421uS in 2.951257mS out  -0.006uS rate_err  0.001 inrate 96003.6798 int 96003.8032 tc 0.001
2023/07/12 16:11:27 st2 PPSpmr 62.6 PPSmad 1.424uS in 2.946953mS out  -0.003uS rate_err  0.000 inrate 96003.6800 int 96003.6564 tc 0.000
2023/07/12 16:11:28 st2 PPSpmr 65.2 PPSmad 1.408uS in 2.946224mS out  -0.010uS rate_err -0.001 inrate 96003.6794 int 96003.5824 tc 0.001
2023/07/12 16:11:29 st2 PPSpmr 67.1 PPSmad 1.400uS in 2.946736mS out  -0.016uS rate_err -0.000 inrate 96003.6789 int 96003.6878 tc 0.001
2023/07/12 16:11:30 st2 PPSpmr 63.5 PPSmad 1.387uS in 2.947304mS out  -0.028uS rate_err -0.001 inrate 96003.6779 int 96003.6066 tc 0.003
2023/07/12 16:11:31 st2 PPSpmr 64.0 PPSmad 1.406uS in 2.947634mS out  -0.024uS rate_err  0.000 inrate 96003.6783 int 96003.8145 tc 0.002
2023/07/12 16:11:32 st2 PPSpmr 66.5 PPSmad 1.398uS in 2.948002mS out  -0.018uS rate_err  0.001 inrate 96003.6789 int 96003.7080 tc 0.002

On the first line, "int" indicates the number of soundcard samples (96003.7718) between the last PPS and the current pulse. You can see it varies ~0.3 sample periods in the consecutive pulses. Since the sample rate is 96k, each sample period is 10us. This means the jitter is 3.125us. The jitter is averaged and absolute value is taken and this is the PPSmad value. "inrate" is the smoothed sample interval between PPS. "in" indicates the difference between GPS time and the soundcard's timestamps and that is determined by the soundcard's read buffer latency and the delay introduced to the system clock by ntp. Here, this delay is about 3ms. The primary reason why it's so low is because I have the GPS PPS connected to a GPIO pin and gpsd/ntpd uses the GPIO pin as a PPS source to discipline ntpd.

The following is an example from the author of vlfrx-tools using his Behringer UMC404HD USB audio interface on his system. Here is the vttime log output and his description of some of the important fields:

Below he describes the output including PPSmad and the “in” field:

The Behringer 404 is running at a nominal 192k samples/sec

and is averaging here about 191964.5874/sec.

vtime is counting the number of soundcard samples from one

PPS pulse to the next.  These intervals are the 'int' field.

You can see that it bounces around a bit at the 2nd decimal

place, a jitter of about 0.01 sample periods which corresponds

to about 50 nanoseconds.

These small differences between consecutive PPS intervals are

averaged to give a 'mean absolute difference', the absolute

meaning that we don't care if it's plus or minus, just the

magnitude is relevant.  So that becomes the 'PPSmad' field.

Smoothing the intervals gives us the mean soundcard sample rate,

that is the 'inrate' field.

The 'PPMpmr' is the peak=to-mean ratio of the PPS channel,

a kind of signa/noise ratio.  A rectangular 10uS pulse of

unit amplitude would have a pmr of 100k, but we are seeing it

after the sound card's electronic and digitial filtering and

after ground and system noise is added.

The other numeric fields aren't all that useful and can be

ignored.

Exception might be the 'in' field.  vttime gets its input

from vtcard and vtcard has assigned a rough timestamp to

each sample by reference to the system clock.  The 'in'

field reports how far ahead of GPS time the vtcard timing

is sitting.    Here about 22mS but it varies on a timescale

of minutes and longer. The number is a combination of soundcard

read buffer latency and the accuracy by which the system clock

on the PC is maintained by ntpd or whatever you're using to do

that job.

You can see his jitter is ~50ns and that is because the clock in the Behringer UMC404HD is much better. The high inrate of ~22ms is primarily due to the increased latency of USB audio and that his ntpd is probably not disciplined by GPS PPS. Still, the correction is made despite the latency because it's continuously measured and calibrated out in his software. This is why his work is such a breakthrough, because it allows even average soundcards (the Audio Injector Stereo soundcard that I use is a higher end Pi soundcard, but nothing too special compared to others) and the use of a GPS to provide such great timing performance. It reduces cost of hardware and allows greater accessibility to VLF study and other non-VLF applications as well. 

Yes, tight timing is required for sferic distance measurements, absolute phase measurements, and many other applications, like correlation between other receivers. One example is that in that initial transmission of DL3JMM's amateur transmission was the use of stacking both spectrum data from my VLF receiver and the one in Forrest, VA to achieve a message decode. This is another application where accurate timing comes into play. Without it, the message would not have been able to be decoded.

Both your calculations for phase resolution and distance resolution are correct! The phase resolution plays a huge role in decoding EbNaut messages. Distance resolution gives accurate geographical stroke solutions.

Jonathan

KC3EEY

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/a244d906-dbea-4654-9309-169b46708c85n%40googlegroups.com.

[Dave Hinerman]

I received a Le Potato board earlier this month. I was able to convert the Grape 1 OS image to run on it but fldigi does not function properly. It halts and restarts unexpectedly, sometimes doesn't fill in its window completely, and doesn't permit changes in its configuration. It's possible to open the config dialog but it didn't allow changes to any field. At other times I had to issue a kill command to halt it because it wouldn't respond to mouse clicks. Because of this I don't think Le Potato is a usable alternative for Grape 1.

I suspect the main problem is inadequate memory (2 GB instead of the recommended 4). But the process of converting a Raspberry Pi image to run on the Le Potato installs a number of new software packages and updates others. This may cause issues with Grape 1 software as well.

Raspberry Pi 4s are becoming available again at reasonable prices, so I don't plan to pursue the Le Potato for Grape 1 use any further. I have other uses for the board.

Dave, WD8CIV

On Sunday, July 2, 2023 at 8:39:12 AM UTC-4 Dave Hinerman wrote:

Jonathan,

I have a Libre "Le Potato" on the way. From what I've seen so far it should boot from a Raspbian micro SD card after the card image has been modified while running in a Raspberry Pi. I have a Pi 2B available, so with a little luck I'll be able to do that. If it works I'll see if I can do the same with a Grape  1 image.

I'll report back to the group when I know more.

Dave, WD8CIV

On Saturday, July 1, 2023 at 9:54:13 AM UTC-4 emum...@gmail.com wrote:

All,

An alternative that may work is the Libre, which you can read about here. It won't boot a Pi image natively. I remember seeing documentation on how to convert a Pi image to boot on a Libre, but I cannot find it. You'll have to try it out as it was never done before. If it works, it'll be a great thing because they are cheap right now and available. I encourage others to try to get it working and write a guide on how to do it.

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/66d4a4c4-15aa-408c-a55a-9710ce098388n%40googlegroups.com.

[Jonathan]

Hi Dave,

I really appreciate the effort here! My gut feeling tells me that it's the age of the image and the updated dependencies causing the issue because this was originally developed on a Pi 3 and it has 1GB of RAM. I didn't realize that so many packages were updated, but the drivers for the Le Potato that are not included in the kernel probably require the updated packages. 

Again, I appreciate the effort here and valuable contribution!

Thanks again!

Jonathan

KC3EEY

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/8fbc8ed8-5015-462c-a8dd-444c15b85ca9n%40googlegroups.com.

[Dave Hinerman]

Jonathan,

You're probably right about the dependencies. I didn't realize how far back the Grape 1 software went. 

One other thing about the Raspbian conversion that caught my attention is that apparently at boot if it detects it's on a Libre board it downloads a compatible kernel. (If I understood what little information I could find correctly.) Otherwise it loads the resident Raspbian kernel. That would make the Libre board dependent on a live internet connection to start up. I don't know if that's acceptable for a Grape system, but at my old job that wouldn't have been allowed.

Dave, WD8CIV

[Jonathan]

Hi Dave,

I'm sure there is a way to permanently install the appropriate kernel. For deployment, it would have to be a permanently installed kernel. 

I believe John N8OBJ's modified version of fldigu is from 2019 or 2020 and was originally running on a Pi 3. I believe his Pi 3 is still currently running.

Still, thank you for the effort!

Jonathan

KC3EEY

To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-grape/91629e65-3c0a-44e6-b640-c5be6f374719n%40googlegroups.com.