[time-nuts] Re: General discussion of PID algorithms applied to GPSDO control loops (continued 1)

2022-04-17 Thread André Balsa
Hi Tobias,
There are various approaches to using AI algorithms in PID controllers. One
approach (which is even described in a YouTube video) is to use genetic
algorithms to find optimal (or more precisely, near-optimal) coefficients
for the PID controller. However, that is not the approach I want to try to
use for the STM32 GPSDO.
I intend to use this Arduino library:
https://github.com/GiorgosXou/NeuralNetworks
and have the NN "learn" to control Vctl.
Whether it succeeds or not, it should be interesting to watch a machine
learning algorithm at work in the control loop of a 100% Open Source 40€
DIY GPSDO that can be put together on a breadboard in one afternoon!

On Mon, Apr 18, 2022 at 12:11 AM Pluess, Tobias via time-nuts <
time-nuts@lists.febo.com> wrote:

> Hi André,
> possibly you should also consider contributing to the Kalman filter
> approach; I haven't read your entire thread yet, but I would be interested
> in filtering the TIC readings with a Kalman filter, using the Kalman filter
> as a kind of observer, and feeding the filtered output to the PID
> controller.
> In my opinion, this approach is missing in your list ;-)
> the neural network is of course the really crazy stuff, do you have some
> literature about that? So would you use the NN also to filter the TIC
> readings and then provide filtered readings to the PID, or is your approach
> a totally different one?
>
> anyways, as glen eglish said:
> "fantastic discussion going on here. love it."
>
> best
> Tobias
> HB9FSX
>
>
>
> On Sun, Apr 17, 2022 at 6:55 PM André Balsa  wrote:
>
> > Hello Poul-Henning,
> > First let me thank you for your career-long significant contributions to
> > the Open Source world and to global internet standards.
> > Second, regarding your comment that "You _can_ have hybrid steering, but
> > you must assign "weight" to the
> > different contributions, so that they will never oscillate."
> > That is exactly how I intend to implement the hybrid PLL/FLL control loop
> > for the STM32 GPSDO. By December this year I should have implemented
> > separate PLL, FLL and hybrid PLL+FLL PID control loops for my STM32 GPSDO
> > project and hopefully I'll be able to collect enough data to compare
> their
> > behavior. I would also like to try programming a Neural Network (NN)
> based
> > GPSDO control loop algorithm and again compare its behavior with the
> > "classic" PID control loops.
> > Many thanks for your comment,
> > Andrew
> >
> > On Sat, Apr 16, 2022 at 4:55 PM Poul-Henning Kamp 
> > wrote:
> >
> > > 
> > > Bob kb8tq writes:
> > >
> > > >>> You mean the FLL and PLL are exclusive of each other ? I guess you
> > are
> > > >> right, but I am trying to think "outside the box" and see if there
> are
> > > any
> > > >> alternatives.
> > > >
> > > >You will have two people driving the car at the same time. One hits
> the
> > > >accelerator and the other hits the brakes at the same time. They both
> > > can’t
> > > >be active *and* feed the EFC at the same time. The practical answer is
> > to
> > > >run each during the warmup phase that it makes sense to do so.
> > >
> > > You _can_ have hybrid steering, but you must assign "weight" to the
> > > different contributions, so that they will never oscillate.  I normally
> > > have found it better to have a big switch which decides who gets to
> > > control,
> > > based on the (external) circumstances.
> > >
> > > As a general rule of thumb, FLL's only make sense if the product
> > > of the rate at which you measure phase difference, and the jitter-noise
> > > when you do, ends up way to the right and above the allan-intercept.
> > >
> > > Prof. Dave's infamous "Call NIST once a day with a modem" mode in
> > > NTPD is a good example:  Forget about tracking temperature, XO drift
> > > or anything else:  Just try to get the average frequency right on a
> > > timescale measured in weeks.
> > >
> > > Poul-Henning
> > >
> > > PS: When you implement your PLL:  The way to void "wind-up"
> > > durign startup, is to short the integrator, until the phase error
> > > has reached its proper sign.  It is surprising how hard it is
> > > to write code to spot that, compared to deciding it manually :-)
> > >
> > > --
> > > Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> > > p...@freebsd.org | TCP/IP since RFC 956
> > > FreeBSD committer   | BSD since 4.3-tahoe
> > > Never attribute to malice what can adequately be explained by
> > incompetence.
> > > ___
> > > 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] 100 MHz Low Phase Noise Mobile GPSDO/GNSSDO?

