Close
0%
0%

GPS Disciplined 555 Timer

UTC Aligned PPS from a 555

Public Chat
Similar projects worth following
A fun project to explorer precision timing with a 555.

How far could you take precision timing, a 555 and a healthy dose of ridiculousness ?

This project covers the creation of possibly the world's most accurate 555 timer (*) (**)

* for some definition of accurate, we'll measure it and see what this means
** because no-one else with any common sense would do this


Objectives

Lock a 555 timer to GPS and measure how well it performs.


Constraints

1) The 555 must output 1 PPS which is phase locked to GPS

Frequency locking won't cut it, one of the measures will be how well the 555 can track UTC.

2) No exotic oscillators or tricks

The project must use a normal astable 555 design with a standard RC oscillator. as commonly found in any textbook. No driving the 555 with a rubidium standard, or controller driven charging tricks.

3) No exotic components

The project will be cheap and cheerful with parts I had to hand and without any specialist components. No special purpose ultra low noise regulators or op-amps; no expensive high precision capacitors or resistors. 


High Level Design

The basic oscillator design is fixed by constraint (2), we'll have a textbook astable 555 design with an RC oscillator, picking a capacitor and some resistors from the parts bin to get approximately 1hz. The only change here is to add a variable resistor so that the frequency can be roughly trimmed later on to centre the control loop voltages.

Whilst there are multiple ways that the frequency of the 555 can be dynamically adjusted, given constraint (2) the simplest approach is to manage the control voltage of the 555. Changing the control voltage changes the trigger thresholds of the 555 which allows the oscillation frequency to be varied as required. 

For the control loop, the only reasonable option is to use a microcontroller. Attempting to phase lock a 1 PPS with analogue components would be Hard and not practical given design constraint (3). 

I chose to use the stm32 family, they are cheap and have decent clock speeds, but crucially have excellent timers with hardware capture support. After an initial proof of concept with an stm32f103 (blue pill), I switched to a stm32f411 (black pill) for a small frequency boost and 32-bit timer. A 32-bit timer simplifies the capture code considerably. 

The job of the controller will be to capture the 1 PPS pulses from the 555 and GPS against its internal timer and then steer the 555 to match the frequency and phase of the GPS. 

The software will use a dual PID to control the frequency and phase of the 555. The first PID manages the frequency and sets the steering output to achieve a set frequency. The second PID makes small adjustments to the frequency set point, drifting the phase forwards or backwards to achieve phase lock.  

Steering of the 555 is achieved via a PWM DAC, output from the controller to the control pin of the 555 via an op-amp buffer. The control voltage precision will be in the uV range so care will be needed to effectively filter the PWM; the configuration of the filter will be found by experimentation and prototyping. 

GPS555-schematic.kicad_sch

Simplified schematic

x-kicad-schematic - 82.19 kB - 07/17/2025 at 12:49

Download

  • 1 × 555 Prototyping Products / PCB Chemicals
  • 1 × stmf411 aka Black Pill
  • 1 × GPS Receiver
  • 1 × MCP6002 Op Amp
  • 1 × 74AC14 Hex Schmitt Trigger

