[time-nuts] Re: GPS failed
The u-blox SAW filtering is great. We've carried out various RF measurements with +40 dBm EIRP at 2.53 and 3.75 GHz with some u-blox ANN-MB within <2m of the Tx antennas. While we haven't conducted in-depth comparisons with a superior ground-truth, my current conclusion is that the u-blox RTK performance is not (noticeably) affected by strong out-of-band emissions. Without extensive filtering the Tx power would likely steamroll any LNA/receiver. Of course, as John pointed out, this won't help against in-band interference. Best regards, Carsten On 11.07.22 15:16, John Ackermann via time-nuts wrote: Hi Skipp -- there is a lot of info about interference mitigation in the u-blox integration manual for the ZED--F9T (available under the docs at https://www.u-blox.com/en/product/zed-f9t-module). It might give you some clues, and I think might also point to another u-blox app note on the topic. Most of the antennas I've seen that have an LNA also include a SAW filter. I also once found on either Amazon or eBay so e new-product, relatively inexpensive, high pass filters with cutoff around 1 GHz. Those would help knock down broadcast, trunking, etc. stuff. (But of course nothing will help with on-frequency crud coming from outside the GPS system.) John On Jul 11, 2022, 8:49 AM, at 8:49 AM, skipp Isaham via time-nuts wrote: Hello to the Group, I'd like to get some opinions and war stories regarding GPS reliability at high RF level and elevation locations. Background: Three different hill-top GPS receivers, all different types, using different antennas mounted on an outside fixiture, plain view of the open sky, all stopped working. Test antennas were brought in and placed on a fixture well away from the original antennas, the recevers went back in to capture and lock. >From what I understand, the original antennas are what I would call straight preamp with no pre-selection / filtering. The ordered and now inbound replacements are said to contain a SAW filter system. It is the intent of the client to just place these "improved antennas" in to service and get on with life. I would suspect a GPS antenna (and receiver) could be subject to RF overload or blocking, however, we're assuming nothing major has changed at the site, nor any nearby location. One might think there are more GPS receivers being pushed out of reliable operation by the world around them, I'm just not hearing those stories >from a lot of people using them (GPS receivers). Any new install GPS receiver antenna ordered will/should contain some pre-selection to potentially avoid a problem, even some years down the road? Seems like that's where things are going... no more off the shelf, wide band, (hot) preamplified GPS antennas in busy locations? Thank you in advance for any related comments and/or opions ... cheers, skipp skipp025 at jah who dot calm ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-le...@lists.febo.com ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-le...@lists.febo.com ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-le...@lists.febo.com
[time-nuts] Re: Realtime comparing PPS of 3 GPS
On 31.05.22 01:10, glen english LIST via time-nuts wrote: Be aware not to confuse the antenna ground plane (the patch will always have its own plane because the top metalization must be fed against a plane or counterpoise - and a ground plane behind the antenna. I can see the usefulness of the larger ground plane for any purchased patch antenna to reduce the likelihood of interference underneath (if the feed coax has a good RF contact with the plane), and if the plane is coupled well, it may improve the low angle response . The supplementary ground plane doesnt have to have a galvanic connection if the gap between the underside of the patch is low- IE use purely a capacitive coupling to tie the patch antenna ground to the large ground sheet- [...] That means reducing the gap to about 0.05mm OR increasing the area- probably means using a bigger patch. Hi Glen, thank you for the insight. I was referring to a ground plane behind the antenna. Gaps below 1~2 mm between a magnetic "puck"-type patch antenna with IP67 housing and an external ground plane seem practically challenging to me. When it comes to stacked patch multi-band antennas like u-blox' ANN-MB [1], the gap between the top patch and the external ground plane is probably significantly higher. Yet, u-blox generally recommends the use of a symmetric ground plane for the RTK applications [1,2]. From my experience, the M8P and F9P RTK fix barely works without a ground plane under the u-blox antennas. While it's just an empirically educated guess, I'd assume that what is required for RTK will not hurt for timing. Could you share your expert opinion on this? My antenna expertise is admittedly limited to reading data sheets and picking the right one for the particular RF measurement requirements. Thanks and best regards, Carsten [1] https://content.u-blox.com/sites/default/files/ZED-F9P_IntegrationManual_UBX-18010802.pdf#page=114 [2] https://content.u-blox.com/sites/default/files/ZED-F9P-MovingBase_AppNote_(UBX-19009093).pdf#page=8 ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-le...@lists.febo.com
[time-nuts] Re: Realtime comparing PPS of 3 GPS
Hi Erik, have you tried running all receivers off the same antenna via a power splitter (make sure to dc block all but one receiver)? That should remove the uncertainty due to antenna differences (location, RF characteristics, etc.). Also, are you using ground planes for your puck antennas? These types of antennas typically require a ground plane for optimal performance [1]. Best regards, Carsten [1] https://content.u-blox.com/sites/default/files/products/documents/GNSS-Antennas_AppNote_(UBX-15030289).pdf#page=16 On 30.05.22 13:00, Erik Kaashoek via time-nuts wrote: Further evaluation did shown the time differences between the 3 GPS modules was due to difference in the trigger level setting of the timer/counter and difference in length of GPS antenna cables. After removal of the phase drift due to Rb frequency offset the attached image shows the phase differences of the 3 modules versus a Rb reference. The two ATGM modules are very consistent over a 2.8 hours period. The NEO-7M varies wildly with phase errors above 100 ns. Possibly due to a somewhat less optimal antenna position. It seems phase variations over time in the order of 10-20 ns are indeed unavoidable, even with a good antenna. Erik. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-le...@lists.febo.com ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-le...@lists.febo.com
[time-nuts] Re: Simple simulation model for an OCXO?
Hi Magnus,
On 15.05.22 19:37, Magnus Danielson via time-nuts wrote:
This is a result of using real-only values in the complex Fourier
transform. It creates mirror images. Greenhall uses one method to
circumvent the issue.
Can't quite follow on that one. What do you mean by "mirror images"?
Do you mean that my formula for X[k] is missing the complex
conjugates for k = N/2+1 ... N-1? Used with a regular, complex IFFT
the previously posted formula for X[k] would obviously generate
complex output, which is wrong. I missed that one, because my
implementation uses a complex-to-real IFFT, which has the complex
conjugate implied. However, for a the regular, complex (I)FFT given
by my derivation, the correct formula for X[k] should be the following:
{ N^0.5 * \sigma * N(0, 1) , k = 0, N/2
X[k] = { (N/2)^0.5 * \sigma * (N(0, 1) + 1j * N(0, 1)), k = 1 ... N/2
- 1
{ conj(X[N-k]) , k = N/2 + 1
... N - 1
If you process a real-value only sample list by the complex FFT, as
you did, you will have mirror fourier frequencies of opposite sign.
This comes as e^(i*2*pi*f*t)+e^(-i*2*pi*f*t) is only real.
I'm familiar with the hermitian symmetry properties of the Fourier
transform, just wasn't entirely sure that's what you were referring to.
Rather than using the optimization to remove half unused inputs
(imaginary) and half unused outputs (negative frequencies) with N/2
size transform, you can use the N-size transform more straightforward
and accept the losses for simplicity of clarity.
I agree that deriving for the regular, complex-to-complex DFT is best
regarding generality and clarity from a theoretical point of view.
However, from a practical standpoint, the complex-to-real IDFT/IFFT is
just a minor optimization with the hermitian symmetry of the spectrum
hard wired into the transform. It's an N-point (not N/2) IFFT that is
analytically -- not numerically, due to limited precision -- identical
to a fully-complex N-point IFFT of data with hermitian symmetry.
Practically, it halves memory usage and computational complexity [2].
When using common numeric packages like Matlab or NumPy, peak memory
usage may even be cut down to one third by obviating the extra copy of
the real values implied by "dropping" the imaginary component of a
regular IFFT's complex output.
IMHO, the minor head scratching involved in using a complex-to-real IFFT
(N/2+1 vs. N input samples) is well worth the computational advantage,
because the two implementation differences are minor and actually reduce
implementation complexity slightly:
1. The complex conjugate required for hermitian symmetry of the IFFT
input does not have to be explicitly computed, but is implied by the
transform.
2. The IFFT's output is already real, so explicitly dropping the
imaginary component is not required.
This is why Greenhall only use upper half frequencies.
Could you elaborate on that? Greenhall uses all 2N frequency-domain
samples of his 2N DFT [1]:
Let Z_k = √(S_k/2) (Uk + iV_k), Z_{2N-k} = Z*_k for k = 1 to N-1
Thanks and best regards,
Carsten
[1] https://apps.dtic.mil/sti/pdfs/ADA485683.pdf#page=5
[2]
https://www.fftw.org/fftw3_doc/One_002dDimensional-DFTs-of-Real-Data.html
--
M.Sc. Carsten Andrich
Technische Universität Ilmenau
Fachgebiet Elektronische Messtechnik und Signalverarbeitung (EMS)
Helmholtzplatz 2
98693 Ilmenau
T +49 3677 69-4269
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-le...@lists.febo.com
[time-nuts] Re: Simple simulation model for an OCXO?
Hi Magnus,
On 14.05.22 08:59, Magnus Danielson via time-nuts wrote:
Do note that the model of no correlation is not correct model of
reality. There is several effects which make "white noise" slightly
correlated, even if this for most pratical uses is very small
correlation. Not that it significantly changes your conclusions, but
you should remember that the model only go so far. To avoid aliasing,
you need an anti-aliasing filter that causes correlation between
samples. Also, the noise has inherent bandwidth limitations and
futher, thermal noise is convergent because of the power-distribution
of thermal noise as established by Max Planck, and is really the
existence of photons. The physics of it cannot be fully ignored as one
goes into the math field, but rather, one should be aware that the
simplified models may fool yourself in the mathematical exercise.
Thank you for that insight. Duly noted. I'll opt to ignore the residual
correlation. As was pointed out here before, the 5 component power law
noise model is an oversimplification of oscillators, so the remaining
error due to residual correlation is hopefully negligible compared to
the general model error.
Here you skipped a few steps compared to your other derivation. You
should explain how X[k] comes out of Var(Re(X[k])) and Var(Im(X[k])).
Given the variance of X[k] and E{X[k]} = 0 \forall k, it follows that
X[k] = Var(Re{X[k]})^0.5 * N(0, 1) + 1j * Var(Im{X[k]})^0.5 * N(0, 1)
because the variance is the scaling of a standard Gaussian N(0, 1)
distribution is the square root of its variance.
This is a result of using real-only values in the complex Fourier
transform. It creates mirror images. Greenhall uses one method to
circumvent the issue.
Can't quite follow on that one. What do you mean by "mirror images"? Do
you mean that my formula for X[k] is missing the complex conjugates for
k = N/2+1 ... N-1? Used with a regular, complex IFFT the previously
posted formula for X[k] would obviously generate complex output, which
is wrong. I missed that one, because my implementation uses a
complex-to-real IFFT, which has the complex conjugate implied. However,
for a the regular, complex (I)FFT given by my derivation, the correct
formula for X[k] should be the following:
{ N^0.5 * \sigma * N(0, 1), k = 0, N/2
X[k] = { (N/2)^0.5 * \sigma * (N(0, 1) + 1j * N(0, 1)), k = 1 ... N/2 - 1
{ conj(X[N-k]) , k = N/2 + 1 ... N - 1
Best regards,
Carsten
--
M.Sc. Carsten Andrich
Technische Universität Ilmenau
Fachgebiet Elektronische Messtechnik und Signalverarbeitung (EMS)
Helmholtzplatz 2
98693 Ilmenau
T +49 3677 69-4269
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-le...@lists.febo.com
[time-nuts] Re: Simple simulation model for an OCXO?
On 14.05.22 16:58, Matthias Welwarsky wrote:
I went "window shopping" on Google and found something that would probably fit
my needs here:
https://ccrma.stanford.edu/~jos/sasp/Example_Synthesis_1_F_Noise.html
Matlab code:
Nx = 2^16; % number of samples to synthesize
B = [0.049922035 -0.095993537 0.050612699 -0.004408786];
A = [1 -2.494956002 2.017265875 -0.522189400];
nT60 = round(log(1000)/(1-max(abs(roots(A); % T60 est.
v = randn(1,Nx+nT60); % Gaussian white noise: N(0,1)
x = filter(B,A,v);% Apply 1/F roll-off to PSD
x = x(nT60+1:end);% Skip transient response
Hi Matthias,
the coefficients could come the digital transform of an analog filter
that approximates a 10 dB/decade slope, see:
https://electronics.stackexchange.com/questions/200583/is-it-possible-to-make-a-weak-analog-low-pass-filter-with-less-than-20-db-decade
https://electronics.stackexchange.com/questions/374247/is-the-roll-off-gain-of-filters-always-20-db-dec
https://m.youtube.com/watch?v=fn2UGyk5DP4
However, even for the 2^16 samples used by the CCRMA snippet, the filter
slope rolls off too quickly. I've attached its frequency response. It
exhibits a little wobbly 1/f power slope over 3 orders of magnitude, but
it's essentially flat over the remaining two orders of mag. The used IIR
filter is too short to affect the lower frequencies.
If you want a good approximation of 1/f over the full frequency range, I
personally believe Greenhall's "discrete spectrum algorithm" [1] to be
the best choice, as per the literature I've consulted so far. It
realizes an appropriately large FIR filter, i.e., as large as the
input/output signal, and it's straightforward to implement. Because it's
generic, it can be used to generate any combination of power-law noises
or arbitrary characteristics, e.g., phase noise based on measurements,
in a single invocation.
Best regards,
Carsten
[1] https://apps.dtic.mil/sti/pdfs/ADA485683.pdf#page=5
P.S.: Python Code to plot attached frequency response:
import matplotlib.pyplot as plt
import numpy as np
import scipy.signal as signal
w, h = signal.freqz(
[0.049922035, -0.095993537, 0.050612699, -0.004408786],
[1, -2.494956002, 2.017265875, -0.522189400],
2**16)
plt.loglog(w/np.pi, abs(h))
plt.plot([1e-3, 1e-0], [0.93, 0.93/10**(0.5*3)], "--")
plt.xlabel("Normalized frequency ($f_\mathrm{Nyquist}$)")
plt.ylabel("Gain")
plt.grid()
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-le...@lists.febo.com
[time-nuts] Re: Simple simulation model for an OCXO?
On 11.05.22 08:15, Carsten Andrich wrote:
Also, any reason to do this via forward and inverse FFT? AFAIK the
Fourier transform of white noise is white noise, [...]
I had the same question when I first saw this. Unfortunately I don't have a good
answer, besides that forward + inverse ensures that the noise looks like it is
supposed to do, while I'm not 100% whether there is an easy way to generate
time-domain Gauss i.i.d. noise in the frequency domain.
If you know how, please let me know.
Got an idea on that, will report back.
Disclaimer: I'm an electrical engineer, not a mathematician, so someone
trained in the latter craft should verify my train of though. Feedback
is much appreciated.
Turns out the derivation of the DFT of time-domain white noise is
straightforward. The DFT formula
X[k] = \Sigma_{n=0}^{N-1} x[n] * e^{-2j*\pi*k*n/N}
illustrates that a single frequency-domain sample is just a sum of
scaled time-domain samples. Now let x[n] be N normally distributed
samples with zero mean and variance \sigma^2, thus each X[k] is a sum of
scaled i.i.d. random variables. According to the central limit theorem,
the sum of these random variables is normally distributed.
To ascertain the variance of X[k], rely on the linearity of variance
[1], i.e., Var(a*X+b*Y) = a^2*Var(X) + b^2*Var(Y) + 2ab*Cov(X,Y), and
the fact that the covariance of uncorrelated variables is zero, so,
separating into real and imaginary components, one gets:
Var(Re{X[k]}) = \Sum_{n=0}^{N-1} Var(x[n]) * Re{e^{-2j*\pi*k*n/N})}^2
= \Sum_{n=0}^{N-1} \sigma^2 * cos(2*\pi*k*n/N)^2
= \sigma^2 * \Sum_{n=0}^{N-1} cos(2*\pi*k*n/N)^2
Var(Im{X[k]}) = \Sum_{n=0}^{N-1} Var(x[n]) * Im{e^{-2j*\pi*k*n/N})}^2
= ...
= \sigma^2 * \Sum_{n=0}^{N-1} sin(2*\pi*k*n/N)^2
The sum over squared sin(…)/cos(…) is always N/2, except for k=0 and
k=N/2, where cos(…) is N and sin(…) is 0, resulting in X[k] with real DC
and Nyquist components as is to be expected for a real x[n].
Finally, for an x[n] ~ N(0, \sigma^2), the DFT's X[k] has the following
variance:
{ N * \sigma^2, k = 0
Var(Re{X[k]}) = { N * \sigma^2, k = N/2
{ N/2 * \sigma^2, else
{ 0 , k = 0
Var(Im{X[k]}) = { 0 , k = N/2
{ N/2 * \sigma^2, else
Therefore, a normally distributed time domain-sequence x[n] ~ N(0,
\sigma^2) with N samples has the following DFT (note: N is the number of
samples and N(0, 1) is a normally distributed random variable with mean
0 and variance 1):
{ N^0.5 * \sigma * N(0, 1), k = 0
X[k] = { N^0.5 * \sigma * N(0, 1), k = N/2
{ (N/2)^0.5 * \sigma * (N(0, 1) + 1j * N(0, 1)), else
Greenhall has the same results, with two noteworthy differences [2].
First, normalization with the sample count occurs after the IFFT.
Second, his FFT is of size 2N, resulting in a N^0.5 factor between his
results and the above. Finally, Greenhall discards half (minus one) of
the samples returned by the IFFT to realize linear convolution instead
of circular convolution, fundamentally implementing a single iteration
of overlap-save fast convolution [3]. If I didn't miss anything skimming
over the bruiteur source code, it seems to skip that very step and
therefore generates periodic output [4].
Best regards,
Carsten
[1] https://en.wikipedia.org/wiki/Variance#Basic_properties
[2] https://apps.dtic.mil/sti/pdfs/ADA485683.pdf#page=5
[3] https://en.wikipedia.org/wiki/Overlap%E2%80%93save_method
[4] https://github.com/euldulle/SigmaTheta/blob/master/source/filtre.c#L130
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-le...@lists.febo.com
[time-nuts] Re: Simple simulation model for an OCXO?
On 10.05.22 10:37, Neville Michie wrote: The use of forward then reverse Fourier transforms is one of the most important achievements of the Fourier transform. When one data set is convolved with another data set, it appears impossible to undo the tangle. But if the data is transformed into the Fourier domain, serial division can separate the data, and transformation back will yield the original data. Absolutely, but in this case I was wondering why to do the costly O(n log n) forward transform at all, if its output can be directly computed in O(n). On 10.05.22 12:58, Attila Kinali wrote: If you happen to find the paper, please share a reference. I'm curious about implementation details and side-effects, e.g., whether implementing the filter via circular convolution (straightforward multiplication in frequency-domain) carries any penalties regarding stochastic properties due to periodicity of the generated noise. Yes, for one, noise is not periodic, neither is the filter you need. You can't build a filter with a 1/sqrt(f) slope over all the frequency range. That would require a fractional integrator, which is a non-trivial task. Unless you actually do fractional integration, all time domain filters will be approximations of the required filter. Any chance the Paper was "FFT-BASED METHODS FOR SIMULATING FLICKER FM" by Greenhall [1]? I've had a look at the source code of the bruiteur tool, which you previously recommended, and it appears to opt for the circular convolution approach. Would you consider that the state-of-the-art for 1/sqrt(f)? The same is used here [3]. Kasdin gives an extensive overview over the subject [2], but I haven't read the 20+ pages paper yet. I had the same question when I first saw this. Unfortunately I don't have a good answer, besides that forward + inverse ensures that the noise looks like it is supposed to do, while I'm not 100% whether there is an easy way to generate time-domain Gauss i.i.d. noise in the frequency domain. If you know how, please let me know. Got an idea on that, will report back. But be aware, while the Gauss bell curve is an eigenfunction of the Fourier transform, the noise we feed into it is not the Gauss bell curve. Thanks for pointing that out. It appears I went for the first reasonable sounding explanation to support my gut feeling without thinking it through :D Best regards, Carsten [1] https://apps.dtic.mil/sti/pdfs/ADA485683.pdf [2] https://ieeexplore.ieee.org/document/381848 [3] https://rjav.sra.ro/index.php/rjav/article/view/40 ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Simple simulation model for an OCXO?
First, thanks to everyone who chimed in on this highly interesting topic. On 04.05.22 18:49, Attila Kinali wrote: FFT based systems take a white, normal distributed noise source, Fourier transform it, filter it in frequency domain and transform it back. Runtime is dominated by the FFT and thus O(n*log(n)). There was a nice paper by either Barnes or Greenhall (or both?) on this, which I seem currently unable to find. This is also the method employed by the bruiteur tool from sigma-theta. Biggest disadvantage of this method is, that it operates on the whole sample length multiple times. I.e it becomes slow very quickly, especially when the whole sample length is larger than main memory. But they deliver exact results with exactly the spectrum / time-correlation you want. If you happen to find the paper, please share a reference. I'm curious about implementation details and side-effects, e.g., whether implementing the filter via circular convolution (straightforward multiplication in frequency-domain) carries any penalties regarding stochastic properties due to periodicity of the generated noise. Also, any reason to do this via forward and inverse FFT? AFAIK the Fourier transform of white noise is white noise, because the underlying Gaussian is an Eigenfuntion of the transform. Generating in time-domain as follows (Python code using NumPy) N = int(1e6) # number of samples A = 1e-9 # Allan deviation for tau = 1 sec # generate white noise in time-domain X = np.fft.rfft(np.random.normal(0, A * 3**-0.5, N)) # multiply with frequency response of desired power-law noise and apply inverse Fourier transform # NOTE: implements circular convolution x = np.fft.irfft(X * H) should yield the same properties as generating the white noise directly in frequency-domain (there may be an off-by-one-or-two in there regarding variance scaling), but the latter will halve the computational cost: # generate white noise directly in frequency-domain # NOTE: imaginary components at DC and Nyquist are discarded by irfft() X = np.random.normal(0, A * 6**-0.5 * N**0.5, N+2).view(np.complex128()) # multiply with frequency response of desired power-law noise and apply inverse Fourier transform # NOTE: implements circular convolution x = np.fft.irfft(X * H) On 05.05.22 18:34, Magnus Danielson via time-nuts wrote: Both is being revisioned and 1139 just went out for re-balloting process after receiving ballotting comments and 1193 is just to get approved to be sent to balloting. Any details you can share regarding the changes over the current version? Are drafts publicly available? Best regards, Carsten ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: What time difference to expect from two clocks using internal GPS receivers?
In late 2019 we successfully employed 4 SRS FS740 (with Rb option; GNSS receiver: Trimble RES SMT 360) to synchronize spatially distributed SDR receivers over distances of 1~2.5 km for the purpose of locating RF emitters via time difference of arrival. As a side product of that measurement campaign we managed to assess the accuracy of the time synchronization of the FS740, which was about 5 ns over the course of 4 hours with a little post-processing relying on log data from the FS740. We circumvented the issues mentioned by Bob via a reference measurement with known emitter location and line of sight to all receivers. If you're interested in details, I'd refer you to a paper we published on the measurement [1]. Best regards, Carsten [1] https://ieeexplore.ieee.org/document/9128562 (behind IEEE paywall; I can send you a personal copy of the paper upon request) On 01.05.22 02:50, Bob kb8tq wrote: Hi If you are looking at time ( = the absolute offset from GPS’s version of UTC) then there are a number of issues. The antenna you use will have a delay and it may well vary more than a bit. The cable to the antenna is in the same category. If both your modules run off a power splitter then those will not show up in an A-B comparison. The modules themselves likely have SAW filters in them. These have group delay just like any other bandpass filter. The tolerance on this is likely in the 10’s of ns module to module. There are other bit and pieces that can contribute at the “nanoseconds” level. A typical set of modules from a good supplier should come in to a +/- 20 ns sort of window for 2/3 of the parts ( = 1 sigma). Geometry errors are fairly simple. A meter is 3 ns in free space. Each meter you are off from “correct” will add 3 ns of “wobble” in the results. Just how this shows up is very dependent on the direction of the error an what sort of satellite view you happen to have. Ionosphere can ( in high sunspot years) contribute 50 ns or more to timing errors. Tropospheric issues can also get into the mix at a bit lower level. You might think these would wash out on co-located units. Unfortunately they are not going to start /stop using this or that sat at exactly the same time. Lots of fun stuff to look for …. Bob On Apr 30, 2022, at 6:41 AM, Erik Kaashoek wrote: Some more info The two GPS do keep their phase stable vs a Rb within +/-10 ns. But the absolute time difference of their PPS pulses was, after a cold start, stable within +/- 20ns but the average value could be up to 100ns and differed after every cold start. The two GPS antenna cables had a length difference of 1 meter, but that should cater for only 5 ns (?) One module is connected to the antenna with only a C, the other has a 1 GHz CLC high pass filter between antenna and module Erik Op za 30 apr. 2022 om 12:32 schreef Erik Kaashoek : The PPS jitter of a cheap Chinese GPS module was measured at about +/- 10 ns. But the phase of the PPS compared to a Rb varied substantial more. To verify if this was possibly due to ionospheric or atmospheric conditions the time difference between the PPS of two identical modules using two identical rooftop antenna was measured. Both only used the GPS constellation. This showed difference of up to 100 ns. Switching to GPS+GLN did not make a visible difference. It was tried to set both GPS modules into fixed position mode but the reported position still kept moving a bit (within 3 m) and the fixed mode did not have a visible impact on the time difference variations. Is a time difference of up to 100 ns to be expected when using two GPS receivers or is this difference possibly due to bad application or performance of the cheap Chinese GPS modules Erik. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. -- M.Sc. Carsten Andrich Technische Universität Ilmenau Fachgebiet Elektronische Messtechnik und Signalverarbeitung (EMS) Helmholtzplatz 2 98693 Ilmenau T +49 3677 69-4269 ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: GPSDO Control loop autotuning
__ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. -- M.Sc. Carsten Andrich Technische Universität Ilmenau Fachgebiet Elektronische Messtechnik und Signalverarbeitung (EMS) Helmholtzplatz 2 98693 Ilmenau T +49 3677 69-4269 ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: 100 MHz Low Phase Noise Mobile GPSDO/GNSSDO?
Hi Markus, On 20.04.22 08:24, Markus Kleinhenz via time-nuts wrote: Am 19.04.2022 um 18:51 schrieb Carsten Andrich: Thanks for the suggestion. I've had a quick look at the RCM. Unfortunately, its "1PPS synchronization counter resolution" is ±2.5ns, which is below what a ZED-F9T can do with pulse quantization correction (~4e-10 ADEV @ 1s) [1]. I presume a short PLL time constant and therefore high resolution are key here to keep the OCXO within 1 ns of the GNSS despite environmental disturbances (temperature, acceleration, vibration). I think I'll have to realize the 1PPS tracking and OCXO disciplining myself with a sufficiently accurate time interval counter (e.g., TI TDC7200, which has ~50 ps resolution). The concept of most GNSSDOs is to "flywheel" the 1PPS generation using a stable local OCXO for tau <100s. This would allow for your spec of ADEV <1e-10@1s. That in turn would mean long time constants for the PLL and your receivers wouldn't track the same disturbances. That's also what I had in mind for generating a stable 1PPS output. For first locking the OCXO to the GNSS' jittery 1PPS, a high resolution time interval counter is required, so the measurement jitter is significantly below the 1PPS jitter. Certainly, finding the right tradeoff for the choice of PLL time constant will not be trivial. A dynamic solution that responds faster to local disturbances would be desirable. On 20.04.22 08:24, Markus Kleinhenz via time-nuts wrote: Another big challenge will be the 1ns relative accuracy between multiple (moving!) devices. Without communication between devices this should not be possible. We've conducted RF measurements with a bunch of stationary(!), but spatially distributed (1~2 km) SRS FS740 GNSSDOs (with Rb option) back in 2019 and have achieved better than 5 ns synchronization accuracy (verified using line-of-sight RF measurements) without communication between the FS70 [2], simply because the FS740 does not support that. Of course that's not really comparable to 1 ns with moving GNSSDOs, but is already pretty decent for the FS740s' single-band GNSS receiver with 15 ns 1PPS timing accuracy (likely Trimble RES SMT 360). I would love to read that Paper, that sounds impressive. As Jim wrote, I think it hinges on the fact that all receivers see the same sats. Dual-band mainly eliminates ionospheric errors but those are pretty much the same if all receivers are in the same area. I've sent you the paper privately. Unfortunately, even for the stationary use case, a common satellite view for all GNSSDOs cannot be guaranteed. It only gets worse for mobile applications where the obstructions and therefore satellites in view change rapidly. This is where I'd expect dual-band to excel, because I'd assume ionospheric conditions differ substantially when the receivers view a disjoint set of set of satellites. On 20.04.22 08:24, Markus Kleinhenz via time-nuts wrote: On 19.04.22 15:49, Lux, Jim wrote: I think that 1 ns might be achievable, if the receivers are in the same general area, so they see the same propagation, but perhaps not as an "off the shelf" device. That's where the ZED-F9T's dual-band reception and differential timing feature come into play, which improve the time pulse accuracy to 2.5 ns. It's similar to real-time kinematic positioning (DGNSS on steroids) by distributing a correction signal to multiple receivers. Does the RTCM feature expect one fixed base station? I think so. The ZED-F9T's datasheet specifies an RTCM 1005 message as the base station information [1], which AFAIK does not include the information required for moving baseline corrections [2]. However, you wouldn't necessarily have to operate a separate base station, as regular RTK correction services should also work (haven't verified with the ZED-F9T). The German state of Thuringia (and some others), provide these RTCM streams via Ntrip free of charge [3]. Best regards, Carsten [1] https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6 [2] https://content.u-blox.com/sites/default/files/ZED-F9P-MovingBase_AppNote_(UBX-19009093).pdf#page=10 [3] https://sapos.thueringen.de/ ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: 100 MHz Low Phase Noise Mobile GPSDO/GNSSDO?
Hi Markus, Jim, thank you for your responses! On 19.04.22 11:53, Markus Kleinhenz via time-nuts wrote: I believe you will have a hard time finding a COTS solution that fits most of your requirements. You will likely have to split your signal chain into multiple devices: 1. UBlox ZED-F9T based GPS-Receiver with 1PPS out 2. Something like a JacksonLabs RCM (a ULN Oscillator that locks to a externally provided 1PPS) 3. Distribution Unit So you can spread your requirements. Thanks for the suggestion. I've had a quick look at the RCM. Unfortunately, its "1PPS synchronization counter resolution" is ±2.5ns, which is below what a ZED-F9T can do with pulse quantization correction (~4e-10 ADEV @ 1s) [1]. I presume a short PLL time constant and therefore high resolution are key here to keep the OCXO within 1 ns of the GNSS despite environmental disturbances (temperature, acceleration, vibration). I think I'll have to realize the 1PPS tracking and OCXO disciplining myself with a sufficiently accurate time interval counter (e.g., TI TDC7200, which has ~50 ps resolution). Another big challenge will be the 1ns relative accuracy between multiple (moving!) devices. Without communication between devices this should not be possible. We've conducted RF measurements with a bunch of stationary(!), but spatially distributed (1~2 km) SRS FS740 GNSSDOs (with Rb option) back in 2019 and have achieved better than 5 ns synchronization accuracy (verified using line-of-sight RF measurements) without communication between the FS70 [2], simply because the FS740 does not support that. Of course that's not really comparable to 1 ns with moving GNSSDOs, but is already pretty decent for the FS740s' single-band GNSS receiver with 15 ns 1PPS timing accuracy (likely Trimble RES SMT 360). On 19.04.22 15:49, Lux, Jim wrote: I think that 1 ns might be achievable, if the receivers are in the same general area, so they see the same propagation, but perhaps not as an "off the shelf" device. That's where the ZED-F9T's dual-band reception and differential timing feature come into play, which improve the time pulse accuracy to 2.5 ns. It's similar to real-time kinematic positioning (DGNSS on steroids) by distributing a correction signal to multiple receivers. We are getting <1ns with post processing using GIPSYx in a weak signal environment with generally poor geometry from GNSS standpoint (we're going to be in GEO, above the constellation, so the signals we see are on the other side of Earth). Unfortunately, post-processing is not really an option for me, as long as I can avoid it. I think the ZED-F9T is as good as it gets in terms of value-for-money. I'll keep you updated when I make any progress on wiring up a proof-of-concept. Best regards, Carsten [1] https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25 [2] https://ieeexplore.ieee.org/document/9128562 <--- Behind IEEE "paywall"; I can send you a personal copy of the paper upon request ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] 100 MHz Low Phase Noise Mobile GPSDO/GNSSDO?
Fellow timing enthusiasts, for RF up-down-converters up to 40 GHz I require highly stable, synchronized reference signals for multiple, spatially distributed RF synthesizers like the TI LMX2595. Do any of you know COTS GNSSDOs that meet (at least some of) the following requirements?: * 100 MHz rectangular high slew rate (>2V/ns) output (no sinusoid; min. +13 dBm into 50 Ohms) * Low phase noise: <-130 dBc/Hz @ 100 Hz; <-140 dBc/Hz @ 1 kHz; <-150 dBc @ 10 kHz * Suitable for mobile use (at least 50 m/s absolute speed) with ADEV < 1e-10 @ 1 s (better preferred) * 1PPS (or preferably fully configurable timepulse signal usable as PLL SYSREF) locked to 100 MHz with better than 1 ns relative accuracy (between multiple receivers of the same type; not absolute accuracy wrt TAI) * Fast settling time after power up (preferably 10~30 min) to 1 ns synchronization of 100 MHz phase and 1PPS between multiple, spatially distributed GNSSDOs * Optional: 19" rack mount or desktop enclosure with SMA connectors * Optional: Dual-band GNSS receiver for improved GNSS timepulse ADEV performance [1] (that should enable a shorter time constant for disciplining the local oscillator and therefore improve compensation of disturbances like acceleration or temperature changes) * Optional: Differential timing GNSS receiver via RTCM feed (e.g., u-blox ZED-F9T [2]) * Optional: Multiple phase matched outputs (preferably at least 4) * Optional: 10 MHz outputs (divided from 100 MHz) for legacy measurement equipment Regarding 100 MHz output GNSSDOs, I've only found the Jackson Labs ULN-1100 [3]. Unfortunately, it doesn't meet my phase noise requirements and its use of a single-band GNSS receiver is not state-of-the-art. Best regards, Carsten [1] https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25 [2] https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6 [3] https://www.jackson-labs.com/index.php/products/uln_1100 - APPENDIX - Read only if you're interested in my reasoning behind some of above requirements. # Why 100 MHz rectangular output? ## 1. Phase noise scaling The primary reason to not use a 10 MHz reference signal is phase noise scaling. Taking the LMX 2595 as an example, its typical closed-loop phase noise at 10 GHz output [4, p. 15] is (averaged between 9 and 11 GHz and then coarsely rounded down to add a safety margin): dBc/Hz @ Off : 100 Hz 1 kHz 10 kHz 100 kHz LMX @ 10 GHz : -90 -100-110-112 Scaled 100 MHz: -130-140-150-152 Scaled 10 MHz : -150-160-170-172 Additionally, I've added the phase noise scaled down to 100/10 MHz to determine the theoretical requirements for a reference oscillator operating at the respective frequency. Checking out AXTAL (AXIOM*ULN) and Wenzel (HF ONYX IV), the lower bound for compact 10 MHz OCXO phase noise at both 10 kHz and 100 kHz appears to be -165 dBc/Hz. Therefore, using a 10 MHz reference would deteriorate the LMX' RF phase noise by ~5 dB. Also, even at +10 dBm OCXO output power, -170 dBc/Hz would be barely 14 dB over the thermal noise floor, raising noise and interference requirements regarding signal distribution and amplification. Admittedly, 10 MHz OCXOs do outperform 100 MHz OCXOs regarding the 10 Hz offset phase noise, but for typical RF applications, e.g., OFDM communication systems, channel estimation and correction typically handle time-variant effects below 100 Hz. ## 2. Phase noise figure of merit Most datasheets I've read, particularly TI LMX, show typical closed-loop performance for 100 or even 200 MHz reference oscillators. The HMC835 -- while certainly not representative -- is a noteworthy example I've stumbled over that actually illustrates the effect of different reference signals on the phase noise figure of merit [5, pp. 9 f.]. Going for anything below 100 MHz for the reference oscillator seems not to be encouraged by more or less modern RF synthesizers. ## 3. Slew rate Many RF synthesizers, e.g., the LMX2595, generally recommend a "high slew rate" for their reference inputs [4, p. 61]. The LMX2820 datasheet illustrates its phase noise degradation vs. slew rate, requiring >0.8 V/ns for optimal performance [6, p. 11]. A 2 Vpp 10 MHz sine has only 0.062 V/ns slew rate, so a 100 MHz sine is still insufficient. As a safety margin the GNSSDO's output slew rate shouldn't be lower than 2 V/ns. [4] https://www.ti.com/lit/ds/symlink/lmx2595.pdf [5] https://www.analog.com/media/en/technical-documentation/data-sheets/hmc835.pdf [6] https://www.ti.com/lit/ds/symlink/lmx2820.pdf ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Question about GPS 1PPS ADEV
Hello Matthias, provided your OCXO is sufficiently stable, i.e., better stability than the 1PPS, I agree that you should see said "bulge". Judging from the DAC plot, the EFC voltage is being adjusted within the tau range in which you expect the NEO-M8T bulge (10~100 s), so I'd expect that to have an effect on the TIC ADEV. Could you measure in holdover mode with fixed EFC voltage? Best regards, Carsten On 16.04.22 15:52, Matthias Welwarsky wrote: I reason that, were the LO more stable, more loosely coupled to the GNSS, I should see the bulge from figure 26. Would you agree? ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
Hello Erik, could you elaborate on your setup? Which oscillator (OCXO?) are you using to drive the STM32's PLL? I'm currently toying around with a (presumarly?) similar configuration. An RCB-F9T's 1PPS fed into an STM32G4's 32-bit timer capture to reference the 1PPS to a local oscillator with ~6 ns resolution, subsequently generating a stabilized 1PPS using another output channel of the same timer. The STM32's PLL is still using a cheap chrystal, but I'm currently working on replacing that with an OCXO. Best regards, Carsten On 01.04.22 18:19, erik at kaashoek.com (Erik Kaashoek) wrote: Nice, I'm trying to do something similar. But without the PICdiv or the TIC measurement. Only the GPS PPS into the STM32 and the stabilized PPS is generated by a timer in the STM32 First step was to measure against the running average of the GPS PPS. As can be seen in attached Timeplot measurement the phase error is (when temperatures stabilized) in the order of 10ns. Erik. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