2022-04-17 Thread Carsten Andrich

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: General discussion of PID algorithms applied to GPSDO control loops (continued 1)

2022-04-17 Thread Pluess, Tobias via time-nuts
Hi André,
possibly you should also consider contributing to the Kalman filter
approach; I haven't read your entire thread yet, but I would be interested
in filtering the TIC readings with a Kalman filter, using the Kalman filter
as a kind of observer, and feeding the filtered output to the PID
controller.
In my opinion, this approach is missing in your list ;-)
the neural network is of course the really crazy stuff, do you have some
literature about that? So would you use the NN also to filter the TIC
readings and then provide filtered readings to the PID, or is your approach
a totally different one?

anyways, as glen eglish said:
"fantastic discussion going on here. love it."

best
Tobias
HB9FSX



On Sun, Apr 17, 2022 at 6:55 PM André Balsa  wrote:

> Hello Poul-Henning,
> First let me thank you for your career-long significant contributions to
> the Open Source world and to global internet standards.
> Second, regarding your comment that "You _can_ have hybrid steering, but
> you must assign "weight" to the
> different contributions, so that they will never oscillate."
> That is exactly how I intend to implement the hybrid PLL/FLL control loop
> for the STM32 GPSDO. By December this year I should have implemented
> separate PLL, FLL and hybrid PLL+FLL PID control loops for my STM32 GPSDO
> project and hopefully I'll be able to collect enough data to compare their
> behavior. I would also like to try programming a Neural Network (NN) based
> GPSDO control loop algorithm and again compare its behavior with the
> "classic" PID control loops.
> Many thanks for your comment,
> Andrew
>
> On Sat, Apr 16, 2022 at 4:55 PM Poul-Henning Kamp 
> wrote:
>
> > 
> > Bob kb8tq writes:
> >
> > >>> You mean the FLL and PLL are exclusive of each other ? I guess you
> are
> > >> right, but I am trying to think "outside the box" and see if there are
> > any
> > >> alternatives.
> > >
> > >You will have two people driving the car at the same time. One hits the
> > >accelerator and the other hits the brakes at the same time. They both
> > can’t
> > >be active *and* feed the EFC at the same time. The practical answer is
> to
> > >run each during the warmup phase that it makes sense to do so.
> >
> > You _can_ have hybrid steering, but you must assign "weight" to the
> > different contributions, so that they will never oscillate.  I normally
> > have found it better to have a big switch which decides who gets to
> > control,
> > based on the (external) circumstances.
> >
> > As a general rule of thumb, FLL's only make sense if the product
> > of the rate at which you measure phase difference, and the jitter-noise
> > when you do, ends up way to the right and above the allan-intercept.
> >
> > Prof. Dave's infamous "Call NIST once a day with a modem" mode in
> > NTPD is a good example:  Forget about tracking temperature, XO drift
> > or anything else:  Just try to get the average frequency right on a
> > timescale measured in weeks.
> >
> > Poul-Henning
> >
> > PS: When you implement your PLL:  The way to void "wind-up"
> > durign startup, is to short the integrator, until the phase error
> > has reached its proper sign.  It is surprising how hard it is
> > to write code to spot that, compared to deciding it manually :-)
> >
> > --
> > Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> > p...@freebsd.org | TCP/IP since RFC 956
> > FreeBSD committer   | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by
> incompetence.
> > ___
> > 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.

[time-nuts] Re: GPS antenna locations

