Re: [time-nuts] TruePosition GPSDO Holdover Issues

[Gabs Ricalde]

On Sun, May 13, 2018 at 10:57 PM, Artek Manuals
 wrote:
> Nigel
> As I recall there is more to it than just the number of satellites.
> involved. Also factored in to all the math is the signal strength of the
> sats plus there relative angles to your spot on the earth. If all three are
> directly overhead the solution is not that accurate compared to if they were
> all at 45 degree elevation at widely divergent compass points gives a much
> more accurate solution . Likely the math / firmware has a quality factor
> built in depending on all the above factors not just the number of sats
>

Hi,

For a position/time solution, the dilution of precision (DOP) depends
on the number of satellites and the satellite geometry. When a timing
receiver is in 1D (position hold) mode, the TDOP is just 1/sqrt(# of
sats).
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] nuts about position (cheap receiver)

[Gabs Ricalde]

On Sat, May 5, 2018 at 12:08 AM, Mark Sims  wrote:
> You could add doppler to the RINEX file.   All the receivers with raw 
> messages seem to output that.

I think the Doppler measurements can be omitted for static
positioning. CSRS-PPP results for a submission with/without Doppler
are identical.

> I am playing with the Furuno GT87 output.  It does not output carrier phase 
> data (only pseudorange / doppler / SNR).   CSRS-PPP can still process that.

It seems the carrier phase is not used for single frequency
submissions. The summary file says
Observation processed:   CODE

For dual frequency,
Observation processed:   CODE
and there are carrier phase residuals in the PDF report.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] nuts about position (cheap receiver)

[Gabs Ricalde]

I submitted 4 days (118-121) of RINEX files from an IGS station to
CSRS-PPP, but with only the GPS C1, L1, and S1 observations. This is
similar to what cheap receivers would be generating, but with probably
lower noise. emr clocks/orbits were used. The east/north/up
differences between the PPP solutions and the latest IGS solution
(week 1996) in meters are:

   E  N  U
 -0.29  -0.05   0.14
 -0.01   0.12   0.03
  0.10   0.11  -0.04
 -0.04   0.02   0.65

The reported 95% sigma is 0.26m (longitude), 0.24m (latitude), 0.63m (elevation)
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] nuts about position (cheap receiver)

[Gabs Ricalde]

On Thu, May 3, 2018 at 9:40 AM, Mark Sims  wrote:
> G...  Canada lives in the dark ages and does not accept RINEX version 
> 3...  I'm now trying Australia...
>
> Version 3 is cleaner and easier to write than Version 2...
>

RTKLIB's RTKCONV can convert between RINEX versions.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] nuts about position

[Gabs Ricalde]

On Tue, May 1, 2018 at 2:14 PM, Hal Murray  wrote:
>
> kb...@n1k.org said:
>> One important qualifier to re-state. L1 post processing is very dependent on
>> the distance to an “open” source of correction data. The spacing of those
>> sites over the US is highly variable. If you get outside the US it is very
>> much a “that depends” sort of thing. Some countries apparently don’t have
>> the same sort of open site network
>
> Is there a map of the available locations?
>

Hi Hal,

There are maps for IGS [1], CORS [2], and EUREF [3] stations (and
probably others I'm not familiar with). For those three, RINEX obs
data can be downloaded if you want to do post processing with RTKLIB.
Centimeter-level static relative positioning is possible with single
frequency receivers and a reference station that is near (~10 km,
maybe more depending on the ionosphere).

[1] http://www.igs.org/network
[2] https://www.ngs.noaa.gov/CORS_Map/
[3] http://www.epncb.oma.be/_networkdata/stationmaps.php
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Gabs Ricalde]

On Mon, Apr 9, 2018 at 3:36 AM, Tom Van Baak  wrote:
>
> My mental model of a black box computer running NTP is that I should be able 
> to give it a pulse (e.g., via parallel, serial, GPIO) and it tells me what 
> time it was. Use a GPSDO / Rb / picDIV to generate precise pulses. Compare 
> the known time of the pulse with the time the box says it was. Repeat many 
> times, collect data, look at the statistics; just as we would for any clock.
>
> Similarly, the box should be able to give me a pulse at a known time. In this 
> case it records the time it thinks the pulse went out, and your GPSDO / Rb / 
> TIC makes the actual measurement. Again, collect data and look at the 
> statistics; just as we would for any clock.

On Wed, Apr 11, 2018 at 2:59 AM, Hal Murray  wrote:
>
> I think that should be a reasonable project.
>
> 1) Write some code to grab the time, send a pulse, grab the time.  Log that.
> 2) Use a time-stamp counter to log the time of the pulse.
> 3) Write the software to merge the two log files.
>

Hal, tvb,

I have a Linux PPS driver that does the following:
(1) Wait for the PPS rising edge
(2) Get the time
(3) Assert a GPIO output
(4) Set a timer that runs the following after 500 ms:
(5) Get the time
(6) Clear the GPIO output
(7) Get the time

The timestamps from (2) are the ones read by ntpd and it looks like this:
1523452407.99977
1523452408.4
1523452410.00021
1523452410.99977
1523452412.00028
PPS is from a u-blox LEA-6T.

(3) is the PPS echo and we will use that to measure the PPS latency.

The timestamps from (5) and (7) look like this:
1523452408.500016042 1523452408.500016467
1523452409.57535 1523452409.57955
1523452410.57246 1523452410.57666
1523452411.58362 1523452411.58782
1523452412.59269 1523452412.500010034

I don't have a TIC so I'm using the LEA-6T external interrupt for
measuring the edges from (3) and (6). The edges are timestamped with a
23 ns accuracy and reported in the TIM-TM2 (time mark) message. The
rising/falling edge values look like this:
306808.00845 306808.500016630
306809.00957 306809.58118
306810.00904 306810.57835
306811.00850 306811.58948
306812.00963 306812.500010207

The integer part is the UTC TOW.
The fractional part of the rising edge is the upper bound of the PPS latency.

Now we can subtract the (5)/(7) timestamps and the u-blox TIM-TM2
falling edge values:
1523452408 -0.00588 -0.00163
1523452409 -0.00583 -0.00163
1523452410 -0.00589 -0.00169
1523452411 -0.00586 -0.00166
1523452412 -0.00938 -0.00173

I've attached some plots:
"pps offset.png" is (2) minus round( (2) )
"before gpio clear.png" is (5) minus TIM-TM2 falling edge
"after gpio clear.png" is (7) minus TIM-TM2 falling edge
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Linux PPS clues?

[Gabs Ricalde]

On Fri, Oct 21, 2016 at 2:12 AM, Attila Kinali  wrote:
>
> Going for an uC is easier in that regard as they have very little interrupt
> latency (usually just 5-10 cycles), but then you have problems with
> getting the output out of the uC as their I/O subsystems are usually
> optimized to work in a stand-alone fashion.
>
> Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an 
> application
> processor) and use their high speed I/O.
>

The TI AM335x (used in the Beaglebone) has a Programmable Realtime Unit
(PRU), a 200 MHz microcontroller separate from the ARM CPU. I have used
this to decode a 192 kHz SPDIF signal (12 Mbit/s biphase mark code). The
samples are batched in the PRU SRAM, an interrupt is triggered
periodically, then a userspace program in the ARM Linux side reads the
samples from the SRAM.

The events can be timestamped by polling the PPS and event pins and
using the cycle counter. A better approach would be to use the 100 MHz
eCAP timers. The Beaglebone has two accessible eCAP pins, the PPS goes
to one and the event goes to the other. The counters can be synchronized
so the event timestamps can be referenced to the PPS timestamps.

Some PRU resources:
- https://www.youtube.com/watch?v=plCYsbmMbmY
- Slides: 
http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf
- http://exploringbeaglebone.com/chapter13/
- The eCAP and PRU-ICSS parts of the AM335x technical reference manual
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Q/noise of Earth as an oscillator

[Gabs Ricalde]

On Sat, Jul 30, 2016 at 1:19 AM, Tom Van Baak wrote:
> The remaining question in this thread is if earth Q measurement has actual 
> meaning, that is, if the concept of Q is valid for a slowly decaying rotating 
> object, as it is for a slowly decaying simple harmonic oscillator. And that's 
> were get into the history and definition(s) and applicability of Q to non 
> harmonic oscillators, such as coils, capacitors, atomic clocks, planets, 
> pulsars, etc.
>
> /tvb
>

On Mon, Aug 1, 2016 at 6:50 AM, Bill Byrom wrote:
> My final argument is that the rotation frequency of the Earth is
> affected by tidal friction, but the amplitude of the motion of that
> point 100 meters from the axis is unaffected. The amplitude of a
> harmonic oscillator is directly affected by friction or other losses,
> but the effect on resonant frequency is tiny. So loss effects frequency
> in one situation and amplitude in the other. How can Q relate to both
> situations?
> --
> Bill Byrom N5BB
>

I'll try to answer both. Apologies for mistakes or shortcuts, I will
correct or provide details in future posts if needed.
If we consider this definition:

Q = 2*pi * energy stored / energy lost per cycle,

we can write it as

Q = 2*pi * E / (-dE/d(cycle))
  = E / (-dE/d(theta))
 => E = E0*exp(-theta/Q).

The energy decays exponentially if the frequency is constant. The
impulse response of an RLC circuit is an exponentially decaying sinusoid
with a fixed frequency, so Q naturally describes the decay of an RLC
circuit and other resonant systems that behave similarly.

Suppose we want to use Q for a rotating object that gradually slows
down. When a rotating object loses energy, the period increases. From
the definition, the energy of a rotating object with constant Q decays
exponentially when we are counting cycles. But each cycle gets stretched
over time, so the energy decay is slower than exponential over time.

Omitting the derivation, a rotating object with constant Q behaves like
this:

E0 = energy at t = 0
I = moment of inertia
k1 = sqrt(E0/I)
k2 = E0*I
theta = 2*Q*log(k1*t/(Q*sqrt(2)) + 1) rad
omega = k1*2*Q / (k1*t + Q*sqrt(2)) rad/s(1)
energy = k2*Q^2 / (E0/2*t^2 + sqrt(2*k2)*Q*t + I*Q^2)



Consider the Earth with an LOD increase of 2 ms/century (6.338e-13 s/s).
Suppose LOD = 0 at t = 0. Then

k3 = 6.338e-13/(86400 s)
omega0 = 72921151.467064e-12 rad/s
omega = omega0 * (1 - t*k3) rad/s.(2)
( from http://hpiers.obspm.fr/eop-pc/earthor/ut1lod/UT1.html )

The frequency linearly decreases over time, which is different from the
angular frequency of a rotating object with constant Q (1). Again
omitting the derivation, the changing Q of the Earth over time is

Q = omega0 * (1 - t*k3)^2 / (2*k3).(3)

The Q is around 4.97e12 and decreases very slowly to 4.74e12 after 100
million years, assuming a constant 2 ms/century for that duration.



If the period linearly increases over time, the angular frequency is

omega = 2*pi / (T0 + k4*t) rad/s(4)

where T0 is the period at t = 0 and k4 is the change in period per
second. This looks like the angular frequency with constant Q (1). Let's
make (4) look like (1):

omega = k1*2*(pi/k4) / (k1*t + T0*k1/k4)

so we set Q = pi/k4 and set k4 equal to the change in the period of (2)
at t = 0. Then we get

Q = omega0 / (2*k3)(5)

which is the same as (3) when t = 0. If we approximate omega0 =
2*pi/86400 (1 cycle = 1 solar day), (5) is the same as tvb's formula
pi * (86400 * 365 * 100 / 0.002).



To recap:
1. An oscillation with fixed frequency and exponential decay has constant Q.
2. A rotating object with linearly decreasing frequency (2) has
decreasing Q (3).
3. A rotating object with linearly increasing period (4) has constant Q (5).
4. Over short time scales or when Q is very large, (3) is almost equal to (5).
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] frequency generation algorithm.

[Gabs Ricalde]

I did something similar in the Beaglebone Black AM335x PRU. Division is
done using a delay loop with variable number of cycles instead of an
interrupt. Converting a delay with a fractional amount to integer is
essentially a quantization problem. I'm using a triangular PDF dither
and first order noise shaping/error feedback ([1], last slide). The
dither randomizes the errors which should eliminate spurs. The feedback
reduces the error at DC to zero but will increase the jitter at high
frequencies. Zero error at DC means the time interval error (TIE) will
not drift. I don't have equipment to test the implementation in the BBB
so I'm just assuming it works.

The disadvantage is that you need a PRNG and do fixed point arithmetic.

I think this method is related to sigma-delta fractional-N techniques in
PLLs.

[1] Udo Zölzer, Quantization_Web_Summary.pdf
http://www.hsu-hh.de/ant/index_vNIYuPdokWfAvSaT.html

The code below is a Matlab/Octave simulation which plots the TIE and TIE
jitter spectrum.

% -
% cycle period (200 MHz)
T = 1/200e6;
% output frequency
f = 24000;
% delay in clock cycles, with fractional part
delay = 1/(f*T);
% enable/disable error feedback
feedback = true;

err = 0;
t = zeros(2048, 2);
for i = 2:2048
% exact
t(i,1) = t(i-1,1) + delay;

d2 = delay - err;
% add triangular PDF noise then quantize
qd = floor(d2 + rand()+rand()-0.5);
if feedback
err = qd - d2;
end
% delay d3 cycles
t(i,2) = t(i-1,2) + qd;
end
tie = t(:,1)-t(:,2);
plot(tie);
title('Time interval error (cycles)');
figure;
f = fft(tie);
f = f(1:end/2);
plot(20*log10(abs(f)));
title('TIE jitter spectrum');
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Beaglebone NTP server

[Gabs Ricalde]

Hello all,

School's about to end so I can finally work on this. I think there is a
standard GPIO PPS driver, configured using the device tree but I haven't
tried that.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Line Frequency

[Gabs Ricalde]

On Tue, Feb 11, 2014 at 1:57 AM, Tom Van Baak t...@leapsecond.com wrote:
 Alternatively, has anyone considered grabbing 50/60 Hz from the air? Just 
 about any dangling unshielded wire will act as a pickup. Maybe not as robust 
 a signal, but this is not so much a problem for solutions already using a 
 hardware or software PLL. And it certainly wins the safety prize. Call it the 
 iClock Air...

 /tvb


I'm using an AM loop antenna near a transformer. The antenna is
connected to the line input of a sound card. I'm also recording a PPS
signal on another channel in case I need a reference.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] sub-minute time-precision in court-case

[Gabs Ricalde]

I noticed that my old Nokia phones kept time better than computers, then
I learned that the oscillator in the phone is adjusted to match the BTS
carrier [1].

To verify this I ran ntpd in an Android phone synced to a stratum 1
server via USB tethering. (USB has a lower latency and jitter than
WLAN.) The frequency offset was between 25 ppb and 50 ppb (loopstats
graph attached). When the phone is put in airplane mode, the frequency
offset jumped to 11 ppm.

Unfortunately Android's timekeeping gets messed up when the phone
suspends since the time is restored from a possibly low resolution RTC
when waking up [2, sec. 3]. The phone is prevented from suspending when
connected to a USB port, another reason for using USB tethering during
the test.


[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSClocks
[2] https://lwn.net/images/pdf/suspend_blockers.pdf


On Wed, Sep 4, 2013 at 7:58 AM, Bill Hawkins b...@iaxs.net wrote:
 Who among you has volunteered to do the research for this?

 I don't have a camera in my cell phone, and I avoid market research
 masquerading as insecure social networks.

 Bill Hawkins


 -Original Message-
 Tom Van Baak said,

 For extra credit, further photos can be sent each hour for hours or
 days to determine the cell phone frequency drift and stability
 parameters.


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
attachment: _abs_frequency.png___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Needed: The Real Serial USB Fix

[Gabs Ricalde]

For serial to Ethernet I use ser2net [1] on cheap wireless routers
using the serial port pads on the board and a Beaglebone. The
application I use (u-blox u-center) can use TCP connections, if you
require a real COM port on Windows com0com and com2tcp [2] should work.

ser2net sends one TCP packet per character received on the serial port,
this may be desirable (when you need the lowest latency) or not (when
you want to reduce packet overhead)

[1] http://ser2net.sourceforge.net/
[2] http://com0com.sourceforge.net/

On Sun, Jan 27, 2013 at 9:47 PM, Stan, W1LE stanw...@verizon.net wrote:
 Hello The Net:

 Yes, I have had the mouse problem, but the more serious issue is when I run
 multiple (3) instances of Lady Heather
 (latest version at KE5FX) and after awhile none of the times agree and the
 problem only gets worse with time.
 I have tried the multiple USB to RS232 adapters into motherboard USB ports
 and I have tried a multi USB port PCI card.

 Any solutions with this problem ?

 Stan, W1LECape CodFN41sr



 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] looking for low-power system for gps ntp timekeeping

[Gabs Ricalde]

I did a quick test using a modified Python script to measure the elapsed
time of several NTP round trips
http://code.activestate.com/recipes/117211-simple-very-sntp-client/
The script is run on the Atom machine, all of the servers are running
ntpd 4.2.6p5

1.6 GHz Atom, loopback: 8100 req/s
400 MHz MIPS, no FPU (TL-WR703N): 2500 req/s
720 MHz ARM (Beaglebone): 3800 req/s

The R-Pi and the B-Bone should handle hundreds - thousands of
behaving clients.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Beaglebone NTP server

[Gabs Ricalde]

On Thu, Jun 20, 2013 at 3:39 AM, Chris Howard ch...@elfpen.com wrote:

 Are you using the original BeagleBone or the new BeagleBone Black?

I'm using the original BeagleBone. it should work on the BeagleBone Black.

 Will you have any details available about what parts are needed to set it up?

If your GPS receiver is using 3.3V logic, wiring it up is
straightforward, similar to the Raspberry Pi NTP server. I will probably
setup a page describing this.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Beaglebone NTP server

[Gabs Ricalde]

ntpd (poll=1) loopstats and ppstest using an eCAP clocksource and PPS

root@beaglebone:~# ppstest /dev/pps0
trying PPS source /dev/pps0
found PPS source /dev/pps0
ok, found 1 source(s), now start fetching data...
source 0 - assert 1371666297.5, sequence: 15602 - clear
0.0, sequence: 0
source 0 - assert 1371666298.3, sequence: 15603 - clear
0.0, sequence: 0
source 0 - assert 1371666299.8, sequence: 15604 - clear
0.0, sequence: 0
source 0 - assert 1371666300.00018, sequence: 15605 - clear
0.0, sequence: 0
source 0 - assert 1371666300.5, sequence: 15606 - clear
0.0, sequence: 0

To anyone interested, prepare a cross compiler (I'm using Linaro
2013.02) and try building a 3.8 kernel
(https://github.com/beagleboard/kernel/tree/3.8). I will post the
sources and patches.
attachment: _offset.png___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Beaglebone NTP server

[Gabs Ricalde]

On Sat, Jun 15, 2013 at 12:50 PM, Doug Calvert
dfc-l...@douglasfcalvert.net wrote:
 Can you explain what is different in this approach  versus the
 traditional gps/pps without needing a custom clocksource?

The default kernel uses TIMER2 for its clocksource, and is configured to
use the internal clock derived from the on-board crystal. TIMER2 does
not support event capture (hardware timestamps). The clocksource driver
uses TIMER4 (which supports event capture) configured to use an external
clock.

On Sat, Jun 15, 2013 at 9:47 AM, Jim King j...@jimking.net wrote:
 I don't have a BeagleBone (yet), but I'm very interested in this.  Are you
 going to post the driver somewhere when you're finished?

 Thanks,
 Jim

I will post the sources and instructions when it's ready.

On Sat, Jun 15, 2013 at 9:48 PM, Paul tic-...@bodosom.net wrote:
 On Fri Jun 14 20:13:51 EDT 2013,  Gabs Ricalde wrote:
 As an alternative to the Net4501, the AM335x in the Beaglebone has
 timers ...
 I'm finishing the clocksource driver for Linux

 Which distribution and which kernel are you using?

I am using the 
Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.05.28.img.xz
image and rebuilt the kernel (3.8.13) from https://github.com/beagleboard/kernel
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Beaglebone NTP server

[Gabs Ricalde]

As an alternative to the Net4501, the AM335x in the Beaglebone has
timers that accept an external clock up to 25 MHz (TCLKIN) and can
timestamp events on an input pin (TIMER4-TIMER7). Both sets of pins are
available on the headers after an appropriate pinmux configuration.

I'm finishing the clocksource driver for Linux, I'm testing it using the
10 MHz and PPS outputs of a LEA-6T. ntpd loopstats show +/- 0.1 us
offsets, frequency is a flat 0.000 PPM as expected.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] have 10MHz need 19.5Mhz

[Gabs Ricalde]

On Mon, Jun 3, 2013 at 4:30 AM, Gerd v. Egidy li...@egidy.de wrote:
 Hi Chris,

 The question is the best way to get from 10MHz to 19.5MHz.

 Must it be the RasPi or can it be another cheap Linux device?

 There are some out there which have a frequency which is simpler to reach than
 19.5 MHz.

 Have a look e.g. at the cheap low-power TL-WR703N, they use 25MHz:
 https://forum.openwrt.org/viewtopic.php?id=39829

 They don't have as much CPU as a RasPi, but should be enough for a local NTP.
 On ebay they cost a bit over 20 EUR delivered from China.

 Kind regards,

 Gerd


Hi,

I've been using WR703N/MR3020 and WR841N routers as NTP servers with
NMEA and PPS. The PPS drivers are a bit of a hack since I don't know how
to enable GPIO interrupts.

https://code.google.com/p/openwrt-stratum1/
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Legal Time dissemination

[Gabs Ricalde]

That looks like a server in an room with unstable temperature. Try
graphing the server's frequency (ntpq rv or ntpdc loopinfo/kerninfo if
enabled on the server), a rising frequency will correlate with a
positive offset if that is the case.

On Tue, May 28, 2013 at 7:52 PM, Miguel Barbosa Gonçalves m...@mbg.pt wrote:
 Hi!

 Lately I've been using the two stratum 2 servers our national observatory
 provides to the public mainly as backup for my GPS based local NTP servers.

 I've always found odd that one of them exhibited an erratic behaviour when
 compared to the other one.

 I decided to use ntpdate on one of my stratum 1 machines (Trimble
 AcutimeGold in position hold mode; looking at my loopstats file my
 clock is always
 within 5 us of UTC) against these 2 servers every minute for a while and
 plotted the results. Offset is in seconds and time is UTC.

 I am on a fibre asymmetrical connection 100 Mbps/25 Mbps. The offsets for
 the best behaved server are expected but... the other server?

 After gathering enough data I'll contact them as ask what is the problem
 with the server...

 Opinions?

 Regards,
 Miguel

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Legal Time dissemination

[Gabs Ricalde]

On Tue, May 28, 2013 at 9:26 PM, Miguel Barbosa Gonçalves m...@mbg.pt wrote:
 Hi!

 They've disabled the queries on both servers because I believe that don't
 want to see how badly they are configured... :-)

 Regards,
 Miguel

That is better than the one I'm monitoring. They* were running an
unsynchronized server for several months (ntpq -p shows INIT) which was
running fast. The offset reached 158 seconds until they installed a GPS
stratum 1 server.

*a government agency responsible for official time
attachment: offset.png___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Precise positions for GPSDOs

[Gabs Ricalde]

On Thu, May 2, 2013 at 5:29 PM, Stewart Cobb stewart.c...@gmail.com wrote:
 GPS surveying equipment can easily determine the position of your antenna
 to within a few centimeters (~20 ps). Unfortunately, such equipment is
 expensive and difficult to borrow.

 A high-end GPSDO designed today should have the ability to record phase
 data into RINEX files, which could be sent to a service like OPUS to find
 the antenna position.

 http://www.ngs.noaa.gov/opus/

 But few do, so far.


There are relatively cheap single frequency GPS receivers that output
raw (code and carrier phase) measurements. If you are near a base
station (e.g., [1]) that provides similar measurements, you can use
RTKLIB to post process both measurements and obtain a position within a
few cm.

A sample plot of the position of the patch antenna outside my window is
attached. The receiver is a u-blox LEA-6T, the RINEX of the base station
is from an IGS station 7.2 km away.

[1] http://igscb.jpl.nasa.gov/network/netindex.html
attachment: rtkplot.png___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Logging the grid frequency....

[Gabs Ricalde]

Hello,

I also don't have a Picotest or similar equipment but I've done similar
things by using the line input of a soundcard. Multiply the recorded
signal with a 60 Hz quadrature oscillator, apply a low pass filter then
do some analysis on the resulting phasor. The stability of the sound
card oscillator should be enough for this purpose.

You can measure the frequency difference w.r.t. the 60 Hz oscillator by
taking the slope of the phasor angle (be careful with phase wraparounds)
and you can do this as often as you like. I'm curious how this compares
with the zero crossing method.

On Fri, Feb 22, 2013 at 8:46 PM, Daniel Mendes dmend...@gmail.com wrote:

 Hi, I have a Picotest U6200A. I´m trying to log the grid frequency (60Hz) to
 generate data for my work. I need to get data from every cycle. I setup
 their program (it always starts in chinese... very funny) but seems that it
 can only log every 100ms. Questions:

 1) Is that a limitation of the equipment or the software?

 2) Using direct comands, can I get data faster?

 Thanks for any help...

 Daniel


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] SSR-6Tr Motorola/u-blox mode not working

[Gabs Ricalde]

I have a couple of SSR-6Tr boards but can't talk to them properly. Here
are the things I've tried:

  @@Am: 
  @@As: Lat 0, Lon 0, Height -0.01 m
  @@Aw: 1 (UTC)
  @@Cj: Synergy copyright, version, etc.
  @@Ga: lat/lon/height I entered earlier
  @@Ge: TRAIM enabled
  @@Gf: TRAIM alarm: 500 ns
  @@Gk: NONE
  @@Ha: all zeroes except E010h receiver status (3D fix, autosurvey
mode, antenna OK)
  @@Hb: corrupted
  @@Ia: 00, 00, 00
  @@Wb (switch to u-blox mode) not working

The receiver does not respond to other @@ commands listed on the
firmware v1.73 technote.

I tapped the UART Tx pin on the u-blox module; I'm seeing NMEA on one
receiver, NMEA + u-blox binary on the other.

Did anyone manage to communicate with the SSR-6Tr in Motorola or u-blox
mode? I'm planning on using the USB port of the LEA-6T, but soldering
might void the warranty.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timing between two GPS PPS outputs.

[Gabs Ricalde]

David,

Thanks for the update. The spikes I'm experiencing coincides with the
time when there are 3 or less visible satellites, as predicted by the
Trimble Planning software.

On Mon, Jan 7, 2013 at 8:02 PM, David J Taylor
david-tay...@blueyonder.co.uk wrote:
 From: Gabs Ricalde
 []
 Non-timing receivers could be unsuitable for your requirements, as
 some of us have discovered:
 http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#oscillations
 []
 ===

 Gabs,

 The oscillations I reported are not due to the use of a navigation GPS
 receiver.  I have discovered one other difference between the two Raspberry
 Pi PCs - firmware version.  I upgraded the PC with the oscillation from
 version 337601 to version 346337 firmware and this appears to have resolved
 the issue.  Fingers crossed!  Once things have stabilised, you will find a
 comparison between navigation (RasPi #1, MTK3339 Adafruit) and timing (RasPi
 #2, Trimble Resolution SMT) receivers here:

  http://www.satsignal.eu/mrtg/performance_ntp-pn.php


 Cheers,
 David
 --
 SatSignal Software - Quality software written to your requirements
 Web: http://www.satsignal.eu
 Email: david-tay...@blueyonder.co.uk

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timing between two GPS PPS outputs.

[Gabs Ricalde]

Some tests of timing receivers' PPS:
ftp://tycho.usno.navy.mil/pub/gps/Furuno/
http://www.cnssys.com/files/PTTI/PTTI_2002_CNS_Testbed.pdf (Motorola M12M)
http://www.cnssys.com/files/PTTI/Low_cost_GPS-based_time_and_frequency_products.pdf
(u-blox LEA-6T)

Non-timing receivers could be unsuitable for your requirements, as
some of us have discovered:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#oscillations
http://www.febo.com/pipermail/time-nuts/2012-December/072358.html

On Sat, Dec 29, 2012 at 3:49 AM, Dan Kemppainen d...@irtelemetrics.com wrote:
 Hi all,

 I've been following this list with some interest, and have a question about
 two individual timing GPS units PPS outputs. Let's assume that the timing
 GPS units are identical units, say two SSR-6t's for example.

 If I take these two units and fire them up next to each other off of the
 same antenna one would expect the PPS signals to be very similar to each
 other. If the unit specifies 20nS, I would expect at most, say, 40nS Error
 between the two PPS signals. (Maybe this is not correct, by all means
 discussion is welcome).

 Now, lets say we fire these units up on different antennas at the same
 location. For the purpose of this discussion let's assume the antennas are
 identical or as identical as reasonably possible. (Same make, mode, cable
 length, etc). Will they still be within the specified errors or each other?

 Now, lets say we move them some distance apart say 500meters (or yards if
 you prefer). Do they still maintain the same relative error between them?

 The reason for this question is two fold.  I have a personal project in mind
 where I'd like to time stamp two events within several tens of hundreds of
 nS if possible, over some distance without cabling. Also, as I started
 thinking of this application, I realized my understanding of the details of
 GPS timing is a little weak. I figured this would be a good place to ask.

 Thanks,
 Dan



 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] New to Time Synching hardware - needing some advice

[Gabs Ricalde]

It could be possible to use two Rb GPSDOs, one providing the PPS and
another disciplined by GPS, then rotate them every month.

On Fri, Dec 28, 2012 at 2:41 AM, Attila Kinali att...@kinali.ch wrote:
 On Thu, 27 Dec 2012 10:19:46 -0800
 Chris Albertson albertson.ch...@gmail.com wrote:

 Yes you could us something like one of the low-cost rubidium
 oscilators to supply a pulse per second to Linux NTP and it would work
 for some time before the error was as large as 10 mS.

 One missing requirement is how long you need be without GPS or
 networking.  Obviously you can't stay out of contact with the world
 forever but it is very easy and cheap if you only need a day. Harder
 if you need a month and expensive if you are talking about years.

 Actually, a couple of months is still quite simple.
 The Rb approace gives you at least something in the range of 10^-9 stability,
 long term. Which gets you into the ballpark of 100 days (with 10ms). If you
 temperature stabilize the Rb you should get down to 10^-11, which would
 be 30 years. At least theoretically, aging is AFAIK larger than this.
 But a couple of years should be still possible without too much effort.

 IIRC the FE5680 sell now for 200USD. Some heatsink and temperature control
 come maybe at 50-100USD. Some equipment to measure where the PPS lies
 relative to UTC and a powersupply that can get you 15V from mains and
 a battery (to get the Rb where the computer is) would also be necessary.

 Alternatively, put the Rb next to the computer in question, hook a powerfull
 linedriver to the PPS output, and a wire that goes all the way out where
 you have GPS reception and can measure the PPS pulse. After measurement,
 you can remove that cable.
 Ofcourse this only works, if you can lay a cable temporarily. If you are in a
 EMP secured room, the only way to get the pulse measured is the approach
 with the traveling Rb.

 Attila Kinali

 --
 There is no secret ingredient
  -- Po, Kung Fu Panda

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Just for Fun - Synergy Systems SSR-6T PPS Comparison

[Gabs Ricalde]

The Synergy site doesn't list the SSR-6Tr but I found a datasheet here:
http://diydrones.com/forum/topics/finally-a-relatively-inexpensive-u-blox-lea-6t-board-in-the-us

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] RaspberryPi and RADclock

[Gabs Ricalde]

On Thu, Dec 13, 2012 at 5:23 AM, Matt Davis m...@synclab.org wrote:
 Hey time-legumes, I figured a few of you all might be interested in some of 
 the
 work that the team and I have been doing.  We recently acquired a couple of
 RaspberryPis, and out of curiosity, we wanted to see how well our RADclock
 software performs on this small platform.  Anyways, our dive into the
 micro-platform world is on our blog:

 http://synclab.org/?post=blog/2012/11/radclock-raspberry-stability-nic-noise.html

 -Matt


Matt,

I haven't played with RADclock yet, any chance of the Linux kernel
patches working on 3.3.8? If it does, you could try RADclock on an
OpenWrt 12.09 Atheros (ar71xx) router and do some stability/NIC noise
measurements.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] PPS offset between GPS receivers

[Gabs Ricalde]

On Tue, Dec 11, 2012 at 5:55 PM, David J Taylor
david-tay...@blueyonder.co.uk wrote:

 Gabs,

 I've seen similar jumps, and it happens when the GPS/PPS signal drops out
 for a while.  In my case, the GPS receiver is sitting just in an upstairs
 room, not near a window or the root (as I normally have my other receivers).

  http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#u-blox

 Watching a low-current LED connected to the PPS signal (through an
 appropriate 680-ohm current-limiting resistor), I sometimes see the PPS stop
 flashing.  If it stops for long enough, NTP will revert to a different
 reference.  The hot-start may also result in a re-acquisition, and hence a
 break in the PPS pulses.

 I now need a 10-channel 'scope, as I have Rapco 1804M, Trimble Resolution
 SMT, a couple of Garmin GPS-18/x, Sure Electronics boards, and the u-blox
 (navigation) receivers shown above.  Comparing the PPS outputs they are all
 within about 100 ns, more or less.  G  Quite adequate for running NTP on
 my systems.

 Cheers,
 David
 --
 SatSignal Software - Quality software written to your requirements
 Web: http://www.satsignal.eu
 Email: david-tay...@blueyonder.co.uk


David,

I forgot to thank you for your helpful site and NTP plotter.

I have the antenna outside with a 180 degree view of the sky, outages
should be rare. Looking at the loopstats, the outage during the 4 us
jump is about 12 seconds. This is a test server, I only have the LOCAL
and PPS refclocks configured so during the outage the clock just
flywheels. I agree these cheap GPS receivers are more than enough for a
stratum 1 NTP server.

How about a 10 channel TIC? I'm sure someone could suggest a way to do
it, probably several PICTIC II's?

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] PPS offset between GPS receivers

