To: rsgb_lf_group@blacksheep.org
References: <15ca21dc75e-1e15-bcda@webprd-m105.mail.aol.com>
 <0f9558b4-457d-a395-58c9-7f9be3393cdd@sky.com>
 <4767d79f-2bf6-d838-bfd4-3e78102d6f5d@abelian.org>
 <510c15eb-b57a-0ebb-9037-1f83e0652cf2@sky.com>
 <933fcc32-d4c9-10cd-14b4-c179d66e27f9@abelian.org>
 <7ab80e0f-40d7-6b07-19c1-f4b256d47c52@sky.com>
 <a9c1a7cc-d835-fb85-1ae4-1682303d0c39@abelian.org>
 <594DB217.8060707@posteo.de>
From: Paul Nicholson <vlf0403@abelian.org>
Message-ID: <2eb826d6-d299-7b37-cf64-f5bef6718f24@abelian.org>
Date: Sat, 24 Jun 2017 05:28:07 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <594DB217.8060707@posteo.de>
Subject: Re: LF: Octo-soundcard for the Raspi, another question
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: RO


 > What is the ideal pulse length, amplitude and shape for
 > vlfrx tools?

I don't know if there's an optimum length but I tend to run at
2mS pulse width.  Probably anything in the range 1mS to 10mS
would do about as well.   I have found very short pulses,
eg the 10uS pulse from a Trimble Thunderbolt, is too short
and so is the longer pulse eg 100mS from a Garmin.

Here's the pulse I use on my VLF rx -

  http://abelian.org/vlf/tmp/170624a.gif

which is sampled at 192k/sec.  The RC time constant is close
to 0.8 of the pulse width, I think anything in the range 0.7 to
0.9 of the pulse width would do.  The shaped pulse spans about
800 to 1000 samples and the tail of the pulse is expected to
overshoot below zero due to the high pass corner of the sound
card input.

It's important that it doesn't clip, or flatten too much at
the top due to time constant too short.  It needs to be free
of noise and hum.

vttime is measuring the pulse centroid to obtain a sub-sample
estimate of the pulse position.  Here's the log of a few
pulse intervals,

  2017/06/24 04:41:57 ... PPSmad 0.038uS ... int 192001.3971
  2017/06/24 04:41:58 ... PPSmad 0.038uS ... int 192001.4029
  2017/06/24 04:41:59 ... PPSmad 0.037uS ... int 192001.3950
  2017/06/24 04:42:00 ... PPSmad 0.036uS ... int 192001.3955
  2017/06/24 04:42:01 ... PPSmad 0.035uS ... int 192001.3947
  2017/06/24 04:42:02 ... PPSmad 0.042uS ... int 192001.3756
  2017/06/24 04:42:03 ... PPSmad 0.043uS ... int 192001.4093
  2017/06/24 04:42:04 ... PPSmad 0.043uS ... int 192001.4025
  2017/06/24 04:42:05 ... PPSmad 0.042uS ... int 192001.3970
  2017/06/24 04:42:06 ... PPSmad 0.042uS ... int 192001.4066
  2017/06/24 04:42:07 ... PPSmad 0.043uS ... int 192001.4089

PPSmad is the average difference between successive pulse
intervals, ignoring sign.  Earlier versions of vttime used
to log the PPS interval sigma but the interval is often not
remotely Gaussian so I changed to mean absolute difference.
The raw interval jitter here is about 1% of a sound card
sample interval.  That's the sub-sample timing resolution you
get thanks to averaging over the pulse to obtain the centroid.
This centroid averaging and its external RC has the advantage
of filtering down any high frequency noise or interference on
the PPS signal.

Pulse intervals are averaged (default time constant 10 seconds)
to determine the prevailing sample rate, and the pulse positions
are averaged (also 10 seconds time constant) to place the
UTC second.  These two time constants can be tweaked on the
command line, eg

  vttime -m ppsbase+,w=auto,rs=5,ts=15 ... @in @out

sets the sample rate smoothing time constant to 5 seconds and
the timestamp smoothing to 15 seconds.   The longer the time
constants, the slower it will respond to genuine sample rate
changes, so shorter is better and you only make it longer if
the PPS intervals are noisy enough to need some extra smoothing.

I usually buffer the GPS PPS before shaping: a hex buffer does
fine for multiple outputs.  Supply rail to the buffer needs to
be very clean because in the 'on' state any noise or hum will
come straight through onto the shaped pulse.

I haven't mentioned the centroid offset.  This is a parameter
you have to calibrate yourself once you have got a clean
stable PPS and settled on RC values and amplitudes.  It tells
vttime how late the centroid is after the leading edge of the
timing pulse.   At 192k/sec you can set it roughly by eye using
the scope to get it within 10uS.   If you want the timestamps
better than that you have to inject PPS pulses into the rx
front end and average their phase and group delay.  You fine
tune the centroid offset to level off the phase slope, then
absorb any remaining frequency dependent phase shift using
an eqmap for vtfilter.

Luckily, for ebnaut reception and signal measurements, the
10uS or so accuracy set by eye is perfectly good enough.

--
Paul Nicholson
--