2022-04-17 Thread N1BUG

On 4/17/22 13:08, Bob kb8tq wrote:

The TBolt needs about 16 db in front of it to do a reasonable job. With a
30 db gain antenna and no splitters, that leaves you with about 14 db or
so for cable and connector loss. Most of us accumulate multiple GPS
gizmos. A 4 way splitter takes your 14 down to 8 db. That puts you “at
the limit” with a bit over 100’ of LMR-400.


I currently have three GPS gizmos and expect to hold at that number. I 
use a GPS Networking LNFA1X4-N filtered amplified splitter spec'd at 0 
dB gain/loss. With the side mount option, the worst case cable loss 
would be around 10 dB, but probably a few dB less. It depends on which 
available cable I use.



The filter is after the amplifier. However the antenna itself is pretty 
narrowband.
If the filter was in front, getting a 2 db noise figure would be exciting.


Well then, possibly a concern but I suspect a GPS antenna doesn't pick 
up RF below 500 MHz very efficiently. I guess the only way to know for 
certain is to try it.


Paul
___
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: GPS antenna locations

2022-04-17 Thread Bob kb8tq
Hi



> On Apr 17, 2022, at 12:58 PM, N1BUG  wrote:
> 
> Thanks Bob.
> 
> I have no idea what makes that gap to the south. There is nothing to block 
> that direction above 15 degrees.
> 
> I am not concerned about cable losses. I have LMR-400 on this roof mounted 
> antenna because it is only a 50 foot run, but the smallest cable I have to 
> either tower is 1/2". The antenna spec sheet says 30 dB gain.

The TBolt needs about 16 db in front of it to do a reasonable job. With a 
30 db gain antenna and no splitters, that leaves you with about 14 db or 
so for cable and connector loss. Most of us accumulate multiple GPS
gizmos. A 4 way splitter takes your 14 down to 8 db. That puts you “at
the limit” with a bit over 100’ of LMR-400.


> 
> The data sheet on this antenna shows it being down >60 dB at +/- 50 MHz. With 
> a noise figure spec of 2.2 dB I suspect that filter is before the amplifier, 
> but I wish it actually said that. Add several tens of dB for separation of 
> antennas and I think it would be OK.

The filter is after the amplifier. However the antenna itself is pretty 
narrowband. 
If the filter was in front, getting a 2 db noise figure would be exciting. 

Bob

> 
> My only concern is with overload of the onboard amplifier in the antenna. It 
> is filtered again by a GPS Networking splitter (-60 dB at +/- 60 MHz) before 
> going to the Thunderbolt.
> 
> Side mounted at 80 feet on the VHF tower (60 feet higher than where the one 
> on the roof is), it would have a much better sky view, neglecting any 
> blockage to the north from the tower itself and at high elevation angles from 
> yagis on top of the tower).
> 
> I am leaning toward getting another of these antennas and side mounting it on 
> the tower, then doing a comparison of the signal strength vs az/el plot 
> against this roof mounted one. It is an extra expense I will have to find a 
> way to budget for, but certainly has educational value if nothing else.
> 
> Paul
> 
> 
> 
> 
> 
> On 4/17/22 09:04, Bob kb8tq wrote:
>> Hi
>> Not knowing everything about the local environment there’s
>> not much way to guess exactly what this or that location
>> will do. The biggest thing I see on your plot is something
>> due south of the current antenna location.
>> In a “typical” setup, anything within 20 degrees of the horizon
>> gets tossed out for timing. The paths are long and with normal
>> clutter multi path is likely at low angles.
>> The filters in the typical “telecom” antennas are set up to block
>> cell phone transmitters. The GPS and cell antennas are co-located
>> on the same tower so they can get hit pretty hard. That said, the
>> cell site isn’t running an ERP in the many hundreds of watts range.
>> The longer your cable, the more likely you are to need a booster
>> amp. The telecom antennas typically don’t have a lot of gain. Yes,
>> fancy cable can help with this. RG-58 is a bad idea :) ….
>> If you have a better sky view at 60 to 80’ on the tower, then a side
>> mount in that range would be my vote. Lightning would be my
>> biggest concern as you go higher. Assuming all the heights are
>> to the same reference, moving the antenna up 40 to 60’ should
>> do the trick.
>> Bob
>>> On Apr 16, 2022, at 2:05 PM, N1BUG  wrote:
>>> 
>>> Hello time nuts,
>>> 
>>> I finally have my long awaited Trimble Thunderbolt up and running. I am not 
>>> thrilled with the coverage using a Symmetricom 58532A antenna on the roof 
>>> about 20 feet above ground level. Here is what I get after ~24 hours:
>>> 
>>> http://n1bug.com/gpssig.png
>>> 
>>> Sometimes I have 8 satellites with usable signal, sometimes as few as 5. 
>>> The problem to the west is trees. I believe the chaotic signal strength in 
>>> the east is due to reflections from a metal roof.
>>> 
>>> I have three options:
>>> 
>>> 1. Leave the antenna where it is.
>>> 
>>> 2. Side mount it at 80 to 90 feet on a radio tower that has yagis for 
>>> 50/432/222/144 MHz at 105/110/115/120 feet. These antennas are used for 
>>> high power transmitting. Potential interference to GPS reception? I don't 
>>> know if the filter in the 58532A is before or after the amplifier. Blockage 
>>> from the tower and/or yagis? I assume mounting a few feet off the south 
>>> tower face would be best.
>>> 
>>> 3. Mount at the top of a mast on another radio tower, at 110 feet. This 
>>> would have a completely unobstructed sky view but would have antennas for 
>>> 7/10 MHz about 3 feet below and 14/18/21/24/28 MHz about 13 feet below. 
>>> Those antennas are used for high power transmitting. There will at some 
>>> point be a 10 GHz dish about 8 feet below the top of that mast.
>>> 
>>> Any comments on these options? Is it good enough where it is? I am only 
>>> using it as a 10 MHz reference now, but I may care about the 1 PPS later.
>>> 
>>> Paul N1BUG
>>> ___
>>> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send 
>>> an email to 

[time-nuts] Re: GPS antenna locations

2022-04-17 Thread N1BUG

Thanks Bob.

I have no idea what makes that gap to the south. There is nothing to 
block that direction above 15 degrees.


I am not concerned about cable losses. I have LMR-400 on this roof 
mounted antenna because it is only a 50 foot run, but the smallest cable 
I have to either tower is 1/2". The antenna spec sheet says 30 dB gain.


The data sheet on this antenna shows it being down >60 dB at +/- 50 MHz. 
With a noise figure spec of 2.2 dB I suspect that filter is before the 
amplifier, but I wish it actually said that. Add several tens of dB for 
separation of antennas and I think it would be OK.


My only concern is with overload of the onboard amplifier in the 
antenna. It is filtered again by a GPS Networking splitter (-60 dB at 
+/- 60 MHz) before going to the Thunderbolt.


Side mounted at 80 feet on the VHF tower (60 feet higher than where the 
one on the roof is), it would have a much better sky view, neglecting 
any blockage to the north from the tower itself and at high elevation 
angles from yagis on top of the tower).


I am leaning toward getting another of these antennas and side mounting 
it on the tower, then doing a comparison of the signal strength vs az/el 
plot against this roof mounted one. It is an extra expense I will have 
to find a way to budget for, but certainly has educational value if 
nothing else.


Paul





On 4/17/22 09:04, Bob kb8tq wrote:

Hi

Not knowing everything about the local environment there’s
not much way to guess exactly what this or that location
will do. The biggest thing I see on your plot is something
due south of the current antenna location.

In a “typical” setup, anything within 20 degrees of the horizon
gets tossed out for timing. The paths are long and with normal
clutter multi path is likely at low angles.

The filters in the typical “telecom” antennas are set up to block
cell phone transmitters. The GPS and cell antennas are co-located
on the same tower so they can get hit pretty hard. That said, the
cell site isn’t running an ERP in the many hundreds of watts range.

The longer your cable, the more likely you are to need a booster
amp. The telecom antennas typically don’t have a lot of gain. Yes,
fancy cable can help with this. RG-58 is a bad idea :) ….

If you have a better sky view at 60 to 80’ on the tower, then a side
mount in that range would be my vote. Lightning would be my
biggest concern as you go higher. Assuming all the heights are
to the same reference, moving the antenna up 40 to 60’ should
do the trick.

Bob


On Apr 16, 2022, at 2:05 PM, N1BUG  wrote:

Hello time nuts,

I finally have my long awaited Trimble Thunderbolt up and running. I am not 
thrilled with the coverage using a Symmetricom 58532A antenna on the roof about 
20 feet above ground level. Here is what I get after ~24 hours:

http://n1bug.com/gpssig.png

Sometimes I have 8 satellites with usable signal, sometimes as few as 5. The 
problem to the west is trees. I believe the chaotic signal strength in the east 
is due to reflections from a metal roof.

I have three options:

1. Leave the antenna where it is.

2. Side mount it at 80 to 90 feet on a radio tower that has yagis for 
50/432/222/144 MHz at 105/110/115/120 feet. These antennas are used for high 
power transmitting. Potential interference to GPS reception? I don't know if 
the filter in the 58532A is before or after the amplifier. Blockage from the 
tower and/or yagis? I assume mounting a few feet off the south tower face would 
be best.

3. Mount at the top of a mast on another radio tower, at 110 feet. This would 
have a completely unobstructed sky view but would have antennas for 7/10 MHz 
about 3 feet below and 14/18/21/24/28 MHz about 13 feet below. Those antennas 
are used for high power transmitting. There will at some point be a 10 GHz dish 
about 8 feet below the top of that mast.

Any comments on these options? Is it good enough where it is? I am only using 
it as a 10 MHz reference now, but I may care about the 1 PPS later.

Paul N1BUG
___
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.

[time-nuts] Re: General discussion of PID algorithms applied to GPSDO control loops (continued 1)

2022-04-17 Thread André Balsa
Hello Poul-Henning,
First let me thank you for your career-long significant contributions to
the Open Source world and to global internet standards.
Second, regarding your comment that "You _can_ have hybrid steering, but
you must assign "weight" to the
different contributions, so that they will never oscillate."
That is exactly how I intend to implement the hybrid PLL/FLL control loop
for the STM32 GPSDO. By December this year I should have implemented
separate PLL, FLL and hybrid PLL+FLL PID control loops for my STM32 GPSDO
project and hopefully I'll be able to collect enough data to compare their
behavior. I would also like to try programming a Neural Network (NN) based
GPSDO control loop algorithm and again compare its behavior with the
"classic" PID control loops.
Many thanks for your comment,
Andrew

On Sat, Apr 16, 2022 at 4:55 PM Poul-Henning Kamp 
wrote:

> 
> Bob kb8tq writes:
>
> >>> You mean the FLL and PLL are exclusive of each other ? I guess you are
> >> right, but I am trying to think "outside the box" and see if there are
> any
> >> alternatives.
> >
> >You will have two people driving the car at the same time. One hits the
> >accelerator and the other hits the brakes at the same time. They both
> can’t
> >be active *and* feed the EFC at the same time. The practical answer is to
> >run each during the warmup phase that it makes sense to do so.
>
> You _can_ have hybrid steering, but you must assign "weight" to the
> different contributions, so that they will never oscillate.  I normally
> have found it better to have a big switch which decides who gets to
> control,
> based on the (external) circumstances.
>
> As a general rule of thumb, FLL's only make sense if the product
> of the rate at which you measure phase difference, and the jitter-noise
> when you do, ends up way to the right and above the allan-intercept.
>
> Prof. Dave's infamous "Call NIST once a day with a modem" mode in
> NTPD is a good example:  Forget about tracking temperature, XO drift
> or anything else:  Just try to get the average frequency right on a
> timescale measured in weeks.
>
> Poul-Henning
>
> PS: When you implement your PLL:  The way to void "wind-up"
> durign startup, is to short the integrator, until the phase error
> has reached its proper sign.  It is surprising how hard it is
> to write code to spot that, compared to deciding it manually :-)
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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] Re: GPS antenna locations

