It seems that all programs fix the lat/lon output. However both gLAB and RTKLIB leave the height as a variable parameter. Interestingly it seems there is some peak at the end of the PTBG data and gLAB compensates by raising the height while RTKLIB compensates by raising the clock value.
And now an entry in the "Plan to throw one away" section.
RF Multiplexer, 8 inputs, 1 output, BNC-connectors, TE HF3 relays specified to 3 GHz, an ULN2803A to pull the relay-coil, and an SPI I/O expander to drive the ULN - should be easy - right?
Well no, PCB trace-geometry does strange things beyond VHF. I clearly don't grok UHF very well.
Onward towards version 2! (any thoughts and advice on simulation or trace-geometry optimizers appreciated!)
For isolated 1PPS distribution I made this distribution board.
The input is a TLP117 (or similar) optoisolator driving a LT1711 comparator with a 1.0 V trigger level. An output LED-blink is provided by LTC6993. Outputs are driven by IDT5PB1108 buffers.
In jitter measurements with a HPAK 53230A counter the jitter between two 1PPS pulses (from masers) seems to degrade slightly through this amplifier: from RMS 16-19 ps directly on the maser-outputs to between 21 and 26 ps RMS from the outputs of the ISOPDA. Maybe a faster optoisolator would be better?
KiCad sources available on request.
A mere ~3months 🙂 after moving to a new place I setup the lab-table again.
- Ikea table 120cm wide and 80cm deep.
- Top shelf on 40cm legs, 40cm deep.
- HPAK E3640A powersupplies
- 2-ch 62MXs-B 600MHz scope
- SDG2042X siggen
- HPAK 34401A and Fluke 177 DMMs
- Olympus SZ51 microscope with LED ringlight
- Hakko FA-400 and FX-888D for soldering
- SR620 counter
The usual noise-types studied have phase PSD noise-slopes "b" ranging from 0 to -4 (or even -5 or -6), corresponding to frequency PSD noise-slopes "a" ranging from +2 to -2 (where a=b+2). These 'colors of noise' can be visualized like this:
I've implemented three noise-identification algorithms based on Stable32-documentation and other papers: B1, R(n), and Lag-1 autocorrelation.
B1 (Howe 2000, Barnes1969) is defined as the ratio of the standard N-sample variance to the (2-sample) Allan variance. From the definitions one can derive an expected B1 ratio of (the length of the time-series is N)
where mu is the tau-exponent of Allan variance for the noise-slope defined by b (or a). Since mu is the same (-2) for both b=0 and b=-1 (red and green data) we can't use B1 to resolve between these noise-types. B1 looks like a good noise-identifier for b=[-2, -3, -4] where it resolves very well between the noise types at short tau, and slightly worse at longer tau.
R(n) can be used to resolve between b=0 and b=-1. It is defined as the ratio MVAR/AVAR, and resolves between noise types because MVAR and AVAR have different tau-slopes mu. For b=0 we expect mu(AVAR, b=0) = -2 while mu(MVAR, b=0)=-3 so we get mu(R(n), b=0)=-1 (red data points/line). For b=-1 (green) the usual tables predict the same mu for MVAR and AVAR, but there's a weak log(tau) dependence in the prefactor (see e.g. Dawkins2007, or IEEE1139). For the other noise-types b=[-2,-3,-4] we can't use R(n) because the predicted ratio is one for all these noise types. In contrast to B1 the noise identification using R(n) works best at large tau (and not at all at tau=tau0 or AF=1).
The lag-1 autocorrelation method (Riley, Riley & Greenhall 2004) is the newest, and uses the predicted lag-1 autocorrelation for (WPM b=0, FPM b=-1, WFM b=-2) to identify noise. For other noise types we differentiate the time-series, which adds +2 to the noise slope, until we recognize the noise type.
Here are three figures for ACF, B1, and R(n) noise identification where a simulated time series with known power law noise is first generated using the Kasdin&Walter algorithm, and then we try to identify the noise slope.
For Lag-1 ACF when we decimate the phase time-series for AF>1 there seems to be a bias to the predicted a (alpha) for b=-1, b=-3, b=-4 which I haven't seen described in the papers or understand that well. Perhaps an aliasing effect(??).
For fun I wrote a simple program that computes the SHA1 checksum for leap-seconds.list.
It turns out there's quirky convention of writing out the 40-character SHA1 checksum in 5 groups of 8 hex characters - whith the special undocumented rule that leading zeros are suppressed. This means the SHA1 check fails for some files where we happen to have a leading zero in one of the 8-character groups - unless you happen to know about the undocumented rule...
The output looks like this. "New" is the checksum computed by the program, "Old" is the checksum contained in the published file.
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list read 117 lines New: 1e2613791c4627c2d0a34c872ece0ae428dfb714 Old: 1e2613791c4627c2d0a34c872ece0ae428dfb714 Identical ? True ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list read 220 lines New: 3f00425591f969f7252361e527aa6754eb6b7c72 Old: 3f00425591f969f7252361e527aa6754eb6b7c72 Identical ? True https://www.ietf.org/timezones/data/leap-seconds.list read 250 lines New: 5101445a69948b5109153e2b2086e3d8d54561a3 Old: 5101445a69948b519153e2b2086e3d8d54561a3 Identical ? False https://data.iana.org/time-zones/code/leap-seconds.list read 250 lines New: 5101445a69948b5109153e2b2086e3d8d54561a3 Old: 5101445a69948b519153e2b2086e3d8d54561a3 Identical ? False ftp://ftp.nist.gov/pub/time/leap-seconds.list read 250 lines New: 5101445a69948b5109153e2b2086e3d8d54561a3 Old: 5101445a69948b519153e2b2086e3d8d54561a3 Identical ? False
There's also another simple script for authoring a leap-seconds.list file. It might be used for adding an artificial leap-second, generating a leap-seocnds.list file, and testing how different devices react to a leap-second - without having to wait for a real leap-second event.
See also time-stamp for leap-seconds.list.