[Gabs Ricalde]

On Tue, Dec 11, 2012 at 8:00 PM, David J Taylor
david-tay...@blueyonder.co.uk wrote:
 From: Gabs Ricalde
 []

 David,

 I forgot to thank you for your helpful site and NTP plotter.

 I have the antenna outside with a 180 degree view of the sky, outages
 should be rare. Looking at the loopstats, the outage during the 4 us
 jump is about 12 seconds. This is a test server, I only have the LOCAL
 and PPS refclocks configured so during the outage the clock just
 flywheels. I agree these cheap GPS receivers are more than enough for a
 stratum 1 NTP server.

 How about a 10 channel TIC? I'm sure someone could suggest a way to do
 it, probably several PICTIC II's?
 

 Agreed, that if your antenna has a good view of the sky you should not be
 seeing these drop-outs, at least not on a regular basis.  There are
 atmospheric conditions which will affect the GPS signals, though, but they
 should be rare.  No chance you get a trucker with a GPS jammer driving by at
 the problem times, I suppose?

 You say LOCAL and PPS - no seconds reference such as GPS/NMEA?

 You might also want to check what's happening on the box at the time of the
 jump.  If it's regular, perhaps some scheduled task is the cause?


 Cheers,
 David
 --
 SatSignal Software - Quality software written to your requirements
 Web: http://www.satsignal.eu
 Email: david-tay...@blueyonder.co.uk


I'm not sure about the jammer but I'm running a timing receiver in
position hold several floors up, I haven't seen dropouts like this.

ntpd is running with a noselect NMEA source since I'm having problems
with ntpd marking the PPS and NMEA as falsetickers. The startup sequence
for the server is this:

* run ntpd -g -q with NMEA enabled
* run chronyd for 3 minutes to set the time and frequency offset
* copy the current frequency to ntpd's drift file, then run ntpd with
NMEA disabled

This hack seems to work everytime with ntpd ready in less than 4 minutes
after turning on. I just hope nothing would happen that changes the
time.

I have seen 0.2 us spikes every hour from some unknown task but the
larger spikes are rare. Another device running the same OpenWrt firmware
but with a timing receiver has only the small periodic spikes.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] PPS offset between GPS receivers

[Gabs Ricalde]

 Date: Fri, 7 Dec 2012 22:28:20 -0500
 From: Bob Camp lists at rtty.us

 Hi

 A lot depends on exactly what the interrupt structure is. It may also depend
 on the phase of the cpu clock relative to the pps signal. What's reasonably
 sure is that there is indeed some offset between the two where the answer is
 indeed ft's random. Another thing to check - how wide is the random region?

 Bob

 On Dec 7, 2012, at 9:19 PM, Chris Albertson albertson.chris at gmail.com 
 wrote:

 One more test to try.  Connect one PPS signal to both GPIO ports and see
 how close to zero offset you get.   It would likely be random which gets
 read first.


I'm using an Atheros ar71xx platform, the GPIO driver does not use
interrupts so I'm using an experimental polling PPS driver:
http://code.google.com/p/openwrt-stratum1/wiki/PpsGpioPollDriver
The jitter is low, about 100 ns p-p (see graph on the main page). A TIC
mode could be added to measure the difference between events on two
GPIO ports.

I had an NTP server which had PPS on the serial port DCD and the
parallel port ACK, both derived from the same source. When both are
connected, the serial port timestamps are 10 us late. When the parallel
port is disconnected, the delay drops to 5 us. Probably the parallel
port ISR is executed first and delays the serial port ISR.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] PPS offset between GPS receivers

[Gabs Ricalde]

Hi everyone,

As Tom suggested, I redid the test with less than 1 ft. of wire from the
PPS output to the GPIO without any logic gates or line receivers. Same result,
the SKG25A1 was 2 microseconds ahead of the 58534A. Without any other way of
testing, I would probably trust the output of the timing receiver more
than the SkyNav module. Anyway the SkyNav board is an inexpensive unit and
I wouldn't mind setting an offset in ntpd.

I don't have a scope yet, and a low jitter PPS GPIO is the closest thing I have
to a TIC.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] PPS offset between GPS receivers

[Gabs Ricalde]

I'm using a Symmetricom 58534A GPS timing receiver and a GPS board with a
SkyNav SKG25A1 module driving stratum 1 NTP servers.

On one of the servers, the ppstest output while the 58534A is connected
looks like:
source 0 - assert 1354495734.00102
source 0 - assert 1354495735.00040

When I switch the PPS source to the SKG25A1, the ppstest output
indicates the PPS of that receiver is about 2 us early compared to the 58534A:
source 0 - assert 1354495740.97923
source 0 - assert 1354495741.97905

The setup looks like this:
58534A GPS - 10 m CAT5 cable - MC3486 RS422 receiver - GPIO
active antenna - 3 m cable - SKG25A1 GPS - GPIO

Both receivers were factory reset before the test.
I'm planning on getting another GPS receiver to check which receiver
is at fault. Has anyone found timing differences this large with their
GPS receivers?

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.