2022-04-17 Thread Bob kb8tq
Hi

Not knowing everything about the local environment there’s 
not much way to guess exactly what this or that location 
will do. The biggest thing I see on your plot is something 
due south of the current antenna location. 

In a “typical” setup, anything within 20 degrees of the horizon
gets tossed out for timing. The paths are long and with normal
clutter multi path is likely at low angles. 

The filters in the typical “telecom” antennas are set up to block
cell phone transmitters. The GPS and cell antennas are co-located
on the same tower so they can get hit pretty hard. That said, the
cell site isn’t running an ERP in the many hundreds of watts range. 

The longer your cable, the more likely you are to need a booster
amp. The telecom antennas typically don’t have a lot of gain. Yes,
fancy cable can help with this. RG-58 is a bad idea :) ….

If you have a better sky view at 60 to 80’ on the tower, then a side
mount in that range would be my vote. Lightning would be my 
biggest concern as you go higher. Assuming all the heights are 
to the same reference, moving the antenna up 40 to 60’ should 
do the trick. 

Bob

> On Apr 16, 2022, at 2:05 PM, N1BUG  wrote:
> 
> Hello time nuts,
> 
> I finally have my long awaited Trimble Thunderbolt up and running. I am not 
> thrilled with the coverage using a Symmetricom 58532A antenna on the roof 
> about 20 feet above ground level. Here is what I get after ~24 hours:
> 
> http://n1bug.com/gpssig.png
> 
> Sometimes I have 8 satellites with usable signal, sometimes as few as 5. The 
> problem to the west is trees. I believe the chaotic signal strength in the 
> east is due to reflections from a metal roof.
> 
> I have three options:
> 
> 1. Leave the antenna where it is.
> 
> 2. Side mount it at 80 to 90 feet on a radio tower that has yagis for 
> 50/432/222/144 MHz at 105/110/115/120 feet. These antennas are used for high 
> power transmitting. Potential interference to GPS reception? I don't know if 
> the filter in the 58532A is before or after the amplifier. Blockage from the 
> tower and/or yagis? I assume mounting a few feet off the south tower face 
> would be best.
> 
> 3. Mount at the top of a mast on another radio tower, at 110 feet. This would 
> have a completely unobstructed sky view but would have antennas for 7/10 MHz 
> about 3 feet below and 14/18/21/24/28 MHz about 13 feet below. Those antennas 
> are used for high power transmitting. There will at some point be a 10 GHz 
> dish about 8 feet below the top of that mast.
> 
> Any comments on these options? Is it good enough where it is? I am only using 
> it as a 10 MHz reference now, but I may care about the 1 PPS later.
> 
> Paul N1BUG
> ___
> 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] Re: GPSDO Control loop autotuning

2022-04-17 Thread Pluess, Tobias via time-nuts
Hallo all,

In the meantime I had to refresh my knowledge about state-space
representation and Kalman filters, since it was quite a while ago since I
had this topic.

So I looked at the equations of the Kalman filter. To my understanding, we
can use it like an observer, and instead of using the phase error and
feeding it to the PI controller, we use the output of the Kalman filter as
input to the PI controller. And the Kalman filter gets its input from the
phase error, but we also tell it how much variance this phase error has.
Luckily, the GPS module outputs an estimate of the timing accuracy, so I
believe one could use this (after squaring) as the estimate of the timing
variance, correct?

I believe depending on how we model the VCO, we can get away with a scalar
Kalman filter and circumvent the matrix and vector operations.
I tried to simulate it in Matlab, and it kind of worked, but I noticed some
strange effects.

a) I made a very simple VCO model, that simulates the phase error. It is
x[k+1] = x[k] + KVCO * u with u being the DAC code. If KVCO is chosen
correctly, this perfectly models the phase measurements. I assumed the
process noise is zero, and the 1PPS jitter contributes only to the
measurement noise.

b) from the above model, we have a very simple state space model, if you
want to call it like this. We have A = 1, B=KVCO, C=1, D=0.

c) in the "prediction phase" for the Kalman filter, the error covariance
(in this case, the error variance, actually) is P_new=APA' + Q, which
reduces in this case to P_new=P+Q with Q being the process noise variance,
which I believe is negligible in this case.

d) in the "update phase" of the Kalman filter, we find the Kalman gain as
K=P*C*inv(C'*P*C + R), and this reduces, as everything is scalar and C=1,
to K=P/(P+R), with R being the measurement noise, which, I believe, is
equal to the timing accuracy estimate of the GPS module. Correct? we then
update the model xhat = A*xhat + b*u + K*(y-c*xhat), which simplifies to
xhat=xhat + Kvco*u + K*(y-xhat). Nothing special so far.

e) now comes my weird observation. I don't know whether this is correct.
The error covariance is now updated according to P=(I-K*C)*P, this breaks
down to P=P-K*P. I now observe that P behaves very odd, first we set P=P+Q,
and then we set P=P-K*P. It does not really converge in my Matlab
Simulation, and I see that the noise is filtered somewhat, but not very
good. It could also be related to my variances not being correctly set, I
am not sure. Or I made some mistakes with the equations.

Any hints?

As soon as I see it sort of working in Matlab, I want to test it on my
GPSDO. Especially the fact that I have an estimate of the timing error (the
GPS module announces this value via a special telegram!) I find very
amazing and hope I can make use of this.

best
Tobias
HB9FSX



On Tue, Apr 12, 2022 at 11:23 PM glen english LIST 
wrote:

> For isolating noise, (for the purpose of off line analysis)  , using ICA
> (Independent Component Analysis) , a kind of blind source separation ,
> can assist parting out the various noises to assist understanding the
> system better . There are some Python primers around for it.
>
> fantastic discussion going on here. love it.
>
> glen
>
>
> On 12/04/2022 6:42 pm, Markus Kleinhenz via time-nuts wrote:
> > Hi Tobias,
> >
> > Am 11.04.2022 um 13:33 schrieb Pluess, Tobias via tim
> ___
> 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] GPS antenna locations

2022-04-17 Thread N1BUG

Hello time nuts,

I finally have my long awaited Trimble Thunderbolt up and running. I am 
not thrilled with the coverage using a Symmetricom 58532A antenna on the 
roof about 20 feet above ground level. Here is what I get after ~24 hours:


http://n1bug.com/gpssig.png

Sometimes I have 8 satellites with usable signal, sometimes as few as 5. 
The problem to the west is trees. I believe the chaotic signal strength 
in the east is due to reflections from a metal roof.


I have three options:

1. Leave the antenna where it is.

2. Side mount it at 80 to 90 feet on a radio tower that has yagis for 
50/432/222/144 MHz at 105/110/115/120 feet. These antennas are used for 
high power transmitting. Potential interference to GPS reception? I 
don't know if the filter in the 58532A is before or after the amplifier. 
Blockage from the tower and/or yagis? I assume mounting a few feet off 
the south tower face would be best.


3. Mount at the top of a mast on another radio tower, at 110 feet. This 
would have a completely unobstructed sky view but would have antennas 
for 7/10 MHz about 3 feet below and 14/18/21/24/28 MHz about 13 feet 
below. Those antennas are used for high power transmitting. There will 
at some point be a 10 GHz dish about 8 feet below the top of that mast.


Any comments on these options? Is it good enough where it is? I am only 
using it as a 10 MHz reference now, but I may care about the 1 PPS later.


Paul N1BUG
___
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.