View all 9 components

  • Measuring the Result - Oscillator Stability

    burble07/17/2025 at 10:30 0 comments

    To measure the performance of the 555 oscillator we will primarily be looking at the Allan Deviation or 'ADEV'. Oscillator stability is a complex topic and there are much smarter people than me who can explain why ADEV is the measure of choice.

    Establishing a Baseline

    The first thing to do is capture the ADEV of the 555 RC oscillator when it is unlocked and not being controlled. This represents the base performance that we are looking to change via locking with GPS.

    The 555 shows a 'U' shape that is very typical of nearly all oscillators. 

    The ADEV tells us that, on average, the 555 is counting every second with a variance of just 2.77E-5 (or 27 us). 

    It can do better though, if we measured the ticks over a 30 second period we can achieve a variance 7.19E-6. This is due to the averaging out of noise sources and is represented in the graph as the bottom of the 'U' shape. 

    However, if we measure over a longer period it actually gets worse and the variation starts to increase again. This is due to other noise sources, such as oscillator drift, becoming dominant. This is the right part of the graph.

    GPS is Different

    The PPS from a GPS receiver does not exhibit the same U shape as seen with an oscillator

    It's actually just a straight line going down (ignoring a little wobble at the 4-5 second mark that is due to sawtooth).

    The atomic clocks in GPS satellites are incredibly precise and any long term noise or drift with the clocks is corrected out. We can take the PPS output from a GPS receiver and look at it over longer and longer intervals and get increasingly lower variance, forever (or at least whilst GPS remains operational).

    GPS Disciplining the 555

    The aim of GPS disciplining an oscillator is to transfer that long term stability of the GPS signal to the oscillator, correcting the longer term noise sources that are present in the right hand side of the 'U' shape. 

    Here's how it did:

    At short intervals, the stability matches that of the unlocked 555 RC oscillator.

    The PIDs in the MCU have a maximum averaging window of 18 seconds (16 seconds average and a 2 second settling time after any change). Clearly visible in the ADEV results is a small degradation in the performance as the PIDs adjust the control voltage to lock to the GPS signal. This is the gap between unlocked (pink) and locked (blue) lines. 

    • The unlocked ADEV shows that the minimum variance in RC oscillator is seen around intervals of 30 seconds. By extending the average time of the PID loops from 16 seconds to 30 we may be able to slightly improve the performance 

    At longer intervals the control loop is tracking the GPS PPS. The upturn in the 'U' seen in the unlocked oscillator is avoided and the variance continues to decrease with tau in a nice straight line.

    Sucess !

    The project succeeded at locking the 555 timer to GPS and achieving long term stability.

    How Does it Compare to Other GPSDO ?

    Badly.

    This image shows the typical ADEV of various oscillators locked to GPS, it's borrowed from the SRS website.

    Oscillators tend to have excellent short term performance, but poor long performance. On the other hand GPS has poor short term performance and excellent long term performance. The aim of a GPSDO is take an oscillator that performs better than GPS in the short term and get the best of both worlds, fusing the short term and long term performance. 

    The 555 RC Oscillator does not perform better than the GPS PPS

    It's worse, a lot worse, in fact by locking the GPS to a 555 we're actually degrading the GPS PPS signal

    It's not even close.

    • The one second pulse from the 555 has a deviation of 2.77E-5 meaning it wobbles around, on average, by 27us. 
    • A standard GPS module has a deviation of around 4E-8 (GPS modules are often spec'ed to 42ns), which is 3 decades or approximately a thousand times better
    • A good OCXO or Rb standard will have a deviation under 1E-11, yet another 3 decades...
    Read more »

  • Measuring the Result - The Control Loop

    burble07/17/2025 at 08:04 0 comments

    Time to see how well the boards perform against, well, time.

    In another case of over doing it, here's the measurement set up.

    The analogue board is placed in a foam box to protect against drafts that might cause short term temperature variations (Longer term temperature changes should be managed automatically by the control loop).

    Frequency and Phase Lock

    The following graphs show the frequency and phase difference of the 555 PPS against the GPS PPS following a reset.

    Frequency offset

    Phase offset

    The control loop is slow, but this is a design choice and we are in no hurry. 

    The two PIDs are  successfully able to bring both the frequency and phase in to alignment with the GPS PPS.

    Here's the view from the MCU parameters. 

    The graph shows the frequency PID maintaining the blue line (measured frequency) against the red line (the frequency set point). 

    The curve of the red line (frequency set point) shows the phase PID adjusting the set point to drift the phase into phase lock.

    Once locked, the phase is maintained with +/- 1 adjustments to the PWM. This hints that there may be slightly better performance available with smaller PWM steps and more control voltage resolution. The board under test has  approximately 9uV per PWM step control voltage resolution.

  • Finalising the Build

    burble07/16/2025 at 20:44 0 comments

    With the analogue board completed, it's now time to build out the digital and power management sections.

    Digital Section

    The digital section is built on to standard perfboard, there's nothing much to see here other than marvel at the poor quality of the construction. At one point, I had power and ground backwards leading to some exciting choices but that's what happens when building out on the fly without a plan. Memo to self, draw a diagram first.

    Breakout pins were added for ground and the PPS signals from the 555 and GPS; these facilitate connecting the TICC for doing measurements.

    Power Section

    So far the prototypes have been running from my bench power supply, but I wanted a bit more flexibility on the power source, allowing the board to run from a standard 12v wall adapter to be a bit more efficient on longer runs.

    Each of the sections has their own 5v LDO voltage regulator to avoid coupling noise between the digital and analogue components. This presents two challenges:

    • avoiding adding noise from using a cheap wall wart
    • dropping 12v to ~7v to supply the voltage regulators

    Whilst the boards use a tiny amount of power and the heat would probably be manageable, it seemed unwise to feed a potentially noisy 12v straight to the LDOs

    The power section uses a small buck converter to initially drop from 12v (or more) down to ~9v. This is then followed by an LM317 adjustable regulator to clean the input and drop the voltage again to 7v. The LM317 provides the analogue and digital sections with a relatively clean 7v which is then tidied up again by the section LDOs.


    The Big View

    Here's an annotated view of the final configuration

  • A Low Noise Analogue Build

    burble07/16/2025 at 20:07 0 comments

    After seeing noise related problems in the breadboard prototype it's time to get a bit more serious about the build and break out the soldering iron.

    The right answer here would probably be to design out a PCB with SMD components and get one of the Chinese fabs to build and ship it. But I'm impatient and I think this breaks constraint (3); a custom PCB is not something I have to hand and it's not cheap and cheerful.  

    The lowest noise way I know to construct circuits is a deadbug / manhattan style build so that's where we are going. It will look like a pile of junk but will hopefully be enough to get the noise floor down to somewhere 'reasonable'.

    Refining the PWM FIlter

    Part way through the build, testing out the PWM filter and with the old breadboard prototype still in situ.

    A key objective for the build is to improve the PWM filter and prevent leakage of the PWM signal through to the control voltage. The filter must effectively squash the 1.4khz PWM signal (moooaaar filtering) whilst also remaining responsive to control changes so that the PID functions (but not too much filtering).

    This design note from TI provides some inspiration on effective PWM filtering: Designing high-performance PWM DACs for field transmitters

    Handily, stm32 MCU have an 'Advanced Timer' peripheral that can generate complementary PWM outputs. These can be used as described in the 'Active ripple suppression' section (page 4) to create a first stage filter with the addition of just a few more passive components.

    The PWM filter now looks like this

    In this configuration the filter is able to move the control voltage between 3.84v and 4.48v with approximately 9uV resolution.


    Final Board

    Here's the built board in all its janky goodness, complete with excessive amount of bypass filters and solder.

  • Debugging the prototype

    burble07/16/2025 at 18:51 0 comments

    The second prototype has some issues:

    • There is a persistent frequency offset and the PID is unable to zero the frequency difference
    • The frequency is way too flat and doesn't show any of the expected noise, there are also strange phase jumps where the frequency should be smoothly varying

    There could be at least three possible causes for the errors:

    • a measurement error
    • a software problem preventing the PID from operating correctly
    • a physical problem with the circuit or layout

    Measurement Errors

    I'm very lucky to own a TAPR TICC:

    TAPR TICC

    The TICC is a timestamping counter with a very high resolution (~60 picoseconds) and very low noise floor around 1e-10); it's designed to perform long running measurements of low frequency (PPS like) signals so is ideally suited to measure the 1hz output from the 555.

    Using the TICC to graph GPS sawtooth errors:

    The TICC requires a 10mhz reference clock and has two timestamping channels. By using a GPSDO reference and providing the GPS PPS and 555 PPS on each channel a three cornered hat measurement can be performed to compare noise across the three sources. 

    The TICC, GPSDO and a standard GPS PPS all have much greater stability than the 555 RC oscilltor by some margin (~4 or 5 decades, at least) so there should be good confidence that the 555 measurements are accurate and the problems seen do not lie here. 

    Software or Hardware Problem ?

    To try and rule out problems with the PID software a simple test was created to sweep the PWM control voltage over a small range between 32768 (the centre frequency) and 33768 . The idea is to check the PWM is being generated correctly and the 555 is responding to the control voltage changes as expected.

    Ooops, that's not right, not at all. 

    Two separate problems become apparent:

    • During the test the 555 PPS became roughly phase aligned with the PPS from the GPS signal and became injection locked. For a small period both signals are locked in sync and beat together exactly
    • Rather than smoothly varying with control voltage, the 555 frequency is being quantized in to step changes

    Checking how far apart the quantization steps are reveals the culprit; each step is a difference of ~6E-4 which looks suspiciously like 65536 / 100,000,000. The smoking gun is pointing firmly at the use of PWM.

    No Surprises

    The control voltage for the 555 is very sensitive, with the each step of the PWM corresponding to just 3uV; any slight noise leaking through to the control voltage is going to influence the system.

    Conversely, a plug in breadboard is not a low noise environment and creating the prototype with digital components sat together with the sensitive analogue components is asking for trouble. It was inevitable that the prototype would get problems somewhere, so it was interesting to see where this would manifest.

    Next Steps

    To improve the results we'll need a lower noise build:

    • The analogue and digital parts of the system need to be kept apart. Physically, with separate builds and electrically by separating the ground and power networks as much as is possible
    • The analogue portion needs to use low noise build techniques with a solid ground plane, no more breadboarding 
    • The PWM filter needs beefing up to prevent the PWM signal leaking through to the control voltage
    • Bypass capacitors, _everywhere_

    Spoiler Alert from the Future

    Here's what a PWM sweep looks like in the final build.

    The difference is clear, showing the 555 frequency smoothly varying with control voltage and that the PWM control steps are smaller than the inherent noise of the 555 RC oscillator.

    Another Spoiler Alert from the Further Future

    A typical GPSDO will incorporate sawtooth correction to improve accuracy and reduce averaging times. This is not going to be required for the 555 as it performs way worse than the GPS PPS, even without taking sawtooth in to account. 

  • More Wires !

    burble07/15/2025 at 20:26 0 comments

    The second prototype makes a number of improvements over the first

    • The stm32f103 (Blue Pill) is swapped to an stm32f411 (Black Pill). The stm32f411 has a 32-bit timer allowing it to count a full 1 second period of 100 million ticks without overflow. This considerably simplifies the timer code and avoids potential race conditions that can occur with a 16bit timer and dealing with overflow. 
    • Power is now provided by a 5v LDO regulator driven from my bench power supply rather than the USB socket of the microcontroller. The flipside to now having plenty of spare power is that I can no longer use the USB serial on the microcontroller and have to add a serial to USB converter and output debug via the USART. The blue/black pill designs do not isolate the USB socket so you are unable to have both the USB and an external 5v supply connected. 
    • A 74AC14 Hex Schmitt trigger has been added to buffer the PPS from the 555 and GPS receiver. The 74AC14 allows adding led's and measurement probs without overloading either of the sources. 
    • With the initial prototype, it became clear that additional PWM resolution would be required so the PWM filter was tightened a bit

    The PWM control voltage is now roughly 3.64v to 3.84v with a resolution of 3uV per PWM step.

    • The first prototype software had 16bits of resolution when comparing the 555 and GPS frequencies. This was also increased to 24bits. This should be way overkill, but I've paid for all those bits and I'm going to use them.

    The result is good

    But actually that is _too_ good. 

    The spikes in frequency also indicate that the phase is being stepped rather than smoothly varying. 

    Zooming in shows a persistent 2.75e-5hz offset in frequency

    Both the stepping and frequency offset can be clearly seen in the phase difference

    Something is clearly not right.

  • First Prototype

    burble07/15/2025 at 19:55 0 comments

    The first step in the project was to quickly get a prototype running to test the concept and get an initial idea on where some of the challenges may lie


    PWM Filtering

    The MCU runs at 3.3v and uses a 16bit timer for the PWM signal, therefore providing 65k levels over a 3.3v range. The 555 however is operating at 5v and a full 3.3v range is way too much, so a simple PWM filter was chosen to shift up the PWM voltage and narrow the range:

    The filter provides a lower bound of the PWM at ~2.24v and an upper bound at ~3.5v with a resolution of around 19uV per PWM step. 


    Success ! 

    The prototype was able to demonstrate management of the 555 frequency using the control pin and a basic PID was able to bring the frequency to 1 hz:

    Approximately anyway, it's pretty noisy and we should be able to do better. 

    The first problem also became apparent pretty quickly ...

    Powering the prototype via the microcontroller USB connection wasn't going to be enough and a separate power supply with regulated voltage was going to be required.

View all 7 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates