To: rsgb_lf_group@blacksheep.org
References: <157b3bf43d2-111e-bfa3@webprd-a11.mail.aol.com>
 <c28460b7-fa1e-cbf9-06bd-e14ad3c95b82@freenet.de>
 <5811C317.7000108@posteo.de> <1477585104.151596050@f13.my.com>
 <581255F6.9060705@abelian.org>
 <db43b601-4995-d735-6aca-340ee8a7ecaf@freenet.de>
 <06df01d2326c$c5b22950$51167bf0$@comcast.net>
From: =?UTF-8?Q?Wolfgang_B=c3=bcscher?= <dl4yhf@freenet.de>
Message-ID: <7f927fc4-e623-d7b5-e572-58593666ef2a@freenet.de>
Date: Mon, 31 Oct 2016 00:15:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <06df01d2326c$c5b22950$51167bf0$@comcast.net>
Subject: Re: LF: Re[2]: LF: Idiot's guide to receiving Ebnaut? - Tutorial
 part2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Content-Length: 4937
Status: O

Hello Jim (and all GPS/SL users),

I have just uploaded a new version of Spectrum Lab (currently V2.92 b01) 
which supports 'very short' GPS sync pulses.
Tested with 10 us GPS pulses. This isn't descibed in the manual yet : 
Simply set the "Pulse Width" on the SR Calibrator panel to "10 us" (the 
parser understands this simple 'tech' notation).
SL will automatically use a modified (*) centroid timing algorithm 
instead of the pulse edge detection.
It now gives a standard deviation of less than 60 ns at 48 kSamples/sec, 
and between 22 and 30 ns at 192 kSamples.

(*) for the curious: the modified centroid algorithm can be seen in the 
C source, which is at
      www.qsl.net/dl4yhf/t/GpsPulseDetector.cpp
     (it's ugly and bulky because I modified it back and forth a few 
dozen times,
     the interesting part is in GPS_Det_ProcessInterpolatedShortPulse() .
     The key for improvement at low sampling rates was the modified 
centroid calculation area,
     as explained in the above function.
    There is also a lengthy note of 'test results' which may be 
interesting. )

It's important not to overload the soundcard's input, even if the sync 
pulse is a rectangle.
I set the gain pot of the E-MU 0202's line input to the center position, 
and feed a pulse with about 200 mV peak into the jack.


All the best,
    Wolf  DL4YHF .


Am 30.10.2016 um 06:16 schrieb hvanesce@comcast.net:
> Wolf,
>
> Thank you, that is great news (10us pulse compatibility, and 25ns standard deviation). I have an E-MU 0202 so I will use the (192kHz centroid 4x interpolated windowed-sync-filtered) setup that you mentioned.
>
> On my previous attempts I was using a Scarlett 2i2 at 96kHz and probably didn’t have the 1pps channel configured correctly (in Windows and/or SpecLab); I'll provide for some hardware termination in case the Trimble rise time, coax length, and Z_in of the sound card don't agree.
>
> I'll also figure out what I did wrong with the Scarlett 2i2; and try the Roland SuperUA to see if it has some favorable attributes.
>
> Thanks again,
>
> Jim AA5BW
>
>    
>
> -----Original Message-----
> From: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.org] On Behalf Of Wolfgang Büscher
> Sent: Saturday, October 29, 2016 7:14 PM
> To: rsgb_lf_group@blacksheep.org
> Subject: Re: LF: Re[2]: LF: Idiot's guide to receiving Ebnaut? - Tutorial part2
>
>
>
> Am 27.10.2016 um 21:31 schrieb Paul Nicholson:
>> I have used the Trimble Thunderbolt with its fixed 10uS pulse.  It
>> worked (vlfrx-tools, M-Audio 192) but timing jitter improved after a
>> pulse stretcher increased the width to 1mS.  As Andy says, the 10uS
>> pulse energy was a bit low giving poor S/N and a jittery centroid of
>> the smoothed pulse.
>>
>> Now I use a Ublox for timing VLF reception and this works fine.  The
>> Thunderbolt is used for calibration and as a reference for comparing
>> my growing collection of GPSDOs.
>>
>> I'll be interested to see Wolf's comparison of edge and centroid
>> timing.  I've never had any luck with edge timing.
>>
> I compared both now, and measured the standard deviation in the GPS sync
> pulse timing.
> Used an E-MU 0202 at 192 kSamples/second.
> Test result:
>    - 100 ms pulses, using *edge* detection (in the fourfold interpolated,
> windowed-sinc filtered signal):
>      standard deviation about 40 to 50 ns/second
>
> - 10 us pulses, using *centroid* detection (also with fourfold
> interpolation):
>      standard deviation a very respectable 25 ns/second.
>
> The interpolated waveform of what used to be a 10-us-pulse is here:
> http://www.qsl.net/dl4yhf/t/10us_pulse_EMU0202_192kS_interpolated.png
>    (the green line in the center marks the length of a sample *from the
> soundcard*, the orange segments are interpolated).
>
> BUT...
> After reducing the sampling rate from 192 to 48 kHz :
>     - standard deviation 200 ns for the edge-detection method
>
>     - standard deviation 600 ns for the centroid method, reasons not
> understood yet
>     (this may be a bug, or it may be caused by using integer array
> indices as 'x' coordinate for the centroid detection area.
>     I will refine the algorithm for these 'very short' pulses by using
> polynominal interpolation for the centroid edges as well.
>     That would be a fairer comparison.)
>
> Even with the above restrictions, 10 us sync pulses seem to be ok, if
> the soundcard uses a good delta-sigmal ADC (which results an almost
> ideal low-pass filter and thus the text-book pulse response as in the
> screenshot linked above).
>
> So, short answer for Jim:
> You can use the Thunderbolt E's 10-microsecond sync pulses as they are,
> no need to shape or stretch them.
> I will upload a new version of SL soon, but first I will try to improve
> the pulse timing for lower sampling rates.
>
> Cheers,
>     Wolf .
> (back in "MEZ" / CET now - farewall, nice daylight-saving time.. sigh.. !)
>
>
>
>
>
>