<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Jonathan,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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<span class="gmail-Apple-converted-space"> supports</span> that. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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...</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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...</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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"  🤔😁</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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) .  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Using the OS system clock for timing gives bad results for above mentioned reasons.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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...</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Make sense?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 24, 2023 at 9:36 AM 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"><div dir="ltr">Hi John,<div><br></div><div>How does the PPS trigger the sampling? </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Jonathan</div><div>KC3EEY</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 21, 2023 at 8:47 PM John Gibbons <<a href="mailto:jcg66@case.edu" target="_blank">jcg66@case.edu</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"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jonathan,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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 </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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....)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 21, 2023 at 1:10 PM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">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"><div dir="ltr">John,<div><br></div><div>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?</div><div><br></div><div>How are you interfacing the A/D converters? Does it have the bandwidth for 96 kHz sampling or higher?</div><div><br></div><div>It looks like both the Grape 2 and the VLF system have equivalent timestamping accuracy.</div><div><br></div><div>Jonathan</div><div>KC3EEY</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 21, 2023 at 9:58 AM John Gibbons <<a href="mailto:jcg66@case.edu" target="_blank">jcg66@case.edu</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"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jonathan,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">3 - I am capturing ~30Hz to 4KHz audio bandwidth</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 16, 2023 at 1:26 PM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">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"><div dir="ltr">John,<div><br></div><div>Do you have a time domain plot showing the clock domains?</div><div><br></div><div>Do you synthesize it from the timepulse2 output on the M8T or do you utilize a DDS with a holdover oscillator?</div><div><br></div><div>Also, do you capture bandwidth in the audio range or even less?</div><div><br></div><div>Jonathan</div><div>KC3EEY</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 16, 2023 at 12:58 PM John Gibbons <<a href="mailto:jcg66@case.edu" target="_blank">jcg66@case.edu</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"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jonathan,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 15, 2023 at 12:50 PM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">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"><div dir="ltr">Hi John,<div><br></div><div>Did you take measurements of the PPS  and clock accuracy? How is the 8 kHz sample clock synthesized?</div><div><br></div><div>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. </div><div><br></div><div>Jonathan</div><div>KC3EEY</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 14, 2023 at 2:44 PM John Gibbons <<a href="mailto:jcg66@case.edu" target="_blank">jcg66@case.edu</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"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jonathan,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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!)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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...).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">What is your freq ref standard for the A/D sample clock?  Is it GPS DO'd?  Is it synced to the 1PPS?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 14, 2023 at 12:13 PM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">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"><div dir="ltr">John,<div><br></div><div>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.</div><div><br></div><div>Jonathan</div><div>KC3EEY</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 14, 2023 at 11:21 AM John Gibbons <<a href="mailto:jcg66@case.edu" target="_blank">jcg66@case.edu</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"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">That has already been designed and built and hardware tested (with better timing for data sampling) - it's called the Grape 2</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 14, 2023 at 9:57 AM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">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"><div dir="ltr">My apologies, the pictures did not attach inline. The attachments are all in order of what I describe.<div><br></div><div>Jonathan</div><div>KC3EEY</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 14, 2023 at 6:20 AM Jonathan <<a href="mailto:emuman100@gmail.com" target="_blank">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">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. <br>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
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. <br>
<br>
<br>
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. <br>
<br>
<br>
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.<br>
<br>
Jonathan<br>
KC3EEY </blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "hamsci-grape" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:hamsci-grape+unsubscribe@googlegroups.com" target="_blank">hamsci-grape+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB1oFMEHL2-ph5Re%3DOBnBBz%2Bv7aKhZiYnvH5gFTS0L4K-g%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/hamsci-grape/CAOY0kB1oFMEHL2-ph5Re%3DOBnBBz%2Bv7aKhZiYnvH5gFTS0L4K-g%40mail.gmail.com</a>.<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>