EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: AndrewBCN on May 14, 2021, 05:30:58 pm
-
Hello,
I have been following the thread by the late Lars about his inspirational DIY Arduino GPSDO project. And I checked the dozen or so GPSDO projects published on the net.
Then I decided to join the party and design and build my own. :palm:
I didn't quite know what I was getting into, but after a couple of months waiting for the parts to come from China, and then another couple of months writing the firmware, I have a working, blinking, timekeeping and happily and precisely oscillating GPSDO. :-+
The main differences with Lars' design are:
- Modular and as much as possible, follows the K.I.S.S. design rule.
- It's based on an inexpensive yet powerful 32-bit STM32F411 MCU development board, the WeAct Black Pill running at 100MHz.
- It uses a digital FLL, not a digital/analog PLL. New! It can also use a PLL, see post #131 on page 6 in this thread.
- It can be put together on a breadboard in one afternoon (provided one has all the parts).
- It works practically "out of the box". There is nothing to adjust.
- It has an optional small OLED display.
- It has an optional BMP280 atmospheric pressure and temperature sensor.
- It has an optional AHT10 temperature and humidity sensor. Note: for new builds, the drop-in compatible AHT20 replaces the AHT10, same cost, slightly better accuracy.
- New! It has an optional INA219 current/voltage sensor to monitor the power consumption of the OCXO.
- It has an optional Bluetooth interface, so you can control it from your smartphone.
- New! It has an optional "Atomic Clock" display in big bright red, green or blue LED digits using a TM1637 display module, with the classic 1Hz blinking colon!
- New! Optional UTC-aligned 1PPS output using a picDIV. http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
- The BOM is very short and all the bits and pieces are easy to find and order.
- Total cost is around 30€ 40€ (that's around US $35 $45) for the stripped-down version, < 50€ 60€ with all the bells and whistles. Note: as of March 2022, with the recent semiconductor shortage and rising prices of components, the total cost has increased correspondingly.
Like with Lars' design, any OCXO, DOCXO or even rubidium frequency standard can be used, but the recommended oscillator is an inexpensive used square wave 10MHz 5V OCXO, which is what I am using in the breadboard prototype. These OCXOs are available from various sources on the net, recycled from decommissioned telecom equipment and sometimes still soldered onto a piece of PCB, for around 10€ or less (< US $12). The OCXO is the most expensive part in this GPSDO.
The second most expensive part is the GPS receiver module. I strongly recommend a u-blox Neo-M8 GPS module with an SMA antenna connector. With a u-blox Neo-M8, I am still getting 5~9 satellites even indoors in my basement cave lab. The much cheaper Neo-M6 struggles to get a fix in the same conditions. :phew:
The open source code in C/C++ (the firmware for the MCU when compiled) and documentation are available on GitHub, here: https://github.com/AndrewBCN/STM32-GPSDO (https://github.com/AndrewBCN/STM32-GPSDO)
Here is the BOM: https://docs.google.com/spreadsheets/d/1BZbZeLiag-d61XXe9ATuPoSe3eMOxMuYYZ0WjF3BLuA/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1BZbZeLiag-d61XXe9ATuPoSe3eMOxMuYYZ0WjF3BLuA/edit?usp=sharing) (updated in March 2022)
New! I posted the latest KiCad schematic revision 0.7.1 (three sheets PDF file) in post #723, page 29 in this thread. A PCB design is in the works and will be available ASAP.
-
Looks like a winner! I assume it puts out 10 MHz. More details please.
Bob
-
I see you are using isotemp in the prototype and in software you also used an osc5a2b02. I have only used the osc5a2b02 as it is very cheap. Do you find the isotemp a better ocxo? I have one osc5a2b02 consistently keeps better than 0.1 ppb but I don't know if that is unusual. I put it down to a good power supply. Do you output the 10MHz anywhere?
-
Hello Bob,
Yes, it uses a (recycled) square wave 5V 10MHz OCXO. The oscilloscope trace is exactly that, taken from the output of the OCXO. The visible ringing is due to a mismatch between the low impedance output of the OCXO and the high impedance of the 10x scope probe, but it doesn't affect the stability of the GPSDO one bit (or one Hz, I could say).
The use of an FLL control loop means that this GPSDO is mostly software-based, and no extra ICs are used (no dividers, no PLL chip, actually not even an op-amp). I am using a 32-bit timer counter in the MCU to do the frequency measurement, and a $1 I2C 12-bit DAC "closes the loop" by providing the frequency control voltage (Vctl) for the OCXO.
The firmware is still in development, but is already functional right now. I am using the Arduino IDE 1.8.13 with the latest STM32 core 2.0.0 package for development. The C/C++ source code for the project is available on GitHub under the GPL V3 license. There was no need for any assembly language code (which is usually an order of magnitude harder to maintain) and the C/C++ source code is copiously commented.
Hello MIS42N,
Yes, I have tested both OCXOs, the Isotemp 143-141 and the CTI OSC5A2B02. They essentially perform the same in terms of stability, but the CTI runs much hotter to the touch.
Depending on the application I would suggest adding a 74HC14 buffer and a coaxial 50 Ohm connector, and eventually an active low-pass filter if one needs a sine wave output.
-
Well then Andrew I hope you intend to give a diagram an maybe even sell a PC board. I already have a rubidium standard but no way to know if it's correct. This could close that gap.
-
I have also been working on a GPSDO. Details here https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/). It started out to see how little was needed to build a respectable system.
In the details of the second build, I show the circuit for output using a 74HC04. This has now been tested, outputs a respectable square wave about 3v p-p into 50 ohm. It was used as the reference for a WSPR receiver, performed well and the tester now wants one.
Build number 3 is in progress. It was pointed out to me that most amateur radio gear runs from 12V so that will be the supply and use a buck converter to get 5V for the OCXO, 74HC04, Line receiver. The PIC16F1455 runs on less than 15mA so it will be supplied from a MAX6350 precision voltage source. I synthesise a 24-bit DAC for the control voltage directly from the output of the PWM, which is dithered at 40kHz. So the stability of the control voltage is dependent on the stability of supply to the PIC. The control voltage seems to be the limiting factor in achieving better figures.
I am not sure if this is abandoning the minimalist approach. If 12V is available 'for free' the main cost was the GPS module and antenna. In Australia this is about $25. The parts cost even for the third build are quite low and I think the major cost will be a case to put it in. Maybe $60 for the lot?
You can expect an OCXO to run hot. It has to be hotter than any expected air temperature. Also the best temperature for SC cut crystals is somewhere near 70C, SC cut is preferred for references as it has a fairly flat C/Hz curve if ovenized. Maybe the Isotemp has better insulation than the CTI. The CTI passes the finger test.
-
Hello Bob,
Yes indeed, a BOM, a circuit diagram and a PCB design are coming ASAP.
EDIT: link to the BOM https://docs.google.com/spreadsheets/d/1BZbZeLiag-d61XXe9ATuPoSe3eMOxMuYYZ0WjF3BLuA/edit?usp=sharing
Hello MIS42N,
Nice work!
-
So I went ahead and wired a second prototype on a second breadboard, and below is a picture of both the original GPSDO prototype spread out on two breadboards, and the second prototype with a more compact layout.
The big difference between the two prototypes, apart from the layout, is in the power supply: the first prototype derives its power entirely from the USB connection to my development laptop, using the USB C connector on the STM32F411CEU6 Black Pill development board, whereas the second prototype uses a +5V and +3.3V power supply board attached to the end of the breadboard.
Both prototypes use a u-blox Neo-M8 GPS module, and both get a position fix in a few minutes from a cold start, even in the less-than-ideal conditions in my basement cave lab. And both achieve a stable +/- 1ppb 10MHz signal within a couple of hours of being turned on.
I am also including a picture of the OLED display with the various fields explained.
And finally: I just pushed version v0.03b of the firmware to GitHub. This is the first version that implements a command parser, and I intend to implement a full set of commands to allow for complete control of the GPSDO using either the USB serial or the Bluetooth serial interfaces, making it compatible with LadyHeather and TimeLab. The command parser really opens up a wealth of possibilities for this project.
-
Looks good so far. I keep reading to see at what point I think I could build this. The software aspect intimidates me. When the board is available I definitely want one. In fact, the whole kit of parts would make life easier for me, since it reduces to assembly and test, without shopping for parts.
-
Good work. We seem to be in parallel universes. Yesterday I adapted one of my GPSDO to run off a 12V wall wart, with a buck converter to supply 5V. Now the whole kit is connected with standard connectors, barrel connector for supply.
I too implemented a command interface but not complex. The only dynamic value the software needs is the V/Hz value for the control voltage and it is read from non volatile memory. If the value is unknown, the software does a calibration run to determine it. So the user doesn't need to do anything. The state is shown by the one LED - a short flash every second says it is running better than 1 ppb. Which is about all the user needs to know. I have a serial interface, it can be set to pass through so the NMEA data can be seen. My thinking is some people just want a simple setup that works, and one LED can do that.
-
What I want is a simple setup that gives me 10 MHz to either compare my counter OCXO or, better, substitute for it.
-
Hello Bob,
The software part is in fact the most enjoyable part of this project for me personally. The big advantage from using a powerful 100MHz 32-bit ARM MCU (with hardware floating point!) is that I can program it in C/C++ and use all the Arduino libraries without any worries about exceeding the capabilities of the MCU.
Also, the hardware is very simple to put together on a breadboard, in fact if one has all the components available, it can be done in an afternoon, and flashing the STM32F411CEU6 MCU takes a few seconds at most from the Arduino IDE.
I haven't started working on the circuit diagram or the PCB yet, but ASAP.
To what precision do you want to calibrate your frequency counter OCXO and/or your rubidium oscillator? Do you have the pinout and/or the technical specs for both?
Hello MIS42N,
I read your impeccable project documentation and I really admire your work, it seems you have a deep understanding of the practical aspects of GPSDO design. I also tried to understand your PIC assembly language firmware for your GPSDO but that was way beyond my capabilities, even though you provide a good description of how it works and ties to your hardware design.
It's very impressive how you managed to fit all that functionality in 4,000 lines of PIC assembly language!
I have one suggestion: ditch the u-blox Neo-M6 GPS module and spend around 10€ to get a much better u-blox Neo-M8 module instead, I have found that it makes a huge difference with getting a position fix and satellite reception in less than ideal conditions.
Compared to yours, my design is oriented toward using standard off-the-shelf modules and easy to understand and maintain C/C++ code. So I would say it's more beginners friendly. But in the end, both projects achieve exactly the same: a stable 10MHz frequency standard with 1ppb accuracy.
Attached pictures:
1. The 10MHz signal from the OCXO "cleaned out" ouput by adding a 220R resistor in series, this greatly reduces the excessive ringing, compared to the previous oscilloscope trace.
2. I have disassembled the first protoype and I am rewiring it in a more compact way so that it fits on a single breadboard. Without the wires it's easier to distinguish the modules in my GPSDO design.
-
I have one suggestion: ditch the u-blox Neo-M6 GPS module and spend around 10€ to get a much better u-blox Neo-M8 module instead, I have found that it makes a huge difference with getting a position fix and satellite reception in less than ideal conditions.
You are probably right. I see you are using a patch antenna, I could not get decent reception in the house anywhere using a patch antenna and even with the puck antenna there were only a few places. Instead of ditching the Neo-6 module I decided to put it where there is a good signal and bring the NMEA and 1pps using line driver/receiver through an Ethernet cable to the GPSDO. A different solution but it works. I've had it set up with the GPS module over 30 meters from the GPSDO with no problems. I'm getting 10-12 satellites many over 40dB so 30 seconds from cold start to fix.
I might revisit the GPS module after I build V3 GPSDO. Design is complete, power supply is sort of working, just need to put it together. I have all the parts (you may notice I don't use a lot of parts). I used a really cheap buck converter to get 5V from 12V (really any input from 9V to 20V should work). It was very difficult to set the pot to 5V so I reverse engineered the circuit to see if there was something wrong. It actually followed the reference design quite closely, except the output voltage is set by varying a potentiometer. The value for 5V is around 35kohm, the pot is 200kohm so only working near the low end. I shall try and parallel it with a 47kohm tomorrow, should make for easier adjustment.
I did try to use C, maybe too early as it was hard to get programs to fit the memory. Now these 32 bit systems are cheap, it is a lot easier. The assembler is a bit of a hobby, I like how precisely things can be controlled. It does however make for a lot of work. I was thinking recently that perhaps I could put just the basic functionality in a PIC processor and have it communicate with another processor to do the grunt work. It would be quite easy, the two devices could chat using the serial interface. The essential PIC part is timing the arrival of the 1pps, and synthesising the 24 bit DAC from the 10 bit PWM. That's probably less than 100 lines of code.
But for the moment, stick to what already works.
-
I am using a 32-bit timer counter in the MCU to do the frequency measurement, and a $1 I2C 12-bit DAC "closes the loop" by providing the frequency control voltage (Vctl) for the OCXO.
Nice project!
If you want a really good short term stability and no adjustments, 12 bits is not enough, you need at least 16 bits.
I also used a sine wave OCXO in my Lars GPSDO. It is way cleaner spectrum wise than the square wave.
-
...
But for the moment, stick to what already works.
Absolutely! In any case, nice work, and I do appreciate your minimalist and original approach.
-
I am using a 32-bit timer counter in the MCU to do the frequency measurement, and a $1 I2C 12-bit DAC "closes the loop" by providing the frequency control voltage (Vctl) for the OCXO.
Nice project!
If you want a really good short term stability and no adjustments, 12 bits is not enough, you need at least 16 bits.
I also used a sine wave OCXO in my Lars GPSDO. It is way cleaner spectrum wise than the square wave.
Hello Miti,
Thank you! I could generate the Vctl for the OCXO using the PWM capabilities of the STM32F411CEU6 (it has a 16-bit PWM mode), that's actually on my (long) list of things to try. The 12-bit I2C DAC I am using right now was readily available and with a negligible cost (€0.50), so I went with that.
And no doubt a sine wave OCXO has much fewer harmonics than a square wave one, I guess for amateur radio applications the way to go is with a sine wave OCXO/DOCXO. In my case, I was really looking for the least expensive OCXOs I could find, and these all happen to be used square wave 5V OCXOs pulled from decommissioned telecom equipment.
-
I eagerly await the final (?) design so I can buy the kit and start soldering. I am really a hardware guy, and while I can see what's going on with software, I can't create my own. But it's a hobby, right? And you can't do everything, right?
My initial goal is to have 10 MHz so close that it will be better than my 500 MHz counter that resolves 0.1 Hz. I think that's about 2 parts in 10^10, maybe 0.2 ppb if my math is good. I think the rubidium standard is capable of better than that, so ultimately I'd like to verify its frequency. Both the counter and the standard put out 10 MHz so right now all I do is put them into my analog scope X-Y and see how fast the Lissajous spins. I can set it so it holds position for a few minutes but when I come back a few months later it has drifted. With the GPSDO I wouldn't even have to test it, but just use it. I would use the latter in place of the internal OCXO of the counter, rather than try to zero beat. That would make my rubidium unit superfluous.
So my BC-221 is ready for a collector.
I remember building a frequency meter in the 1970s that was about as accurate as one could want, but somewhat laughable today.
-
So I went ahead and built a third GPSDO, again on a breadboard. The hardware is almost identical to the first two, and so it performs exactly the same: with 5 or more satellites in view for a few hours, I get 10MHz +/- 1ppb. The only thing that has changed is that I have now tested three different OCXOs, one from CTI (Chinese company), one from IsoTemp (US company, but I think they are assembled in Singapore), and one from NDK (Japanese company). They all perform exactly the same.
I think this validates one of my design objectives, which was to get acceptable performance "out of the box", without any adjustments or fiddling with component values. By not spending time on the hardware, I can spend more time on the software, and that is exactly what I did these last few days.
I uploaded to GitHub* Version v0.03e of the STM32 GPSDO firmware which implements a 64-bit counter (tested and working) and 64-bit ring buffers, and also provides a PWM signal with 16-bit resolution, which I still have to test and see whether it can be used instead of the 12-bit DAC, to control the OCXO frequency. All in all the project is coming along quite nicely.
I have also started working on the circuit diagram in KiCad.
Lastly, one thing I have noticed and I am certain that every GPSDO designer knows well: a GPSDO is only as good as the GPS receiver it uses, and a GPS receiver is only as good as the signal it gets from the antenna. :wtf:
*: The GitHub repository is this one: https://github.com/AndrewBCN/STM32-GPSDO
-
Lastly, one thing I have noticed and I am certain that every GPSDO designer knows well: a GPSDO is only as good as the GPS receiver it uses, and a GPS receiver is only as good as the signal it gets from the antenna.
It's a little more subtle than that. Designs that rely on a Phase Locked Loop perform better when the synchronising signal (usually 1 pulse per second) is accurately timed. If the 1 pps wanders, the loop has to follow. A few people have published the DAC value they are using, and they generally are altering the DAC value every few minutes. To optimise the 1 pps, people are using special timing receivers and require that signal's arrival time to be timed accurately. They also play with aperture settings etc to iron out ionospheric variations.
The other approach is based on the idea that in the short term the synchronising signal wanders a bit but statistically will iron out. As an example, say you have a perfect oscillator and are allowed 2 events to synchronise it. If the signals are known to vary by +-100ns, then taking two events 1 second apart can result in a maximum error of 200ns in 1 second, so the error will be 2 parts in 10E-8. But if you take the readings 3 hours apart (about 10,000 seconds) then the error is 2 parts in 10E-12.
Of course we don't work with perfect oscillators but we can collect a lot of 1 second samples and hope the average is statistically better than the individual sample errors. Then there is a compromise between the sampling length and the oscillator stability.
My design is based on the second approach - use a cheap GPS unit and an approximate arrival time (within 25ns). Then average. My rig is a bit sensitive to external influences so I just let it run overnight with no electronic equipment nearby. This is the result - the 'DAC' (really synthesised from PWM) values are given as a voltage assuming supply is exactly 5V. The DAC only changes when it has to, which is usually a drift of the oscillator by 1 cycle from zero error:
Time 132258 UTC. Ctrl 2.0974806 0.112 ppb
Time 134833 UTC. Ctrl 2.0973743 -0.101 ppb
Time 151352 UTC. Ctrl 2.0973154 -0.056 ppb
Time 153511 UTC. Ctrl 2.0972531 -0.059 ppb
Time 175142 UTC. Ctrl 2.0971912 -0.059 ppb
Time 192533 UTC. Ctrl 2.0971301 -0.058 ppb
Time 201644 UTC. Ctrl 2.0971545 0.023 ppb
However, I agree with the requirement for good reception of satellites. I have tried a few times to use weak signals, the result is disappointing. The GPS 1 pps can wander +- 500ns and that is very hard to work with.
-
Hello MIS42N
It is exactly as you wrote: over a single second the 1PPS signal from the GPS receiver has an accuracy (total error) of roughly +/- 100ns. Which is exactly the period of the 10MHZ OCXO. So any frequency measurement of the 10MHz OCXO over a sample time of 1 second, based on the 1PPS signal from the GPS receiver, whether by means of an analog or digital phase locked loop or a frequency meter, has a maximum resolution of +/- 1Hz (1x10E-7). To get any higher resolution requires averaging the data over a longer sample time, independent of the method used to measure/control the OCXO frequency.
- 10s sample time gives us 0.1Hz resolution (1x10E-8).
- 100s sample time gives us 0.01Hz resolution (1x10E-9 or 1ppb).
- 1000s sample time gives us 0.001Hz resolution (1x10E-10).
- etc.
The problem for GPSDOs based on inexpensive single oven OCXOs is that for measurement sample times beyond around 500s, the OCXO itself can and most probably will randomly drift in frequency by 0.005Hz or so, because of various environmental factors (temperature, atmospheric pressure, electromagnetic noise, etc), even assuming a stable, noiseless, good quality power supply. So imho it hardly makes sense to claim that a $100 GPSDO based on a cheap GPS receiver module and a single oven OCXO has any better performance than 5x10E-10. And that's assuming one has an excellent antenna mounted on top of the roof.
Going for a double oven OCXO (DOCXO) and a high quality power supply will multiply the cost of the GPSDO by 3x to 10x, and supposedly allows one to get an order of magnitude better precision by using an order of magnitude longer sample time (around 5000s max). Or one can go for a rubidium oscillator and that multiplies the cost of the GPSDO by 50x to 100x, but with the recent development of chip-scale atomic clocks, personally I don't think rubidium oscillator based GPSDOs make sense anymore in terms of price/performance ratio.
And again: imho all these considerations on GPSDO accuracy are only valid if your latest generation GPS receiver has a fix and is providing a stable 1PPS, with 6 or more satellites in view, uninterrupted over several days.
-
It is exactly as you wrote: over a single second the 1PPS signal from the GPS receiver has an accuracy (total error) of roughly +/- 100ns. Which is exactly the period of the 10MHZ OCXO. So any frequency measurement of the 10MHz OCXO over a sample time of 1 second, based on the 1PPS signal from the GPS receiver, whether by means of an analog or digital phase locked loop or a frequency meter, has a maximum resolution of +/- 1Hz (1x10E-7). To get any higher resolution requires averaging the data over a longer sample time, independent of the method used to measure/control the OCXO frequency.
- 10s sample time gives us 0.1Hz resolution (1x10E-8).
- 100s sample time gives us 0.01Hz resolution (1x10E-9 or 1ppb).
- 1000s sample time gives us 0.001Hz resolution (1x10E-10).
- etc.
I was only looking at the case where you can take two samples. In reality you can take a sample a second then apply statistics to find a mean value. If the distribution were a bell curve, then the mean of 100 samples has (with 90% confidence) 5 times less error than any individual sample. So if you individual errors are around +- 100ns but you look at the mean of two successive 100 samples, the error in each with reasonable confidence is only +- 20ns, the maximum error is 40ns over 100 seconds giving 0.004Hz resolution rather than 0.01Hz.
I have not been able to find any information of how reliable a single frequency GPS is in the medium term. It is affected by changes in the ionosphere, but I don't know by how much. I used VisualGPS to record a day of data, it says the location coordinates vary by less than 3 meters horizontally. If the 1 pps is derived from the same data, it is about +- 10 ns in time of arrival. With a long sample time it shouldn't have a lot of effect.
The problem for GPSDOs based on inexpensive single oven OCXOs is that for measurement sample times beyond around 500s, the OCXO itself can and most probably will randomly drift in frequency by 0.005Hz or so, because of various environmental factors (temperature, atmospheric pressure, electromagnetic noise, etc), even assuming a stable, noiseless, good quality power supply. So imho it hardly makes sense to claim that a $100 GPSDO based on a cheap GPS receiver module and a single oven OCXO has any better performance than 5x10E-10. And that's assuming one has an excellent antenna mounted on top of the roof.
Check the figures I gave in my last post - many of the readings are less than 0.1 ppb - i.e. better than 1 part in 10E-10. And I am still not sure what is causing that error - may be temperature, ageing, power supply etc. So my limit at the moment seems to be about 6 parts in 10E-11. Part of that is the limit of arithmetic, I had not expected anything much better than 1E-9 but both GPSDOs with OSC5A2B02 OXCO are doing better than 1E-10 most days. So I have to rewrite the control algorithm.
Going for a double oven OCXO (DOCXO) and a high quality power supply will multiply the cost of the GPSDO by 3x to 10x, and supposedly allows one to get an order of magnitude better precision by using an order of magnitude longer sample time (around 5000s max). Or one can go for a rubidium oscillator and that multiplies the cost of the GPSDO by 50x to 100x, but with the recent development of chip-scale atomic clocks, personally I don't think rubidium oscillator based GPSDOs make sense anymore in terms of price/performance ratio.
IMHO a good disciplined DOCXO should be as good or better than a rubidium standard. A rubidium standard disciplines an oscillator using information from the rubidium cell. It is more stable in the short term than GPS, but not as accurate. So I agree, rubidium is too expensive with a shorter lifetime, for maybe no benefit.
And again: imho all these considerations on GPSDO accuracy are only valid if your latest generation GPS receiver has a fix and is providing a stable 1PPS, with 6 or more satellites in view, uninterrupted over several days.
As I mentioned before, I don't see the need for 'latest generation' or high performance GPS if one is willing to accept the short term errors of a basic GPS. They can be reduced to insignificance with statistics. However, no argument with continuous view of satellites. I keep statistics on missing or rejected 1 pps (missing because the GPS unit doesn't report a valid fix in the $GPRMC message; rejected because it arrived outside of a window of acceptance (which I think is +- 400 ns but I'd have to check the program)). Unless I deliberately interfere, there are no errors (in several weeks' data).
-
I was only looking at the case where you can take two samples. In reality you can take a sample a second then apply statistics to find a mean value. If the distribution were a bell curve, then the mean of 100 samples has (with 90% confidence) 5 times less error than any individual sample. So if you individual errors are around +- 100ns but you look at the mean of two successive 100 samples, the error in each with reasonable confidence is only +- 20ns, the maximum error is 40ns over 100 seconds giving 0.004Hz resolution rather than 0.01Hz.
I have not been able to find any information of how reliable a single frequency GPS is in the medium term. It is affected by changes in the ionosphere, but I don't know by how much. I used VisualGPS to record a day of data, it says the location coordinates vary by less than 3 meters horizontally. If the 1 pps is derived from the same data, it is about +- 10 ns in time of arrival. With a long sample time it shouldn't have a lot of effect.
...
U-blox has an Application Note which I believe you'll find interesting: GPS-based Timing - Considerations with u-blox 6 GPS receivers
https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_(GPS.G6-X-11007).pdf (https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_(GPS.G6-X-11007).pdf)
Of particular interest is section 2.1 Accuracy of time pulse.
-
I have just uploaded firmware version v0.03h which fixes various bugs, but most importantly has various improvements in measurements available, reporting and in the commands.
New commands:
- F (Flush) command: flushes the ring buffers.
- Up/Down PWM/DAC fine/coarse adjust commands.
The 64-bit counter is implemented and tested, the new code seems to be working fine and will soon replace the previous, slightly messy 32-bit code.
The 16-bit PWM to generate Vctl to control the OCXO frequency seems to be working well, but further testing is required and ongoing.
And this is what the GPSDO reports on either the USB serial monitor or the Bluetooth serial:
Wait for GPS fix max. 5 seconds...
Fix time 884mS
Uptime: 000d 00:52:11
New GPS Fix:
Lat: 48.~~~~~~ Lon: 7.~~~~~~ Alt: 132.9m Sats: 8 HDOP: 0.90
UTC Time: 06:05:26 Date: 27/5/2021
Vctl: 1.72 DAC: 2177
VctlPWM: 1.78 PWM: 35345
Vcc: 5.05
Vdd: 3.30
Using 64-bit counter implemented in software
Most Significant 32-bit Count (OverflowCounter): 7
Least Significant 32-bit Count (TIM2->CCR3): 1225527159
64-bit Count: 31290298231 Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1000s Frequency Avg: 10000000.000 Hz
BMP280 Temperature = 21.2 *C
Pressure = 1018.8 hPa
Approx altitude = 67.2 m
AHT10 Temperature: 18.16 *C
Humidity: 77.63% rH
And yes, I have implemented a 1000s 64-bit ring buffer that allows 10MHz frequency measurements with a resolution of 0.001Hz (10E-10). Note that I am not claiming an accuracy of 0.001Hz, but a measurement resolution of 0.001Hz over 1000s. Those are two different things.
-
I have just pushed version v0.04b of the STM32 GPSDO firmware to GitHub.
This version is focused on improving the serial Bluetooth communications and general code refactoring. As far as I know, this is the only GPSDO in the world, DIY or commercial, with a Bluetooth interface. :o Many commercial GPSDOs feature an RS-232 DB-9 port or in some cases a GPIB (instrumentation) port, which is fine for their intended purpose, but how many laptops are available these days with an RS-232 serial port, and how much does a GPIB interface cost? On the other hand, there are 4 billion or so smartphones with Bluetooth out there, so...
But enough bragging! Apart from that, I have had the breadboard prototype with the 16-bit PWM Vctl control loop running version v0.03i uninterrupted these days, uptime is 5 days 19 hours right now and this is what it's displaying on the serial monitor:
Wait for GPS fix max. 5 seconds...
Fix time 885mS
Uptime: 005d 19:08:09
New GPS Fix:
Lat: 48.560772 Lon: 7.781876 Alt: 151.2m Sats: 10 HDOP: 1.37
UTC Time: 09:28:08 Date: 3/6/2021
Vctl: 2.25 DAC: 2804
VctlPWM: 1.85 PWM: 35721
Vcc: 5.00
Vdd: 3.29
Using 64-bit counter implemented in software
Most Significant 32-bit Count (OverflowCounter): 1135
Least Significant 32-bit Count (TIM2->CCR3): 732228963
64-bit Count: 4875520109923 Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.01 Hz
1,000s Frequency Avg: 10000000.006 Hz
10,000s Frequency Avg: 10000000.0022 Hz
BMP280 Temperature = 27.2 *C
Pressure = 1020.8 hPa
Approx altitude = 50.9 m
AHT10 Temperature: 23.42 *C
Humidity: 67.47% rH
So far so good, I would say. :-+
I was asked if I wouldn't consider changing the FLL to a PLL, and I would like to comment on that.
1. The use of a PLL, as in Lars' DIY GPSDO or in Brooks Shera original design from 1998 (or in many commercial GPSDOs), requires the use of extra components (ICs, capacitors, resistors), some of which may or may not require calibration and may or may not be temperature and supply voltage sensitive. My FLL is 100% digital and 100% implemented using the flexible 32-bit timers available in the STM32F411 MCU, so it requires zero extra components and is in principle temperature and supply voltage insensitive.
2. Mathematically the frequency and phase closed loops (FLL and PLL) are equivalent in their capacity to control the OCXO frequency, but each has some advantages and disadvantages. The main advantage of the FLL as I implemented it, is that its behavior (response time, avoiding oscillations/overshoot, temperature compensation, aging compensation, etc) is entirely software configurable, meaning that as the firmware improves, so does the quality of the FLL.
3. Finally, when I got started on this project, very early on I was impressed by the elegant implementation of a PLL in Lars' DIY GPSDO, and I thought that it would be rather impossible to improve on his work: it's just as good and as simple as it gets for a 1ns resolution TIC/PLL. So I had two choices: either copy Lars' PLL design or go a completely different way, and I decided on the latter.
I would like to note that if anybody feels like it, she/he can perfectly well stitch together my STM32 GPSDO design and Lars' 1ns resolution TIC. That would take some work to merge Lars' code with mine, but it should not be too difficult, since both code bases are well documented. Personally I have no interest in doing that, I believe Lars' DIY GPSDO project is best left as he originally intended it.
-
You have shot way over my head. I was hoping for a way to build one of these but at this point I think I will give up. It would have been nice to have a module that could substitute for the 10 MHz time base of my counter but alas, I have been left in the dust.
While I understand the basic idea of programming, and have even done some of it, the plethora of languages and complexity of installing (and running) code has me totally wiped out.
-
You have shot way over my head. I was hoping for a way to build one of these but at this point I think I will give up. It would have been nice to have a module that could substitute for the 10 MHz time base of my counter but alas, I have been left in the dust.
While I understand the basic idea of programming, and have even done some of it, the plethora of languages and complexity of installing (and running) code has me totally wiped out.
Bob,
I have been using the Arduino IDE to develop the STM32 GPSDO firmware, it's very user-friendly and can be learned in one afternoon (and it's totally free). But you don't need to learn it to flash the firmware to the MCU module, that's something that requires one-click and 30 seconds! As for assembling the STM32 GPSDO: you can put it together on a breadboard in a couple of hours as long as you have the essential parts at hand. In terms of hardware, I believe the STM32 GPSDO is the simplest design ever: the barebones configuration requires just three modules and a few passive components:
- The GPS module.
- The 10MHz OCXO.
- The STM32F411CEU6 Black Pill module.
- Two 10uF capacitors and two 20k resistors.
-
Okay Andrew I won't give up yet. Give me a schematic diagram and parts list and instructions and I will give it a go, if I think I can do it.
-
Okay Andrew I won't give up yet. Give me a schematic diagram and parts list and instructions and I will give it a go, if I think I can do it.
Bob, the first thing you should do is to install the Arduino program on your computer, because that's what you will need to interface to the STM32 GPSDO and flash the STM32F411CEU6 Black Pill board. It's free software, you can download it from here: https://www.arduino.cc/en/software (https://www.arduino.cc/en/software)
-
I did that some time ago.
-
I did that some time ago.
Good, now the second step: install the STM32 Core 2.0 from GitHub, instructions here: https://github.com/stm32duino/Arduino_Core_STM32/#getting-started
That takes a few minutes as the installation process fetches the ARM compiler and various other packages and installs them.
The next step after that is buying a WeAct STM32F411CEU6 "Black Pill" on AliExpress (WeAct Studio WeiXing Store), and a USB C cable to program it. Total cost less than US$ 8 + shipping.
-
I went to that link but it's unclear to me how to proceed. I will see about buying that thing from AliExpress.
-
I went to that link but it's unclear to me how to proceed. ...
Please follow the instructions with screenshots here: https://github.com/stm32duino/wiki/wiki/Getting-Started
-
Wow that is involved! What does deprecate mean here?
I am hesitant to do this, as I really have no idea what is going on.
-
Wow that is involved! What does deprecate mean here?
I am hesitant to do this, as I really have no idea what is going on.
Deprecate means that was what you did before, it may still work, but the line above is the one you should use. Since you are starting out, ignore the deprecated line.
-
I went to that link and read the instructions a few times. It still leaves me uncertain; some of the language is strange to me. (Maybe it was written outside the USA.) This whole thing is way outside my level of competence. I can generally get by with this computer stuff but when it gets into the nitty gritty of programming and its ancillary activities, I am lost.
I think what I will do is try to find someone who feels comfortable with this. Unless you want to get the chip and load it for me. I will of course pay you for your trouble and hardware.
-
Bob, I can if you want send you a Black Pill with the program flashed, but I can't really recommend that. First because then the MCU becomes a black box for you, and second because the STM32 GPSDO software is evolving very rapidly, and freezing it in time is a really bad idea.
I know at first sight installing the Arduino IDE and the STM32 Core package may seem daunting, I have been through that too.But in the end it's really simple to install the STM32 Core package in the Arduino IDE, just take your time :popcorn: and try to understand the sequence of instructions in the last link I sent you, the one with the screenshots. And don't worry about doing something wrong, there is zero chance of this breaking your PC or starting a fire. :-BROKE
If you really can't find anybody to help you get over this hurdle, I suggest you wait for when I am ready to put together a couple of kits for people to assemble this GPSDO, with a proper PCB and proper instructions. By then I hope the firmware will have stabilized a little bit...
-
So I am working right now on the STM32 GPSDO firmware Version v0.04e, and what's new? Plenty!
1. All the measured voltages are now filtered through a 10 samples moving average.
2. The Bluetooth serial and USB serial outputs are now identical, and consists of the following:
Wait for GPS fix max. 1 second
$GNGSA,A,3,27,10,23,26,18,15,,,,,,,2.30,1.91,1.28*13
$GNGSA,A9,76,38,268,,77,23,327,,84,05,085,,85,57,052,23*61
$GLGSV,3,3,09,86,53,308,*5F
$GNGLL,4833.66284,N,00746.88237,E,134626.00,A,A*72
$GNRMC,134627.00,A,4833.66358,N,00746.88039,E,2.527,,050621,,,A*64
$GNGGA,134627.00,4833.66358,N,00746.88039,E,1,07,1.91,137.7,M,47.3,M,,*46
Fix time 889mS
Uptime: 000d 00:28:44
New GPS Fix:
Lat: 48.xxxxxx Lon: 7.xxxxxx Alt: 137.7m
Sats: 7 HDOP: 1.91
UTC Time: 13:46:27 Date: 5/6/2021
Voltages:
Vctl: 1.97 DAC: 2404
VctlPWM: 1.81 PWM: 35751
Vcc: 5.02
Vdd: 3.29
Frequency measurements using 64-bit counter:
64-bit Counter: 17215439735
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 9999999.99 Hz
1,000s Frequency Avg: 9999999.997 Hz
10,000s Frequency Avg: 0.0000 Hz
BMP280 Temperature = 26.6 *C
Pressure = 1020.0 hPa
Approx altitude = 57.3 m
AHT10 Temperature: 23.57 *C
Humidity: 76.48% rH
This is repeated once per second. The above is with Verbose NMEA option enabled.
-
Andrew, thank you for your patience with this incompetent hobbyist. I did ask a friend for help but so far he hasn't done anything. We shall see.
What I like best is your intent to create a kit to build one of these. My needs are not critical and I am very willing to wait for a more polished setup. As I mentioned, I do have a rubidium standard which suffices for now, although I have no way to verify its accuracy.
I also wonder about the permanence of GPS. They require some maintenance and there may be periods of down time over the years. Also, someone may devise a new, better system.
Nothing is forever.
-
I also wonder about the permanence of GPS. They require some maintenance and there may be periods of down time over the years. Also, someone may devise a new, better system.
Nothing is forever.
I think GPS will outlive us. There are now systems put up by the USA, European union, Russia and China. Any one of them would be adequate. The satellites get replaced when they fail, and each system has redundant satellites. Only 4 satellites are required for a fix, my system rarely has less than 10 in view, usually 12.
I think it will be like the Internet. It is based on concepts more than 50 years old, just gets modified to accommodate new things.
-
That is encouraging. After all, WWV has lasted for many decades and isn't dead yet.
-
Andrew, thank you for your patience with this incompetent hobbyist. I did ask a friend for help but so far he hasn't done anything. We shall see.
...
Bob, don't worry about it. I know it takes a few tries to get over these hurdles, but the main reward is that you learn something new. Which is really my main motivation for this project, it has given me the opportunity to learn so many new things. And I hope it can be likewise for other people: build it and learn lots!
-
Andrew, you keep encouraging me and that isn't a bad thing. But first I need a BOM and a schematic. Once I have that, I can see where I need to buy and where I already have what I need.
Then I can review the procedure until I understand it or ask for help. The actual circuit board would be good.
-
Andrew, you keep encouraging me and that isn't a bad thing. But first I need a BOM and a schematic.
...
Bob, you already have the BOM. https://github.com/AndrewBCN/STM32-GPSDO/blob/main/STM32%20GPSDO%20-%20BOM.pdf :phew:
A KiCad schematic will be available ASAP. However, note that even if you wire the STM32 GPSDO on a breadboard or put it together on a proper PCB from a kit, without the firmware it makes for a rather poor doorstop and nothing else. :-//
There is no way around it: you'll have to learn at least a tiny bit of the Arduino IDE for this project to be of any use to you. Take your time to do it, but do it! :)
-
Well okay it seems the hardware parts add up to a bit over $50. As for my learning experience, it will be fun. I did go through a similar project recently but without success. I need to review the job I did and see if the problem lies with me or the software/firmware (written by someone else). So my confidence level is not too high right now.
-
A very simple video I just uploaded on YouTube about the STM32 GPSDO:
https://www.youtube.com/watch?v=mgoK4KuVDhw (https://www.youtube.com/watch?v=mgoK4KuVDhw)
-
Unfortunately the audio is too weak and I cannot hear what you are saying. But it appears rather complicated with all the boards and wires.
Perhaps I should forget about it. I have too many uncompleted projects already.
-
Unfortunately the audio is too weak and I cannot hear what you are saying.
...
Bob, that's what the captions are for on YouTube videos.
-
Thanks Andrew! I hadn't enabled captions so now I understand what you are saying.
I may purchase the OCXO and see how that works. As for the rest, well my confidence level is low right now. I still would be willing to purchase a working system from you and figure out how it works later.
-
I have just uploaded to GitHub version v0.04g of the STM32 GPSDO firmware, and the big news is that this version implements an auto-calibration algorithm for the OCXO.
In previous versions of the firmware, any new OCXO had to be tested/characterized first before the firmware was compiled with an initial Vctl so that the frequency locked loop wouldn't take ages to reach 10MHz +/- 1ppb.
This auto-calibration takes just 30 seconds to run and calculates an approximate initial Vctl for 10MHz +/- 10ppb. :-+
-
I am unsure of the role the OCXO plays. I would think the GPS signal would enable creation of the 10 MHz without the need for a separate oscillator. I guess that isn't the case.
So if the OCXO is locked within 10 ppb, how does that help get the unit within 1 ppb?
-
I am unsure of the role the OCXO plays. I would think the GPS signal would enable creation of the 10 MHz without the need for a separate oscillator. I guess that isn't the case.
No, the GPS gives us a 1PPS (1Hz pulse) signal, which is used to precisely measure the frequency of the OCXO every second. It is the OCXO that gives us a stable 10MHz square wave signal.
So if the OCXO is locked within 10 ppb, how does that help get the unit within 1 ppb?
That's a very good question.
Let's assume we have assembled the STM32 GPSDO on a breadboard with a 5V square wave OCXO that was bought on AliExpress. These are used, recycled OCXOs that cost <$10. They have a frequency control pin that allows adjusting the frequency by around +/- 20Hz by varying the voltage applied to that pin between 0 and 4V. We call that voltage Vctl.
So roughly speaking the frequency of the OCXO can be varied around 10MHz by adjusting Vctl, with a slope of 10Hz per Volt, or 0.01Hz (1ppb) per millivolt. Calibration means finding the Vctl(e) that sets the OCXO to 10MHz +/- some arbitrary error e. This Vctl(e) is unique to each and every OCXO, so it has to be determined experimentally.
What the auto-calibration procedure does is, in 30 seconds, it finds the correct value for Vctl that brings the OCXO within 0.2Hz (20ppb) of its nominal 10MHz frequency; we can call it Vctl(20ppb). At this stage the FLL (frequency locked loop) takes over and further fine-tunes Vctl to bring the OCXO within 0.01Hz (1ppb) or 0.001Hz (0.1ppb) (when used with the 16-bit PWM software DAC) of its nominal 10MHz frequency. This fine-tuning process can take up to 2 or more hours, but it would take much longer without the prior auto-calibration.
-
This is the CETC CTI OSC5A2B02 10MHz square wave OCXO that I am using, usually available for < $10 on AliExpress.
Top and bottom pictures with pinout and a datasheet in Chinese.
-
This is the CETC CTI OSC5A2B02 10MHz square wave OCXO that I am using, usually available for < $10 on AliExpress.
I bought 10 used ones on ebay for $40AU (about $3 ea US). I've used 4 and all are better than 10MHz+-0.001Hz (0.1ppb) after a week burn in. They are about 0.1V/Hz pulling which means with a 16 bit DAC the control is in steps of 0.07 ppb. There's not much point in using a better OCXO unless using better than a 16 bit DAC (with suitably stable power). I think they are great value.
-
This stokes me up once again. But I am still intimidated by the project. All advice and other kinds of help appreciated.
-
This stokes me up once again. But I am still intimidated by the project. All advice and other kinds of help appreciated.
Wait until you are building. At the moment it's like trying to get you to learn to drive a car when all you have is a picture of a car. Much easier with you sitting in the car. At worst you are going to blow $100 and end up with a lemon. But you will learn a lot along the way. At best you love your hand built GPSDO because it does what is supposed to do and you built it.
Or you can skip the learning, go buy a ready built unit.
In reply to your 'is an OCXO required' - no, there are GPS modules that will output 10MHz directly. It has a lot of short term jitter, good enough to calibrate a counter with a long gating period but could not be used as the frequency base for a transmitter. The job of the OCXO is like a flywheel, smoothing the short term jitter. The fun bit is seeing how well those jitters can be eliminated. Andrew and I are using completely different methods to achieve the same end. Swings and roundabouts.
-
Since all the BOM items are sourced from AliExpress, I went there and tried to find the parts. I had mixed success. In some cases (notably the MCP4725) the shipping cost exceeded the item price. In a few cases, the 10 MHz oscillator was offered as a package of two, tempting me to go that route to avoid later trouble in case of failure. Or offering a replacement module for some other gear.
What does the display show? Is it something good to have? Same question about bluetooth. The temp and humidity and current/voltage and pressure sensors don't seem to add much to the functionality.
I have all the parts for the power supply as well as a bunch of LEDs and a great assortment of capacitors and resistors.
-
Since all the BOM items are sourced from AliExpress, I went there and tried to find the parts. I had mixed success. In some cases (notably the MCP4725) the shipping cost exceeded the item price. In a few cases, the 10 MHz oscillator was offered as a package of two, tempting me to go that route to avoid later trouble in case of failure. Or offering a replacement module for some other gear.
What does the display show? Is it something good to have? Same question about bluetooth. The temp and humidity and current/voltage and pressure sensors don't seem to add much to the functionality.
I have all the parts for the power supply as well as a bunch of LEDs and a great assortment of capacitors and resistors.
Bob,
The OLED display (picture on first page of this topic explaining what it shows), all the sensors, the MCP4725 DAC and the Bluetooth module are all OPTIONAL meaning the STM32 GPSDO will operate with or without them. It's up to you to decide if you want to spend another $10~$15 for these parts or not.
The essential can't-do-without parts are:
- The WeAct STM32F411CEU6 Black Pill development board. Around $7 + shipping.
- The 10MHz 5V square wave OCXO. Around $10 + shipping.
- The u-blox Neo-M8 GPS module and an antenna. Around $9 + shipping.
And of course a standard breadboard and the wires to assemble the GPSDO, and you'll also need a USB C cable to program the MCU.
Again, the first and most essential part you need to buy as a first step is the STM32F411CEU6 development board, and then install on your PC both the Arduino IDE and the STM32 Core 2.0 package and make sure you can upload the program to the MCU. That's 90% of putting together this project in these simple steps that should take you no more than 10 minutes of your time.
-
Okay Andrew that seems simple enough. I will order the parts I need. Probably will get them in July sometime. I have a USB C cable.
I am particularly interested in the OCXO and likely will get two of them.
-
I ordered the OCXO and the STM32 but can't locate the U-blox Neo-M8 module with antenna. Help please.
-
Bob,
Picture of the recommended GPS module attached below. It is available from a number of sellers on AliExpress, a search for "Neo-M8" on AliExpress will quickly show you a dozen results or more.
I cannot recommend any particular seller, but this one seems to have that module for a good price: WAVGAT Official Store. Make sure you order the Neo-M8 module.
Note this module does not come with an antenna, so you also need a GPS antenna with an SMA connector. Search for "GPS antenna SMA" on AliExpress or Amazon. The least expensive antennas usually look like a small "puck" at the end of a coax cable, picture attached below.
-
I couldn't find the one you suggested but will this one do?
https://www.aliexpress.com/item/4000657237507.html?spm=a2g0o.productlist.0.0.8bcb3497WMXu23&algo_pvid=17814730-b359-4b13-8428-03d5023426ff&algo_exp_id=17814730-b359-4b13-8428-03d5023426ff-0 (https://www.aliexpress.com/item/4000657237507.html?spm=a2g0o.productlist.0.0.8bcb3497WMXu23&algo_pvid=17814730-b359-4b13-8428-03d5023426ff&algo_exp_id=17814730-b359-4b13-8428-03d5023426ff-0)
And this antenna?
https://www.aliexpress.com/item/1005002073324329.html?spm=a2g0o.productlist.0.0.383543336GT6g1&algo_pvid=446a5c2c-d222-4e83-b88d-9d9e7f67d942&algo_exp_id=446a5c2c-d222-4e83-b88d-9d9e7f67d942-9 (https://www.aliexpress.com/item/1005002073324329.html?spm=a2g0o.productlist.0.0.383543336GT6g1&algo_pvid=446a5c2c-d222-4e83-b88d-9d9e7f67d942&algo_exp_id=446a5c2c-d222-4e83-b88d-9d9e7f67d942-9)
-
Yes and yes. For the antenna: make sure to choose the one with the gold metallic SMA connector, NOT the one with the plastic blue Farka connector.
-
Orders all placed. I expect delivery in about a month. Four items, the oscillator, gps module, antenna, and stm module. I bought an extra oscillator to play with.
When I am ready to program, I will post here for detailed instructions. I have programmed an arduino once, with some guidance, so it's not entirely strange.
-
I scanned the entire thread and didn't see the code to upload to the STM. Where do I find that?
-
I scanned the entire thread and didn't see the code to upload to the STM. Where do I find that?
Bob,
I am sure I wrote this before, but all the STM32 GPSDO source code is freely available in my GitHub repository, here:
https://github.com/AndrewBCN/STM32-GPSDO
Download the latest release zip file, unzip it and you should be good to compile and flash.
-
I downloaded what I think is the program in a zip file, gpsdo.imo.
Once I get the hardware I guess I have to see how to put that file into the unit. Presumably a USB cable and some steps with the arduino program.
I appreciate your patience with me. I alternately feel totally lost and happily doing things.
I expect the hardware to arrive in July. It will be fun to learn a new procedure, especially if it works.
It's kind of reinventing the wheel for me, as my rubidium standard is probably overkill for my needs as it is. If the two references disagree, I will then have to decide which is closest to the 'right' frequency.
-
Andrew, did you finish the schematic diagram yet? I have the oscillator and the gps unit. The antenna and STM module should be here presently.
-
Andrew, did you finish the schematic diagram yet? I have the oscillator and the gps unit. The antenna and STM module should be here presently.
Not yet, no, but you won't need a schematic diagram for now.
First things first: you need a 5V power supply, a breadboard, wires and a red or orange LED and a 330R resistor. And a USB C cable and the STM32F411CEU6 Black Pill. Also a PC with the Arduino IDE installed. Also needed for testing: 2 x 4.7k resistors, and an oscilloscope which I believe you have?
Then we can already test the 10MHz OCXO. Tell me when you are ready and we can get started testing things out.
-
I have everything but the black pill, which should arrive in a day or two. Oh, and the antenna hasn't arrived either. I have all the other stuff.
-
I have everything but the black pill, which should arrive in a day or two. Oh, and the antenna hasn't arrived either. I have all the other stuff.
OK, so you can already test the OCXO. To insert it into the breadboard you need to solder longer leads to the 5 short leads of the OCXO, I suggest adding 5mm long leads. Then power it up (5V) and check that it is generating a square 10MHz TTL signal with your scope.
I posted the pinout of the OCXO here: https://github.com/AndrewBCN/STM32-GPSDO/tree/main/docs/pictures
Please include a picture of your test setup in your next post.
-
I have had the OCXO for some time and it has been tested. I found that it takes 2.36 V to bring it on frequency, and it's both very stable and quick to stabilize. The square wave has a bit of overshoot but looks good.
These OCXOs do not arrive by themselves. They are already mounted on a piece of circuit board that has been cut from a larger board. So connecting is easy, as the pins have been soldered already.
I ran mine on 5V and, when first connected, draws about 660 mA but shortly settles to about 180 mA.
-
Well done. Are you going to desolder the OCXO from the sawed off piece of PCB it came soldered on, or leave it as is? :-/O
-
My inclination is to leave the oscillator on the board fragment. It gives it more stability and the risk of damage is less.
No mail yet today but I am confident that the STM black pill will arrive shortly. The antenna as well.
-
OK, so I finally found some time to draw the schematic for the minimal configuration (no OLED display, no sensors, no Bluetooth module, no buffers, etc) for the STM32 GPSDO. This took a lot longer than I thought, because I had to create my own KiCad symbol for the WeAct STM32F411CEU6 "Black Pill" module, and also for the OCXO. :phew:
Attached is the KiCad schematic exported as a jpeg PDF file.
I'll soon update the GitHub repository with all the KiCad files.
-
The diagram is almost unreadable. After considerable mofification of contrast etc. I finally got something I can read but the callouts are blurred. Does the lead on the far right connect to the black pill? After I build it, what is the next step?
-
The diagram is almost unreadable. After considerable mofification of contrast etc. I finally got something I can read but the callouts are blurred. Does the lead on the far right connect to the black pill? After I build it, what is the next step?
Bob, sorry for the unreadable KiCad schematic export, the colors came out wrong for some reason.
I'll post a more readable jpg PDF export of the schematic ASAP. (DONE! I re-exported the schematic as a PDF file and it's 1000x easier to read now)
Before you assemble the parts as per the schematic, I suggest you become familiar with flashing/uploading the firmware to the STM32F411CEU6 Black Pill module and communicating with it using the Arduino IDE Serial Monitor. This requires of course the STM32 module and a USB-C cable.
-
I don't have the STM32 module yet. What's the best resource for learning how to install the firmware? I don't even know the basics, such as can you overwrite whatever firmware is already installed, and can you make little changes to it, stuff like that. It's a totally new subject for me and I am totally clueless.
Actually I think I once installed firmware in an arduino module but have forgetten what I did or how I did it.
We each have our strengths and weaknesses, and this is one area in which I am woefully weak. I can design analog circuits and troubleshoot them but show me a digital setup and all I can do is scratch my head.
-
I'm build a combination of Lars GPSDO (the phase detector) and a SI5351 with a TCXO instead of a Xtal and special drivers to enable 1/1000 Hz frequency control instead of a VCXO
Now it's all working but I have no means to measure the accuracy.
The arduino SW outputs the absolute frequency to which the SI5351 is set to output the target frequency of 10MHz (blue trace) and it outputs the correction it made (red trace)
(http://[attachimg=1])
The corrections are well below 1e-8 and the absolute frequency is also stable within 1e-8 (no drift)
Can I assume the GPSDO is stable within 1e-8 or am I fooling myself?
-
I don't have the STM32 module yet. What's the best resource for learning how to install the firmware?
...
There are various blogs with detailed instructions on using the Arduino IDE to flash/upload the firmware to STM32 boards, here are a couple of links:
1. https://www.sgbotic.com/index.php?dispatch=pages.view&page_id=49 (https://www.sgbotic.com/index.php?dispatch=pages.view&page_id=49)
2. https://blog.hobbycomponents.com/?p=758 (https://blog.hobbycomponents.com/?p=758)
I suggest reading link 2 as it has detailed instructions.
-
The diagram is almost unreadable. After considerable mofification of contrast etc. I finally got something I can read but the callouts are blurred. Does the lead on the far right connect to the black pill? After I build it, what is the next step?
That was before it was a PDF I guess? The PDF reads perfectly.
-
I'm build a combination of Lars GPSDO (the phase detector) and a SI5351 with a TCXO instead of a Xtal and special drivers to enable 1/1000 Hz frequency control instead of a VCXO
...
The corrections are well below 1e-8 and the absolute frequency is also stable within 1e-8 (no drift)
Can I assume the GPSDO is stable within 1e-8 or am I fooling myself?
Hi Erikka,
It sounds like you have a very nice design for a GPSDO. :-+
And you are faced with the same problem as all GPSDO designers and experimenters: to measure the accuracy and stability of a clock, you need... a better clock! ;)
Unfortunately, it's impossible to answer your question without more details on how your circuit and software are configured, but as far as I can tell from the graph you posted, it seems your GPSDO is indeed stable.
I would suggest you create a thread in this forum for your modified Lars' GPSDO and share the details of your design.
There is also the time-nuts mailing list where maybe you may get some expert advice. http://www.leapsecond.com/time-nuts.htm (http://www.leapsecond.com/time-nuts.htm)
-
And you are faced with the same problem as all GPSDO designers and experimenters: to measure the accuracy and stability of a clock, you need... a better clock! ;)
Maybe not. Stability is part of the specification of the oscillator. Usually specifies sensitivity to supply voltage, temperature and load variations. So if you are confident that those are under control, then you should get the specified stability.
Accuracy is not so easy. In the long term, a locked oscillator (one that generates on average 10M cycles for every 1pps) is accurate, because the 1pps (in the long term) is locked to NIST standards. If the sensitivity of the oscillator to the control voltage is known, and the assumption is made that all adjustments of control voltage are to compensate for inaccuracy (and therefore make the oscillator more accurate) then the change in control voltage can be converted to a change in frequency. In a locked oscillator that change should be larger than the frequency error, because it corrects the frequency inaccuracy and also returns the oscillator to sync with the 1pps. An example - if control voltage comes from a 16 bit DAC with 0-5V output, then each step is around 76uV. If the DAC value is changed by 1, and the sensitivity is 0.1V/Hz, then the frequency change is 760uHz. At 10MHz that's 0.76 parts in 10E-10. So the DAC change tells you roughly the accuracy. There is a caveat. Only if the DAC is changes at infrequent intervals (minutes). At shorter intervals the 1pps jitter and changes in satellite constellation contribute some short term inaccuracy. Which is why people like phase lock loops with long time constants like 20 minutes.
-
And you are faced with the same problem as all GPSDO designers and experimenters: to measure the accuracy and stability of a clock, you need... a better clock! ;)
Maybe not. Stability is part of the specification of the oscillator. Usually specifies sensitivity to supply voltage, temperature and load variations. So if you are confident that those are under control, then you should get the specified stability.
Accuracy is not so easy. In the long term, a locked oscillator (one that generates on average 10M cycles for every 1pps) is accurate, because the 1pps (in the long term) is locked to NIST standards. If the sensitivity of the oscillator to the control voltage is known, and the assumption is made that all adjustments of control voltage are to compensate for inaccuracy (and therefore make the oscillator more accurate) then the change in control voltage can be converted to a change in frequency. In a locked oscillator that change should be larger than the frequency error, because it corrects the frequency inaccuracy and also returns the oscillator to sync with the 1pps. An example - if control voltage comes from a 16 bit DAC with 0-5V output, then each step is around 76uV. If the DAC value is changed by 1, and the sensitivity is 0.1V/Hz, then the frequency change is 760uHz. At 10MHz that's 0.76 parts in 10E-10. So the DAC change tells you roughly the accuracy. There is a caveat. Only if the DAC is changes at infrequent intervals (minutes). At shorter intervals the 1pps jitter and changes in satellite constellation contribute some short term inaccuracy. Which is why people like phase lock loops with long time constants like 20 minutes.
It is just the other way 'round. Accuracy is easy, but stability is difficult to assess.
-
And you are faced with the same problem as all GPSDO designers and experimenters: to measure the accuracy and stability of a clock, you need... a better clock! ;)
Maybe not. Stability is part of the specification of the oscillator.
...
Yes, of course both stability and accuracy are part of the specifications of the oscillator and various other components in a GPSDO. But specifications are not measurements. So I stand by my earlier statement: if you want to measure the accuracy and stability of a clock to within any error margin, you need a clock with an accuracy and stability that both exceed that error margin i.e. an even better clock as a reference! BTW that is the entire rationale behind the development of ever more accurate atomic clocks and the very reason GPSDOs exist, since a GPSDO is nothing more than a local clock/oscillator that uses three or more very remote atomic clocks as references (the ones onboard GPS satellites)! :-/O
-
To access the stability I may be able to use a SSA3021X+ at 1GHz using the 100th harmonic of 10MHz.
As the absolute frequency error of the SSA3021X+ is specified as <1PPM it is not possible to be sure about the absolute frequency.
But once the TCXO in the SSA3021X+ is stable (after 40 minutes according to the spec) the 100Hz minimum span and 1Hz RBW should show easily the 1e-8 boundary as +/- 10Hz so if the 10MHz harmonic at 1GHz is stable within +/- 10Hz on the SA both the SA and the GPSDO should be stable within 1e-8, correct?
-
To access the stability I may be able to use a SSA3021X+ at 1GHz using the 100th harmonic of 10MHz.
...
Erikka,
There are simpler ways to measure the stability and accuracy of your GPSDO, and again: they all involve using a better clock as a reference.
1. You can compare your GPSDO to the atomic clock DCF77 radio signal from Mainflingen.
2, You can take your GPSDO to a lab equipped with an atomic clock or a calibrated rubidium clock.
3. You could use the three-cornered hat method, which requires two more clocks.
4. You could use another GPSDO with known performance parameters as a reference. (that is the weakest option from all four, but it's also the cheapest)
Before you get started on any of these, I would suggest you ask yourself exactly what you are trying to measure, why it matters, and familiarize yourself with the concepts of Allan variance / Allan deviation.
Here are some links:
1. http://www.wriley.com/3-CornHat.htm (http://www.wriley.com/3-CornHat.htm) APPLICATION OF THE 3-CORNERED HAT METHOD TO THE ANALYSIS OF FREQUENCY STABILITY
2. DCF77: https://en.wikipedia.org/wiki/DCF77 (https://en.wikipedia.org/wiki/DCF77)
3. CLOCK CHARACTERIZATION TUTORIAL by Dr. Allan himself https://tf.nist.gov/general/pdf/2082.pdf (https://tf.nist.gov/general/pdf/2082.pdf)
Just one last note: in general, in a correctly designed GPSDO with an active GPS lock, the long-term (over 1000s) stability is the same as that of the atomic clock on GPS satellites (excellent), and the short term (under 1000s) stability is the same as that of the OCXO (very good) or TCXO (good/acceptable) used in the GPSDO. And that is very easy to verify.
-
AndrewBCN
Thanks for the excellent info.
My goal is a good lab frequency reference, at least 1e-8 accuracy (10Hz error at 1GHz) but preferably 1e-9 (1Hz error at 1GHz)
Furthermore this should be reached well within 10 minutes as I do not want to have my lab powered all the time.
Therefore I did not want to go for very long integration times and choose for the phase detector approach
After updating the phase detector I've reached 1e-9 short term frequency stability (40 seconds measurement interval)
The neo-7M PPS has 22ns fractional time uncertainty. Averaging over 40 seconds gives 0.5ns accuracy in the PPS so 1e-9 should be correctly measured (I hope)
Looking at the 1GHz harmonic of the 10MHz output on a SSA3021X+ shows no visible jumps or drift (after the SSA has warmed up) . This is option 4 of your proposed verification
Here is the latest run. Corrections (red trace) every 40 seconds are below 1e-9, which is reached after only 5 minutes
(http://[attach=1])
-
And here is the spectrum analyzer measurement of the 1GHz harmonic over about 10 minutes
The variations of the 1GHz harmonic are all within 2Hz
(http://[attach=1])
-
AndrewBCN
Thanks for the excellent info.
My goal is a good lab frequency reference, at least 1e-8 accuracy (10Hz error at 1GHz) but preferably 1e-9 (1Hz error at 1GHz)
Furthermore this should be reached well within 10 minutes as I do not want to have my lab powered all the time.
...
Most GPSDOs provide better than 10E-9 accuracy and stability as described earlier, however most phase locked loops (PLLs) are tuned for longer time constants than 10 minutes, and that's after GPS lock acquisition, OCXO warming and calibration which all take some time. Your 10 minutes requirement also means you'll need a good rooftop GPS antenna.
In the case of my FLL-based STM32 GPSDO, 10E-9 frequency accuracy is achieved after a few (typically 4, if properly configured) 100s measurement cycles after GPS lock acquisition, OCXO warming and initial calibration (another 60s to 120s).
That spectrum analyzer is a very impressive instrument!
-
Most GPSDOs provide better than 10E-9 accuracy and stability as described earlier, however most phase locked loops (PLLs) are tuned for longer time constants than 10 minutes, and that's after GPS lock acquisition, OCXO warming and calibration which all take some time. Your 10 minutes requirement also means you'll need a good rooftop GPS antenna.
Thanks for the hint. Yes I have a rooftop GPS antenna.
What would be the reason for having a PLL loop time constant of 10 minutes? Is this because the temperature/pressure/whatever variation on a good OXCO are anyway slower? The TCXO I'm using even reacts to me getting close to it as its all still all open on the bench, let alone if I dare to breath close to it
-
If you followed the discussions on Lars thread, good OCXOs will allow time constants of over 1000 seconds, if you keep them nicely shielded from external temperature changes and air drafts.
-
...
What would be the reason for having a PLL loop time constant of 10 minutes? Is this because the temperature/pressure/whatever variation on a good OXCO are anyway slower? The TCXO I'm using even reacts to me getting close to it as its all still all open on the bench, let alone if I dare to breath close to it
In any control loop, there is a time constant, which has to be optimized either by design or empirically.
As you have intuited, the reason for a long (several minutes) time constant for the PLL in GPSDOs is not because of temperature variations. I believe it is because the analog portion of the PLL control loop in most GPSDOs is designed to adjust the oscillator frequency by very small increments, as MIS42N calculated in his example, so the PLL requires a very long time constant to remove the "noise" from the GPS reference signal and avoid small oscillations in the output frequency.
Since you have read and modified Lars' code, you probably have noticed that he has a configurable time constant for his PLL control loop.
Which again brings me back to my 100% software configurable FLL: the time to achieve any given oscillator frequency accuracy only depends on the sophistication and performance of the control algorithm, and the fundamental resolution of measuring any frequency over a given time interval.
-
the PLL requires a very long time constant to remove the "noise" from the GPS reference signal and avoid small oscillations in the output frequency.
Thanks again for the hint. I measured the noise in the PPS versus the TCXO and its actually very small. The biggest excursion you see is the 22ns jumps up and down to build the fractional timing for the PPS
The measurement, one every second, shows the delta time between PPS in 0.5ns accuracy, you can see the drift of the oscillator in the NEO-7M but this is nicely corrected by adding/removing 22ns every so PPS pulses
(http://[attachimg=1])
It seems the biggest reason to do averaging of the PPS is to get rid of the 22ns increment/decrementing.
-
the PLL requires a very long time constant to remove the "noise" from the GPS reference signal and avoid small oscillations in the output frequency.
Thanks again for the hint. I measured the noise in the PPS versus the TCXO and its actually very small. The biggest excursion you see is the 22ns jumps up and down to build the fractional timing for the PPS
The measurement, one every second, shows the time between PPS in 0.5nns accuracy, you can see the drift of the oscillator in the NEO-7M but this is nicely corrected by adding/removing 22ns every so PPS pulses
(http:// (Attachment Link) )
It seems the biggest reason to do averaging of the PPS is to get rid of the 22ns increment/decrementing.
That's very interesting. Perhaps that recurring 22ns "noise" is quite simply the resolution of the NEO-7M which I believe is clocked at 48MHz? So by design the 1PPS pulse from the NEO-7M GPS receiver cannot have a resolution higher than 1/48MHz ~= 21ns to which you must add the approx, 1ns resolution of Lars' circuit, so you get 22ns?
Unfortunately Lars is not among us to share his deep knowledge of these questions...
-
That's very interesting. Perhaps that recurring 22ns "noise" is quite simply the resolution of the NEO-7M which I believe is clocked at 48MHz? So by design the 1PPS pulse from the NEO-7M GPS receiver cannot have a resolution higher than 1/48MHz ~= 21ns to which you must add the approx, 1ns resolution of Lars' circuit, so you get 22ns?
I should have mentioned 21ns instead of 22ns. And yes, its the resolution of the NEO-7M clock.
The circuit from Lars can be greatly simplified and added to any GPSDO having a spare analog input to increase the measurement resolution.
Look at the bottom of here: https://github.com/erikkaashoek/Arduino_SI5351_GPSDO
The circuit I use takes the 2.5MHz as input but it will equally work (even with possibly better resolution) using the 10MHz signal
The Vphase is the analog representation of the time between the up edge of the PPS and the first up edge of the 2.5MHz (or 10MHz) and it has to be sampled shortly after the PPS when the capacitor is charged but did not yet have time to uncharge. This is easy using the PPS to drive an interrupt which you have anyway.
For best linearity the ADC should have a range upto 1V and the R1 should be matched to just stay within that range for the longest duration.
Lars did some tricks to compensate for non-linearity but this only has impact on the loop speed and as its speed is reduced anyway when below 10e-8 it really does not matter.
-
Another reason for averaging is that standard GPS modules receive one frequency band so don't fully compensate for ionospheric conditions. Advanced modules receive more than 1 band and are able to compensate by comparing them. Feed the NMEA data into a program like VisualGPS for a day and it shows deviations of several meters, each meter is about 3ns difference. Also for timing the best source is the satellite highest in the sky, but for position calculation it is better to have a scatter. So a standard GPS module is different from a timing module.
Manufacturers specify the stability of an OCXO after it has warmed up for a specified period, and that period is usually longer than 10 minutes. So expecting a GPSDO based on an OCXO to be OK after 10 minutes may be unrealistic. This might not be a problem with a TCXO because it doesn't have a warm up period. I have not used a TCXO.
-
Let me try to summary some GPSDO system design parameters we have discussed.
Counting the 10MHz pulses: 1 seconds gives 10e+7 count, 1000 seconds gives 10e+10 count. To reach 10e-10 accuracy you must at least count 1000 seconds to know if you are within the 10e-10 boundary. To correct to stay within 10e-10 you must count longer.
Measuring the phase of the PPS (once locked) from 2.5MHz can be done with at least 0.5ns accuracy, using the 10MHz for the phase may give 0.1ns accuracy. Without taking the fractional time of the GPS PPS into account, measuring one PPS with 0.1ns accuracy is sufficient to reach 10e-10
Including the 21ns fractional clock jitter of the PPS from the NEO-x modules gives 210 times less accurate time so you need to measure 210 times longer so to reach 10e-10 you need to measure the phase for 210 seconds. This 21ns clock jitter has exactly the same impact on counting the pulses but for 10e-10 accuracy using a 10MHz clock you already need to measure 1000 seconds so the 21ns PPS jitter has no impact when counting pulses.
This indicates that a FLL should count for at least 100 minutes to be able to adjust and remain within 10e-10 so the drift of the 10MHZ oscillator within 100 minutes should be well below 10e-10
Adding the phase measurement could reduce the measurement time needed to reach 10e-10 with a factor of 5. When using a GPS PPS without the 21ns PPS jitter this reduction could be much bigger.
The GPS position has an uncertainty in the order of 10ns leading to noise in the PPS of the same magnitude. Elimination of the position noise to reach 10e-10 requires at least 100 seconds measurement which is not relevant for the phase measurement method (as its smaller then 210 seconds) and also irrelevant for the pulse counting method as the measurement time is already 1000 seconds to reach 10e-10
Is this a correct summary?
-
Let me try to summary some GPSDO system design parameters we have discussed.
Counting the 10MHz pulses: 1 seconds gives 10e+7 count, 1000 seconds gives 10e+10 count. To reach 10e-10 accuracy you must at least count 1000 seconds to know if you are within the 10e-10 boundary. To correct to stay within 10e-10 you must count longer.
Measuring the phase of the PPS (once locked) from 2.5MHz can be done with at least 0.5ns accuracy, using the 10MHz for the phase may give 0.1ns accuracy. Without taking the fractional time of the GPS PPS into account, measuring one PPS with 0.1ns accuracy is sufficient to reach 10e-10
Including the 21ns fractional clock jitter of the PPS from the NEO-x modules gives 210 times less accurate time so you need to measure 210 times longer so to reach 10e-10 you need to measure the phase for 210 seconds. This 21ns clock jitter has exactly the same impact on counting the pulses but for 10e-10 accuracy using a 10MHz clock you already need to measure 1000 seconds so the 21ns PPS jitter has no impact when counting pulses.
This indicates that a FLL should count for at least 100 minutes to be able to adjust and remain within 10e-10 so the drift of the 10MHZ oscillator within 100 minutes should be well below 10e-10
Adding the phase measurement could reduce the measurement time needed to reach 10e-10 with a factor of 5. When using a GPS PPS without the 21ns PPS jitter this reduction could be much bigger.
The GPS position has an uncertainty in the order of 10ns leading to noise in the PPS of the same magnitude. Elimination of the position noise to reach 10e-10 requires at least 100 seconds measurement which is not relevant for the phase measurement method (as its smaller then 210 seconds) and also irrelevant for the pulse counting method as the measurement time is already 1000 seconds to reach 10e-10
Is this a correct summary?
It's a bit more complex.
Regarding the jitter in the 1pps - assuming the GPS module outputs the 1pps at the next available clock cycle from when it should be produced, it will be delayed by a random amount between 0 and 21ns. If it is truly random, the mean delay is 10.5ns and the statistical uncertainty is +- 21ns/n where n is the number of observations. So for 100 observations the mean delay will be 10.5ns +- less than 0.5ns. If a PLL is used with a time constant > 100s then it is insignificant. In reality the constraint 'truly random' is not true, the jitter will show beats with 10MHz but a 48MHz clock should beat quickly enough that a period of 100 observations is pseudo random. So the jitter can be ignored if the measurement period is long.
The situation with the GPS module is not so clear cut. The uncertainty of the position (and by inference, the 1pps) depends on the specific module, the position of satellites used, the number of satellites used, the constellations they are in (GPS, Glonass, Bidou, etc), the strength of the received signals. The receiver calculates a DOP (dilution of precision) and if that is consistently high then the 1pps can have a lot of variation (in addition to the jitter). There is a specification somewhere that says something like 99% of 1pps within 30ns of true with good signal. This may be a bell curve distribution (does anyone know) so more observations means higher confidence. Again 100 seconds of data should be enough to reduce errors to the point the data is usable if the signal is good.
If the oscillator is running at 10MHz with an error of less than 1E-10, and assuming the oscillator is stable and the 1pps arrival time is known accurately (even though the 1pps itself is jumping around a bit), then 100 seconds should be plenty of time to verify it. The uncertainty in measurement should be small enough to make that call.
The real problem is if the measurement shows the oscillator is off by more than 1E-10. Then the mechanism to correct comes into play. That is a whole new can of worms, each strategy has benefits and drawbacks. Most schemes the better they are at averaging, the slower they are to converge. So to get the oscillator error within 1E-10 may take longer than verifying it is achieved.
-
If the oscillator is running at 10MHz with an error of less than 1E-10, and assuming the oscillator is stable and the 1pps arrival time is known accurately (even though the 1pps itself is jumping around a bit), then 100 seconds should be plenty of time to verify it. The uncertainty in measurement should be small enough to make that call.
The real problem is if the measurement shows the oscillator is off by more than 1E-10. Then the mechanism to correct comes into play. That is a whole new can of worms, each strategy has benefits and drawbacks. Most schemes the better they are at averaging, the slower they are to converge. So to get the oscillator error within 1E-10 may take longer than verifying it is achieved.
Sorry for being slow to understand. In 100 seconds you can count 10e+9 of the 10MHz pulses that happened between the previous up edge of the PPS pulse and the up edge of the current PPS pulse.
To know if the 10MHz is within 10e-10 correct you need to count at least 1000 seconds. To know in what direction to adjust the PLL to stay within 10e-10 you need to count even longer, say 3000 seconds
When counting pulses for 100 seconds a long averaging time in the PLL does not help as the PLL will simply drift till it exceeds the 10e-9 boundary (e.g. you count 1 pulse too many or too less) and then be kicked back. If you not only count the pulses but also measure with sufficient accuracy when the last up edge of the 10MHz clock arrives versus the 1PPS up edge, this is what Lars did with his phase measurement, you get additional accuracy. Normally the 10MHz clock ticks every 100ns. IF you can measure the clock up edge versus the PPS up edge within 21ns you have gained a factor 5 accuracy, which is still not enough to keep the PPL within 10e-10, regardless of a long integration time. Using the phase detector you need probably 600 seconds.
Any shorter measurement time sends noise into the PLL loop
Here a table showing the measurements and corrections as used in my GPSDO showing the counting of the pulses, even with 80 seconds to count, does not provide any information once below 10e-9
(http://[attachimg=1])
-
Like I said I'm slow to understand and my assumptions where wrong!!!!
The GPSDO is not trying to stay within the exact count but at the exact transition between one too less and just enough so without jitter you should be able to adjust, given enough time, to any accuracy, even when measuring every second.
The jitter of the PPS and the jitter of the GPS signal limit the accuracy of the PPS to the order of 20ns, when measuring over 100 seconds you reduce this jitter to 0.2ns per second e.g. 2.0e-9. This then feeds into a PLL loop that averages this measurement every 100 seconds over sufficient time to reduce to well below 3.0e-11 error to avoid correcting too much so the the PLL loop time should be well above 100 minutes
Hope I'm now understanding this. Sorry for wasting your time.
-
The main reason to aim for long time constants is to make maximum use of the short term stability an OCXO offers against GPS. In other words, you want to disturb the OCXO only as required to meet your accuracy requirements (not stability!). Basically, you will want the OCXO to run freely without correction until it starts to drift away from the reference clock. A method to find this time constant is described in Lars documents about his GPSDO, but it similarly applies to all designs.
Herein lies a significant advantage of using a PLL over the counter method IMHO. A PLL let's you choose time constants as needed by the local oscillator only, while the counter demands time constants driven by the accuracy you want to achieve. Those two don't match most of the time.
-
Let me try to summary some GPSDO system design parameters we have discussed.
Counting the 10MHz pulses: 1 seconds gives 10e+7 count, 1000 seconds gives 10e+10 count. To reach 10e-10 accuracy you must at least count 1000 seconds to know if you are within the 10e-10 boundary. To correct to stay within 10e-10 you must count longer.
Measuring the phase of the PPS (once locked) from 2.5MHz can be done with at least 0.5ns accuracy, using the 10MHz for the phase may give 0.1ns accuracy. Without taking the fractional time of the GPS PPS into account, measuring one PPS with 0.1ns accuracy is sufficient to reach 10e-10
Including the 21ns fractional clock jitter of the PPS from the NEO-x modules gives 210 times less accurate time so you need to measure 210 times longer so to reach 10e-10 you need to measure the phase for 210 seconds. This 21ns clock jitter has exactly the same impact on counting the pulses but for 10e-10 accuracy using a 10MHz clock you already need to measure 1000 seconds so the 21ns PPS jitter has no impact when counting pulses.
This indicates that a FLL should count for at least 100 minutes to be able to adjust and remain within 10e-10 so the drift of the 10MHZ oscillator within 100 minutes should be well below 10e-10
Adding the phase measurement could reduce the measurement time needed to reach 10e-10 with a factor of 5. When using a GPS PPS without the 21ns PPS jitter this reduction could be much bigger.
The GPS position has an uncertainty in the order of 10ns leading to noise in the PPS of the same magnitude. Elimination of the position noise to reach 10e-10 requires at least 100 seconds measurement which is not relevant for the phase measurement method (as its smaller then 210 seconds) and also irrelevant for the pulse counting method as the measurement time is already 1000 seconds to reach 10e-10
Is this a correct summary?
Erik, :-+ :-+ :-+ :-+
I would say that's a really excellent summary of the measurement accuracy/timing of PLL vs FLL GPSDOs, at least in theory and in ideal conditions. In theory, you are 100% correct. In practice, unfortunately, things are slightly more complicated.
1. As you have already noticed, all electronic circuits are sensitive to temperature variations. Thus, there are various parts of any GPSDO that are temperature sensitive: the power supply, the XO or TXCO or OCXO, the ADCs and DACs, the GPS receiver itself, the phase measurement circuit in the Lars design, etc.
2. Noise. Unfortunately noise is everywhere in electronic circuits, and when you are dealing with 1ppb or better measurements, it's impossible to ignore noise.
3. Random atmospheric propagation variations, and the fact that GPS satellites are always moving.
4. Aging effects of all the electronic components but most importantly, of the quartz itself.
A very interesting blog about building a version of Lars' GPSDO and the practical problems that can occur can be found here: http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
My approach to all these measurement uncertainty issues was to set for my GPSDO design an objective of 1ppb (10E-9) accuracy and stability while keeping the BOM and the components cost to a minimum, and being able to complete the project in less than four months. Thus my K.I.S.S. hardware and software approach. Also of course I wanted to "do it my way" instead of copying Lars' circuit, and most importantly, I believe any hobby project should be fun. And I admit I had great fun designing building and testing my STM32 GPSDO. ;D
You can always make a GPSDO more accurate, more reliable, and faster, but this always adds cost, complexity, and engineer.hours. And I guess at some point it's not fun anymore.
All that aside, I am very curious about your final GPSDO design which you have published on GitHub. I am going to get a good look at it in the coming weeks when I have more time. Good work! :-+
-
Another reason for averaging is that standard GPS modules receive one frequency band so don't fully compensate for ionospheric conditions. Advanced modules receive more than 1 band and are able to compensate by comparing them. Feed the NMEA data into a program like VisualGPS for a day and it shows deviations of several meters, each meter is about 3ns difference. Also for timing the best source is the satellite highest in the sky, but for position calculation it is better to have a scatter. So a standard GPS module is different from a timing module.
Manufacturers specify the stability of an OCXO after it has warmed up for a specified period, and that period is usually longer than 10 minutes. So expecting a GPSDO based on an OCXO to be OK after 10 minutes may be unrealistic. This might not be a problem with a TCXO because it doesn't have a warm up period. I have not used a TCXO.
Yes, I also think that TCXO's are too ambient temperature sensitive to be used in GPSDOs, at least when the target accuracy and stability are better than 10E-9. A used OCXO (< $10) provides the best "bang for the buck" for a DIY GPSDO, in my humble opinion.
-
The main reason to aim for long time constants is to make maximum use of the short term stability an OCXO offers against GPS. In other words, you want to disturb the OCXO only as required to meet your accuracy requirements (not stability!). Basically, you will want the OCXO to run freely without correction until it starts to drift away from the reference clock. A method to find this time constant is described in Lars documents about his GPSDO, but it similarly applies to all designs.
100% agree. That is why I wrote that for any control loop, the time constant can either be calculated by design, or found empirically. Lars' method to find a time constant is a good example of the empirical method.
Herein lies a significant advantage of using a PLL over the counter method IMHO. A PLL let's you choose time constants as needed by the local oscillator only, while the counter demands time constants driven by the accuracy you want to achieve. Those two don't match most of the time.
I disagree, because I wouldn't call that an advantage. ;)
The Lars' PLL control loop time constant must be adjusted individually for each build, and may even require periodic adjustments. It's an example of an empirical method. :-/O
The FLL control loop I use measures over predetermined overlapping time intervals of 1s, 10s, 100s, 1,000s and 10,000s for predetermined measurement resolutions for a 10MHz oscillator of 10E-7 to 10E-11. This is an example of a deterministic method and it's much simpler to explain/understand for students and beginners, imho.
-
The Lars' PLL control loop time constant must be adjusted individually for each build, and may even require periodic adjustments. It's an example of an empirical method. :-/O
It fairly simple to change this. My version already uses an adaptive strategy where the time between updates is automatically increase when proven stability over the current interval (and decreased when drift increases). There is currently an upper limit to the interval but but this is easily removed. After adding an absolute phase delta as minimum condition to act the oscillator will only be adjusted when needed.
-
The Lars' PLL control loop time constant must be adjusted individually for each build, and may even require periodic adjustments. It's an example of an empirical method. :-/O
It fairly simple to change this. My version already uses an adaptive strategy where the time between updates is automatically increase when proven stability over the current interval (and decreased when drift increases). There is currently an upper limit to the interval but but this is easily removed. After adding an absolute phase delta as minimum condition to act the oscillator will only be adjusted when needed.
Erik,
That means your control loop algorithm uses a time variable (not a constant), but its empirical behavior doesn't differ in any essential way from Lars' control loop algorithm which has a fixed time constant.
For Lars' control loop algorithm: there is no update to the DAC value if the phase difference is below some arbitrary value. An update may or may not happen at the next time interval T-Lars.
For your control loop algorithm: there is no update to the DAC value if the phase difference is below some arbitrary value, and the update time interval T-Erik increases by delta. Again, an update may or may not happen at the next time interval (T-Erik + delta). At some point I assume the variable T-Erik stabilizes at some value which is just the maximum value for a given level of stability (and may not be the optimal value for your control loop, actually).
Lars' documentation provides an algorithm to find an empirical "optimal" value for the control loop time constant for T-Lars, your algorithm automates the task of monotonically increasing the initial time variable T-Erik up to some empirical stable time interval T-Erik(Max) where the measured phase difference is above some arbitrary value.
In both cases the "optimal" time interval is empirically determined, it changes from build to build, and it can (and probably will) change over time, as the quartz crystal and other components age.
Again, I fail to see any advantage here compared to the fixed overlapping time intervals for a given resolution of the FLL control loop in the STM32 GPSDO.
-
Trial & Error activities and using empirical methods are the signs of incomplete knowledge.
The true nature of the phenomenom is still hidden.
Whether the outcome is close to the true value or not remains uncertain.
We, all humans, have this deficiency.
Just a matter of evolutionary developments and they come slow.
Frans
-
Trial & Error activities and using empirical methods are the signs of incomplete knowledge.
The true nature of the phenomenom is still hidden.
Whether the outcome is close to the true value or not remains uncertain.
We, all humans, have this deficiency.
Just a matter of evolutionary developments and they come slow.
Frans
If there was a grain of useful information here, I missed it. The true nature of the phenomenon is well known and it has random elements. An adaptive response is appropriate to cater for this.
-
My STM black pill module still hasn't arrived. Worse, the antenna is delayed until September. I fear this project will get buried and never be finished.
-
1. The Planck time is the length of time at which no smaller meaningful length can be validly measured due to the indeterminacy expressed in Werner Heisenberg's uncertainty principle. Theoretically, this is the shortest time measurement that is possible, roughly 10(−44) seconds, Wiki
2. https://www.nist.gov/pml/time-and-frequency-division/time-services/utcnist-time-scale/performance-utcnist-and-utcnist (https://www.nist.gov/pml/time-and-frequency-division/time-services/utcnist-time-scale/performance-utcnist-and-utcnist)
the NIST steering adjustments typically keep the root-mean-square deviation of UTC – UTC(NIST) to within < 3 ns, and the frequency instability of UTC(NIST) to below 2 ×10(−15)
As generally in physics, there are promising routes and there are waste of time routes.
The difference between 1. and 2. shows the lack of current knowledge and understanding.
Any time division improvement (a decade) takes about 10 years.
Trial & error or empirical efforts will not solve this. The contribution to a solution is still nill.
Individual satisfaction is the only gain. As for opinions.
Frans
-
1. The Planck time is the length of time at which no smaller meaningful length can be validly measured due to the indeterminacy expressed in Werner Heisenberg's uncertainty principle. Theoretically, this is the shortest time measurement that is possible, roughly 10(−44) seconds, Wiki
2. https://www.nist.gov/pml/time-and-frequency-division/time-services/utcnist-time-scale/performance-utcnist-and-utcnist (https://www.nist.gov/pml/time-and-frequency-division/time-services/utcnist-time-scale/performance-utcnist-and-utcnist)
the NIST steering adjustments typically keep the root-mean-square deviation of UTC – UTC(NIST) to within < 3 ns, and the frequency instability of UTC(NIST) to below 2 ×10(−15)
As generally in physics, there are promising routes and there are waste of time routes.
The difference between 1. and 2. shows the lack of current knowledge and understanding.
Any time division improvement (a decade) takes about 10 years.
Trial & error or empirical efforts will not solve this. The contribution to a solution is still nill.
Individual satisfaction is the only gain. As for opinions.
Frans
I believe you are indulging in a philosophical observation in a practical thread. We are interested in GPSDO construction and you contribute nothing toward it. Time is a human construct to make sense of events. Without events, time does not exist. Comparing events like the transitions between the spin states of the cesium nucleus in different gravitational fields leads to the conclusion time as we measure it is not absolute. It is just a convenient construct that allows humans to send payloads from Earth to Mars and have them arrive within meters of the target destination. Measuring "time" to a greater accuracy than is already done is not yet useful. GPSDOs are practical instruments that are used to calibrate other instruments or as a reference frequency for radio transmission and reception. It is irrelevant to us that we cannot do this to better than 10(−44) seconds. There are practical reasons for having frequencies that are accurate to 1 part in 10E-10 for low power transmission world wide, which in turn can be used for emergencies. And to calibrate them conventionally reference standards are 10 times more accurate. Individual satisfaction is a gain, but not the only gain.
-
Trial & Error activities and using empirical methods are the signs of incomplete knowledge.
The true nature of the phenomenom is still hidden.
Whether the outcome is close to the true value or not remains uncertain.
We, all humans, have this deficiency.
Just a matter of evolutionary developments and they come slow.
Frans
True, but that's what engineering is about: starting from a good guess rooted in experience and improving the solution empirically until it matches the requirements.
There is no "truth" in any science other than Mathematics. All we have is models that match what we can observe empirically and allow predictions. And lets not forget that Math is not realitiy, it describes reality, and it has its limits, too. Not everything can be "computed".
-
[/quote]
I believe you are indulging in a philosophical observation in a practical thread. We are interested in GPSDO construction and you contribute nothing toward it. Time is a human construct to make sense of events.
Individual satisfaction is a gain, but not the only gain.
[/quote]
I disagree strongly. There are plenty of subjects to spend positive time on.
Just follow the TEA thread.
All personal satisfaction and an enourmous sense of pleasure is derived from it.
The results is often working test equipment to the limits of the initial sales brochure.
Another thread to follow is the metrology section.
There you sometimes find ideas on "nutty" approaches: time-nuts, volt-nuts etc.
And the limits of relevant measuring equipment.
Frans
-
Hello,
I am still working on the STM32 GPSDO schematic in KiCAD, here is the latest version with the OLED display, the Bluetooth interface and the various sensors as optional modules. While these add modestly (< $10) to the cost and complexity of the circuit, I recommend adding them to the minimal version I published earlier.
Notes:
1. The final version will have (optional) output buffers for the 10MHz and 1PPS signals, and an (optional) onboard low-noise but still inexpensive linear 5V @ 1A power supply.
2. I am still debating whether or not to include an optional phase difference measurement circuit based on Erik's modified/simplified Lars' design, as well as a couple of op-amps for various optional features.
3. I got started on the PCB, using KiCad.
4. The final PCB design will include the footprints for all the optional modules.
5. All the KiCad files will be uploaded to the GitHub repository.
-
A few minor remarks based on a cursory look on your schematics:
* I see no pull-ups for the I2C1? Are they on the Black Pill module? If not, it's better to not rely on the weak pull-ups in the STM32, put some 4k7 resistors to VCC.
* MISO1 and MOSI1 could use some 22R resistors close to the driving pins, just take off the edge and prevent ringing. Only if not already on the Black Pill.
* Same for RX1, TX1, RX2, TX2.
* Add a bulk decoupling electrolytic capacitor 22µF close to the power plug, maybe add a series inductor of around 10µH before, for EMI purposes.
-
A few minor remarks based on a cursory look on your schematics:
* I see no pull-ups for the I2C1? Are they on the Black Pill module? If not, it's better to not rely on the weak pull-ups in the STM32, put some 4k7 resistors to VCC.
* MISO1 and MOSI1 could use some 22R resistors close to the driving pins, just take off the edge and prevent ringing. Only if not already on the Black Pill.
* Same for RX1, TX1, RX2, TX2.
* Add a bulk decoupling electrolytic capacitor 22µF close to the power plug, maybe add a series inductor of around 10µH before, for EMI purposes.
Hi thinkfat,
Many thanks for your remarks:
1. The pull-ups for the SDA/SCL are on the modules connected to the I2C bus. Ditto for the SPI bus (for the BMP280 module).
2. Indeed if the sensors/GPS/Bluetooth modules were mounted somewhere distant from the main circuit board, perhaps series resistors to avoid ringing would be recommended. In the case of mounting everything on a PCB, I don't think there is any significant ringing because the PCB traces are quite short (low inductance). I still have three prototypes assembled on breadboards, I am going to check the signals for ringing with my DSO.
3. There is an electrolytic decoupling capacitor close to the power plug on the 5V power supply, but I think your suggestion of a 10uH inductor to reduce EMI is a good idea, I am going to include the footprint for it on the final PCB design. Also note that the STM32 Black Pill has many decoupling capacitors, as do all the modules.
More generally, the fact that I am using prebuilt, breadboard-ready modules for the GPS, Bluetooth, MCU and sensor chips means that most/all of them already include LDO regulators and generous decoupling capacitors, as well as the pull-ups and series resistors where needed. In principle that helps coping with noise and signal transmission issues.
-
Andrew, I still don't have the STM black pill. I have sent a complaint to Aliexpress but so far no response. If I can get a refund, the ordering process will start over. Perhaps something will happen soon.
In case it does arrive, I am still at sea regarding my next step. The antenna and GPS module and TCXO and so on are all sitting here in a little cardboard box.
I did run the rubidium standard to see how far my counter master oscillator had drifted, and it was amazingly close, so close in fact that I saw no need to adjust it.
On an unrelated (sort of) topic, I have been frustrated by the inaccuracy of the cheap digital watches. I did find one that was almost perfect but it has disappeared. I suspect one of my cats. However, I bought a package of 20 32768 crystals to replace some of the poor timekeeper crystals. On trying to measure the frequencies of these 20, I encountered a problem in that my source of signal for the test isn't stable enough to get a good reading. I suppose my best move would be to make an oscillator and swap in the different crystals. That would give me a stable reading which I could read out to 0.1 Hz resolution. Right now, the best I can do is about 1 Hz. Any ideas of a simple oscillator? Maybe a dual AND gate or something similar.
-
Hi Bob,
I would suggest you order the WeAct STM32F411CEU6 Black Pill from their recommended seller on AliExpress:
https://www.aliexpress.com/store/910567080 (https://www.aliexpress.com/store/910567080)
Normal delivery in 10 days.
Testing 32.768 kHz watch crystals for accuracy would not be too difficult if you had a working STM32 GPSDO, since it works as a frequency/period meter with 0.001Hz/100ns precision. We can discuss that possibility once you have the GPSDO assembled and working.
The simplest 32.768 kHz XO oscillator possible requires a single unbuffered inverter gate from a 4069UB chip, an example here: https://reviseomatic.org/help/x-more/Crystal%20Oscillator.php (https://reviseomatic.org/help/x-more/Crystal%20Oscillator.php)
-
The black pill I ordered was half the price posted by WeAct. So I guess I will have to see if they refund or replace. If refund, I'll reorder.
I will try to build an oscillator and find the closest crystal to nominal frequency. Of course I don't know the oscillator parameters in the watches so each oscillator will operate on a slightly different frequency. Trying it is the best way but I want to reduce the number of crystals to try. Removing the current watch crystal and measuring it will get me a number that I can use to select the best crystal.
Most of the crystals are within 1 Hz of nominal, series resonance.
-
This is the second sheet of the GPSDO schematic, with an optional 5V @ 1A regulated low ripple, low noise power supply, and optional output buffers for the 10MHz and 1PPS signal. The footprints for these will be on the future PCB, but they can be left unpopulated if not needed, just like the sensors, OLED display, etc.
-
Andrew, I eagerly await the chance to acquire a PCB to assemble this project, which seems to keep growing in cost and complexity with time. All I want is 10 MHz, no other functions required. Perhaps it will be easy for me to see how to get that.
-
Hi Bob,
Designing the PCB will take some time, but I am working on it, and of course I will post here when I am done. The STM32 GPSDO is very much a modular design, as I wrote before the guiding principle for this project is K.I.S.S. (keep it simple, stupid).
https://en.wikipedia.org/wiki/KISS_principle
Apart from the MCU board, the OCXO and the GPS module, everything else is pretty much optional, as clearly indicated in the schematic. So for a precise 10MHz +/- 1ppb frequency reference, basically you only need three small modules, an antenna and a few passive components for a total cost of less than $30. And even with all the optional modules the total cost should remain under $35.
And no, the project has not grown in complexity or cost, if anything it is simpler and cheaper than a couple of months ago, since now the MCP4725 12-bit DAC module can be replaced with a couple of resistors and capacitors to generate a 16-bit PWM voltage.
Please PM me when you finally receive the STM32F411CEU6 Black Pill and we can get started on detailed assembly instructions.
-
Andrew, good news from you. Yes I will send you a PM if and when the STM pill shows up. I have opened a dispute with Aliexpress. All the other stuff was ordered from them and arrived okay so it's the one part. I don't necessarily blame the vendor; it has to pass through many hands. In fact there is some evidence that it arrived in this country a few weeks ago so it's lost locally. Nevertheless, I suspect Ali will refund my money, at which point I will reorder from a different vendor at double the price. As they say, in for a dime, in for a dollar. Or maybe the same vendor.
In the meantime I am trying to get a little radio working. I designed it in about 1951 for my girl friend's high school science project and it worked (to the consternation of the teacher!). I was about 19 at the time and essentially made her a kit. It uses one tube, a 1N5GT and just a few other components. I think it works but I have to hook up headphones to find out. Somehow it got preserved for all these years and is mostly intact.
Two technological extremes.
-
Andrew, I eagerly await the chance to acquire a PCB to assemble this project, which seems to keep growing in cost and complexity with time. All I want is 10 MHz, no other functions required. Perhaps it will be easy for me to see how to get that.
It seems to me that you're attempting to build your very first DIY GPSDO and trying to overcome your fear of starting a project with a seemingly high level of complexity that you're worried you might not be able to master without making a rather greater investment in both time and money than you can afford.
In view of your stated requirement for a basic 10MHz reference, may I suggest that you start with the most basic of GPSDO projects as outlined by Gyro in this topic thread here:-
https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133 (https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133)
As he mentions, it was inspired by James Miller's simple GPSDO (a small factoid I'd forgotten when I first described my own initial GPSDO projects as being inspired by this version, namely the circuit diagram he'd attached in the final thread posting).
I'd substituted the 74HC4046 with a 74HC86 quad XOR IC on account I didn't have a 74HC4046 handy but I did have a few 7486s to hand to exactly emulate the PC1 portion of the HC4046 being utilised. Also I'd left out the dual RRO 5v cmos opamp and fed the output of the LPF direct to the the VFC pin on my 13MHz square wave output OCXO which I was feeding into a TTL based divide by 1.3 circuit to generate a 10MHz square wave locked to the OCXO.
Whilst a 13MHz square wave OCXO can be used to make a 10MHz GPSDO reference source, it really has little to recommend it other than, in my case, it being a cheap way to get an OCXO that can directly drive logic gates without the need to include a voltage level shifter (as I discovered, much to my chagrin, when I first started using a 10MHz sinewave version of these AE CQE OCXOs -ex Symmetricon kit as I later found out).
I was using a ublox M8N (my very first GPS module purchase and, rarity of rarities, a genuine one to boot!) in place of the LEA6T used by Gyro. I built the whole thing on a solderless breadboard, experimenting with various enhancements before transferring it onto vero stripboard and boxing it all up into a rather petite 110x110x50mm extruded aluminium enclosure which completed my MK I GPSDO which I powered from a cheap 12v plugtop psu (slightly modified to kill off the "Y" cap induced 90vac mains leakage 'touch voltage' that typically afflicts such smps based wallwarts).
I'd made the choice of external psu power deliberately to facilitate rapid swap out of a failed psu to minimise the down time involved in disassembling it to troubleshoot an integrated mains psu, plus, this would also eliminate a significant source of internal heating.
As a further measure to minimise internal waste heat, I'd used a low noise 7 to 24v input 5v output buck converter (designed to power the avionics in drones powered from 3 to 6s lipo battery packs) rather than the classic 7805 which would otherwise have required the additional complication of heatsinking to the aluminium case. This gave me another degree of freedom regarding my wallwart output voltage options since it can be powered from supply voltages ranging from 7 right up to a maximum of 24 volts and still only draw (OCXO at set temperature) 1.7 to 1.8 watts in the case of the MK I (the MK II only needs 1.3 to 1.4 watts over this range after the OCXO has come up to temperature).
The main downside with using a navigation class GPS receiver module in such a basic James Miller based design is the 30 to 50ns phase wander due to ionospheric effects (space weather). Long term, with impractically long PLL time constants, it can match the much more expensive single and multiband timing modules. This where a cheap microcontroller and properly optimised firmware can win out but there are a whole bunch of temperature related issues that have to be dealt with which the basic James Miller design can neatly 'sweep under the carpet' as demonstrated in this interesting comparison here:-
http://www.leapsecond.com/pages/gpsdo/ (http://www.leapsecond.com/pages/gpsdo/)
The significant improvements over the MK I GPSDO I'd made in the MK II were the use of a 10MHz (sine wave output) OCXO (same AE CQE brand) allowing elimination of all the noisy and power hungry TTL 'Magic' required to create a 10MHz clock from a 13MHz OCXO and a GPS Rx module upgrade to a ublox M8T which can be 'surveyed in' to put it into 'overdetermined mode' allowing it to retain a locked PPS output even when only a single valid SV signal is available (the navigation types such as the M8N require a minimum of four good SV signals to maintain a valid locked PPS output - not a problem when feeding it from a cheap active puck antenna mounted where it has a clear all round view of most of the horizon).
With the MK II, I only see around a 6 to 7ns Pk-Pk phase wobble on a time scale of a minute or three which makes syntonising my LPRO 101 to the GPS atomic time reference much easier. I've connected a ten turn helipot to the C field input, padded out by a factor of ten with a pair of 22k resistors either side to provide a much finer adjustment of the Rubidium's frequency than is available from its internal ten turn trimpot.
Even with such fine control, it only takes a degree or two of rotation to discern its effect after allowing the minimum of two or three hours required to identify the drift against the GPSDO's background phase wobbles. The toughest part of this syntonising process is resisting the urge to fiddle with the helipot before enough time has passed by to properly identify how much, if any, drift has occurred. In this, patience is most definitely a virtue. :)
Since encasing my fan cooled LPRO in a 2cm thick layer of polystyrene foam about three weeks ago to minimise changes to the internal thermal gradients due to variations in room temperature, I'm now routinely seeing some 30 to 60ns net daily phase shifts between it and the GPSDO as recorded by the infinite persistence displayed after a 24 hour run using an SDS1202X-E to compare the output waveforms.
This shows that it's possible to syntonise a rubidium oscillator to better than 10E-10 with a very basic GPSDO. If you're not planning on doing anything more with your rubidium oscillator than simply mount a large passive heatsink to its baseplate to prevent it overheating as most video bloggers appear to have done and leave it at the mercy of room temperature variations, a simple GPSDO will more than suffice to syntonise it to around the 10E-9 mark. Even the more simplified version of Gyro's that I described should be good enough for the job.
The component parts won't go to waste since the expensive bits will be needed anyway when you eventually do come round to adding a microcontroller into the mix and the experience gained will ultimately prove rather useful.
I've attached four images which might prove inspirational (if inspiration was needed). :)
-
Johnny B Good I read your message and frankly it's mostly over my head. All I want is 10 MHz but it appears that getting it isn't as simple as I expected. While I have an engineering degree, it predates all this modern stuff by many years. I have a reasonable grasp of the fundamentals and more, and have texts which I can peruse, but I am mostly lost in this morass of integrated circuits, digital technology, and software. I don't hide behind my age, since I don't see that as a factor. But my proclivities and talents lie elsewhere than what it seems to require to manage a project such as this.
So I was hoping Andrew would supply a circuit board and I could install the components and have a complete project.
If someone can give me a simpler route to my destination, I am ready to try it.
-
That does rather beg the question as to what you're intending to use a 10MHz reference for. Correct me if I'm wrong but would I be right in assuming you intend to recalibrate some HF radio gear?
-
Johnny B Good I read your message and frankly it's mostly over my head. All I want is 10 MHz but it appears that getting it isn't as simple as I expected. While I have an engineering degree, it predates all this modern stuff by many years. I have a reasonable grasp of the fundamentals and more, and have texts which I can peruse, but I am mostly lost in this morass of integrated circuits, digital technology, and software. I don't hide behind my age, since I don't see that as a factor. But my proclivities and talents lie elsewhere than what it seems to require to manage a project such as this.
So I was hoping Andrew would supply a circuit board and I could install the components and have a complete project.
If someone can give me a simpler route to my destination, I am ready to try it.
What Johnny tried to tell you in his usual elaborate ways, is not to be afraid. Even with a ragtag assembly like his, good results can be achieved.
-
Just to get back on topic, attached is a picture of the tiny WeAct STM32F411CEU6 Black Pill MCU development board, the "brains" in this project that Bob has been waiting upon for the last month or so. Note it also includes an onboard LDO 3.3V regulator which provides 3.3V to the OLED display and other modules. The STM32F411CEU6 chip includes a 32-bit ARM Cortex-M4 processor running at 100MHz, 128kB RAM and 512kB of flash memory and various peripherals, which help reduce the BOM of the GPSDO to a handful of parts.
The WeAct STM32F411CEU6 Black Pill costs around €5.50 plus shipping and taxes from the recommended seller on AliExpress. Delivery in 10 days usually. If anybody wants one pre-programmed with the latest version of the STM32 GPSDO firmware I can ship it worldwide at cost (please PM me if interested, do not post on this thread), but I strongly recommend that one program it oneself, as part of the learning experience and the entire operation takes a few seconds at most.
-
Andrew,
W.r.y the choice of adding the phase detector.
Lars could not directly count 10MHz due to the low clock speed of the nano so he had to count 2.5MHz and lost a factor 4 accuracy compared to directly counting the 10MHz.
The phase detector in theory can have a (sub) 1ns resolution (10e-10) of the 10MHz edge but as the 1PPS has jitter in the order of 21ns. The increase in resolution versus counting 2.5MHz (400ns) is only about a factor 20 and versus counting 10MHz it is only a factor 5. To have a practical below 1ns 1PPS timing measurement accuracy I do average over at least 40 seconds.
The advantage of the phase detector in my view is not so much the fact it can detect a correct phase at high accuracy (1ns) as the counting of pulses also can do this given enough time, but the phase detector gives a (almost) linear reading of the amount of deviation allowing a P controller to very quickly steer the 10MHz to the right value.
Below a log of a hot start. The phase detector starts to contribute at 0:01:00 with a first measure phase error of 15.5 (7.7ns error, 6.0e-9 correction) and in two steps this error is reduced to 0.2ns or -8.0e-11 correction at 0:03:07
Waiting for GPS
0:00:05 dur=4 acount=864 dcount=27872 calfact=0 xtal=10000000000 corr=0.0e0 dac = 2047
0:00:08 dur=2 acount=4999999 dcount=-1 calfact=0 xtal=10000000000 corr=0.0e0 dac = 2047 Lock
0:00:13 dur=4 acount=9999999 dcount=-1 calfact=0 xtal=10000000000 corr=0.0e0 dac = 2047 Lock
0:00:22 dur=8 acount=19999999 dcount=-1 calfact=10 xtal=10000000000 corr=10.0e-11 dac = 2057 Lock
0:00:39 dur=16 acount=40000000 dcount=0 calfact=0 xtal=10000000000 corr=-10.0e-11 dac = 2047 Lock
0:01:00 dur=40 p_average=15.05 phase=-1.00 calfact=602 xtal=10000000000 corr=6.0e-9 dac = 2649
0:01:47 dur=80 p_average=-4.32 phase=-1.00 calfact=516 xtal=10000000000 corr=-8.6e-10 dac = 2563
0:03:07 dur=160 p_average=-0.43 phase=779.16 calfact=508 xtal=10000000000 corr=-8.0e-11 dac = 2555
-
I'm doing an experiment with using a SI5351 as GPSDO clock output generator. The XTal on the SI5351 module is removed and the OXCO 10MHz is used as the PLL reference for the SI5351.
By avoiding fractional dividers the 10MHz output of the SI5351 to the STM32 (or 2.5MHz for the LARS GPSDO) and also additional 100MHz or other frequencies outputs can be generated. And the SI5351 also acts as a buffer for the OXCO.
The SI5351 is perfectly happy with the 10MHz reference and the phase noise is outstanding. No fractional spurs at all. The datasheet mentions a limited PLL reference clock range but this only applies when used with an XTal, not when using an external oscillator.
-
In view of your stated requirement for a basic 10MHz reference, may I suggest that you start with the most basic of GPSDO projects as outlined by Gyro in this topic thread here:-
https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133 (https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133)
As he mentions, it was inspired by James Miller's simple GPSDO (a small factoid I'd forgotten when I first described my own initial GPSDO projects as being inspired by this version, namely the circuit diagram he'd attached in the final thread posting).
Bob
I tried this by setting the output of a NEO-7M to 10MHz and using a 7474+7400 phase frequency comparator (an XOR would have worked too) to lock the 10MHz OXCO using a loop filter with a corner frequency of about 0.1Hz. Locking is very quick but.....
When looking at the 99th overtone of 10MHz (990MHz) on a SA the SA can show 1Hz changes in frequency, which is 0.01Hz of 10MHz or 10e-9 accuracy and the locked frequency of the OXCO jumps 0.01Hz up and down every second as the NEO-7M is dithering its output frequency. You will never see this when measuring the frequency of the 10MHz signal as you have to average over a long period for sufficient accuracy.
Or was I doing something wrong here?
-
Hi,
I have very good news: Erik (erikka) has kindly agreed to allow me to include his 1ns resolution phase difference measurement circuit (inspired by and an improvement on Lars' similar circuit) in the final STM32 GPSDO schematic.
I am including the footprints in the PCB for the components for Erik's phase detector, these can be optionally populated or not: a 74HC74 dual flip-flop and a handful of passive components.
The inclusion of Erik's circuit makes it possible for the STM32 GPSDO to use two different control loops, FLL or PLL, or even a hybrid FLL/PLL control loop: this is now up to the imagination and talent of the programmer.
As far as I know this will make the STM32 GPSDO quite unique in the world, as the only GPSDO to include both FLL and PLL functionality. It's probably the ideal platform for experimentation with GPSDO concepts and algorithms, at this point.
I am working on finalizing the schematic for the STM32 GPSDO and I already got started on the PCB layout.
In summary: the basic version of the STM32 GPSDO requires three modules and a handful of passive components plus a GPS antenna, costs around €25, can be assembled on a breadboard in a couple of hours and outputs a stable 10MHz +/- 0.01Hz signal (that's 1ppb or 10E-9). The three essential modules fit in the palm of one's hand (see picture below).
The maximum configuration including all the bells and whistles will include a quality 5V power supply and allow exploration of 10E-10 and 10E-11 territory, algorithms for improved holdover performance, comparisons of PLL vs FLL vs hybrid PLL+FLL control loops, etc, etc, etc. All that while still remaining under €40 total BOM cost (+ PCB cost) and fitting on a small 150x100mm PCB. And oh yes, did I mention the STM32 GPSDO can be controlled from any smartphone using the (optional) Bluetooth module? 8)
And of course one can assemble the STM32 GPSDO "à la carte", meaning with the optional modules of one's choice.
So again: the good news is that Erik has kindly agreed to allow me to include his 1ns resolution phase detector circuit. I have included it in the second sheet of the schematics, see attached KiCad schematics sheet.
-
@erikka
First things first, my name is John (it's hidden away in my sig line at the bottom of each of my posts :) ). The 7474+7400 phase frequency comparator (PC2 option in the 74HC4046) has the charm of being insensitive to the duty cycle as well as outputting a voltage in response to frequency difference between the ref and sig inputs.
In this case, assuming you've configured the PPS for a 50% duty cycle 10MHz output, a simple XOR phase detector (PC1 option) would have served just as well (or even better, depending on your needs). I tried the PC3 charge pump option of the 4046 but this had too large a deadband to be of any value in this application so I went back to the PC1 option in my MK II design.
Unless you're using a screened feed for the PPS output (with a 33ohm series resistor to attenuate the high frequency harmonics), the 10MHz square wave (a rather respectable looking square wave I might add) is likely to impair reception of the SV signals (as I noticed when I tried experimenting with different PPS output frequencies (1MHz and 10MHz settings). I stuck with the 100KHz option as used by Gyro and for much the same reason that he chose this as a more optimised setting than the 10KHz only option provided by the Jupiter T GPS engine that had allowed James Miller to simplify his GPSDO design (avoiding the need to divide the 10MHz OCXO frequency output by 10,000,000 in order to phase lock it to the 1PPS as had been the case with earlier designs).
One thing I did notice when phase locking on the 1 and 10MHz PPS output settings was the speeding up of acquiring a lock between the OCXO and the GPS. A not unexpected result after my doomed to total failure trying to get a cheap M6N to emulate a 1KHz signal on its PPS line where the process could at best, only be described as "Glacial" (those early pioneers using a 10,000,000 divider to lock to the 1PPS line must have had inexhaustible supplies of patience ::)
Still, since you really need to allow the OCXO a good ten minutes of warm up time, fast lockup to the GPS is not a particularly high requirement since all that does is have the PLL chase a rapidly moving target as well as impose an otherwise needlessly high switching performance requirement on the PLL circuit and raise the power density of the switching harmonics in the L1 band.
Whether you're phase locking at 10MHz or, more sanely, 100KHz, provided you're using a long time constant filtered output from the PLL to drive the VFc pin on the OCXO (buffered or not), the jitter and sawtooth corrections will more or less disappear into the noise leaving only the inescapable effects of space weather (changes in the ionosphere) and to a lesser extent variations of "precipitatable moisture content" in the stratosphere to contend with.
Ionospheric effects seem to account for around 6 or 7ns pk-pk phase shifts with my L1 band NEO M8T. A much more expensive multiband ZED9 timing module can eliminate this type of error on the fly for each and every SV signal but not the order of magnitude less variations in the ToF due to the stratospheric moisture content variations (nor for the remaining errors in the GNSS system (clock timings and orbital positions of the SVs themselves as well as a bunch of other lesser sources of error within the system as a whole).
There's only so much you can do with a James Miller type of GPSDO design despite its excellent performance compared to those microcontroller based units. I suspect this may have been more to do with his choice of OCXO (a low phase noise Axtal IIRC) than anything else. Longer time constants can help reduce the effects of fluctuations in the GPS signals but this relies on the medium term (hours long) stability of the OCXO or DOCXO being used.
It's possible to make a hardware LPF with a time constant as high as 5000 seconds but even if the LO was stable enough to take advantage, this isn't the optimum way to filter out the GPS errors. Doing this filtering in software is a more optimal solution but it lets in a whole host of temperature related issues that can't neatly be swept under the carpet as is the case with a simple hardware filtered PLL solution.
However, when it comes to disciplining a Rubidium oscillator (essentially to take care of the ageing effect), a software approach is really the only effective solution since we can now realistically integrate a whole 24 hours' worth of GPS timing data, allowing our GPSDRO to closely approach the 10E-14 limit of the GPS system clock.
Although I've been extolling the simple charm of a hardware PLLed GPSDO, I'm reading these microcontrolled GPSDO project threads to acquire ideas on how to best implement my own variation of a microcontroller solution to turn my RFS project into a GPSDRO.
Despite my avoiding the use of a microcontroller so far in my RFS project, it has become rather obvious that I've reached the stage where I now have to compensate for barometric changes which means I'll need to use one of my stock of three Nano 3 modules simply to convert the I2C output of a BMP280 sensor into an analogue control voltage to feed into the external C Field adjustment pin on the LPRO. Inevitably, once I've got that far, it becomes rather obvious that I can also use it to control the fan cooler much more intelligently than that thermal controller breadboard lashup I've got set up on the bench.
Ultimately, I'll be using it (or a second one) in a GPSDRO setup. However, I started to suspect that a Nano 3 might not be up to this task so when I spotted a link in one of Banggood's many spam mails to a RPi pico board, I took a closer look. At something like 12 quid delivered from China for just one board, I decided to shop around and landed up buying a pair for just less than Banggood's price delivered from the UK based PiHut in less than a week.
It struck me that the Blackpill is like a Nano 3 on steroids. You could say the same for the RPi pico but it's more like a Blackpill on steroids with its Dual-core ARM Cortex M0+ processor, flexible clock running up to 133 MHz, 264kB of SRAM, and 2MB of onboard Flash memory. Best of all, like the Blackpill, it too can be programmed using the Arduino IDE.
Either of these two "Nano 3 on steroids" modules will do the job with plenty of left over power to spare and It seems to me that AndrewBCN's code should run on either of these modules but I haven't dared to take a peek at his code to check :scared:
-
John, I think you were asking me my application for the 10 MHz. I simply want it as a standard for my counter. Most of the time I deal with frequencies in the HF range but I want the confidence that I feel when my source is a couple of orders of magnitude more accurate than the counter. And I want verfification of my rubidium standard, which otherwise runs off at its own pace with no way to see how good it is.
So 1 ppb is good enough for most of what I do but a little better would be welcome.
-
I'm using an Efratom LPRO-101 rubidium oscillator so I only have datasheets and manuals for this model of rubidium oscillator as my guide. I can only speak for that model which has an internal 10 turn trimpot to adjust the frequency (as well as an external C field input pin) which, according the the manual specifies an adjustment range of >+/-1E-9 (one part in a billion) for either input going on to state that the internal and external adjustments are summed together followed by mentioning a >1.5E-9 adjustment range individually. I think they'd gotten things a little mixed up and I suspect they meant that the adjustments combined could provide in excess of +/-1.5ppb and a guarantee of at least a +/- 1ppb for each input.
I would expect the FEI models to have similar fine tuning options with very much the same adjustment ranges, implying that if you preset the internal pot to its mid position, you'd almost certainly land up well within +/-1ppb without any need to calibrate it against another atomic standard such as a GPSDO. In other words, it's very likely to exceed you requirements as it stands without any further adjustment.
Incidentally, the ageing error is given as less than 50ppt per month and less than 1ppb per decade according to this Symmetricom telecoms information leaflet (attached below).
Whilst accepting such calibration accuracy on blind faith in the manufacturer's specifications does go against the grain, for the moment that's your best option until you can compare it against a GPSDO (whether borrowed, begged or stolen or courtesy of an obliging friend).
JOOI, what brand/model of Rubidium oscillator do you have (there's more than just the Efratom/Symmetricom LPRO and FEI models to choose from)?
-
Electronic Research Model 130.
-
Electronic Research Model 130.
Thanks (I think... :-// )
I did a search for that model but only found 4 pictures which led to a couple of ebay sellers who offered zero information other than pictures (one with a date code of 95-23, presumably week 23 in 1995).
They've most likely simply repackaged one of 'the usual suspects' (Efratom LPRO or FE-5680A or WHY) in an enclosure of their own design. Have you taken a peek inside to see what they've actually used?
-
I suggest getting a LPRO. I have good experience with them, they are usually reasonably priced, a quite modern design that has only few unobtainable components should the need to repair them arise. Solid performance.
-
I suggest getting a LPRO. I have good experience with them, they are usually reasonably priced, a quite modern design that has only few unobtainable components should the need to repair them arise. Solid performance.
I wholeheartedly agree with that conclusion. Just over a year back when I was researching purchasing options on rubidium oscillators, I swiftly came to the conclusion that the LPRO 101 was the best bet over the more ubiquitous FE-5680A (and its many many variants).
The two main reasons being its much cleaner output and, perhaps more importantly, the much greater availability of meaningful service manuals and user guides and a greater proliferation of repair and configuration/setup youtube videos and articles. The sheer number of various options mostly under the single model number of FE-5680A in the case of the FE inc brand units meant you couldn't be certain as to what you'd land up purchasing - the FE inc units were pretty much a crap shoot so best left untouched as far as I was concerned hence my purchasing an LPRO-101 from (as I later discovered) fellow EEVBlog member testpoint1, last August for just under £200 shipped to the UK from Massachusetts, USA. My recent search for info on that rare Electronic Research Model 130 of Bob's revealed that the prices on these rubidium oscillators are still climbing skywards!
:wtf: a prime example of "supply and demand effect" being so strongly evident with ebay (and Amazon) sellers. It's not just limited to rubidium oscillators, of course. I had a taste of this last year when I purchased my first NEO M8T module at a bargain knockdown price of just 41 quid from an Amazon seller who, just a few weeks later, started selling them for just 24 quid each of which I snapped up another two, only to discover a few more weeks afterwards that he'd jacked the price right up to 61 quid a pop - one of the few times that I've been in the right place at the right time! :)
BTW, I've attached a screenshot showing the result of a 12 plus hours overnight run comparing the RFS against the GPSDO using infinite persistance to record the 6ns GPS wobble and 18ns RFS drift after finally managing to re-syntonise the RFS around 3am yesterday.
There's probably a strong element of serendipity involved (the barometric readings had dropped to a low of 979mB by then- it's now been showing 981mB over the past 4 hours and may continue a modest rise over the next 24 hours).
The key improvement over my earlier temperature stabilisation experiments lies in my upgrading the 3 or 4mm thick wrapping of polyethylene foam packaging material I'd applied as an afterthought when I'd deluded myself that I'd found just the right size of enclosure for the project (there wasn't any room to use more insulation). I've ditched that enclosure entirely and wrapped it up in a 2cm thick layer of polystyrene foam which now makes the attached fan cooled heatsink almost entirely the sole arbiter of the LPRO's temperature with a much reduced internal thermal gradient variation from changes in the ambient temperature.
I'm building myself a custom sized enclosure to allow the insulation to be supplemented by another two centimeter's worth of polystyrene foam which means the otherwise hidden barometric effect on frequency stability will need to be addressed to effect any further improvement. This means I'll need to throw a nano 3 at the task (analogue output barometric sensors are as rare as rocking horse droppings if you exclude the rather expensive industrial standard 4 to 20mA types making the 2 quid BMP280 sensor the only sane option).
Since I can't avoid adding a nano 3 without foregoing the benefit of barometric compensation, I'll be maximising the benefit by making the nano 3 take care of the temperature control as well, neatly doing away with the current analogue controller lashup.
I've got a couple of those new fangled RPi pico boards (basically a Blackpill on steroids) which could do both these jobs and that of a GPSDRO with resources to spare but I think I'll split the GPSDRO and environmental regulation on separate microcontrollers since the nano 3 will create a standalone RFS setup independently of whatever GPSDRO software experiments I may care to run on the RPi pico board.
-
I have not opened my Electronic Research Model 130. I am loath to do so for fear of damaging it. Once I get this GPSDO running I will have less to lose. As it is, too many things need doing around here and it overwhelms me such that I don't do any of them. I did pull out the TS-940S transceiver and got it running properly again so that's a good thing.
I do believe the model 130 is simply someone else's standard unit packaged with a power supply. It has a lamp to indicate warming up and one to indicate lock. Not even a power switch.
https://testequipment.center/Product_Documents/Electronic-Research-130-Specifications-F561E.pdf (https://testequipment.center/Product_Documents/Electronic-Research-130-Specifications-F561E.pdf)
https://www.popscreen.com/prod/MTgxOTYxOTIy/Electronic-Research-Company-ERC-Model-130-Rubidium-Reference-Oscillator-R1192A (https://www.popscreen.com/prod/MTgxOTYxOTIy/Electronic-Research-Company-ERC-Model-130-Rubidium-Reference-Oscillator-R1192A)
-
@bob91343
Thanks for posting those links. I'd already discovered those pictures but the pdf link provided some useful data. The specifications are pretty well run of the mill for these surplus Rb oscillators and seem a close match to those for the LPRO. The 5E-10 per year ageing figure neatly ties in with the 10 year ageing figure of <1E-9 for the LPRO (the annual ageing rate typically slows down over the years).
I can understand your reluctance to poke around the innards. "If it ain't broke, don't fix it!". However, you may have to if it turns out to be in need of a re-calibration once you do sort out a GPSDO to test it against.
Talking of which, I have another screenshot at the 22+ hours mark in my current frequency stability test. If I'm still up and about when it completes the full 24 hour run, I'll be posting a final screen shot in another two hours or so.
-
As promised in the previous post, I'm providing the final screenshot of a 24 hour run which has used the DSO's infinite persistence to record the relative shifts in phase between the Rb oscillator (trigger source CH2) and the GPSDO's 10MHz output (CH1).
The persistence shows a total of some 24ns shift in phase relative to the trigger source of which at least some 6ns worth will be that due to the effects of the ionosphere on the GPS signal. This suggests a net drift of the Rb oscillator of around 18ns in the past 24 hours (the test run had been started with both traces aligned with each other just after 3am the day before).
This translates to a frequency difference of 2μHz or an error of 2E-13 against the GPS master clock. I've now cleared and realigned the two traces as of 03:54 BST to observe another 12 or 24 hours' run to see how long it takes before it starts drifting off frequency. I expect the error to increase from now on in, it's not a question of if, only one of when.
-
When I first got the Model 130 I beat it against the HP 10811 in my counter. I set the Lissajous as steady as I could, which was excellent. After several minutes it had drifted one cycle or so at 10 MHz but for the casual observer it was stationary.
Months later I warmed up the model 130 again and ran the same test. To my joy and amazement, the Lissajous was pretty much steady as before. So maybe it's not right on frequency, but it's certain matched between the two 10 MHz signals. The GPSDO will allow me to compare it to whatever the scientific world now uses as a standard. Once I do that comparison, I can adjust the two local sources such that all three signals are zero beat, or as close as my patience (and the phase noise) will allow.
Why I get pleasure from all this is a mystery. However, I do, and once it all gets synchronized I will have as good a frequency standard as I can get. While the lab at WWV might have better signals, there is no way I know to make any further comparison, without spending considerable money by shipping my gear to Colorado.
-
If all that is needed is a 10MHz reference with +-0.01 accuracy (i.e. 1 part in 10E-9) then this circuit does it. It has a GPS module and two ICs; a PIC16F1455 to do the the heavy lifting and a 74HC04 to output 10MHz square wave into 50Ω. I have tried several versions of this and 1 part in 10E-9 is easy, 1 part in 10E-10 is not so. Of course, being locked to GPS its long term accuracy is however long you want to run it. I intend to get a PCB made for it when I figure which version of the micro USB port will be used, there appears to many options.
The design is supposed to be somewhat flexible in that either it is run off a 5V USB charger or some other supply through a barrel connector and a 7805 regulator, just mount the appropriate bits. It has a serial output for debugging and logging, but the one LED indicates a lot of status - e.g. lock is a double flash per second, achieved 10E-9 is single flash per second. It also has signals for no input (OCXO not running so PIC running off internal clock), no serial input from GPS, indication of satellites before getting a fix (e.g. receiving less than 4 satellites will not achieve a fix). I have been writing it up here https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/) but been busy with other things for a few weeks.[attachimg=1]
-
Just to get back on topic, attached are the three sheets for the schematic of the STM32 GPSDO, rev. 0.4, with the optional 5V low noise power supply, sensor modules and output buffers and most importantly, the (also optional) 1ns resolution phase difference measurement circuit by Erik (erikka).
The software source code - actually an Arduino sketch - is available in my GitHub repository here: https://github.com/AndrewBCN/STM32-GPSDO
As duly noted in the schematic and in the GitHub repository, this project is entirely Open Source. More specifically, the software is under a GPL V3 license and the hardware is under a Creative Commons - Attribution - ShareAlike 3.0 license, described here: https://creativecommons.org/licenses/by-sa/3.0/
The next chapter in this project/adventure is the PCB which I am also designing with KiCad. I have started work on the PCB design already but I expect it will take me a few weeks. And just as a reminder: the basic version of the STM32 GPSDO can be assembled and tested on a $3 breadboard in a couple of hours, provided one has the three main modules at hand: the u-blox Neo M8N module, the STM32F411CEU6 "Black Pill" and the 10MHz OCXO (see attached picture).
-
A question to the esteemed and knowledgeable visitors of this topic.
As far as I am able to judge there are at least two ways to gather information for the OCXO control loop.
- Take per PPS a TIC value either from counting the 10MHz pulses or optionally extended with a value from a phase detector and feed this TIC into a PI(I)D controller to determine t o set to what DAC voltage when needed
- Count 10MHz pulses, optionally extended with phase measurement, over a certain large (40-400) number of PPS and use that number to calculate a new value for the DAC (if needed)
In the leapsecond GPSDO simulator method #1 is used, Andre and Lars also use(d) method #1. Roland used method #2 in his very simple, but functional GPSDO
Is there any clear advantage of either method #1 or #2?
-
A question to the esteemed and knowledgeable visitors of this topic.
As far as I am able to judge there are at least two ways to gather information for the OCXO control loop.
- Take per PPS a TIC value either from counting the 10MHz pulses or optionally extended with a value from a phase detector and feed this TIC into a PI(I)D controller to determine t o set to what DAC voltage when needed
- Count 10MHz pulses, optionally extended with phase measurement, over a certain large (40-400) number of PPS and use that number to calculate a new value for the DAC (if needed)
In the leapsecond GPSDO simulator method #1 is used, Andre and Lars also use(d) method #1. Roland used method #2 in his very simple, but functional GPSDO
Is there any clear advantage of either method #1 or #2?
Erik, my understanding is that what you describe as control loop method #2 is just the same as control loop method #1, but averaged over a time interval of 40-400 seconds. This "averaging" mathematically has the same effect as the "low pass filter" in an analog PLL or the "time constant" in Lars' GPSDO or the overlapping 1s/10s/100s/1000s/10000s time intervals in my FLL GPSDO.
The mathematical analysis of closed control loops has decades of history and I would say it's pretty much established science, so I would prefer to point you to this Wikipedia article rather than discuss it here in this thread: https://en.wikipedia.org/wiki/PID_controller
Note that since you, Lars and myself are using MCU's in our control loops, we can program whatever control loops we want. But from my limited experience I would say even a simple control loop does a good job of rapidly stabilizing an OCXO to 1ppb.
So If you are curious, I would suggest you read more about control loop theory, and then program and experiment with various algorithms yourself, you'll learn a lot while doing so! :-+
-
@bob91343
Why you get pleasure out of such activity is really no mystery :) As pretty well everyone here knows full well, it comes from that warm glow of 'a strong sense of achievement'. In your case from being able to improve the accuracy of your HP10811 against a (secondary) Atomic Standard and later discovering months afterwards that both had remained 'in calibration', proving that both were remarkably stable frequency references under the quite reasonable assumption that this wasn't likely to be due to both having coincidentally suffered exactly the same ageing induced error.
I swiftly discovered in my late teens (just over half a century ago now :o) never to trust that even well respected manufacturers 'had done the right thing' in regard of both design and calibration so learned very early on to ignore that old adage "If it ain't broke, don't fix it!".
I became rather interested in high quality audio recording (a logical step from my interest in amateur radio) so had purchased an Akai 4000D way back in 1967/8 which proved to have a mismatch between the record and playback heads which I belatedly discovered when downmixing my stereo recordings into mono to dub onto mono cassettes for portable convenience (I'd already dubbed a hundred or more vinyl albums by then so it was a particularly egregious discovery - no great problem with today's computerised audio processing but a disaster back then).
When I upgraded to an Akai GX630DB a few years later, I was mindful of this issue and the possibility of other 'design errors' so made sure to order a full service manual from Akai before the supply dried up (When I'd placed an order with Rank Xerox for an M8 service manual, they'd been obliged to ship me a photocopy of their own service manual copies - two in fact!).
I'm glad I did because when I'd read an otherwise glowing review of the GX630DB in Studio Sounds magazine, spoilt only by the discovery of a replay clipping issue (at the +8dB VU level) when testing with recordings made at high levels on another brand of machine, it led me to take a closer look at the replay circuitry, notably the Dolby processing boards where I discovered the emitter follower output stage was biased at quarter of the rail voltage rather than the expected mid point voltage. I calculated a resistor capacitor biassing network that would maintain the audio gain but shift the emitter voltage to the mid point to eliminate the asymmetric clipping that had reduced the clipping level by some 6 or 7 dB.
It was only several months later that I saw the original Dolby circuit published in a Wireless World article which revealed that I had only managed to reverse engineer away the penny pinching bodge that Akai had inflicted and restore it back to the full Dolby reference standard. You may well imagine my sense of satisfaction and smugness (don't hold back on the 'smugness' :) )
The story with the Dolby boards didn't end there since the stereo Dolby board used in the record amp chain had been likewise afflicted which neatly explained why a gross intermodulation would arise with high levels of bass, an effect which I'd initially assumed to be a limitation of ferrite over mu-metal used in Akai's Glass Xtal heads.
Since the bass boost part of the recording EQ had been applied before going through the Dolby circuit on the quite reasonable assumption that the Dolby processing ignores the extreme low bass content (the high frequency record EQ boost being applied to the final stage after the Dolby circuit), this too needed to be brought back to standard.
The only difference this time being that I didn't need to replace the resistor in the emitter follower with a constant current generator circuit as I had done with the replay boards to avoid the onset of asymmetric clipping with output loadings above a minimum limit of 3K impedance. The use of a resistor, in this case 3kR, in an emitter follower compromises the clipping limit in an asymmetric way even for reasonably high impedance loads of 10K (I had decided on this extra modification to the Dolby reference design on the basis of "Why only do a half assed job whilst you have the opportunity to a full assed one to make it more robust against any unusually low loadings that may get connected to the line out sockets?). The output loading on the record boards was well defined so didn't require this level of robustness.
That investment in a workshop manual had more than paid for itself. Not only was I able to add more upgrade modifications (Xtal locked bias oscillator, 12 step switch adjustable bias, HF EQ and record amp sensitivity levels to optimise for a wide range of tape formulations that could be noted against each reel of tape for future reference) as well as allow me to troubleshoot a sudden capstan speed instability due to a shorted out 1N4001 diode in the bridge rectifier part of the servo circuit which controlled the direct drive capstan motor, not once but twice - second time round I used higher voltage 3A rated diodes to avoid any further repeat performances.
The result of that hard won experience with kit that turns out to 'broken by design' (Transam Tuscan S100 bus computer kit, anyone? and of course that classic of "Bean counteritus gone mad", the wonderful Feeltech FY6600 'modify to your heart's content' project) means I rarely apply the adage "If it ain't broke, don't fix it!" unless it's so complex that I wouldn't know where to start looking for things in need of improvement such as that LPRO 101 where there's some risk of making things worse for no effective gain.
I don't need to open it up since I've been able to see more than enough photographs of its innards published on the interweb and in all the various downloaded maintenance and repair guides and manuals I've collected. I'm seeing no hint of any issues in its operation to warrant deeper investigation so I'll wait until the time, if ever, to deal with any problems that may arise.
Right now, the only minor concern is over the lamp photocell output voltage being a little lower than I'd have preferred. It was measuring 4.975v when I first got it some 12 months ago and is now at 4.912v with most of the drop seemingly having taken place as a result of powering it down rather than actual run time. Extrapolating the rate of fall implies it won't reach its 3 volt end point for another decade or two so I'll 'make hay while the sun shines' and ignore the urge to check on certain critical resistors and a decontamination of a quarter of a century's worth of pollution on the glassware inside the physics package for another year or three.
Incidentally, when I checked on the drift rate of the Rb oscillator some 4 hours after re-aligning the traces for another test run, it had drifted by some 55ns and then a further 55 ns or so another four hours later.
Checking the heatsink temperature with my IR thermometer showed it had warmed up by a good half degree C. I guess I must have disturbed my breadboard lash up sufficiently to introduce the half degree error when I'd disconnected the long redundant scope probe I'd been using to monitor the PWM fan motor drive signal up until a couple of weeks ago.
Solderless breadboards have their charms but stability of their connection points ain't one of them, especially when mV levels of voltage stability are a critical requirement of the circuit lash up as it was in this case. Fortuitously, after fiddling with the breadboard at 1pm, that drift has, rather gratifyingly, been slowed right down to 1ns per hour over the past 6 hours.
Soldering the components onto a PCB would fix that issue but since I now want to use a nano 3 for the task, I'll skip that step and commit to getting to grips with the Arduino IDE and write (or modify) a fan controller sketch of my own. I've been putting this step off for long enough. I've seen ample enough 'proof of concept' with my breadboard testbed now to take that next step.
It's not as if programming is an alien art so much as it being over 30 years since I last coded anything in Z80 assembler and even longer since I last used TCL BASIC (that Transam Tuscan kit I'd alluded to earlier) and before that, Sinclair BASIC on the original ZX80.
My main problem is that I've finely honed my otherwise useful skills in procrastination to such an extreme as to be counterproductive in making further progress in a hobby that now routinely makes use of microcontrollers as a cheaper alternative to the more traditional analogue solutions of yesterdayyear. Even my writing style is afflicted by this. :(
-
FYI - here is a link to an excel table for calculating the filter parameters of a XOR based Miller design.
https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070 (https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070)
-
FYI - here is a link to an excel table for calculating the filter parameters of a XOR based Miller design.
https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070 (https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070)
Very, very nice.
However, it clearly shows how an analog PLL hardware control loop is limited when compared to a PLL or FLL control loop implemented in software.
When using a software control loop (Lars' GPSDO, STM32GPSDO or Erik's GPSDO), changing the corner frequency of the low pass filter is as simple as changing the value of a constant or variable. In Lars' GPSDO and the STM32 GPSDO, this is a constant defined at compile time, in Erik's GPSDO this is a variable that "adapts" to the stability of the TCXO.
When using an analog hardware control loop as in the Miller design and various old commercial GPSDOs, changing the corner frequency of the low pass filter requires changing an onboard capacitor and resistor pair. Also, since the capacitor and resistor are temperature sensitive, the corner frequency will change with temperature, and will also be affected by aging of the components.
Back in the early 2000's when James Miller came up with his simple GPSDO design, the use of a hardware control loop was justifiable and was an ingenious solution. But we are in 2021, and an MCU development board can cost as little as $2. A software control loop is a superior, cost effective solution, without a shadow of a doubt.
-
FYI - here is a link to an excel table for calculating the filter parameters of a XOR based Miller design.
https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070 (https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070)
Thanks for sharing that but TBH, I'm not quite sure how to apply the calculations. I do know that my OCXOs have a EFC sensitivity of around 3Hz per volt but I think any further optimisation of the LPF will only offer me a marginal improvement at best.
I'd been dithering about how exactly to phase lock an OCXO to the output from a GPS receiver module when I came across Gyro's posting of the circuit I've attached below. Its utter simplicity neatly condensed the essentials to galvanise me into lashing together my very first GPSDO project.
I think I was still stuck with that 13MHz OCXO and a bunch of TTL magic to generate the required 10MHz output so had enough complexity of my own to persuade me to take just the bare minimum of his circuit to start experimenting. I simplified his further by eliminating the opamp and its RC LPF by simply taking the PLL's LPF output straight to the EFC pin. I'd figured it wouldn't seriously compromise its performance and this turned out to be the case. From then on, I was finally up and running to developing my own improved versions.
What I basically did was keep to his 10:1 ratio between R1 and R2 (there was no R3 in his circuit) and ditto for the capacitors, merely scaling the caps up to 470 and 47 μF and using larger and larger R values once I'd added a 5v cmos RRO opamp back in. I just took it on faith that he'd chosen ratios close to the optimum and this does seem to have been the case.
I've since tested with TCs ranging from a low of 100 to a high of 5000 seconds with no great variations in stability (with a NEO M8N module - it might be a different story now I'm using NEO M8T modules). I landed up compromising on a TC of 1200 seconds but I might revisit the 5000 seconds option now that I'm using NEO M8Ts.
The protracted startup to lock times, despite the inclusion of a startup accelerator circuit don't overly concern me since you need to allow a good 10 to 15 minutes (preferably longer) for the OCXO to warm up and stabilise anyway. In fact, despite the note on my MK II diagram, I think I'd managed to reduce the time to lock from cold power up to just over ten minutes with a TC of 5000 seconds (although that result might have been with a TC of 2000 seconds).
When you're running a reference oscillator where the addition of an on/off switch would be an act of insanity because any sane person wouldn't dream of shutting down a piece of kit that's best left to run 24/7 year in year out if they could possibly help it, even a run up time of an hour or more to achieve 'lock' will be of no consequence in this case.
Anyway, I'm about to re-aquaint myself with a nano 3 that's currently got an edited version of the Blink program on it from when I last tried it out over six months back in order to run a barometric sensor sketch to test out that BMP280 module and start getting my eye in on all this microcontroller malarky. It'll probably go rather quiet from my end for a while as I suspect some here will be pleased to hear.
My apologies to AndrewBCN for the "Off Topic" contributions but I thought they might help Bob's endeavours to build himself a GPSDO, eventually based on your design efforts, by offering him a gentler route into making up a simple and basic James Miller inspired design from which to work upon and gain some valuable experience. After all, the required parts for such a basic GPSDO are also the very same essentials he'd need anyway to build your design.
As already mentioned I've attached a copy of Gyro's simple GPSDO image file to help clarify my description of the cutdown version I'd used as a prototype for my own humble efforts.
-
...
My apologies to AndrewBCN for the "Off Topic" contributions but I thought they might help Bob's endeavours to build himself a GPSDO, eventually based on your design efforts, by offering him a gentler route into making up a simple and basic James Miller inspired design from which to work upon and gain some valuable experience. After all, the required parts for such a basic GPSDO are also the very same essentials he'd need anyway to build your design.
...
Apologies accepted however:
1. To be honest I would prefer if you would start your own thread and post in it your experiments with your rubidium oscillator. Your numerous long posts are completely off-topic in this thread.
2. Imho the James Miller GPSDO (as well as the numerous GPSDO designs copied or "derived" from it) is more complex to understand, more expensive to build and technologically obsolete, compared to either Lars' GPSDO or the STM32 GPSDO. It was a valid GPSDO design 20 years ago, but not in 2021. Btw James Miller himself has ceased selling his GPSDOs in 2017.
3. If you want to exchange exclusively with Bob you can use the Private Messaging option in this forum, there is no need to post here in this thread.
-
FYI - here is a link to an excel table for calculating the filter parameters of a XOR based Miller design.
https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070 (https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070)
Very, very nice.
However, it clearly shows how an analog PLL hardware control loop is limited when compared to a PLL or FLL control loop implemented in software.
When using a software control loop (Lars' GPSDO, STM32GPSDO or Erik's GPSDO), changing the corner frequency of the low pass filter is as simple as changing the value of a constant or variable. In Lars' GPSDO and the STM32 GPSDO, this is a constant defined at compile time, in Erik's GPSDO this is a variable that "adapts" to the stability of the TCXO.
When using an analog hardware control loop as in the Miller design and various old commercial GPSDOs, changing the corner frequency of the low pass filter requires changing an onboard capacitor and resistor pair. Also, since the capacitor and resistor are temperature sensitive, the corner frequency will change with temperature, and will also be affected by aging of the components.
Back in the early 2000's when James Miller came up with his simple GPSDO design, the use of a hardware control loop was justifiable and was an ingenious solution. But we are in 2021, and an MCU development board can cost as little as $2. A software control loop is a superior, cost effective solution, without a shadow of a doubt.
There's no argument with those last two statements, however I do think you're rather overstating the case against using a James Miller type of hardware PLL'd GPSDO design.
The limitations of tuning a hardware PLL filter are only an issue during the development phase when proving the calculated values are actually optimised, Once set and in production, there's no further need to experiment with different values. Also, even if the tempco was as high as 1% per deg C on the LPF components, it would make only an imperceptible difference. It's not as if they're highly stressed like the caps in a switching regulator or psu and ageing isn't a thing with caps and resistors when faced with no more stress than what they'd suffer under storage conditions.
You might want to take another look at that leapsecond.com page here:- http://www.leapsecond.com/pages/gpsdo/ (http://www.leapsecond.com/pages/gpsdo/) before condemning the James Miller design out of hand. It was only beaten to first place at the 40,000 seconds mark by the Thunderbolt. It exhibited no unusual behaviour to mark it out as not being a microcontrolled design like its three competitors.
There's no need to extol the already well known virtues of using microcontrollers by extolling the overstated vices of analogue solutions, especially when you fail to mention the downsides of having to account for the effect of temperature on critical sub-components such as DACs and voltage regulators and so on - all things that are rather neatly dealt with in the James Miller design by the action of the PLL in handling their effects and that of the OCXO's drift as a single source of error to be corrected.
Don't get me wrong, I can well see the shortcomings of the James Miller design in the face of the residual sources of error inherent in the GPS system itself when relying on a single frequency band receiver to discipline an OCXO. In the end, no matter what technique is used, it will be limited by the medium term stability of its OCXO. I'm going to cheat my way past this limitation by disciplining a temperature stabilised and barometrically compensated Rb oscillator instead. >:D
Now I'm off to make a long overdue appointment with a 'blinking' nano 3 and its friend, the Arduino IDE but only after I've had a good night's sleep!
-
An advantage of microprocessor based GPSDO control over analog control is it can make estimates of its own accuracy. As far as I can see, the only way to test an analog design is to compare it with a better design. The GPS signal is long term the best reference that most of us can access, and a uP is able to accumulate data comparing the local oscillator with the arrival of 1pps. A second advantage is a uP can be programmed to be adaptive.
Something that still confuses me is Allan Deviation. I assume the only way to measure?/calculate? this is by comparison with a better reference than the system being measured. Is the reason they all head for 10-13 after 10,000 seconds because they are all locked by one means or another to GPS? Does that have practical meaning? Johnny B Good links to an article that shows the Miller design is beaten by the Thunderbolt after 40,000 seconds. Is that due to differences in OCXO or differences in control? and is that difference significant?
It seems to me there are two groups of GPSDO makers - the ones who will use the GPSDO as a reference for other things, and therefore is the most accurate piece of equipment they own - and ones who are trying to make better and better GPSDO for a challenge (when some already own a cesium beam reference). People in the first group would like to know their equipment meets some standard. With an analogue design they just have to take it on trust that their equipment meets the standard. With a microprocessor design it is possible to demonstrate it (although as noted early Leo Bodnar designs had a software error that ensured it was inaccurate).
So I am firmly in the microprocessor camp, not because I think it results in superior performance (I believe this ultimately comes down to choice of OCXO and the careful design of the supporting circuitry and environment), but because it gives better bang for buck for those on a budget. They are the ones most likely to use a GPSDO as a reference device. They won't be looking for ultimate accuracy, just better than what they already have.
-
Just grafting a microprocessor onto a previous analog design doesn't necessarily result in a "better" GPSDO.
The STM32 GPSDO was designed from the start around the capabilities of the STM32F411CEU6 "Black Pill", and makes extensive use of all the available peripherals in the STM32 MCU. The result is a fully featured experimental GPSDO that compares well to what I consider the "Gold Standard" of modern DIY GPSDOs, Lars' GPSDO.
It is extremely unfortunate that Lars is not among us anymore, I am sure he would have very interesting remarks and his insight would be most valuable.
-
@MIS42N
Just one tiny nit pick, if I may. It seems to me that the last sentence is missing the word "initially". :)
-
@MIS42N
Just one tiny nit pick, if I may. It seems to me that the last sentence is missing the word "initially". :)
:-DD :-DD so true.
It depends on how you interpret that sentence. Having acquired a GPSDO, it then becomes part of their kit and they then want to know if it performs well. So they acquire a better GPSDO. It's an iterative process - leading down one very long rabbit hole.
I have no use for a GPSDO at all. I like the programming challenge. I am now hooked on the electronic challenge as well.
-
@MIS42N
Just one tiny nit pick, if I may. It seems to me that the last sentence is missing the word "initially". :)
I can subscribe to that, oh my...
-
It is great we have got here more threads on different approaches to the GPSDO design!!
:-+
To the discussion on "old" Miller design (or any MCU-less one) - could we somehow formalize which one is better for a specific use? For example I want to use 10MHz GPSDO as a reference for my QO-100 satellite operation. Do I need to mess with SW one? Is the simple Miller ok for that?
From my practical experience with the Miller - there are 2 issues I see:
1. when the loop is disrupted it takes a few multiplies of the LPF filter time constant to get "locked".
Note: "locked" in Miller means you are as close as possible to the "right" EFC such you get 10MHz. There is none indication it happened, however, unless you measure the EFC voltage (I did).
2. when having a Neo module without a backup battery you have to set up the Neo module (to say a 10kHz output) via an MCU at the start (thus you need the MCU either).
With SW designs you can almost immediately "judge" you are close to 10MHz because you can remember the statistics history, thus you know that "this DAC setting is as close as possible to the 10MHz" (provided your DAC and OCXO are long time stable).
Otherwise, when locked, it does not matter whether you run Miller or any SW GPSDO, imho..
-
It is great we have got here more threads on different approaches to the GPSDO design!!
:-+
To the discussion on "old" Miller design (or any MCU-less one) - could we somehow formalize which one is better for a specific use?
...
Imo, to answer your questions:
1. As I wrote before, just because a GPSDO has an MCU means nothing. It all depends on how the MCU is used, in other words, on the program.
2. Please define "better". In the case of a DIY GPSDO, this could mean many, many things.
3. I am not at all critical of the Miller GPSDO design, quite the contrary actually. But technology has evolved while his design did not. So, in 2021, it's obsolete. Note that obsolete does not mean it was a bad design or didn't do its job many years ago, similar to the Apollo Guidance Computer on the lunar lander that put men on the moon some 50 years ago.
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
4. There are so many potential advantages to using an advanced MCU in a GPSDO (or any lab instrument) that I can't really make a list, it would just be too long. However, as I noted above, these potential advantages translate into reality if and only if the software/firmware implements them. Conclusion: the software really matters when you add an MCU to a GPSDO (or, again, any lab instrument).
Let's see some advantages of the STM32 GPSDO vs other designs:
1. Inexpensive.
2. Can be assembled on a breadboard in two~three hours.
3. Easily purchased components.
4. Informative OLED display.
5. Low power consumption (< 5W).
6. Full suite of sensors.
7. Modular.
8. Bluetooth interface to a smartphone.
9. Full GPS status reporting.
10. Open source hardware and software.
11. No adjustments, works "out of the box".
12. Hardware implements both PLL and FLL control loops. (Note: the PLL software is still work in progress)
13. Upgradable firmware. Flashing a new firmware takes less than a minute.
14. Uses a powerful 100MHz 32-bit ARM Cortex-M4 MCU.
And there are some disadvantages:
1. No PCB yet - this is coming ASAP.
2. Not a commercial project, you can't buy it assembled or as a kit.
3. People with no programming background may be put off by the GPSDO software, or how to flash the STM32 MCU.
4. Still an evolving project (Beta stage).
5. There is no user manual yet.
6. Even though it is probably capable of better performance, the claim is 1ppb (10E-9) short term accuracy/stability. That translates into 0.01Hz frequency or 10ns phase accuracy/stability; or 1 second every 32 years, but I honestly doubt anybody is going to keep a GPSDO running continuously for 32 years... ;D
-
Now it is becoming realistic.
Thanks,
Frans
-
Advantage number 3 isn't working for me. I am still in the midst of a dispute with Aliexpress. Each time a deadline is reached, a new one appears. I ordered this thing in June and the latest 2-day deadline produced a new 10-day deadline. I despair of ever getting this thing assembled. Even if they send a new one it will take several weeks to arrive. (I am not measuring these times with my not-yet-built GPSDO, but with an old fashioned calendar.)
It certainly has been a learning experience, but not one I had anticipated. I have built quite a bit of stuff over the years but this one is very frustrating.
Pardon me for venting here; I don't expect any useful replies other than to throw more money at the project and order from someone else. Thanks for reading.
-
To the discussion on "old" Miller design (or any MCU-less one) - could we somehow formalize which one is better for a specific use? For example I want to use 10MHz GPSDO as a reference for my QO-100 satellite operation. Do I need to mess with SW one? Is the simple Miller ok for that?
:
:
Otherwise, when locked, it does not matter whether you run Miller or any SW GPSDO, imho..
It looks like you answered your own question. When locked, for practical purposes it doesn't matter. My experiments are all microprocessor based so no experience with Miller.
When looking at a practical application, need to specify what is actually required. For satellite operation at 2.4GHz is +- 3Hz OK? That's an accuracy of 1 part in 10E9 and as discussed just about any GPSDO should achieve that. I am running a test at the moment, the worst figure for the last 8 hours is 2 parts in 10E10. Using a $4 second hand OCXO.
So it becomes a matter of trust. Can you trust your Miller design to be locked? If so, then use it. Can you trust the software in a microprocessor? if so, use it.
My preference for uP based systems is because it can tell you when it is locked (I do that through a LED). Also it is very flexible. I use the 1pps from the cheapest GPS module straight into the processor and measure TIC to nearest 25ns. Since the jitter on the module is estimated to be 20ns they are a good match. The uP averages that (similar to a PLL but in software). Also the uP decodes the NMEA messages to ensure the GPS module thinks it has a fix (adequate signal). Can't do that with a Miller design.
The downside is that the disciplining algorithm is up to the programmer. Plenty of scope for mistakes.
-
The main justification for adding a processor is allow more functionality than just output of am accurate reference frequency. Technically, for this purpose the G3RUH design is just fine.
You add a processor if you want to experiment with control algorithms, have more status info than just a "locked" LED or just want more functionality in general. I made a GPSDRO with an STM32 and a TDC7200 and it worked really nicely, but then I realized that I'm wasting a lot of potential and that using a Linux SBC as the basis would open up a whole set of additional functions I hadn't thought about. For example, a stable 1PPS output without GPS jitter, a Stratum 1 NTP server, a PTP grandmaster, ...
-
When a 5ft (1.5m) GPS cable costs twice as much as a complete STM32 GPSDO...
Perhaps you have heard about a little company called FacePlant or something. It turns out their engineers decided to design an "open source" GPSDO on a PCI-e card, except of course they don't call it a GPSDO. They call it a "Time Card". See the attached diagram.
They claim anybody can build their "Time Appliance", given enough time and money... lots of money and lots of time apparently. A 1.5m GPS cable for their GPSDO Time Card costs $77:
https://store.orolia.com/collections/accessories/products/antenna-cable?variant=32314965721166
( :wtf: What use is a $77 1.5m GPS cable, you may wonder? Well, I wonder too.)
Apart from that, their GPSDO Time Card would require a number of "unobtainium" parts, but you can go over the fine details of the project here: https://github.com/opencomputeproject/Time-Appliance-Project if you can make sense of their documentation.
Having poured some tens of engineer.years and no doubt about a couple of $ millions or more into their project, what is their claim for accuracy/stability? Well of course they don't give us an Allan Deviation number, because why should they follow long established standards for measuring clock accuracy and stability?
Instead, we get this, which is comically naïve:
"Indeed, when we compare 1 PPS between Time Card output and the internal reference of the Calnex Sentinel, we see that the combined error ranges within ±200 nanoseconds..."
So, 200ns jitter. Can't say I am impressed really. :palm:
I am hereby declaring that I am challenging FacePlant that I can build a better GPSDO Time Card at less than 1/10 their cost, with at least 2x better performance, using three months of my spare time, with a total development budget of $5,000. Ouch! :box:
https://engineering.fb.com/2021/08/11/open-source/time-appliance/
-
My preference for uP based systems is because it can tell you when it is locked (I do that through a LED). Also it is very flexible. I use the 1pps from the cheapest GPS module straight into the processor and measure TIC to nearest 25ns. Since the jitter on the module is estimated to be 20ns they are a good match. The uP averages that (similar to a PLL but in software). Also the uP decodes the NMEA messages to ensure the GPS module thinks it has a fix (adequate signal). Can't do that with a Miller design.
That last remark is true enough with the original Jupiter T based version but if you upgrade that vintage Jupiter T to a u-blox 7N or 8N (preferably an M8T) and chuck an FTDI232 into the mix, you can do some cunning reprogramming of the PPS line to output any frequency and duty cycle of your choosing (within the 1Hz to 24MHz range allowed) for each of the locked and unlocked states. A very useful feature when all you require (as you implied) is a simple LED indication to show whether it is locked or not. :)
I was using fake M8N modules during the time I was developing the MK II. These didn't have flash ram to store the user settings through an indefinite power down, relying only on the BBram's 40 minutes or so reserve provided by a cheap 80mF supercap. This limitation was bypassed by simply adding a CR2032 with a backfeed protection diode (and, optionally a 1k series resistor to provide short circuit protection but mainly to verify the claimed 14μA consumption of the BBRam circuit).
Even though the CR2032 cell gave you an accumulated total powered down time of some 280 days of backup, I still needed some clear indication that it hadn't reverted to its default settings so I programmed the PPS to output 4Hz 50% duty cycle when unlocked and a 100KHz 50% when locked. There was little point in trying to phase lock the OCXO with a 100KHz derived from its 48MHz TCXO so I figured I'd be damned if I tried to do so anyway.
More usefully, the 4Hz 50% duty cycle would produce an EFC midway between 0 and 5 volt, reasonably close to the 2.421v mark (at that time - it's now dropped to 2.381v some 12 months on) when locked to a valid 100KPPS. I could have programmed the duty cycle to place it even closer if it had occurred to me at the time but my main concern was to generate an "Unlocked to GPS" indicator on the green 'Lock Status' LED that could also alert me to a loss of user settings and reversion to the default 1PPS at 10% duty cycle where it would visibly blink (or wink) at 1PPS - the locked state is a steady but slightly dimmed glow adjusted to match the brightness of the red power on LED which, it could be argued as being an unnecessary indicator.
I did briefly consider this 'minimalist approach' but decided it would not only provide a reassuring confirmation of its powered up status with a cheerful red glow, it would also, in that rarest of scenarios, take the guesswork out of deciding whether a completely extinguished green LED was due to an internal fault or just a missing 7 to 24 volt supply to the whole GPSDO. A modicum of redundancy being no bad thing in this case.
The point in this case being that a modern day re-spin of the James Miller GPSDO effectively provides you with a user programmable microcontroller at the heart of these u-blox modules with sufficient end user options to make a second microcontroller redundant when all you need are simple LED indications of the GPSDO's status. :)
I don't deny the benefit of using a microcontroller (with appropriately sophisticated DSP based algorithms) to greatly improve on the James Miller's erstwhile excellent performance at its inception but, as you were careful to point out, only with carefully thought out and bug free firmware (not overlooking the need to minimise the sources of error arising out of the design and assembly of the actual hardware itself).
If you're aiming to develop a better than James Miller performance GPSDO via the microcontroller route, it might help to actually have a James Miller type of GPSDO on hand from which to improve upon, even if merely to provide a 'sanity check' on your own modest efforts, besides which, it can give you a better insight into the full extent of the problems you'll be dealing with... imho. :)
Right now I'm working on figuring out an arduino based temperature controller having successfully got the BMP280 with OLED1306 display module sketch to work as a beginner's exercise and test utility. The Banggood 128 by 64 display was using the 0x3C address of the 128 by 32 version mentioned in the comment line of that sketch so I only had to edit the defined 0x3D address to get it to display the BMP's output.
I've tracked down a sketch that uses thermistor input rather than temperature sensing module I2C outputs. Now all I have to do is figure out how to process and output this via a PWM pin to drive the switching FET controlling the cooling fan's speed between minimum and max as smoothly as I can.
I'm just building towards a micro controlled GPSDRO one baby step at a time at this stage of the game and I need all the experience I can gain. ;D
-
Well, you'll have to provide some means to beat all their specs then, and while I too think that their solution is probably a bit overengineered (I'm quite sure you don't need an FPGA and a ublox F9T for decent GPSDO), without an atomic clock you'll not beat the holdover performance, and without a timestamping NIC you won't be able to distribute the time with the necessary accuracy. So, some money will have to change hands.
-
Well, you'll have to provide some means to beat all their specs then, and while I too think that their solution is probably a bit overengineered (I'm quite sure you don't need an FPGA and a ublox F9T for decent GPSDO), without an atomic clock you'll not beat the holdover performance, and without a timestamping NIC you won't be able to distribute the time with the necessary accuracy. So, some money will have to change hands.
Indeed. It wouldn't be fun and it wouldn't be a challenge if it didn't require some "thinking outside the box". :popcorn:
-
I did briefly consider this 'minimalist approach' but decided it would not only provide a reassuring confirmation of its powered up status with a cheerful red glow, it would also, in that rarest of scenarios, take the guesswork out of deciding whether a completely extinguished green LED was due to an internal fault or just a missing 7 to 24 volt supply to the whole GPSDO. A modicum of redundancy being no bad thing in this case.
I took the minimalist approach. If the LED isn't doing something, something has failed. It makes different indications for power on, OCXO failure, satellites in view, trying to lock, locked but not verified as 10E-9 accurate, and verified. The use of 1 LED was partially philosophical (why have two when one will do) and partially practical (ran out of easy options to program a pin).
I spent a few minutes looking through the Time Card documentation, talk about using a bulldozer to crack a nut!!
I doubt that AndrewBCN could deliver on his challenge, but what would be the point? The thing overspecified to the extreme. It seems most synchronisation needs are in the microsecond region, so specifications like this seems a bit over the top:
PPS out
PPS Out Rise/Fall Time < 5 nano Sec
PPS Out Delay < 400 pico Sec
PPS Out Jitter < 250 femto Sec
PPS Out Impedance = 50 Ohm
PPS Out frequency 1Hz - 10MHz (a new meaning for PPS?)
I question the need for holdover - "In the event of the GNSS signal loss". I have never seen signal loss of more than a few seconds, and that is rare. I just looked at stats from my current test, over 500,000 seconds and no loss. The losses are categorised as 'Lost Fix' (the NMEA data says fix is lost), 'missing 1pps' (expected to be in a 1ms wide window) or 'discarded' (in the window but not within +- 400ns) and the figures are zero for all. The GNSS has multiple constellations each of which has redundant satellites. They are not going to fall out of the sky and they are not going to run into each other. What sort of event causes losses greater than a few minutes (which any decent OCXO will hold within a few nanoseconds). And if it is a worry, put in a redundant GPS derived time source.
Then there's the interesting idea that the time card goes in a PC that then talks to a NIC. The PC clock isn't synchronised to anything so inevitably introduces some jitter. Or "For the extremely high precision 1PPS output of the Time Card will be connected to the 1PPS input of the NIC, providing <100ns precision". Whoopy do. Does this need a PPS with jitter < 250 femto seconds and delay of 400 pico seconds?
A solution looking for a problem to solve?
When people really need synchronised clocks, they do it by independent dual band GPS receivers. For most commercial use, a few microseconds is immaterial. Years ago I supervised the implementation of time synchronisation on many thousands of PCs and servers. We were happy if they agreed to the second.
-
The holdover specification is a legacy from pre-2000 GPS receivers, when the world had a single constellation of timing satellites, and some or most of them could be brought off-line at any time, arbitrarily, by the US military. When NTP servers and entire communication networks depended on these GPS satellites, you had to have a specification for when the GPS system was brought off-line. Hence the different holdover requirements for different NTP strata servers.
In the case of a GPSDO, the holdover specification refers to the maximum drift over an arbitrary specified period, usually 24 hours, and/or one month and/or one year. As MIS42N wrote, these holdover specifications don't make much sense in 2021, when any commercial GPSDO and even a $35 DIY STM32 GPSDO can be kept working uninterrupted and permanently GNSS locked for any length of time (hence with essentially zero drift relative to GPS time).
Also NTP servers check on each other, the whole NTP infrastructure is extremely resilient and if you want to make sure your local network always has accurate time, just use two, three, four or more inexpensive GPSDOs connected to properly distributed Linux NTP servers (which don't even need to be dedicated machines).
As MIS42N wrote, the FacePlant GPSDO Time Card is ridiculously overengineered, over and under specified, absurdly expensive and worst of all, constitutes a single point of failure if an entire FacePlant data center depends on it. It's a solution looking for a problem that doesn't exist, and it's also a security risk for an entire data center to be brought down because of a single hardware or software failure.
Oh, I stand by my challenge. :popcorn:
-
What irks me most about the TimeCard is the effort spent on a nearly jitter-free, low-delay PPS output (well, edges could be a bit faster, but hey...) just to feed it into the PPS input of a network card which then wastes all the precision because its timestamping is not nearly at the same level.
PS: Adding insult to injury, the PHC that delivers the timestamps is asynchronous to the wall clock of the PC which requires synchronizing that clock to the PHC using a software PLL, which additionally degrades the stability of the end result.
-
Erik (erikka) has noticed an important error in the schematics Rev 0.4: I had inverted pins PB10 and PA15. I am attaching below the corrected schematics, Rev 0.5.
Many thanks to Erik, of course. :-+
Btw, Erik is testing the use of the cheaper, but with less RAM and ROM, STM32F401 Black Pill. For most purposes, it's a drop in replacement, except for one detail: the 10,000 seconds 64-bit ring buffer does not fit in 64KB of RAM. No big deal, since we can use a 5,000s ring buffer with a one-bit loss of resolution in our 0.0001Hz frequency measurements.
More news on this front as Erik progresses with his experiments.
-
Ian Cutress did an interview with a Facebook engineer involved with this on his Youtube TechTechPotato channel:
“Democratizing Time: Hands on with an Atomic Clock PCIe Card”
https://www.youtube.com/watch?v=Gr7sZ4MPMu8 (https://www.youtube.com/watch?v=Gr7sZ4MPMu8)
It's maybe not the best interview ever, but it gives an overview and helps explain design choices like the oscillator. Holdover requirements really are still here in 2021.
-
"It's maybe not the best interview ever..."
That's quite the understatement. It's a terrible interview.
The name of the FacePlant engineer is Oleg Obleukhov (also the co-author of the blog post I linked to), and during the entire interview he does not refer so much as once to the essential concepts of Allan variance/deviation, just as in the blog post.
Clearly the team that designed the FacePlant GPSDO "Time Card" skipped on the fundamentals, tried to compensate for that lack of basic knowledge by overengineering the "clock processing logic" aka "time engine" (the FPGA), worked hard on "re-inventing the wheel" of GPSDOs, and failed.
One excerpt from the blog post: "The time engine’s job is to interpolate in nanoseconds the granularity required between consecutive PPS signals." That translates to "We reinvented a nanosecond resolution TIC using an expensive FPGA, to measure the phase difference between the oscillator and the GPS PPS".
Lars used a $0.50 4046 and a few discrete components to achieve the same thing, and the STM32 GPSDO uses Erik's version of Lars' TIC that requires a $0.10 74HC74 and a few discrete components, plus a few lines of code in the STM32 MCU. And it probably has better overall resolution than the FacePlant TIC "Time Engine" (implemented in the FPGA).
If your $50 million datacenter cannot afford a pair of good $50 rooftop GNSS antennas :wtf: then I guess yes, in your case holdover specs still matter in 2021. :palm:
Oh, and the most incredible "feature" of the FacePlant GPSDO "Time Card" is probably the most obvious one, and also the reason I mentioned the FacePlant project in this thread in the first place: they spent > $3,000 and are using an 8-layer PCB with plenty of empty space, but they couldn't fit a $5 32-bit ARM MCU in their design. |O
-
After checking with Erik, I made one small change to the TIC circuit: the 1N4002 diode is replaced with a 1N5711 Schottky diode with 1ns reverse recovery time or equivalent. The 1N4002 definitely should not be used for the TIC.
Attached the revised schematic.
I have received the components to build the TIC circuit and I'll add it to one of my three STM32 GPSDO prototypes for testing.
An excellent, detailed description of how the TIC works can be found in Lars' documentation, for those interested.
As I wrote before. adding a TIC / phase difference measurement circuit to the STM32 GPSDO allows the implementation of a PLL control loop, or something that has never been tried before AFAIK: a hybrid PLL/FLL control loop.
-
"It's maybe not the best interview ever..."
That's quite the understatement. It's a terrible interview.
It's maybe a bit of an unfortunate combination. Sometimes even those who really know their stuff are not so good at explaining it to a general audience. A good interviewer can guide things along, but in this case Ian appears to be a bit out of his specialist area so can't that help much. Even so, it gives a good bit of context.
The name of the FacePlant engineer is Oleg Obleukhov (also the co-author of the blog post I linked to), and during the entire interview he does not refer so much as once to the essential concepts of Allan variance/deviation, just as in the blog post.
This project does all seem to be very much a work in progress, and there are not a lot measurements given. The Orolia page on their ART card also has very few details. The official announcement was very recent, so hopefully there will be more info sometime.
A statistic like Time Deviation would be needed to give an overview of the performance, but along the way these statistics are just one of many ways of looking at the data.
A time error plot is given for the SA.53s oscillator, which at least gives some indication of the holdover performance.
Clearly the team that designed the FacePlant GPSDO "Time Card" skipped on the fundamentals, tried to compensate for that lack of basic knowledge by overengineering the "clock processing logic" aka "time engine" (the FPGA), worked hard on "re-inventing the wheel" of GPSDOs, and failed.
One excerpt from the blog post: "The time engine’s job is to interpolate in nanoseconds the granularity required between consecutive PPS signals." That translates to "We reinvented a nanosecond resolution TIC using an expensive FPGA, to measure the phase difference between the oscillator and the GPS PPS".
Lars used a $0.50 4046 and a few discrete components to achieve the same thing, and the STM32 GPSDO uses Erik's version of Lars' TIC that requires a $0.10 74HC74 and a few discrete components, plus a few lines of code in the STM32 MCU. And it probably has better overall resolution than the FacePlant TIC "Time Engine" (implemented in the FPGA).
Although the basic GPSDO is important, it's only one small part of what the card has to do. Given the info in the interview, it's these other requirements that would appear to be driving the FPGA selection. The FPGA on the Orolia card looks like one of the higher pin count Cyclone 10 FPGAs.
Although there are low cost TDCs around, they seem to want the Time Card to be the start of a larger project, so I can understand why they would want to integrate it in the FPGA. It also allows a lot of flexibility.
If your $50 million datacenter cannot afford a pair of good $50 rooftop GNSS antennas :wtf: then I guess yes, in your case holdover specs still matter in 2021. :palm:
The holdover requirement is in case of any GNSS signal loss, not just a bad antenna. This can sometimes be official, like the military testing jamming or whatever, but is probably more often less official. Since the signal is such low power, something like a faulty power supply or inverter can jam GNSS signals over a significant area. If a company is providing any service that needs precise time, it needs to take this sort of scenario into account as there could be serious financial and even legal consequences if the service goes down because of something foreseeable like this. Pretty much any GPSDO supplier will show holdover as one of the specs, especially for rubidium oscillator based units.
Oh, and the most incredible "feature" of the FacePlant GPSDO "Time Card" is probably the most obvious one, and also the reason I mentioned the FacePlant project in this thread in the first place: they spent > $3,000 and are using an 8-layer PCB with plenty of empty space, but they couldn't fit a $5 32-bit ARM MCU in their design. |O
The FPGA, which is needed for other things anyway, would likely make it redundant.
-
...
This project does all seem to be very much a work in progress, and there are not a lot measurements given.
...
For companies that depend on reliable, precise timing, a "work in progress" product that doesn't provide a clear service out of the box is not an option. There are fully characterized PTP servers available commercially, with guaranteed performance ; here is a ready-to-rack-and-connect example: https://www.cxr.com/en/produits/vcl2156-ntp-ptp-263.html (https://www.cxr.com/en/produits/vcl2156-ntp-ptp-263.html)
Disclaimer: I have zero connection with CXR.
-
Well, seems like they don't like the security risks connected with these time appliances. That was one of the drving forces to build an open source solution.
-
I watched about half the video then skipped through and sampled the rest. There didn't seem to be any solid information about why sub microsecond timing is so important. If transaction A is initiated 1us before transaction B but from a distance 1000m further away it will arrive at least 2us later. Either ignore the fact that A arrives after B and process them as if B were first, or create a queue based on time stamps. The queue solution is problematic. How long to wait for message A before processing B? Maybe there is no A, so every message must be stored for the latency of the longest delay. Or have a system that can reverse out any action if a previous stamped action is received. How far does the reversal go? It is the stuff of programming nightmares.
And once in the realm of microseconds, there's many other considerations - interrupt latency in the computer, the fact instructions are executed at discrete intervals, delays in cables.
It seems there are two sorts of time requirements. The sort that would be used for scientific purposes such as imaging a black hole. In that case, the 'time card' is not going to be good enough - the observatories would use something more accurate than a rubidium cell as their base, and try to maintain picosecond synchronisation around the globe. The other requirement is in the commercial world, and given the delays intrinsic in networks a sub millisecond accuracy would be good enough and the 'time card' is overkill.
Just my thoughts. I can see that NTP may not be good enough today. I had a look at my server and it reports variations of about 10ms (which is good enough for my wife who looks at the computer clock and decides it is time to cook dinner). However even a poor OCXO can have sub millisecond holdover for 24 hours.
So is there justification for this 'time card'? The effort around it - to have open standards and a forum - make a lot of sense. The card itself, not so sure.
-
Well, seems like they don't like the security risks connected with these time appliances. That was one of the drving forces to build an open source solution.
Uh? What "security risks" do they associate with a commercial PTP server? PTP/IEEE1588 Rev. 2 is a well defined standard, whether you publish the source files for your implementation of it, changes exactly nothing.
Also, the FacePlant PTP server "package" doesn't seem to work out of the box, actually it looks more like a nightmare to integrate into a network - if it works at all. :horse:
-
Andre, As you were so kind to help me with the right components its was a quick task to assemble your GPSDO on a breadboard and do some experiments.
YOu code is well formatted with relevant comments so it was easy to find my way.
First questions:
Looking at this part of the code and having looked at the frequency measurements this part of the control loop is a bit puzzling:
// check first if we have the data, then do ultrafine frequency adjustment
// ultimately the objective is 10000000.000 over the last 1000s (16min40s)
if ((cbTho_full) && (avgftho >= 9999999.990) && (avgftho <= 10000000.010)) {
// decrease frequency
if (avgftho >= 10000000.001) {
if (avgftho >= 10000000.005) {
// decrease PWM by 5 bits = very fine
adjusted_PWM_output = adjusted_PWM_output - 5;
} else {
// decrease PWM by one bit = ultrafine
adjusted_PWM_output = adjusted_PWM_output - 1;
}
analogWrite(VctlPWMOutputPin, adjusted_PWM_output);
}
// or increase frequency
else if (avgftho <= 9999999.999) {
if (avgftho <= 9999999.995) {
// increase PWM by 5 bits = very fine
adjusted_PWM_output = adjusted_PWM_output + 5;
} else {
// increase PWM by one bit = ultrafine
adjusted_PWM_output = adjusted_PWM_output + 1;
}
analogWrite(VctlPWMOutputPin, adjusted_PWM_output);
}
}
Do I read the code correctly that you do nothing if (avgftho == 10000000.000)?
That would imply that avgftho == 10000000.000 is the dead zone. And I indeed see the frequency wander between 9999999.999 and 10000000.001
Is the range of the PWM sufficient to go one decade lower?
If yes you can move ultra ultra fine down when (avgftho == 10000000.000) and up when (avgftho == 9999999.999) to avoid the dead zone.
Or am I missing something?
Next question:
After adjusting the PWM you do not flush/restart the ring buffers so at the next call to adjustVctlPWM the avgtho could still contain a large amount of data from before the PWM adjust.
Is that on purpose? I understand that if your control loop acts very slow it does not matter but if you want the OCXO to be adjusted in time with temperature changes in the room the loop should not be slower than needed. At least if you want to be as good as possible during drifting of the OCXO.
I know your chosen MCU has plenty of flash but it may be a good idea to have a critical review and elimination of duplicated code. A shorter program is often easier to fully understand.
Some small remarks from someone that tried to use your code for learning and experimenting (and if you read your own code again in some years, I've learned this the hard way):
Define symbolic names of the used MCU pins at the top of the ino and use these symbolic names in the code. THis facilitates changing pinning where allowed and acts as documentation of the HW
The control loop preferably should not have magic constants (such as '5' in the above code) but these constants should all be defined in one place together with an explanation of their value.
Suggest to add some early debugging info using the blue led (which is always available) to help people trying to duplicate your design for error cases like: no PPS, no 10MHz, no display (if enabled), frequency adjust not working as expected
-
Hello Erik,
First, thank you very much for taking the time to be my very first beta tester, and for your kind expert comments. It is quite essential to have someone with an outside view of any complex project, and for the STM32 GPSDO, you are that person. Additionally, you have an excellent grasp of all GPSDO concepts since you have built your own using an SI5351.
Let me try to answer your questions as best as I can.
...
Do I read the code correctly that you do nothing if (avgftho == 10000000.000)?
Yes. That is because my initial objective was really to achieve 10E-9 precision. At 10000000.000 +/- 0.001Hz we are already an order of magnitude better than the initial objective, so I guess it's just bonus precision at this point.
That would imply that avgftho == 10000000.000 is the dead zone. And I indeed see the frequency wander between 9999999.999 and 10000000.001
Is the range of the PWM sufficient to go one decade lower?
I honestly don't know. There is a lot of noise in the Vctl line in the breadboard assembly, with the inexpensive power supply I am using. I am waiting to have an STM32 GPSDO assembled on a proper PCB with a good power supply to explore 10E-10 and 10E-11 territory "comme il faut". :-/O
If yes you can move ultra ultra fine down when (avgftho == 10000000.000) and up when (avgftho == 9999999.999) to avoid the dead zone.
Or am I missing something?
No, you are 100% correct. I had not thought of that and I did not understand :o at first when you mentioned a deadband around 10000000.000 but now I finally realize that the simple change you suggest would make the control loop gain one bit of resolution with a very simple change in the software. That is going into the next release for sure. :-+ :-+ :-+
Next question:
After adjusting the PWM you do not flush/restart the ring buffers so at the next call to adjustVctlPWM the avgtho could still contain a large amount of data from before the PWM adjust.
Is that on purpose? I understand that if your control loop acts very slow it does not matter but if you want the OCXO to be adjusted in time with temperature changes in the room the loop should not be slower than needed. At least if you want to be as good as possible during drifting of the OCXO.
You are right, and I confess again I never thought of that. The FLL control loop is still very much in its "first writing" stage, I have been procrastinating on rewriting it, basically because I wanted o do a lot more testing and collect more data. But I have noticed that even with temperature variations of +/- 5C the control loop as it is can still keep the OCXO frequency at better than 10E-9. And here again I was thinking of waiting for the PCB to collect more serious data with frequency variations vs. temperature.
And before that I want to implement the PLL control loop with your TIC circuit, and the hybrid control loop algorithm! :scared: :scared: :scared:
I know your chosen MCU has plenty of flash but it may be a good idea to have a critical review and elimination of duplicated code. A shorter program is often easier to fully understand.
Some small remarks from someone that tried to use your code for learning and experimenting (and if you read your own code again in some years, I've learned this the hard way):
Define symbolic names of the used MCU pins at the top of the ino and use these symbolic names in the code. THis facilitates changing pinning where allowed and acts as documentation of the HW
The control loop preferably should not have magic constants (such as '5' in the above code) but these constants should all be defined in one place together with an explanation of their value.
Suggest to add some early debugging info using the blue led (which is always available) to help people trying to duplicate your design for error cases like: no PPS, no 10MHz, no display (if enabled), frequency adjust not working as expected
Defnitely those are excellent suggestions and I'll try to focus on them for the next major bump in the STM32 GPSDO revision, when I go from 0.04 to 0.05. In particular your suggestion to use the onboard blue LED as an early error indicator is a brilliant idea (another one). :-+ :-+ :-+
Please do post a picture of your setup when you have the time!
-
I found a very interesting article which compares the performance of various u-blox receiver modules. Since the STM32 GPSDO uses preferably an inexpensive (10€) u-blox NEO M8N GPS receiver module, I think the choice is fully justified when we examine the data provided by the article:
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf
by John Ackermann N8UR
What the data in the article essentially indicates is that the tested u-blox GPS receiver modules all perform more or less the same, when they are used to provide a 1PPS signal in a stationary GPSDO application.
-
That is a really informative paper and it finally explained Allan Deviation in terms I can understand. It also vindicates my decision to use the cheapest GPS units with a 25ns Tic. The sawtooth spreads the 1pps over an interval of about 22ns so if the 25ns window is exactly positioned over the 22ns sawtooth the output will read all zeros. The window only has to move 4ns one way or the other to pick up the occasional top or bottom of the sawtooth. Given the slight fluctuation in received GPS, the sawtooth itself wanders a bit so a few non zero readings are almost certain. That matches what I have observed and gives a sound basis for it. excellent.
-
I always check AliExpress for the availability of u-blox GPS modules, and recently the NEO M9N has shown up on the radar. Just to provide the context:
The M9N is > M8N > M7N > M6N, in terms of performance and in terms of price too. (see the article I linked to above)
Right now, the M9N modules cost around $40~50. The M8N modules can be found for around $10~12, the M7N for $7~10 and the bottom-of-the-barrel M6N for $5~8.
So I would say the sweet spot at this time is clearly the NEO M8N modules. I'll post an update when this changes, of course.
-
@AndrewBCN
That was a very interesting document (downloaded and added to my ublox folder). I read it all from start to end. The CEP scatter plot for the M8N closely matched that of my very first (genuine as it happened) M8N module. The subsequent fakes (needed to replace the original on account I managed to blow up the PPS output with a 12v jolt) also showed similar CEP map deviation plots.
It was interesting to note the almost constant observed sawtooth correction rate (which does depend on how close the tcxo just happens to be to its nominal 48MHz frequency as was later acknowledged in that document).
If you program the PPS to 10MPPS and monitor this frequency (or better yet, the third harmonic) with an HF receiver using narrow band FM, you can quite clearly hear these saw tooth corrections as ticks which IME can vary at a rate of from 4 per second to one every 25 seconds or longer, depending on the tcxo's temperature (cooling or warming the whole module will vary the rate - a finger tip touch is usually sufficient to reveal this sensitivity to temperature).
Fortunately, since I'm not interested in such short term (1 to 100 seconds) stability, the saw tooth corrections disappear below the noise at more sensibly chosen 1000 seconds or longer integration intervals as far as its use as a GPSDO frequency standard goes.
Whilst I still had the M8N based MK I working to compare with the MK II GPSDO, I had the distinct impression that the M8N had a much greater phase shift modulation (up to 50ns at minutes long time scales versus the 6 or 7 ns pk-pk shifts of the M8T). However, I didn't possess a GPS antenna splitter to properly compare them at that time and by the time I'd made one up, I'd already stripped the MK I to test its "Five Volt" 13MHz OCXO at potentially destructive voltages without endangering the rest of the component parts.
As it eventually turned out, this "Five Volt" ocxo did prove to be a 12 volt unit that just happened to be able to function perfectly fine from a 4.8 to 5.2v supply (mind you, it took a few seconds before it would start outputting a sine square wave on 4.8v which reduced to just a second when powered from 5.2v).
It had been my very first, one and only, ocxo that, in the absence of a datasheet, I didn't care to risk burning out before getting some use out of my 4 quid purchase - hence my playing safe and assuming it might possibly be a five volt only part.
By the time I was ready to sacrifice it on the altar of 'scientific research', I'd already gained a few clues to indicate that the experiment wasn't likely to end in tears. Indeed, I raised the test voltage to 14 volts to put its 12 voltedness beyond all doubt. >:D
I've been meaning to lash up a second MK II on solderless breadboard using another 10MHz ocxo with an M8N module to compare against the performance of the M8T using an antenna splitter to 'level the playing field'. Previous tests had involved an indoors antenna alongside of the external antenna, which setup had only served to confuse these initial comparative test results. Hopefully this time round, I'll be able to get a more definitive answer to the question, "Does replacing the M8N with an M8T make as much of an improvement as I think it does?" :-//
BTW, if anyone's interested in my DIY Rb lab reference project, I've retired the analogue temperature controller in favour of an Arduino nano setup, the details of which I posted into a seemingly moribund Rubidium oscillator based topic as per the link below.
https://www.eevblog.com/forum/blog/eevblog-235-rubidium-frequency-standard/msg3652885/#msg3652885 (https://www.eevblog.com/forum/blog/eevblog-235-rubidium-frequency-standard/msg3652885/#msg3652885)
Although there haven't been any responses so far, the number of times that the attached images have been viewed suggest it's not an entirely dead topic. I'm not the first one to have made such a necro-posting as you'll see if you look about half a dozen postings upthread. ::) Whether I'll get any replies as the first necro-posting received remains to be seen. It's early days yet :-//
-
This post is to explain why I have decided to add an optional second MCU to the STM32 GPSDO. Actually I have a very good reason for doing so.
First things first: I am adding an optional PIC12F675 (or PIC12F629) which is one of the smallest PICs available in 8 pin format. It will be programmed to function as a synchronous divider for the 10MHz OCXO output, instead of 7 decade counters. It costs under $1.
Datasheet: https://ww1.microchip.com/downloads/en/devicedoc/41190c.pdf (https://ww1.microchip.com/downloads/en/devicedoc/41190c.pdf)
Divider code: http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
Purpose: to provide an accurate 1PPS signal even in the absence of GPS reception, in other words, whether the GPSDO is operating in holdover mode or normal mode.
I still have to add the PIC to the schematic diagram and of course I have to add it to the PCB. In fact I still have to test this idea, I just ordered the PICs and should receive the ICs in two weeks or more.
-
Hmm
Why a PIC ?
I guess the vast majority of users here , would already have Arduino (AVR) programming devices in hand.
I'll not be adding that "Option"
Here is a "PicDiv" for Avr ie (T84) , by the late Ulrich Bangert
https://www.eevblog.com/forum/projects/divide-by-10000000/msg2815024/#msg2815024 (https://www.eevblog.com/forum/projects/divide-by-10000000/msg2815024/#msg2815024)
/Bingo
-
Hmm
Why a PIC ?
Because it's the smallest possible chip that does the job perfectly (8-pin DIP).
I guess the vast majority of users here , would already have Arduino (AVR) programming devices in hand.
I'll not be adding that "Option"
Here is a "PicDiv" for Avr ie (T84) , by the late Ulrich Bangert
https://www.eevblog.com/forum/projects/divide-by-10000000/msg2815024/#msg2815024 (https://www.eevblog.com/forum/projects/divide-by-10000000/msg2815024/#msg2815024)
/Bingo
Choose your favorite solution!
Three reasons why I personally prefer the PIC:
1. I have carefully examined both the PIC and the AVR source code files and the PICdiv code is much, much better quality.
2. The AVR T84 is a 14 pin DIP, and 3 x more expensive than the PIC.
3. The PIC can be easily programmed using the STM32F411CEU6 Black Pill.
-
Choose your favorite solution!
I will
-
Me in your shoes, I'd try to stop the feature creep at a point ;) Anyone wanting a 1PPS output derived from the 10MHz, can easily add their own "PicDiv" themselves. Keep in mind that a 1PPS output is not worth a lot if it's not aligned to an actual reference time, e.g. UTC seconds.
-
Hmm
Why a PIC ?
I guess the vast majority of users here , would already have Arduino (AVR) programming devices in hand.
I'll not be adding that "Option"
Here is a "PicDiv" for Avr ie (T84) , by the late Ulrich Bangert
https://www.eevblog.com/forum/projects/divide-by-10000000/msg2815024/#msg2815024 (https://www.eevblog.com/forum/projects/divide-by-10000000/msg2815024/#msg2815024)
/Bingo
PIC programming hardware is so cheap it shouldn't cause a problem. The PIC is probably a better choice for the job in this application though anyway.
-
Does anyone use a 1pps for anything? It does seem like feature creep. I had a quick look at my own project, I could generate a 1pps from the processor, no need to add another. I would need to use a PIC16F1459 to get an extra 6 pins and output 1pps using the second PWM. Since the processor clock is the OCXO, and the PWM is driven by internal circuitry, the leading edge is hardware timed and not dependent on an accurate software interrupt. It could be aligned with the 1pps from the GPS module within 25ns by slewing the OCXO frequency a bit. Maybe you could do that instead of adding more bits. Those 32 bit processors have lots of inbuilt goodies.
Unless there is a big demand, I'm not going down that rabbit hole.
-
...
Keep in mind that a 1PPS output is not worth a lot if it's not aligned to an actual reference time, e.g. UTC seconds.
Good point.
From the PICdiv page:
These dividers also allow for 1PPS synchronization. If pin 4 (Arm) is held low for a second the divider stops and waits. The divider synchronizes to the rising edge of pin 5 (Sync). There is a weak pullup on the Sync pin. If you never plan to stop or sync the divider connect the Arm pin to Vdd, or simply connect the Arm pin to the Sync pin.
-
Does anyone use a 1pps for anything?...
A 1PPS signal aligned with UTC has many uses, and if I can get it using a $0.90 8 pin MCU, the cost/benefit ratio is more than acceptable.
In any case, it's optional, like the sensors, display, Bluetooth interface, regulated PSU, phase detector/TIC, etc. If you don't want it, don't populate the PCB with it and don't enable the firmware subroutines for it.
-
A 1PPS signal aligned with UTC has many uses,
I guess that's what I was asking. What are these uses (other than industrial people that would be buying a $1000 GPS unit that provides what they want).
-
I have a similar question. If a 1 pps is to be accurate, its rise/fall time must be short. For a precision of 1 ppb it would have to be known within one nanosecond. So its rise and fall must be of that order of magnitude or better, and its amplitude and shape needs to be stable. Any circuitry that uses it must also be stable; I suppose the precision would be allocated among both the pulse parameters and the triggered circuit constants.
The stuff I don't understand far exceeds what I think I understand. Here, perhaps a little knowledge isn't a dangerous thing as much as it's misleading.
-
...
Keep in mind that a 1PPS output is not worth a lot if it's not aligned to an actual reference time, e.g. UTC seconds.
Good point.
From the PICdiv page:
These dividers also allow for 1PPS synchronization. If pin 4 (Arm) is held low for a second the divider stops and waits. The divider synchronizes to the rising edge of pin 5 (Sync). There is a weak pullup on the Sync pin. If you never plan to stop or sync the divider connect the Arm pin to Vdd, or simply connect the Arm pin to the Sync pin.
Interesting, but I am not sure if this will work. What will be the Sync signal, 1PPS from the GPS, I guess. Thats very noisy. If you want the 1PPS to be within 1ns of UTC, some trickery in software will be needed.
-
Those pic dividers are using the pic chip as a logic device (more less it mimics an fpga), not as a traditional "MCU".
The pic is clocked by 10MHz (10MHz is fed from the OCXO into the pic's master clock). Everything inside the pic happens on the rising edge of its clock and the added jitter of the pic's 1PPS output is in XX pico-seconds area, afaik.
-
All your questions have been answered here:
https://en.wikipedia.org/wiki/Pulse-per-second_signal
:)
-
That PIC has a 4 cycle instruction time so the 1pps output could be anywhere in a 400ns window. You would get within 100ns using an ATTiny for the same money. And yes I looked at Wikipedia before but it says nothing useful.
-
That PIC has a 4 cycle instruction time so the 1pps output could be anywhere in a 400ns window. You would get within 100ns using an ATTiny for the same money.
...
No, please check again the PIC datasheet (I posted a link to it): "- All single cycle instructions except branches."
In that respect, the ATTiny and the PIC 12F675 are similar. More importantly, the PICdiv code is of excellent quality and it implements synchronization. The AVR code is mediocre and I don't think it implements synchronization. So PICdiv it is. :-+
...
The pic is clocked by 10MHz (10MHz is fed from the OCXO into the pic's master clock). Everything inside the pic happens on the rising edge of its clock and the added jitter of the pic's 1PPS output is in XX pico-seconds area, afaik.
The PICs are on their way and I'll be sure to check and compare the 1PPS output from the PICdiv to the 1PPS output from the GPS (using probe cables of the same length and impedance!).
-
The "PICdiv" chip (maybe 20 types afaik) "dividers" are pre-programmed such they produce an output signal, where the "4 clock cycles per instruction" are already incorporated into the stuff.
Therefore take it as a dumb logic circuit - a divider by N - where only a rising edge of the input/output clock plays a role in this specific app.
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
Jitter is extremely low since the PIC is a synchronous device. Recent measurement suggest it is less than 2 ps.
-
No, please check again the PIC datasheet (I posted a link to it): "- All single cycle instructions except branches."
Please check the data sheet more thoroughly. In section 10.0 INSTRUCTION SET SUMMARY "One instruction cycle consists of four oscillator periods". Also note "For external interrupt events, such as the INT pin, or GP port change interrupt, the interrupt latency will be three or four instruction cycles. The exact latency depends upon when the interrupt event occurs". That throws another 400ns uncertainty into the mix.
I have been programming 8-bit PICs for over 10 years. I know how they work.
-
No, please check again the PIC datasheet (I posted a link to it): "- All single cycle instructions except branches."
Please check the data sheet more thoroughly. In section 10.0 INSTRUCTION SET SUMMARY "One instruction cycle consists of four oscillator periods". Also note "For external interrupt events, such as the INT pin, or GP port change interrupt, the interrupt latency will be three or four instruction cycles. The exact latency depends upon when the interrupt event occurs". That throws another 400ns uncertainty into the mix.
I have been programming 8-bit PICs for over 10 years. I know how they work.
But it is irrelevant. Just don't use interrupts and you can exactly calculate how many clock cycles any piece of code will take.
-
The PicDIV's dividing by N works as a state machine clocked synchronously by the master clock (the clock coming from 10MHz OCXO, for example). Thus the 4_clock_per_instructions issue does not apply here.
It would apply when you try to divide by small N , like N=2,3,4,5 etc, where the "4 clocks per instruction" is the limiting factor.
Also - any messing with async signals at GPIO inputs could have a latency of many clocks - based on whether there are synchronizers at the inputs, etc., etc.
For example the "Sync" input - it should synchronize the divider to the rising edge of the Sync signal. That could be a subject to the 4++ clocks uncertainty, imho.
-
But it is irrelevant. Just don't use interrupts and you can exactly calculate how many clock cycles any piece of code will take.
I made the comment because the picDIV programs that were mentioned do use an interrupt for sync. So not irrelevant in this context. And why people use code for delays is a mystery to me. There are timers to do that.
-
I think the "Arm" and "Sync" signals there are used for not_timing_critical processes, like to reset the 1PPS signal to log1 in order to prepare a measurement waiting on the next 1PPS rising edge. Thus there is no need to wait 1 second worst case. It does not matter whether it takes 10us or 1ms.
Otherwise, while not using the Arm and Sync inputs, it works like a dumb divider by large N..
-
I had an overnight think about generating the 1pps from a PIC. If you just want 1pps that isn't aligned to anything, then no problem.
If you want to align the 1pps with something (e.g. the UTC second) then it is necessary to decide what is an acceptable error. There will be an error, just a matter of deciding how much is tolerable.
I think 1us can be achieved just by using the picDIV arm/sync and not actually monitoring the generated 1pps. It may a few hundred ns off due to the instruction time/interrupt latency issue. But if your aim is 1us then no problem.
To get within 100ns will require monitoring the output. If trying to align with the 1pps from the GPS, imho monitoring the falling edge of the PIC would be advisable. It is guaranteed to be a fixed time after the rising edge, and the processor may be busy dealing with the GPS rising edge so not able to attend to the PIC rising edge at the same time. To align within 100ns, just change the OCXO frequency for a few seconds. A shift of 0.25Hz will reduce the error by 25ns per second. I think your circuit will allow this. The Lars circuit won't allow it because it is locked to 10 cycle intervals.
Getting below 100ns is tricky and probably not worth the trouble, it requires the phase of the OCXO to be adjusted relative to the GPS 1pps. This depends on how your detector works. The Lars circuit does allow the phase of the OCXO to be shifted relative to the 1pps, but can't overcome the multiple 100ns cycle offsets.
-
This is what he's getting at and I am hoping to do this too in a project I am working on. I already have the GPSDO its planned to complement and a case with power supply and lots of BNC connectors and a rack mount chassis with a nifty alphanumeric display.
This is @tvb 's web site. He has a lot of info there. The most compelling reason is the synchronous nature of the PICS and the code which means no additional error is introduced.
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
-
This is what he's getting at and I am hoping to do this too in a project I am working on. I already have the GPSDO its planned to complement and a case with power supply and lots of BNC connectors and a rack mount chassis with a nifty alphanumeric display.
This is @tvb 's web site. He has a lot of info there. The most compelling reason is the synchronous nature of the PICS and the code which means no additional error is introduced.
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
Please read previous comments from #186 onward. We've all been there.
-
...
This is @tvb 's web site. He has a lot of info there.
Indeed it's a fascinating website by a true time-nut (by his own admission). The information about the PICdiv operation can be found in the source code, which is abundantly commented.
The PicDIV's dividing by N works as a state machine clocked synchronously by the master clock (the clock coming from 10MHz OCXO, for example). Thus the 4_clock_per_instructions issue does not apply here.
The frequency division is perfectly synchronous so indeed there is < 1ns jitter introduced by the PIC.
For example the "Sync" input - it should synchronize the divider to the rising edge of the Sync signal. That could be a subject to the 4++ clocks uncertainty, imho.
Yes, you are 100% correct. But I am thinking there are ways to work around that 400ns uncertainty, to get the PICdiv 1PPS perfectly aligned to UTC (within the limits of the GPS receiver, of course). Because it seems that the "uncertainty" is always exactly 100 or 200 or 300 or 400ns, so it's not an uncertainty at all, just a random exact time difference with only four possible values.
I will be testing that of course when I receive the PICs.
And here is where the STM32 GPSDO shines as an experimental platform and a source of fun. ;)
-
Hi,
I got some parts in the mail today:
1. 1N5711 Schottky diodes.
2. 1nF polystyrene capacitors, one of which was DOA! :--
3. 10uH inductors.
The fast recovery Schottky diode and the polystyrene capacitor are required by Lars' 1ns resolution phase detector and the 10µH inductors are used in a T-filter to get an approximate sinewave 10MHz fundamental, for people who need/want a 10MHz sinewave (since the STM32 GPSDO uses a square wave OCXO).
I'll be testing/experimenting these circuits and posting some DSO captures in the coming days. I hope I can reproduce Lars' 1ns resolution measurements, but we'll see. :-/O
-
That 10uH inductors are not optimal for 10MHz usage (ie a filter). Something like a small T-37-2 (red) amidon iron powder toiroid would be a better choice..
~50turns for 10uH..
-
That 10uH inductors are not optimal for 10MHz usage (ie a filter). Something like a small T-37-2 (red) amidon iron powder toiroid would be a better choice..
~50turns for 10uH..
By not optimal, do you mean losses? Do they radiate the 10MHz signal? Or something else? I have very little experience with RF analog circuits.
-
I'd rather go for a 4th order Butterworth low pass. Should get you about 38dBc attenuation at 30MHz. Plenty of online calculators around that will get you the design. 50 Ohms output recommended. You'll need a driver.
-
Yours inductors are for general decoupling/blocking. They have got low Q and high temperature coefficient (ferrite core). Also they pick up noise (as a ferrite rod antenna).
The iron powder toroids are with low tempco, higher Q, and they are closed (toroid) for outside interference..
-
So I assembled the buffered (using a 74HC14) sine wave T filter using 2 x 10µH inductors + 1 x 100pF ceramic capacitor on a breadboard next to the STM32 GPSDO (which is also on a breadboard) and the resulting quasi-sine is rather acceptable imho. Yes, there is a certain amount of noise and depending on the application this may or may not matter. Also I am not sure how much of that noise is due to the breadboard assembly and would be avoided when the circuit is assembled on a proper PCB.
Next to be tested: Erik's version of Lars' 1ns resolution phase detector (the 74HC74, the Schottky diode etc can be seen on the same breadboard as the square to sine converter). And personally I find that a DSO is an essential tool to understand what is happening during these experiments.
Pics of the breadboard assembly and DSO traces (yellow is 10MHz square wave from OCXO, green is quasi-sine output of T filter):
-
I'd rather go for a 4th order Butterworth low pass. Should get you about 38dBc attenuation at 30MHz. Plenty of online calculators around that will get you the design. 50 Ohms output recommended. You'll need a driver.
I went for a 5th order Butterworth as you can see in the hand drawn circuit diagram for the MK II design in reply #123, page 5 in this thread (https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg3620946/#msg3620946 (https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg3620946/#msg3620946) for those who prefer a quick link :) ).
I tracked down a filter calculator here: http://leleivre.com/rf_butterworth_LPF.html (http://leleivre.com/rf_butterworth_LPF.html) and selected the 5th order LPF option using a 12MHz turnover to reduce the 3dB attenuation at 10MHz, further boosting the output by resonating the C3 cap with a 1.6μH inductor (L3) in parallel.
I'd needed an inductor to ground reference the output anyway and this seemed a cheeky way to achieve that and compensate for the loss when operating so close to the turnover frequency to maximise attenuation at the 3rd harmonic and beyond. ISTR achieving a 50dB attenuation of a 30MHz sine wave compared to 10MHz when checking its performance (with my much modified FY6600 "toy" function generator, natch :) ) as a result of this addition.
My first attempts using toroidal cores recovered from scrapped PC motherboards produced very poor performance (barely 30dB attenuation at 30MHz). In hindsight, a not too surprising result since I doubt rather think the buck regulator circuits they'd been part of would have been switching at sub MHz rates and an increased loss at 10MHz would be a switching noise reduction bonus in this service.
In the end, I tracked down a collection of small inductors (VHF transistor radio chassis are a good source) wound onto open ferrite bobbins with black heatshrink wrapping that I could tune by unwinding turns whilst measuring with a cheap BangGood LC meter. These were a vast improvement over the ex-PC MoBo toroidal cores I'd tried. The last image in that post shows a fine example of the filter's effect on the 10MHz square wave output coming from the 74HC14 four gate buffer (CH1, yellow trace).
-
This is what I use. Components are all SMD 0805, though. Johanson Technology has a nice catalog of RF coils which are good to use for this kind of stuff.
-
I'm still old skool when it comes to small diy projects like this and I tend to repurpose my collection of 'salvage' (where the components are still fit for their new purpose :) ).
I've not yet gotten round to tooling up for diy multi-layer PCB layouts that I can submit to a PCB house upon which to solder a collection of brand new smd parts. Maybe one day soonish, I might make that leap but for now, my version of 'dead bug' on a copper clad board serves me reasonably well. However, I've taken note of your recommendation of Johanson Technology as an RF smd inductor supplier for when I take that leap into the present day. :)
That MK II was built onto such a copper clad board - seeing as how there were only 4 1/2 3 1/2 DiP IC's worth (plus OCXO) in that project, I just drilled 0.6mm holes to mount the ICs conventionally, chamfering all but the ground pin holes so I could connect using jumper wires on the underside to complete the circuit connections.
If there had been just a few more ICs to mount, I'd have used the dead bug style of construction instead (and never mind its 'ugliness' - I see the beauty of "function over style" as an engineering statement anyway in these DIY builds).
I noticed that your 4th order Butterworth LPF is only one small capacitor away from being a full blown 5th order filter which is a little surprising seeing as how this 'extra' takes up so little space. When I was considering my options, the even order filters struck me as being the less elegant asymmetric option (the expression "Being one sandwich short of a picnic." coming to mind in this case),
Since the caps in my case are the smallest component parts when relying on thru-hole inductors, it just seemed a little remiss of me to save on the relatively minuscule space that one such extra capacitor would occupy so I "spared no expense" and went for the 5th order filter. :)
One feature of low pass filtering a 10MHz square wave is the fact that the third (most troublesome) harmonic from the gate outputs is just one third of the fundamental's amplitude to begin with which is theoretically just over 9.5dB down (and likely a little in excess of 10dB down due to the limitations of the 74HC series of ICs at 30MHz). In this case, you can expect to see the third harmonic content down to 60dB below the fundamental at the output representing a THD of around 0.1% given that the higher harmonic contributions should disappear into the noise, assuming the filter is doing a reasonable job up to 100MHz and beyond. It's no wonder the sine wave looks 'perfect' on a scope trace! ::) :)
-
5th order Butterworth is a clever thought as it is mostly symmetrical, saves on unique BOM items ;) Only one inductor value needed and two different capacitors.
Your design however leaves me wondering, you go to some extent to achieve a 50 Ohms impedance and then you slap a crystal at the end of the filter. I understand that it's series resonance is really quite narrow and the gigantic Q of the crystal certainly doesn't present 50 Ohms outside of its passband, have you spent time investigating what this does to the characteristics of the filter?
-
I would suggest a Chebyshev filter. With a single frequency CW signal, ripple and dispersion are of no concern, while it is much steeper than Butterworth (lower order needed). Most filter calculators can do Chebyshev too.
Elliptic filters are even steeper, but I prefer Chebyshev for simplicity, and because the attenuation (theoretically) increases monotonically with frequency (lowpass).
Marko Cebokli
-
Also mind the output impedance of various cmos families and gate types vary from something like 15ohm up to 150ohm..
-
That was the old, now stripped down MK I circuit, that I'd built onto stripboard. The MK II is the second circuit diagram below.
The addition of the crystal was simply to filter out all the jitter components that were being injected from the Vcc and ground rails by all the additional TTL chips I'd used to convert the 13MHz OCXO's square wave output into a 10MHz square wave. In that regard, it did clean up the output considerably. I wasn't overly concerned over any 'out of band' effect it may have had (I already had plans for the MK II by then and it was just a 'quick fix' anyway).
The experience I'd gained with the MK I provided very useful guidance for the design and build of the MK II. Basically, it taught me how to avoid the errors and pitfalls created by the original design and build. In essence, whilst the use of a complex divide by 13 circuit (as clever as that may seem - I'd done it because I could) to pervert a 13MHz OCXO into doing duty as a 10MHz reference, it was not without its own unique problems of injected spurious noise onto the Vcc rail, made all the worse by by the use of stripboard construction. :(
By sticking to a more conventional design (I had 7 examples of those ex-Symmetricom AE CQE 12v 10MHz sine output OCXOs to hand by then -close cousins of the original 13MHz OCXO I'd started off with), I was able to eliminate four ICs reducing it to just 3 1/2 IC's worth to drill 0.6mm holes for in the copper clad board I'd substituted for the stripboard used in the MK I. That meant I no longer needed a xtal filter in the MK II as you will see when to take a close look at the second, hand drawn, circuit diagram below the MK I's diagram.
BTW, I still have that first filter in the pot of components recovered from the MK I since I'd had to build it as a unit part on a copper strip made from a piece of opened up half inch water pipe due to the lack of space to build it directly onto the stripboard which in any case makes for a lousy groundplane even at 10MHz, let alone all the odd harmonics that need to be filtered out. It might yet see use in another GPSDO but sans its xtal embellishment. :)
-
I have now moved on to Erik's version of Lars' 1ns resolution analog TIC, and it works (thank you Erik! :-+ ), except that I am seeing much more jitter in the TIC output than I was expecting, and it has two components:
- the regular and expected 21ns jitter from the u-blox GPS receiver MCU which runs at 48MHz.
- a random 30ns component which I guess could also be expected, apparently linked to signal propagation delays through the atmosphere and the relative movement of the satellites.
Unless the noise (i.e. the jitter) can be removed by software from the TIC information, its effective resolution is more like 50ns, not 1 ns. :wtf:
Lars only mentions this in his documentation:
"As the 1PPS has a lot of jitter, normally in the range 10-50ns p-p, the time measured between the 1PPS and 10MHz is filtered with a low-pass filter in the software."
Erik has already noted the 21ns jitter from the GPS MCU, so the TIC jitter is really in the range 25-50ns p-p. You cannot get less than 21ns jitter, at least with a u-blox receiver with an MCU clock frequency of 48MHz.
I guess I'll have to read Lars' source code to see how he dealt with this much jitter in software. This also confirms that my original FLL approach is the way simpler method to "close the loop" i.e. to obtain a Vctl to control the OCXO frequency.
Attached the DSO capture. The yellow trace is the rising edge of the 1PPS from the u-blox GPS receiver module, the green trace is the charging of the 1nF capacitor in the TIC circuit. The 10MHz noise in both traces is due to inadequate decoupling and the lack of a good ground in the breadboard assembly. That should be solved with a correct layout in the final PCB assembly. The ringing is probably the result of the DSO probe and the excessive impedance of the wiring in the breadboard assembly, but it is irrelevant as the ADC capture will occur a couple of µs later.
Now on to reading Lars' code!
-
There isn't a lot of magic in Lars' software regarding noise filtering. There is an EMA (Exponential Moving Average) applied to the TIC readings and then the rest is in the PI controller constants.
-
I have now moved on to Erik's version of Lars' 1ns resolution analog TIC, and it works (thank you Erik! :-+ ), except that I am seeing much more jitter in the TIC output than I was expecting, and it has two components:
- the regular and expected 21ns jitter from the u-blox GPS receiver MCU which runs at 48MHz.
- a random 30ns component which I guess could also be expected, apparently linked to signal propagation delays through the atmosphere and the relative movement of the satellites.
====snip====
That reference to a 30ns component caught my attention. JOOI, does this have a subsonic frequency in the region of 3mHz (around a period of 2 to 5 minutes) by any chance?
-
The Neo-7/8 modules have "Accuracy of time pulse signal 30ns RMS".. Peak-Peak value is much higher..
-
Even if the phase detector does not bring much extra resolution (from 100ns when only counting 10MHz edges to 20-50ns with the phase detector) the big advantage is you are now able to SEE the PPS jitter of the GPS so you know the measurement uncertainty and you are able to calculate your measurement error to prevent you are measuring and acting on noise.
-
Unless the noise (i.e. the jitter) can be removed by software from the TIC information, its effective resolution is more like 50ns, not 1 ns.
The u-blox binary UBX-TIM-TP message has the correction for the quantization error, so you can correct the TIC measurement for that. It can also just be logged to see how much it might affect the calculations.
A delay line like a DS1023 is also sometimes used to correct the 1PPS in hardware so that the corrected pulse can be fed out to other equipment.
-
Unless the noise (i.e. the jitter) can be removed by software from the TIC information, its effective resolution is more like 50ns, not 1 ns.
The u-blox binary UBX-TIM-TP message has the correction for the quantization error, so you can correct the TIC measurement for that. It can also just be logged to see how much it might affect the calculations.
Now that's very interesting. But obviously it's not how Lars's code does it, so I am still left wondering how/why nobody (except Erik) commented on this in the 37 or so pages of the Lars thread? I mean, one can see the voltage at the TIC capacitor jumping up and down by an equivalent 21ns.
But Lars's original TIC range is 1µs (because he divides the 10MHz from the OCXO by 10 before feeding it to the TIC), so 21ns is just a 2.1% error. I am feeding the TIC directly with 10MHz so my measurement range is 100ns, and 21ns represents 21%.
Hmm. Perhaps a "1ns resolution TIC" is only useful if the 10MHz OCXO frequency is divided by 10 or more before being phase-compared to the 1PPS? I'll have to think more about that. Also it probably means I'll have to order some 74HC390's.... |O
A delay line like a DS1023 is also sometimes used to correct the 1PPS in hardware so that the corrected pulse can be fed out to other equipment.
Very interesting again. Yes, I was thinking about how to phase-correct the 1PPS from the picDIV-OCXO so it would be aligned (within 100ns) with the GPS-UTC time. That is a rather challenging bit of engineering creativity question...
Thank you for your comment, much food for thought.
-
Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.
-
Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.
Yes, that is exactly what I wrote. And since the picDIV is the simplest and cheapest solution to obtain a 1PPS from the OCXO, the question boils down to how to align/phase lock the 1PPS from the picDIV with the 1PPS from the GPS receiver, and ideally even correct the quantization error from the u-blox, since a u-blox proprietary message can provide the required information.
This is quite a challenging problem. And I can't find any information on anybody having solved this problem before in a DIY GPSDO or GPS clock.
-
The Lars 1ns figure is the outcome of using a 10-bit ADC and a 1000ns window. I have not looked at Lars code, but I suspect it steers the oscillator so the average reading from the ADC is middle of the range. i.e. about 500. To fine adjust the phase of the oscillator is just picking a different value to steer to. A a full cycle of phase adjustment is obtained by picking values between say 450 and 550.
The problem is Lars hardware is locked to 10 cycle blocks so if the output of the picDIV needs to be shifted by a large amount, it can't be done. A possibility is inserting hardware between the oscillator output and the picDIV that can block one cycle of the PIC clock each time it is triggered. Start the picDIV early and delete cycles until its output is within 100ns of where it should be, then change the phase of the oscillator to remove the residual.
The real problem is aligning the picDIV output to what?
-
Well obviously you align to the GNSS time pulse.
-
Well obviously you align to the GNSS time pulse.
Easier said than done. The electrical time pulse out of the GPS receiver may or may not be synchronous with the time as known to the GNSS satellites. If you use an active antenna with a 3 meter lead, there is a delay (about 15ns, depending on the material) between the signal reaching the antenna and reaching the GPS receiver. So the picDIV pulse should be ahead of the 1pps from the receiver. This has to be detected and measured in hardware, the processor is unaware of the arrival of the 1pps until it is interrupted, and because the processor clock (in the case of your usual Arduino) is not aligned with the local oscillator, there is a variable delay. There's other delays to consider. It's messy.
IMO just produce a 1pps somewhere within a microsecond or two of the 1pps from the receiver. What's it going to be used for? I can't think of one application that needs accurate time stamping to better than a microsecond. Measuring time intervals is a different matter, pulses exactly one second apart are useful and the picDIV can do that. But they don't need to be aligned to anything.
-
It's not that difficult, if you have a timer that can be clocked by the 10MHz OCXO output. Ideally, the timer would allow capturing an external event (the GNSS timepulse) and be configured to output a pulse on underrun on an externally visible output.
You would preset this timer to 9,999,999 counts and configure it to auto-reload on underrun. The externally visible underrun output is your 1PPS. Then you capture the timer count on the GNSS timepulse and tune the OCXO until the captured count is 0. You're within 100ns of the GNSS timepulse now. This basically selects the 10MHz "edge" you want to finetune the 1PPS output to. You do that with using your 1ns resolution TIC. I bet you can get the 1PPS output to within a couple nanoseconds around UTC top-of-second this way.
-
Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.
It depends what it's being used for - the 1PPS from a GPS has a different set of errors compared to one derived from an GPSDO OCXO.
Some of the errors and fluctuations in the GPS timing are over tens of minutes and into hours. If the time constant in the GPSDO is short, it will not reduce them much. If it is long enough to reduce them, small instabilities and environmental sensitivities in the OCXO and the GPSDO measurement and control can cause significant errors.
It can also be used to improve the 1PPS with an FLL GPSDO.
-
Well, let's assume your control loop has locked on the GNSS timepulse, which you would typically detect by monitoring the phase between your timepulse output and the GNSS timepulse (or the selected edge of the 10MHz output), finding that it stays within the GNSS time uncertainty for a longer period of time (like, multiple times your control loop time constant). You can then be sure that the timepulse derived from the OCXO is more accurate and stable than the timepulse from the GNSS itself.
-
Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.
It depends what it's being used for - the 1PPS from a GPS has a different set of errors compared to one derived from an GPSDO OCXO.
Some of the errors and fluctuations in the GPS timing are over tens of minutes and into hours. If the time constant in the GPSDO is short, it will not reduce them much. If it is long enough to reduce them, small instabilities and environmental sensitivities in the OCXO and the GPSDO measurement and control can cause significant errors.
It can also be used to improve the 1PPS with an FLL GPSDO.
A GPSDO can output two 1PPS pulses, and each one has its advantages and disadvantages.
1. The 1PPS from the GNSS receiver. Short term jitter (1s): 50~100ns. Long-term deviation from UTC: essentially zero.
2. A 1PPS derived from the OCXO. Short term jitter (1s): <10ns. Long-term deviation from UTC: essentially zero if perfect satellite reception over the measured period, otherwise OCXO drift.
Obviously the 1PPS from the GNSS receiver is dependent on satellite reception. For networks that need a guaranteed UTC-aligned 1PPS, we must use the 1PPS derived from the OCXO, meaning we have to phase-align it with the 1PPS from the GNSS receiver. And if possible/practical, correct the phase-alignment for the GNSS receiver quantization error, the length of the antenna cable, etc.
It's not that difficult...
I think it's one of those things that seems "not that difficult" until you actually try to do it. I haven't found a single example of a DIY UTC-aligned 1PPS on the web. A picDIV will get us within 400ns of UTC top-of-second, but that's not "good enough", so I am still trying to find a way to align that to UTC within < 100ns (which is the bar I have set myself).
-
It's not that difficult...
I think it's one of those things that seems "not that difficult" until you actually try to do it. I haven't found a single example of a DIY UTC-aligned 1PPS on the web. A picDIV will get us within 400ns of UTC top-of-second, but that's not "good enough", so I am still trying to find a way to align that to UTC within < 100ns (which is the bar I have set myself).
I know one, from a fellow time-nut who's also active here on the forum. The implementation I outlined, roughly describes what he did, using some rather beefy STM32 clocked by the 10MHz OCXO output. My own DIY GPSDO based on a Beaglebone Black should be able to do it eventually, if I ever find the time to complete the PCB.
-
I think I found a possible solution which I should be able to test when I receive the 12F675 PICs and the PIC programmer in the coming days.
I would just take the 1PPS from the picDIV and compare its rising edge to the rising edge of the 1PPS from the GNSS receiver, using Erik's version of Lars' TIC. Then adjust the OCXO Vctl until the phase difference is as small as possible and preferably under 50ns.
That would simultaneously adjust the OCXO frequency to a phase locked 10MHz and synchronize the picDIV 1PPS to UTC top-of-second (within 100ns, which is the objective I set myself).
At least in theory, that should work. In practice: we'll see when I build it and test it. :-/O :o
EDIT: the PICs 12F675 have arrived, now just waiting for the PIC programmer to test the above.
EDIT2: In case anybody is wondering why I would want a 1PPS aligned to UTC within 100ns, it's because that's exactly twice as good as the FacePlant GPSDO "Time Machine". >:D
-
I have decided to rebuild one of my STM32 GPSDO prototypes on two breadboards, with every single possible optional module and trying to minimize noise.
I took a picture of the layout before wiring it. (see below)
This STM32 GPSDO prototype includes, clockwise from top left:
- Regulated power supply (5V and 3.3V).
- 10MHz squarewave OCXO.
- INA219 current sensor module.
- 74HC74 for the TIC / phase detector.
- picDIV (PIC12F675).
- 74HC14 output buffer and square to sine filter.
- I2C OLED display.
- HC-06 Bluetooth module.
- AHT10 temperature and humidity module.
- Yellow status LED.
- BMP280 atmospheric pressure and temperature sensor.
- u-blox Neo-M8N GNSS module; note the SMA connector for an external antenna.
- The brains of the GPSDO: an STM32F411CEU6 "Black Pill" MCU module.
:phew:
Still waiting for the PIC programmer...
-
FYI - I built my gpsdo+reciprocal counter on the exactly same 2 solderless breadboards - with rather moderate results (too much noise/jitter in my measurements). Those boards are not well suited for prototyping systems where you are going to chase uAmps, uVolts and XXXpicoseconds, imho.. A tiny bang into your workbench and your data will be jumping all over the place..
PS: better you go with those green "perfboards" (https://www.ebay.co.uk/itm/291984166392?_trkparms=ispr%3D1&hash=item43fb9ccdf8:g:jzEAAOSwIfFdyNqh&amdata=enc%3AAQAGAAACwPYe5NmHp%252B2JMhMi7yxGiTJkPrKr5t53CooMSQt2orsS%252Fwocn770hnih0B3mVHNZ5FD0otCiqywc7fDCCTAhJDF0iVYoj4L6ckExrXXVEVBF%252Fyv%252BldOU86NSYvrPqAtWuVCeDixz4hViOCEmeRsaJ4vwUdiNWwnMmUqxF1defAOaELzmjxQvTNNnp4kc%252FBCcoXly%252BllnUuyDAwPuJWAMJ6rSbzoGEfjTI3cYwc0LUjSJjxXkj%252FYcbzcAH3pZJUY6RGVh6RZx7VHN5EsV1MlmYJDBazfwWrlwWmigjukQyXTMMi9qOLCKOHxX%252BLLRwNZI69IAGZzL8XsPJgBv6jyXLJQA7o%252F3cw2vfwT6tTKTyZHeE2P1%252FqS4hWVicXjqJuJ%252FHJb6HoedWKYoIPf8ZKlWyJZv49lU8S8n%252BOgl2p2FHvc%252BX5Id0GUkwGE9aRCtRsOpJiQZ80AE8cP0onvputtavcsMXdgxpPt9OpU2BY%252FAmOCb5wnl8v%252Flhp1C%252BVooc90UiSNFXHeHlV0of8whTqzkJ3CEQPI2xNKabzcGaFWOl76TQl%252FVOfw6uy3vTa9cNphcQkg7CWM%252BtzGF9F0ddF8l%252FGD6DgA2jYAIJ3BNj9jqrcLuPyvrtozJH64XvWSf1RtsaFP6J8H7mCqbdDG9EzAFcBKEChZy%252BZ23UTha7xLY2SRHAvn1k2INA%252FMMzs2xe8z3T0naI0ktG2z3bm85EzQ3lBFcH%252B%252FjxXHN9Sqr%252F3HXqepO5rLLr4Pp8mkCkM4m2orXzCXouvrXcj4YhquaLzDf3bS%252F1KM268Mho4Mle71T1%252BdSz6z7cxhCzbwd4ztFNJdr3FEl0GQ9v1LN9GS8NJHcf55RNL9nAgTPLI500yuhQ3ky1jdi75LBWlIY5SC%252BSdKS3iOLPIyz5jT9Aw5S8qEbs0I0ZT4KZ6LdBapcnYMX4DVY%7Campid%3APL_CLK%7Cclp%3A2334524), for chips using precision sockets soldered into it, smaller green breakout boards for smd parts, soldering in all the passive parts, wiring with careful selection of grounding points, beefy decoupling, etc.
-
@AndrewBCN
Thanks for posting that breadboard layout picture before wiring it all together. :)
Once you've got it all wired up, those components are going to be buried underneath a rat's nest of jumper wires that you dare not disturb once you manage to get it doing something that approximates its intended function, for fear you'll send it all haywire (in this case, a rather apt expression! :) ).
-
The cheapo jumping wires a) contain almost no copper, b) wire is not soldered to the pin.
For the green perfboards soldering jobs I've been using wires from cat5 patch cables (solid or stranded). Also doublecheck the cat5 solid ones - there is a lot of copper clad aluminum ones on the market (not easy to recognize).
-
Yes, I am quite aware that noise and jitter are a problem with the GPSDO prototypes built on these cheap breadboards, if you check the previous scope captures I have posted, the noise is quite obvious.
In this development phase of the STM32 GPSDO project, they have proven (just) good enough for testing various circuit ideas and allowing me to write the frequency measurement algorithms and test them.
At some point I'll probably start soldering things on a perforated board (which I already have), but I am not quite there yet.
Some ideas I still want to test and have some fun with, on this latest breadboard prototype:
- Committing calibration and configuration parameters and data to the MCU flash using the EEPROM emulation library for the STM32.
- Expanding flash using a separate SPI memory chip to log days/months of data (yet another optional module...).
- More tests of Erik's version of Lars' TIC.
- The picDIV.
- 1PPS from OCXO+picDIV, synchronized to UTC.
- Measuring the power consumption of the STM32 GPSDO.
The really tedious part of all this experimentation is wiring everything... :'( (The picture below is for you, JBG)
-
The latest news about my quest for a black pill is that there is no news. Aliexpress has no means to ask for help. I finally found a US phone number but all I get is an answering machine. So I am out the money and am obviously not going to get my part.
-
The latest news about my quest for a black pill is that there is no news. Aliexpress has no means to ask for help. I finally found a US phone number but all I get is an answering machine. So I am out the money and am obviously not going to get my part.
How much did you pay for the STM32F411CEU6 "Black Pill", Bob, if I may ask? And which vendor was it that you ordered from, on AliExpress?
-
https://www.aliexpress.com/item/1005001636616276.html?spm=a2g0s.9042311.0.0.27424c4duCukmJ (https://www.aliexpress.com/item/1005001636616276.html?spm=a2g0s.9042311.0.0.27424c4duCukmJ)
-
Wonder of wonders! The black pill finally arrived! Packaging was messed up but the part seems intact. It took three months and finally it's here.
Assuming it's functional, what do I do next?
-
Wonder of wonders! The black pill finally arrived! Packaging was messed up but the part seems intact. It took three months and finally it's here.
Assuming it's functional, what do I do next?
Bob,
1. Solder the two 20-pin headers that came in the same anti-static pouch as the Black Pill and insert the Black Pill at the edge of a breadboard, as shown in one of my latest posts. Then please take pictures of your setup and the parts you have available, and post them here. Be careful with this step because if you mess up the soldering, you'll destroy the Black Pill. Note: don't solder the 4-pin header for the SWD interface, only the two 20-pin headers along the sides of the Black Pill.
2. Install the Arduino IDE on your computer, install the STM32 package, and post a screenshot here. If your PC is running Windows (any version) I can't help you with this installation, so you'll need help from somebody else.
3. Make sure you have a USB C cable, connect it to the STM32, download the "blink" example from your PC to your Black Pill, and post a screenshot here.
4. Wire the GPS module on the breadboard and post a screenshot here. That involves 4 wires but they have to be correctly setup, otherwise you could destroy your GPS module and/or the Black Pill.
5. Test the GPS module with the example code that I will post here for you, once we have confirmed steps 1, 2, 3 and 4 above.
After step 5 we'll be around 50% done. Let's see how long that takes.
-
Thanks Andrew! That is quite a procedure and I gave a big gulp upon reading it. However I will try to follow the instructions, but not tonight. I put all the parts in a little box so I don't misplace any (I am good at that!). It has been suggested to me not to solder all the pins of the headers, but just the ones in use, to make life easier should replacement be necessary.
-
Ah yes, one last thing I just thought of: hide all the parts for this project from your cats, specially the one you suspect stole one of your crystals! :o
Seriously, I was going to suggest you get somebody to help you with the soldering part, and to double check with me here before you heat up your soldering iron. This soldering step is critical and the MCU board can easily be ruined with bad soldering.
For the soldering iron: use the thinnest tip you have, a blunt tip will just ruin the soldering job here, and you would need to order another Black Pill and possibly wait another 3 months to get it. If you use the same mains-connected 100W soldering iron you use to solder wires around the house, you'll most certainly destroy your Black Pill sample.
-
I never lost a crystal due to a cat. However I am still looking for a nail file and a nanoVNA stylus that is probably in the hidden stash of one of the cats.
I will be careful with soldering. I am not exactly a newbie so don't worry about it; with all my experience I am certain I will have no trouble screwing it up.
When mindset is correct, the assembly will begin. One unsure step is the downloading of the software. Not my first time, but still...
-
...
It has been suggested to me not to solder all the pins of the headers, but just the ones in use, to make life easier should replacement be necessary.
That's complicating things unnecessarily right at the first step of the assembly. Just no, don't. :-- :-- :--
I would suggest you follow my instructions to the letter.
Of course, suit yourself, but imho that's the best way to ruin the headers alignment and the entire solder job. A big risk for essentially zero gain.
Please watch this video and proceed similarly, as you can see it's a 3 minutes solder job tops.
https://www.youtube.com/watch?v=37mW1i_oEpA&ab_channel=PeteB (https://www.youtube.com/watch?v=37mW1i_oEpA&ab_channel=PeteB)
-
Well, let's assume your control loop has locked on the GNSS timepulse, which you would typically detect by monitoring the phase between your timepulse output and the GNSS timepulse (or the selected edge of the 10MHz output), finding that it stays within the GNSS time uncertainty for a longer period of time (like, multiple times your control loop time constant).
What do you mean by GPS time uncertainty here? How would you measure if it has been exceeded?
You can then be sure that the timepulse derived from the OCXO is more accurate and stable than the timepulse from the GNSS itself.
That's a very broad statement.
I'm not suggesting that a GPSDO can't be made very stable, just that for a standard DIY one with a $20 Ebay OCXO, and operating in a domestic rather than controlled lab environment, it's not so simple. Things as simple as opening a window or turning on a heater can cause significant phase errors.
Jackson Labs did a presentation a few years ago which shows some interesting phase plots:
https://www.gps.gov/cgsic/meetings/2017/jackson.pdf (https://www.gps.gov/cgsic/meetings/2017/jackson.pdf)
Page 5 has a plot of the 'LN Rubidium Ultimate' version of their GPS-3500 GPSDO along with their Lab GPS. It is certainly an improvement, but it is a commercial rubidium GPSDO costing a fair few thousand dollars.
-
...
Jackson Labs did a presentation a few years ago which shows some interesting phase plots:
https://www.gps.gov/cgsic/meetings/2017/jackson.pdf (https://www.gps.gov/cgsic/meetings/2017/jackson.pdf)
Page 5 has a plot of the 'LN Rubidium Ultimate' version of their GPS-3500 GPSDO along with their Lab GPS. It is certainly an improvement, but it is a commercial rubidium GPSDO costing a fair few thousand dollars.
Thank you for the link to this interesting presentation. And indeed, commercial rubidium GPSDOs cost upwards of $3,000 and so does the FacePlant GPSDO "Time Machine". Of course their absolute performance differs from DIY GPSDOs that rely on inexpensive recycled OCXOs pulled out from decommissioned telecoms equipment.
But the question is, what is the intended application? And how is the raw information from the rubidium oscillator handled? A GPSDO does nothing by itself, in its most basic form it just provides a 10MHz signal with a specified accuracy and stability, and in many commercial applications the advantages of OCXO-based GPSDOs (smaller, cheaper, more mechanically robust and less power-hungry, so less heat dissipation issues, etc) makes them the better choice vs rubidium-based GPSDOs.
As usual, the answer is "It depends..."
-
Well, let's assume your control loop has locked on the GNSS timepulse, which you would typically detect by monitoring the phase between your timepulse output and the GNSS timepulse (or the selected edge of the 10MHz output), finding that it stays within the GNSS time uncertainty for a longer period of time (like, multiple times your control loop time constant).
What do you mean by GPS time uncertainty here? How would you measure if it has been exceeded?
You can then be sure that the timepulse derived from the OCXO is more accurate and stable than the timepulse from the GNSS itself.
That's a very broad statement.
I'm not suggesting that a GPSDO can't be made very stable, just that for a standard DIY one with a $20 Ebay OCXO, and operating in a domestic rather than controlled lab environment, it's not so simple. Things as simple as opening a window or turning on a heater can cause significant phase errors.
Jackson Labs did a presentation a few years ago which shows some interesting phase plots:
https://www.gps.gov/cgsic/meetings/2017/jackson.pdf (https://www.gps.gov/cgsic/meetings/2017/jackson.pdf)
Page 5 has a plot of the 'LN Rubidium Ultimate' version of their GPS-3500 GPSDO along with their Lab GPS. It is certainly an improvement, but it is a commercial rubidium GPSDO costing a fair few thousand dollars.
One thing a GNSS receiver is particularly good at is estimating uncertainties. So, finding out the uncertainty of the timepulse one can just ask the receiver for its TFOM.
Also, I don't think it's preposterous to say that the OCXO derived timepulse is more stable and accurate than the GNSS timepulse. Certainly, if you expose the OCXO to the environment directly, especially temperature fluctuations, phase shifts are inevitable. But the whole idea of locking an OCXO to a GNSS hinges on the assumption that the OCXO has superior short term stability, and once you have met equilibrium, you oscillator phase will be smack in the middle of the uncertainty window given by the GNSS. Of course it will not stay there, depending on the quality of your system it will drift around until your loop filter finds a correction is necessary. But excluding singularities in the oscillator outputs like phase jumps, the excursions of the OCXO phase will always stay _within_ the uncertainty window of the GNSS, simply because the loop filter has a time constant that is a lot larger than the time between two GNSS timepulses.
Yes, if your system setup is shitty, so will be your output stability. But such is the nature of things.
-
Hi,
A few weeks ago I set myself a challenge to develop a "better" project than FacePlant with twice the "performance" and at less than 1/10th the cost. So I am announcing the STM32 Open Time Server, a compact, inexpensive PTP/NTP server that can be plugged into any network and provide accurate timing.
This is basically a combination of the STM32 GPSDO with the UTC aligned 1PPS (which is still under development) and an STM32 development board with Ethernet. The interesting thing about the STM32 development board's onboard Ethernet interface is that it provides for IEEE-1588 hardware timestamping of Ethernet packets. The attached diagram makes clear the basic setup for this project.
I have a couple of STM32 development boards with Ethernet (STM NUCLEO-F429ZI) on their way courtesy of ST Micro, I'll post pictures when I get them.
Btw the code for the PTP server for the STM32 development board already exists, here: https://github.com/mpthompson/stm32_ptpd
-
I ran into my first stumbling block. I was careful to purchase perfboard that has holes on 0.100" conters. The OCXO has pin spacing of 0.75" so I am pondering drilling out a few holes so it will fit.
-
I ran into my first stumbling block. I was careful to purchase perfboard that has holes on 0.100" conters. The OCXO has pin spacing of 0.75" so I am pondering drilling out a few holes so it will fit.
Bob,
I recommend that you first assemble the STM32 GPSDO on a breadboard. But then again, suit yourself.
I wrote this three months ago:
...you need to solder longer leads to the 5 short leads of the OCXO, I suggest adding 5mm long leads.
See the attached picture. That takes 2 minutes and is the solution I found to use these OCXOs with a breadboard.
-
The K150 PIC programmer just arrived! Now to check whether it survived shipping from China and try to program a couple of PIC12F675s with it. :-/O
BTW if anybody is curious I found an open-source Python program that allows using the K150 under Linux, as explained here: https://eliasandrade.wordpress.com/2015/01/20/como-usar-o-gravador-pic-k150-no-linux/
Note the Python picpro.py program requires installing Python 2.7 which is deprecated in 2021. It doesn't work with Python 3.4 (I tested).
Edit 1: tested the K150 PIC programmer with picpro.py and it seems it managed to flash a picDIV correctly, but I'll only be able to test the picDIV tomorrow.
Edit 2: tested the picDIV running pd11.hex and it generates a 100µs pulse @ 1Hz frequency, as designed. See attached DSO trace.
-
Okay I will solder leads to the OCXO and see how to secure the unit so as not to stress the solder. I don't want to use my glue gun, as the unit runs warm enough that the glue is likely to soften. So maybe a wire strap or epoxy or super glue or something else.
I removed the OCXO from the bit of PC board it was on. I want to apologize for my incompetence here. I used to be pretty good with this stuff but it's been a while and I don't have the visual acuity or steady hand I used to have. I had my 89th birthday last month.
-
...
I removed the OCXO from the bit of PC board it was on. I want to apologize for my incompetence here. I used to be pretty good with this stuff but it's been a while and I don't have the visual acuity or steady hand I used to have. I had my 89th birthday last month.
Bob,
I understand.
I just think you should get somebody to help you with the soldering, assembling and programming for this project. I myself have problems with my sight, so soldering small parts can be quite a challenge.
-
I have soldered leads to the OCXO and am pondering the next step.
As for getting help, that isn't readily available due to the pandemic, and to the fact that most of my friends aren't local. So I will take my time.
I will report progress, however slight. I appreciate your patience.
-
Bob,
Take as much time as you want/need. And don't hesitate to post about your progress and any issues or questions. And of course, most importantly: stay safe. :-+
-
Thanks for all you are doing, Andrew. I ran the arduino software but was unable to load it into the black pill. As luck would have it, I have a house guest, my grandson, who is a computer guy. I sat him down here and he did not have an easy time of it, having to download stuff and all, but he managed finally to flash the STM and now it's sitting here flashing.
So I have done step 3. I haven't finished soldering the headers so I will do that next. I have the wires soldered to the OCXO. What I think I need now is the stuff you wrote to make all of this play together. I have taken no pictures yet. When I get it all lashed together I will do that.
-
Thanks for all you are doing, Andrew. I ran the arduino software but was unable to load it into the black pill. As luck would have it, I have a house guest, my grandson, who is a computer guy. I sat him down here and he did not have an easy time of it, having to download stuff and all, but he managed finally to flash the STM and now it's sitting here flashing.
So I have done step 3. I haven't finished soldering the headers so I will do that next. I have the wires soldered to the OCXO. What I think I need now is the stuff you wrote to make all of this play together. I have taken no pictures yet. When I get it all lashed together I will do that.
Well done, both you and your grandson! :-+
I'll be awaiting the pictures.
-
The STM32 Nucleo boards have arrived!
I'll be creating a separate thread for the STM32 Open Time Server project, this one will continue as the thread specifically for the STM32 GPSDO.
Edit: the new thread for the STM32 Open Time Server project is https://www.eevblog.com/forum/projects/stm32-open-time-server/ (https://www.eevblog.com/forum/projects/stm32-open-time-server/)
-
Hi,
Attached is the STM32 GPSDO KiCad schematic PDF file, version 0.6, sheets 1 to 3. The main difference is the addition of an optional picDIV on sheet 3 which should provide a 1PPS synchronized to UTC / GPS time within +/- 100ns. The other sheets have small modifications to accommodate the addition of the picDIV.
Synchronization within +/- 100ns is supposed to be achieved in two steps:
1. After OCXO warmup and GPS lock acquisition, the Arm input of the picDIV is held low for 1.3s. The next 1PPS rising edge will sync the 1PPS output from the picDIV to the 1PPS from the GPS receiver within (at least in theory) 500ns (400ns is the uncertainty in the picDIV and 100ns is jitter from various sources).
2. The phase difference between the 1PPS output from the picDIV and the 1PPS from the GPS receiver is monitored/measured by Erik's version of Lars' 1ns resolution TIC with 1µs range, and the OCXO frequency is then adjusted to keep the phase difference < 100ns.
That's the theory. Now I have to program the above and test it on my latest "rewired" breadboard prototype. As usual, the code will be available on GitHub.
And again: this is optional, like the OLED display, the sensors, the low-ripple/noise power supply, the output buffers, the square to sine filter and the Bluetooth interface. Don't want it, don't use it.
-
Hi AndrewBCN
I have collected most of the items needed for the basic GPSDO project:
1) 10MHz OCXO
2) STM32 Black Pill
3) 8v power supply incl 317 regulator
4) GPS aerial
5) NEO 8 GPS module
6) 4725 DAC
I was looking at your schematic diagrams and wondering how you generate Vdd (3.3v) for optional circuits.
Or, does the micro output 3.3v from Vcc (5v) input?
-
Hi AndrewBCN
I have collected most of the items needed for the basic GPSDO project:
1) 10MHz OCXO
2) STM32 Black Pill
3) 8v power supply incl 317 regulator
4) GPS aerial
5) NEO 8 GPS module
6) 4725 DAC
I was looking at your schematic diagrams and wondering how you generate Vdd (3.3v) for optional circuits.
Or, does the micro output 3.3v from Vcc (5v) input?
Hi enut11,
Yes, the STM32F411CEU6 "Black Pill" can provide 3.3V at up to 100mA or so to the I2C MCP4725 DAC, the I2C SSD1306 OLED display and the various I2C/SPI temperature/pressure sensors. The 3.3V pins on the Black Pill are power output pins. Also note that the NEO-M8 GPS module has its own 5V to 3.3V regulator, so even though it interfaces at 3.3V logic levels, you must supply 4.8~5V to it.
As for Bob, I suggest that the very first step when you are building the STM32 GPSDO is to program the STM32 Black Pill itself, so you'll need a USB C cable and then you can familiarize yourself with that process first, if you are not familiar with it already.
A good test is to simply compile and download the "Blinky" example program to the STM32 Black Pill. If you get a 1Hz blinking LED you know your Arduino IDE is correctly setup for STM32 programming work, and your STM32 Black Pill is working correctly.
The next step is to download the STM32 GPSDO sketch from GitHub and familiarize yourself with the dozen or so lines of #defines that determine the various optional modules installed. If you have any doubts about this step do not hesitate to check with me in this thread. :-+
-
Thanks AndrewBCN. I will proceed as you suggest. Looking forward to when I box this project, I expect the OCXO to generate a fair amount of heat in an enclosure. Are there any heat sensitive components/ modules that need to be thermally isolated so as not to compromise performance?
Does the type of 5v power supply make any difference, ie linear vs SMPS?
enut11
-
Thanks AndrewBCN. I will proceed as you suggest. Looking forward to when I box this project, I expect the OCXO to generate a fair amount of heat in an enclosure. Are there any heat sensitive components/ modules that need to be thermally isolated so as not to compromise performance?
No, in principle everything should work fine up to 50C and even beyond that. The OCXO dissipates around 3W during the warmup phase (less than 3 minutes in general) and then around 1W. So at most the GPSDO enclosure should feel slightly warm to the touch after a few hours of operation.
Does the type of 5v power supply make any difference, ie linear vs SMPS?
enut11
The basic circuit (without the 1ns TIC) is pretty much impervious to power supply noise and ripple, as far as I could tell, but I haven't extensively tested or quantified that. I have powered one of the prototypes with a cheap 5V 18W USB power supply and it performs pretty much the same as the other two which use 5V linear regulators. Of course, YMMV. :)
PS: I have just noticed that STM32 Core version 2.1 has just been released a few days ago. It is the version I recommend for use with the STM32 GPSDO firmware.
-
"PS: I have just noticed that STM32 Core version 2.1 has just been released a few days ago. It is the version I recommend for use with the STM32 GPSDO firmware."
Hi AndrewBCN
Would you please explain what this means?
-
"PS: I have just noticed that STM32 Core version 2.1 has just been released a few days ago. It is the version I recommend for use with the STM32 GPSDO firmware."
Hi AndrewBCN
Would you please explain what this means?
Sure. To be able to program the STM32 chips using the Arduino IDE, you have to install the STM32 support package called Arduino Core STM32, which you can find on GitHub, with its installation instructions for Windows or Linux. Here is the link: https://github.com/stm32duino/Arduino_Core_STM32
The latest version of Arduino Core STM32 is version 2.1.
To install, follow the instructions here: https://github.com/stm32duino/wiki/wiki/Getting-Started
Once you have installed the Arduino Core STM32 version 2.1 on your PC, you can test your Arduino IDE setup using the Blinky example, by flashing the compiled Blinky code to the STM32F411CEU6 Black Pill.
-
OK, thanks. I do not have a breadboard so have started to assemble the modules on perf-board.
For the micro I have used plug-in stand-offs to allow easy replacement if necessary.
-
There are lots of different STM32xx boards with V2.1 support at Github. Does it matter which one I use?
-
Very interesting topic, thank you @AndrewBCN for sharing this project.
I'm a total noob and would like to implement this GPSDO. Searching for antennas in the Aliexpress, I found different options for use with GNSS. Will a better antenna give better results in this GPSDO application?
Considering that I'll install the antenna on the roof of my house, connected by a 10m cable, will a cheap external car antenna have a similar performance than a more expensive antenna?
Here are some examples (all from the same Aliexpress store, to compare the prices):
1- external car antenna - USD 22
https://www.aliexpress.com/item/4000058995645.html?spm=a2g0o.store_pc_groupList.8148356.8.1b17160aJTPOwE (https://www.aliexpress.com/item/4000058995645.html?spm=a2g0o.store_pc_groupList.8148356.8.1b17160aJTPOwE)
2- "mushroom" antenna - USD 26
[attach=1]
https://www.aliexpress.com/item/4000132134387.html?spm=a2g0o.store_pc_groupList.8148356.12.1b17160aJTPOwE (https://www.aliexpress.com/item/4000132134387.html?spm=a2g0o.store_pc_groupList.8148356.12.1b17160aJTPOwE)
3- "mushroom 2" - USD 72
[attach=2]
https://www.aliexpress.com/item/4000132160065.html?spm=a2g0o.store_pc_groupList.8148356.52.1b17160aJTPOwE (https://www.aliexpress.com/item/4000132160065.html?spm=a2g0o.store_pc_groupList.8148356.52.1b17160aJTPOwE)
4- "mushroom 3" - USD 130
https://www.aliexpress.com/item/33051103562.html?spm=a2g0o.store_pc_groupList.8148356.4.1241160azKuoHa (https://www.aliexpress.com/item/33051103562.html?spm=a2g0o.store_pc_groupList.8148356.4.1241160azKuoHa)
5- "mushroom 4" - USD 150
https://www.aliexpress.com/item/4001252421244.html?spm=a2g0o.store_pc_groupList.8148356.10.1241160azKuoHa (https://www.aliexpress.com/item/4001252421244.html?spm=a2g0o.store_pc_groupList.8148356.10.1241160azKuoHa)
6- "disc" - USD 280
https://www.aliexpress.com/item/33051111137.html?spm=a2g0o.store_pc_groupList.8148356.30.1241160azKuoHa (https://www.aliexpress.com/item/33051111137.html?spm=a2g0o.store_pc_groupList.8148356.30.1241160azKuoHa)
7- "dome" - USD 3500
[attach=3]
https://www.aliexpress.com/item/33049894933.html?spm=a2g0o.store_pc_groupList.8148356.42.1241160azKuoHa (https://www.aliexpress.com/item/33049894933.html?spm=a2g0o.store_pc_groupList.8148356.42.1241160azKuoHa)
Of course, I'm not going to buy a 3.5K antenna. But maybe it is woth to invest a little more in the antenna if the GPSDO performance could be improved. And considering that the antenna will be installed on the roof, it can be used in a future GPSDO upgrade.
-
There are lots of different STM32xx boards with V2.1 support at Github. Does it matter which one I use?
You have to select the WeAct STM32F411CEU6 Black Pill in the Boards Manager menu in the Arduino IDE.
See attached screenshot.
-
Very interesting topic, thank you @AndrewBCN for sharing this project.
I'm a total noob and would like to implement this GPSDO. Searching for antennas in the Aliexpress, I found different options for use with GNSS. Will a better antenna give better results in this GPSDO application?
...
Yes, a better antenna will provide a more stable satellite signal reception and a lower jitter than a small "puck" antenna. If you decide to mount a GNSS antenna on the roof of your home then yes I would consider a better, more expensive antenna. Just for experimenting, a <$10 "puck" antenna with a 3 meters cable is good enough though.
I would start with a small antenna and once you have the STM32 GPSDO working and thoroughly tested, invest in a better, rooftop-mounted antenna.
-
OK, thanks. I do not have a breadboard so have started to assemble the modules on perf-board.
For the micro I have used plug-in stand-offs to allow easy replacement if necessary.
Looks good. Please check the following datasheet for your OCXO: https://www.isotemp.com/wp-content/uploads/2011/03/OCXO-131.pdf (https://www.isotemp.com/wp-content/uploads/2011/03/OCXO-131.pdf)
Note that the Isotemp 131-xxx was manufactured in different versions/configurations, xxx being the customer order number.
Your OCXO is possibly the 12V, sine-wave output type. If you have an oscilloscope at hand, please check it out beforehand. Power it with 5V first and check the output pin for a 10MHz signal, with an oscilloscope. If you see a CMOS-level 10MHz square wave then you indeed got a 5V, square wave version of the Isotemp OCXO, which is what we want for the STM32 GPSDO.
Also, a last minute tip: I suggest you use standoffs for the DAC and GPS modules, and even for the OCXO too. This will make it easier to "recycle" all the modules for other projects or different versions of the STM32 GPSDO.
-
@rodpp
That 22 dollar puck antenna should be more than ok for the time being even if you have to extend the feeder by another ten metres. The most important aspect of any GPS antenna being that you site it in a location that has an unobstructed 360 degree view of the horizon.
I wouldn't bother upgrading to another fancy (and over-priced) navigation grade GPS/GNSS antenna. I'd save the money for a dual band timing grade antenna to make the most of a dual band GPS receiver module such as a u-blox ZED9 when you finally cave in to the pressure to upgrade to an even better setup. :)
I'm still using a mag mount puck antenna, similar to enut11's, that I bought three years ago for £2.99 delivered (less than 5 dollars!) from a UK based ebay seller. This had a 5 metre RG174 co-ax with male SMA plug making it an even better bargain than the more common 3 metre co-ax cabled types.
Even so, I needed to extend this by another 5 metres of RG174 (SMA in-line female to SMA male terminated patch lead) which surprisingly, only reduced the C/No ratio by a mere 2dB rather than by the 6 to 7 dB I was expecting of 5 metre's worth of RG174. This allowed me to locate the antenna on a ballasted biscuit tin parked on the flat bay window roof of my 1st floor workroom (2nd floor in the oddball American terminology that names the ground floor as the 1st floor).
Moving the antenna from a South West facing window ledge onto the bay window roof with a 180 degree view centred on a direct westerly view made a significant improvement in SV reception but it was completely obstructed to the East by the brickwork of the gable ended 2nd floor bedroom above which seemed to offer a 3dB boost by constructive reflection of near overhead satellite passes.
Ideally, I wanted to mount a short mast onto this brickwork in order to raise the antenna a foot or so above the ridge tiles to finally gain a full 360 degree view of the horizon but stepping out through the 2nd floor bedroom window onto this flat bay roof in order to drill into the brickwork was, to say the least, a bit too precarious even for me. The ballasted biscuit tin arrangement had only required me to lean out of said 2nd floor bedroom window, no actual crawling out onto the bay window roof needed (although I have done so in times past even through it's a bit of a struggle with the top hinged upward opening window).
I only needed to raise the puck antenna another 8 feet or so from the biscuit tin location to allow it to peek over the ridge tiles so when I spotted a 60 by 70cm metal drawer in the basement I'd been using to store some motorbike parts in, it came to me in a flash that I could extend the ballasted biscuit tin antenna mount setup using this with four old car batteries for ballast and a 7 or 8 foot 1 1/4" diameter aluminium (aluminum) pole clamped into one corner to which I could screw the 20cm diameter biscuit tin lid onto by which to mag mount that puck antenna, reinforced with some impact adhesive to make it somewhat secure against even hurricane level storms (an over-kill/engineered solution in most UK locations but only pennies to implement so, Why not? :) ).
The chosen pole was about 18 inches short of the required length and required another length of 3/4" diameter aluminium tube to be added a few months later. Despite this initial shortfall, I did see a significant improvement but the fact that the view of the horizon was not quite the full 360 degree I'd aimed for, niggled me enough to properly finish the job even though this required yet more faffing around to recover the support pole and extend its length and then relocate it back to its pride of place... about three times over!
There were a few changes to the groundplane mount and an "upgrade puck antenna" I'd wanted to try out. The "upgrade" antenna proved to be a washout since it seemed to lack any immunity to overloading by cellphone signals from a nearby tower so I landed up reverting to the original 3 quid puck and the 20cm biscuit tin lid setup.
I'd had to replace the original 5 metre RG174 patch lead, that I'd used to connect to the GPSDO via a cracked open window, with an 11 metre RG58 patch lead so I could reroute it through an existing conveniently located hole in the wall that had been drilled for a now long since redundant TV antenna feeder years before we'd moved into the property. The C/No figures range between 35 to 45 dB and have done so ever since I finalised this antenna mounting arrangement some 18 months ago.
That first image shows a navigation class antenna that Banggood had been selling for around £18 about a year ago. I think this was the version with a 16 metre RG58 co-ax and I had been tempted to buy one until reason stayed my hand. It had occurred to me that it would offer no more performance than the 3 quid puck I already had in my possession and it would be far better to invest in a dual band timing class antenna for when the pricing on dual band timing GPS receivers finally descends from out of the stratosphere.
Those fancy looking antennas will almost certainly be using the same 1 inch square patch antenna (pretty well the best choice for GNSS service) as that 22 dollar puck antenna. The radome comes into its own where you have to endure heavy persistent snowfall cursed winters - not usually a problem south of the Scottish border here in the UK.
Unless you have to endure such winter conditions or need to use a very long run of feeder, I'd save my money for a more effective dual band antenna upgrade and make do with a well sited cheap puck antenna for now.
-
From AndrewBCN:
Looks good. Please check the following datasheet for your OCXO: https://www.isotemp.com/wp-content/uploads/2011/03/OCXO-131.pdf (https://www.isotemp.com/wp-content/uploads/2011/03/OCXO-131.pdf)
Note that the Isotemp 131-xxx was manufactured in different versions/configurations, xxx being the customer order number.
Your OCXO is possibly the 12V, sine-wave output type. If you have an oscilloscope at hand, please check it out beforehand. Power it with 5V first and check the output pin for a 10MHz signal, with an oscilloscope. If you see a CMOS-level 10MHz square wave then you indeed got a 5V, square wave version of the Isotemp OCXO, which is what we want for the STM32 GPSDO.
Also, a last minute tip: I suggest you use standoffs for the DAC and GPS modules, and even for the OCXO too. This will make it easier to "recycle" all the modules for other projects or different versions of the STM32 GPSDO.
[/quote]
The Isotemp OCXO was purchased as a 12v unit but I was able to run it at 5v, albeit with increased current.
The shape of the 10MHz square wave was the same at both voltages. The DSO was set to unlimited bandwidth.
-
I am not familiar with OCXO specs so cannot determine if mine is suitable for use in your GPSDO project.
-
I am not familiar with OCXO specs so cannot determine if mine is suitable for use in your GPSDO project.
Well, we know it's a square wave version, now we just have to check the control voltage range. We'll do that later. First thing is flashing the firmware to the Black Pill.
-
Very interesting topic, thank you @AndrewBCN for sharing this project.
I'm a total noob and would like to implement this GPSDO. Searching for antennas in the Aliexpress, I found different options for use with GNSS. Will a better antenna give better results in this GPSDO application?
...
Yes, a better antenna will provide a more stable satellite signal reception and a lower jitter than a small "puck" antenna. If you decide to mount a GNSS antenna on the roof of your home then yes I would consider a better, more expensive antenna. Just for experimenting, a <$10 "puck" antenna with a 3 meters cable is good enough though.
I would start with a small antenna and once you have the STM32 GPSDO working and thoroughly tested, invest in a better, rooftop-mounted antenna.
Ok, I'll start with the small puck antenna. Thank you!
@rodpp
That 22 dollar puck antenna should be more than ok for the time being even if you have to extend the feeder by another ten metres. The most important aspect of any GPS antenna being that you site it in a location that has an unobstructed 360 degree view of the horizon.
I wouldn't bother upgrading to another fancy (and over-priced) navigation grade GPS/GNSS antenna. I'd save the money for a dual band timing grade antenna to make the most of a dual band GPS receiver module such as a u-blox ZED9 when you finally cave in to the pressure to upgrade to an even better setup. :)
I'm still using a mag mount puck antenna, similar to enut11's, that I bought three years ago for £2.99 delivered (less than 5 dollars!) from a UK based ebay seller. This had a 5 metre RG174 co-ax with male SMA plug making it an even better bargain than the more common 3 metre co-ax cabled types.
Even so, I needed to extend this by another 5 metres of RG174 (SMA in-line female to SMA male terminated patch lead) which surprisingly, only reduced the C/No ratio by a mere 2dB rather than by the 6 to 7 dB I was expecting of 5 metre's worth of RG174. This allowed me to locate the antenna on a ballasted biscuit tin parked on the flat bay window roof of my 1st floor workroom (2nd floor in the oddball American terminology that names the ground floor as the 1st floor).
Moving the antenna from a South West facing window ledge onto the bay window roof with a 180 degree view centred on a direct westerly view made a significant improvement in SV reception but it was completely obstructed to the East by the brickwork of the gable ended 2nd floor bedroom above which seemed to offer a 3dB boost by constructive reflection of near overhead satellite passes.
Ideally, I wanted to mount a short mast onto this brickwork in order to raise the antenna a foot or so above the ridge tiles to finally gain a full 360 degree view of the horizon but stepping out through the 2nd floor bedroom window onto this flat bay roof in order to drill into the brickwork was, to say the least, a bit too precarious even for me. The ballasted biscuit tin arrangement had only required me to lean out of said 2nd floor bedroom window, no actual crawling out onto the bay window roof needed (although I have done so in times past even through it's a bit of a struggle with the top hinged upward opening window).
I only needed to raise the puck antenna another 8 feet or so from the biscuit tin location to allow it to peek over the ridge tiles so when I spotted a 60 by 70cm metal drawer in the basement I'd been using to store some motorbike parts in, it came to me in a flash that I could extend the ballasted biscuit tin antenna mount setup using this with four old car batteries for ballast and a 7 or 8 foot 1 1/4" diameter aluminium (aluminum) pole clamped into one corner to which I could screw the 20cm diameter biscuit tin lid onto by which to mag mount that puck antenna, reinforced with some impact adhesive to make it somewhat secure against even hurricane level storms (an over-kill/engineered solution in most UK locations but only pennies to implement so, Why not? :) ).
The chosen pole was about 18 inches short of the required length and required another length of 3/4" diameter aluminium tube to be added a few months later. Despite this initial shortfall, I did see a significant improvement but the fact that the view of the horizon was not quite the full 360 degree I'd aimed for, niggled me enough to properly finish the job even though this required yet more faffing around to recover the support pole and extend its length and then relocate it back to its pride of place... about three times over!
There were a few changes to the groundplane mount and an "upgrade puck antenna" I'd wanted to try out. The "upgrade" antenna proved to be a washout since it seemed to lack any immunity to overloading by cellphone signals from a nearby tower so I landed up reverting to the original 3 quid puck and the 20cm biscuit tin lid setup.
I'd had to replace the original 5 metre RG174 patch lead, that I'd used to connect to the GPSDO via a cracked open window, with an 11 metre RG58 patch lead so I could reroute it through an existing conveniently located hole in the wall that had been drilled for a now long since redundant TV antenna feeder years before we'd moved into the property. The C/No figures range between 35 to 45 dB and have done so ever since I finalised this antenna mounting arrangement some 18 months ago.
That first image shows a navigation class antenna that Banggood had been selling for around £18 about a year ago. I think this was the version with a 16 metre RG58 co-ax and I had been tempted to buy one until reason stayed my hand. It had occurred to me that it would offer no more performance than the 3 quid puck I already had in my possession and it would be far better to invest in a dual band timing class antenna for when the pricing on dual band timing GPS receivers finally descends from out of the stratosphere.
Those fancy looking antennas will almost certainly be using the same 1 inch square patch antenna (pretty well the best choice for GNSS service) as that 22 dollar puck antenna. The radome comes into its own where you have to endure heavy persistent snowfall cursed winters - not usually a problem south of the Scottish border here in the UK.
Unless you have to endure such winter conditions or need to use a very long run of feeder, I'd save my money for a more effective dual band antenna upgrade and make do with a well sited cheap puck antenna for now.
So it seems that antenna is the last piece of the kit that I'll need to upgrade. I have no severe winter where I live, no snowfall. I'll go with the puck antenna. Thanks for sharing your experiences!
-
I am not familiar with OCXO specs so cannot determine if mine is suitable for use in your GPSDO project.
Well, we know it's a square wave version, now we just have to check the control voltage range. We'll do that later. First thing is flashing the firmware to the Black Pill.
When flashing the firmware using the Arduino software, does the sketch have to be compiled first?
-
Progress on the hardware so far. All modules are plug-in.
-
I am not familiar with OCXO specs so cannot determine if mine is suitable for use in your GPSDO project.
Well, we know it's a square wave version, now we just have to check the control voltage range. We'll do that later. First thing is flashing the firmware to the Black Pill.
When flashing the firmware using the Arduino software, does the sketch have to be compiled first?
In my limited experience of the Arduino IDE with nano MCUs (and one RPi Pico), the answer is yes. There's not much time to be saved by using the generated code from a previous compile time run so I guess there was little to no incentive to provide such a "time saving" option considering the hobbyist users to whom this was aimed at. Far less chance of the end user coming to grief by always forcing a recompile prior to every upload to the MCU.
-
I am totally lost here. I guess I don't have what it takes to follow along, much less to accomplish anything.
Flashing, compiling, all these terms aren't real to me. I wish someone would build this for me and I can be done with it. I have all the parts, I think. I just don't know how to proceed without screwing up. Maybe I have to accept being too old.
-
I am not familiar with OCXO specs so cannot determine if mine is suitable for use in your GPSDO project.
Well, we know it's a square wave version, now we just have to check the control voltage range. We'll do that later. First thing is flashing the firmware to the Black Pill.
When flashing the firmware using the Arduino software, does the sketch have to be compiled first?
It's a one-click operation: click on the "Upload" button in the Arduino IDE, this will compile the sketch and upload (flash) the firmware to the Black Pill.
-
Progress on the hardware so far. All modules are plug-in.
Well done. Two comments:
1. I would add a yellow/red LED + 330R resistor as per the schematic. This is the main status LED, it provides some useful indication of what's going on.
2. Don't use 12V for your OCXO! Power it with 5V for now. You'll damage the Black Pill if you apply a > 5.5V signal to any of its pins (as per the datasheet).
-
I am totally lost here. I guess I don't have what it takes to follow along, much less to accomplish anything.
Flashing, compiling, all these terms aren't real to me. I wish someone would build this for me and I can be done with it. I have all the parts, I think. I just don't know how to proceed without screwing up. Maybe I have to accept being too old.
Bob, as the title of this thread says, this is a DIY project. If you feel like you can't build it yourself, there is no shame in getting somebody to help you (a friend, your grandson, another electronics DIYer, etc), specially in regards to your age. But most importantly, I would say it's not worth getting frustrated over it.
Start with testing your OCXO with an oscilloscope, that's already one step that you can accomplish.
-
I am totally lost here.
C'mon, Bob, we're all rooting for you! You can get it done.
I don't want to derail this, but just a quick question:
For somebody who doesn't want to run a GPSDO all the time, wouldn't a good PPS do most of some minimal need?
Use it to gate a counter and you have ~1 Hz measurement in a second, ~0.001 Hz in 17 minutes?
Ok, I know that there is jitter in there too, but 1 ppm of 24 MHz is 24 Hz (xtal calibration on PSoC4) which should be easy.
What's the best receiver with a high res PPS for under ~$50? Thanks!
-
...
For somebody who doesn't want to run a GPSDO all the time, wouldn't a good PPS do most of some minimal need?
You are confusing a GPSDO with a frequency meter; these are two distinct instruments with different purposes. A GPSDO is a high accuracy low phase noise reference frequency generator, as the name indicates, where the frequency generated is either the fundamental or some harmonic of the oscillator that is "disciplined" (in the STM32 GPSDO, 10MHz). It may or may not output a 1Hz signal, and it may or may not have that 1Hz aligned with UTC/GPS time, these are optional auxiliary functions. And a GPSDO will continue to generate the reference frequency even without a GPS signal (that's called holdover mode).
Use it to gate a counter and you have ~1 Hz measurement in a second, ~0.001 Hz in 17 minutes?
Ok, I know that there is jitter in there too, but 1 ppm of 24 MHz is 24 Hz (xtal calibration on PSoC4) which should be easy.
What's the best receiver with a high res PPS for under ~$50? Thanks!
The best GPS receiver with a high res PPS is one where you have a good rooftop GNSS antenna with a clear view of the sky in 360 degrees. If you can get that for under ~$50, congratulations! ;)
Check a few posts back, I have posted a link to a comparison of various GPS receiver modules.
-
Wouldn't a good PPS do most of some minimal need?
You are confusing a GPSDO with a frequency meter...
Um, no I'm not. I could use a calibrated frequency meter. A 10 MHz carrier (no matter how pure) won't do anything for me as my hearing has deteriorated.
Many USB "hockey pucks" go for under $50. I run a BU-353S4 24/7. I'd rather not tear it apart to go find the PPS.
-
I have already tested the OCXO. Waveform looks good with the scope, the amplitude is fine, the frequency can be adjusted nicely with the control voltage (1.38V seems about right) and so all is well there.
Where I am having trouble is 1) mounting the parts properly (the OCXO has oddball pin spacing) and 2) the software/firmware aspects.
There seems to be an intellectual/experience gap I can't cross. I dip my toe into it and am immediately flummoxed. My grandson can be no help, as he has returned home to another state. My friends are mostly worse off than I, never having gone into this territory.
If I decide to rely on my rubidium standard, I can be done with this stuff and forget about GPSDO. But I really want to have a means of getting a solid, reliable frequency standard that coincides (as closely as possible) with the NIST value. Yes, I am an analog guy and can't seem to get on board with the digital stuff. You'd think that in the small town where I live (Los Angeles California) there ought to be a neighbor who would be willing to help but I know of no such person.
-
Where I am having trouble is 1) mounting the parts properly (the OCXO has oddball pin spacing) and 2) the software/firmware aspects.
...
I suggest you check the other forums here on EEVblog and ask for help on specific points where you are having trouble.
For mounting the parts: https://www.eevblog.com/forum/beginners/ (https://www.eevblog.com/forum/beginners/)
Also check the pictures posted by enut11. You can copy what he did to mount the (5 pins) OCXO on a perfboard.
For the Arduino IDE, programming and flashing the MCU: https://www.eevblog.com/forum/microcontrollers/ (https://www.eevblog.com/forum/microcontrollers/) or the excellent Arduino forum: https://forum.arduino.cc/ (https://forum.arduino.cc/)
-
Hey @bob91343. I understand your situation. I too grew up with analog electronics and struggle with all this digital stuff. However, we now live in a digital age so have to manage it in some way. There's lots of help on this Forum and all you need do is follow the advice, step by step, at your own pace.
enut11
@AndrewBCN, here is my powered-up GPSDO project. Added the LED as suggested (bottom left micro board) but there is still some wiring to do.
I am powering it all from a 12v SMPS plugpak into a 7805 5v regulator. The regulator directly powers the OCXO and there is a 5v takeoff to the micro board.
The small heatsink under the 7805 seems adequate for now and runs a little hotter than the OCXO.
-
@AndrewBCN
Some questions on the circuit. I intend to only use the modules above.
1) is Vocxo redundant?
2) What is the purpose of the 2.5v bias on STM pin26?
3) C4/C5 look to be part of a filter. Is the 10uF value critical? I have 22uF on hand.
enut11
-
...
@AndrewBCN, here is my powered-up GPSDO project. Added the LED as suggested (bottom left micro board) but there is still some wiring to do.
I am powering it all from a 12v SMPS plugpak into a 7805 5v regulator. The regulator directly powers the OCXO and there is a 5v takeoff to the micro board.
The small heatsink under the 7805 seems adequate for now and runs a little hotter than the OCXO.
Looking good. :-+ Thanks for the pics, btw.
-
@AndrewBCN
Some questions on the circuit. I intend to only use the modules above.
1) is Vocxo redundant?
2) What is the purpose of the 2.5v bias in STM pin26?
3) C4/C5 look to be part of a filter. Is the 10uF value critical? I have 22uF on hand.
enut11
1) Vocxo is only used if you are using an optional INA219 current sensor to measure the power consumption of the OCXO, you can ignore it in your case.
2) That's explained in the schematic version 0.6. Actually that's an input to the ADC channel 0, we just measure Vcc divided by 2. IIRC it's also optional. :)
3) C4 and C5 are used to filter the PWM output of the STM32 to generate Vctl. In your case you have the choice of using the MCP4725 DAC or this simple PWM. I suggest you use the PWM. And no the value of C4/C5 is not critical, 22uF should work fine.
Why the PWM and not the DAC? The PWM is 16 bit and the DAC is 12 bit resolution.
-
Thanks. In that case I do not need the 4725 DAC so I will unplug it and save a bit of power. Also, I will not use the 4.7K/4.7K divider to pin 26 of STM micro
The 7805 was getting too hot with the small heatsink so I interfaced a programmable pre-regulator, here showing ~8.5v/220mA
Easy part done (all the wiring), now the hard part - loading the control program >:D
Do I need to unplug the micro from the PCB in order to program it via USB C?
-
Thanks. In that case I do not need the 4725 DAC so I will unplug it and save a bit of power. Also, I will not use the 4.7K/4.7K divider to pin 26 of STM micro
The 7805 was getting too hot with the small heatsink so I interfaced a programmable pre-regulator, here showing ~8.5v/220mA
Easy part done (all the wiring), now the hard part - loading the control program >:D
Do I need to unplug the micro from the PCB in order to program it via USB C?
Looking very good. :-+ In principle, you can program the STM32 Black Pill in-circuit and run the firmware while always connected to your PC - and read the status messages on the Arduino IDE Serial Monitor (see my post on the first page of this thread). This is actually almost essential for testing/debugging, since you don't have an OLED display.
But for testing your STM32 programming setup (with the Blinky program) I would disconnect the Black Pill from the perfboard.
Once you have passed the "Blinky test", we can proceed to configure the firmware to your hardware setup.
-
This is the website that I was working from:
https://www.sgbotic.com/index.php?dispatch=pages.view&page_id=49 (https://www.sgbotic.com/index.php?dispatch=pages.view&page_id=49)
Man, what a process downloading and installing the Arduino IDE!
I ended up with V1.8.16. I also downloaded and installed STM32Cube.
I then copied the 'blink' code into a new page on the IDE and started the upload process.
I received an error message
Arduino: 1.8.16 (Windows Store 1.8.51.0) (Windows 10), Board: "Generic STM32F4 series, BlackPill F411CE, STM32CubeProgrammer (DFU), Enabled (generic 'Serial'), CDC (generic 'Serial' supersede U(S)ART), Low/Full Speed, Smallest (-Os default), Newlib Nano (default)"
Sketch uses 22128 bytes (4%) of program storage space. Maximum is 524288 bytes.
Global variables use 3624 bytes (2%) of dynamic memory, leaving 127448 bytes for local variables. Maximum is 131072 bytes.
An error occurred while uploading the sketch
STM32_Programmer_CLI.exe not found.
Please install it or add <STM32CubeProgrammer path>\bin' to your PATH environment:
https://www.st.com/en/development-tools/stm32cubeprog.html (https://www.st.com/en/development-tools/stm32cubeprog.html)
Aborting!
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
Could this be due to me changing STM32Cube from the default installation directory?
-
...
Could this be due to me changing STM32Cube from the default installation directory?
I can't really help you here, because I use Linux and you are using Windows 10. But from the error message, it seems you can solve the problem by uninstalling STM32Cube and reinstalling it in its default installation directory, where the Arduino IDE should be able to find it.
If you need help with this Windows 10 installation, please take a look at the STM32duino forum, there are a number of very competent people there willing to help.
https://www.stm32duino.com/viewforum.php?f=35 (https://www.stm32duino.com/viewforum.php?f=35)
-
for arduino ide need a package
https://github.com/stm32duino/Arduino_Core_STM32
as it described in "getting started" .JSON url add in "Additional Boards Managers URLs" ; that located: Files -> Preferences; at very bottom as stated "additional ... " with window on right side, click on to add more url's board
then:
menu Tools -> Board -> right side board manager type STM32, it will shows "STM32 MCU based board" i think it 2.1V
older version
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
-
Well, some success with Blinky, but I am not sure!
I re-installed the STM32 Cube into its default directory.
I then tried to upload Blinky but got the following error message:
"Error: No debug probe detected"
On re-connecting the STM32 to USB the blue led now blinks slowly.
As I said, I am not sure if it has successfully passed this test!
-
Well, some success with Blinky, but I am not sure!
I re-installed the STM32 Cube into its default directory.
I then tried to upload Blinky but got the following error message:
"Error: No debug probe detected"
On re-connecting the STM32 to USB the blue led now blinks slowly.
As I said, I am not sure if it has successfully passed this test!
It seems "Blinky" has been flashed successfully! :-+
Now you can try to upload a program to test the serial monitor and then we can move on to testing the GPSDO firmware.
To test the serial monitor, try flashing the Communication-> ASCII table example. Open the serial monitor and you should see the ASCII table being printed out.
-
A little more info on the serial monitor test please.
As for the "blinky" test, it is more a fading in-out of the blue LED rather than a flash which makes me think that something is not working?
-
basically arduino looking for PATH for bin folder for CubeProg, in overall you can install it in any place adding path, or create a custom one per session. like:
my working folder: C:\Arduino ; inside C:\Arduino\arduinoIDE - with IDE and STM: C:\Arduino\STM32CubeProg
i created runard.BAT in :\Arduino\arduinoIDE , to launch IDE, with custom PATH variable it looks like, last after ; is what we need :
REM ------
SET PATH=C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Arduino\STM32CubeProg\bin
arduino.exe
REM ------
for com port, when you STM running, it will be COM port in your system, to know precise one:
You can press Windows + R keys simultaneously to open Windows Run.
type compmgmt.msc, and hit Enter to open it.
Device Manager -> Ports (COM @ LPT) ... List of ports (COM-X ) your device
compilation process in IDE should invoke STM ... like this:
Sketch uses 22156 bytes (8%) of program storage space. Maximum is 262144 bytes.
Global variables use 3624 bytes (5%) of dynamic memory, leaving 61912 bytes for local variables. Maximum is 65536 bytes.
-------------------------------------------------------------------
STM32CubeProgrammer v2.6.0
and so ... lot of additional info .... ending:
File download complete
Time elapsed during download operation: 00:00:01.152
RUNNING Program ...
Address: : 0x8000000
Start operation achieved successfully
-
Gigajoe quote
"You can press Windows + R keys simultaneously to open Windows Run.
type compmgmt.msc, and hit Enter to open it.
"
Yes, I did this after plugging the STM32 into the USB port. It did not show up in Device Manager Ports. Do any of the buttons on the STM32 board have to be pressed?
-
Gigajoe quote
"You can press Windows + R keys simultaneously to open Windows Run.
type compmgmt.msc, and hit Enter to open it.
"
Yes, I did this after plugging the STM32 into the USB port. It did not show up in Device Manager Ports. Do any of the buttons on the STM32 board have to be pressed?
Yes, you have to keep the BOOT button pressed while plugging in the USB C cable to the STM32 board, to enter DFU mode. Check post #78 on page 4 of this thread, I pointed Bob around three months ago to a website that explains the STM32 flashing procedure in detail. Or ask on the STM32duino forum.
-
you need drivers to support com port mode , and DFU programming mode, drivers installing with cube prog, or separately, able to find it in folder ...\STM32CubeProg\Drivers - where CUBE Prog was installed
so when STM plug-in and running it will be COM port, press -0 and reset - DFU mode, if no com port, and DFU - as exclamation mark in devices - drivers not installed (or STM not recognized )
try restart PC if drivers was installed ....
UPD: just a note , if ublox connected to PA9 PA10, as on PDF diagram, it possible that board using the same pins for USB, it depends on model. so STM will not recognized in OS.
-
Gigajoe quote
"You can press Windows + R keys simultaneously to open Windows Run.
type compmgmt.msc, and hit Enter to open it.
"
Yes, I did this after plugging the STM32 into the USB port. It did not show up in Device Manager Ports. Do any of the buttons on the STM32 board have to be pressed?
Yes, you have to keep the BOOT button pressed while plugging in the USB C cable to the STM32 board, to enter DFU mode. Check post #78 on page 4 of this thread, I pointed Bob around three months ago to a website that explains the STM32 flashing procedure in detail. Or ask on the STM32duino forum.
Thanks for the reminder @AndrewBCN. Looks like I skipped over that when I was scanning the thread to catch up on what I had missed.
I must say that Win10 is very fussy in handling the STM32 via USB, more often than not rejecting and refusing to talk to it.
Anyway, using reply #78, I managed to to get Blinky to work properly this time. I then loaded the ASCII program and got the following response in Monitor:
"ASCII Table ~ Character Map
!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct: 47, bin: 100111
(, dec: 40, hex: 28, oct: 50, bin: 101000
), dec: 41, hex: 29, oct: 51, bin: 101001" plus a lot more...
So that appears to work.
I believe I am now ready to tackle the REAL program to control my GPSDSO. :)
-
@AndrewBCN quote:
"PS: I have just noticed that STM32 Core version 2.1 has just been released a few days ago. It is the version I recommend for use with the STM32 GPSDO firmware.
« Last Edit: October 11, 2021, 07:32:22 pm by AndrewBCN »"
The latest Core for my Black Pill F401CC is version 1.9. Is this a problem?
enut11
-
@AndrewBCN quote:
"PS: I have just noticed that STM32 Core version 2.1 has just been released a few days ago. It is the version I recommend for use with the STM32 GPSDO firmware.
« Last Edit: October 11, 2021, 07:32:22 pm by AndrewBCN »"
The latest Core for my Black Pill F401CC is version 1.9. Is this a problem?
enut11
Yes. Actually it's the other way around, the earliest Core for the Black Pill F401CC was version 1.9. Please uninstall version 1.9 (simply delete the whole directory) and then reinstall 2.1 from this link: https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/2.1.0
-
...
Anyway, using reply #78, I managed to to get Blinky to work properly this time. I then loaded the ASCII program and got the following response in Monitor:
"ASCII Table ~ Character Map
!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct: 47, bin: 100111
(, dec: 40, hex: 28, oct: 50, bin: 101000
), dec: 41, hex: 29, oct: 51, bin: 101001" plus a lot more...
So that appears to work.
I believe I am now ready to tackle the REAL program to control my GPSDSO. :)
Excellent! :-+ Well done.
-
You can press Windows + R keys simultaneously to open Windows Run.
type compmgmt.msc, and hit Enter to open it.
For directly to the Device Manager:
C:\>devmgmt.msc
-
This ublox NEO-M9N board looks pretty nice and a decent value at $40.
It's designed as a daughter board for some arbitrary standard, but that shouldn't hurt much.
https://www.digikey.com/en/products/detail/MIKROE-3922/1471-MIKROE-3922-ND/11507397 (https://www.digikey.com/en/products/detail/MIKROE-3922/1471-MIKROE-3922-ND/11507397)
What do you think?
-
A few months ago I bought a Neo-M8N board and a cheap Bingfu puck antenna. Both together were less than $25 from Amazon (of course I threw in some other random cheap item to get free shipping).
Indoors and 3 meters from any window, the GPS module alone did struggle to connect. But once I hooked up the antenna it was able to connect in a matter of minutes. As far as I can tell from the u-blox software the part is genuine.
https://www.eevblog.com/forum/chat/what-did-you-buy-today-post-your-latest-purchase!/msg3612283 (https://www.eevblog.com/forum/chat/what-did-you-buy-today-post-your-latest-purchase!/msg3612283/#msg3612283)
-
A few months ago I bought a Neo-M8N board...
Oh, I hadn't realized that those little guys had a micro USB connector on them too.
I have a NEO-5M (that was discontinued ~2014?) on a fleet surveilance board that I removed from a friend's 2nd hand van!
I forget where the SMA antenna went to. In any case, with a 1/4 wave antenna it can barely pick up the time sometimes.
So I ordered the NEO-M9N and an active antenna.
-
@AndrewBCN quote:
"PS: I have just noticed that STM32 Core version 2.1 has just been released a few days ago. It is the version I recommend for use with the STM32 GPSDO firmware.
« Last Edit: October 11, 2021, 07:32:22 pm by AndrewBCN »"
The latest Core for my Black Pill F401CC is version 1.9. Is this a problem?
enut11
Yes. Actually it's the other way around, the earliest Core for the Black Pill F401CC was version 1.9. Please uninstall version 1.9 (simply delete the whole directory) and then reinstall 2.1 from this link: https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/2.1.0
V1.9 STM32 Cores is the only option I have in the Arduino setup and I don't know how to update to the later version.
Is it possible to run the GPSDO with STM32 Cores V1.9?
-
Is it possible to run the GPSDO with STM32 Cores V1.9?
STM32 Core 1.9 and 2.0 have several bugs that are fixed in 2.1.
Please uninstall both the STM8 and STM32 support packages you have installed (deleting the directories should do it), and reinstall the STM32 Core 2.1 package following the instructions on GitHub. This should take less than 5 minutes.
You should not have the DEPRECATED warning if you follow the installation instructions correctly to install STM32 Core 2.1.
https://github.com/stm32duino/Arduino_Core_STM32/#getting-started (https://github.com/stm32duino/Arduino_Core_STM32/#getting-started)
If you are still unsure, please create a thread in the STM32duino forum and ask for detailed instructions. https://www.stm32duino.com/viewforum.php?f=35 (https://www.stm32duino.com/viewforum.php?f=35)
-
Serial2.print("$PUBX,41,1,0003,0003,115200,0*1C\r\n"); // 115200
a bit faster ...
-
When I add
https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/2.1.0
to the Arduino IDE Preferences, the only option that I can see in the Board Manager for 2.1 support is the deprecated version.
A little lost at the moment...
Posted a help request on Arduino STM32 forum.
-
Uninstall then reinstall the Arduino IDE.
Then in File menu -> Preferences
The "Preferences" dialog will open, then add the following link to the "Additional Boards Managers URLs" field:
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
Then in Boards Manager dialog you should have the option to install STM32 Core 2.1 without the DEPRECATED warning.
-
@AndrewBCN
You should edit your first post, and add an url to your github repos
/Bingo
-
...
You should edit your first post, and add an url to your github repos
...
The link to my GitHub repo has been in my first post since the very first day.
-
Whoopzz - :palm:
But where is SerialCommands.h ??
Ahh .. found it , it's also in the library manager
https://github.com/ppedro74/Arduino-SerialCommands
Success
Sketch uses 72460 bytes (13%) of program storage space. Maximum is 524288 bytes.
Global variables use 94244 bytes (71%) of dynamic memory, leaving 36828 bytes for local variables. Maximum is 131072 bytes.
-
Whoopzz - :palm:
But where is SerialCommands.h ??
Ahh .. found it , it's also in the library manager
https://github.com/ppedro74/Arduino-SerialCommands
Success
Sketch uses 72460 bytes (13%) of program storage space. Maximum is 524288 bytes.
Global variables use 94244 bytes (71%) of dynamic memory, leaving 36828 bytes for local variables. Maximum is 131072 bytes.
Well done. :-+
Are you just compiling the firmware for fun or are you actually building an STM32 GPSDO?
-
I'm preparing a bit.
But i need to finish my favorite PICDIV Clone (1-PPS source) as per here
https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg3663190/#msg3663190 (https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg3663190/#msg3663190)
And will prob do an alternate PhaseDetector too.
Do you still use the DAC or was that replaced by PWM ?
What gives the best resolution / voltage stability ?
I have some DAC's here
/Bingo
-
...
Do you still use the DAC or was that replaced by PWM ?
I have both the DAC and the PWM circuit installed in my two working prototypes, but of course Vctl is only connected to one, and it's the PWM for now. If I need to go beyond 16-bit resolution, I might cook up a circuit that uses both.
What gives the best resolution / voltage stability ?
The 16-bit PWM works fine, but I can't really compare effective resolution and stability between it and the 12-bit DAC. There's simply too much noise in my breadboard prototypes.
-
I got my ublox NEO-M9N in and was impressed with how much stuff is flying around. Visibile was 14 GPS, 7 GLONASS, 7 Galileo, 5 BeiDou. For somebody born before Sputnik, this is impressive. Ok, there's a ton more Iridium, Starlink, etc flying around.
Anyway, does this really get us a lot when we're dealing with a basic 16MHz clock as far as jitter goes?
-
I got my ublox NEO-M9N in and was impressed with how much stuff is flying around. Visibile was 14 GPS, 7 GLONASS, 7 Galileo, 5 BeiDou. For somebody born before Sputnik, this is impressive. Ok, there's a ton more Iridium, Starlink, etc flying around.
Anyway, does this really get us a lot when we're dealing with a basic 16MHz clock as far as jitter goes?
The M9N is a navigation module and has similar jitter of previous navigation modules. Other people have indicated for timing it is better to listen to only one constellation (e.g. GPS) as each constellation has slightly different time base. More important if using a specific timing module where the GPS module reports the correction to the 1pps and the processor can correct it down to ns level. With a naviagtion module just have to put up with the jitter and rely on the software to smooth it out.
-
STM32 GPSDO new layout on two breadboards with the picDIV clocked by the OCXO.
The picDIV is programmed to output three 1PPS signals: 1Hz square wave (not used), 10ms pulse here shown connected to a green LED (so I know it's working), 100µs pulse which will be connected to the TIC to measure its phase difference with the 1PPS from the u-blox NEO-M8N GPS module. The TIC will be configured to measure up to 1000ns phase difference with a theoretical resolution of 0.25ns, but I'll check and report the real resolution here.
Note the use of a separate LM317T voltage regulator module (top left) that supplies +5V to the OCXO @ 600mA during warmup, 200mA in normal operation. The LM317T is attached to a small heatsink and gets to around 45C in normal operation (at 20C room temperature), well within operating parameters.
-
This is a tangent to the original topic of this post, but I'm just wondering if the Raspberry Pi Pico device would be an interesting choice for this kind of project. The reason I'm thinking that is that it has some programmable state machines that can be synchronously clocked up to 200 MHz (unofficially, but in my experience reliably), and their I/O can both generate and detect pulses at Fclock/2 meaning 100 MHz or 10 ns timing resolution. As I recall a PIC does not go so high. I have not studied the code closely, but I'm wondering if a Pico might be able to serve the function of both the STM32 and the picDIV parts of this project. The Pico board is also generally cheaper than a STM32.
-
This is a tangent to the original topic of this post, but I'm just wondering if the Raspberry Pi Pico device would be an interesting choice for this kind of project.
You can base your GPSDO on just about any MCU (or even no MCU at all), but your choice of MCU will essentially determine how much can be done in hardware and how much will have to be done in software. I chose the STM32F411CEU6 because it is a comparatively powerful, fast MCU, has tons of RAM and flash, and a number of very flexible peripherals and interfaces.
Just to give you one parameter that would automatically exclude the RP2040: it has a single, dedicated 64-bit timer with µs resolution (RP2040 datasheet page 555). By contrast, the STM32F411 has 2 x 32-bit and 6 x 16-bit general purpose timers with capture and external triggers all internally clocked at 48MHz, plus a few more dedicated timers. There is simply no comparison in terms of flexibility.
Also, note that unlike the STM32F411CEU6, the RP2040 has no 5V tolerant pins at all.
Finally, and I won't even go into the details here, but the availability of I/O libraries for the STM32F411 was paramount in the development of the STM32 GPSDO software.
The reason I'm thinking that is that it has some programmable state machines that can be synchronously clocked up to 200 MHz (unofficially, but in my experience reliably), and their I/O can both generate and detect pulses at Fclock/2 meaning 100 MHz or 10 ns timing resolution. As I recall a PIC does not go so high. I have not studied the code closely, but I'm wondering if a Pico might be able to serve the function of both the STM32 and the picDIV parts of this project.
You are welcome to try and port both the STM32 GPSDO and the picDIV firmwares to the RP2040, but I would not underestimate the amount of programming and debugging required to make the RP2040 "state machines" do what you want. Some people like the challenge of "reinventing the wheel" for their hobby projects, but me, I'll pass. YMMV of course.
The Pico board is also generally cheaper than a STM32.
You must consider the cost of the MCU development board in relation to the total BOM cost for the project.
When you can find the Pico, it costs more or less the same as the STM32F411CEU6 Black Pill + a PIC12F675, that is < 10€ (including taxes and shipping), with perhaps a few euros difference. Personally I would consider a difference of a couple of euros to be relatively irrelevant in this sort of project.
-
@JBeale
Exactly.
You may like to check Time Nuts forum for Marek Dorsic's PicoDIV/PicoPET (RP2040) and Jeremy Elson's $5 Timestamper (STM32G4xxx) entries.
-
@AndrewBCN
Thanks for reminding us all of the pitfalls of trying to use the Arduino IDE with a Rpi Pico (and, of course all the other pitfalls). After my initial misguided enthusiasm in comparing it as "An STM32F411 on steroids", I have to admit I'd been somewhat conned by the marketing hype in its abilities, most notably its 133MHz clock speed and the statements made in regard of being able to use the Arduino IDE to program it.
Whilst it has some very interesting features (IO with programmable state machine features) and can, in theory, be programmed using the Arduino IDE, this is of little use when, as you reminded us all, there is little to no library support for peripherals for those of us who'd rather not have re-invent wheels in order to transition away from the AVR based Arduino MCU boards to this more powerful version of a nano. This is an issue I discovered for myself several weeks back.
No doubt, given enough time, we may yet see a build up of libraries to support the common peripherals (BMP280 and the SSD1306 being two of some interest to my current needs) but there's no guarantee that this will happen within the next 12 months considering that it was released to the market some ten months ago now.
Trying to persuade the Pico to do something more interesting than simply blinking or fading its on-board LED has been an exercise in futility for me so far, so it looks like I'm stuck with the arduino nano mcu for the time being or else acquaint myself with an STM32F411 which looks to be a better way to combine the ease of the Arduino IDE with a more powerful MCU. Unfortunately, with all the chip shortages, now is not the best time to go shopping for any of these STM32F411 based mcu boards so I'll carry on as best I can with my stock of pre-chip shortage mcu purchases and just hope it's not too long before the situation improves.
-
@JBG
You can still buy STM32F411 (Blackpill) at ebay or aliexpress , for a reasonable price.
For many things the "Little Brother" STM32F401 is fully capable (just a little less flash/ram) , and it's close to ½ price.
/Bingo
-
@bingo600
Thanks for that tip (although I'd rather deal with Banggood than AliExpress). I'll check out those sources and take my chances with one of them if the price hasn't been hiked up too much. :)
I've just had a quick look and my best bet (UK supplier with free three day delivery and VAT inclusive pricing) is this ebay item at £7.99 one off price :-
https://www.ebay.co.uk/itm/234243041497?hash=item3689f928d9:g:fPUAAOSwMjNhbaLK (https://www.ebay.co.uk/itm/234243041497?hash=item3689f928d9:g:fPUAAOSwMjNhbaLK)
I haven't pulled the trigger (I'm thinking buying two - for a two off price of £15.66, possibly even three for £23.01).
Banggood only had the lower spec 401 modules at a vat inclusive £6.29 and free delivery. AliExpress otoh, had a whole bunch of the 411s on this page:-
https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20211021081453&SearchText=STM32F411 (https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20211021081453&SearchText=STM32F411)
I checked out the first one here:-
https://www.aliexpress.com/item/1005001798664558.html?spm=a2g0o.productlist.0.0.1526692e24npFI&algo_pvid=92a76e03-1c86-4c4b-a392-789fd089af88&aem_p4p_detail=20211021091454609157465904160010711167&algo_exp_id=92a76e03-1c86-4c4b-a392-789fd089af88-4&pdp_ext_f=%7B (https://www.aliexpress.com/item/1005001798664558.html?spm=a2g0o.productlist.0.0.1526692e24npFI&algo_pvid=92a76e03-1c86-4c4b-a392-789fd089af88&aem_p4p_detail=20211021091454609157465904160010711167&algo_exp_id=92a76e03-1c86-4c4b-a392-789fd089af88-4&pdp_ext_f=%7B)"sku_id"%3A"12000017626172510"%7D
After adding the postage (10 day delivery) and 20% VAT onto the whole deal, it came to £7.08 Quite frankly, AliExpress is my last resort, either to buy an item not sold elsewhere or a widely available item that's outrageously overpriced by their competitors (mainly Amazon).
The ebay seller seems to be my safest option (relatively local seller and ebay's money back promise when the seller fails to remedy any shortcomings). However, I thought I'd best seek your opinion on these options before placing my order. :)
-
@bingo600
Just in case you missed my previous edited post... er, it's, well, been edited with the results of my search for suppliers. :)
[EDIT] Never mind, I've pulled the trigger on that ebay order for three modules. They should be with me by Monday, just possibly even sooner.
-
Two small changes to the STM32 GPSDO KiCad schematic, so a schematic version bump from 0.6 to 0.6.1:
- The MCU output pin that connects to the picDIV "Arm" input was changed from PB5 to PB3.
- The MCU PB5 output pin now generates a 2kHz square wave test signal. As usual, this is optional and can be disabled in the source code.
-
@JBG
The US seller is prob. as good as Ali.
The only reason for Ali would be price or WeAct (The original blackpill creator) , that still has a reputation of delivering 100% genuine STM chips
https://www.aliexpress.com/item/1005001456186625.html (https://www.aliexpress.com/item/1005001456186625.html)
Happy coding.
Ps: I hope you have a few USB-A to USB-C cables @home , the Blackpill uses USB-C
The Blackpill F401/411 can load the sw via USB DFU (load over usb cable) , so no jtag is needed for programming that one.
Allthough i'd prob recommend one anyway ... For advanced debugging.
https://www.ebay.co.uk/itm/292479630125 (https://www.ebay.co.uk/itm/292479630125)
/Bingo
-
In the first attached DSO capture below, shown are the two rising edges for respectively:
- In Yellow, bottom trace, 1PPS from the GPS module. This has a typical peak +/- 10ns jitter when receiving 11~12 sats.
- In Green, top trace, 100µS pulse at 1Hz from the picDIV (10MHz from the OCXO divided by 10 million by the picDIV), aligned within 20ns manually by controlling Vctl from my smartphone via Bluetooth! 8)
Explaining: the DSO capture shows the time interval or phase difference in ns between the two positive edges from the 1PPS from the GPS module and the 1PPS from the picDIV (which is really the 10MHz from the OCXO divided by 10 million). By controlling the OCXO frequency one can bring down this time interval to approximately its "floor" value which is the jitter in the GPS 1PPS.
This is how any GPSDO based on a PLL works, essentially. In this case, for this shot I was acting as a "human PLL", by manually adjusting the Vctl of the OCXO.
So, how to automate this? This is where Lars' ingenious 1ns resolution TIC comes into play. I will be using Erik's version of Lars' 1ns resolution TIC to obtain a voltage proportional to the time interval between the two PPS edges. The voltage is then read by the STM32F411CEU6 ADC, and converted back into an approximate time interval value in nanoseconds.
So the next two steps are:
- Wire the TIC and feed the MCU ADC with a voltage.
- Program the PLL.
In the second DSO capture below: using the "Arm" pin on the picDIV, one can "synchronize" the 1PPS from the picDIV with the 1PPS from the GPS module. I have tested this repeatedly and this has always resulted in the same approximately 700ns delay between the two pulses, which is very convenient because it's almost midrange in the range of time intervals the TIC can measure (0 to 1000ns). To reduce this time interval to < 100ns one just "accelerates" the OCXO clock for a few seconds (by raising the Vctl value) while checking the value returned by the TIC. In an nutshell, that's (simplifying very much) how the PI algorithm in Lars' DIY GPSDO works.
Also note that the DSO measurement has itself a 2ns resolution (at 500M samples per second).
Finally: the objective of adding a picDIV and Erik's version of Lars' TIC (for a total cost of around 4€ and 100~200 lines of code) is to get a UTC aligned top-of-second PPS from the OCXO within an as small as possible time window, in this case, hopefully less than 100ns and ideally less than 50ns. This in turn will be passed on to an NTP/PTP server based on a 25€ STM32 Nucleo board to provide precise timing information to a local network.
Remember, the idea is to surpass the > $3000 to build (if you manage to purchase the "unobtainium" bits and pieces for it), > $3 million to develop, 200ns-accurate FacePlant GPSDO "Time Machine" with a solution that outperforms it by 100% and costs < 1/20th as much to build.
-
@bingo600
Thanks for the heads up on the USB A to C cable requirement. I only have, as far as I can see, just the one short cable which is most likely just a charging cable without the data wires. Possibly it may be a full lead just for the sake of being able to signal the higher charging current demand of the vaping stick it was supplied with but it looks like it would only be prudent of me to order a few 'spares' from ebay anyway just to be sure I can connect these modules to my desktop PC.
Well, that's £10.11 blown on four cables (from four different UK based ebay sellers). I'd already stocked up on micro and mini B ended cables in 0.5 to 5 metre lengths including two or three 5 metre A plug to A socket extension cables so I think it would be a good idea to address this blind spot in my USB cable inventory. :)
I don't mind this investment in C type ended USB cables since I've always regarded the micro B plug as an abomination that should never have been inflicted upon the general smartphone/tablet owning public in the first place - it's what the micro B connector should have been to begin with. The sooner all those USB micro B socketed devices end up in land fill and we can all forget that that mistake ever happened , the better afaic. >:D
-
Having wired the 1ns resolution, 1000ns range TIC (Erik's version of Lars' TIC), attached is a DSO capture of the TIC output voltage. Bottom Yellow trace is the 1PPS from the GPS module, top Green trace is the TIC output voltage.
Explanation (please refer to the schematic page 2): a 1nF capacitor gets charged through a 1k resistor for X ns, X being the time difference between the GPS 1PPS and the picDIV 1PPS rising edges, which in the capture below is around 730ns. Hence the voltage output by the TIC when the capacitor is charged is more or less proportional to X, where X is between 0 and 1000ns. The 1nF capacitor is slowly discharged by a 1M resistor in parallel.
The 1PPS from the GPS also generates an interrupt, which causes the MCU to read the ADC channel that is connected to the TIC. The MCU then will use this information to adjust Vctl (the OCXO frequency control voltage) to minimize the phase difference between the 1PPS from the GPS and the 1PPS from the picDIV.
As can be seen in the DSO capture, there is still a lot of noise in the TIC output voltage, but it's manageable.
-
Just a minor footnote...
Most board GPS have an easily accessible PPS output, the consumer hockey pucks, not so much.
The (very common) GlobalSat BU-353S4 has a blinky LED but at 0.5 Hz (groan).
If you take one apart you'll see that there is a 6 pin connector with one pin not populated.
If you happen to have a spare 1mm pitch pigtail you can stuff the contact in.
The actual signal is a 1.8V logic signal but it's straining a bit under the LED drive.
I just took a pair of dykes to the LED, the signal swings 0.0 to 1.8V now.
-
Hi,
My parts arrived from China. I followed the schematics and it didn't work.
After some troubleshooting, I concluded that the GPS M8N is defective. It arrived with some scratches, so it probably was used before, albeit it was selled as new (product link: https://www.aliexpress.com/item/32672644764.html?spm=a2g0s.9042311.0.0.42f84c4dIWiH8P (https://www.aliexpress.com/item/32672644764.html?spm=a2g0s.9042311.0.0.42f84c4dIWiH8P)).
See attached some pictures of the circuit and of the defective M8N GPS module. I changed some things in the code to show informations on the OLED display, even without the GPS module working, otherwise it stays locked waiting an GPS response and shows nothing on the screen.
I ordered locally another GPS module to replace this one.
Regards,
Rodrigo.
-
Hi,
My parts arrived from China. I followed the schematics and it didn't work.
After some troubleshooting, I concluded that the GPS M8N is defective. It arrived with some scratches, so it probably was used before, albeit it was selled as new (product link: https://www.aliexpress.com/item/32672644764.html?spm=a2g0s.9042311.0.0.42f84c4dIWiH8P (https://www.aliexpress.com/item/32672644764.html?spm=a2g0s.9042311.0.0.42f84c4dIWiH8P)).
:
:
Regards,
Rodrigo.
I have a similar GPS module, I just connected it to a USB port on the computer with a cable from the USB port on the module. The USB supplies +5 to run the module and it runs. The module appears as a serial device, COM5, 9600 baud. I used Tera Term to see the serial data, it looked OK. I plugged in an antenna, and loaded VisualGPS (not VisualGPSview, I don't like it) and it show the module has a fix and is working.
I suggest you try this before saying the M8N is defective, the problem may be somewhere else.
-
Hi,
My parts arrived from China. I followed the schematics and it didn't work.
After some troubleshooting, I concluded that the GPS M8N is defective. It arrived with some scratches,
...
Regards,
Rodrigo.
Hello Rodrigo.
First, thank you for the pictures. :-+ Looking good!
I see two problems with the GPS module:
1. The scratches you describe. It almost seems like someone was trying to "tune" the patch antenna. In any case, with these scratches I don't think it is going to work.
2. It's not an M8N, it's an M8L! First time I see an M8L, btw! Very strange.
You can open a dispute and ask for a full refund, including shipping costs. I have been promptly refunded by AliExpress before in some cases.
As MIS42N suggested, you can test the GPS module separately, or in-circuit with the small Arduino sketch I am attaching.
Are you using an extra "puck" antenna?
And yes, without a PPS the STM32 GPSDO does almost nothing. It really depends on the PPS signal to work.
-
I have a similar GPS module, I just connected it to a USB port on the computer with a cable from the USB port on the module. The USB supplies +5 to run the module and it runs.
Yes, the model shown will just run off USB power.
A board I have had an unpopulated jumper/0 ohm labelled "USB PWR" you needed to bypass for standalone USB operation.
-
A small warning.
When you have the GPS module on a breadboard surrounded by all kind of high frequency wires the GPS may find it difficulty to lock (at least mine did).
To solve you put the GPS module as far away as possible from all the high frequency wires.
This locking problem should be very visible when connected to a PCB using the USB port.
Once the GPS module gets close to the digital wires the number of satellites goes down and you even may loose GPS lock
-
I have a similar GPS module, I just connected it to a USB port on the computer with a cable from the USB port on the module. The USB supplies +5 to run the module and it runs. The module appears as a serial device, COM5, 9600 baud. I used Tera Term to see the serial data, it looked OK. I plugged in an antenna, and loaded VisualGPS (not VisualGPSview, I don't like it) and it show the module has a fix and is working.
I suggest you try this before saying the M8N is defective, the problem may be somewhere else.
I tried to connet it using the USB without success, the computer doesnt detect it.
I installed the VisualGPS and it doesn't detect it either.
Hello Rodrigo.
First, thank you for the pictures. :-+ Looking good!
I see two problems with the GPS module:
1. The scratches you describe. It almost seems like someone was trying to "tune" the patch antenna. In any case, with these scratches I don't think it is going to work.
2. It's not an M8N, it's an M8L! First time I see an M8L, btw! Very strange.
You can open a dispute and ask for a full refund, including shipping costs. I have been promptly refunded by AliExpress before in some cases.
As MIS42N suggested, you can test the GPS module separately, or in-circuit with the small Arduino sketch I am attaching.
Are you using an extra "puck" antenna?
And yes, without a PPS the STM32 GPSDO does almost nothing. It really depends on the PPS signal to work.
Thanks for the sketch, i tried but no success.
I'm using the puck antenna. I checked the RX/TX pins using the scope serial decoder, and it only shows data coming from the STM32F411 to the Ublox and no data from the Ublox to the SMT32F411.
But it seems I have a problem with the TinyGPS++ library, even with the basic example that do not need a GPS module (it creates the GPS response string), the STM32F411 is not presenting data on the serial console as it should.
Other examples like the Communications->Ascii are working normally with the serial console. I'll investigate it further.
Yes, the model shown will just run off USB power.
A board I have had an unpopulated jumper/0 ohm labelled "USB PWR" you needed to bypass for standalone USB operation.
My unit is not recognized when connected in the USB port.
A small warning.
When you have the GPS module on a breadboard surrounded by all kind of high frequency wires the GPS may find it difficulty to lock (at least mine did).
To solve you put the GPS module as far away as possible from all the high frequency wires.
This locking problem should be very visible when connected to a PCB using the USB port.
Once the GPS module gets close to the digital wires the number of satellites goes down and you even may loose GPS lock
Thanks, I'll change my circuit to place it far away from the other components.
-
...
I tried to connect it using the USB without success, the computer doesnt detect it.
...
Thanks for the sketch, i tried but no success.
I'm using the puck antenna. I checked the RX/TX pins using the scope serial decoder, and it only shows data coming from the STM32F411 to the Ublox and no data from the Ublox to the SMT32F411.
...
Other examples like the Communications->Ascii are working normally with the serial console. I'll investigate it further.
Hmm, from everything you described, it seems that GPS module is "dead".
-
@rodpp
Looking at the pictures (and assuming you haven't tested with an external active GPS antenna), I think you may be experiencing the very same problem I came across with my first purchase of that M8N module (a genuine one as it turned out) just over 2 1/2 years ago.
https://www.eevblog.com/forum/projects/ublox-neo-m8n-gps-navigation-signal-amplify-module-for-arduino-rasppery-pi/msg2277186/#msg2277186 (https://www.eevblog.com/forum/projects/ublox-neo-m8n-gps-navigation-signal-amplify-module-for-arduino-rasppery-pi/msg2277186/#msg2277186)
The link takes you to the relevant post describing the cause and its solution. Assuming the PPS LED lights when powered up, you can try a simple test with a 14cm length of solid core wire inserted into the SMA socket to act as a 3/4λ antenna (gives better results than a 1/4λ in this scenario). You can power it via its usb port from a powerbank.
Using a powerbank allows you to roam anywhere this makeshift setup can get an unobstructed view of the sky - you only need to be able to see the LED start blinking at a steady 1PPS at this stage to confirm whether it will be worth performing a "Patchectomy" as I described in that post. :)
[EDIT] I almost forgot to mention that it can take up to 20 minutes for these M8 (and M6 and M7) modules to reacquire the ephemeris data if they've gone more than four hours without an update (or the BBRAM supercap has discharged - typically 45 minutes reserve from loss of power if it's a fake without flash).
Once it has valid ephemeris data, it can regain lock on subsequent power up cycles in anywhere from 3 to 36 seconds. The genuine (and the better fakes) can retain lock for an embarrassingly long time when you unplug the antenna or shield an attached patch antenna whilst in an outdoor location when you want to force a loss of lock in order to test how quickly they can regain lock after such LOS events. ::)
PS the attached image shows what I'd discovered when I removed the patch antenna on my M8N module. :wtf: no wonder it was struggling to receive any signals looking at all those circuit traces in what should have been just a solid groundplane. The LNA must have been overloaded into total submission (fortuitously muting the interference it would have otherwise injected into the RF input on the module itself, leaving the signal from the external antenna connection unmolested).
-
Hmm, from everything you described, it seems that GPS module is "dead".
Yes, unfortunately it seems dead.
@rodpp
Looking at the pictures (and assuming you haven't tested with an external active GPS antenna), I think you may be experiencing the very same problem I came across with my first purchase of that M8N module (a genuine one as it turned out) just over 2 1/2 years ago.
https://www.eevblog.com/forum/projects/ublox-neo-m8n-gps-navigation-signal-amplify-module-for-arduino-rasppery-pi/msg2277186/#msg2277186 (https://www.eevblog.com/forum/projects/ublox-neo-m8n-gps-navigation-signal-amplify-module-for-arduino-rasppery-pi/msg2277186/#msg2277186)
The link takes you to the relevant post describing the cause and its solution. Assuming the PPS LED lights when powered up, you can try a simple test with a 14cm length of solid core wire inserted into the SMA socket to act as a 3/4λ antenna (gives better results than a 1/4λ in this scenario). You can power it via its usb port from a powerbank.
Using a powerbank allows you to roam anywhere this makeshift setup can get an unobstructed view of the sky - you only need to be able to see the LED start blinking at a steady 1PPS at this stage to confirm whether it will be worth performing a "Patchectomy" as I described in that post. :)
[EDIT] I almost forgot to mention that it can take up to 20 minutes for these M8 (and M6 and M7) modules to reacquire the ephemeris data if they've gone more than four hours without an update (or the BBRAM supercap has discharged - typically 45 minutes reserve from loss of power if it's a fake without flash).
Once it has valid ephemeris data, it can regain lock on subsequent power up cycles in anywhere from 3 to 36 seconds. The genuine (and the better fakes) can retain lock for an embarrassingly long time when you unplug the antenna or shield an attached patch antenna whilst in an outdoor location when you want to force a loss of lock in order to test how quickly they can regain lock after such LOS events. ::)
PS the attached image shows what I'd discovered when I removed the patch antenna on my M8N module. :wtf: no wonder it was struggling to receive any signals looking at all those circuit traces in what should have been just a solid groundplane. The LNA must have been overloaded into total submission (fortuitously muting the interference it would have otherwise injected into the RF input on the module itself, leaving the signal from the external antenna connection unmolested).
Thanks for the detailed answer!
I tested it with a external puck antenna placed outdoor, with no success. I tried connecting it using the computer USB port, and no success too.
Even after hours with an external antenna, the pps LED never turned on or blinked, always off... and no communications too. Checked with the scope, the serial communication from the STM32F411 to the M8L arrives ok, but the module never answer anything.
I opened an AliExpress dispute.
Here is the serial output using the AndrewBCN code from github, even after hours powered on and using an external antenna:
21:46:59.345 -> UBX command sent, waiting for UBX ACK...
21:46:59.345 -> * Reading ACK response: (FAILED!)
21:47:02.347 -> Oops, something went wrong here...
21:47:02.347 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
21:47:02.347 -> UBX command sent, waiting for UBX ACK...
21:47:02.347 -> * Reading ACK response: (FAILED!)
21:47:05.347 -> Oops, something went wrong here...
21:47:05.347 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
21:47:05.347 -> UBX command sent, waiting for UBX ACK...
21:47:05.347 -> * Reading ACK response: (FAILED!)
21:47:08.347 -> Oops, something went wrong here...
21:47:08.347 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
21:47:08.347 -> UBX command sent, waiting for UBX ACK...
21:47:08.347 -> * Reading ACK response: (FAILED!)
21:47:11.348 -> Oops, something went wrong here...
21:47:11.348 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
21:47:11.348 -> UBX command sent, waiting for UBX ACK...
21:47:11.348 -> * Reading ACK response: (FAILED!)
21:47:14.319 -> Oops, something went wrong here...
21:47:14.319 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
21:47:14.319 -> UBX command sent, waiting for UBX ACK...
21:47:14.319 -> * Reading ACK response:
-
Another minor note for what it's worth.
Some devices have a 0.5 Hz "PPS" which is just stupid. You can't get exact triggering the same on a rising edge as a falling edge. It's better to just pick one if you're stuck with 0.5 Hz.
In any case, I just discovered that the 0.5 Hz out of a GlobalSat BU-353S4 is not even locked to even/odd seconds. It's just random at startup and XORed once a second.
-
A small warning.
When you have the GPS module on a breadboard surrounded by all kind of high frequency wires the GPS may find it difficulty to lock (at least mine did).
To solve you put the GPS module as far away as possible from all the high frequency wires.
This locking problem should be very visible when connected to a PCB using the USB port.
Once the GPS module gets close to the digital wires the number of satellites goes down and you even may loose GPS lock
Yes.. thank you!
If you read the UBLOX implementation manual they say this also. Their modules should not be placed on the backside of the antenna. (As shown)
As erikka says this is a guaranteed problem because the module is a source of noise. Better to use a large external andtenna with built in LNA and placed in a place it can see the sky. The digital traces should not be where they are with this module. Bet you it is misrepresented as an M8N and actually is not a real M8N. Send it back. If its mislabeled a something it isn't (like an official M8N, ebay will cancel out your sale and the debit. If the module does not have working flash memory and cannot be updated, it is not an M8N. Very few if any of them bought in this context are genuine.
-
The new GPS module I bought locally arrived today, with a M8N chip and not a M8L as before. I replaced the suspect GPS module and the circuit worked (please, see the attached image). Thank you all!
My universal counter is measuring around 1.5Hz above 10MHz, I'll monitor it over the days.
I put the puck antenna over the rooftop, using a 6m SMA extension cable. It is only getting around 5 or 6 satellites. Should I upgrade the antenna, or is that ok?
-
I put the puck antenna over the rooftop, using a 6m SMA extension cable. It is only getting around 5 or 6 satellites. Should I upgrade the antenna, or is that ok?
When you say "getting around 5 or 6 satellites" is that satellites in view or satellites used to get a fix. I suggest you pull the M8N module off the breadboard and plug a usb cable from a computer into the usb socket on the M8N module. You can then use a program to see exactly what satellites are in view and their signal strength, and what satellites are used for a fix. I am not 100% sure what the signal strength value means, but I suspect SNR in dB. If you are getting four or more satellites at 30 (dB?) or greater then all should be well and you don't need to do anything with your antenna. The critical value for good readings is HDOP or PDOP (dilution of precision). Ideally this is always below 2. VDOP can be higher.
A well positioned antenna will "see" many more satellites than needed. There are recommendations elsewhere for timing GPS modules how to get the best results by selecting constellations and only accepting signals from satellites above a certain angle.
-
Ideally this is always below 2. VDOP can be higher.
Just saying (reading this morning):
DoP H/V 0.48 / 0.91My cheaper GPS is saying 0.7 / 1.4
-
There are two problems somewhere in your setup, because after three hours uptime, the OCXO frequency should have stabilized at 10MHz +/- 0.01Hz, and you should be getting at least a dozen satellites in view or so with a rooftop antenna.
1. Are you using the PWM 16-bit DAC or the redundant 12-bit DAC module? Try using the 16-bit PWM DAC (requires 2 resistors and 2 capacitors).
2. Try to reposition your puck antenna. Even indoors I get > 10 satellites in view with the M8N module.
3. Please copy/paste a 1s sample of what the GPSDO is reporting through the USB serial or the Bluetooth.
4. Please copy paste the configuration section of the firmware you have compiled (the #define's).
-
Hi @AndrewBCN , i have created a PCB layout with a socket for the DAC module and overlooked that in your schematic you supply that module with 3.3V instead of 5V (i blame it on the fact that i didn't have my glasses on and an almost empty toner cartridge). The module works with both voltages but when supplied with 5V its output range is 0...5V. Does the larger voltage range require changes to your software?
I'm afraid it's too late to change the layout as it is already being manufactured in China. In the worst case i can add a 3.3V regulator to the module.
-
Hi @AndrewBCN , i have created a PCB layout with a socket for the DAC module and overlooked that in your schematic you supply that module with 3.3V instead of 5V (i blame it on the fact that i didn't have my glasses on and an almost empty toner cartridge). The module works with both voltages but when supplied with 5V its output range is 0...5V. Does the larger voltage range require changes to your software?
I'm afraid it's too late to change the layout as it is already being manufactured in China. In the worst case i can add a 3.3V regulator to the module.
The problem is that the I2C DAC module interfaces with the STM32 module which works with 3.3V logic levels. I am not sure what could happen if you power the DAC with 5.0V when all the other modules are powered with 3.3V.
Note that you don't need to add a 3.3V regulator, the Black Pill can supply more than enough current from its 3.3V power output pin, it has an onboard LDO 3.3V regulator.
-
I think the I2C I/Os on most STM32 are 5V tolerant. It should not be a problem to pull them up to 5V. You'll have to check the datasheet of your particular STM32 but it is very likely.
Or, you could use a DAC that has separate I/O rails for digital I/O and for the analog part.
-
I just had a closer look at the MCP4725 module (Adafruit version) and they come with their own pullup resistors and it is the the only module on SDA1/SCL1. The only other optional module i use is the INA219 which hangs off SDA3/SCL3. So while the MCU port pins are 5V tolerant the rail-to-rail design of the DAC would mean up to 5V on the MCU's PB0 pin. I have a bag full of 3.3V LDO regulators lying around (MCP1702). I think i'll add one of those to the module, it's much simpler than to reroute 3.3V to the socket pin on the GPSDO board, really should have gone with the PWM option in the first place....
The only missing piece is one of those chains to hang my glasses around my neck so i can't misplace them anymore.
-
It is because of these small problems that come up during the build that I advise people to assemble the STM32 GPSDO on a breadboard first.
For example, it is easy to compare the OCXO frequency regulation from the 12-bit I2C DAC vs the 16-bit PWM DAC on a breadboard prototype. Both work to achieve 10E-9 (0.01Hz) regulation, but the 16-bit PWM DAC goes a little bit further and one can achieve 10E-10 (0.001Hz) regulation (as far as I can tell), even on a noisy breadboard prototype.
And personally I am still experimenting with the optional picDIV, sinewave output filter, 1ns (theoretical) resolution TIC, so I have not committed to a PCB layout yet.
-
I put the puck antenna over the rooftop, using a 6m SMA extension cable. It is only getting around 5 or 6 satellites. Should I upgrade the antenna, or is that ok?
When you say "getting around 5 or 6 satellites" is that satellites in view or satellites used to get a fix. I suggest you pull the M8N module off the breadboard and plug a usb cable from a computer into the usb socket on the M8N module. You can then use a program to see exactly what satellites are in view and their signal strength, and what satellites are used for a fix. I am not 100% sure what the signal strength value means, but I suspect SNR in dB. If you are getting four or more satellites at 30 (dB?) or greater then all should be well and you don't need to do anything with your antenna. The critical value for good readings is HDOP or PDOP (dilution of precision). Ideally this is always below 2. VDOP can be higher.
A well positioned antenna will "see" many more satellites than needed. There are recommendations elsewhere for timing GPS modules how to get the best results by selecting constellations and only accepting signals from satellites above a certain angle.
5 or 6 satellites is the number shown in the OLED display. Sometimes it goes up to 9 or 10 and decreases again.
I connected the module using the USB as suggested and I used the VisualGPS software. It never had 4 satellites above 30. The best I can get is 2 satellites above 30, sometimes less in the same antenna position. The total of satellites in view inside the VisualGPS software is around 10. The VisualGPS never get a fix or show any coordinates, so no HDOP, PDOP or VDOP values.
It was a goot test to show that the 6m SMA cable degrates the antenna signal significantly, it is much better to leave the antenna in an obstructed view than over the rooftop using the extension cable.
Probably, I'll need to buy a better antenna and a better extension cable, maybe coaxial intead of this thin SMA extension cable. To put the antenna over the rooftop, passing the cable inside the walls, I'll need around 10m of cable.
There are two problems somewhere in your setup, because after three hours uptime, the OCXO frequency should have stabilized at 10MHz +/- 0.01Hz, and you should be getting at least a dozen satellites in view or so with a rooftop antenna.
1. Are you using the PWM 16-bit DAC or the redundant 12-bit DAC module? Try using the 16-bit PWM DAC (requires 2 resistors and 2 capacitors).
2. Try to reposition your puck antenna. Even indoors I get > 10 satellites in view with the M8N module.
3. Please copy/paste a 1s sample of what the GPSDO is reporting through the USB serial or the Bluetooth.
4. Please copy paste the configuration section of the firmware you have compiled (the #define's).
Regarding your questions:
1- I was using the 12-bit DAC. Now I'm using the PWM and the circuit now is working good. Maybe the problem was not the DAC, but the Universal Counter that I'm using to measure the output frequency. It's impendance is 1Mohm, but if I connect it after the resistor R5 the 10MHz signal deteriorates. Now I'm connecting it between the oscillator and the R5, and it is ok.
2- As discussed above, I tested the antenna connecting it to the USB using the VisualGPS software. The extension cable is really bad, so no success placing the antenna in a better position, like over the rooftop. Sometimes I get 9-10 satellites on the OLED screen too, but most of the time it is around 6.
3- Please, see the output (only coordinates edited):
$GNGSA,A,3,02,05,18,24,25,29,20,12,,,,,2.30,1.19,1.97*1E
$GNGLL,XXXX.XXXXX,S,XXXXX.XXXXX,W,154555.00,A,A*72
$GNRMC,154556.00,A,XXXX.XXXXX,S,XXXXX.XXXXX,W,0.040,,181121,,,A*69
$GNGGA,154556.00,XXXX.XXXXX,S,XXXXX.XXXXX,W,1,11,0.92,744.5,M,-7.7,M,,*5F
Fix time 879mS
Uptime: 000d 17:53:41
New GPS Fix:
Lat: -XX.XXXXXX Lon: -XX.XXXXXX Alt: 744.5m
Sats: 11 HDOP: 0.92
UTC Time: 15:45:56 Date: 18/11/2021
Voltages:
Vctl: 1.88 DAC: 2336
VctlPWM: 1.66 PWM: 30046
Vcc: 4.83
Vdd: 3.28
Frequency measurements using 64-bit counter:
64-bit Counter: 644065948477
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 9999999.999 Hz
10,000s Frequency Avg: 0.0000 Hz
BMP280 Temperature = 27.6 *C
Pressure = 947.2 hPa
Approx altitude = 729.9 m
AHT10 Temperature: 26.95 *C
Humidity: 70.20% rH
4- When I was using the 12-bit DAC, the configuration were:
// Define hardware options
// -----------------------
#define GPSDO_OLED // SSD1306 128x64 I2C OLED display
#define GPSDO_MCP4725 // MCP4725 I2C 12-bit DAC
// #define GPSDO_PWM_DAC // STM32 16-bit PWM DAC, requires two rc filters (2xr=20k, 2xc=10uF)
#define GPSDO_AHT10 // I2C temperature and humidity sensor
#define GPSDO_GEN_2kHz // generate 2kHz square wave test signal on pin PB9 using Timer 4
#define GPSDO_BMP280_SPI // SPI atmospheric pressure, temperature and altitude sensor
// #define GPSDO_INA219 // INA219 I2C current and voltage sensor
// #define GPSDO_BLUETOOTH // Bluetooth serial (HC-06 module)
#define GPSDO_VCC // Vcc (nominal 5V) ; reading Vcc requires 1:2 voltage divider to PA0
#define GPSDO_VDD // Vdd (nominal 3.3V) reads VREF internal ADC channel
#define GPSDO_CALIBRATION // auto-calibration is enabled
#define GPSDO_UBX_CONFIG // optimize u-blox GPS receiver configuration
#define GPSDO_VERBOSE_NMEA // GPS module NMEA stream echoed to USB serial xor Bluetooth serial
Now, using the PWM, it is:
// Define hardware options
// -----------------------
#define GPSDO_OLED // SSD1306 128x64 I2C OLED display
#define GPSDO_MCP4725 // MCP4725 I2C 12-bit DAC
#define GPSDO_PWM_DAC // STM32 16-bit PWM DAC, requires two rc filters (2xr=20k, 2xc=10uF)
#define GPSDO_AHT10 // I2C temperature and humidity sensor
#define GPSDO_GEN_2kHz // generate 2kHz square wave test signal on pin PB9 using Timer 4
#define GPSDO_BMP280_SPI // SPI atmospheric pressure, temperature and altitude sensor
// #define GPSDO_INA219 // INA219 I2C current and voltage sensor
// #define GPSDO_BLUETOOTH // Bluetooth serial (HC-06 module)
#define GPSDO_VCC // Vcc (nominal 5V) ; reading Vcc requires 1:2 voltage divider to PA0
#define GPSDO_VDD // Vdd (nominal 3.3V) reads VREF internal ADC channel
#define GPSDO_CALIBRATION // auto-calibration is enabled
#define GPSDO_UBX_CONFIG // optimize u-blox GPS receiver configuration
#define GPSDO_VERBOSE_NMEA // GPS module NMEA stream echoed to USB serial xor Bluetooth serial
If I comment the 12-bit DAC line, the compilation returns a error because a non declared variable is used.
I attached two multimeter screens that shows the control voltage of the oscillator over time.
The 10MHz output measure by the universal counter is 9.999,999,966,5MHz, the last two digits varying aproximately between 50 to 78.
So, the frequency variantion is < 1ppb and my universal counter is off by 3.35ppb.
-
Hi Rodrigo,
That looks very good to me with the PWM DAC working as it should. :-+
I will be uploading version 0.04j of the STM32 GPSDO firmware soon, it should fix a few small bugs and add a few new features. Version 0.05 is still a couple of months away.
You can also try the Bluetooth connection, check the GitHub repository there is a small program to configure the HC-06 Bluetooth module. Then you can control the GPSDO from your smartphone! ;D
About the SMA extension cable, to be honest I was suspicious that it was the cause of your poor satellite reception.
You can consult with MIS42N, he has a very good and inexpensive setup for his GPS rooftop antenna.
-
Thank you Andrew,
I'll try the bluetooth later, will be nice to control it using my smartphone!
Regarding the antenna, one option is to place the GPS module on the roof, near the antenna, and use a CAT5e cable to connect it to the STM32. But I would like to put everything inside a box in the future, so better if the GPS module stay near the STM32. I'll research more about placing the antenna far away from the GPS module.
-
How about using a 10 turn trimmer to set the voltage and scale down your DAC by a factor of 16 or so. You gain four bits at the sacrifice of having to retrim your center every few years or so. Your software could give proper notice when the DAC is running out of range.
-
How about using a 10 turn trimmer to set the voltage and scale down your DAC by a factor of 16 or so. You gain four bits at the sacrifice of having to retrim your center every few years or so. Your software could give proper notice when the DAC is running out of range.
Actually 16 bits is more than enough resolution to reach 0.001Hz OCXO stability and beyond that we are at the jitter/noise limit of various parameters, so there is little to nothing to be gained.
Quoting Lars: "For those skeptical that a 16 bit DAC is enough I recommend to use the GPSDO simulator found on leapsecond.com to simulate different resolutions."
Link to the GPSDO simulator:
http://www.leapsecond.com/pages/gpsdo-sim/ (http://www.leapsecond.com/pages/gpsdo-sim/)
-
How about using a 10 turn trimmer to set the voltage and scale down your DAC by a factor of 16 or so. You gain four bits at the sacrifice of having to retrim your center every few years or so. Your software could give proper notice when the DAC is running out of range.
You can do the maths. An OSC5A2B02 has a pulling value of about 0.1V/Hz (look at the specification sheet). If the DAC is 0-5V then 1Hz change requires around 1300 steps. So 1 step changes the frequency by 0.00076Hz. As Andrew says, that is less than 1 part in 10E-10 and probably less than the ability of the rest of the system.
If you are logging the DAC value and it spends most of the time fluctuating by 1, then increased resolution may be useful. Or go to a better oscillator like the Morion MV89 with a pulling value of 1V/Hz.
There is another scenario where a trimmer is worthwhile. If it is across a precision voltage source, and the other inputs are not, then it damps the fluctuations due to voltage changes. So could be beneficial, but not to improve resolution.
-
Attached the KiCad schematic for the STM32 GPSDO revision 0.6.2.
What's new/changed:
1. Changed the output buffer sections for the 1PPS and 10MHz TTL outputs.
2. Added an optional 10MHz sinewave output.
3. Added an optional Frequency Counter input.
4. Added a note about the STM32F411CEU6 Black Pill 3.3V power output and 5V power input pins.
About the frequency counter input: this is for a feature that I intend to add in firmware v0.05 and later. Basically, the STM32 GPSDO can be repurposed into a high precision counter - frequency meter - period meter - clock.
-
Actually 16 bits is more than enough resolution...
Well, yeah, of course. That wasn't my point.
I meant, maybe an 8 bit DAC at the same effective LSB scale would have enough range for all contingencies.
Using your 16 bit example, what is the code range over a day, a month, a year?
-
Actually 16 bits is more than enough resolution...
Well, yeah, of course. That wasn't my point.
I meant, maybe an 8 bit DAC at the same effective LSB scale would have enough range for all contingencies.
Using your 16 bit example, what is the code range over a day, a month, a year?
Certainly what you say would work. My GPSDO (described elsewhere) converts DAC readings to control voltage for reporting. For the last 5 days it has read 1.93xx Volts, so an 8 bit DAC could provide the xx. But why do it? Let the electronics look after the adjustment. Is a 10 turn pot cheaper than the difference between an 8-bit and 16-bit DAC? Or do you have something else in mind?
-
Using resistors for scaling is a typical trick with DIY GPSDOs because a cheap DACs and voltage references often have more errors than a good voltage divider. See back with the Brooks Shera GPDSO.
If only medium accuracy is needed it's less of a problem, but for high accuracy, getting a DAC to accurately cover the full EFC range of the OCXO over reasonable temperature range is not trivial.
-
Trying to fix the far away antenna problem, I'm looking to an All-in-one antenna/receiver Trimble Acutime Gold:
https://xdevs.com/doc/Trimble/Data%20Sheets/Acutime%20Gold.pdf (https://xdevs.com/doc/Trimble/Data%20Sheets/Acutime%20Gold.pdf)
Any opinions about its specifications?
I could install it on the rooftop and use the serial communication over a long cable to the GPSDO circuit.
-
I'm looking to an All-in-one antenna/receiver Trimble Acutime Gold:
I think that device is getting kind of long in the tooth, the datasheet is 2006.
Apparently? it's working on a 12 MHz clock (80 ns is quoted as resolution).
It doesn't seem to pick up any of the other stuff, Glonass, Galileo, BeiDou.
There are no sensitivity specs.
The thing going for it is a nice environmental package and RS-422 drivers.
I'd rather put a newer ublox with an RS-422 driver added in a sandwich case.
-
I could install it on the rooftop and use the serial communication over a long cable to the GPSDO circuit.
I made my own using UA9638/UA9639 driver/receiver. Works well over maybe 12 meters of Ethernet cable (the maybe is because I ran the cable without measuring it, just rolled it out and decided it was long enough). I have tested with a 20 meter cable. The only fiddly bit is wiring up the Ethernet sockets. After I tested I got PCBs made which made it very easy. There is a sender board and a receiver board, identical boards. The receiver has 100 ohm terminating resistors and supplies 12V. The data is the PPS and 9600 Baud NMEA data. I used a 5V regulator at the sender end to drop 12V to 5V. I am about to test using a buck converter instead, to lower the voltage drop in the earth return.
I looked at the data yesterday using VisualGPS, 12 satellites above 30, some in the 40s. This is with a neo 7 and active antenna. The antenna on the roof, the neo and driver board underneath out of the weather (but not in a box, just cable tied to timber). I have plans for a box but this setup working fine for over 6 months.
-
Just saying.
-
@AndrewBCN Hi. Great project. I have already ordered parts to test it. Meanwhile I have made small cleaning of Your GitHub project. That would be essencial if You can track it there ;) That really helps a lot! :)
https://github.com/AndrewBCN/STM32-GPSDO/pull/4
Is it possible that after merging You will update it with KiCAD files so I can have a look on that as well? ;)
Same with Your Lars' GitHub project: https://github.com/AndrewBCN/Lars-DIY-GPSDO/pull/1 (don't forget to Squash my commits before Merge, I haven't done that here ;/ )
Cheers, Paweł 'felixd' Wojciechowski
-
Hi AndrewBNC and all post participants.
Thanks for the work done that can be useful to many :)
I'm trying on breadboard the software created by AndrewBNC using only the Blackpill, a SI5351 module (Type Erikka) to create the 10MHz signal as I still don't have a VCXO,
and Neo 6M for PPS count.
// on the include section
#include <si5351.h>
Si5351 si5351;
//on setup()
// Initialize I2C
Wire.begin(1); // SDA(PB7) SCL(PB6)
// try setting a higher I2C clock speed
Wire.setClock(400000L);
si5351.init(SI5351_CRYSTAL_LOAD_8PF, 0, 0); si5351.drive_strength(SI5351_CLK0, SI5351_DRIVE_2MA);
// Set CLK0 to output 10mhz
si5351.set_correction(125630, SI5351_PLL_INPUT_XO);
si5351.set_ms_source(SI5351_CLK0, SI5351_PLLA);
si5351.set_freq(1000000000ULL, SI5351_CLK0); // 0.01hz
si5351.output_enable(SI5351_CLK0, 1);
si5351.update_status();
Obviously I had to retouch the code a little but it works all correctly.
I'm using everything in read-only mode, without now integrating any PLL or FLL control.
The sketch is well commented so that an almost neophyte like me can understand the operating logic.
precisely for this reason I did a bit of debugging because sometimes the frequency value squirts out of the standards and trying to understand why I noticed that all buffers do not have value as an initialization:
volatile uint64_t circbuf_ten64[11]; // 10 + 1 seconds circular buffer
volatile uint64_t circbuf_hun64[101]; // 100 + 1 seconds circular buffer
volatile uint64_t circbuf_tho64[1001]; // 1,000 + 1 seconds circular buffer
volatile uint64_t circbuf_tth64[10001]; // 10,000 + 1 seconds circular buffer
But for example with the code entered in the LogFcount64 () function and only in the part relating to the 11 entry buffer:
// 10 seconds buffer
circbuf_ten64 [cbiten_newest] = fcount64;
cbiten_newest ++;
int _s_circbuf_ten64 = sizeof (circbuf_ten64); // NEWLINE FOR DEBUG
Serial.Print (F ("1 Size circbuf_ten64:")); // NEWLINE FOR DEBUG
Serial.println (_s_circbuf_ten64); // NEWLINE FOR DEBUG
If (cbiten_newest> 10)
{
cbten_Full = True; // This Only Needs to Happen Once, When The Buffer Fills Up For The First Time
cbiten_newest = 0; // (Wrap Around)
ect ...
The size of the array reports me a value of 88.
I would have expected 12 if I'm not wrong.
Where does it out of 88?
Thanks for the answer because there's something that escapes me and many others that I have to understand.
See you soon, Angelo.
-
sizeof(uint64_t) == 8
-
Thanks thinfat,
So I'm afraid to enumerate the number of objects inside the array?
How can I enumerate the number objects inside array at runtime?
I imagine something like:
Serial.print (F ("circbuf_ten64 [0]:")); Serial.println (circbuf_ten64[0]);
Serial.print (F ("circbuf_ten64 [1]:")); Serial.println (circbuf_ten64[1]);
Serial.print (F ("circbuf_ten64 [2]:")); Serial.println (circbuf_ten64[3]);
And so on...
This is the first problem :)
TNX :)
-
@AndrewBCN Hi. Great project. I have already ordered parts to test it. Meanwhile I have made small cleaning of Your GitHub project. That would be essencial if You can track it there ;) That really helps a lot! :)
https://github.com/AndrewBCN/STM32-GPSDO/pull/4
Is it possible that after merging You will update it with KiCAD files so I can have a look on that as well? ;)
Same with Your Lars' GitHub project: https://github.com/AndrewBCN/Lars-DIY-GPSDO/pull/1 (don't forget to Squash my commits before Merge, I haven't done that here ;/ )
Cheers, Paweł 'felixd' Wojciechowski
Hello Pawel, many, many thanks for the GitHub pull requests. Give me a few days to sort them out, as I have some health problems these days and feel very tired.
-
Hi AndrewBNC and all post participants.
Thanks for the work done that can be useful to many :)
I'm trying on breadboard the software created by AndrewBNC using only the Blackpill, a SI5351 module (Type Erikka) to create the 10MHz signal as I still don't have a VCXO,
and Neo 6M for PPS count.
Very interesting.
...
But for example with the code entered in the LogFcount64 () function and only in the part relating to the 11 entry buffer:
// 10 seconds buffer
circbuf_ten64 [cbiten_newest] = fcount64;
cbiten_newest ++;
int _s_circbuf_ten64 = sizeof (circbuf_ten64); // NEWLINE FOR DEBUG
Serial.Print (F ("1 Size circbuf_ten64:")); // NEWLINE FOR DEBUG
Serial.println (_s_circbuf_ten64); // NEWLINE FOR DEBUG
If (cbiten_newest> 10)
{
cbten_Full = True; // This Only Needs to Happen Once, When The Buffer Fills Up For The First Time
cbiten_newest = 0; // (Wrap Around)
ect ...
The size of the array reports me a value of 88.
I would have expected 12 if I'm not wrong.
Where does it out of 88?
Thanks for the answer because there's something that escapes me and many others that I have to understand.
See you soon, Angelo.
The arrays are 11 entries long, and each entry is 8 bytes, hence 88 size.
-
Hi AndrewBNC,
Thanks for the reply.
I'm doing this kind of debugging to understand why I have strange frequency changes,
as in the example reported below average at 1000s, but it also happens in that at 100s and 10s.
Measurements Using 64-bit Counter:
64-Bit Counter: 62849419998
Frequency: 10000006 Hz
10s AVG: 10000006.3 Hz
100s AVG: 10000006.64 Hz
1,000s AVG: 10140006.795 Hz
10,000s AVG: 0.0000 Hz
avgupsec: 6286
avgupsec is uptime in seconds from micro start.
I don't understand from where the value 10140006.795 comes out,
in practice 100khz of difference from other readings,
I would just expect a few mHz as in fact it happens all the time except for a few moments where that kind of busted value is reported.
Believe that it is the SI5351 module that shoots busted values is a hypothesis, but I would like to understand soft side if I can do some check.
If you have advice for a more accurate debug I would be grateful as they may be able to serve everyone even for other reasons.
thanks, A.
-
I'm back after understand how enumerate entry in the array
Thanks to the count between weight array and weight element as recommended by thinkfat and AndrewBNC.
Snippet of code, same place as before:
// 10 seconds buffer
circbuf_ten64[cbiten_newest]=fcount64;
Serial.print(F("cbiten_newest: ")); Serial.println(cbiten_newest);
cbiten_newest++;
_s_circbuf_ten64 = sizeof(circbuf_ten64) / sizeof(uint64_t);
Serial.print(F("1 item circbuf_ten64: "));
Serial.println(_s_circbuf_ten64);
for(int i=0; i <= _s_circbuf_ten64; i++)
{
Serial.print(i); Serial.print(F(" circbuf_ten64[i]: "));
Serial.println(circbuf_ten64[i]);
}
if (cbiten_newest > 10)
{
cbTen_full=true; // this only needs to happen once, when the buffer fills up for the first time
cbiten_newest = 0; // (wrap around)
etc....
# Begin paste #
measurements using 64-bit counter:
64-bit Counter: 960949385
Frequency: 10000005 Hz
10s Avg: 10000004.6 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 98
1 item circbuf_ten64: 11
0 circbuf_ten64: 900949357
1 circbuf_ten64: 910949362
2 circbuf_ten64: 920949367
3 circbuf_ten64: 930949371
4 circbuf_ten64: 940949376
5 circbuf_ten64: 970949390
6 circbuf_ten64: 850949334
7 circbuf_ten64: 860949339
8 circbuf_ten64: 870949344
9 circbuf_ten64: 880949348
10 circbuf_ten64: 890949353
11 circbuf_ten64: 20948948
# one second later
measurements using 64-bit counter:
64-bit Counter: 970949390
Frequency: 10000005 Hz
10s Avg: 12000005.6 Hz <=== PROBLEM HERE jump from previous 10000004.6 Hz to 12000005.6 Hz!!!
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 99
1 item circbuf_ten64: 11
0 circbuf_ten64: 900949357
1 circbuf_ten64: 910949362
2 circbuf_ten64: 920949367
3 circbuf_ten64: 930949371
4 circbuf_ten64: 940949376
5 circbuf_ten64: 970949390
6 circbuf_ten64: 980949395
7 circbuf_ten64: 860949339
8 circbuf_ten64: 870949344
9 circbuf_ten64: 880949348
10 circbuf_ten64: 890949353
11 circbuf_ten64: 20948948
# another second later
measurements using 64-bit counter:
64-bit Counter: 980949395
Frequency: 10000005 Hz
10s Avg: 12000005.6 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 100
1 item circbuf_ten64: 11
0 circbuf_ten64: 900949357
1 circbuf_ten64: 910949362
2 circbuf_ten64: 920949367
3 circbuf_ten64: 930949371
4 circbuf_ten64: 940949376
5 circbuf_ten64: 970949390
6 circbuf_ten64: 980949395
7 circbuf_ten64: 990949399
8 circbuf_ten64: 870949344
9 circbuf_ten64: 880949348
10 circbuf_ten64: 890949353
11 circbuf_ten64: 20948948
# end paste #
The problem does not seem to be related to a specific point over time,
Really very strange but an explanation must be there.
A.
-
...
# one second later
measurements using 64-bit counter:
64-bit Counter: 970949390
Frequency: 10000005 Hz
10s Avg: 12000005.6 Hz <=== PROBLEM HERE jump from previous 10000004.6 Hz to 12000005.6 Hz!!!
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 99
...
Hi, Yes, I have that occasional jump too, so it's not a hardware problem, most definitely it's a bug in my code. Note that the jump "goes away" at the next 10s measurement.
I have no good explanation at the moment.
-
Eh, 20% accuracy is not bad for a GPSDO. >:D
Your print library stinks. You're not looking at reality. A 64 bit number that never exceeds 32 bits in value? And never exceeds 9 decimal digits? (Maybe their temp buf isn't big enough?) Something is rotten.
Print the numbers using your own hex routine. You'll see that something is screwed up.
-
Tnx AndrewBNC :)
Hi Renate,
pleased to meet you.
The purpose of my current use is to understand how the code works by simply going to sample PIN PA15,
I don't care about "precision".
At PIN PA15 not having an oscillator available I used the SI5351 module that once calibrated,
set and lit from a few days, remains quite stable in frequency and remains "near" to 10MHz.
that's all.
My doubts derive from the fact that sometimes both on serial and on I2C LCD
I noticed too wrong values in the middle of 10s 100s 1000s.
This fact is true because as the current frequency is:
calcfreq64 = fcount64 - prepfcount64; // The Difference is Exactly The OCXO in Hz
It always proves "precise" in relation to previous readings, nothing "jump".
It must be there, somewhere in the mathematical account of the averages, a bug.
From here my intent to understand if there is some busted value that enters the circular buffer,
or a not appropriate truncation exists somewhere in the code.
Following another occurrence that was shortly after starting:
measurements using 64-bit counter:
64-bit Counter: 442704762
Frequency: 10000004 Hz
10s Avg: 10000004.3 Hz <= CORRECT FREQUENCY
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 45
1 item circbuf_ten64: 11
0 circbuf_ten64: 362704727
1 circbuf_ten64: 372704732
2 circbuf_ten64: 382704736
3 circbuf_ten64: 392704740
4 circbuf_ten64: 402704745
5 circbuf_ten64: 412704749
6 circbuf_ten64: 422704753
7 circbuf_ten64: 432704757
8 circbuf_ten64: 452704766
9 circbuf_ten64: 342704719
10 circbuf_ten64: 352704723
11 circbuf_ten64: 22704580
# one second later
measurements using 64-bit counter:
64-bit Counter: 452704766
Frequency: 10000004 Hz
10s Avg: 11000004.7 Hz <= JUMP TO 11000004.7 Hz, add 100khz more or less
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 46 <= here on 46sec, before it was a 99/100sec, seems it's not related to time
1 item circbuf_ten64: 11
0 circbuf_ten64: 362704727
1 circbuf_ten64: 372704732
2 circbuf_ten64: 382704736
3 circbuf_ten64: 392704740
4 circbuf_ten64: 402704745
5 circbuf_ten64: 412704749
6 circbuf_ten64: 422704753
7 circbuf_ten64: 432704757
8 circbuf_ten64: 452704766
9 circbuf_ten64: 462704770
10 circbuf_ten64: 352704723
11 circbuf_ten64: 22704580
The time has changed in which anomaly has appeared.
probably the problem is in the value : 11 circbuf_ten64: 22704580 ?????
perhaps the value had to be more similar to a 342704725 ????
to follow under debug with some other active entry:
# another example with more debug with run time of 10266sec
measurements using 64-bit counter:
64-bit Counter: 102632754455
Frequency: 10000006 Hz
10s Avg: 10000006.1 Hz
100s Avg: 10200006.30 Hz
1,000s Avg: 10180006.442 Hz
10,000s Avg: 10189004.9564 Hz
avgupsec: 10266
lsfcount: 3858506654
previousfcount: 3848506647
fcount64: 102642754462
prevfcount64: 102632754455
1 item circbuf_ten64: 11
0 circbuf_ten64: 102582754424
1 circbuf_ten64: 102592754431
2 circbuf_ten64: 102602754437
3 circbuf_ten64: 102612754443
4 circbuf_ten64: 102622754449
5 circbuf_ten64: 102632754455
6 circbuf_ten64: 102642754462
7 circbuf_ten64: 102542754400
8 circbuf_ten64: 102552754406
9 circbuf_ten64: 102562754412
10 circbuf_ten64: 102572754418
11 circbuf_ten64: 102012754073
In this case the counters exceed 10 billion for which I believe that it is correctly printing the software.
If you don't think it is incorrect, how do you advise me to print for a more comprehensive proof?
what about " Your Own Hex Routine" ?
tnx A.
-
I have given up on the project. I have a box of parts and don't know how to proceed.
-
Hello bob91343,
what's your problem?
if I can help you I'm here :)
bye, A.
-
Take a read up on Bob's issues, he did post a few of them.
I am just waiting for a circuit board to appear but I do have the parts and maybe if I get board I might peg board it.
-
Hi all.
I have given up on the project. I have a box of parts and don't know how to proceed.
for Bob91343
First you need to install the IDE of Arduino is to configure it
As wisely Andrewbnc wrote to you.
have you managed at least until here?
A.
-
Here you go, use this. See if there are any big jumps in your printout. You can print as you have, but add this.
/* This is ugly coding, but we need something simple to see what's going on */
void print_hexit(uint8_t x)
{
x&=0xf;
if (x>=10) x+='a'-10;
else x+='0';
print_however_char(x); // I don't know how you print a char
}
void print_x64(uint64_t x)
{
print_hexit((uint8_t) (x>>60));
print_hexit((uint8_t) (x>>56));
print_hexit((uint8_t) (x>>52));
print_hexit((uint8_t) (x>>48));
print_hexit((uint8_t) (x>>44));
print_hexit((uint8_t) (x>>40));
print_hexit((uint8_t) (x>>36));
print_hexit((uint8_t) (x>>32));
print_hexit((uint8_t) (x>>28));
print_hexit((uint8_t) (x>>24));
print_hexit((uint8_t) (x>>20));
print_hexit((uint8_t) (x>>16));
print_hexit((uint8_t) (x>>12));
print_hexit((uint8_t) (x>>8));
print_hexit((uint8_t) (x>>4));
print_hexit((uint8_t) x);
}
-
Frankly, it has been so long since I looked at it, I don't remember how far I got. I need to look in the box, but I don't recall installing any firmware.
-
[NOTE]
That might be interesting.
http://triode.dip.jp/honkytonk/2021/06/electronicworks/an-introduction-of-my-original-gpsdo-a-frequency-standard-oscillator-with-stm32.html (http://triode.dip.jp/honkytonk/2021/06/electronicworks/an-introduction-of-my-original-gpsdo-a-frequency-standard-oscillator-with-stm32.html)
https://www.youtube.com/watch?v=U3Zv6acD2b0 (https://www.youtube.com/watch?v=U3Zv6acD2b0)
Microcontroller: STM32F411CEU6
GPS module: Icofochina ATGM332D 5N31
OCXO: Morion MV89A
EFC control DAC: PCM5102A <-- That's interesting. 32bit DAC
-
Goodmorning everyone,
The problem relating to frequency jumps seems related to the function:
if (gpsWaitFix(waitFixTime))
which is called into the main loop.
It seems that sometimes the system reveals a loss of fix and therefore passes in the else where in practice it loses about a second and then reset the buffers at the next round setting the variable:
flush_ring_buffers_flag = true;
which is then evaluated in the ISR_2Hz
By putting a:
return;
Immediately after else condition in the function the problem seems to resolve.
startGetFixmS = millis(); // have a fix, next thing that happens is checking for a fix, so restart timer
}
else // no GPS fix could be acquired for the last five seconds
{
return; // <======= ADD THIS LINE
yellow_led_state = 1; // turn on yellow LED
Probably it should be understood because it detects a nofix when it is not true.
AndrewBNC's work on buffers and related mathematics is perfect :)
Obviously every advice is welcome, AndrewBNC's project is very interesting.
@Renate
thanks for the code, I try it as soon as I can
by, A.
-
Oops, I see what confused me there. Your print is probably ok.
The first example ran out of steam right before one billion.
You are also printing out the buffer stats in a fixed order, not by age.
That means there is a break in the middle of your listing between the newest and the oldest.
That is: 4, 5, 6, 7, 8, 9, 10, 1, 2, 3
-
Hi Renate,
I made the change this morning as reported in the previous post.
Everything looks fine now.
Obviously the problem of the Satfix control logic must be solved, if that is the prob.
Here to follow the statistics in the second 6602 of runtime, I await the 10000s for the statistic and then restart with some modifications.
measurements using 64-bit counter:
64-bit Counter: 65996867149
Frequency: 10000008 Hz
10s Avg: 10000008.2 Hz
100s Avg: 10000008.17 Hz
1,000s Avg: 10000007.678 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 6602
circbuf_ten64[0]: 65986867141
circbuf_ten64[1]: 65996867149
circbuf_ten64[2]: 66006867157
circbuf_ten64[3]: 65906867075
circbuf_ten64[4]: 65916867084
circbuf_ten64[5]: 65926867092
circbuf_ten64[6]: 65936867100
circbuf_ten64[7]: 65946867108
circbuf_ten64[8]: 65956867116
circbuf_ten64[9]: 65966867125
circbuf_ten64[10]: 65976867133
circbuf_ten64[11]: 60156862557
The 11 entry circular buffer as above is populated starting from 0 and reaching [10].
The entry [11] I have not yet understood where it is overwritten,
I will debug at the next restart on value change to show me when and where it happened.
So it's right that you see "shifting" values as you wrote:
4, 5, 6, 7, 8, 9, 10, 1, 2, 3
The next round will be:
3, 4, 5, 6, 7, 8, 9, 10, 1, 2 and 2, 3, 4, 5, 6, 7, 8, 9, 10, 1 and so on ...
bye, A.
-
Your code is broken. There are 11 elements in your buffer, indexed 0 to 10. At least your debug code accesses elements 0 to 11. That is certainly not correct. Check if you have other places in the program with the same bug.
-
Goodmorning everyone,
The problem relating to frequency jumps seems related to the function:
if (gpsWaitFix(waitFixTime))
which is called into the main loop.
It seems that sometimes the system reveals a loss of fix and therefore passes in the else where in practice it loses about a second and then reset the buffers at the next round setting the variable:
flush_ring_buffers_flag = true;
which is then evaluated in the ISR_2Hz
By putting a:
return;
Immediately after else condition in the function the problem seems to resolve.
startGetFixmS = millis(); // have a fix, next thing that happens is checking for a fix, so restart timer
}
else // no GPS fix could be acquired for the last five seconds
{
return; // <======= ADD THIS LINE
yellow_led_state = 1; // turn on yellow LED
Probably it should be understood because it detects a nofix when it is not true.
AndrewBNC's work on buffers and related mathematics is perfect :)
Obviously every advice is welcome, AndrewBNC's project is very interesting.
@Renate
thanks for the code, I try it as soon as I can
by, A.
Excellent work finding this bug! I am going to try your solution ASAP. But it makes sense, when I have very good satellite reception I don't get the "jumps" so much.
Thank you!
-
Perhaps someone wants to volunteer to finish my unit. I would pay for postage at least if someone can get this thing working.
-
Hi Thinkfat,
The problem is simply that cycle on the total length of the array,
But it's not a problem because the arrays are correctly filled.
volatile uint64_t _s_circbuf_ten64 = 0;
_s_circbuf_ten64 = sizeof(circbuf_ten64) / sizeof(uint64_t); _s => size circbuf_ten64 => 11!!!!
for(int i=0; i <= _s_circbuf_ten64; i++) // => probably (_s_circbuf_ten64-1) make sense
{
print lines like circbuf_ten64[i]:
}
...
Following an example on 10s buffer:
#
circbuf_ten64[0]: 28485109 <= NEW ENTRY same value as 64-bit Counter <= FIRST VALUE in array0 correct
circbuf_ten64[1]:
circbuf_ten64[2]:
circbuf_ten64[3]:
circbuf_ten64[4]:
circbuf_ten64[5]:
circbuf_ten64[6]:
circbuf_ten64[7]:
circbuf_ten64[8]:
circbuf_ten64[9]:
circbuf_ten64[10]:
circbuf_ten64[11]:
Fix time 958mS
measurements using 64-bit counter:
64-bit Counter: 28485109
Frequency: 10000003 Hz
10s Avg: 0.0 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 4
#
#
circbuf_ten64[0]: 28485109
circbuf_ten64[1]: 38485113 <= NEW ENTRY same value as 64-bit Counter
circbuf_ten64[2]:
circbuf_ten64[3]:
circbuf_ten64[4]:
circbuf_ten64[5]:
circbuf_ten64[6]:
circbuf_ten64[7]:
circbuf_ten64[8]:
circbuf_ten64[9]:
circbuf_ten64[10]:
circbuf_ten64[11]: 28485109 <= first value now shifting in last position and remaing here...
Fix time 966mS
measurements using 64-bit counter:
64-bit Counter: 38485113
Frequency: 10000004 Hz
10s Avg: 0.0 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 5
#
#
circbuf_ten64[0]: 28485109
circbuf_ten64[1]: 38485113
circbuf_ten64[2]: 48485116 <= NEW ENTRY same value as 64-bit Counter
circbuf_ten64[3]:
circbuf_ten64[4]:
circbuf_ten64[5]:
circbuf_ten64[6]:
circbuf_ten64[7]:
circbuf_ten64[8]:
circbuf_ten64[9]:
circbuf_ten64[10]:
circbuf_ten64[11]: 28485109
Fix time 963mS
measurements using 64-bit counter:
64-bit Counter: 48485116
Frequency: 10000003 Hz
10s Avg: 0.0 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 6
#
and so on ... in the end show this:
#
circbuf_ten64[0]: 28485109
circbuf_ten64[1]: 38485113
circbuf_ten64[2]: 48485116
circbuf_ten64[3]: 58485119
circbuf_ten64[4]: 68485122
circbuf_ten64[5]: 78485126
circbuf_ten64[6]: 88485129
circbuf_ten64[7]: 98485132
circbuf_ten64[8]: 108485135
circbuf_ten64[9]: 118485139 <= NEW ENTRY same value as 64-bit Counter
circbuf_ten64[10]:
circbuf_ten64[11]: 28485109
Fix time 959mS
measurements using 64-bit counter:
64-bit Counter: 118485139
Frequency: 10000004 Hz
10s Avg: 0.0 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 13
#
#
circbuf_ten64[0]: 28485109
circbuf_ten64[1]: 38485113
circbuf_ten64[2]: 48485116
circbuf_ten64[3]: 58485119
circbuf_ten64[4]: 68485122
circbuf_ten64[5]: 78485126
circbuf_ten64[6]: 88485129
circbuf_ten64[7]: 98485132
circbuf_ten64[8]: 108485135
circbuf_ten64[9]: 118485139
circbuf_ten64[10]: 128485142 <= NEW ENTRY same value as 64-bit Counter
circbuf_ten64[11]: 28485109
Fix time 961mS
measurements using 64-bit counter:
64-bit Counter: 128485142
Frequency: 10000003 Hz
10s Avg: 10000003.3 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 14
#
#
circbuf_ten64[0]: 138485145 <= NEW ENTRY same value as 64-bit Counter <= new beginning of cycle but last value is the same
circbuf_ten64[1]: 38485113
circbuf_ten64[2]: 48485116
circbuf_ten64[3]: 58485119
circbuf_ten64[4]: 68485122
circbuf_ten64[5]: 78485126
circbuf_ten64[6]: 88485129
circbuf_ten64[7]: 98485132
circbuf_ten64[8]: 108485135
circbuf_ten64[9]: 118485139
circbuf_ten64[10]: 128485142
circbuf_ten64[11]: 28485109 <= SAME VALUE for many many cycle, when and where change?
Fix time 956mS
measurements using 64-bit counter:
64-bit Counter: 138485145
Frequency: 10000003 Hz
10s Avg: 10000003.2 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 15
#
#
circbuf_ten64[0]: 138485145
circbuf_ten64[1]: 148485148 <= NEW ENTRY same value as 64-bit Counter
circbuf_ten64[2]: 48485116
circbuf_ten64[3]: 58485119
circbuf_ten64[4]: 68485122
circbuf_ten64[5]: 78485126
circbuf_ten64[6]: 88485129
circbuf_ten64[7]: 98485132
circbuf_ten64[8]: 108485135
circbuf_ten64[9]: 118485139
circbuf_ten64[10]: 128485142
circbuf_ten64[11]: 28485109
Fix time 962mS
measurements using 64-bit counter:
64-bit Counter: 148485148
Frequency: 10000003 Hz
10s Avg: 10000003.2 Hz
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 16
#
and so on...
Excellent work finding this bug! I am Going to Try your solution ASAP. But it Makes Sense, When I Have Very Good Satellite Reception I Don't Get The "Jumps" So Much.
Thank You!
I am Happy That I Can Help !!!
This project is very nice and not expensive, this makes it quite easily.
bye A.
-
Your "not a problem" is a classic "out-of-bounds" access. C is not a managed language. Accessing the array at index 11 means you're accessing, possibly writing to a memory location that is occupied by another variable. No wonder you get strange values.
-
thinkFat you are perfectly right,
thanks for the clarification :)
bye, A.
-
circbuf_ten64[11]: 28485109
Yes, that's an out-of-bounds memory access.
-
@bob91343
Do You have already Arduino IDE? If not, install it from here:
https://www.arduino.cc/en/software (https://www.arduino.cc/en/software) (Arduino IDE 1.8.19)
then You have to install STM32Duino support in Arduino IDE. Here You can read how to do that:
https://github.com/stm32duino/wiki/wiki/Getting-Started (https://github.com/stm32duino/wiki/wiki/Getting-Started)
PM me when You finish this step. Do You use Discord? This is offical EEVBlog channel there: https://discord.gg/qGMhKbq (https://discord.gg/qGMhKbq) (try it, it's IRC like software)
[EDIT]
After it's done You can watch this video. It explains how to connect to board (program, access serial data etc)
https://www.youtube.com/watch?v=b1123kz_3MM (https://www.youtube.com/watch?v=b1123kz_3MM)
-
Got it working :-+
... but commands are not recognized
Any ideas why?
I am more a HW guy ...
12:44:25.193 -> Voltages:
12:44:25.193 -> Vctl: 1.06 DAC: 2397
12:44:25.193 -> VctlPWM: 2.12 PWM: 45074
12:44:25.193 -> Vcc: 4.71
12:44:25.193 -> Vdd: 3.31
12:44:25.193 ->
12:44:25.193 -> Frequency measurements using 64-bit counter:
12:44:25.193 -> 64-bit Counter: 13442871830
12:44:25.193 -> Frequency: 10000000 Hz
12:44:25.193 -> 10s Frequency Avg: 10000000.0 Hz
12:44:25.193 -> 100s Frequency Avg: 10000000.07 Hz
12:44:25.193 -> 1,000s Frequency Avg: 10000000.063 Hz
12:44:25.193 -> 10,000s Frequency Avg: 0.0000 Hz
12:44:25.193 ->
12:44:25.239 -> Unrecognized command [V]
12:44:25.239 ->
-
Got it working :-+
... but commands are not recognized
Any ideas why?
I am more a HW guy ...
12:44:25.193 -> Voltages:
12:44:25.193 -> Vctl: 1.06 DAC: 2397
12:44:25.193 -> VctlPWM: 2.12 PWM: 45074
12:44:25.193 -> Vcc: 4.71
12:44:25.193 -> Vdd: 3.31
12:44:25.193 ->
12:44:25.193 -> Frequency measurements using 64-bit counter:
12:44:25.193 -> 64-bit Counter: 13442871830
12:44:25.193 -> Frequency: 10000000 Hz
12:44:25.193 -> 10s Frequency Avg: 10000000.0 Hz
12:44:25.193 -> 100s Frequency Avg: 10000000.07 Hz
12:44:25.193 -> 1,000s Frequency Avg: 10000000.063 Hz
12:44:25.193 -> 10,000s Frequency Avg: 0.0000 Hz
12:44:25.193 ->
12:44:25.239 -> Unrecognized command [V]
12:44:25.239 ->
Well done! :-+
And many thanks for the picture.
As to why the commands are not recognized... I have no idea. :-//
It could possibly be due to a change in the command library API. Commands work fine here.
-
I have a plan to run it tonight (8PM right now).
Software is already uploaded, I have managed to program Black Pill. Altough it doesn't look like original one, (it doesn't have USB-C). I found that yesterday. Pinout looks different as well.
Going back to wiring and locating correct pins... DOH...
(https://a.allegroimg.com/original/1109f9/953c6f784d7393bbd4a1937e305c/STM32-STM32F411CEU6-Black-Pill-MicroPython-Arduino)
(https://lh3.googleusercontent.com/50oCNmDGi80PywOh1j5KKl_ppKao5hGviRCvx3M2W1JNgOmWBCxc2lEFpiTJbjRwx0RfZEhhPH6OKFzJ5JFdIi_B_BnCiCW099iBwlbO2YP9534Vul4_p3XydHiTV1KyiKOgVnRZDNP_ClglDIv5SgylNo_URLe-DCS_PifH_icjuZq2L770e6x4xCEvRkDdH02IBILWiC5J8qojwin0cKdsXLW9Ch7cFcfMNFBK24t7cJfd2dSPqvZ1L4t3h-HR3ZIhfPODkvA7pnAJ5eF90-YmVTGdpuQ6H_RW0wJ7KAI4eRm-p59lGxjzzNIXc2B1XiT2pi8izD4fg1kKmeyVuDxzeLOAcoeEQFdKD48cHPR08WlwUWwJIW4B6MmwRqHEo6RXGIbFU3DHZL69gi-9yM-sZgEAenjRTkg_0axuVulBBymDj_bTh5bEEpwVOPduJDKEt4BZB5uEiGQ7OWsUEOYptZGYg8rtMcGRJtLHL9eagDfLTRagF5beCaVfExLwaD6h0nE40Tc7-965oqzcxg8dBgsMuB6L_5C-sT6nA5DTImyFsnlpUhEYG3l57dk7W2Ww_e9Ov0mLMgiVgUQayBYqm-MFSwGfjYtPW-7PbjoYn2DM2z-Zo1Ju2sKpspI0BTF5PJxXDXQ9HN05_uXc-zi_oM_sElkKAGz7H2A1PyDPm-yf5E6-94NurudLK2kK1LEP8ivc1BpPuh4tTqJE7elsRQ=w834-h625-no?authuser=0)
(https://lh3.googleusercontent.com/n06TNJjsWp5i5lwttb7crnrazbquq4jA-B2YK1eGfIhk7OhkdxZ4-_WymTPYLFbHmxUnW_sHOwlHH4hPKlNFpYhXnqWOUpyF7QItPwwRvsJ801mx_mbqFWI1tML0vHOv8Z-YLNoKr1RkMHK1YbpHqm9tR2SuU-cW0ZXyDEoukWzUvQVbOrXlQy9blDMBqDZr6erYH-yucYTREaeQgEfD5_7ITfi6n9P49RqH-S0pQumqFQalsRzjd1EAfqxObYvtSSRqSqH7aoKr7FFKbDxvGh1RQx8dr9G2DnfNvlHQjfK9PbdUCX_1abkxwCf1DeScprGPi1I8pe99kadjWcr8Wwt9uwV2MpUQ_Eo390rBj7wfmbfbyYfp6swMYg3t6NjxIF_H-_IueCMWZUy7jHQhgjdP9485jcdpytjqLDYXwzSFnREtRzVw1Hx97LSGcL2F5-_bbXP8qW5LAmKpKyozMPFZwepStXY0jaF8LB_yhO927Ism_0GN_j0g205Xz6iG6HL4zGkecpvZisQSLMxrRSxQScouSu8Ip0bjvKQUfa8mJke0sCde1QAOAceauyoIfFQtHaaB2Q-EQmx8utLisQli-7v8a92EAwdb3GHxCoomNsK8R0b8CqnXyhE2kZS0yH4LxYOp4PjvwwrjbWqF093jgqfI_VeAXZz7-5nRpyr2VEAgsWhiImdhrGNwHFFfP-W8NzbwoP4uz8scMGAWa4yh1w=w469-h625-no?authuser=0)
(https://lh3.googleusercontent.com/NSfKGDysakx2HQubHtYTRDhcqdf3FlD6AYHx3wjsiBBBNzwwDj2zld_HgNlivMYUnfklQ9lQUqhFrQTg4yrrymq7HznG-0ZFVHKyHt6TF3Le5DKUlysuT1scw7_6sDFOs6k1GOOXFvarRa0RM-DuyWI6ocCgauSb54wQQiq45GDp2cqkHqw7XI7lDwkOU13iK29fDIA9I4u4y1MfbFfPSAOAxtRO-it7ylZgyJXQkmyoQ5NfrEHL5oTJ_qKm73hn5Os0MPfF0EnYLUEce80h01mMFkmTWTsArehDnJOZ9UUeKGYzr69loemd4bUMmHJKJ94DIwc0liIl9itCkO8XTlsQvvzHMKYnW_5Q-dg1bQzeyrjJWw52aw9nPZHH62CQ6ZDDZJ4WWwG4b0Oq7POJbaMLJxzGhm2tQMOiClPhhoFLgY7cTkCJcL0BRJt118j3x4iYb-aMLRcPw1DseWBTCdO9CBpEZzjDu3TlN6q1IAYD0UhtvPhKcBuXGr5p8mliNsDmmH9hS5mK1SF3TvulC4n-GoNkb_zObT49trfiBjg7ZgOhCJ3w8er-Df_GtSueFM9KiLNqRvovc7zv2wbpd7Zg9XpBJw0Mv4OMC0w_0_FFquzq3RxFs7gzOKMNP4loBrxfOa3LjypBsvG_zBFHYpjam59_4MYClkUJiD9Or6iDixobFAWb6j-FtRmKHeaSrB_QxLk_JIM5hr9cyLrLCHY1IQ=w469-h625-no?authuser=0)
-
... recognizing commands .....
-> reading the comments in the code helps a lot (well done :clap:)
// "\n" means only newline needed to accept command
... works fine :-+
Tnx, Frank
-
[UPDATE on Bob91343]
Quick update on @Bob91343 situaton. After exchanging tons of screenshots on Facebook and some remote desktop VooDoo I have managed to help Bob with Arduino and BlackPill board.
So Bob already has:
- Latest Arduino installed
- All required libs for compilling
- STM32 (STM32CubeProgrammer) installed. Just for DFU checking.
- We were able to upload code to uC.
- After uploading code we were able to connecto Serial Monitor
We have received simillar messages like one below.
23:37:38.313 -> UBX command sent, waiting for UBX ACK...
23:37:38.313 -> * Reading ACK response: (FAILED!)
23:37:41.297 -> Oops, something went wrong here...
23:37:41.297 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
I assumet it's becuase program cannot connet Yet with u-Blox. I am fighting with that at the moment on my side.
- Bob knows how to set BlackPill in BOOT mode.
Now Bob need some assitance with wiring things and setting up code to work with components he has. I can't assist him now with that, as I need to go though that for myself ;)
Good luck Bob!
-
Yes felixd you worked some magical miracles with my board. Now I need to think about what comes next. I have the diagram so will wire up the units and see what to do.
I should pick up some perf board and put it on that.
Big thanks to you felixd! I could never have done that. It's what happens when your engineering becomes obsolete.
-
...
We have received simillar messages like one below.
23:37:38.313 -> UBX command sent, waiting for UBX ACK...
23:37:38.313 -> * Reading ACK response: (FAILED!)
23:37:41.297 -> Oops, something went wrong here...
23:37:41.297 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
I assumet it's becuase program cannot connet Yet with u-Blox. I am fighting with that at the moment on my side.
...
Yes, that means the STM32 Black Pill did not get the expected response from the u-blox GPS module.
You can check:
1. That you have a u-blox M8N module. I am not sure that command works with the M6N or M7N.
2. That the serial connection to the u-blox module is working. (you have examples in the GPS library that do that).
3. That your GPS module is working. You can connect it to a PC using a USB to serial adapter.
-
uC was powered up before GPS ;) All fixed.
02:30:36.264 -> $GPGSA,A,3,19,01,21,22,32,17,03,31,,,,,2.29,1.39,1.81*04
02:30:36.264 -> $GPG92,35*7A
02:30:36.264 -> $GPGSV,3,3,10,31,18,103,28,32,33,053,30*7F
02:30:36.264 -> $GPGLL,5231.xxxxx,N,01736.xxxxxx,E,013037.00,A,A*69
02:30:37.156 -> $GPRMC,013038.00,A,5231.xxxxxx,N,01736.xxxxxxx,E,0.041,,270122,,,A*79
02:30:37.156 -> $GPGGA,013038.00,5231.xxxxx,N,01736.xxxxxx,E,1,08,1.39,129.5,M,37.4,M,,*58
02:30:37.203 ->
02:30:37.203 -> Fix time 939mS
02:30:37.203 -> Uptime: 000d 00:04:00
02:30:37.203 -> New GPS Fix:
02:30:37.203 -> Lat: 52.xxxxxx Lon: 17.xxxxxx Alt: 129.5m
02:30:37.203 -> Sats: 8 HDOP: 1.39
02:30:37.203 -> UTC Time: 01:30:38 Date: 27/1/2022
02:30:37.203 ->
02:30:37.203 -> Voltages:
02:30:37.203 -> Vctl: 0.33 DAC: 2400
02:30:37.203 -> VctlPWM: 0.54 PWM: 0
02:30:37.203 -> Vcc: 1.34
02:30:37.203 -> Vdd: 3.31
02:30:37.203 ->
02:30:37.203 -> Frequency measurements using 64-bit counter:
02:30:37.203 -> 64-bit Counter: 2315230278
02:30:37.203 -> Frequency: 9999990 Hz
02:30:37.203 -> 10s Frequency Avg: 9999990.1 Hz
02:30:37.203 -> 100s Frequency Avg: 9999990.18 Hz
02:30:37.203 -> 1,000s Frequency Avg: 0.000 Hz
02:30:37.203 -> 10,000s Frequency Avg: 0.0000 Hz
02:30:37.203 ->
02:30:37.249 ->
Tomorrow I will play a bit with Vctl/PWM (there is small issues in code) + I haven't connected Vctl at all :D
Great job Andrew! (+ kind reminder about pull request). I suggest also for others, whenever we are talking about code it would be great to point it on GitHub so we all know what we are talking about and which version we are talking about ;)
Good night.
(https://lh3.googleusercontent.com/e4Om5iL4cC4wN7XloaphiHPmqQGqXb6JpvnGXrCiEENM9NxcDFp5_H2lhbyS1rzZlN2eQeXiAiUi0mE1y-r-_PIWA82KJWjQBQrYsrsUZI4k1cbFlmMgDM2a3TgW3OreTOgmdetlnn-jqJ7EoiAj7i5-IkcBKDpBedyhVfOlHSlqw1qCTxPlzWRv_9eCAyKU-zs2EjjbnffYqfoGSpmLYINLgrYCUQhdLD6zaUb5FImDpwHIUAOjAuYzFM7qBkxPNEnuV3Aqga98fch-JzAaTdTXrSwPoLAw3gs5pKpR0-u5gKTzqjiLUAyjk88pmp1lS5BPq3bpe1n4uIOMEzIEGIe5p8nK-xSXJCXWEqwqZKOQwW63VDpW3UGUyvecxlBY9cULu4A8Ojw49Yi11rsm5Sb7ORSWrEzkc-GfQGuOcjKcI-NhQaZwNdcqmjnnyZ5p43Dq2fAWMyTXID_6PAFcyT9Hw_nHtBu2zvnlJWqTlFYJ0ZayoUYHREDrJtd4EGLGwcTTxM7-khXVh1sHNCkhhJHF7Ztl-q_lwY9L6IaX4fAyFg3As3fboXZh--p4Brm8hjnaSoZatpC6JuoAVR8XypMvNw9rbFkZkMn0zlflGYTatXbtqeX8AdfxNxjR_uT9vjL54lotvTH0_M6kXxN2iin0r0_ZvjAH5gTrSXZTADh8g99tF2ZBUUfC6pA-yfPE1NVgnYdI1peFUEFcXkVthocS3A=w834-h625-no?authuser=0)
------------
[UPDATE] We have working 10000000.00 Hz :) Since hardware is working fine I will now have time to look at software ;)
Fix time 949mS
Uptime: 000d 01:45:42
New GPS Fix:
Sats: 11 HDOP: 0.96
UTC Time: 17:41:29 Date: 27/1/2022
Voltages:
Vctl: 0.31 DAC: 2395
VctlPWM: 1.91 PWM: 37996
Vcc: 5.01
Vdd: 3.31
Frequency measurements using 64-bit counter:
64-bit Counter: 63349355009
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 9999999.999 Hz
10,000s Frequency Avg: 0.0000 Hz
-
Good work felixd !!!
-
felixd you are the man! Single handed you pulled me up from disaster and now I have some hope that this project can be completed successfully.
Thank you once again.
Now I need to mull over the next step, probably assemble all the pieces.
-
Hey Bob, YES! now You need to wire up the board. Few changes in code and GOOD wiring and we have working project! :)
I just went trough that. you can do it.
Yellow trace is 10MHz from OCXO.
Blue same signal, after resistor ;)
-
Hi bob91343,
If you have a breadboard and jumper cables you can enter the components
and make connections to test both the micro and your GPS (what model is it?).
I attach some photos and AndrewBNC schematic that have already been posted.
These make you understand how to make connections to the various micro pins.
I also put a picture of you like I do the tests, but don't look at the cables or anything
because I use for now in the absence of VXCO another oscillator.
bye, A.
-
Some more images of my setup. BTW, that's not my lab but since my wife is gone for some days... :D hahaha I moved some things to different place.
Below some log from AutoCalibration I run after GPSDO was running for about 40 minutes. I was checking frequency range avail for correction.
UTC Time: 19:46:29 Date: 27/1/2022
Voltages:
Vctl: 0.33 DAC: 2406
VctlPWM: 1.91 PWM: 37889
Vcc: 5.00
Vdd: 3.31
Frequency measurements using 64-bit counter:
64-bit Counter: 34517460710
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.1 Hz
100s Frequency Avg: 10000000.09 Hz
1,000s Frequency Avg: 10000000.016 Hz
10,000s Frequency Avg: 0.0000 Hz
Auto-calibration sequence started
Calibrating...
set PWM 1.5V, wait 15s
f1 (average frequency for 1.5V Vctl): 9999997.3 Hz
set PWM 2.5V, wait 15s
f2 (average frequency for 2.5V Vctl): 10000005.3 Hz
Calculated PWM: 37631
Calibration done.
-
Any good advice how to enter stm32f411 flash mode via direct USB connection?
I found different procedures for boot and nrst button but I need some 10-20 tries, even it is directly connected to the PC without any hub.
@felixd: your 2nd snap: there is a small bug in display sub routine, between longitude/latitude and voltages the previous text is not removed.
-
Hey Badwater.
I had same issues on my side (also same issue happened when I was playing with Bobs computer). What worked for me and for Bob was to:
1. Disconnect USB cable from uC
2. Hold BOOT button
3. While holding it plug USB cable.
4. Look for STM32 BOOTLOADER device in Device Manager
If it won't work try to install STM32 Cube Programmer software first and follow above steps again.
https://www.st.com/en/development-tools/stm32cubeprog.html (https://www.st.com/en/development-tools/stm32cubeprog.html)
That worked for me and Bob.
Once STM32 BOOTLOADER driver is loaded correctly You can than (while USB cable is connected) just press and hold BOOT button and press shortly NRST. Now it should work just fine.
Tell me please if that helped.
Cheers, Paweł.
-
@felixd: your 2nd snap: there is a small bug in display sub routine, between longitude/latitude and voltages the previous text is not removed.
You're spying on me! :) haha ;]
Yes, I have noticed that. I am using not modified source code from Andrews GitHub. It's not a big deal at the moment. Most important if frequency ;)
I am trying to reorganize this repo a little bit. You can check for changes I have made here: https://github.com/felixd/STM32-GPSDO/tree/main
BTW, I am using u-Blox NEO-6M, works a treat (8M is on the way).
-
You're spying on me! :) haha ;]
:-DD ... no, no ... I noticed the same here and fixed it for me. I am not acquainted with the git stuff, neither a good programmer :-//
-
I use a stlink for programming blackpill.
and usb connector for debug with arduino ide.
Simple and comfortable.
in the photo bluepill but it s the same for blackpill
-
...
@felixd: your 2nd snap: there is a small bug in display sub routine, between longitude/latitude and voltages the previous text is not removed.
Yes, there is a small bug, it's missing a line that clears the display. That should be fixed in my next release, or you can add the line.
-
I use a stlink for programming blackpill.
Yes, this works flawlessly .... :-+
The advice from @felixd is also not always working, my two (chinese) boards are picky :-//
Tnx, Frank
-
...
@felixd: your 2nd snap: there is a small bug in display sub routine, between longitude/latitude and voltages the previous text is not removed.
Yes, there is a small bug, it's missing a line that clears the display. That should be fixed in my next release, or you can add the line.
Hey Andrew, fix has just been added to #4 pull request on GitHub. I have also added some more information to be displayed on OLED during calibration.
-
This whole conversation is way over my head. Does it mean I have to reload the pill?
-
Yes, Bob.
We will have to make small changes in software, re-compile it so we will have new firmware that we can upload to a hardware.
I will help You with that.
We will prepare Minimal Version that doesn't requier by You to have: OLED nor other sensors. Just:
- STM32 μC - BlackPill
- OXCO
- resistors and capacitors + some cables. (analog things :) )
I never asked, which components have You already bought Bob?
-----
@AndrewBNC
First time GPSDO is running longer than 8 hours:
Sats: 11 HDOP: 0.90
UTC Time: 06:16:47 Date: 28/1/2022
Voltages:
Vctl: 0.34 DAC: 2406
VctlPWM: 1.93 PWM: 37855
Vcc: 5.00
Vdd: 3.31
Frequency measurements using 64-bit counter:
64-bit Counter: 277404315810
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 10000000.000 Hz
10,000s Frequency Avg: 10000000.0001 Hz
Nice! :)
-
...
@AndrewBNC
First time GPSDO is running longer than 8 hours:
Sats: 11 HDOP: 0.90
UTC Time: 06:16:47 Date: 28/1/2022
Voltages:
Vctl: 0.34 DAC: 2406
VctlPWM: 1.93 PWM: 37855
Vcc: 5.00
Vdd: 3.31
Frequency measurements using 64-bit counter:
64-bit Counter: 277404315810
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 10000000.000 Hz
10,000s Frequency Avg: 10000000.0001 Hz
Nice! :)
Well done! :-+ Thanks for all the feedback and GitHub contributions!
And with 11 sats tracked, the measured precision is similar to what I get, and exceeds the project's original target precision by two orders of magnitude! So really not bad for such an inexpensive GPSDO.
-
Well done! :-+ Thanks for all the feedback and GitHub contributions!
And with 11 sats tracked, the measured precision is similar to what I get, and exceeds the project's original target precision by two orders of magnitude! So really not bad for such an inexpensive GPSDO.
Thank You. That's correct, it was not expensive.
Paweł.
-
Hi Felixd,
I saw that you talked about github and there would be a bit of things in the default code they don't compile.
if for example I comment The DAC 12bit #define...
How can you proceed?
tnx, A.
-
I don't understand Your question correctly. Can You write it ance again?
https://github.com/felixd/STM32-GPSDO <-- this is my fork of AndrewBCN repository. I am making my own changes there + I am pulling my main branch to Andrews main branch (but he needs to accept changes first).
And if You are intersted in changes I am trying to pull to Andrews GitHub repository:
https://github.com/AndrewBCN/STM32-GPSDO/pull/4/files
If by DAC 12-bit commenting You mean this line:
//#define GPSDO_MCP4725 // MCP4725 I2C 12-bit DAC
https://github.com/felixd/STM32-GPSDO/blob/main/software/GPSDO/GPSDO.ino#L126
Yes, that has been fixed on my side.
That's the quick fix: https://github.com/felixd/STM32-GPSDO/commit/6075b9ca35ba59c5528f45c6956bfe042e1bc88a
Cheers
-
I understood now.
You made a fork on github where locally make your changes.
I have to study github :)
bye, A.
-
I understood now.
You made a fork on github where locally make your changes.
I have to study github :)
bye, A.
Yes, study Git (Github is just an "overlay" on Git).
https://lab.github.com/githubtraining/introduction-to-github (https://lab.github.com/githubtraining/introduction-to-github)
Some YT videos on topic:
https://www.youtube.com/watch?v=2ReR1YJrNOM (https://www.youtube.com/watch?v=2ReR1YJrNOM)
https://www.youtube.com/watch?v=USjZcfj8yxE (https://www.youtube.com/watch?v=USjZcfj8yxE)
-
Yes one step at a time :)
https://github.com/iannezsp/STM32-GPSDO
next step i try pull request, i hope :)
A.
-
I bought boards at All Electronics. Now to assemble the project. Maybe I have all the parts.
-
I bought boards at All Electronics. Now to assemble the project. Maybe I have all the parts.
Remember, less parts, less problems :-DD
-
So no parts, no problems?
-
100% TRUE >:D
But I guess we need "a little problem". Everything is wired up already?
-
Not yet. I had to install a security light and camera outside. Now I need to warm up and maybe practice some jazz. I have to be in the right mood for these things.
I did in fact do some work on an LCD illuminator for a DMM. Once I take inventory of the parts I will decide how to organize the hardware. I don't know if I should use perf board or a push-wires-in breadboard I bought. I need to mount the black pill, the arduino, the receiver, the TCXO, and I have to see what else. I spent about $5 for stuff from All Electronics.
The layout needs to allow for connections to power, antenna, and output connector. The operation of this gizmo is still a mystery.
-
So no parts, no problems?
More properly put: "No parts, no problems, no project."
Sorry, I couldn't resist. :)
-
This project sounds interesting and fun. I have ordered the needed parts.
Andrew, do you have an approx date when you plan to merge the software changes/fixes that
have been discussed in the last month, and update your GIT site with a new version?
Sincere Thanks for designing this project. It has far fewer parts than some of the other
DIY GPSDO projects, including LARS.
Cheers,
Neal
-
Have you ever encountered issue like this with GPS?
$GPTXT,01,01,02,u-blox ag - [url=http://www.u-blox.com]www.u-blox.com[/url]*50
$GPTXT,01,01,02,HW UBX-G60xx 00040007 FF7FFFFFp*53
$GPTXT,01,01,02,ROM CORE 7.03 (45969) Mar 17 2011 16:18:34*59
$GPTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*20
$GPTXT,01,01,02,ANTSTATUS=DONTKNOW*33
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPTXT,01,01,02,ANTSTATUS=INIT*25
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPTXT,01,01,02,ANTSTATUS=OK*3B
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
I have looked for last NMEA codes and it says it's Internal Error of GPS...
I start to look right now for an answer in Intenet, but I am asking here, maybe you had issues like this before ;)
EDIT:
Looks like some !@#!@$ antena connection... ... |O
It is working again. I am not touching them anymore ;D
Cheers
-
Hi Felixd,
I've never seen that kind of mistake before.
I imagine that if you restart everything back to normal.
Have you verified the number of active satellites at the moment?
And the other parameters detected?
in the meantime I'm trying to understand the difference of
"Fix Time" between two GPS modules (Chinese ...)
This because it often comes out:
Fix Time 1001ms and even more
and this is not good because it clears the counter even if I have the FIX of the Counter PPS.
bye A.
-
Felix, I recently has issues with my Lightening detector. Often it's a power issue, either no power getting to the antenna or in my case the usb power supply dying. The data coming from the chip just shows as default data but no time fix.
I must get around to getting mine working, can't let Bob beat me to getting one up and running. ;-)
-
This project sounds interesting and fun. I have ordered the needed parts.
Andrew, do you have an approx date when you plan to merge the software changes/fixes that
have been discussed in the last month, and update your GIT site with a new version?
...
I should be merging the various pull requests and my own further developments in the coming days.
-
Have you ever encountered issue like this with GPS?
...
EDIT:
Looks like some !@#!@$ antena connection... ... |O
It is working again. I am not touching them anymore ;D
Cheers
Yes, I think I wrote it before, but it's worth repeating: any GPSDO depends on getting a good signal from as many satellites as possible (10 or more, preferably), and for that you need a good antenna and a good view of the sky.
-
What ever happened to your plans for a PCB? Maybe I missed it.
-
What ever happened to your plans for a PCB? Maybe I missed it.
I think it is in the pipeline but I did see AndrewBCN says he hasn't been well.
-
@AndrewBCN I have few questions. I have made some changes to code, some things were really confusing for me in the beggining so I decided to change some names to something more meaningful.
Changes that are done, are made on fit-gpsdo branch on my fork. (this is WIP - Work In Progress branch so it can be messy ;) )
https://github.com/felixd/STM32-GPSDO/tree/fit-gpsdo (https://github.com/felixd/STM32-GPSDO/tree/fit-gpsdo)
Idea is: GPSDO_FUNCTION_IDENT
How it looks right now on my side:
#define GPSDO_DISPLAY_OLED // SSD1306 128x64 I2C OLED display
//#define GPSDO_VCTL_MCP4725 // MCP4725 I2C 12-bit DAC
#define GPSDO_VCTL_PWM // STM32 16-bit PWM DAC, requires two rc filters (2xr=20k, 2xc=10uF)
//#define GPSDO_SENSOR_AHT10 // I2C temperature and humidity sensor
#define GPSDO_GEN_2kHz // Generate 2kHz square wave test signal on pin PB9 using Timer 4
//#define GPSDO_SENSOR_BMP280 // SPI atmospheric pressure, temperature and altitude sensor
//#define GPSDO_SENSOR_INA219 // INA219 I2C current and voltage sensor
// TODO: When UART2 (Bluetooth) is activated less messages are shown on OLED and UART1 (USB serial)
#define GPSDO_UART2 // UART2 (Bluetooth) serial (HC-06 module)
#define GPSDO_ADC_5V // Vcc (nominal 5V) ; reading Vcc requires 1:2 voltage divider to PA0
#define GPSDO_ADC_3V3 // Vdd or Vref (nominal 3.3V) reads AVREF internal ADC channel
// TODO: Below Calibration definition is not used..
#define GPSDO_CALIBRATION // Auto-calibration is enabled
#define GPSDO_GPS_UBX_CONFIG
//#define GPSDO_GPS_VERBOSE_NMEA // GPS module NMEA stream echoed to USB serial xor Bluetooth serial
--
Vcc and Vdd were super confusing for me in the beggining (same on Schematics). It was not clear what Voltages I should expect so I've changed names to point what voltages we are working with. Same with variable names
--
GPSDO_CALIBRATION is not used at all. From my point of view it should work as it is working right now: Calibration is done everytime after restart. This option sould be removed from code.
--
GPSDO_GPS_VERBOSE_NMEA I have just dirrectly connected to Serial1 on breadboard to see all GPS<->STM32 traffic. That's much better in my opinion. You have proper NMEA messages which can be decoded by u-Center app. An for that, this port should be available as well on PCB
--
I have also formated code (autoformating in Arduino IDE v1 with indent-preproc-block option ON)
Example of what I am writting about:
#ifdef GPSDO_SENSOR_INA219
#include <LapINA219.h> // LapINA219 library library
LapINA219 ina219(0x40); // create object INA219 with I2C address 0x40
float ina219volt = 0.0, ina219curr = 0.0;
TwoWire Wire3(PB4, PA8); // Second TwoWire instance for INA219 on SDA3/SCL3 (should be put somewhere more fitting but must stay global)
#endif // INA219
--
Once functions / block are recognized and corrected in GPSDO.ino they should be move outside. Example GPS should be moved to gps.h / gps.c file. Same with sensors
--
UART output format: I suggest to format data in Arduino IDE Serial Plotter format.
https://docs.arduino.cc/software/ide-v2/tutorials/ide-v2-serial-plotter (https://docs.arduino.cc/software/ide-v2/tutorials/ide-v2-serial-plotter)
You can directly save that to CSV file and process data later on. You can as well parse data with an external application.
--
That's where I am slowly going to. Waiting for Your feedback.
BTW: My Racal-Dana 9514 (last calibrated 11/10/2012) was only 0.4 Hz off (it's running for more than 30 hours already). I have just adjusted it, which was a bit tricky but I have managed to do it ^-^
https://www.eevblog.com/forum/testgear/list-your-test-equipment-score-here!/msg790750/#msg790750 (https://www.eevblog.com/forum/testgear/list-your-test-equipment-score-here!/msg790750/#msg790750)
Cheers, Paweł.
-
Hi felixd,
I also made various modifications to the code ...
GPSDO_CALIBRATION is not used now also because
To enable or disable it, just use the following:
force_calibration_flag = false;
ocxo_needs_warming = false;
So doing bypasses from loop entry into the functions.
I'm running the compiled sketch for more than 26 hours.
Only with serial and si5351 for frequency generation on I2C.
All counters are perfectly consistent.
The frequency no because I simply read it from the si5351.
I'm waiting for Aliexpress a VCXO, hopefully good.
Fix Time 997MS
Uptime: 02:04:51 <= counter reset 24hours
SATS: 6 HDOP: 1.28
Frequency Measurements Using 64-bit Counter:
64-Bit Counter: 938771955800
Frequency: 9999997 Hz
10s Frequency AVG: 9999997.8 Hz
100s Frequency AVG: 9999997.85 Hz
1,000s Frequency AVG: 9999998.017 Hz
10,000s Frequency AVG: 10000000.0028 Hz
I have to check if the fixtime changes with the change of GPS module, I think so but I have to try again, I don't remember it.
In any case if it takes more than 1000ms just put 2 in:
const uint16_t waitFixTime = 2;
A bit of things should be reviewed but let's see what AndrewBNC says.
bye, A.
-
I'm waiting for Aliexpress a VCXO, hopefully good.
Why go for a VCXO over OCXO?
-
...
I think it is in the pipeline but I did see AndrewBCN says he hasn't been well.
After managing to avoid the 1st, 2nd, 3rd and 4th waves of SARS-COV-2 here in France, I was finally infected with the Omicron variant 10 days ago (community transmission, I don't know who I got it from or who I passed it on to - also I am fully vaccinated + booster with Pfizer), spent a week in isolation coughing and sneezing, and today (Sunday 30/01) is the first day I felt good enough to go out and walk a little bit and ride my bicycle.
I still have quite a few things to work out but in the coming days I should be able to find the time to sort the various pull requests from Pawel as well as my own accumulated changes and prepare a new release by next Sunday (6/02), if all goes well. I think I will name the next release "Omicron" - hehehehehehe, cough, cough. >:D
Thanks all for your patience! 8)
-
...
I think it is in the pipeline but I did see AndrewBCN says he hasn't been well.
After managing to avoid the 1st, 2nd, 3rd and 4th waves of SARS-COV-2 here in France, I was finally infected with the Omicron variant 10 days ago (community transmission, I don't know who I got it from or who I passed it on to - also I am fully vaccinated + booster with Pfizer), spent a week in isolation coughing and sneezing, and today (Sunday 30/01) is the first day I felt good enough to go out and walk a little bit and ride my bicycle.
I still have quite a few things to work out but in the coming days I should be able to find the time to sort the various pull requests from Pawel as well as my own accumulated changes and prepare a new release by next Sunday (6/02), if all goes well. I think I will name the next release "Omicron" - hehehehehehe, cough, cough. >:D
Thanks all for your patience! 8)
I think it's just down to luck with this thing. I spend a lot of time in engineering firms all over the UK, lots of a near misses but so far I have stayed free of it. I'm one door handle away from catching it.
-
mendip I ordered this:
https://it.aliexpress.com/item/1005001402512471.html?gatewayAdapt=glo2ita&spm=a2g0o.9042311.0.0.79314c4d96bWX1
bye,A.
-
My partner took Omicron many days ago.
But after three days of influence is now fine.
Tomorrow should have control, we hope it is negative otherwise another 10 days of quarantine.
Rested AndrewBNC :D
Bye, A.
-
mendip I ordered this:
https://it.aliexpress.com/item/1005001402512471.html?gatewayAdapt=glo2ita&spm=a2g0o.9042311.0.0.79314c4d96bWX1
bye,A.
That is a OX and not a VX, one is controlled by temp and seen and the better, the other by Voltage and is not as good.
-
To try it goes more than good.
I connect to the potentiometer with the filtered PWM.
It should work properly, i hope eheheheh :)
Bye, A.
-
[NOTE]
There is Temperature sensor on STM32 uC. Why not to use it by default? :)
---
Andrew, have you seen that?
https://github.com/stm32duino/wiki/wiki/API#analog
https://github.com/stm32duino/STM32Examples/blob/main/examples/Peripherals/ADC/Internal_channels/Internal_channels.ino
Edit: My breadboard had weak connections. That was causing all power related problems....
Title Count Deviation Unit Description
Lat 18862 0.00004179 ° Position LTP Latitude
Lon 18862 0.00004728 ° Position LTP Longitude
Alt (HAE) 18861 7.143 m Position LTP Altitude (above ellipsoid)
Alt (MSL) 18861 7.143 m Position LTP Altitude (above mean sea level)
X 18861 3.668 m Position ECEF X
Y 18861 3.090 m Position ECEF Y
Z 18861 7.744 m Position ECEF Z
-
The temperature sensor on the STM32 is not worth a lot for general purpose use. You mainly need it for ADC offset calibration IIRC. It is measuring the die temperature of the MCU, as soon as it gets "something to do" the temperature will rise, but that's only a very local effect. There is of course an influence from ambient temperature, but if you want to correlate that with frequency deviation of the OCXO, it's not really suited for that. I've tried that and then decided to add a separate sensor near the OCXO.
-
I have tested the temperature sensor on the STM32F411CEU6 and it is practically unusable, even with averaging ("smoothing") algorithms. The first (internal) builds of the STM32 GPSDO firmware actually had the code for reading the temperature sensor, then I commented it out, then I deleted it entirely.
But you can easily try it: just check the code where I read the Vref, with a few small changes you can read the internal temperature sensor too.
-
[NOTE]
Adding 300uF on 3V3 + 200uF on 5V helped a lot:
- GPS readings are much more stable now
- 3V3 (Provided by BlackPill ) is much more stable (below +/- 0.01V)
- There is Temperature sensor on STM32 uC. Why not to use it by default? :)
---
Andrew, have you seen that?
https://github.com/stm32duino/wiki/wiki/API#analog
https://github.com/stm32duino/STM32Examples/blob/main/examples/Peripherals/ADC/Internal_channels/Internal_channels.ino
---
Going back to 3V3 caps, GPS readings are now way much more stable. Before I was hitting even 100m circle.
Title Count Deviation Unit Description
Lat 18862 0.00004179 ° Position LTP Latitude
Lon 18862 0.00004728 ° Position LTP Longitude
Alt (HAE) 18861 7.143 m Position LTP Altitude (above ellipsoid)
Alt (MSL) 18861 7.143 m Position LTP Altitude (above mean sea level)
X 18861 3.668 m Position ECEF X
Y 18861 3.090 m Position ECEF Y
Z 18861 7.744 m Position ECEF Z
Looking at those deviation map captures, it looks as though the antenna doesn't have a direct view of the sky.
As an example of just how accurate a positional accuracy you can get out a uBlox M8N (fake or not!), I've attached a set of screen photos (1st three from when I was using a fake M8N module way back in 2019 just before raising the mag mount active patch antenna another half meter to peep over the ridge tiles by a foot or so) and the last 7 screenshots were from after raising the antenna into 'clear air' whilst I was surveying in a freshly acquired M8T I'd installed into my MK II GPSDO.
-
Good evening everyone,
Today I finally arrived the VXCO from Alixepress :)
I calibrated it with a precise 10mhz on board potentiometer.
Fix Time 991ms
Uptime: 01:02:32
SATS: 8 HDOP: 1.29
Frequency Measurements Using 64-bit Counter:
64-Bit Counter: 37454988627
Frequency: 10000000 Hz
10s Frequency AVG: 10000000.0 Hz
100s Frequency AVG: 10000000.00 Hz
1,000s Frequency AVG: 10000000.004 Hz
10,000s Frequency AVG: 0.0000 Hz
Now I wanted to understand how to connect the quartz control pin to the micro PWM without using external DACs.
Apart from the KICAD scheme do you have advice on how to connect point-point pin resistor cap
and with the names of the pin?
tnx all, A.
-
... it is an OCXO 8)
... follow the schmatic: PB9 - low pass (R2+3, C4+5) - Vctl - Vadj
Jumper3 1-2 connected, 3 open
... do not forget to set the correct defines in the code: uncomment the PWM defines, comment the DAC defines
BTW: alternative display 8)
-
I like that display! Fabulous!
-
tnx Badwater!
Tomorrow morning I try the connections :)
PS: the monitor is beautiful!
good night all :D
-
What is the model number of the display?
-
It is: 1,8" SPI TFT Display 128x160; ST7735 controller
... but it isn't that easy .... OLED is connected to I2C, this one is SPI .... other library .... there is a lot of code work to be done
I do not want to mix it up here, I have to acquaint myself with git to provide mods/changes to keep @AndrewBCN code data base consistent.
@AndrewBCN
BTW: I noticed that the calibration shall not be done before GPS-fix, so consider in the loop:
if (force_calibration_flag && gpsWaitFix(waitFixTime)) docalibration(); else
... keep it up :-+
-
BTW: These small modules use other pin for PPS output and might not work with the current initialization out of the box!
And my chinese board cannot be updated with u-center to the latest FW (3.xx, Galileo improvement); complaining not supported flash type.
Not recommended ...
-
Hello!
I made the links all ok: D
Tnx Badwater for advice!
Fix time 996mS
Sats: 8 HDOP: 1.02
UTC Time: 12:30:45 Date: 1/2/2022
Voltages:
Vctl: 0.27 VctlPWM: 0.50
PWM: 39973 LASTPWM: 39972 TREND:
Frequency measurements using 64-bit counter:
64-bit Counter: 45372829648
Frequency: 10000000 Hz
10s Avg: 10000000.0 Hz | 4/10
100s Avg: 10000000.00 Hz | 92/100
1,000s Avg: 10000000.000 Hz | 532/1000
10,000s Avg: 5464s wait to avg
uptime: 4544s | 000d 01:15:44
ULTRAFINE+1 RULE 8 ADJUST PWM: 39930
Added some voices to the serial to have better reading and indications.
At the next reboot there will also be the PWM trend if positive or negative and maybe equal.
I'm running the PWM control not every 429s (buffer overflow) but every 10s:
if ( (_avgupsec%10) == 0 && cbHun_full ) adjustVctlPWM();
So to have a faster check to test everything.
_avgupsec is variable that increases +1 each PPS.
I saw that there is no Lock control with LED or otherwise, could it be useful?
Could it be useful to use a configurable timer with here use a single LED for multiple functions / warnings?
Type two blinks per second, heating, three per second calibration, 4 for second other control, fixed for lock frequency at 0.01Hz etc ...?
I'm also collecting links to buy components for phase control and pps output with pcdiv.
Superb project and great forum: D
thank you all,
See you soon, A.
-
I noticed that in the PWM control cycle it is possible in a single step to configure the voltage twice:
Fix time 1000mS
Sats: 8 HDOP: 0.90
UTC Time: 13:16:20 Date: 1/2/2022
Voltages:
Vctl: 0.27 VctlPWM: 0.50
PWM: 40025 LASTPWM: 40026 TREND:
Frequency measurements using 64-bit counter:
64-bit Counter: 72732829648
Frequency: 10000000 Hz
10s Avg: 10000000.0 Hz | 1/10
100s Avg: 10000000.01 Hz | 0/100
1,000s Avg: 10000000.001 Hz | 265/1000
10,000s Avg: 2728s wait to avg
uptime: 7280s | 000d 02:01:20
FINE-10 RULE 2 ADJUST PWM: 40015 <= decrease freq fine
ULTRAFINE-1 RULE 6 ADJUST PWM: 40014 <= decrease freq ultrafine
Is it normal to run the two PWM controls or would you need a break in every if?
bye, A.
-
The control voltage does not seem to be correct in the print out.
Shall be between 1.5V and 2.5V and stabilize at abt. 2.0V.
-
uhmm, yep, with the multimeter on PB1 => VCTL i measure 1.94v
Do you also need the voltage divider R7,R6 connected to PA0?
Be minimal is not always good. :D
Bye, A.
-
...
Do you also need the voltage divider R7,R6 connected to PA0?
...
PA0 is the input to the STM32F411 ADC that reads Vcc (+5V) divided by 2 (by the two resistors that form a simple 2:1 voltage divider). It has no effect on the PWM DAC operation. It is not strictly needed as the STM32 GPSDO will perfectly operate without it, but it gives you a good idea if Vcc is correct or too low/high. In the source code I believe it is optional (one of the #defines).
-
Hi AndrewBNC,
Yes, looking at the code there is no correlation with the PWM which is piloted by the PB9 pin.
I asked why I actually misured in 1.94V but on serial I read 0.52 on VctlPWM
am I doing something wrong?
tnx, A.
-
Hi AndrewBNC,
Yes, looking at the code there is no correlation with the PWM which is piloted by the PB9 pin.
I asked why I actually misured in 1.94V but on serial I read 0.52 on VctlPWM
am I doing something wrong?
tnx, A.
PB1 is used to read back the VctlPWM, just make sure it is connected to the filtered output of the PWM DAC and that the compiled code is reading it correctly. You can also check that there is no ripple using an oscilloscope.
Also I would completely disconnect the circuit on the OCXO PCB (the trimpot) before you try to inject the VctlPWM to the OCXO. Otherwise you could damage the STM32F411.
-
Tnx AndrewBNC,
I removed the trimmer as recommended.
Performed initial calibration:
Calibrating...
set PWM 1.5V, wait 15s
f1 (average frequency for 1.5V Vctl): 9999995.7 Hz
set PWM 2.5V, wait 15s
f2 (average frequency for 2.5V Vctl): 10000004.2 Hz
Calculated PWM: 41080
I added serial commands to increase / decrease 1000 units at a time the PWM.
So I actually check that the frequency changes instantly, so the PWM is working.
If I measure PIN38 3.3V the multimeter marks 3.20V approx.
If I measure PIN40 5V the multimeter marks 4.30V approx.
If PIN38 3.3V bridge with PIN PA0 the serial returns to Vcc: 1.65.
Shouldn't it be 3.20V as measured by a multimeter?
In any case the micro is checking the VCXO because the frequency
It is beautiful stable:
Vdd: 13.25 <= should not be 3.20 as measured by a multimeter?
Frequency measurements using 64-bit counter:
64-bit Counter: 11333854696
Frequency: 10000000 Hz
10s Avg: 10000000.0 Hz | 10/10
100s Avg: 10000000.00 Hz | 21/100
1,000s Avg: 10000000.040 Hz | 131/1000
10,000s Avg: 8868s wait to avg
uptime: 1139s | 000d 00:18:59
thank you all,
maybe something escapes me,
Bye A.
-
...
If I measure PIN38 3.3V the multimeter marks 3.20V approx.
If I measure PIN40 5V the multimeter marks 4.30V approx.
...
You should get 3.3V and 5.0V +/- 0.1V. You are probably using the +5V from the Black Pill/USB to power the OCXO, and it's overloading the protection diode. Can you use a separate +5V source for the OCXO? This should solve your problem. In the schematic you'll notice the 5V@1A minimum requirement and the jumper to disconnect the Black Pill 5V from the OCXO 5V.
-
AndrewBNC I am using a mobile phone power supply for OXCO.
STM32 is powered via USB and shares power with the Neo7M GPS.
really strange the fact of the measures not consistent on the pins.
It is not that it to calibrate something or connect the 3.3 / vref
somewhere that I haven't seen?
Bye, A.
-
...
It is not that it to calibrate something or connect the 3.3 / vref
somewhere that I haven't seen?
...
In principle the Vref pin is connected to the 3.3V on the Black Pill. Do you have a real WeAct Black Pill or a clone? Check here: https://github.com/WeActTC/MiniSTM32F4x1
The program reads the Vref and prints it on the serial, what reading are you getting? Also make sure you are using a USB 3.0 (1A current capability) port to power the Black Pill, not USB 2.0 (500mA current).
Also try something better than a phone charger to power the OCXO, as suggested in the schematic it really prefers a stabilized linear 5V regulator (7805 or LM317T).
-
...
Added some voices to the serial to have better reading and indications.
At the next reboot there will also be the PWM trend if positive or negative and maybe equal.
I'm running the PWM control not every 429s (buffer overflow) but every 10s:
if ( (_avgupsec%10) == 0 && cbHun_full ) adjustVctlPWM();
So to have a faster check to test everything.
_avgupsec is variable that increases +1 each PPS.
...
There is cbTen_full cbiten_newest variable that is 1 once every 10s. Use that ;)
-
@iannez
I am missing the Vcc and Vdd line in your console print out are you shure the related defines are set correct in your code?
This is my console pront out:
Fix time 709mS
Uptime: 000d 00:04:02
New GPS Fix:
Lat: 5xxxxx Lon: 1xxxx Alt: 51.4m
Sats: 12 HDOP: 0.82
UTC Time: 23:08:33 Date: 1/2/2022
Voltages:
VctlPWM: 2.02 PWM: 43007
Vcc: 4.86
Vdd: 3.31
Frequency measurements using 64-bit counter:
64-bit Counter: 2344717350
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.02 Hz
1,000s Frequency Avg: 0.000 Hz
10,000s Frequency Avg: 0.0000 Hz
-
@BadWater:
What model display is that, and where can it be purchased?
Are you willing to share the code to write to that display?
It looks like a very useful addition to the project.
Neal
-
BTW: These small modules use other pin for PPS output and might not work with the current initialization out of the box!
And my chinese board cannot be updated with u-center to the latest FW (3.xx, Galileo improvement); complaining not supported flash type.
Not recommended ...
Maybe it's not even a M8.
-
Goodmorning everyone,
Badwater There are no voices because I removed them by tests.
AndrewBNC I tried with a minimal sketch with only Movingavg.h library and micro with USB psu/serial debug.
make bridge between PIN38 3.3V and PIN35 PB1
make bridge between PIN38 3.3V and PIN26 PA0.
I always read busted values.
I would expect a value next to 3.3V.
Question: Does the power supply 5V obviously connected to PIN40 5v?
IMPORTANT: can I use USB for debugging while it is connected to 5V power supply?
I wouldn't want to break anything.
As soon as I answer I feel other tests.
thank you,
bye, A.
-
discovered the problem ...
Obviously my fault, in erasing the line concerning the DAC12bit I also deleted:
analogreadedresolution(12);
in setup();
Now it's all correct:
Fix time 994mS
Sats: 9 HDOP: 0.91
UTC Time: 13:59:50 Date: 2/2/2022
Voltages:
VctlPWM: 1.87
PWM: 39412 LASTPWM: 39312
Vcc: 3.97 <= too smal probably because I share usb power supply with GPS...
Vdd: 3.31
Frequency measurements using 64-bit counter:
64-bit Counter: 2434798841
Frequency: 10000000 Hz
10s Avg: 10000000.1 Hz | 0/10
100s Avg: 10000000.04 Hz | 40/100
1,000s Avg: 758s wait to avg
10,000s Avg: 9758s wait to avg
uptime: 250s | 000d 00:04:10
FINE-10 RULE 2 ADJUST PWM: 39402
Felixd: thanks for the advice and you're right.
In any case they would both unnecessary because, in my case,
to speed up only the (_avgupsec%10) == 0 result would be enough.
I used cbTen_full to avoid entering the function at the moment in here is not yet full.
But it's not a problem, only testing to play here.
Can I advise to put more possible code as function so as to have setup() and loop() cleaner?
I have to learn Git Pull :)
Can you answer my question?
Does the power supply 5V obviously connected to PIN40 5v?
IMPORTANT: can I use USB for debugging while it is connected to 5V power supply?
I'm trying to bring everything on a pre-fried base to be a minimum more stable.
I will use three separate power supplies like AndrewBNC in KICAD pdf.
l love playing :D
See you soon, A.
-
discovered the problem ...
Obviously my fault, in erasing the line concerning the DAC12bit I also deleted:
analogreadedresolution(12);
...
IMPORTANT: can I use USB for debugging while it is connected to 5V power supply?
...
Not recommended. Again, this is why there is a jumper to disconnect the +5V going to the Black Pill. If you connect the Black Pill to USB, you must disconnect the +5V from pin 40.
-
right.
So how can I feed micro with externall psu and at the same time debug via usb serial?
where is a jumper?
bye A.
-
Iannez, great you have solved Your problems.
BTW I have made a mistake, use: cbiten_newest variable that is == 1 once every 10s.
Yes, learn how to use Git. Push,pull, commit. merge ;)
BTW, following Iannez I have also corrected serial messages :) Some alignment.
Latest changes are here: https://github.com/felixd/STM32-GPSDO/tree/fit-gpsdo/software/GPSDO (this is "development" branch)
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz [9/10]
100s Frequency Avg: 10000000.00 Hz [67/100]
1,000s Frequency Avg: 10000000.001 Hz [526/1000]
10,000s Frequency Avg: 10000000.0009 Hz [1572/10000]
I have also seen that sometimes variables are not incremented every 1s. I am talking about that. One code is cleaned up I will try to investigate that.
- cbiten_newest
- cbihun_newest
- cbitho_newest
- cbitth_newest
-
right.
So how can I feed micro with externall psu and at the same time debug via usb serial?
where is a jumper?
bye A.
As soon as you connect the Black Pill USB to your PC/laptop, you are feeding it 5V, which goes through a Schottky diode and then a LDO 3.3V regulator and then finally to the STM32F411. The 5V pin 40 on the Black Pill is both a (approx. 4.6V) power output (when the USB is connected) and a 5V power input (when the USB is not connected). It's not recommended to have an external +5V connected to pin 40 at the same time as the USB is connected, this is why there is a jumper in the schematic.
-
Tnx AndrewBNC,
its more clear now.
http://land-boards.com/blwiki/index.php?title=STM32_Black_Pill (http://land-boards.com/blwiki/index.php?title=STM32_Black_Pill)
Warning: The +5V pins on this board are directly connected to the +5V pin of the USB connector. There is no protection in place. Do not power this board through USB and an external power supply at the same time.
Very very clear now!!!
I have to find ways to have separate supply and serial for active debug.
is critical for me :D
maybe another couple of pin with softwareserial o not.
felixd:
Nice job with the serial, it is convenient to have uncovered data.
About the variables perhaps the function in the loop()
if (gpsWaitFix(waitFixTime))
he does not respond within 1000ms and you lose something.
But you should understand it, the buffers are reset because in else performs:
flush_ring_buffers_flag = true;
For example in my case every two / three cycles are above 1000ms:
Fix Time 1004ms
So I had to increase the variable to 2:
const uint16_t waitFixTime = 2;
In my humble opinion the parts related to PPS and GPS data should be separated.
It is true that they are correlated, but we need precise PPS,
if then the gps via serial replies in 10 seconds it is not a problem...
or in any case manageable
bye, A.
-
As reported before, I also noticed that the control of the PMW generated two corrections of the PWM-value when 10000000.000Hz is nearly achieved. The fine/croase and verifine/ultrafine control are independend from each other which is the root cause.
I rearranged the subroutine. May I ask you @AndrewBCN and the other guys playing around to review and check the same. I have limited debugging skills :-//
A declaration shall be done at the beginning or remove it from the code below; I use the same to display tendence on the display:
char trendstr[5] = " ___"; // PWM trend string
#ifdef GPSDO_PWM_DAC
void adjustVctlPWM()
// This should reach a stable PWM output value / a stable 10000000.00 frequency
// after an hour or so, and 10000000.000 after eight hours or so
{
// check first if we have the data, then do ultrafine and veryfine frequency
// adjustment, when we are very close
// ultimately the objective is 10000000.000 over the last 1000s (16min40s)
if ((cbTho_full) && (avgftho >= 9999999.990) && (avgftho <= 10000000.010)) {
// decrease frequency; 1000s based
if (avgftho >= 10000000.001) {
if (avgftho >= 10000000.005) {
// decrease PWM by 5 bits = very fine
adjusted_PWM_output = adjusted_PWM_output - 5;
strcpy(trendstr, " vf-");
}
else {
// decrease PWM by one bit = ultrafine
adjusted_PWM_output = adjusted_PWM_output - 1;
strcpy(trendstr, " uf-");
}
}
// or increase frequency; 1000s based
else if (avgftho <= 9999999.999) {
if (avgftho <= 9999999.995) {
// increase PWM by 5 bits = very fine
adjusted_PWM_output = adjusted_PWM_output + 5;
strcpy(trendstr, " vf+");
}
else {
// increase PWM by one bit = ultrafine
adjusted_PWM_output = adjusted_PWM_output + 1;
strcpy(trendstr, " uf+");
}
}
}
///// next check the 100s values in second place because we are too far off
// decrease frequency; 100s based
else if (avgfhun >= 10000000.01) {
if (avgfhun >= 10000000.10) {
// decrease PWM by 100 bits = coarse
adjusted_PWM_output = adjusted_PWM_output - 100;
strcpy(trendstr, " c- ");
}
else {
// decrease PWM by ten bits = fine
adjusted_PWM_output = adjusted_PWM_output - 10;
strcpy(trendstr, " f- ");
}
}
// or increase frequency; 100s based
else if (avgfhun <= 9999999.99) {
if (avgfhun <= 9999999.90) {
// increase PWM by 100 bits = coarse
adjusted_PWM_output = adjusted_PWM_output + 100;
strcpy(trendstr, " c+ ");
}
else {
// increase PWM by ten bits = fine
adjusted_PWM_output = adjusted_PWM_output + 10;
strcpy(trendstr, " f+ ");
}
}
else { // here we keep setting, because it is exact 10000000.000MHz
strcpy(trendstr, " hit");
}
// write the computed value to PWM
analogWrite(VctlPWMOutputPin, adjusted_PWM_output);
must_adjust_DAC = false; // clear flag and we are done
} // end adjustVctlPWM
#endif // GPSDO_PWM_DAC
-
Hi Badwater,
It seems to be correct.
I extended a little bit.
Tomorrow I also put cbTen so as to verify some behaviors to possibly implement control over time.
void adjustVctlPWM_2()
{
// This should reach a stable PWM output value / a stable 10000000.00 frequency
// after an hour or so, and 10000000.000 after eight hours or so
// check first if we have the data, then do ultrafine and veryfine frequency
// adjustment, when we are very close
// ultimately the objective is 10000000.000 over the last 1000s (16min40s)
if ((cbTho_full) && (avgftho >= 9999999.990) && (avgftho <= 10000000.010))
{
// decrease frequency; 1000s based
if (avgftho >= 10000000.001)
{
if (avgftho >= 10000000.005)
{
// decrease PWM by 5 bits = very fine
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output - 5;
Serial.print(F("VF-5 RULE 1 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " vf-");
}
else {
// decrease PWM by one bit = ultrafine
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output - 1;
Serial.print(F("UF-1 RULE 2 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " uf-");
}
}
// or increase frequency; 1000s based
else if (avgftho <= 9999999.999)
{
if (avgftho <= 9999999.995)
{
// increase PWM by 5 bits = very fine
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output + 5;
Serial.print(F("VF+5 RULE 3 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " vf+");
}
else {
// increase PWM by one bit = ultrafine
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output + 1;
Serial.print(F("UF+1 RULE 4 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " uf+");
}
}
}
else if ((cbHun_full) && (avgfhun >= 9999999.90) && (avgfhun <= 10000000.10))
{
///// next check the 100s values in second place because we are too far off
// decrease frequency; 100s based
if (avgfhun >= 10000000.01)
{
if (avgfhun >= 10000000.10)
{
// decrease PWM by 100 bits = coarse
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output - 100;
Serial.print(F("COARSE-100 RULE 5 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " c- ");
}
else {
// decrease PWM by ten bits = fine
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output - 10;
Serial.print(F("FINE-10 RULE 6 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " f- ");
}
}
// or increase frequency; 100s based
else if (avgfhun <= 9999999.99)
{
if (avgfhun <= 9999999.90)
{
// increase PWM by 100 bits = coarse
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output + 100;
Serial.print(F("COARSE+100 RULE 7 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " c+ ");
}
else {
// increase PWM by ten bits = fine
prev_adjusted_PWM_output = adjusted_PWM_output;
adjusted_PWM_output = adjusted_PWM_output + 10;
Serial.print(F("FINE+10 RULE 8 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " f+ ");
}
}
else {
// here we keep setting, because it is exact 10000000.000MHz
prev_adjusted_PWM_output = adjusted_PWM_output;
Serial.print(F("HIT RULE 9 ADJUST PWM: "));
Serial.println(adjusted_PWM_output);
strcpy(trendstr, " hit");
}
}
// write the computed value to PWM
analogWrite(VctlPWMOutputPin, adjusted_PWM_output);
gpsdatetostrings();
must_adjust_DAC = false; // clear flag and we are done
} // end adjustVctlPWM_2
change adjustVctlPWM() to adjustVctlPWM_2() in the calling function
good night all.
A.
-
Hi,
I have (finally!) :phew: released a new version of the firmware.
This is version v0.05a.
It is essentially the same as the previous v0.04h (no new functionality added), with a few small changes and fixes:
1. From this release on, compiling will require STM32 Core version 2.2.0 or later. If you have installed an earlier version of STM32 Core, it is very easy to update directly from the Arduino IDE.
2. I have (in principle) fixed the small OLED display bug after calibration that many of you noticed.
3. I have (in principle) fixed the compilation error(s) when GPSDO_MCP4725 was not defined, and this is now the default, since the recommended DAC is the 16-bit PWM.
I still have a long backlog of small changes I have made to the code, and of course I would like to merge the various excellent contributions made by various people, who I thank for their hard work and their patience of course. Credits will be mentioned in the code where applicable.
So versions v0.05b, v0.05c, etc should be coming ASAP over the next few days/weeks.
Just a question is what you guys want to see added to the firmware in priority?
-
As reported before, I also noticed that the control of the PMW generated two corrections of the PWM-value when 10000000.000Hz is nearly achieved. The fine/croase and verifine/ultrafine control are independend from each other which is the root cause.
I rearranged the subroutine. May I ask you @AndrewBCN and the other guys playing around to review and check the same. I have limited debugging skills :-//
...
I'll take a look first thing today, and as soon as possible push v0.05b with the fix to the GitHub repository.
-
Hi AndrewBNC,
thank you for your work!
It would be very useful, at least for me, to be able to insert a manual value via serial.
I cloned two commands to insert an up1000 and dp1000.
But entering a manual value would be better because faster. :D
See you soon, I think we're all testing your soft!
bye, A.
-
Hi AndrewBNC,
thank you for your work!
It would be very useful, at least for me, to be able to insert a manual value via serial.
...
That is a very good suggestion and I actually think I implemented it in an unreleased code. I am going to check what I have written and after testing I think this command will be included in version v0.05c.
-
yeah
tnx :D
-
Random idea,
How about a circuit board that you can mount the OCXO on with pin headers so it can be plugged into the peg boards for now but later when the full board is made it's more plug and play ish?
-
Random idea,
How about a circuit board that you can mount the OCXO on with pin headers so it can be plugged into the peg boards for now but later when the full board is made it's more plug and play ish?
That's actually a very good idea: to have a separate "OCXO module board", on which one could have a separate LM317T regulator, the PWM filter, decoupling capacitors, perhaps the optional buffers and sinewave filter too.
Give me a few days (weeks?) to think about a good PCB layout. But I like the idea. :-+
-
I was thinking more basic than that. Let the complicated stuff be done on the main board when it gets made.
-
At any rate it looks like I will need to make a footprint thingy for kicad as a quick google didn't show any obvious ones that fit.
-
I just uploaded to GitHub the STM32 GPSDO code Version v0.05b "Omicron". :-DD
This is almost the same as Version 0.05a (which itself was almost the same as Version v0.04h) with two small but important differences:
1. Added 2kHz test signal generator on pin PB5. If you put an oscilloscope to this Black Pill output you should see a 2kHz square wave with 3.3V logic levels. The signal can be PWM controlled by writing to the appropriate variable, see the code right at the beginning of the setup( ) function. Note this is a second PWM output completely independent and separate from the 16-bit PWM DAC used for Vctl.
2. Fixed bug in adjustVctlPWM() function which generated two overlapping adjustments when the OCXO frequency would come close to 10,000,000.000. Thanks to Badwater-Frank and all of you guys who noticed the bug, for the bug squashing and code fixes. Note that I manually merged the code as edited by Badwater which he posted here on the EEVBlog, and I haven't tested it yet. It does compile fine.
Please test at your convenience. Now that there are at least 3 or 4 different persons experimenting with the STM32 GPSDO code I have decided to release more often and each time with few and small changes to the code base, to make it easier to experiment and progress.
Btw Badwater-Frank has also posted a pull request on GitHub with his code for his very nice color LCD mod. I'll be merging his code ASAP.
-
This has a single change: it adds the "SP <number>" command to set the PWM value. The number must be between 1 and 65535.
Also, the next release v0.05d will be called "BA.2". You probably know why... :scared:
-
This has a single change: it adds the "SP <number>" command to set the PWM value. The number must be between 1 and 65535.
Also, the next release v0.05d will be called "BA.2". You probably know why... :scared:
"Don't Panic!"
- The HGTTG
-
@AndrewBCN tnx for merge :-+
Next I will ad some lines of code for an ADF4351 to generate some different frequencies stabilized by the 10MHz; here I am aiming for 50MHz and divide this by 2 to get additional 25MHz, but other frequency is possible by easily changing the initialization of the ADF4351. :-/O
This sounds a bit strange, but here comes the phase noise into picture, frequency multiplier as e.g. ICS501B are not suitable in this sense. And ...yes ... it might be easier to take a 50MHz or 100MHz QCXO. 50MHz OCXO I did not find so far and 100MHz OCXO is really expensive.
This might be interesting for HAM radio guys working QO100 with an SDR (ADALM Pluto) .... 8)
If this is interesting for "our" project I can share the code and details once the concept is tested on my side.
.... stay tuned ....
-
Good evening everyone.
I did some modifications to the code.
You can use only one circular buffer and make all the calculations on it.
probably now fit on F401 micro with [10001] buf.
If you are interested in trying let me know so let's see if it can be a way to optimize where possible.
I took a look at the 0.05C code of AndrewBNC and I see that he has already entered the features that I will then imagine it will publish.
// special 10s sampling rate data structures (work in progress)
volatile uint16_t esamplingfactor = 10; // sample 64-bit counter every 10 seconds
volatile uint16_t esamplingcounter = 0; // counter from 0 to esamplingfactor
volatile bool esamplingflag = false;
I'm curious eheh: D
Bye, A.
-
Just to keep you updated: I am working on Version v0.05d which is basically a manual merge of Badwater-Frank's SPI color LCD mod. I have here a small ST7789 200x200 SPI color LCD and as it happens it can use the same LCD libraries and almost the same code that Frank used for his ST7735 LCD, so in principle I should be able to test the SPI color LCD mod in one of my prototypes soon.
I also (in principle) managed to put all the MCP4725 I2C 12-bit DAC code inside conditional compilation. Plus a few small improvements in the code layout.
I estimate I should be able to release Version v0.05d by the end of this week. I haven't forgotten about felixd's pull request(s) and that will be for Version v0.05e (next week). I'll be taking a look at iannez's code for Version v0.05f (until the end of the month). That's the plan for now.
I also have a few fun ideas on the hardware side but unfortunately days only have 24h. :phew:
-
A friend was here today and we assembled the three major parts on to a solderless breadboard. The rest now, is interconnections. As I recall, felixd remotely programmed my STM board so all I need do is supply power and it should work. Yeah right, should.
-
So as pre-announced, I have published Version v0.05d which is essentially v0.05c + ST7735 SPI color LCD support by Badwater-Frank. :clap:
Please test when you have some time.
I am moving on to Version v0.05e which I estimate I will publish in around 10 days, unless you guys find some major bug(s) that needs urgent squashing. :wtf:
Also please for future pull requests, please base your patches on this version (v0.05d), and not on v0.04h.
Note that I have moved the setup() and loop() functions to the bottom of the source code file, so the best way to read the source code is now to read the configuration section at the top and then jump to the bottom and read the setup() and loop() code.
-
Hi,
Version v0.05e is mostly the same as Version v0.05d with a single change: I manually merged the code submitted by iannez (thank you, iannez!) to check the value input for the SP command.
The logic now is the following:
SP command:
- If no value specified (null string): set default value (set during compilation by editing the source file, I suggest once you have tested your OCXO for a few hours to edit the source and apply the value that you have reached).
- If a value was specified, but does not translate into a correct integer: atoi() returns zero and the value is rejected at the next step.
- If a value is specified, but is not in the correct range: print error message, leave PWM value unchanged.
- If a value is correctly specified, >=1 && <=65535: set PWM to the value specified.
I think that more or less covers all the possible error cases. :-/O As usual, please test when you have some time and kindly report any bugs. :-+ or :--
Moving on to Version v0.05f... :phew:
-
Hi chaps,
there is a small issue in the occurence of the calibration in the main loop:
If there is no fix at startup the calibration takes place at first place, which results in wrong frequency measurement and PWM setting.
This might take place in rare cases after the "normal" 300s warm up and GPS sill not fixed.
I suggest to move the calibration into the gps fix/no fix if statement:
if (gpsWaitFix(waitFixTime)) // wait up to waitFixTime seconds for fix, returns true if we have a fix
{
if (force_calibration_flag) docalibration(); // if we have gps fix we can start calibration
#ifdef GPSDO_BLUETOOTH
Serial2.println();
and at the end (else leg), set the PWM to a reasonable value:
// no fix, raise flush_ring_buffers_flag
flush_ring_buffers_flag = true;
strcpy(trendstr, " nof");
// no fix at iniial startup, set PWM to reasonable value
if (!force_calibration_flag) {
adjusted_PWM_output = default_PWM_output;
analogWrite(VctlPWMOutputPin, adjusted_PWM_output);
}
.... missing: substract the waiting time for initial fix from OCXO warm up time when the calibration routine is entered. If fix exeeds the warm up time we can do the calibration immediately.
-
Hi chaps,
there is a small issue in the occurence of the calibration in the main loop:
If there is no fix at startup the calibration takes place at first place, which results in wrong frequency measurement and PWM setting.
...
Hi Badwater,
In principle the calibration procedure waits until there is a fix and the PPS pulse is available. This wait is achieved with a single line of code, here:
// make sure we have a fix and data
while (!cbTen_full) delay(1000);
Since cbTen_full is only true if we have a fix and a PPS from the GPS, the calibration procedure will wait for as long as needed and only run when there is a fix.
Do you agree or am I forgetting something?
-
Hi AndrewBCN,
... may be .... ;)
ver 0.05e
initial value:
volatile bool force_calibration_flag = true; // indicates GPSDO should start calibration sequence
Main loop, first if clause ... this is the only one call of docalibration subroutine ... GPS fix is nested later ...
void loop()
{
serial_commands_.ReadSerial(); // process any command from either USB serial (usually
// the Arduino monitor) xor Bluetooth serial (e.g. a smartphone)
if (force_calibration_flag) docalibration(); else
if (tunnel_mode_flag) tunnelgps(); else
if (gpsWaitFix(waitFixTime)) // wait up to waitFixTime seconds for fix, returns true if we have a fix
{
#ifdef GPSDO_BLUETOOTH
Do you agree or am I slipping something?
BTW:
if (!force_calibration_flag) {
adjusted_PWM_output = default_PWM_output;
analogWrite(VctlPWMOutputPin, adjusted_PWM_output);
is not needed in the no-fix leg, because it is done in setup ... sorry, over engineered .... :palm:
-
I have made some progress. I installed the GPS receiver on the proto board and connected the antenna. Looking at the PPS output, I see a pulse of a few volts and about 120 ms duration. Connecting this to my counter, I measure 1 second to an accuracy of about 9 digits.
Next step is to wire up the arduino and OCXO and such to see if the OCXO can be disciplined. Lots of jumpers and a few components.
Wish me luck, guys!
-
Outstanding Bob!
Great progress. Keep at it.
Neal
-
Great work Bob!
it's all downhill now :)
-
I hooked up the OCXO and compared it to the counter time base. With a variable power supply I adjusted it for a stationary Lissajous pattern; it took about 2.48 V input for that.
So it appears all that remains is to connect the arduino. I have it installed on the board so I am faced with the tedious job of pushing wires through holes in hopes of not making an error nor leaving any out. There are a few resistors and capacitors, which I have.
The GPS receiver appears to be working well. When I apply power, the LED comes on for a second or two and then begins flashing once per second; the antenna is sitting on my bench.
I found a couple of project boxes into which this whole contraption may fit. I'll have to drill holes for power and output and antenna.
Actually my needs can be served by what I already have working. I measure the 1 PPS period and adjust the counter time base for exact count of 10,000,000.0 microseconds and I have my counter calibrated to within its resolution capabillity. I could also measure my rubidium standard to verify that all is synchronized. However, I can't stop here, since it's not that much more to do.
The main problem is patience, and keeping track of what I have done and what remains to be done. My main uncertainty is whether the arduino will in fact discipline the OCXO. That remains to be seen.
-
Hi Bob,
You have to check first that Blackpill (not Arduino!) is counting well.
You see under serial the voice:
64-Bit Counter: 45372829648 <== incremental number +~ 10mhz each cycle.
And then the current frequency:
Frequency: 10000000 Hz <= could be different obviously.
This is the first thing to do.
bye, A.
-
iannez, I don't understand your instructions.
-
Hi Bob,
- You simply need to connect the USB to Blackpill
- start the IDE of Arduino
- open the serial monitor
- check that the counter is advancing.
-
You show me four steps but I only understand how to do the first one.
-
I've been trying to adapt and revise your code to build this using an Feather STM32F405 from Adafruit. I've adapted the code to utilize what I think are appropriate pins on the Feather. I'm running the Arduino IDE and I've selected the STM32 under Tools tab. I can run other simple code on it such as 'Blinky,' so it's not a DFU issue. I've run into some difficulties. It seems that the Feather lacks an ETR alternate function. I also get this error repeatedly upon compiling:
"c:/users/lavam/appdata/local/arduino15/packages/stm32/tools/xpack-arm-none-eabi-gcc/9.2.1-1.1/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: sketch\GPSDO.ino.cpp.o: in function `getUBX_ACK(unsigned char*)':
GPSDO.ino.cpp:(.text._Z10getUBX_ACKPh+0xc0): undefined reference to `Serial1'
I'm wondering if this is a fool's errand. Maybe I should just wait on the Blackpill.
Is it possible to adapt this code to a Feather STM32 or should I give up? I'm a coding amateur but not a total neophyte. thanks
-
I've been trying to adapt and revise your code to build this using an Feather STM32F405 from Adafruit.
...
Is it possible to adapt this code to a Feather STM32 or should I give up?
I am not sure whether it's possible, but in any case in my opinion it's just not worth it. The Adafruit Feather STM32F405 costs $40 + shipping, the STM32F411CEU6 Black Pill cost around $10 + shipping (used to be $5, btw). You are better off buying the Black Pill and using the software as is rather than spending days or weeks to adapt the original code for another MCU development board.
-
Here is my state of building. I am making progress.
-
Somebody ought to buy you some new alligator clips for your birthday. :-DD
-
I have run into a snag. On the schematic diagram there are two terminals marked and no place for them to go.
Vphase
picARM
I have everything else connected but there is no control voltage being fed to the OCXO.
-
A small update, Version v0.05f. I still have to merge a lot of excellent code from tic226n, felixd, Badwater-Frank, iannezsp.
- Added missing Bluetooth OCXO warmup messages.
- OCXO warmup now a separate function from calibration. This was an excellent suggestion from iannez.
- Added countdown for calibration (only reported on USB serial for now).
- Added selectable and configurable calibration countdowns (15s in FastBootMode or 60s normal), was 15s before. This is per step, calibration requires two steps so double this time to complete calibration.
- A few comments improved / clarified.
Many thanks to iannez, this update is basically a manual merge of his latest excellent pull request + a few additions of my own.
Please test when you have the time!
-
Good evening everyone!
Great job AndrewBNC ;D
I'll do tests as soon as possible
bye, A.
-
Hello everyone!
The release seems correct in its operation.
go on ;D
a question...
As written in the define:
//define GPSDO_PICDIV // generate a 1.2s synchronization pulse for the picDIV
Does the pulsation make 1.2s?
shouldn't it be 1s precisely?
bye, A.
-
Hello everyone!
The release seems correct in its operation.
go on ;D
a question...
As written in the define:
//define GPSDO_PICDIV // generate a 1.2s synchronization pulse for the picDIV
Does the pulsation make 1.2s?
shouldn't it be 1s precisely?
bye, A.
Hi iannez,
According to the picDIV documentation http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm) the synchronization pulse can be any length > 1s. So this feature will implement a pulse approximately 1.1~1.2s. But note that this is not implemented yet (in the GPSDO software). I will work on this feature for Version v0.06a and later, I think.
-
Hi AndrewBNC
I saw that you're slowly implementing.
Mine was just curiosity because I thought the utility was a precise PPS per second, in the case of Gpsdo.
As soon as I can order some components I try too.
They also tried with the right CD74HC390E dividers for tests on various frequencies.
The problem is that I have no instrumentation to check in detail ...
Bye, A.
-
Apparently nobody has an answer to my question regarding the diagram. I'd like to get this thing working already.
-
bob91343, here you are ...
Vphase
picARM
... not needed ....
I have everything else connected but there is no control voltage being fed to the OCXO.
This I answered a few posts back to you:
You need to populate R2, R3, C4, C5 and connect as per schematic. Connect vctrl to vadj (OCXO) this can be seen on schematic page 1. Do not populate the jumper and DAC stuff, just direct connect the junction R3/C5 to the control/adjust of the OCXO.
-
Thank you Badwater! I will take your advice and see what happens.
-
I'm having problems updating to STM32 core version 2.2.0 using Arduino IDE.
After inserting the URL "https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/2.2.0" into File->Preferences>Additional Board Manager URL, I'm still not able to find any STM32 core versions under Tools>Board Manager.
I've tried all of the URL links included in this thread to no avail.
Any help updating to stm32 core version 2.2.0 much appreciate.
Thanks
Instantcrow
-
figured it out somehow. disregard
-
...
After inserting the URL "https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/2.2.0" into File->Preferences>Additional Board Manager URL
...
Correct menu option, but wrong URL.
This is the correct URL :-+
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
As explained in this page, with screenshots and all: https://github.com/stm32duino/wiki/wiki/Getting-Started
;)
-
Have this working for the most part. The onboard blue LED is blinking about 1/sec and the yellow LED is as well.
However, my ssd1306 OLED display is blank. I know it's wired correctly as I can display graphics with other demo programs.
Any common errors with getting the OLED to work? I'm wondering if the address is wrong...my display needs address of 0x3D.
instantcrow
-
Have this working for the most part. The onboard blue LED is blinking about 1/sec and the yellow LED is as well.
However, my ssd1306 OLED display is blank. I know it's wired correctly as I can display graphics with other demo programs.
Any common errors with getting the OLED to work? I'm wondering if the address is wrong...my display needs address of 0x3D.
instantcrow
This is why we have the serial monitor. What does it tell you?
-
Right. I missed that important function! I have every option installed other than bluetooth and ina219.
Here is what serial monitor shows. Appears to hang up and sticks here for over fifteen minutes:
07:03:54.141 -> Now sending UBX commands to GPS
07:03:54.141 -> Setting u-Blox M8 receiver navigation mode to stationary:
07:03:54.141 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
07:03:54.141 -> UBX command sent, waiting for UBX ACK...
07:03:54.141 -> * Reading ACK response: B5625120624325B (SUCCESS!)
07:03:54.328 -> Success: UBX ACK received!
07:03:54.703 -> AHT10 found
07:03:54.797 -> GPSDO Starting
07:03:54.797 ->
-
Right. I missed that important function! I have every option installed other than bluetooth and in .....
Carefully check all #defines!
Do only enable these which you have in your HW setup. E.g. if you have OLED display, do NOT enable LCD ...
-
...
I have every option installed other than bluetooth and ina219.
...
Please copy paste the configuration section as you compiled it, and list the hardware you have. Definitely not every option should be enabled, as Badwater explained.
On the other hand, we already know that your GPS module is wired correctly, because it responded correctly to the UBX command. ;)
-
Here's my config:
#define Program_Name "GPSDO"
#define Program_Version "v0.05f"
#define Author_Name "André Balsa"
// Debug options
// -------------
#define FastBootMode // reduce various delays during boot
#define TunnelModeTesting // reduce tunnel mode timeout
// Hardware options
// ----------------
// #define GPSDO_STM32F401 // use an STM32F401 Black Pill instead of STM32F411 (reduced RAM)
#define GPSDO_OLED // SSD1306 128x64 I2C OLED display
// #define GPSDO_LCD_ST7735 // ST7735 160x128 SPI LCD display
// #define GPSDO_LCD_ST7789 // ST7789 240x240 SPI LCD display
// #define GPSDO_MCP4725 // MCP4725 I2C 12-bit DAC
#define GPSDO_PWM_DAC // STM32 16-bit PWM DAC, requires two rc filters (2xr=20k, 2xc=10uF)
#define GPSDO_AHT10 // I2C temperature and humidity sensor
//#define GPSDO_GEN_2kHz_PB5 // generate 2kHz square wave test signal on pin PB5 using Timer 3
#define GPSDO_BMP280_SPI // SPI atmospheric pressure, temperature and altitude sensor
// #define GPSDO_INA219 // INA219 I2C current and voltage sensor
// #define GPSDO_BLUETOOTH // Bluetooth serial (HC-06 module)
#define GPSDO_VCC // Vcc (nominal 5V) ; reading Vcc requires 1:2 voltage divider to PA0
#define GPSDO_VDD // Vdd (nominal 3.3V) reads VREF internal ADC channel
#define GPSDO_CALIBRATION // auto-calibration is enabled
#define GPSDO_UBX_CONFIG // optimize u-blox GPS receiver configuration
#define GPSDO_VERBOSE_NMEA // GPS module NMEA stream echoed to USB serial xor Bluetooth serial
// #define GPSDO_PICDIV // generate a 1.2s synchronization pulse for the picDIV
Hardware:
stm32f411 black pill weact
BMP280
ssd1306 oled
aht10
ublox neo-m9n
yellow led
CIT OCXO
PWM DAC with RC filter as described in circuit
--------------------
FWIW: I've built several circuits in my life, and am quite comfortable in wiring, etc. Nonetheless I am human so it is possible that I made circuit error, so will continue to review. My OCXO is warm, the GPS PPS led is blinking, and every piece of hardware is powered up.
Tnx agn,
instantcrow
-
If I disconnect the OCXO 10mhz output from circuit, I get this:
11:02:15.396 -> Now sending UBX commands to GPS
11:02:15.396 -> Setting u-Blox M8 receiver navigation mode to stationary:
11:02:15.396 -> B562624240FFFF23000010270050FA0FA06402C100001027000000004953
11:02:15.396 -> UBX command sent, waiting for UBX ACK...
11:02:15.396 -> * Reading ACK response: B5625120624325B (SUCCESS!)
11:02:15.443 -> Success: UBX ACK received!
11:02:15.771 -> AHT10 found
11:02:15.864 -> GPSDO Starting
11:02:15.864 ->
11:07:31.397 ->
11:07:31.397 -> Warming up 15s
11:07:32.428 ->
11:07:32.428 -> Warming up 14s
11:07:41.358 ->
11:07:41.358 -> Warming up 13s
11:07:42.389 ->
11:07:42.389 -> Warming up 12s
11:07:43.411 ->
11:07:43.411 -> Warming up 11s
11:07:44.395 ->
11:07:44.395 -> Warming up 10s
11:07:45.426 ->
11:07:45.426 -> Warming up 9s
11:07:46.455 ->
11:07:46.455 -> Warming up 8s
11:07:47.439 ->
11:07:47.439 -> Warming up 7s
11:07:48.460 ->
11:07:48.460 -> Warming up 6s
11:07:49.491 ->
11:07:49.491 -> Warming up 5s
11:07:50.475 ->
11:07:50.475 -> Warming up 4s
11:07:51.504 ->
11:07:51.504 -> Warming up 3s
11:07:52.488 ->
11:07:52.488 -> Warming up 2s
11:07:53.510 ->
11:07:53.510 -> Warming up 1s
11:07:54.494 ->
11:07:54.494 -> Calibrating...
Then it hangs up again after reinserting OCXO output back into circuit.
-
The configuration is absolutely correct :-+ and we know the GPS module is correctly wired. Also the AHT10 is correctly recognized, so that would rule out any major problem with the I2C bus. I would check the SPI bus wiring (Black Pill to BMP280) and the VCC/VDD connections to the various modules.
If you are not getting the OCXO warmup and calibration countdown messages on the serial monitor, that would indicate there is a problem before you get to the calibration routine. And actually even before that, since the i2C OLED is initialized in the setup routine with the program name and version. I am scratching my head because you are not even getting the OCXO warmup countdown messages on the serial monitor. :-//
EDIT: OK, so if you disconnect the OCXO output you do get to the warmup countdown.
So that suggests there is possibly a problem with your OCXO output or wiring or power (it needs 5V @ 600mA during warmup). Do you have an oscilloscope to check what it's putting out? You should see a TTL-level 10MHz squarewave. See my first posts in this thread, I posted a picture of the OCXO output. Also eventually if you have too much ringing, put a 100R resistor in series with the OCXO output.
-
I have done all that and am getting a nice 10 MHz square wave from the OCXO. There is no control voltage being fed to it. Is there a startup procedure for the black pill? Pressing RESET and so on? The 10 MHz reads about 20 Hz low. The GPS receiver is getting a signal and pulsing 1 per second.
-
Prior to building circuit, I tested the CTI OCXO on my oscilloscope, and it put out a nice square 10Mhz wave. I'll check again with my scope now that it is in circuit.
I've been running power off of my laptop USB, so might have a low current. The OCXO definitely gets warm if not hot, though.
I'm wondering if the SSD1306 OLED serial address is incorrect for my particular model (StemmaQT adafruit ssd1306 oled). Where in the code is the I2C serial address defined for OLED? I couldn't find it.
great project, I'm really enjoying making it work. I never was able to get it to work with a Feather STM32f405, but was able to pick up a Black Pill.
InstantCrow
-
I have every option installed other than bluetooth and ina219.
INA226 is a nicer chip. Just saying.
-
Hi Istantcrow,
The line that sets the I2C address of the oled is
In the setup() function at the end of the script, before the void().
you have to insert in the brackets in the line:
disp.begin();
of the code block:
#ifdef GPSDO_OLED
// Setup OLED I2C display
// Note that u8x8 library initializes I2C hardware interface
disp.setBusClock(400000L); // try to avoid display locking up
disp.begin(); // <======= INSERT HERE YOUR i2c CODE
disp.setFont(u8x8_font_chroma48medium8_r);
disp.clear();
disp.setCursor(0, 0);
disp.print(F(Program_Name));
disp.print(F(" - "));
disp.print(F(Program_Version));
#endif // OLED
Your exact ID that detects using this script:
#include <Wire.h>
void setup()
{
Wire.begin();
Serial.begin(9600);
while (!Serial); // Leonardo: wait for serial monitor
Serial.println("\nI2C Scanner");
}
void loop()
{
byte error, address;
int nDevices;
Serial.println("Scanning...");
nDevices = 0;
for(address = 1; address < 127; address++ )
{
// The i2c_scanner uses the return value of
// the Write.endTransmisstion to see if
// a device did acknowledge to the address.
Wire.beginTransmission(address);
error = Wire.endTransmission();
if (error == 0)
{
Serial.print("Appareil I2C trouve a cette adresse 0x");
if (address<16)
Serial.print("0");
Serial.print(address,HEX);
Serial.println(" !");
nDevices++;
}
else if (error==4)
{
Serial.print("Erreur inconnue a cette address 0x");
if (address<16)
Serial.print("0");
Serial.println(address,HEX);
}
}
if (nDevices == 0)
Serial.println("Aucun appareil I2C trouve\n");
else
Serial.println("Fin\n");
delay(5000); // wait 5 seconds for next scan
}
bye, A.
-
Almost! Ran the I2C scanner code, got 0x3D which matches what is known about my SSD1306 oled.
I added code as you suggested:
#ifdef GPSDO_OLED
// Setup OLED I2C display
// Note that u8x8 library initializes I2C hardware interface
disp.setBusClock(400000L); // try to avoid display locking up
disp.begin(0x3D);
disp.setFont(u8x8_font_chroma48medium8_r);
disp.clear();
Returned this error:
C:\Users\lavam\Documents\Arduino\STM32-GPSDO-main\software\GPSDO\GPSDO.ino: In function 'void setup()':
GPSDO:1931:18: error: no matching function for call to 'U8X8_SSD1306_128X64_NONAME_HW_I2C::begin(int)'
1931 | disp.begin(0x3D);
| ^
In file included from C:\Users\lavam\Documents\Arduino\STM32-GPSDO-main\software\GPSDO\GPSDO.ino:220:
C:\Users\lavam\Documents\Arduino\libraries\U8g2\src/U8x8lib.h:232:10: note: candidate: 'bool U8X8::begin()'
232 | bool begin(void) {
| ^~~~~
C:\Users\lavam\Documents\Arduino\libraries\U8g2\src/U8x8lib.h:232:10: note: candidate expects 0 arguments, 1 provided
C:\Users\lavam\Documents\Arduino\libraries\U8g2\src/U8x8lib.h:237:10: note: candidate: 'bool U8X8::begin(uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint8_t)'
237 | bool begin(uint8_t menu_select_pin, uint8_t menu_next_pin, uint8_t menu_prev_pin, uint8_t menu_up_pin = U8X8_PIN_NONE, uint8_t menu_down_pin = U8X8_PIN_NONE, uint8_t menu_home_pin = U8X8_PIN_NONE) {
| ^~~~~
C:\Users\lavam\Documents\Arduino\libraries\U8g2\src/U8x8lib.h:237:10: note: candidate expects 6 arguments, 1 provided
exit status 1
no matching function for call to 'U8X8_SSD1306_128X64_NONAME_HW_I2C::begin(int)'
Will continue to plug away but not sure how to parse this out.
On other fronts, my CTI OXCO in the GPSDO circuit puts out the following waveforms on my scope. One with a 220ohm resister, one without. The ringing seemed minor to begin with.
-
try this before disp.begin()
u8x8.setI2CAddress(0x3D);
disp.begin();
...
bye,A.
-
also try
disp.setI2CAddress(DISPLAY_I2C_ADDRESS * 2)
bye, A.
-
returned:
GPSDO:1931:3: error: 'u8x8' was not declared in this scope
1931 | u8x8.setI2CAddress(0x3D);
| ^~~~
exit status 1
'u8x8' was not declared in this scope
-
Two things:
1. the disp.begin() function does not take any parameters, so disp.begin(0x3D) is incorrect. Check the u8x8 manual here: https://github.com/olikraus/u8g2/wiki/u8x8reference
You can try a different constructor.
Please take a picture of your OLED module with its pinout and post it here.
2. You have a problem with your OCXO, or it's wired incorrectly, or it's not getting the required power, or you are overloading its output with a capacitor. You definitely should not get a triangular waveform.
If the STM32 does not get a proper 10MHz input, then the counter does not advance and the GPSDO simply won't work. Please make sure you get a 10MHz squarewave with the proper amplitude.
-
Got it.
This line:
disp.setI2CAddress(DISPLAY_I2C_ADDRESS * 2)
fixed the OLED display.
In order to start the warm up timer, I had to disconnect the OXCO. Then it just hangs in calibration mode. Probably because of aforementioned waveform problem.
Will work on this.
Thanks everyone.
instantcrow
-
2. You have a problem with your OCXO, or it's wired incorrectly, or it's not getting the required power, or you are overloading its output with a capacitor. You definitely should not get a triangular waveform.
If the STM32 does not get a proper 10MHz input, then the counter does not advance and the GPSDO simply won't work. Please make sure you get a 10MHz squarewave with the proper amplitude.
I'm stumped. It's a weird waveform for this OCXO. I'm using CTI OSC5A2B02 OCXO, and their datasheet indicates they're square wave. But, alas, they're from Ebay so who knows. I did capture the wave on the scope with just 5V and no other circuit components. Must be fried...but have to wonder what would cause square wave to degrade to triangular wave.
Will have to source a better OCXO. hard to trust ebay.
-
...
I've been running power off of my laptop USB, so might have a low current.
...
Did you connect the OCXO Vcc to the +5V pin on the Black Pill? That's a no-no.
Please take out your multimeter and check the voltage across Vcc and GND for your OCXO. You should have 5V +/- 5%, but I suspect you have much less than that during OCXO warmup, with possibly a ton of noise too.
-
...
I'm using CTI OSC5A2B02 OCXO,
...Must be fried
...
These things are pretty tough, so unless you supplied it with 12V accidentally or shorted its output, it should still be good. Just give it a separate 5V (not from your laptop USB !) and check its output waveform with your scope, it should be back to a nice squarewave. Just wondering, what scope are you using and what is its bandwidth, and the bandwidth of the probes?
-
All the waveforms I’ve shown were using 5V and 5 amp wall wart with usb to black pill. I was using the 5V pin on black pill to power the ocxo. Oops.
Using a tektronix 475 scope. 200Mhz and my probes are good but can’t remember bandwidth.
Here is a waveform of ocxo removed from circuit and bare. using 5V DC power directly from high quality Astron DC supply. I think it’s good enough? I’ll have to wire it back into gpsdo circuit and clean up my power.
-
... I was using the 5V pin on black pill to power the ocxo. Oops.
...
That was the source of all your problems. |O If you had measured the OCXO Vcc with a multimeter you would have noticed that you were supplying your OCXO with 4V or less during warmup. :-DMM
Note that the schematic has a separate 5V@1A power supply and there is a jumper that goes to the +5V pin on the Black Pill, for that exact reason. The +5V pin on the Black Pill is a power input, not a power output.
-
Here is the note marked "Important" on the main page in the STM32 GPSDO schematic, about the 5V and 3.3V pins on the Black Pill:
-
Good morning everyone!
This line:
disp.setI2CAddress(DISPLAY_I2C_ADDRESS * 2)
fixed the OLED display.
Great news ;D
As recommended AndrewBNC, now separates the power supplies and guarantees at OCXO at least 1A / 5V.
bye, A.
-
Right on. My obvious mistake...Usually I'm building radio circuits. so the MCU's are a bit new for me. :horse:
Now that power lined up (5V at OXCO), the OLED shows version of firmware. Then it just hangs. does not start warmup procedure unless I pull OCXO output from circuit, then warm up procedure starts. Reinserting OCXO output halts the warmup procedure. If I reinsert OCXO output once calibration starts, it just hangs there forever.
I have two different CTI OCXO, and both put out same waveform. Get same results with both...
I'll keep revising...not sure if it's code, or my hardware or my wiring. :scared:
-
please report here output of serial console.
Check that the 10MHz output pin of OCXO is connected to PA15 and PPS on PB10.
Check all wirings on blackpill.
bye, A.
-
I still am not getting any OCXO control voltage from the black pill. Everything else seems to work. The OCXO is putting out a 10 MHz square wave but it's a few Hz low in frequency. The GPS receiver is putting out precisely 1 PPS. Its yellow LED is flashing once per second. The blue LED on the black pill is flashing once per second (not precisely). I have everything wired up as per the diagram.
What do I do now?
-
Here is what I have.
-
Got it to work. I had used outdated circuit diagram Ver 0.2, resulting in a reversed PPS and 10MHz pins.
:-/O
Now it works like a charm.
Instant
-
...
Now it works like a charm.
...
Well done. :clap: :clap:
Please post a few pics of your working STM32 GPSDO when you have the time.
-
Thanks again for all the help. Hopefully I can return the favor to someone
-
Andrew, are you ignoring me? I need a bit of help here but nobody has stepped up. I feel there is something awry with the black pill.
-
Andrew, are you ignoring me? I need a bit of help here but nobody has stepped up. I feel there is something awry with the black pill.
(replied to Bob by PM, to avoid polluting the thread)
-
Thanks again for all the help. Hopefully I can return the favor to someone
Looks good to me, but I am not seeing the two 10µF capacitors required by the PWM DAC. Did you use two 10nF ceramic capacitors by mistake?
-
Wow, good eye, Andrew. This is what I get with a disordered junk box.
Turns out they're 10nF capacitors; this would yield two 314Hz LPF in series. They should be 314KHz LPF, right?
Somehow it is working splendidly. Using a Leo Bodnar GPSDO as reference (I don't assume it is gold standard BTW) for my HP frequency counter, I find the STM32 GPSDO is 100% concordant with it. 100% match down to hundredths of a Hertz over several hours.
Will have to drill down as to why the LPF error is not impacting circuit in way that I can immediately discern. WIll fix and report back.
And I guess I'll be selling my Leo Bodnar GPSDO.
Instant
-
disregard my LP filter calculations...messed up the math.
What I am presently using with great results is a two pole LPF filter with cutoff frequency of 796 Hz (R=20kohm, C=0.01 uF). Somehow it's working.
WOndering how you picked the LP filter you did Andrew?
Instant
-
...
What I am presently using with great results is a two pole LPF filter with cutoff frequency of 796 Hz (R=20kohm, C=0.01 uF). Somehow it's working.
...
It's somehow working because the OCXO is modulating its 10MHz output with the remaining 2kHz ripple on Vctl, and the FLL algorithm removes that modulation. However, I do recommend you stick to the values on the schematic diagram (10µF capacitors), which will provide a "clean" DC Vctl to the OCXO. You want as much as possible to remove any ripple on the PWM Vctl, so 10µF is 1000x better than the 10nF ceramic capacitors you are using.
It doesn't make much sense to leave tens of mVs 2kHz ripple on the 16-bit PWM Vctl, which in theory has a resolution of around 5µV.
-
Good evening everyone,
I inserted some other feature in the serial screen as shown in the attached photo.
I inserted the trend on the last 10 PWM adjustments, in the square brackets the current value.
I then inserted the PPM value and the frequency drift.
Obviously you can also adapt to various LCDs.
These activities will serve to enumerate the PWM changes regarding the frequencies and then apply the variable PWM transmission over time to arrive first to maximum stability.
Otherwise you have to wait 429s (timer2 overflow) for each change of PWM, sometimes, especially initially, too long.
See you soon, A.
-
Is there secret magic to receiving the Bluetooth serial output? I enabled the Bluetooth #define in code, and I'm able to pair HC-06 to my android device running Bluetooth Serial Monitor. It connects, but no serial output is received or displayed. What might I be missing here?
Thanks
Instant
-
@AndrewBCN:
What is the latest version of the schematic, and have you considered adding a folder in your GITHUB project for the schemtic (both PDF and KiCad format) so
that interested parties can find it more easily? I "think" the current version of the schematic that I have is ver 0.2, in PDF only.
Cheers,
Neal
-
Is there secret magic to receiving the Bluetooth serial output? I enabled the Bluetooth #define in code, and I'm able to pair HC-06 to my android device running Bluetooth Serial Monitor. It connects, but no serial output is received or displayed. What might I be missing here?
Thanks
Instant
Yes, there is a tiny bit of magic: ;) Note that it's not really a secret, as it's clearly mentionned in the source code. :o
You need to flash the Bluetooth HC-06 module for a name and higher baud rate. Check the "extra" folder on GitHub, you can find the Arduino sketch for this bit of "magic" there.
-
@AndrewBCN:
What is the latest version of the schematic, and have you considered adding a folder in your GITHUB project for the schemtic (both PDF and KiCad format) so
that interested parties can find it more easily? I "think" the current version of the schematic that I have is ver 0.2, in PDF only.
Cheers,
Neal
Hi Neal, the latest schematic is version 0.6.2 and it's linked in the first post in this thread. And yes, I need to update the GitHub archive, it's on my TODO list. :o
-
I'm a neophyte...
I flashed the HC-06 config.ino file from the extras folder. I assume that means loading it via the STM32 dfu bootloader via arduino IDE. then reloading the GPSDO.ino.
Still think I'm missing something. I reviewed all the files and code for clues, but still can't receive the serial flow. though i am able to connect and pair with HC-06.
tnx
Instant
-
...
I flashed the HC-06 config.ino file from the extras folder. I assume that means loading it via the STM32 dfu bootloader via arduino IDE. then reloading the GPSDO.ino.
That is 100% correct. Well done. :-+
Still think I'm missing something. I reviewed all the files and code for clues, but still can't receive the serial flow. though i am able to connect and pair with HC-06.
...
Right now the Black Pill and the HC06 module are talking with different baudrates, that's why it's not working. You'll always be able to pair, but nothing will show on your smartphone.
When you run the HC06 flashing program, it gives you some messages on the serial monitor, to confirm (or not) the correct configuration of the Bluetooth module. What messages did you get?
-
Here is a summary of how to add the HC-06 Bluetooth interface module to the STM32 GPSDO.
Introduction
The HC-06 Bluetooth interface module is a serial-to-Bluetooth converter, costing around $5. It connects to one the various UART interfaces available on the STM32F411CEU6 MCU.
Connecting
There are four steps to connecting the STM32 GPSDO to the Bluetooth interface of your smartphone or PC:
- Wire the HC-06 module: TX, RX, Vcc and Gnd. See the STM32 GPSDO schematic diagram.
- Configure the HC-06 module baudrate and interface name and save the configuration on the HC-06 flash. This only needs to be done once. There are various ways to do that, but the simplest way is to use the Arduino sketch available in the extra folder on GitHub, which uses the BlackPill itself to configure and flash the HC-06 module. Note that you have to download this sketch to the Black Pill, which erases any previous sketch on it. When running the sketch, take note of the messages it sends on the Arduino serial monitor, which confirm (or not) if the HC-06 was correctly flashed.
- Enable the Bluetooth interface in the STM32 GPSDO source code in the configuration section, recompile and flash again the Black Pill with the GPSDO code.
- On your PC or smartphone, pair with the HC-06 Bluetooth module and launch a Bluetooth serial terminal program.
Usage
You will get exactly the same messages as on the Arduino USB serial monitor, with the advantage that you no longer need a cable or a bulky PC to connect to the STM32 GPSDO. 8)
Debugging
If you are able to pair with the HC-06 module but you are not getting any messages on the Bluetooth serial terminal on your smartphone :wtf: , the most likely cause is that the HC-06 was incorrectly configured (is not using the correct baudrate to talk to the Black Pill) during step 2 above. Just repeat step 2 until you have your HC-06 correctly configured (hint: read the source code).
-
07:26:42.600 -> Done setting HC06, turn off development board now
so it flashed to hc-06.
I'll keep trying to solve. Though I'm able to pair and connect with HC-06, I can't read any serial stream on either PC (Win 11) or Android smartphone.
thanks
Instant
-
07:26:42.600 -> Done setting HC06, turn off development board now
so it flashed to hc-06.
...
You can check whether or not it flashed the HC-06 if the Bluetooth device name has changed, and I assume in your case it didn't. :--
Every time you run the program, you must check for a proper response from the HC-06 module (a string beginning with "Response=...").
As I wrote above, read the code. If you run the sketch as-is, it will fail because it assumes the HC-06 is already set at 115200, you have to change the line
Serial2.begin(115200); // serial to Bluetooth moduleto
Serial2.begin(9600); // serial to Bluetooth module
and then set the Bluetooth interface name.
In a second step, you have to comment out the name setting part and uncomment the baud rate part.
Also note that once you have changed the baudrate to 115200, the program itself must be modified again since the HC-06 baudrate will be 115200.
Yes, it's a bit of a chicken and egg problem, :P
// Very short program just used to configure HC-06 Bluetooth modules
// for name and baud rate, using AT commands
HardwareSerial Serial2(PA3, PA2); // Serial to Bluetooth module
void setup() {
// put your setup code here, to run once:
Serial1.begin(9600); // serial to GPS module
Serial2.begin(115200); // serial to Bluetooth module
Serial.begin(115200); // USB serial
Serial.print(F("Check HC-06 module version, set baud rate to 115200 and rename to GPSDO1"));
Serial.println();
// check module version
Serial2.println("AT+VERSION"); // module should answer with HC06 version
delay(1500);
if (Serial2.available()) Serial.println("Response="+Serial2.readString());
// change BT module name
Serial2.println("AT+NAMEGPSDO1"); // change 1 to 2 or 3 or etc
delay(1500);
if (Serial2.available()) Serial.println("Response="+Serial2.readString());
// Change BT module baud rate (default is 9600)
// Serial2.println("AT+BAUD8"); // 8=115200
// delay(1500);
// if (Serial2.available()) Serial.println("Response="+Serial2.readString());
}
void loop() {
// put your main code here, to run repeatedly:
Serial.println("Done setting HC06, turn off development board now");
delay(5000);
}
-
Well, maybe I'm at my limits of understanding arduino/c++ code.
I implemented your suggestions, and I'm just getting the same message in serial monitor:
07:26:42.600 -> Done setting HC06, turn off development board now
I get no other messages.
I wonder if I'm not running serial monitor properly and am missing messages. I open the serial monitor as soon as I compile and flash in arduino IDE. The name simply won't change.
The library books on C++ seem too advanced for arduino ide. I need to learn more code...
Instant
-
Well, maybe I'm at my limits of understanding arduino/c++ code.
I implemented your suggestions, and I'm just getting the same message in serial monitor:
07:26:42.600 -> Done setting HC06, turn off development board now
I get no other messages.
I wonder if I'm not running serial monitor properly and am missing messages. I open the serial monitor as soon as I compile and flash in arduino IDE. The name simply won't change.
...
You can have the serial monitor open before you download the program to the Black Pill, or you could add a delay(10000); line of code just after the Serial.begin lines.
There are many ways to achieve the same result, just think about it calmly and I am sure you'll figure it out.
-
Regardless of serial2 baud rate (9600 vs. 115200), I get this serial message:
13:43:32.867 -> Check HC-06 module version, set baud rate to 115200 and rename to GPSDO1
13:43:49.333 -> Done setting HC06, turn off development board now
So it seems serial2 is not responding to AT commands...
I'll keep plugging away
-
it's working...but the character set must be wrong. there are hundreds from which to choose...
-
it's a baud rate discrepancy. I'll figure it out.
-
it's a baud rate discrepancy. I'll figure it out.
You are right, and it's my fault, my apologies. :rant: :o :P
In the GPSDO main program, please change:
#define BT_BAUD 57600
to
#define BT_BAUD 115200
recompile, redownload to the Black Pill.
That (in principle) should make it work. :-+
-
K. Will try that, however, with the HC-06 config.ino file, I can change name, but I can't check version or change baud rate to 115200. I'm pretty sure I'm commenting/uncommenting code correctly.
-
I'm nearly certain the AT commands AT+VERSION and AT+BAUD are not working with this particular HC-06 module (OSEPP BTM 01). AT+NAME worked on several occasions. I've tried different delay times for response, different BAUD setup rates, different V to module (both 3.3 and 5V). I was able to connect to and receive non-sense characters (due to Baud discrepancy), but now can't receive anything. I've never received responses for AT+BAUD or AT+VERSION, just "OK" with AT+NAME; was able to change name several times.
-
I'm nearly certain the AT commands AT+VERSION and AT+BAUD are not working with this particular HC-06 module (OSEPP BTM 01). AT+NAME worked on several occasions. I've tried different delay times for response, different BAUD setup rates, different V to module (both 3.3 and 5V). I was able to connect to and receive non-sense characters (due to Baud discrepancy), but now can't receive anything. I've never received responses for AT+BAUD or AT+VERSION, just "OK" with AT+NAME; was able to change name several times.
Now we are getting somewhere.
AT+VERSION also is not working with the HC-06 modules I have here, and AT+BAUD is not going to give you a "Response=..." message exactly because it changes the baudrate of the HC-06 module, so you would need to also change the baudrate of the STM32 MCU UART "on the fly", and the short program I wrote doesn't do that.
Keep trying, at some point you'll manage to match the baudrate of the HC-06 module with that of the UART of the STM32 MCU.
-
Good morning everyone!
I inserted a couple of new code lines that I think can improve data collection about the number of counts in circular buffers.
In practice, the circular buffers at 1000 and 10000 objects will be enabled to store data only after the previous buffer is full.
This serves to store data that had at least some corrections (at least 2 in the case of the 1000 buffer, 429s overflow).
So making the new data have a better deviation from the basic frequency (10MHz) and therefore during the average they will give a more precise result.
This should help you arrive first at the frequency lock.
// 1000 seconds buffer
if(cbHun_full) <= NEW IF ADDED WITH WITH ANNEXED PARENTHESIS
{
circbuf_tho64[cbitho_newest]=fcount64;
cbitho_newest++;
if (cbitho_newest > 1000) {
cbTho_full=true; // this only needs to happen once, when the buffer fills up for the first time
cbitho_newest = 0; // (wrap around)
cbTho_count++;
}
}
// 10000 seconds buffer (2 hr 46 min 40 sec)
if(cbTho_full) <= NEW IF ADDED WITH WITH ANNEXED PARENTHESIS
{
circbuf_tth64[cbitth_newest]=fcount64;
cbitth_newest++;
if (cbitth_newest > 10000) {
cbTth_full=true; // this only needs to happen once, when the buffer fills up for the first time
cbitth_newest = 0; // (wrap around)
cbTth_count++;
}
}
AndrewBNC let me know what you think and if it can be useful ;D
See you soon, A.
-
Good morning everyone!
I inserted a couple of new code lines that I think can improve data collection about the number of counts in circular buffers.
In practice, the circular buffers at 1000 and 10000 objects will be enabled to store data only after the previous buffer is full.
This serves to store data that had at least some corrections (at least 2 in the case of the 1000 buffer, 429s overflow).
So making the new data have a better deviation from the basic frequency (10MHz) and therefore during the average they will give a more precise result.
This should help you arrive first at the frequency lock.
...
AndrewBNC let me know what you think and if it can be useful ;D
See you soon, A.
Thank you Angelo.
I think it's a very good idea. :-+ Let me test it for a few days and if the results are confirmed good, I'll certainly add it to the next release on GitHub.
-
Now we are getting somewhere.
AT+VERSION also is not working with the HC-06 modules I have here, and AT+BAUD is not going to give you a "Response=..." message exactly because it changes the baudrate of the HC-06 module, so you would need to also change the baudrate of the STM32 MCU UART "on the fly", and the short program I wrote doesn't do that.
Keep trying, at some point you'll manage to match the baud rate of the HC-06 module with that of the UART of the STM32 MCU.
I can change the name every time at HC-06 BAUD 9600; however any attempt to change to any BAUD other than 9600 simply doesn't work. Iterative tests to change name following BAUD rate change don't work, only
Serial2.begin(9600); // serial to Bluetooth moduleworks to change name.
Truly stumped on the HC-06...I'll cease and desist on this forum re: Hc-06, don't want to pollute it as it's really about this fantastic GPSDO.
-Instant (at baud of 9600)
-
Hi,
Here is the datasheet for the HC-06 module (attached).
Check Section 9．AT command set
There are two commands to try, depending on how you have set the UART speed in the main GPSDO program:
AT+BAUD7 <-------- (to set 57600 baudrate)
AT+BAUD8 <-------- (to set 115200 baudrate)
If both of these fail, you can try leaving the baudrate of the HC-06 module untouched, and change the speed of the STM32 MCU UART to 9600 baudrate:
Find this line in the main program:
#define BT_BAUD 57600
And replace with:
#define BT_BAUD 9600
but that is really a last resort solution, as at 9600 baud the Bluetooth interface doesn't quite have enough bandwidth for our rather verbose GPSDO output.
-
BT_BAUD 9600 worked. But it is same as GPS BAUD, and these conflict thereby preventing a GPS fix. I guess I could change the GPS module BAUD but that opens another can of worms.
For whatever reason, this HC-06 only registers the AT+NAME command. doesn't even respond to AT. I've reviewed other forums and the datasheet. definitely a sticky wicket here.
I know AT+BAUD8 was sent from STM32 to HC-06 as the AT+BAUD8 message showed up in my smartphone serial monitor. but just passed through.
-
There appears to be a key pin that needs to go high for AT commands...I'll test it out and report back
-
...
I know AT+BAUD8 was sent from STM32 to HC-06 as the AT+BAUD8 message showed up in my smartphone serial monitor. but just passed through.
OK, so it seems your module is simply not responding to the AT+BAUD8 command. Strange. I really don't know what to say to help you at this stage. I am stumped. :o
-
Good evening everyone,
Andrewbnc a curiosity ...
Why in the calibration routine uses 3.2 in the calculation to follow?
// for 16-bit PWM
// 1.5V for PWM = 65536 X (1.5 / 3.2) = 30720 Results in Frequency F1 = 10MHz + E1
// 2.5V for PWM = 65536 X (2.5 / 3.2) = 51200 Results in Frequency F2 = 10MHZ + E2
Wouldn't it be more precise 3.3 or the VDD value?
I have for Vdd a 3.31v now.
thanks, A.
-
Good evening everyone,
Andrewbnc a curiosity ...
Why in the calibration routine uses 3.2 in the calculation to follow?
// for 16-bit PWM
// 1.5V for PWM = 65536 X (1.5 / 3.2) = 30720 Results in Frequency F1 = 10MHz + E1
// 2.5V for PWM = 65536 X (2.5 / 3.2) = 51200 Results in Frequency F2 = 10MHZ + E2
Wouldn't it be more precise 3.3 or the VDD value?
I have for Vdd a 3.31v now.
thanks, A.
That's a good question and the simple answer is that in this equation 3.1, 3.2 or 3.3 is not a critical value. But yes, you can try 3.3 or 3.31. :-+
-
OK, so it seems your module is simply not responding to the AT+BAUD8 command. Strange. I really don't know what to say to help you at this stage. I am stumped. :o
[/quote]
Using a USB/TTL converter, I was able to send AT, AT+VERSION, AT+NAME and AT+BAUD8 to the same HC-06 module. So bluetooth is now working. For reasons that are entirely opaque to me, the STM32 could not send any AT serial message other than AT+Name to HC-06. This was true for other HC-06 modules that I had on hand as well.
I'm scratching my head as to why; could it be the serial baud rate (not serial2 baud rate) in the HC06 config.ino file?
instant
-
Using a USB/TTL converter, I was able to send AT, AT+VERSION, AT+NAME and AT+BAUD8 to the same HC-06 module. So bluetooth is now working.
Well done! :-+ :clap:
As far as I know there are only two GPSDOs in the world that are connected through Bluetooth, and you have one of them. ;) :D
For reasons that are entirely opaque to me, the STM32 could not send any AT serial message other than AT+Name to HC-06. This was true for other HC-06 modules that I had on hand as well.
I'm scratching my head as to why; could it be the serial baud rate (not serial2 baud rate) in the HC06 config.ino file?
Honestly I have no idea. But I promise to investigate this when I have some time.
-
@InstantCrow:
Regarding your STM32 could not send many AT commands, and not sure why;
Have you guys considered that if the BlackPill module had a bad/cheap/china crystal,
and the clock frequency was off, then your baud rate is not the baud rate you think it is....
It might be worth checking two things here;
a. measure the frequency of the STM32 clock on board and see that it is correct.
b. verify that the 3.3volt signal levels on the STM32 rx/tx lines are matched to the logic levels on the HC-06 Bluetooth module.
(Does one require 3.3v logic and the other 5v logic? )
Just checking.
Neal
-
Ah, indeed, be careful. Some websites say to run the HC-06 on 5 volts to the VCC pin. Other web sites say 3.3 volts to VCC.
Another website cautions: The HC-06 operating voltage is between 3.3V to 5V. However, the tolerance level of RXD pin is 3.3V and not 5V. Hence, a Logic Level Converter is recommended to convert the 5v input to 3.3V.
You CAN run the HC-06 VCC pin to 3.3 volts and then it should match logic levels to the STM32. But try it and see if that works, since the schematic for the HC-06 is vague about the RX TX logic levels, and I find differing wiring diagrams online for the same HC-06 modules. One, for example, is https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf (https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf)
Hard to get a straight answer specification for this classic module :-) It will take some experimenting and measuring.
Neal
-
The data sheet you linked says 3.3V.
It also says it should work between 3.1V and 4.2V, which would be convenient because then you can just hook it up to a LiPo battery without the need for an extra buck converter or voltage regulator (such as the BQ25015 I'm currently playing with). Just a charger circuit would be enough.
But under no circumstance I would dare connecting 5V to a pin labeled 3.3V.
-
@ThinkFat:
I completely agree. And my point was that you have to figure out WHICH hc-06 module design you are holding.
Here is a schematic where VCC is 5 v input and then a 5v to 3v regulator, and then 5v pull-up on TX-TTL output.
https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf (https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf)
So again, apparently we need to figure out WHICH hc-06 design we have, and keep within it's specs.
Neal
-
Hi,
I have tested this single transistor buffer design (see attached files) for the 10MHz sinewave output from the square-to-sine converter filter and it seems to work well enough. I am using the ubiquitous TO-92 2N2222A with a measured hFE of 430. I have calculated the approximate resistor values using an online calculator found here: https://www.changpuak.ch/electronics/BJT_Buffer_Amplifier_4.php (https://www.changpuak.ch/electronics/BJT_Buffer_Amplifier_4.php)
Notes
1. There are much more sophisticated distribution amplifier designs available on the web, using high-speed opamps and surface mounted components, which will probably perform a lot better (lower output impedance) than this single-transistor buffer.
2. This buffer can also be used with the 10MHz squarewave output from the OCXO, or the 2KHz test squarewave from the MCU.
3. As usual, this is optional. Don't use it if you don't need it, but if you need it, it's there. 8)
-
I use similar buffers. Here, you have about 10k of input impedance, is that OK for your filter?
If needed, you can simply add a resistor to ground (+capacitor, if there is DC)
In fact, if you have a suitable DC level at the output of your filter (assuming your square comes from some logic, and the filter is a lowpass with series inductances), you can connect directly to the base, no cap and 15k,33k resistors.
-
I use similar buffers. Here, you have about 10k of input impedance, is that OK for your filter?
If needed, you can simply add a resistor to ground (+capacitor, if there is DC)
In fact, if you have a suitable DC level at the output of your filter (assuming your square comes from some logic, and the filter is a lowpass with series inductances), you can connect directly to the base, no cap and 15k,33k resistors.
Hi S57UUU,
I was wondering about that, and for buffering a TTL/CMOS squarewave, I fully agree that the input cap and 15k, 33k resistors are not needed. But in the case of a sinewave, don't we still need the resistors to setup a minimum current to keep the transistor in its linear region ? Btw I am still experimenting with different resistor values, but the 15k, 33k, 220 trio seems to work well for the sinewave coming out of the filter.
-
This is a emitor follower, the output voltage will be one (B-E) diode drop below the input (base). So, if your input sine does not go below 1V or so, you can connect directly, no resistors and caps.
If it goes below 1V, you need to "lift" the base with those resistors and a cap - or else use a PNP transistor - in that case, your input must not go above Vcc-1V.
-
S57UUU,
Looking at your photos of your EME setup, thatlooks like what I'd like to do when I get my ham ticket, I want to set up a 3meter dish. In my suburban backyard :) Why not?
-
Hi,
So, an important change that I will be making to the code and the schematic for the STM32 GPSDO: I am moving the BMP280 pressure and temperature sensor from the SPI bus to the I2C bus in the default configuration.
(an interesting fact from the BMP280 datasheet: it can be used with either SPI or I2C!) 8)
In terms of code, this involves just a few lines changed, and new configuration option (so one can choose to connect the BMP280 either through SPI or I2C, or not have it at all; default will be I2C).
In the schematic, it means the BMP280 sensor module will be either connected to the I2C1 bus or the SPI bus.
Also, for the temperature/humidity sensor, I have now tested both the AHT10 or AHT20 sensor modules since they are interchangeable, both work fine and there is no change at all required to the code (the same library handles both sensors). For new builds I suggest using the newer and slightly more accurate AHT20, but if you have an AHT10 don't worry, it works fine as it is.
Why these changes? Because of what I am working on right now: I am beginning tests of an SPI 1.3" TFT LCD ST7789 module (see attached images), using the code that Frank/badwater has kindly contributed to the project. I wanted to have the SPI1 bus dedicated to the LCD module, so I had to move the BMP280 module from the SPI bus to the I2C bus.
Also I am testing this new setup using an STM32F401CCU6 Black Pill, not the usual STM32F411CEU6. Why? Because the STM32F401CCU6 Black Pill is cheaper and except for the fact that it has less flash and RAM and is a little bit slower, it's a drop-in replacement for its more powerful sibling.
One last note for people who are just getting interested in building this project: I am seeing the price of components continuing to rise and the semiconductor shortage is now predicted to last until 2023/2024. So my suggestion is to get the parts you need ASAP. :scared:
If you are in Europe and are having trouble getting some parts, send me a PM and I will see what I can do.
And thanks again to Frank/badwater for his TFT color display work, it really opens a lot of possibilities for this project. If you want to add a color LCD display instead of the monochrome OLED display, this is the way to go in my opinion.
-
Hi,
I am still not completely done wiring a new prototype of the STM32 GPSDO with the ST7789 LCD display, but if you check the attached picture below, you'll notice the INA219 current sensor that measures the voltage/current/power consumption of the OCXO. It's working (finally)!
So the (as usual, optional) INA219 I2C current sensor is probably going to be implemented into the next firmware release. Its use is to monitor the power consumption of the OCXO so it can be correlated with ambient temperature and other parameters.
-
Where can one find and download the latest code for loading into the arduino?
-
Hi,
I have updated the BOM to reflect the latest prices and the changes in the schematics and latest developments, here:
https://docs.google.com/spreadsheets/d/1BZbZeLiag-d61XXe9ATuPoSe3eMOxMuYYZ0WjF3BLuA/edit?usp=sharing
I am deprecating the I2C 12-bit DAC MCP4725, for any future build the 16-bit PWM DAC has proved itself reliable and accurate and it only requires two 20k resistors and two 10µF capacitors.
Also I will soon be adding the SPI color TFT LCD display option to the schematic and the firmware, the recommended displays are based on either ST7735 or ST7789 SPI units. Unfortunately, with recent prices, these color LCD displays are much more expensive than the small OLED displays that I used initially. So I still recommend the OLED displays (or no display at all) for a simple and inexpensive build.
Lastly, I have a surprise development in the works... ;) It's inexpensive and rather flashy, >:D I'll show and tell when it's ready. :popcorn:
If you are curious, it's related to this: https://commons.wikimedia.org/wiki/File:HP_5061A_Cesium_Beam_Frequency_Standard.JPG
-
yeahhh
i m curious ;D
-
yeahhh
i m curious ;D
Patience! ;)
-
;D
Ok, here is the surprise: I connected an old school LED clock display (green, but you can have it in blue or red) to the GPSDO - with the classic 1Hz blinking colon!
Compared to the tiny text on the OLED or LCD display, this LED display is a giant (see attached picture) ! Now, you may ask, how is that related to the HP5061A Cesium Frequency Standard ? Well, the early production HP5061A's actually had a mechanical Patek Philippe clock on their front panel, the purpose of which to me is a total mystery, apart from making an already expensive piece of equipment even more expensive. Later models replaced the Patek Philippe clock with a more conventional LED clock (with red digits), but I wonder if it was synchronized to the Cesium Beam ?
In any case, there you have it, and all it takes is an extremely inexpensive TM1637 4-digit LED module, which can be had for around 4 euros including shipping! So now we have plenty of options to display some useful information from the STM32 GPSDO: USB serial, Bluetooth, small OLED, small color LCD, 4-digit LED... and more coming !
And the INA219 current sensor is now working, too. Check the OCXO voltage / OCXO current in the serial output below:
$GNGSA,A,3,08,10,22,27,32,,,,,,,,3.60,2.94,2.08*11
$GNGSA,A,3$GNRMC,203230.00,A,4833.64693,N,00746.90987,E,0.061,,200322,,,A*60
$GNGGA,203230.00,4833.64693,N,00746.90987,E,1,06,2.94,159.4,M,47.3,M,,*4A
Fix time 576mS
Uptime: 000d 00:20:14
New GPS Fix:
Lat: 48.560783 Lon: 7.781831 Alt: 159.4m
Sats: 6 HDOP: 2.94
UTC Time: 20:32:30 Date: 20/3/2022
Voltages:
VctlPWM: 2.00 PWM: 42366
Vcc: 5.01
Vdd: 3.30
OCXO voltage: 5.05V
OCXO current: 206mA
Frequency measurements using 64-bit counter:
64-bit Counter: 7750871378
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 9999999.94 Hz
1,000s Frequency Avg: 0.000 Hz
10,000s Frequency Avg: 0.0000 Hz
BMP280 Temperature = 20.6 *C
Pressure = 1033.7 hPa
Approx altitude = -15.1 m
AHT10 Temperature: 21.43 *C
Humidity: 65.65% rH
All these developments are going in the next firmware v0.05i, which I will release tomorrow. :phew: There is a new TODO list at the top of the source code, please check it out when you have some time !
-
Version v0.05i "Stop the war in Ukraine" is now available on GitHub. I am basically a pacifist, so this version is named "Stop the war in Ukraine", there has to be a peaceful negotiated solution to this conflict as soon as possible so that the Ukrainian people stop suffering this terrible situation. In my opinion sending more weapons to Ukraine and imposing more sanctions on Russia are measures that are not going to stop this war. The main victims here are the elderly and the women and children of Ukraine, and they don't care about joining NATO or territorial disputes. They need a peaceful solution ASAP.
Back to the STM32 GPSDO, this firmware version brings many, many changes and there will also be some changes to the schematics coming soon, since there is new hardware support.
- ST7789 TFT LCD SPI display initial support. This is a follow-up on the code provided by Frank/badwater which implemented support for the ST7735 LCD displays.
- BMP280 sensor on I2C bus support.
- AHT20 support.
- TM1637 4-digit LED clock display initial support. The "atomic clock" option! Very nice, easy to read and really inexpensive display. As you all know, the more blinking lights, the better. ;)
- INA219 I2C current/voltage sensor support (finally!). This is used to monitor the OCXO power usage.
- MCP4725 I2C 12-bit DAC deprecated (replaced by 16-bit PWM DAC). I will be progressively removing all the code related to the MCP4725.
- Program refactoring, better comments, various small bugs fixed. As usual, I am trying to make the program easier to understand and maintain, not only for myself but for everybody else too! :P
Available on GitHub as usual: https://github.com/AndrewBCN/STM32-GPSDO/releases/tag/v0.05i
Also I have added an Arduino sketch in the "extra" folder, lcd_test_1a.ino, purely for educational purposes. This is the code I used to test the ST7789 SPI TFT LCD, the BMP280 on the I2C bus and the AHT20, just in case anybody is curious how I work on implementing support for new hardware or testing new ideas.
The reason for this is that the main program has gotten too long for quick debugging, so at least for me, it's easier to test new ideas using a smaller, more compact code base.
-
Good evening everyone!
In my opinion sending more weapons to Ukraine and imposing more sanctions on Russia are measures that are not going to stop this war.
The main victims here are the elderly and the women and children of Ukraine, and they don't care about joining NATO or territorial disputes.
They need a peaceful solution ASAP.
Holy words AndrewBNC... I agree in everything.
Here in Italy the government was wrong with the energy transition, with the Covid and are now wrong with the war.
The life of people, their rights are not a game or software ...
I hope that all this moment that includes energy transition, pandemic and war ends really early.
We have already been divided for too long.
Returning to us have you tried some patches of some posts ago?
bye, A.
-
Good evening everyone!
In my opinion sending more weapons to Ukraine and imposing more sanctions on Russia are measures that are not going to stop this war.
The main victims here are the elderly and the women and children of Ukraine, and they don't care about joining NATO or territorial disputes.
They need a peaceful solution ASAP.
Holy words AndrewBNC... I agree in everything.
Here in Italy the government was wrong with the energy transition, with the Covid and are now wrong with the war.
The life of people, their rights are not a game or software ...
I hope that all this moment that includes energy transition, pandemic and war ends really early.
We have already been divided for too long.
Returning to us have you tried some patches of some posts ago?
bye, A.
Hello iannez,
Good question! :-+ The warmup and calibration routines are separated now, this I remember I implemented.
I confess I lost track of the other changes I implemented lately, this is why the version jumped from v0.05f to v0.05i. :-[ :palm: :rant:
I have to make a list of all the patches submitted in the last months and go through them one by one, something I'll probably do in April.
Please if you guys can take a look at the program and suggest which patches are more urgent to integrate, I'll make sure to test them ASAP.
Some of the things I plan to work on are in the TODO list at the top of the code, you can just add more items to that list. :o
-
OK, so I have been implementing the ST7789 SPI 240x240 TFT LCD display module to display more or less the same information that we have on the 128x64 OLED module and I have run into a couple of annoying issues.
1. The AdaFruit GFX library is slow. And I mean very, very slow. :--
2. If using higher resolution fonts, the pixels where the characters get displayed have to be cleared first ! The built-in font (there is just one) doesn't have this problem but it looks ugly when scaled to a normal size. :--
3. Because the LCD display needs to get updated every second and because of 1 and 2 above, there is noticeable flicker. |O
The small I2C OLED display does not have any of these problems, as it uses a much faster u8g2 monochrome library.
So I still recommend the use of the small, inexpensive I2C OLED display module for new builds.
-
Hi,
I have uploaded to YouTube a short video (1min40s) showing how I test OCXOs and picDIVs for basic functionality, without an oscilloscope or any other instrument. :-/O
https://www.youtube.com/watch?v=AZey4SuaGbA (https://www.youtube.com/watch?v=AZey4SuaGbA)
-
(https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=1448497;image)
This is my build of Lars' DIY GPSDO, the project that inspired me to create the STM32 GPSDO. Lars' DIY GPSDO project is described in this forum, here: https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/ (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/)
The main feature of Lars' GPSDO is his 1ns (theoretical) resolution TIC, which essentially translates the phase difference between the 10MHz from the OCXO and the 1PPS from the GPS receiver into a voltage that is then sampled by the Arduino ADC once per second. Using a very ingenious software phase locked loop (PLL), the frequency of the OCXO is adjusted so that the phase difference between the 10MHz from the OCXO and the 1PPS from the GPS receiver is kept constant (within the jitter limits of the GPS signal). All in all Lars' GPSDO achieves the same precision as the STM32 GPSDO, that is to say around 1x10E-9 or 1ppb or better.
I would like to point out some very important differences between Lars' DIY GPSDO and the STM32 GPSDO. Note that this is not at all a criticism of Lars' design, as I have the utmost respect and admiration for his work.
- Lars' GPSDO uses a 16MHz 8-bit AVR MCU. The STM32 GPSDO uses a 100MHz 32-bit ARM MCU.
- The AVR MCU works at 5V logic levels. The STM32F411CEU6 works at 3.3V logic levels.
- Lars' GPSDO supports only a pair of thermistors. The STM32 GPSDO supports a number of environmental sensors.
- Lars' GPSDO does not support any display. The STM32 GPSDO supports a number of different displays.
- Lars' GPSDO measures and reports the phase difference from the TIC. The STM32 GPSDO measures and reports the actual frequency of the OCXO
- Lars' GPSDO has to be configured to obtain a PLL "Lock". The STM32 GPSDO requires no configuration, it works "out of the box".
- Lars' GPSDO code has not been maintained since August 2017. The STM32 GPSDO code is being actively maintained.
- Lars' GPSDO "mixes" two 8-bit PWM outputs to obtain a 16-bit-like PWM DAC. The STM32 GPSDO uses a true 16-bit PWM output to obtain a 16-bit PWM.
- Lars' GPSDO does not interface with the GPS module. The STM32 GPSDO interfaces with and controls the GPS module.
- Lars' GPSDO is a minimal, "bare bones" GPSDO. The STM32 GPSDO is an extensible project (with for example a Bluetooth interface, a picDIV to provide a 1PPS UTC-synchronized output and a frequency counter input).
- Lars' GPSDO is unfortunately rather sensitive to electrical noise. The STM32 GPSDO works fine even with high levels of electrical noise.
All in all, I would say that Lars' DIY GPSDO is a finished project: once you build it and configure it, it works (or doesn't) and that's it. The STM32 GPSDO is very much an ongoing project and a development platform; if you are willing to write some C code, you can take it in any direction you want. The STM32 GPSDO Frequency Locked Loop (FLL) algorithm is also simpler to understand than the rather complex Phase Locked Loop (PLL) algorithm in Lars' DIY GPSDO.
-
Can someone please explain the procedure or process for measuring the stability of a 10MHz oscillator or GPSDO?
I always see people talking about their stability hitting approx +/- 1ppb (10E-9) or better. Where can I learn how
this is measured?
I am going to build the GPSDO, and apart from looking at the output on my scope and freq counter, how is the
stability measurement done?
Cheers,
Neal
-
Can someone please explain the procedure or process for measuring the stability of a 10MHz oscillator or GPSDO?
I always see people talking about their stability hitting approx +/- 1ppb (10E-9) or better. Where can I learn how
this is measured?
I am going to build the GPSDO, and apart from looking at the output on my scope and freq counter, how is the
stability measurement done?
Cheers,
Neal
Hi Neal,
Mathematically, "stability" is defined as the variance or standard deviation over a certain period of time. Translating that into more practical concepts, let's say you are measuring the frequency of the OCXO every second (as the STM32 GPSDO does and reports), and you notice that over a period of one hour, it never goes above 10,000,000.01Hz or below 9,999,999.99Hz. In other words, it stays at 10MHz +/- 0.01Hz, over a period of 1 hour. Now 0.01Hz is 1ppb in relation to 10MHz, so your GPSDO stability is 1ppb over a period of 1 hour.
You could also for example measure the stability of a standard crystal oscillator, and you would find that over one hour, most 10MHz crystal oscillators have their frequency varying by a few Hz, and they almost never deliver a precise 10MHz frequency, they are often off by 10Hz or even 100Hz.
I will soon be working on an option that makes the STM32 GPSDO into a very accurate frequency meter / counter, so people will be able to use it to investigate the accuracy and stability of various oscillators.
-
Tom Van Baak's PIC hardware-mentioned elsewhere in this thread, runs on a PIC microcontroller and outputs ASCI which can act as a high accuracy frequency counter, given an accurate 10 MHz or 1pps source. (see leapsecond.com ) It has a UART-pseudo-RS232 interface thats fairly compatible to lots of other tools.
You could likely use that . Taking care to minimize other potential sources of errors.
There are a few, but not many straightforward options out there that let you measure to leverage an accurate source to give you numerous other info or even derive other frequency clock signals of the same accuracy reliably.
We don't all have the room for the physically large HP gear that implements a 'universal counter,' etc. So the STM32 GPSDO timer may really be useful..
-
Tom Van Baak's PIC hardware-mentioned elsewhere in this thread, runs on a PIC microcontroller and outputs ASCI which can act as a high accuracy frequency counter, given an accurate 10 MHz or 1pps source. (see leapsecond.com ) It has a UART-pseudo-RS232 interface thats fairly compatible to lots of other tools.
There are a few, but not many straightforward options out there that let you leverage an accurate source to give you numerous other frequency clock signals of the same accuracy reliably.
We don't all have the room for the physically large HP gear that implements a counter, etc. So the STM32 GPSDO timer may really be useful..
Thank you for your comment. Indeed the STM32 GPSDO can optionally use a picDIV by Tom Van Baak to generate a UTC-synchronized PPS signal. I am working on this exactly these days. If you feel you would find an STM32 GPSDO useful in your lab / office, don't hesitate to put one together on a breadboard and experiment with it! And if you have any questions you are more than welcome to ask in this thread, of course.
-
I should definitely build this since I already have virtually all of the parts here now. Why not?
I just got an LEA-5T module for $4 on ebay, its not here yet. (ebay seller queens_land ) That is very good deal for a timing GPS. Its just the PCB chopped out of some other device, its going to require desoldering..
It has the sawtooth timing correction signal. Does not have the adjustable oscillator speed, I think that did not come along until the 6 version. LEA-5T is RTKlib capable though.
It can do very accurate positioning with RTKlib.
-
Hi,
Attached is a short paper describing how the STM32 GPSDO with the picDIV option and Erik's/Lars' TIC can be used to generate a UTC-synchronized PPS.
Comments, suggestions and kind criticism are welcome. :box:
I will be implementing the generation of a UTC-synchronized PPS in the STM32 GPSDO code over the coming weeks. :phew:
-
I should definitely build this since I already have virtually all of the parts here now.
...
There is a link to the BOM which I just updated in the first post in this thread.
-
Gooooood job ;D
-
Fantastic work, AndrewBCN - thank you! And thanks for your generosity as you have released everything on Github and here in this forum.
I plan to build this myself over the next weeks. :) I have ordered most of parts and I am glad to have an inexpensive uBlox M8/8 GPS Rx already up and running. Friendly hint for other users located in Germany/EU. This uBlox M8/8 GPS Rx is also available as a "BL1 Stratix GPS" receiver from amazon etc.
Allow me a newbie question, please: What if the OXCO's output frequency per se is too low? I am currently measuring a salvaged CTI OSC5A2B02 OXCO with my RACAL 1992 counter (who knows how well that holds its calibration?) and I can only pull it up to 9.9998936 MHz with the control voltage Vcont set to its max. level of 4V. :-//
Before you ask: Yes, I have read the schematics and my understanding is that this design can only pull the OXCO to its max. Vcont And that represents its max. achievable output frequency. What am I missing?
Thanks for letting me know.
Cheers,
THDplusN_bad
-
Fantastic work, AndrewBCN - thank you! And thanks for your generosity as you have released everything on Github and here in this forum.
I plan to build this myself over the next weeks. :) I have ordered most of parts and I am glad to have an inexpensive uBlox M8/8 GPS Rx already up and running. Friendly hint for other users located in Germany/EU. This uBlox M8/8 GPS Rx is also available as a "BL1 Stratix GPS" receiver from amazon etc.
Allow me a newbie question, please: What if the OXCO's output frequency per se is too low? I am currently measuring a salvaged CTI OSC5A2B02 OXCO with my RACAL 1992 counter (who knows how well that holds its calibration?) and I can only pull it up to 9.9998936 MHz with the control voltage Vcont set to its max. level of 4V. :-//
Before you ask: Yes, I have read the schematics and my understanding is that this design can only pull the OXCO to its max. Vcont And that represents its max. achievable output frequency. What am I missing?
Thanks for letting me know.
Cheers,
THDplusN_bad
Hi,
I can't say for sure, but either your OCXO is out of spec or your Racal counter needs some serious calibration. I would check two things before jumping to any conclusions:
1. Check the voltage you are supplying to the OCXO: it should be 5V +/- 1% (I personally prefer to set the OCXO supply voltage at 5.05V).
2. Allow the OCXO to warm up and run for a couple of hours.
In any case when you have the STM32 GPSDO assembled you'll be able to measure the OCXO frequency with a good degree of certainty. :-DMM
EDIT: we now know it was the Racal counter reading way too low, meaning its own frequency reference needs to be calibrated. I just want to note that in my experience, these CTI (and Isotemp and ENE) OCXO's are pretty resilient components, I have tested quite a few that are some 8 to 10 years old and so far they all worked within specs.
-
Allow me a newbie question, please: What if the OXCO's output frequency per se is too low? I am currently measuring a salvaged CTI OSC5A2B02 OXCO with my RACAL 1992 counter (who knows how well that holds its calibration?) and I can only pull it up to 9.9998936 MHz with the control voltage Vcont set to its max. level of 4V. :-//
Before you ask: Yes, I have read the schematics and my understanding is that this design can only pull the OXCO to its max. Vcont And that represents its max. achievable output frequency. What am I missing?
Thanks for letting me know.
Cheers,
THDplusN_bad
You're not missing anything. The GPSDO wants to steer the OXCO to 10MHz flat. If it cannot, because the OCXO cannot reach that frequency, it will not lock.
-
@THDplusN_bad
Since you already have that uBlox M8N up and running, presumably you've been using ucentre to test it out. If that's the case and you have a dual channel 'scope with a bandwidth of 30MHz or more to hand, you can simply program it to output a (somewhat jittery) 10MHz square wave out of its PPS line and compare it against the ocxo's output, making the question over your frequency counter's calibration moot.
The jitter may be horrible to behold but you'll still be able to compare the frequency of the ocxo against the 10MHz from the PPS pin and check that you can adjust the ocxo's frequency either side to verify whether it is still within its tuning range.
The raw 10Mpps output from the uBlox will show a modest 10 to 50mHz drift up and down over time scales of 2 to 5 minutes but will always average out to exactly 10Mpps in the longer term (from hours to years) so you can expect to see such drift with this simple test.
-
Wow - thanks for your prompt replies, Johnny B Good, thinkfat and AndrewBCN.
@Johnny B Good, I think your idea is a very good one. Confirm that I am using the ucentre software. And I have a sufficient collection of oscilloscopes to choose from (suffering from a bad case of TEA) :-DD
I am currently reading the "u-blox 8 / u-blox M8 Receiver description - Manual" ... At first look, it seems that I cannot unlock the "Timepulse" and "Timepulse 5" configuration settings, but I need to understand the specifications and the manual better.
Update: My RACAL DANA 1992 reads 9.9998966 MHz when probing the re-configured 10 MHz output from the ublox M8/8 GPS Rx, so indeed too low. Now I can use this for oscilloscope probing as proposed by Johnny B Good or use it as a reference input for the RACAL DANA 1992 counter >:D
Cheers,
THDplusN_bad
-
I spoke too soon when I have blamed my counter reading low. I had powered it up for 120 min or so, but it seems that I need to be significantly more patient with it and allow it much more warm-up time.
Sorry for the half-off-topic.
The service manual for the RACAL DANA 1992 counter calls for 72 hours of uninterrupted operation for calibration (my unit is equipped with options "02M" and "4E". The latter stands for "High stability Oven Oscillator"). I did not find any warm-up time specifications for the mentioned option 04E in the user manual. But I have used the counter's math function to measure the delta between nominal 10 MHz and the measured input frequency from the CTI OXCO at input channel A - and the difference is constantly getting lower. By 25 Hz over the past hour or so...
For these measurements, I had put the CTI OXCO into an isolating box. I am using a cardbox with some soft foam surrounding it.
I have not tried any adjustments of the counter's OXCO yet. But I noted that RACAL had used some special screws to cover the holes for the adjustment. These screws have some plastic washers in order to provide a sealed cover. See the attached photo. Interesting...
Anyway, I will be busy with other things over the next days, so I will return to this next week. Again, thank you for all the friendly pointers!
Cheers,
THDplusN_bad
-
Temperature and air drafts play a big role in OCXO stability. Were I to name the single, most important improvement to my own GPSDO, it would be "putting it in a box".
-
Hi,
So I have been asked to produce some nice ADEV plots for the STM32 GPSDO and of course I have none. :palm: :rant: :wtf:
The first step is to have an option/switch/command that will activate "Tab delimited reporting mode" vs the human-readable reporting that exists now. This is quite simple to implement (just add a boolean variable and an extra command to the command parser), but the question is, what information/fields should the STM32 GPSDO report?
I have thought of the following list for a fully configured STM32 GPSDO:
STM32 GPSDO reporting tab delimited fields
Line no. (0 if no position fix, increments by one each second if position fix)
timestamp (UTC)
uptime (days hours mins secs)
64-bit count
frequency
10s freq. avg. (one decimal)
100s freq. avg. (two decimals)
1,000s freq. avg. (three decimals)
10,000s freq. avg. (four decimals)
no. of sats
HDOP (meters)
PWM (16-bit, 1-65535)
PWM adc mov. avg. (V)
Vcc adc mov. avg. (5.0V nominal)
Vdd adc mov. avg. (3.3V nominal)
BMP280 Temp. (C)
BMP280 Atm. Pressure (hPa)
AHT20 Temp. (C)
AHT20 Humidity (%)
INA219 OCXO Voltage (5.05V nominal)
INA219 OCXO Current (2A maximum)
TIC (10-bit, 1024ns max)
What do you guys think? Am I missing anything? :o
This should allow for easy import into a spreadsheet or any other package for statistics and plots. Well, that's the idea anyways.
I also propose the two commands RD/RH to switch between Reporting in Human-readable format / Reporting in tab Delimited format.
That should not take too long to implement and will go into v0.05j after testing.
-
Announcement: iannez joining as STM32 GPSDO GitHub collaborator
As you all know - or perhaps don't -, iannez has not only built a prototype of the STM32 GPSDO, but has contributed quite a few excellent ideas and code for the firmware, and I have been exchanging with him through email and PMs.
So I was happy to invite iannez to be a GitHub collaborator for this project. What does that mean? It means iannez can now directly change the files in the repository ("git push"), without asking me - the owner of the repository - for approval for each push request. 8)
If any of you feel you also want to become collaborators, please PM me and I can send you an invitation through the GitHub website. Note that some proficiency and understanding of git is necessary.
-
This looks like an interesting project that I will have to follow.
-
Temperature and air drafts play a big role in OCXO stability. Were I to name the single, most important improvement to my own GPSDO, it would be "putting it in a box".
Hi thinkfat
What kind of box did you implement for the ocxo?
do you have any pictures?
I'm curious because I would like to try to make checks.
thanks, see you soon
PS: tnx AndrewBNC ;D
-
Temperature and air drafts play a big role in OCXO stability. Were I to name the single, most important improvement to my own GPSDO, it would be "putting it in a box".
Hi thinkfat
What kind of box did you implement for the ocxo?
do you have any pictures?
I'm curious because I would like to try to make checks.
thanks, see you soon
PS: tnx AndrewBNC ;D
I printed it out of PLA. It's really nothing special. My GPSDO is a "cape" for the Beaglebone Black. I printed a box that fits the whole PCB stack and has holes for the various connectors. It's not isolated or anything, it just keeps the temperature somewhat uniform.
-
Tnx thinkfat for the hints.
bye!
-
At this breadboard build stage, a suitably sized cardboard box will do the job just as well. You can save the time and effort or expense of a custom enclosure for the later stages of the project. :)
-
Hi,
So I have been asked to produce some nice ADEV plots for the STM32 GPSDO and of course I have none. :palm: :rant: :wtf:
The first step is to have an option/switch/command that will activate "Tab delimited reporting mode" vs the human-readable reporting that exists now. This is quite simple to implement (just add a boolean variable and an extra command to the command parser), but the question is, what information/fields should the STM32 GPSDO report?
Hi Andrew:
Your post opened the door for me to ask a "newbie" question. I am trying to learn how to measure stability of a self built GPSDO, and have been reading various
website articles. Can you really make meaningful ADEV graphs with just the TAB delimeted output data of your GPSDO itself? I was predictably ignored for asking
a question on time-nuts mailing list, but from what I am reading, it looks like the time interval counter method for measuring drift requires having a reference oscillator
that is more stable than our GPSDO device under test.
So to summarize, it seems like we could gather measurement data on phase drift between a reference oscillator that is better than our GPSDO project, and also
our DIY GPSDO project, by using a time interval counter. For connections / hook-up:
The most stable reference 10MHz feeds the time interval counter back panel 10MHZ REF input, and that stable reference also needs
to go through a picdiv (unless it already has a 1 PPS output), and the 1 PPS REF goes into the channel 1 input port of the time interval counter.
Then, the DIY GPSDO that we are testing will feed it's 1 PPS output into the time interval counter port 2.
This provides a continuous output stream of phase difference measurements that can be plotted by timelab or many other programs.
However, I am a total newbie, so I am asking all of you if the above IS the proper way to measure the performance of the GPSDO?
Also, from what I am reading, you can't get a meaningful idea of GPSDO performance by measuring like this against a second GPSDO.
The reference would need to be a NON-gps reference, such as a simple rubidium oscillator. The reason being that two GPSDO's used
for the above style measurement would simply show common-mode GPS results, and not useful data specifically about the device
under test?
Can anyone share how we can test our self-built GPSDO without spending thousands of dollars on a cessium standard?
[Of course, used rubidium oscillators can be had for under $300 USD on eBay. But they come from China, and may
or may not be working, or working well (China ebay sellers are known to dump surplus into big boxes left outdoors in
the rain, and then use welding torches to remove parts from boards, and then toss them into another big box.) So if
purchasing a rubidium oscillator on eBay, I assume I would also need to pay a calibration vendor to test it against a
known accurate/working primary standard oscillator?]
But is there another way to test, even if slightly less accurate?
Cheers,
Neal
-
Hi, so I have coded and tested the "tab delimited data output" mode and the commands to switch back and forth between this tab delimited output mode and the usual human-readable output mode for firmware version v0.05j.
This is what the tab delimited data output looks like:
84 1/4/2022 18:43:40 000d 00:12:20 3008687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 1.99 4.99 3.31 20.3 1011.0 21.13 59.60 5.06 206 0
85 1/4/2022 18:43:41 000d 00:12:21 3018687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.01 4.98 3.31 20.3 1011.0 21.13 59.62 5.05 206 0
86 1/4/2022 18:43:42 000d 00:12:22 3028687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.01 4.99 3.31 20.3 1011.0 21.12 59.62 5.05 206 0
87 1/4/2022 18:43:43 000d 00:12:23 3038687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.02 4.97 3.31 20.3 1011.0 21.14 59.57 5.05 206 0
88 1/4/2022 18:43:44 000d 00:12:24 3048687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.03 4.97 3.31 20.3 1011.0 21.14 59.60 5.05 206 0
89 1/4/2022 18:43:45 000d 00:12:25 3058687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.02 4.94 3.31 20.3 1011.0 21.14 59.61 5.05 206 0
90 1/4/2022 18:43:46 000d 00:12:26 3068687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.02 4.93 3.31 20.3 1011.0 21.14 59.58 5.05 206 0
91 1/4/2022 18:43:47 000d 00:12:27 3078687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.03 4.94 3.31 20.3 1011.0 21.13 59.63 5.05 206 0
92 1/4/2022 18:43:48 000d 00:12:28 3088687124 10000000 10000000.0 9999999.97 0.000 0.0000 7 3.61 42455 2.02 4.92 3.31 20.3 1011.0 21.14 59.63 5.05 206 0
I listed the fields in a previous post. You can switch back and forth between the two output formats with the RD (Report Delimited) and RH (Report Human-readable) commands.
I'll be uploading and releasing firmware version v0.05j in the next couple of hours. Also new are two new documentation files in the docs directory and I have manually merged iannez latest excellent patch.
-
...
Can anyone share how we can test our self-built GPSDO without spending thousands of dollars on a caesium standard?
...
Hi Neal,
Don't worry, you definitely don't need to spend tens of thousands of dollars on a caesium standard just to test a self-built GPSDO. :scared:
I suggest you read Lars' documentation "What is Lars Arduino based GPSDO Controller page 8-14.pdf" which you can find in Lars's DIY GPSDO thread here in the EEVblog. Also note that Lars' DIY GPSDO does not measure the frequency of the OCXO, it measures the TIC value which represents a phase difference. The STM32 GPSDO directly measures the frequency of the OCXO which makes things much simpler.
Lastly, I suggest you first build the STM32 GPSDO on a breadboard and get a good grasp of how it works, that will make testing much easier to understand for you later.
-
Version v0.05j "All it takes to stop the war in Ukraine is a phone call." is now available on GitHub.
Yes, all it would take to end all this suffering, elderly people losing everything they had, children and mothers having to take trains to refugee camps, towns destroyed and people dying, is a single 5 minutes phone call. Weapons manufacturers are very happy these days, but Ukrainian children and innocent people are suffering irremediable harm. We don't need heroes, we need a compromise for peace. Think about it.
Lots of changes in this firmware release:
- Added two documentation files in /docs.
- Merged iannez pull request "Better use variables/constants". Thank you, excellent work!
- Added iannez as Collaborator at top of .ino sketch file comments.
- Preliminary work on adding EEPROM emulation in Flash to save operating parameters. NEW!
- Added "tab delimited data output" mode and commands to switch back and forth between formats.
- Removed (hopefully) all remaining code related to MCP4725 12-bit DAC.
- Better comments and code formatting.
The STM32F411CEU6 MCU does not have EEPROM, but there is a library to emulate EEPROM in Flash. This will allow to save the last PWM DAC value in Flash and automatically restore it at the next power on. Hopefully I can make this work for version v0.05k. Btw I might take a couple of weeks away from the project after version 0.05k, so please post any suggestions or bug reports here as soon as possible.
Also please test the new "tab delimited data output" mode and if anyone can come up with some nice charts, I would really appreciate it.
-
Indeed, if you want to learn something about a GPSDO, you need a more stable reference, which might be difficult to obtain. But the question is, what do you want to know?
If you want to know about short term stability (for sub-second to 10 second intervals), you'd need something like a "DMTD", a very stable oscillator as a reference (not crazy stable, but better than the OCXO in your GPSDO) and an almost as good oscillator for mixing both. And a reasonable time interval counter.
If you want to learn something about its medium term behavior up to a couple of hundred seconds (or maybe thousands), a very good frequency counter with a stable reference (very good OCXO or rubidium, if you have one), something that gives you sub-Hz resolution at 1-2 second measurement intervals (e.g. HP53131A or better HP53132A) can reveal a lot (also about your reference: even a rubidium will drift).
If you have nothing but your GPSDO, well, you have at least the GPS as a long-term stable reference. Of course your OCXO is likely more stable than the GPS up to at least a couple hundred seconds, so you cannot learn a lot for shorter time intervals, because you see mostly the GPS in your plots, but you can still see something "qualitatively". And you will be able to compute the long-term drift of your OCXO.
-
Hi,
I have tested the EEPROM emulation library with a small eeprom_emulation_test_1a.ino sketch which I have now uploaded to the STM32 GPSDO GitHub repository in the /extra folder.
According to my tests the STM32 EEPROM emulation library works absolutely fine.
What does it do? Well, AVR chips have both flash and eeprom memories, but most STM32 chips only have flash. The big difference between flash and eeprom is that one can write to eeprom byte by byte, so it doesn't take too long, for example, to save a parameter in eeprom. With flash, we have to write an entire page at a time, so even if we want to save a single byte, we must read the whole page, change the byte, and then write the whole page back to flash. Also flash wears off, so there is a limited number of flash write cycles before it fails (10,000 write cycles specified for the STM32F411 and STM32F401).
The STM32 EEPROM emulation library is buffered so all the work to read and write as fast as possible is taken care of by the library.
The short program I wrote tests the EEPROM emulation library for the STM32f411 and STM32f401 Black Pill boards that are used in the STM32 GPSDO project, and I can confirm that it works fine and is quite fast: the buffer flush takes just 19ms.
This allows the STM32 GPSDO to save up to 16,000 bytes of data semi-permanently, like for example an initial PWM DAC value, so we can skip the calibration step.
So that feature will go into firmware version v0.05k that I should push to GitHub soon. EDIT: v0.05k cancelled. Next release is v0.06c around mid-May.
If you guys are interested you can try the test program yourselves, or simply take a look at it to understand how it works. :-/O
-
JOOI,
does can this cope with sudden loss of power events?
-
JOOI, does can this cope with sudden loss of power events?
If you power your GPSDO off of a high capacity battery thats charged by a battery charger periodically, you might be able to make it a continuous power supply that was resilient to power outage events over years.
I run a bunch of equipment off of a car battery including a raspberry pi that could be used to shut stuff down in a controlled way if the power goes out.
-
JOOI, does can this cope with sudden loss of power events?
Obviously not. However, if you want an uninterruptible power supply for the STM32 GPSDO, you can use a simple, inexpensive USB "power bank".
-
Good evening everyone!
I tested the "tab delimited data output" and the columns are tabulate
correctly. Great job AndrewBNC ;D
But if the frequency drops below 10MHz you create a certain confusion on video,
obviously the tab remains correct to copy and paste to Excel that is the important thing.
Perhaps with sprintf probably something improves, I take a look.
Bye A.
-
JOOI, does can this cope with sudden loss of power events?
Obviously not. However, if you want an uninterruptible power supply for the STM32 GPSDO, you can use a simple, inexpensive USB "power bank".
Ah! If only it were that simple (BTDTAGTBTS! >:(). I tried two different powerbanks, a 5 quid 4AH "Poundland" one that BigClive had favourably reviewed as being a neat 5v UPS and a 10AH one from Home Bargains for just £9.99 (25% more capacity per pound sterling) and discovered what BigClive had missed - the 10 to 20ms break in supply during the transition from wallwart power to battery power (or it may have been the other way round - either way, a major issue when powering anything using an MCU) and both types exhibited exactly the same behaviour :palm:
Since my initial plan had been to use them as a 5v UPS to power my gpsdo via a 5 to 12v dc-dc converter (the input voltage range only covered the 6 to 24v range at that time), I added a diode and resistor and a 1mF capacitor to the 5 to 12 converter to ride out the short switchover break.
This proved a lot more effective than my initial attempt using only a capacitor straight across the converter's output which simply bogged it down to 2.7v, causing corruption of the M8T's bbram contents but leaving it with a valid checksum that prevented the M8T from restoring valid defaults from the flashram. I landed up swapping out my 'faulty' M8T for one of my spares before realising that I could have saved myself the trouble if only I'd had the patience to leave it unpowered for an hour to discharge the bbram's 80mF supercap and force a reload of the defaults from the flashram (typical run time is a mere 40 to 45 minutes) :palm:
I even built this "drop out" protection into the gpsdo before realising that this only addressed this one specific issue with these UPS styled battery banks. I was still left with the OCXO's mcu assuming a literal stone cold start after every reset and turning the heater full on without checking the temperature beforehand.
I guess the programmer had assumed it would never have to cope with brief outages and took a "Shoot first - ask questions later" approach to the problem of bringing the oven up to temperature without delay after every power on reset.
This is all fine and dandy when it's part of a rack mounted Symmetricom GPSDO timing/frequency reference in a telecom setting but a bugbear when used in a diy gpsdo powered from a large choice of wallwarts that you can swap willy nilly or unplug for a minute or two to reroute the connecting cable where doing so leaves it in a state of confusion as the oven over and undershoots its target temperature for the next ten minutes or so every bleedin' time.
Long story short. The gpsdo now sports a protected 1500mAH LiPo pouch cell and a third dc-dc converter which floats the cell at 3.85v (around the 60% SoC point) which powers the 12v boost converter to power the OCXO and a 5v buck converter powering the electronics.
I really only required a few minutes of autonomy to allow painless wallwart swap outs or cable rerouting but even with just a 60% SoC, I was seeing 2 hours run time with the cheap active puck antenna. I won't see quite as long a run time with the new GNSS/RTK antenna, most likely somewhere around the 90 to 100 minute mark which is still well in excess of my original requirement of 3 to 5 minutes (or better).
It's an overkill solution but at least I can now power it directly from 5v powerbanks since the input voltage can now range from a minimum of 4.5v up to a maximum of 24 volt (steady warmed up state consumption of 1.6 to 1.7 watts, depending on the active antenna's power requirements - black start with a depleted LiPo cell requires a 10W peak maximum during the first couple of minutes).
Using one of these newer powerbanks, capable of being charged whilst charging a smartphone, or whatever, might look like a cheap way to get a 5v UPS but I suspect anyone trying to do this will suffer the same issue I'd had with the two different brands I'd tried.
-
Hello,
It's time for a fundamental change in the counting algorithm, and that is what I am going to discuss in this post. :scared:
The STM32 GPSDO is based on a Frequency Locked Loop: every second we measure the frequency of the OCXO and adjust Vctl if needed. To measure the frequency of the OCXO, we connect it to the STM32F411 and measure the number of transitions between two PPS pulses from the GPS receiver.To do so, we use a 32-bit counter which we extend to 64 bits by software. Every second, we save the value of this 64 bit counter in RAM in various ring buffers and from this information we can calculate the frequency averages.
Since we are storing the 64-bit counter values, we need 8 bytes per second, so for the 10,000s ring buffer we need 80,000 bytes.
However, we don't really need to save the 64-bit counter value, because we know it increments by 10,000,000 every second, +/- a small offset. And this small offset fits in an 8-bit integer (-127 to +127). So instead of storing 8 bytes per second, we could store 1 byte per second. We can cut RAM usage by a factor of 8.
Consequently I am scratching v0.05k: the next firmware release will be v0.06c and it will come with this new counting algorithm and various other smaller changes.
I am forced to take some 2~3 weeks off the project starting today to deal with some personal matters and then I'll be working on this new counting algorithm (and the picDIV, the TIC, the EEPROM emulation...) so I expect a release date of around mid-May for v0.06c. :phew:
-
very very good...
This way would also be solved in printing with sprintf that is boring on 64bit ... :D
bye, A.
-
In this post I will try to explain why it is difficult to determine the performance of a home build GPSDO without a "better" or "other" frequency reference.
For this explanation you need to understand what an ADEV measurement is, the ADEV measurement of my own build GPSDO is attached to this post.
Somewhat simplified the ADEV plot shows the average frequency error between two clocks plotted versus the time distance between the two measurement.
This way of plotting gives insight in the stability of the GPSDO over both short (such a 1 second) or long (such as 1000 seconds ) term.
The plot was based on one hour of data and gives insight up to 1000 seconds.
The Blue line (GPSDO vs Rb) shows the performance (or better "amount of variation" ) of the GPSDO output versus a Rubidium clock.
As you can see the blue line is at a 1e-10 level till about 100 seconds and than it starts to go down.
This tells you the frequency variation you can expect from the GPSDO versus the period of observation.
The purple line is the ADEV plot of the PPS from the internal GPS module versus the Rubidium clock.
As you can see the plot starts at 1 second at about 1e-8 and goes down a factor 10 every decade increase in time.
This tells you that for sure GPSDO can never determine its own performance for intervals below 100 seconds as there is nothing to compare with as the PPS (on a below 100 seconds timescale) is worse than the performance you are hoping to realize.
And example of a problem you may have and will be unable to detect is a small slow supply ripple caused by different amount of CPU cycles needed for the various internal tasks causing OCXO speed variations on a second timescale.
But also above 100 seconds you may have problems to determine the performance as the PPS from the GPS may easily vary over a day due to atmospheric conditions and difference in quality and amount of satellites in view.
And then there is the problem of measuring 10MHz with 1e-10 accuracy within a period of 1 second. One way to do this is to use a PLL to upconvert the 10MHz to 10GHz and count the 10GHz over 1 second.
This is not really a feasible approach. Another way is to divide the 10MHz down to 1 Hz and measure the edge of the 1Hz with 100ps accuracy. Also not very simple.
Most high resolution frequency counters therefore use a combination of a high resolution TIC (<100ps) and statistical methods to give 12 digits of accuracy using a 1 second gate time.
So yes, using only you GPSDO data output and perfect GPS reception, you will be able to make statements on the GPSDO performance over periods longer than 100 seconds but during use of the GPSDO you often want to do measurements or transmit signals locked to the GPSDO over a much shorter period and without a "better" reference and "more accurate" measurements you will not be able to really know the performance of your GPSDO.
And that is the reason why a timenut asks for an ADEV plot, what reference you have been using for the ADEV plot and what frequency measurement device you used as those thee elements determine the credibility of any statement on the performance of you GPSDO.
-
Thank you Erik for this brilliant post.
Please allow me some comments about the excellent chart you have included.
1. ADEV measurements
First, the plot of the GPS receiver PPS vs the Rubidium is exactly what is expected and any GPS receiver (assuming a good antenna and good reception of a sufficient number of satellites) will result in a similar line, sloping down and reaching 10E-13 for very long time intervals. Why? Because the 10E-13 is the stability of the atomic clocks on the GPS satellites themselves, and over 1s the PPS is inherently jittery by about 10ns or the 10E-8 that your chart shows. Since the jitter "averages out" with time we get the basically straight slope down to the stability of the atomic clocks onboard the satellites.
The other line that plots the GPSDO 10MHz clock vs the Rubidium starts at 10E-10 in your chart and that is the inherent stability of the OCXO in your GPSDO, which you can find specified in the OCXO datasheet, and is really determined by the properties of the quartz crystal (usually SC cut in OCXOs, versus the AT cut in cheaper oscillators). Since the OCXO frequency is "disciplined" by the PPS in any GPSDO, this is why the GPSDO line intercepts and then tracks the PPS line for time intervals > around 100s or so.
Again, any correctly working GPSDO with a reasonably good OCXO will show a similar line, more or less horizontal until around 100~500s when the "disciplining" kicks in, and then matching the PPS signal. There is no "fairy dust" or "secret potion" that will improve these measurements, because that's just how GPSDOs work.
Because all correctly working GPSDOs will show similar ADEV curves (and you can test any number of GPSDOs and verify this is true, because this is how they are supposed to work), when GPSDO manufacturers write the spec sheets of their GPSDOs they don't focus on ADEV measurements, but on other technical characteristics, such as the power consumption, stabilization time, holdover performance, volume (important for satellite applications), number of outputs (important for lab work), cost, etc, depending on the market they are aiming at.
In my opinion, it doesn't make any sense at all to expect any GPSDO to have any different ADEV measurements from those you show in your excellent chart, since they all work according to the same principles. That is basically the reason I didn't spend any time looking for an atomic clock nearby to measure the ADEV for the STM32 GPSDO. ADEV measurements are simply not a very good way to define the "performance" of a GPSDO.
2. Statistical methods
Also another interesting point that you mention in your post is the use of statistical methods for improving the resolution of time measurements. This is one of the strong points of the STM32 GPSDO, because it supports a number of environmental sensors as well as frequency and phase measurements, so one can collect a ton of information for statistical analysis. And the use of a powerful 32 bit ARM MCU with 512K of flash allows for the implementation of sophisticated GPSDO algorithms. As I wrote many times before in this thread, the STM32 GPSDO was always intended and designed as an Open Source experimenter platform, and it is really excellent for that, whereas almost all commercial GPSDOs are just "black boxes" that are totally useless for experimentation.
For reference, here is a good web page about AT cut vs SC cut quartz crystals and their use in OCXOs : https://www.rfwireless-world.com/Terminology/AT-cut-vs-SC-cut-quartz-crystal.html (https://www.rfwireless-world.com/Terminology/AT-cut-vs-SC-cut-quartz-crystal.html)
-
OK, so I have been implementing the ST7789 SPI 240x240 TFT LCD display module to display more or less the same information that we have on the 128x64 OLED module and I have run into a couple of annoying issues.
1. The AdaFruit GFX library is slow. And I mean very, very slow. :--
2. If using higher resolution fonts, the pixels where the characters get displayed have to be cleared first ! The built-in font (there is just one) doesn't have this problem but it looks ugly when scaled to a normal size. :--
3. Because the LCD display needs to get updated every second and because of 1 and 2 above, there is noticeable flicker. |O
The small I2C OLED display does not have any of these problems, as it uses a much faster u8g2 monochrome library.
So I still recommend the use of the small, inexpensive I2C OLED display module for new builds.
If using a prehistoric AVR, that's what you get, what do you expect from a 20MHz mcu with 90s architecture? :-DD
However, if using stm32, last year I deeply modified several libraries for the ST7789 to greatly improve performance.
Check: ST7789-STM32-uGUI (https://github.com/deividAlfa/ST7789-STM32-uGUI) for code and examples.
Based on my UGUI port (https://github.com/deividAlfa/UGUI), also made a custom version of ttf2ugui (https://github.com/deividAlfa/ttf2ugui) font converter for it.
Uses DMA for filling (Also for sending pictures), so drawing filled rectangles (Clearing the screen, too) are done very fast, limited by the spi bandwidth.
Font drawing is also optimized to avoid pixel-by-pixel drawing when possible, which creates a lot of overhead, so it first counts same-color consecutive pixels and draws them in a single operation when a different color is found, boosting the performance specially when drawing big fonts.
Another feature I added was Unicode/UTF-8 support and font stripping (Instead storing the whole charset, you can only those you need, ex. "0-9, C, F, K, º, m, s", saving a lot of space ) .
A relatively slow 72MHz stm32F103 + 135*240*16bpp SPI ST7789 gets this:
- Fill screen: 28ms
- Drawing "Hello Steve!", font 20X23: 6ms
- Drawing "Hello Steve!", font 49X57(Huge): 28ms
- Drawing 114*77*16bpp image: 8ms
That's with a 18MHz spi.
I tried reducing the prescaler to 2, overclocking the bus to 36MHz, worked perfectly fine and times halved in some cases.
If you adjust everything for 8bpp, it would be even faster
F4 series will perform way better. I've ran the screen up to 72MHz SPI clocks on a 144MHz (Overclocked) STM32F411 :D
I haven't used it for any project yet, kinda stupid considering the time I spent on it :-DD
-
Andrew, you wrote: , it doesn't make any sense at all to expect any GPSDO to have any different ADEV measurements from those you show in your excellent chart
But after measuring the performance of several iterations of my own design I have a different view
-
Thank you DavidAlfa,
Your ST7789 library optimized for the STM32 definitely sounds like it would be the ideal one to use for the STM32 GPSDO project. :-+
I'll test it when I have some time, unfortunately probably not until May.
-
Andrew, you wrote: , it doesn't make any sense at all to expect any GPSDO to have any different ADEV measurements from those you show in your excellent chart
But after measuring the performance of several iterations of my own design I have a different view
Well, I am very curious about your measurements, of course. But have you been using always the same OCXO, or a TCXO, or both ? TCXOs behave very different from OCXOs and of course different OCXOs can have different inherent stability specs (from their spec sheet), which will result in different GPSDO ADEV measurements.
For example, DOCXOs (Double Ovenized Crystal Oscillators) (usually costing 10x to 20x more than the OCXOs used in the STM32 GPSDO) have 10x bettter (1E-11) stability than OCXOs between 1 and 1000s. So if you use a DOCXO for your GPSDO you'll get improved ADEV measurements, of course. But I expect the curve would be very similar, just shifted down by one order of magnitude. I have no experience with TCXOs so I can't say anything about them.
Erik, please feel free to discuss this matter here or on the time-nuts list, as you prefer. Personally I am extremely interested by your fascinating work on GPSDOs and oscillators. :-+
-
The actual performance of the measured GPSDO is irrelevant for what I tried to say.
I've build and tested GPSDO with TCXO, OCXO and Rubidium clock's but the choice of oscillator is mostly irrelevant for what you have to do to understand the performance.
As long as you can not show an ADEV plot against a reference with known better performance you will have limited knowledge, mostly assumptions, about the performance.
And this maybe fine when you are not interested in knowing more details.
It all depends on your ambition. If you want a frequency reference of which you want to be sure that, measured over a long period say a several day's, it is on average very accurate than using the PPS pulse only for measurement can be OK.
-
The actual performance of the measured GPSDO is irrelevant for what I tried to say.
Then I did not understand what you tried to say. Could you explain?
I've build and tested GPSDO with TCXO, OCXO and Rubidium clock's but the choice of oscillator is mostly irrelevant for what you have to do to understand the performance.
Do you agree that with different oscillators, you got different ADEV curves? Could you post some ADEV curves for your GPSDOs with TCXO, OCXO and Rubidium clocks?
As long as you can not show an ADEV plot against a reference with known better performance you will have limited knowledge, mostly assumptions, about the performance.
No, I don't think this is limited knowledge, as long as you understand how a GPSDO works. What you call assumptions are in fact the upper bounds and constraints that any GPSDO designer has to deal with.
And this maybe fine when you are not interested in knowing more details.
It all depends on your ambition. If you want a frequency reference of which you want to be sure that, measured over a long period say a several day's, it is on average very accurate than using the PPS pulse only for measurement can be OK.
It's not so much a question of ambition, rather it's a question of knowing the physical limitations of the hardware. As I wrote, there is no "fairy dust" or "secret potion" that will make any GPSDO have a better ADEV than the laws of physics (the basic specs of the OCXO or other oscillator and the known jitter of the GPS PPS) allow it to. Good engineering is not magic.
You can measure a $100 GPSDO against another two $100 GPSDOs (using the three-cornered hat method) or against a $100,000 caesium frequency clock, and surprisingly you will still get a very similar, if not identical, ADEV curve, as long as you have your math correct.
-
Then I did not understand what you tried to say. Could you explain?
The first Attached ADEV shows in red the ADEV of a TCXO without being controlled. As you can see the ADEV at 100s is much worse as the previous ADEV I showed. This was due to minute temperature variation as the TCXO was not yet sufficiently thermally isolated and the supply was not perfectly stable.
The other traces are three ADEV measurements using different control loop parameters (blue, purple and green)
All three parameters sets nicely showed on the display they reached 1e-10 after some time but the the performance was rather different.
The green was over controlled. It followed the PPS too quick thus causing unwanted short term fluctuation, which where invisible on the long term averaging.
The blue was way to slow in adjusting the TCXO given the temperature and supply variations.
The pink seems better but there are some strange fluctuations above 100s and the hump around 100s is rather high suggestion the parameters are still not optimal given the measured quality of the PPS (see previous posted ADEV)
The second plot shows the absolute phase error of a synthesized PPS as it is kept in sync with the PPS of the GPS module versus the 10 second running average of the PPS of the same GPS. What you see is that these two disagreed up to 40ns. But is this good or bad? As long as you do not know the phase error of the PPS due to all kind of causes you do not know the performance of your generated PPS.
The third plot shows such an actual GPS PPS phase error. The phase of a GPS PPS can "walk away" due to less then perfect reception even though the PPS frequency seems to be still perfect.
Before I did these kind of measurements I assumed my GPSDO was perfect when it showed below 1e-10 error after some time.
Hope this helps to understand what I am trying to say.
-
I was too curious to see if my idea of what I call the "offset method" to measure the OCXO frequency would work or not, so I ended up implementing it. |O
And it works! :-+ :-DMM
It really works, and actually it works even better than the previous method of saving 64-bit counts. It is also simpler to understand, and most importantly, it uses 8x less RAM!
So I have uploaded version v0.06b which is not a release, it's just for testing purposes. It measures the frequency of the OCXO using both the previous method and the new method, and prints both measurements to USB serial:
instant_offset: 0
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.01 Hz
1,000s Frequency Avg: 10000000.013 Hz
10s offset Frequency Avg: 10000000.0 Hz
cumulten_offset: 0
100s offset Frequency Avg: 10000000.01 Hz
cumulhun_offset: 1
1,000s offset Frequency Avg: 10000000.013 Hz
cumultho_offset: 13
10,000s Frequency Avg: 0.0000 Hz
BMP280 Temperature = 20.3 *C
Pressure = 1017.2 hPa
Approx altitude = 123.0 m
AHT10 Temperature: 21.14 *C
Humidity: 57.54% rH
As we can see, the numbers are identical, in other words, the new algorithm is working fine! ;D :-+
The "normal" firmware releases will resume around mid-May with version v0.06c with the new frequency measuring algorithm fully implemented and the old algorithm removed, and many other firmware changes, new features, etc.
-
Thank you Erik, this is absolutely fascinating.
I think your first chart shows the difficulty in configuring the parameters for a proper PID loop to "discipline" a TCXO, and also shows the reason why most GPSDOs use a much more stable OCXO instead of a TCXO.
Even with proper PID loop tuning, the TCXO-based GPSDO shows much worse ADEV measurements than the OCXO-based GPSDO.
Your latest comments prompted me to add a new command to the STM32 GPSDO (in the TODO list), to manually switch on and off the GPSDO "disciplining" (in GPSDO language, to enter and exit "holdover" mode). I guess I'll have to implement that for version v0.06c which I plan to release in mid-May. :-+
Btw I am not sure I have mentioned this to you but I implemented your version of Lars' TIC using a 74HC74 instead of a 74HC4046 in his GPSDO and it works just P-E-R-F-E-C-T-L-Y! :-+ :-+ :-+
And of course I am also using your version of Lars' TIC in the phase measurement circuit in the STM32 GPSDO. I have just solved the conundrum I had to implement the AD conversion but the solution is still in my head, I still have to code it. So many things to code, too little time... :phew:
-
I think your first chart shows the difficulty in configuring the parameters for a proper PID loop to "discipline" a TCXO, and also shows the reason why most GPSDOs use a much more stable OCXO instead of a TCXO.
Even with proper PID loop tuning, the TCXO-based GPSDO shows much worse ADEV measurements than the OCXO-based GPSDO.
System design is about reaching a certain goal under the constraints set. Choosing a more stable oscillator will always make it easier to reach a stability goal, but if you have other goals, such as cost, size and power consumption life becomes more complex and the design becomes more interesting.
It is difficult to make any statement about a design being good or bad without understanding the constraints.
-
AndrewBNC one question ...
Why didn't you activate the 10000 circular buffer?
;D
bye, A.
-
AndrewBNC one question ...
Why didn't you activate the 10000 circular buffer?
;D
bye, A.
Hi,
Good question! And the answer is that the "old method" which I left active to be able to compare results, takes too much RAM. When I completely remove the "old method" data structures and code, then I will have enough RAM to activate a large "unified buffer" for the "new method". And in fact the "new method" will have frequency averages for 10s, 100s, 1000s, 10000s and 20000s (one extra bit of resolution) making readings like 10,000,000.00005Hz possible! That will be achieved with a 20,000 size unified circular buffer which only uses 20,000 bytes. The present multiple buffers which only hold information up to 10000s, use around 90,000 bytes.
So don't worry, for version v0.06c you'll have even better resolution than 10,000s! :D
-
I think your first chart shows the difficulty in configuring the parameters for a proper PID loop to "discipline" a TCXO, and also shows the reason why most GPSDOs use a much more stable OCXO instead of a TCXO.
Even with proper PID loop tuning, the TCXO-based GPSDO shows much worse ADEV measurements than the OCXO-based GPSDO.
System design is about reaching a certain goal under the constraints set. Choosing a more stable oscillator will always make it easier to reach a stability goal, but if you have other goals, such as cost, size and power consumption life becomes more complex and the design becomes more interesting.
It is difficult to make any statement about a design being good or bad without understanding the constraints.
Well, it's also difficult to make any statement about the performance of a GPSDO without understanding the constraints, as I am sure you'll agree. ;)
-
[/quote]
Hi,
Good question! And the answer is that the "old method" which I left active to be able to compare results, takes too much RAM. When I completely remove the "old method" data structures and code, then I will have enough RAM to activate a large "unified buffer" for the "new method". And in fact the "new method" will have frequency averages for 10s, 100s, 1000s, 10000s and 20000s (one extra bit of resolution) making readings like 10,000,000.00005Hz possible! That will be achieved with a 20,000 size unified circular buffer which only uses 20,000 bytes. The present multiple buffers which only hold information up to 10000s, use around 90,000 bytes.
So don't worry, for version v0.06c you'll have even better resolution than 10,000s! :D
[/quote]
Right RAM is not infinite :)
We must at least get to the 1980s accuracy...
-
...
However, if using stm32, last year I deeply modified several libraries for the ST7789 to greatly improve performance.
Check: ST7789-STM32-uGUI (https://github.com/deividAlfa/ST7789-STM32-uGUI) for code and examples.
Based on my UGUI port (https://github.com/deividAlfa/UGUI), also made a custom version of ttf2ugui (https://github.com/deividAlfa/ttf2ugui) font converter for it.
...
DavidAlfa, I took a look at your GitHub repository and the performance of your ST7789 library looks very impressive, but it's for the STM32 CUBE IDE. The STM32 GPSDO uses the Arduino programming environment and library system, so unfortunately your library is not directly applicable to the STM32 GPSDO project. :(
-
Yes... I don't do Arduino! :D
As you see most the library is unrelated to the architecture, only very few functions for drawing pixels, starting DMA transfers or sendimg raw data over spi.
How do you run stm32 DMA transfers on Arduino? No idea!
That's all you really need to make it work!
Have you tried it? Testing the demo takes very little work, just import the 411 project, modify the LCD dimension and compile!
Check the ioc for the connections.
-
...
We must at least get to the 1980s accuracy...
We'll see... ;)
-
DavidAlfa,
I'll be sure to try it when I have some time. :-+
-
This is what firmware version 0.06c (beta) reports after 13 hours uptime. If you look at the frequency averages (which are now all calculated using the "offset method"), you'll notice that there is a 0.001Hz (actually one count) disturbance, that was when I turned on a microwave oven in the same room as the GPSDO a few minutes ago to make myself some tea. Also the 20,000s frequency average has a maximum resolution of 1/20000Hz (0.05mHz or 5E-12 in relation to our 10MHz OCXO). Another change is that the "instantaneous frequency" measurement is reported in MHz if the frequency is an exact MHz multiple, and reported in Hz if not.
You can also see that the GPSDO now reports whether the OCXO is being disciplined by the GPS receiver PPS or if it is in "Holdover Mode" (meaning not disciplined, as the PWM Vctl is kept fixed at the last set value). This is also reported in the OLED display, with a small blinking "H" in the top right corner of the display when the GPSDO is operating in "Holdover Mode".
And also the INA219 sensor reports the voltage and current for the OCXO.
With "Holdover Mode" + the data from the environmental sensors + the frequency measurements, all collected using Tab Delimited reporting and processed in a spreadsheet program, we can characterize the OCXO very extensively. :-/O
(GPS data omitted)
Fix time 873mS
Uptime: 000d 13:30:21
New GPS Fix:
Lat: XX.XXXXX Lon: Y.YYYYYY Alt: 170.9m
Sats: 8 HDOP: 1.27
UTC Time: 13:18:04 Date: 7/4/2022
Voltages:
VctlPWM: 1.98 PWM: 42264 OCXO disciplining: ACTIVE
Vcc: 5.00
Vdd: 3.31
OCXO voltage: 5.01V
OCXO current: 206mA
Frequency measurements:
64-bit Counter: 486111552054
Frequency: 10 MHz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 9999999.999 Hz
10,000s Frequency Avg: 10000000.0000 Hz
20,000s Frequency Avg: 10000000.00005 Hz
BMP280 Temperature = 20.4 *C
Pressure = 1000.7 hPa
Approx altitude = 262.7 m
AHT10 Temperature: 21.50 *C
Humidity: 59.34% rH
And what you get when there are no disturbances:
Frequency measurements:
64-bit Counter: 576511552055
Frequency: 10 MHz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 10000000.000 Hz
10,000s Frequency Avg: 10000000.0000 Hz
20,000s Frequency Avg: 10000000.00005 Hz
Notice the final digit of the 64-bit counter! It changed from a "4" to a "5". So the OCXO stabilized back in frequency from the previous -1 count disturbance when I made some tea. :-+
-
Hello Team:
For those of you who have actually been building this, I have a question:
I received my STM32F411 black pill board, ver 3.1. I have tested it by compiling the blink
example in the arduino IDE and using ONLY the USB C connector for testing and power and
program download.
Next, I am starting to build the actual GPSDO project on my breadboard.
QUESTION: How are you guys dealing with breadboard power vs. USB 5v power?
It looks like, from the STM32 BlackPill schematic, that USB 5V "VBUS" will always feed,
via a diode, into the STM32 board 5v pins, and also into the board 3.3V regulator.
This means that if USB is connected, then the STM32 breadboard pins will have 5V and 3.3V
as generated from the USB cable and the STM32 blackpill 5v to 3.3v regulator.
If I also hook up a power supply on the breadboard, there is a collision or "dual source"
of voltage. Not a big problem if they perfectly match in voltage, otherwise, not sure.
So how do you prevent problems in cross-powering? Some websites caution against
having both the USB and the breadboard pin 5v supplied at the same time.
But after programming, this eevblog thread keeps talking about monitoring the STM32
serial output, which I assume is via the USB C connection? (Unless you guys are using
different programmable GPIO USART pins on the STM32, and leaving the USB-C
disconnected after programming?)
So, in summary, what is the safe way to power the black-pill module on the breadboard,
but also connect the USB to program and also monitor the blackpill serial output while
the GPSDO software is running?
Thanks,
Neal
-
The diode will avoid exactly that.
-
Neal,
As DavidAlfa wrote, that's what the (undocumented, and mentioned early in this thread) diode is there for. It's a Schottky diode btw. It's there to prevent any current from flowing back into your Laptop/PC from the BlackPill.
OK, so how do you deal with this? It's not very complicated actually. There are two possibilities:
1. You intend to always have a USB cable from your laptop/PC to the GPSDO/BlackPill USB C connector, to monitor the GPSDO using its USB serial interface. In this case, do not connect the +5V pin on the BlackPill to your breadboard +5V supply. And that's it. Simple, right? Of course, the OCXO and maybe other peripherals (the GPS receiver module) need a separate +5V supply (700mA peak current for the OCXO). See the schematic for what your should connect to +3.3V and what needs +5V.
2. You may or may not connect a USB cable from your laptop/PC to the GPSDO/BlackPill USB C connector (for example, you may want to use the Bluetooth interface). In this case, whenever the BlackPill is connected to the Laptop/PC, disconnect it from the breadboard +5V supply, and whenever it is not connected to your Laptop/PC, connect it to the breadboard +5V. This is shown as a jumper in the KiCad schematic. Again, very simple.
What happens if you accidentally connect the BlackPill to both the USB from your Laptop/PC and the breadboard power supply? Well, your laptop/PC USB interface is protected by the Schottky diode and a resettable fuse on your Laptop/PC motherboard, but your breadboard +5V supply probably doesn't have such a good protection, so let's say you could see a bit of magic smoke from it! :P :-BROKE :wtf:
-
OLED display for firmware version v0.06c (beta) showing blinking H (in upper right corner) for Holdover Mode operation:
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1457758;image)
-
One of my GPSDO's is supposed to learn how to be more accurate with time. It has its own computer implemented in a FPGA that learns what kind of conditions are the result of temperature changes, insulation, etc.
True Position.
-
Note there're two black pill versions, one with the diode, other without.
I removed it from mine because OTG wouldn't work, you need the 5V going into the USB Port, thus I replaced it with a solder bridge.
-
Neal,
As DavidAlfa wrote, that's what the (undocumented, and mentioned early in this thread) diode is there for.
….
What happens if you accidentally connect the BlackPill to both the USB from your Laptop/PC and the breadboard power supply? Well, your laptop/PC USB interface is protected by the Schottky diode and a resettable fuse on your Laptop/PC motherboard, but your breadboard +5V supply probably doesn't have such a good protection, so let's say you could see a bit of magic smoke from it! :P :-BROKE :wtf:
Thanks Andrew and DavidAlfa. I had not noticed that diode.
Now that I see it on the schematic, Andrew, I do not think you can harm anything if both the usb cable is supplying 5v and the breadboard is too. As long as you isolate the OCXO power supply, if the USB is connected and you accidentally turn off the breadboard power supply, current draw from the USB should not exceed 200ma for the STM32 and the other modules, excluding the OCXO on its own different supply of course.
And even if the breadboard supply is higher, like 5.1 volts, and the USB is lower, like 4.7 volts, the diode will block reverse current. So if we isolate other modules so the total current draw from USB on the black pill 5v pins is less than USB max spec of 200ma (low speed USB port), then no reverse current will flow, and both the breadboard supply and USB can be connected indefinitely long.
Do I have this incorrect?
Cheers,
Neal
-
Neal,
The +5V pin on the BlackPill is a power input pin, not a power output pin, as stated in the schematic. This was discussed before in this thread, check a few pages back. :horse:
Btw USB2 spec is 500mA and USB3 spec is 1A. And some motherboards and laptop USB ports can supply even more current. Even though they are (in principle) protected against shorts, I personally wouldn't take any chances. And that's the reason there is a jumper at the BlackPill +5V pin, in the schematic.
-
Anyways, the voltage difference between two different 5V supplies would be very small, perhabs 0.5V at most, so it's unlikely to cause huge currents flowing.
-
Neal,
The +5V pin on the BlackPill is a power input pin, not a power output pin, as stated in the schematic. This was discussed before in this thread, check a few pages back. :horse:
Btw USB2 spec is 500mA and USB3 spec is 1A. And some motherboards and laptop USB ports can supply even more current. Even though they are (in principle) protected against shorts, I personally wouldn't take any chances. And that's the reason there is a jumper at the BlackPill +5V pin, in the schematic.
I just did a metered experiment to prove to myself that there is no harm in powering the breadboard from a 5V benchtop supply, and ALSO leaving the USB cable connected to a computer.
I placed a USB diagnostic voltage and milliamp meter inline between the blackpill STM32 and the computer USB cable.
I also have voltage and current meters on my benchtop breadboard power supply.
Configuration of my GPSDO build is currently as follows:
1. Black Pill STM32 and GPS receiver module are fed from the first 5V benchtop power supply output channel.
2. OCXO is fed from a second 5V power supply channel.
3. Computer USB cable to BlackPill is metered.
4. All grounds are common.
Test Case 1: Power ONLY supplied by USB cable, OCXO is OFF. Current draw is approx 75mA, and due to poor/thin
USB flexible cable, there is a voltage drop down to 4.92 volts, but everything runs.
Test Case 2: Turn on benchtop power supply, channels 1 (STM32 and GPS) and channel 2 (OCXO).
Leave USB cable connected to PC.
RESULT: USB metering now shows, as expected, zero current draw, and therefore no voltage drop,
and therefore both USB meter and benchtop power supply meter show 5.0v.
Combined total current for STM32 BlackPill and GPS module is still ~75mA.
Basically this proves the existence of the protection diode from the blackpill schematic.
Turning on and off the benchtop power supply cycles back to the condition at TEST CASE 1 above.
Conclusion: As long as the OCXO is powered by a different 5V power supply, and NOT the one connected
to the STM32 BlackPill 5V pins, there is no risk to the PC or the GPSDO, and total USB current consumption
at worst case is below 100mA (for this minimal build, higher if you add display and more modules).
I have verified that all the wiring is in place for sheet 1 of the schematic, minimalist GPSDO, and have scoped
the output of the recycled OCXO, and also verified ability to control the OCXO frequency using the FC pin (Vctl),
by adjusting a third power supply channel. Apparently all the HW is good!
So next, I am now starting to configure the source code file for my build, and to install the needed libs.
Within the hour, I might have this thing working :-)
Cheers,
Neal
-
...
Apparently all the HW is good!
So next, I am now starting to configure the source code file for my build, and to install the needed libs.
Within the hour, I might have this thing working :-)
Well done! :-+
Please post a picture or two of your setup once you get it up and running!
-
Well, an hour has gone by, but I suppose MURPHY loves me. I don't have any serial output from the STM32.
The GPSDO 0.05j sketch compiled without error, uploaded into the blackpill, it booted, and I can see the on-board
blue LED blinking, and also my off-board yellow LED on pin PB8 is blinking too.
BUT, I can't get anything on the arduino IDE serial monitor. I went into device manager on windows 10 and
confirmed that when plugging in the USB cable from the BlackPill, COM4 appears. I went into properties for
COM4 and set the baud to 115200 (was 9600), to match the sketch SETUP() section. I made sure flow control
was set to NONE. I also, in the arduino IDE, opened the serial monitor, and at the bottom right, set it to 115200 Baud.
On the Arduino IDE TOOLS menu, I made sure to set PORT to COM4.
I assume I can restart the blackpill by pushing the NRST button on the blackpill next to the boot button?
I tried that, and still no output on the serial monitor.
Did the upload really happen? Is the STM32 "really" running the GPSDO code? Let's try to find out:
I probed pin PB5 with my scope, and indeed, a 2kHz square wave. That, along with the blinking blue led and
blinking yellow led on PB8, tells me we really are running the GPSDO code.
Any ideas how I can debug why I get no serial monitor window output, via the USB/serial?
Don't assume I know anything, this is my first time starting to use STM32 with the Arduino IDE.
But I have previously built a number of projects and GPS adjusted clocks using Arduino NANO with the IDE,
so I have plenty of time using the serial monitor window, and reading/writing/modifying the C code, compiling,
and uploading.
Thanks for any pointers on debugging.
Neal
-
...
Apparently all the HW is good!
So next, I am now starting to configure the source code file for my build, and to install the needed libs.
Within the hour, I might have this thing working :-)
Well done! :-+
Please post a picture or two of your setup once you get it up and running!
OK, I uploaded a photo to google drive. First time, not sure if I set the permissions correctly.
Here is the link to the photo. Let me know if you can't see it.
(https://drive.google.com/uc?id=1yCi4OfBS0tuzjgT6KQz72DPC7mPyJosF)
Neal
-
Hi Nealix,
To try if the USB/Serial works loading a test sketch with only an echo video and the LED lighting up with a "different" pattern, so you are sure that there are no timeout or anything that can block sketch.
For the GPSDO only loads the minimal defines for the first time at startup, but I'm sure you've already tried it.
these:
#define GPSDO_PWM_DAC // STM32 16-bit PWM DAC, requires two rc filters (2xr=20k, 2xc=10uF) - always enable this!
#define GPSDO_GEN_2kHz_PB5 // generate 2kHz square wave test signal on pin PB5 using Timer 3
#define GPSDO_VCC // Vcc (nominal 5V) ; reading Vcc requires 1:2 voltage divider to PA0
#define GPSDO_VDD // Vdd (nominal 3.3V) reads VREF internal ADC channel
// begin sketch
#if !defined(STM32_CORE_VERSION) || (STM32_CORE_VERSION < 0x02020000)
#error "Due to API changes, this sketch is compatible with STM32_CORE_VERSION >= 0x02020000 (2.2.0 or later)"
#endif
#define blueledpin PC13 // Blue onboard LED is on PC13 on STM32F411CEU6 Black Pill
void setup() {
Serial.begin(115200); // USB serial try even 9600
delay(5000); // to settle
pinMode(blueledpin, OUTPUT);
}
void loop() {
Serial.println("LED ON");
digitalWrite(blueledpin, HIGH);
delay(500);
Serial.println("LED OFF");
digitalWrite(blueledpin, LOW);
delay(1000);
}
// end sketch //
It also happens to me that does not "work" usb, an STM32F411 no longer answers me but works properly,
Probably a dead-board regulator.
I ordered 3 new 3.1 on Aliexpress with 8MB of memory on board, they will serve for new experiments.
The best thing is to use new serial (serial3) with its converter so that you always have active debug and connected power.
bye, A.
-
Well, an hour has gone by, but I suppose MURPHY loves me. I don't have any serial output from the STM32.
...
Neal,
1. Did you leave #define GPSDO_BLUETOOTH uncommented? This option disables the output to USB serial. Make sure to comment it out.
2. Try removing this orange wire. ;)
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1458994;image)
3. Quit and restart the Arduino IDE, then re-open the Serial Monitor window.
4. Please copy/paste the configuration section and post it here. The setup() function will halt if you have configured any of the I2C or SPI sensors but it is not detected.
From everything you wrote, I am pretty confident that your STM32 GPSDO build is actually 90% already functional, there is just a small problem somewhere that is preventing USB serial communications.
-
Hi,
Just to give you all an idea of one of the many things I am working on for firmware version v0.06c (to be released in mid-May), I am implementing the hybrid FLL/PLL control loop which will result in the UTC-synchronized PPS, using Lars' TIC (with Erik Kaashoek's modifications) and the picDIV, both of which can be found in the STM32 GPSDO schematic version 0.6.2.
This is a capture from my DSO showing the GPS PPS pulse rising edge (Yellow trace) and the pulse generated by the 74HC74 (Green trace) in Lars' TIC. The TIC pulse width is exactly the phase difference between the GPS PPS pulse rising edge and the picDIV PPS pulse rising edge. The TIC pulse charges a capacitor through a diode and resistor and this translates into a Vphase which is read by the 12-bit ADC in the MCU once per second. Hence this Vphase is a measurement of the phase difference between the GPS PPS pulse and the picDIV PPS pulse. By minimizing this phase difference we can align the two pulses together, in other words, we can obtain a UTC-synchronized PPS derived from our OCXO 10 MHz.
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1460182;image)
The firmware must of course read the Vphase voltage and then discharge the 1nF capacitor and this is already working. Check the Vphase reading in the data reported by the GPSDO once per second (in the voltages section):
$GNGSA,A,3,10,32,16,08,21,23,27,,,,,,1.84,1.15,1.44*1D
$GNGSA.00,A,A*7D
$GNRMC,174622.00,A,4833.64928,N,00746.91793,E,0.028,,100422,,,A*68
$GNGGA,174622.00,4833.64928,N,00746.91793,E,1,09,1.15,156.0,M,47.3,M,,*45
Fix time 873ms
Uptime: 000d 02:03:35
New GPS Fix:
Lat: 48.560822 Lon: 7.781966 Alt: 156.0m
Sats: 9 HDOP: 1.15
UTC Time: 17:46:22 Date: 10/4/2022
Voltages:
VctlPWM: 1.99V PWM: 42618 OCXO disciplining: ACTIVE
Vcc: 4.93V
Vdd: 3.31V
OCXO voltage: 5.06V
OCXO current: 205mA
Vphase: 0.99V
Frequency measurements:
64-bit Counter: 74061103944
Frequency: 10 MHz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 10000000.002 Hz
10,000s Frequency Avg: N/A
20,000s Frequency Avg: N/A
BMP280 Temperature = 21.2 *C
Pressure = 1019.5 hPa
Approx altitude = -60.8 m
AHT10 Temperature: 22.26 *C
Humidity: 58.47% rH
The Vphase is the voltage across the TIC 1nF capacitor that one can see charging during ~600ns to ~1.75V in this second DSO capture:
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1460365;image)
The hybrid FLL/PLL control loop and the UTC-synchronized PPS during holdover are unique features that (to the best of my knowledge) cannot be found in other DIY or commercial GPSDOs. I have also implemented two new commands PO and AO to calibrate respectively the BMP280 atmospheric pressure and altitude measurements.
There are also new commands to save/retrieve the current PWM DAC value to flash memory. And as mentioned before, there are two new commands to switch on/off the OCXO disciplining, in other words to enter/exit "Holdover Mode".
All the above is already working but still needs many hours of testing. :phew:
-
I have experimented a lot and found that the HW is OK, and that USB serial does work with only the STM32 and the GPS module attached.
I installed the GPS checker sketch in the extra software folder, after editing out all the SD1306 OLED display code.
It works fine, so now I know that the computer link is OK and the STM32 is OK.
Next, I reloaded the v0.06C GPSDO sketch, and while the blue LED blinks and the yellow LED blinks, there is no USB serial output.
So next, randomly poking around, I noticed that if I shut down the OCXO 5V supply (it's own dedicated 5V), then I DO get USB serial
output from the main GPSDO code.
I restarted the STM32 without the OCXO powered up, and USB serial gets all the way to the OCXO warmup countdown, and then
the "Calibrating..." statement.
If I reset and try again, I can turn on the OCXO during the warmup countdown, and serial output hangs. In fact, there is evidence
that the entire GPSDO code in the STM32 hangs. Because if I then power down the OCXO, serial output resumes at the next
second of that warmup countdown on the serial monitor console.
So next, suspicious that maybe the 5V OCXO was putting too large a signal into the PB10 pin on the STM32, I scoped it.
Vmax of the OCXO square wave was approx 4.3 volts. Even though the input pins are supposed to be tolerant of 5V, I decided
to try a divider on the OCXO output. So I placed on the OCXO output a 100 ohm resistor and 330 ohm resistor to ground.
This yields a 3.4 volt square wave on my scope.
I ran the midpoint of the resistor divider to STM32 pin PB10, per schematic version, um, er, ah, D U H !!!!!!
I was using an older print of schematic version 0.2, which has 1-PPS and 10Mhz reversed between pins PA15 and PB10.
Dang it! :-)
Just re-verified wiring with Schematic 0.6.2.
Start-up test sequence:
1. plug in USB to computer (STM32 and GPS module light up).
2. Immediately click the arduino IDE to open serial monitor.
3. Immediately enable 5V power to OCXO.
Now it's working :-)
I will let it run for a while and see how stable the 10MHz becomes.
Right now it's wandering plus/minus 1hz on the serial monitor.
I will also wire up the 74HC14 output buffer so I can leave my
external frequency counter attached without loading the OCXO pin.
Sorry for the noise. I had printed out the ver 0.2 schematic early on when this forum
thread was just starting, and then later printed out the v0.6.2 schematic, and then
promptly got them mixed up. I HATE being human :-)
Sorry for the noise.
Neal
-
Follow up status after several hours.
It seems to be working fine, but the self calibration is slightly off.
No complaint, just an observation.
When running the "C" calibration command, it comes up with a
PWM setting of 44272 one time, and running the command again
comes up with 44475. This measures 0.028 Hz high above 10MHz.
Manually entering SP 44391 results in 10,000,000 point 000 Hz.
Obviously, either setting is more accurate than I need for hobby work.
But I wonder, when getting back to this project in May, if there are any
thoughts about how to make the calibration routine more accurate,
even if it takes longer?
A second thought: I really have only run this several hours. After 24 hours,
should I see the PWM number change a little bit as it slowly tries to adjust,
or will it simply stay locked at one number?
It seems to have drifted up by 0.012 Hz over the time I am typing this message.
Overall, it seems to be working just fine. Here is the project station;
(https://drive.google.com/uc?export=view&id=1JEUOF2DrmaFgdpo_lmhzi5wu_PZE9cQx)
Thanks,
Neal
-
Good morning everyone.
Neal:
congratulations for the workbench :)
The calibration routine can be extended to 60 seconds of sampling by commenting:
#define FastBootMode // Reduce Various Delays During Boot
This allows a more data collection to make the two medium for two-point calibration.
Probably something you can improve and do it, I had changed the setting of the equation to be tested to make the VDD participate instead of a fixed number.
The PWM must certainly change during the time until it stops if you reach a frequency that is within the range described in the code.
This gpsdo for "now" works like FLL, follow the frequency. ( FLL means Frequency Locked Loop, like PLL but not for phase )
When you are in those ranges the PWM is no longer changed.
But it is a transitory situation because it is enough for a breath of air on the OCXO that the frequency again starts to deviate.
The biggest problem for these devices is to keep the OCXO safe from air movements.
bye, A.
-
Neal, congratulations on getting your STM32 GPSDO up and running. :-+ The real fun part starts now! :-/O
The calibration command C is based on a simple two-point interpolation algorithm and is designed to reach an accuracy of no better than 0.1 Hz, with the OCXO already warmed up to its normal operating temperature. As iannez explained, for debugging purposes the duration of the calibration procedure can be shortened from two minutes to 30 seconds by defining the FastBootMode flag, and that also shortens the OCXO warmup from 5 minutes to 30 seconds, at the expense of some loss of accuracy in the calculated PWM DAC value. In normal operation the FastBootMode flag should remain undefined (commented out).
Also as Iannez explained, the frequency accuracy (in other words, the optimal PWM DAC value) reached after several hours depends on several factors, among others: OCXO retrace, ambient temperature stability, GPS satellite reception, the presence and use of electrical appliances nearby (e.g. a microwave oven in my case), etc. OCXO retrace can take several days and even weeks of continuous operation, satellite reception is best with a good rooftop antenna with a 360 degrees unobstructed view of the sky, and ambient temperature stability can be greatly improved by simply placing a cardboard box on top of the GPSDO. And of course don't make yourself a tea using the microwave oven less than 3m/10ft from your GPSDO. :)
And as you are aware, directly measuring the frequency of the OCXO with a probe places a capacitive load on its output and that very slightly changes the OCXO frequency, which is the reason the 74HC14 buffers are best used in such cases.
Finally: the present FLL control loop algorithm is still in its infancy and in very rough shape, so its performance is far from optimal. I simply haven't had the time to work on a more sophisticated FLL algorithm until now. But there is certainly room for improvement in that code! And also as I mentioned before I want to explore the hybrid FLL/PLL algorithm that the addition of the TIC and picDIV allows. :phew:
-
As the STM32 GPSDO project moves on to the (as usual, optional) PLL/FLL hybrid control loop development phase, new and old builders may wonder where to get a picDIV chip ( http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm) ) which is essential for the PLL.
If you are in the US, the best source is of course the leapsecond.com website: tvb@LeapSecond.com - one picDIV is $3, first-class postage & handling is $4 (USA) or $8 (international) , please do tell Tom that you are building an STM32 GPSDO. EDIT: oops, not anymore, unfortunately.
If you are in France, Germany, the Netherlands, Belgium or other parts of Europe near France or Germany, contact me by PM.
If you want to program the picDIV by yourself, you need either a PIC12F629 or a PIC12F675 (an 8-pin PIC) and a PIC programmer, and the hex file is pd11.hex which you can download from the leapsecond.com website.
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1460773;image)
-
Hi,
I am pleased to publish the STM32 GPSDO schematic version 0.7.
Main changes are the deletion of the MCP4725 12-bit I2C DAC which is replaced by the 16-bit PWM DAC, and the addition of the (optional) TM1637 "Atomic Clock" display. Also a couple of small changes in the TIC (one resistor deleted, one resistor added), and the connection of the INA219 current sensor to the I2C1 bus (it was on the I2C3 bus before but those MCU pins are now used by the optional TM1637 display). Also a note concerning the recommended use of an AHT20 sensor module for new builds (almost the same price as AHT10 but slightly better precision), and another note about possibly using a 1N4148 diode instead of the Schottky diode in the TIC (much cheaper and seems to work just as well, but more testing needed to confirm this).
-
G'd day,
oooh, so many interesting things and updates here. Great work, chaps, really.
I am sorry for the delay, but other things got in the way - such as the repair of my power supplies https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg4112938/#msg4112938 (https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg4112938/#msg4112938)
I have all the components for a 1st breadboard build of an Arduino or STM-32 GPSDO here, but so little time. This might need to wait until after the Easter hols. :(
Cheers,
THDplusN_bad
-
Hi,
I am pleased to publish the STM32 GPSDO schematic version 0.7.
It would make some of us smile if you always place the latest schematic into the github directory
here https://github.com/AndrewBCN/STM32-GPSDO
You could add a folder called schematics.
That way, people joining this thread at random times can always find the latest schematic that
matches the latest code, in one place :-) :-)
Cheers,
Neal
-
Hi,
I am pleased to publish the STM32 GPSDO schematic version 0.7.
Hi Andre:
On sheet 3 there is the optional frequency counter input, and in zone A 6, it has an output tag FCinput->
Is that simply a future work in progress, or did you intend for that FCinput tag to also show up on page 1
at the STM32? Or not yet?
(No rush at all, I was simply curious since I could not find the other end of it on the schematic.)
Cheers,
Neal
-
As the STM32 GPSDO project moves on to the (as usual, optional) PLL/FLL hybrid control loop development phase, new and old builders may wonder where to get a picDIV chip ( http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm) ) which is essential for the PLL.
If you are in the US, the best source is of course the leapsecond.com website: tvb@LeapSecond.com - one picDIV is $3, first-class postage & handling is $4 (USA) or $8 (international) , please do tell Tom that you are building an STM32 GPSDO.
Note: Two weeks ago I emailed Tom asking to order some of the PD11 PicDiv's. He indicated that he no longer had much free time for programming those and selling them
so inexpensively, and suggested I just get some myself. They are very easy to program.
I was able to order a ten pack of chips on ebay, and also ordered a PicKit3 programmer on ebay. I am sure that AliExpress has them also. I also downloaded the source code
and hex programming files from Tom's website for all the different PicDiv types.
FYI
Neal
-
...
It would make some of us smile if you always place the latest schematic into the github directory
here https://github.com/AndrewBCN/STM32-GPSDO
You could add a folder called schematics.
That way, people joining this thread at random times can always find the latest schematic that
matches the latest code, in one place :-) :-)
...
Neal, you can smile now, because I just did exactly that. :)
-
Hi,
I am pleased to publish the STM32 GPSDO schematic version 0.7.
Hi Andre:
On sheet 3 there is the optional frequency counter input, and in zone A 6, it has an output tag FCinput->
Is that simply a future work in progress, or did you intend for that FCinput tag to also show up on page 1
at the STM32? Or not yet?
...
Good eye, Neal! And indeed the FCinput output from sheet 3 should go somewhere into an MCU input on sheet 1. Originally, I wanted to use a second Timer/Counter inside the STM32F411 to handle the frequency counter functionality, but as it turns out we are running out of pins! :( :o
One possible solution is to have an electronic switch that will select either the OCXO 10MHz or the FCinput and route that signal to the same pin we are using now. Another solution is to try to rearrange the pins on the STM32F411 to accomodate an extra timer input. I haven't decided yet, and I still have to write the first line of code to implement the Frequency Counter functionality... so yes, that's still very much work in progress so to speak. :)
Also I was hoping one of you would be kind enough to test that frequency counter input circuit, because quite honestly I have no idea what its sensitivity is or its -3dB cutoff.
-
...
Note: Two weeks ago I emailed Tom asking to order some of the PD11 PicDiv's. He indicated that he no longer had much free time for programming those and selling them
so inexpensively, and suggested I just get some myself. They are very easy to program.
I was able to order a ten pack of chips on ebay, and also ordered a PicKit3 programmer on ebay. I am sure that AliExpress has them also. I also downloaded the source code
and hex programming files from Tom's website for all the different PicDiv types.
FYI
Neal
Thank you very much for letting me know, Neal. I have sent you a PM.
-
Hello,
Here is the STM32 GPSDO schematic revision 0.7.1 with the following small changes:
- Added frequency counter input selector circuit using 74HC157. See Nealix post above and my reply to him. I think this is one possible solution to provide a selectable frequency counter input, and the 74HC157 is not an expensive chip ( < $1). Note that this circuit is untested and there is no code for that functionality yet. GPIO pin PB2 is used to select between the OCXO 10MHz and an external signal for the frequency counter.
- Added note about capacitor type for 1nF TIC capacitor. The TIC 1nF capacitor should be of a type that is as temperature stable as possible, so not a ceramic capacitor. Recommended are polyester or polystyrene or polypropylene.
The schematic revision 0.7.1 is also uploaded to GitHub. Please check when you have some time. 8)
-
Hi,
Supposing you want to plot some nice charts to show off the performance of your STM32 GPSDO build >:D or perhaps you are serious about investigating how the OCXO frequency correlates with ambient temperature, atmospheric pressure, supply voltage, or how the FLL algorithm could be improved (that I am afraid will require a complete rewrite, because right now it's crappy code which I wrote in a hurry), or just out of curiosity, how do you get the USB serial or Bluetooth data from the GPSDO into a spreadsheet in your PC/laptop/mobile phone ? ???
Well, it's actually not that complicated ! :o Here is one way to do it using a Linux laptop or PC :
1. Make sure your STM32 GPSDO is properly connected to your Linux laptop or PC by opening the Serial Monitor window in the Arduino IDE.
2. Send the "RD" (Report Delimited) command to the STM32 GPSDO. Notice how the output format changes to tab-delimited fields.
3. Close the Serial Monitor window in the Arduino IDE. There is no need to exit the Arduino IDE, though.
4. Open a terminal, change directory to whatever directory you want to use to store the STM32 GPSDO data, and type:
tail -f /dev/ttyACM0 > gpsdo_data.txt
This will save the data to the file gpsdo_data.txt until you exit the "tail" command with Control-C.
5. You can watch the file gpsdo_data.txt getting written by opening a second terminal and typing the command:
tail -f gpsdo_data.txt
6. Once you have accumulated enough data for your intended purpose, exit the "tail" program with Control-C, and open the gpsdo_data.txt file in your favorite spreadsheet program. I have attached a screenshot of LibreOffice Calc with some data from my GPSDO prototype #1.
A couple of remarks:
1. It could be that you will find the frequency data from your STM32 GPSDO rather boring to graph - because in principle it should be just a straight horizontal line. :-DD
2. If you want to collect data about the OCXO, then things could get more interesting, but you have to enter "Holdover Mode" (using the "MH" command) before you disconnect the Arduino IDE serial monitor. In that case, you should be able to observe how day/night changes in room temperature change the OCXO frequency, and its natural "drift" over time, as well as any "crystal retrace" effects (which are supposed to cause sudden small jumps in frequency).
3. The GPSDO data file will grow by one line per second, and most spreadsheet programs have a limit on the number of lines that they accept, but at least for LibreOffice Calc that shouldn't be a problem: its maximum number of lines is 1,048,576 (around 12 days of data) ! 8)
-
And for caputring the serial monitor output on a, cough, Windows 10 machine, you can open a free serial
terminal program instead of the Arduino IDE serial monitor, and then use a capture to file command in
the serial terminal program. Take note of the COM port# that your STM32 uses in the Arduino serial
terminal monitor, and the baud rate. CLOSE the arduino IDE serial terminal window to release the com port,
and then open a serial terminal program below using that same COM port# and baud rate.
Here are some options:
https://forum.arduino.cc/t/how-to-export-data-from-arduino-serial-monitor-to-a-csv-or-txt-file/354651/5
or
Using CAPTURE in the RealTerm program https://realterm.sourceforge.io/#Capture
Disclaimer: Linux is far better for almost any type of development work, coding, logging, text
manipulation, etc, because of the rich options that linux has built-in for these tasks and the powerful
linux pipe meachanism for cascading sub-commands. But for those who are stuck with Windows OS,
at least the above options will work just fine for capturing the serial monitor output on Windows OS to a log file.
I hope the above is helpful.
Neal
-
Thank you Neal. :-+
Also I just wanted to add a note that there is a third, very practical way to capture the GPSDO output to a file: use the Bluetooth interface to send the data to your smartphone! :o :wtf:
Yes, your smartphone! Just use this free app available on the Google Playstore: https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=en&gl=US
-
Alpha quality firmware v0.06c (pre-release version with a number of outstanding bugs) uploaded to GitHub in folder /software, along with a warning message in file WARNING.txt.
There is now a "help" command, type H and it prints a list of available commands. Many small or cosmetic changes and the only major feature fully implemented is the complete switch to the new counting algorithm, and that needs a lot of testing but so far it seems to work fine. No PLL algorithm but the Vphase value is read and reported once per second. The picDIV arming and synchronization manual operation is now supported with the AP command (Arm picDIV).
-
Chip caution notes for builders who modify or deviate from the schematic, and/or implement optional parts and/or optional power supply arrangements:
1. With regard to the ST32F411 Black Pill GPIO pins being 5V tolerant (the chip runs on 3.3V but we feed 5V OCXO and 5V PicDiv into IO pins),
please be cautious and refer to ST.COM Application Note AN4899 Rev 3, section 5.2.2 "Five Volt Tolerant GPIO":
On the Black Pill, or most any other model STM32 MCU board, VDD will be run at 3.3 volts.
From the app-note: "STM32 devices embed five-volt tolerant GPIOs. These GPIOs are actually tolerant to
VDD + 3.6 V. It means that the I/O pins can accept such voltages without causing leakage
current and damages on the GPIOs.
Regardless of the supply voltage, VIN cannot exceed 5.5 V.
When VDD = 0 V, the input voltage on the GPIO cannot exceed 3.6 V.
In case of a multi-supplied and multiplexed GPIO (VDD, VDDUSB, VLCD, VDDA), the GPIO is
tolerant to 3.6 V augmented of the minimum supply voltage among VDD, VDDUSB, VLCD, and VDDA.
However, a GPIO is five-volt tolerant only in input mode. When the output mode is enabled,
the GPIO is no more five-volt tolerant. For more details about I/O input voltage, refer to VIN
parameters in the general operating conditions table of the datasheet."
For the GPSDO project, the above indicates that there are two risk factors for damaging the STM32:
A. If the 5V OCXO is powered from a different power supply, and the STM32 is turned off (VDD goes to zero), the input pin could potentially be damaged.
and
B. If the 5V OCXO is running/powered, and the STM32 has not yet been programmed, or if an input pin is accidentally programmed as output.
In either of the two above situations, the max permissible input voltage on a GPIO pin could be exceeded, potentially causing damage to the chip.
So, for those who decide to power the OCXO on a different isolated power supply or regulator chip, you may wish to use sequencing, to
effectively keep the OCXO power off until AFTER the STM32 chip boots. Of course, it takes far less parts and complication if we simply keep
the input voltage to ANY STM32 GPIO pin no higher than 3.3 volts (3.6V max). For our STM32, for example, this can be accomplished for the
5V PicPPS input pin and the 10MHz 5V OCXO input pin, by using a resistor divider or a high speed level translator.
2. PicDiv chip (MicroChip 12F675 programmed with PD11.hex divider code):
On our GPSDO schematic, note that we take a GPIO output (PB3 on the STM32 Black Pill) and drive it as signal "picARM" to pin 4 (GP3) on the 12F675 PIC Chip.
[ THIS IS AN OPTIONAL PART OF THE GPSDO SCHEMATIC, SHOWN ON GPSDO SCHEMATIC PAGE 3, ZONE C2. ]
From the 12F675 PIC DataSheet, please take note of Section 12.0, Electrical Specifications, footnote at bottom of page:
Regarding 12F675 GP3 pin, Voltage spikes below VSS at the MCLR pin, inducing currents greater than 80 mA, may cause latchup. Thus,
a series resistor of 50-100 Ω should be used when applying a "low" level to the MCLR pin, rather than pulling this pin directly to VSS (Ground, pin 8 ).
So, in summary, IF you implement the PicDiv chip option, and IF you happen to run into stability issues, please try adding a series resistor of anywhere from 50-100 Ω in
between PicDiv pin 4 (Signal picARM) and the STM32 Black Pill picARM output pin. This is not likely a routine problem, and is not likely to create any issue
or damage.
I hope the above information is useful to those who are extending or adding to the project design.
Neal
-
For those in the USA or Canada who are building this, and IF you decide you want to add the optional PicDiv chip,
I am willing to help on an as-time-permits basis, for cost and my time.
I have the programmer for the PIC 12F675, and Tom at LeapSecond.com has granted me permission to
program the PD11 hex file into the PIC chips for GPSDO project builders who do not have their own programmer.
NOTE: I still work full time, and don't have too much hobby time to spare. And I am certainly NOT looking
for another full-time side business. So I would please ask; Do not contact me until you have already built the
basic GPSDO project and have it working. Once you get it working, if at that point you are serious about adding
a PicDiv chip, there are two options I can help with;
1. You can send me your blank PIC 12F675 and I will program it with the PD11 hex file and test it, for $5 USD.
And mail it back to you via USPS mail. [If you are in Canada, I need to look up postage cost and add that.]
or
2. For $7 I can sell and mail a complete programmed and tested chip if you do not have a blank chip.
[Again, If you are in Canada, I need to look up postage cost and add that.]
I would prefer to handle a max of 2 chips per person, since I only buy 10 chips at a time, and they take 2
weeks to come in from China. And also, because it takes time to hook up the programmer, set options,
erase and verify the blank chip, load the hex file, flash the chip, move the chip to a bread-board, test
several output pins, put it in an envelope, address it, stamp it, and mail it. So in reality it's more like
$35 of my time to sell you a chip for $7. So I am trying to limit this to a handful of GPSDO project builders,
and NOT become a general source for buying PicDiv divider chips.
If you need this help, please send me a private message and I will try to find time to assist you.
If you have purchased the programmer, or want to get one, and need help setting it up to program your
own chips, I can also assist with that via email or phone (as time permits).
REF: https://www.google.com/search?&q=pickit3 (https://www.google.com/search?&q=pickit3)
https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2047675.m570.l1313&_nkw=PICKit3+Microchip+Programmer+w%2F+USB+cable%2C+wires+Pic+Kit+3+and+ICSP+Socket&_sacat=0 (https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2047675.m570.l1313&_nkw=PICKit3+Microchip+Programmer+w%2F+USB+cable%2C+wires+Pic+Kit+3+and+ICSP+Socket&_sacat=0)
Yes, get the 40-Pin Universal programming socket with it. Works fine for the 8-pin chip and all the other larger chips.
If you are in Europe, AndrewBCN is able to assist with programming a PicDiv.
Cheers,
Neal
-
Hello,
Since I am going to be working on the hybrid FLL/PLL control loop algorithm for the STM32 GPSDO, I want to discuss a few aspects of GPSDO control loops and PID algorithms as applicable.
So first the PID reference is the Wikipedia article: https://en.wikipedia.org/wiki/PID_controller
And let us clarify a couple of points related to GPSDO control loops:
1. There are two main types of GPSDO control loops: FLL and PLL.
2. In FLL loops, the "process variable" PV is the frequency of the OCXO in Hz, measured by a counter with the gate time controlled by the PPS from the GPS receiver. No PPS, no frequency measurement.
3. In PLL loops, the "process variable" PV is the phase difference (in ns) between the rising edge of the 10MHz from the OCXO, and again the rising edge of the PPS from the GPS receiver, measured by a "time interval counter" TIC circuit which can be digital or analog. And similarly, no PPS, no phase difference measurement.
4. In both cases, the presence of a PPS from the GPS receiver is essential. Not only that, but the "precision" of the PPS from the GPS receiver determines the precision of our measurements of the PV variables frequency or phase difference. This is in fact what GPSDOs are all about: we use the PPS from the GPS receiver as a "proxy" for the atomic clocks onboard the satellites, to measure our local oscillator frequency or phase, and "discipline" it.
5. Just a note about digital/analog measurement circuits: the STM32 GPSDO FLL uses a 100% digital frequency measurement circuit, Lars' DIY GPSDO uses an analog TIC that generates a voltage that is then converted to a digital value using an ADC.
6. Getting back to our PPS from the GPS receiver, how "accurate" is it ? The accuracy of a clock is not a single number, it is actually best described ("characterized") by a chart, the famous ADEV/MDEV charts, which essentially plot the statistical variance of the frequency of our clock over a period of time (tau). So we know that the ideal frequency of the PPS from the GPS receiver is exactly 1Hz, and we can measure (using an even better clock) the minute variations in time between two consecutive rising edges of our PPS signal, and then if we collect enough measurements over e.g. a day or two, we can plot an ADEV/MDEV chart for our PPS receiver. This has been done over and over again by extremely knowledgeable people using very expensive equipment for a number of GPS receivers, and - surprise, surprise - they have found that the ADEV/MDEV curves for the PPS from different GPS receivers are actually quite similar. I'll come back to that later. But for the moment, we can assume that the "precision" of the PPS signal from a < $10 u-blox NEO M8N is better than 100ns over 1 second (10E-7) and improves by an order or magnitude per decade iow it is approximately 10E-8 for tau = 10s, 10E-9 for tau = 100s, etc. up to 10E-11 for tau=10k seconds.
7. I have previously posted a link to an excellent analysis of various GPS receivers and I again refer you to it : https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf by John Ackermann N8UR
8. Note that in the STM32 GPSDO we use a little trick to further improve the accuracy of the PPS from the u-blox NEO-M8N. Check the function ubxconfig() and you'll find this comment:
// send UBX commands to set optimal configuration for GPSDO use
// we are going to change a single parameter from default by
// setting the navigation mode to "stationary"
9. Getting back to the Wikipedia article on PID control loops, we have now defined our two process variables PVs frequency and phase difference, and we have just seen how to measure them. What is the setpoint SP or target value for these PVs ? For the frequency, it is the nominal frequency of our OCXO or 10MHz in our case, and for the phase difference it is exactly 0. In the STM32 GPSDO we already measure the error term e(t) every second for both PVs: for the frequency, this is the "offset" which is now stored in a unified ring buffer, and for the phase difference this is the reading from the TIC Vphase, which we average over the last 10 second using the moving average library.
10. Again referring to our ideal PID controller, our control variable u(t) in the case of most low-cost GPSDOs is the control voltage that we can apply to the OCXO to vary its frequency. For Lars' DIY GPSDO and for the STM32 GPSDO a 16-bit PWM DAC is used to generate a control voltage Vctl between 0 and 4V. This is an extremely economical solution but it does the job.
11. A complicating factor for programming the PLL or FLL algorithms for a GPSDO is that we are dealing with a discrete correction process, in other words changes in the control variable are applied at discrete time intervals which can be fixed or variable. For example, the STM32 GPSDO with its very crude FLL algorithm uses a fixed interval of 429s to change Vctl (except during the initial calibration). In older GPSDO designs using a purely analog circuit the control variable is applied continuously.
12. Consequently the program of an FLL or PLL loop for a GPSDO has two decisions to make every second:
a) What is the size of the correction to be applied to the control variable in other words how to compute the new value for Vctl ?
b) Should the correction that was just computed be applied now, or should we wait and apply a different correction later ? How frequently do we change Vctl and do we use a fixed or variable time constant?
13. The programmer (in this case myself) has to decide whether to use a P, PI or PID loop, the optimal values for Kp, Ki and Kd, how frequently do we change Vctl and do we use a fixed or variable time constant (the delay between changes to the Vctl), and any processing (filtering, averaging, removal of outlying values, etc) of the measurements from the frequency counter and the TIC.
14. More precisely in my case, there is an extra complicating factor because I am trying to merge the FLL and PLL control loops into a "hybrid" FLL/PLL control loop. How to best combine the information from the two measurements frequency and phase difference ? Should I have the two loops acting concurrently, or should one loop take over and in what conditions ? Aaaaahhhhhhhh :scared:
-
I notice that some of you guys mention using the STLINK to flash the BlackPill STM32 instead of the USB port DFU mode.
I too, am also having trouble with the USB DFU mode being fussy, and sometimes it takes ten tries to get the USB port to
appear as an STMboot device on the PC for download of the compiled code.
I have an STLINK device but never got around to learning to use it.
For those of you who are using the STLINK device, is there a procedure where you are able
to compile the GPSDO code using the arduino IDE, and then use some program with the
STLINK hardware to flash the blackpill using the Arduino IDE generated binary?
Is anyone willing to point me in the direction where I can learn these steps?
Thx,
Neal
-
Neal,
The program to use ST-Link is STM32 Cube Programmer which is installed automatically when you install the Arduino STM32 support package. Normally you can select to upload the firmware to the STM32 development board (the Black Pill in our case) through the ST-Link directly from the Arduino IDE.
Take a look at this: https://idyl.io/arduino/how-to/program-stm32-blue-pill-stm32f103c8t6/
-
I don't see much merit in a FLL/PLL hybrid, especially since your FLL has a very long settling time. The phase error you get from the TIC is normally sufficient. However, a frequency measurement can come in handy to speed up the lock of the PLL. If you're able to get the OCXO at least to within 100ns/s of the "true" 10MHz quickly so that the PLL can take over and lock to the phase, that would be something.
The frequency measurement can also prevent the PLL from trying to lock to multiples of 100ns/s of frequency offset. I've never actually seen this happen, but in theory, it could.
-
I don't see much merit in a FLL/PLL hybrid, especially since your FLL has a very long settling time. The phase error you get from the TIC is normally sufficient. However, a frequency measurement can come in handy to speed up the lock of the PLL. If you're able to get the OCXO at least to within 100ns/s of the "true" 10MHz quickly so that the PLL can take over and lock to the phase, that would be something.
The frequency measurement can also prevent the PLL from trying to lock to multiples of 100ns/s of frequency offset. I've never actually seen this happen, but in theory, it could.
Actually the STM32 GPSDO can achieve a PLL "lock" much faster than Lars' GPSDO and does not need the educated guesswork of a correct value for the "gain" in Lars' algorithm: we can calculate a nearly optimal "gain" value (or perhaps not optimal, but "good enough" gain value) during the calibration procedure. The problem with the PLL is the real resolution of Lars' TIC, which is around 25~30ns (vs. the claimed theoretical resolution of 1ns).
So my problem is creating an algorithm that takes the best features of the FLL and PLL and combines them into a "super" control loop.
-
A few (bad) hand drawings to illustrate a few concepts discussed above:
1) Frequency vs Time for an analog FLL PID controller showing the effects of non-optimal coefficients. Note the correction (Vctl) is continuously changed so the OCXO frequency also changes continuously.
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1463563;image)
2) Again an analog FLL PID controller, this time the OCXO frequency settles much faster and with little overshoot, since the coefficients are optimal or near-optimal.
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1463569;image)
3) Digital FLL PID controller showing discrete Vctl changes, once per second ("time constant" = 1 second). The coefficients are not optimal so there is some over and under shoot.
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1463575;image)
4) Digital FLL PID controller showing discrete Vctl changes, once per second ("time constant" = 1 second). At time t we lose the PPS or we enter "Holdover Mode" manually, whereupon the OCXO frequency starts drifting up, since the OCXO is not "disciplined" anymore (Vctl remains at the last value set by the PID controller).
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1463581;image)
-
Yes, that is all well understood, basic control theory. In fact, the digital and analog PLLs are not actually very different. It really depends on how frequently you get new information into the system.
For example, the old G3RUH design with the Jupiter GPS receiver used a quite high-frequent time signal, however this receiver would only update the phase of the signal once per second and so effectively it was quite digital as well. And I've seen "analog" designs that would use a discrete sample-and-hold circuit to store the output of the phase discriminator between time pulses from the GNSS receiver - not very analog either.
Regarding the time it takes for a PLL to settle, that is really a question of implementation. In that respect, Lars' PI controller implementation is very basic and should not be taken as a benchmark for what is possible. You can play a lot of tricks in software to adjust the characteristic of the regulation based on system state and achieve much quicker lock time.
Regarding the performance of the FLL - The problem is always to measure the frequency with high enough precision, and if it takes 100 seconds to get down to 1ppb precision that is your update frequency. In between your regulation cannot do anything.
On the other hand, a TIC gives you new information every second and that can be exploited.
However - you have all the tools available now to make a very interesting experiment: You can put your FLL to the test. Just plot the TIC values while leaving the control to the FLL. I would really love to see an evaluation of the stability.
-
...
Regarding the performance of the FLL - The problem is always to measure the frequency with high enough precision, and if it takes 100 seconds to get down to 1ppb precision that is your update frequency. In between your regulation cannot do anything.
...
Hello thinkfat,
That's not how the FLL works. Yes, you have to wait 10 seconds to get the first 0.1Hz resolution reading, 100 seconds to get the first 0.01Hz resolution reading, and so on. But that's just for the first reading at each resolution. All subsequent readings at each resolution are taken every second. So the regulation based on each resolution can take place every second, once the respective ring buffer has filled to capacity.
That is exactly the same constraint that a PLL loop has, because it has to "average" the TIC readings over a certain period of time to get any meaningful error value to a certain resolution.
In terms of measurement update frequency constraints, there is really no difference between a PLL or a FLL when used in a GPSDO control loop.
...
However - you have all the tools available now to make a very interesting experiment: You can put your FLL to the test. Just plot the TIC values while leaving the control to the FLL. I would really love to see an evaluation of the stability.
You are right, that is a very interesting experiment that only the STM32 GPSDO can perform. I'll get on to it soon. :-+
-
That is exactly the same constraint that a PLL loop has, because it has to "average" the TIC readings over a certain period of time to get any meaningful error value to a certain resolution.
In terms of measurement update frequency constraints, there is really no difference between a PLL or a FLL when used in a GPSDO control loop.
Well, no. The TIC adds an uncertainty of a couple nanoseconds per second, while the counter has an uncertainty of +/- 100ns per second. That makes a difference. Of course the timepulse of the GPS has some uncertainty, too, especially if you're not correcting the quantization error, but that is not in the order of 100s of nanoseconds - there's still some advantage that the TIC can provide.
-
Neal,
The program to use ST-Link is STM32 Cube Programmer which is installed automatically when you install the Arduino STM32 support package. Normally you can select to upload the firmware to the STM32 development board (the Black Pill in our case) through the ST-Link directly from the Arduino IDE.
Take a look at this: https://idyl.io/arduino/how-to/program-stm32-blue-pill-stm32f103c8t6/
Thanks. ST-link V2 USB dongle is MUCH Easier and quicker for program upload/flash, compared to the very fussy USB Serial DFU pushbutton method. The firmware in the eBay ST-Link V2 dongle had to be updated using the STM32CubeProgrammer software, and then, in the current Arduino IDE (v1.8.19), the TOOLS->Upload Method: menu entry needs to be "STM32CubeProgrammer (SWD)". The menu no longer has an entry that says "ST-Link".
Neal
-
I ran into trouble getting the ST7735 display module working. There is no schematic showing which pins to interface.
Badwater-Frank shared a PM with some of the details, but I still can't get the display going.
I googled and found this thread describes my problem exactly:
https://www.stm32duino.com/viewtopic.php?t=1113 (https://www.stm32duino.com/viewtopic.php?t=1113)
Does anyone have this display working, and if so, can they please share which specific pins are used to interface
on the STM32 Black Pill?
Cheers,
Neal
-
I ran into trouble getting the ST7735 display module working. There is no schematic showing which pins to interface.
Badwater-Frank shared a PM with some of the details, but I still can't get the display going.
...
Neal, the ST7735 display is not yet supported, it's an experimental feature. The SPI pins used in Badwater-Frank's ST7735 display implementation conflict with the pin assignments in the latest schematic.
You can try adapting the pins I used in the ST7789 code, these have no conflict.
Unfortunately I don't have an ST7735, so my help regarding this experimental feature will be very limited. :-//
-
OK, so another chart, this time it's the Allan deviation for:
1. A $5,000 (new) very high quality OCXO such as the one shown here: http://www.leapsecond.com/museum/osa8601/view.htm (http://www.leapsecond.com/museum/osa8601/view.htm) This is completely out of reach for most hobbyists.
2. A $10 used OCXO such as the ones we are using for the STM32 GPSDO.
3.The PPS from a $10 u-blox NEO-M8N GPS with a good antenna. If you think you would get a very different PPS ADEV curve from a more expensive GPS receiver, I refer you to the paper by John Ackermann that I linked to previously.
OK, so what does this chart show and why is it relevant to our discussion on PID controllers and the "performance" of a GPSDO in general ?
a) As the chart shows, a $5000 OCXO is approximately an order of magnitude more stable compared to a $10 OCXO up to until a tau of 1,000s.
b) As you can observe, the PPS Allan deviation intersects the $5,000 OCXO Allan deviation at around a tau of 100,000s, and doesn't really improve on it much beyond that. What this means is that there is practically no advantage to "disciplining" such a high quality OCXO with a $10 GPS receiver module. We gain practically nothing in terms of stability, and we actually would probably make things worse.
c) On the other hand, as the chart shows, the PPS Allan deviation intersects the $10 OCXO Allan deviation at around a tau of 1,000s. What this means is that if we carefully "discipline" such a $10 OCXO using the PPS from a $10 u-blox NEO-M8N GPS receiver module with a proper PID control loop with a "time constant" around 500s, the Allan deviation curve of our GPSDO should combine the OCXO stability up to around 1000s and the PPS stability from that point on.
That's the idea behind all GPSDOs, no matter how they implement the control loop or what hardware they are using. If the control loop is correctly setup and working as it should, the "performance" of a GPSDO can only be as good as the "performance" of the OCXO it is based upon up until the point at which it intersects the "performance" of the PPS from the GPS receiver used. And from this point on it should match the "performance" of the PPS from the GPS receiver.
As I wrote many times in this thread already: there is no magic happening in a GPSDO and there are no "special tricks" that can make it perform any better than the components it is based upon, because these components set the strict mathematical limits on the GPSDO overall performance.
I have just found this note by Lars Walenius in his PDF describing his Lars' DIY GPSDO: "The hardware may seem simple but the performance is still mostly dependent of the GPS receiver
and 10MHZ oscillator. So, first I recommend selecting a GPS receiver and oscillator depending on your requirement on stability." (my emphasis)
Note: all the numbers above are ballpark approximations, and so is the chart below.
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1464232;image)
-
i'm on vacation this week but i'm reading and thinking about various correlations between the variables for the pid. the problem is to have the given realtime frequency, tro have the direct correlation between pwm increase (1/65536), relative frequency increase and how long this increase takes effect.
I'm thinking...
-
That is exactly the same constraint that a PLL loop has, because it has to "average" the TIC readings over a certain period of time to get any meaningful error value to a certain resolution.
In terms of measurement update frequency constraints, there is really no difference between a PLL or a FLL when used in a GPSDO control loop.
Well, no. The TIC adds an uncertainty of a couple nanoseconds per second, while the counter has an uncertainty of +/- 100ns per second. That makes a difference. Of course the timepulse of the GPS has some uncertainty, too, especially if you're not correcting the quantization error, but that is not in the order of 100s of nanoseconds - there's still some advantage that the TIC can provide.
From Lars' PDF, right on the first page:
As the 1PPS has a lot of jitter, normally in the range 10-50ns p-p, the time measured between the 1PPS and 10MHz is filtered with a low-pass filter in the software.
(my emphasis)
Lars' low pass filter essentially averages the 1Hz TIC reading to extract a usable value from the noise. In the FLL used in the STM32 GPSDO we average the 1Hz frequency readings to chop down the 100ns uncertainty associated with a single reading. Essentially neither PLL nor FLL control loops can extract sufficient information about the error from a single 1Hz measurement. So exactly the same problem and exactly the same solution: take multiple sequential readings.
Neither PLL nor FLL have any advantage in terms of how much information either can extract from a single 1Hz error measurement.
-
That's not quite correct. Lars' TIC has about 1ns resolution. Not sure about the uncertainty, I guess it depends a lot on the component choice and the cleanliness of the build, but it can sample the noisy 1PPS input once a second and then averaging over like 10 or 20 seconds (Lars used an EMA filter for that purpose) gets rid of the quantization error mostly. So, there is information in that jittery signal that can be extracted. Mind you the PPS is not jittery because the time signal recovered by the receiver is so noisy. It is noisy because the 1PPS output is aliased to the receivers internal clock source. Over a couple of 10 seconds, the accuracy is much better than 50ns.
Using a 10MHz counter on the other hand, it is completely blind to this. There's no way to extract the information with 10 or 20 seconds of averaging.
-
That's not quite correct. Lars' TIC has about 1ns resolution. Not sure about the uncertainty, I guess it depends a lot on the component choice and the cleanliness of the build, but it can sample the noisy 1PPS input once a second and then averaging over like 10 or 20 seconds (Lars used an EMA filter for that purpose) gets rid of the quantization error mostly. So, there is information in that jittery signal that can be extracted. Mind you the PPS is not jittery because the time signal recovered by the receiver is so noisy. It is noisy because the 1PPS output is aliased to the receivers internal clock source. Over a couple of 10 seconds, the accuracy is much better than 50ns.
Using a 10MHz counter on the other hand, it is completely blind to this. There's no way to extract the information with 10 or 20 seconds of averaging.
Not at all. You can easily extract information from a 10MHz counter after 10 or 20 seconds: that's exactly what the STM32 GPSDO FLL control loop does. Actually the FLL control loop extracts information from the 10MHz counter continuously every second as soon as the GPS receiver provides a PPS, and saves the information for each and every reading in a (at present) 20,000 seconds circular buffer.
By contrast Lars GPSDO does not save the total information for each and every TIC reading, since Lars decided that for his control loop it was enough to use an exponential moving average of the TIC readings.
Note that I am not at all claiming either method is "superior" to the other, those are design decisions that each GPSDO designer deals with as best she/he can.
-
The problem with the PLL is the real resolution of Lars' TIC, which is around 25~30ns (vs. the claimed theoretical resolution of 1ns).
How have you measured the resolution of your hardware implementation of Lars' TIC? The 25~30 ns you specify is suspiciously close to the NEO-M8N's 30 ns time pulse rms accuracy (datasheet, page 6 (https://content.u-blox.com/sites/default/files/NEO-M8-FW3_DataSheet_UBX-15031086.pdf#page=6)). If you require higher time pulse accuracy (e.g., for shorter time constants or better transient behavior) you'd need a GNSS receiver with quantization error compensation.
The STM32F411's timers should enable 10 ns resolution capture at their 100 MHz max clock frequency (https://www.st.com/resource/en/datasheet/stm32f411ce.pdf#page=27). Unfortunately, that is not (trivially) possible with the BlackPill, because its PH0 pin is not accessible unless you desolder the HSE crystal. When using the 10 MHz OCXO as the HSE source, a timer could be run at 100 MHz from the PLL locked to the OCXO, enabling 10 ns resolution timer capture of the GNSS timepulse relative to the OCXO's current frequency. The same timer could be used to generate an OCXO-locked timepulse. Erik is currently experimenting with that (https://febo.com/pipermail/time-nuts_lists.febo.com/2022-April/105404.html). As long as the timepulse measurement resolution is below the timepulse jitter and both are uncorrelated (e.g., use a different clock), you can increase your accuracy via averaging.
Just an idea: With 30 ns jitter from the GNSS timepulse, using only the STM32F411 timers (at 100 MHz) might simplify your design by obviating the need for the analog TIC and the picDIV.
3.The PPS from a $10 u-blox NEO-M8N GPS with a good antenna. If you think you would get a very different PPS ADEV curve from a more expensive GPS receiver, I refer you to the paper by John Ackermann that I linked to previously.
The ZED-F9T w/ quantization correction is an order of magnitude better than a NEO-M8T (Fig. 26 of John Ackermann's paper (https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25)). That could move the ADEV intercept of OCXO and timepulse by an order of magnitude on the tau axis, enabling, e.g., significantly faster settling after power up.
-
Notice that I often put performance between quotes? That's because defining the "performance" of a GPSDO is not that simple.
Going back to basics once again, what is the purpose of a GPSDO? As the name implies, a GPSDO is essentially an oscillator with a high degree of stability.
From the Wikipedia article on GPSDOs: "A GPS clock, or GPS disciplined oscillator (GPSDO), is a combination of a GPS receiver and a high-quality, stable oscillator such as a quartz or rubidium oscillator whose output is controlled to agree with the signals broadcast by GPS or other GNSS satellites."
https://en.wikipedia.org/wiki/GPS_disciplined_oscillator
And also as we have seen, the stability of an oscillator has a precise definition in mathematical terms: it is described by an ADEV/MDEV curve, and that curve is essentially determined by the quality of the two main components: the oscillator and the GPS receiver (when the GPSDO control loop is operating properly). As Lars Walenius wrote, the selection of a GPS receiver and oscillator essentially define the stability envelope of a GPSDO. The rest is up to the control loop, and when a control loop is well designed and well tuned it should realize the full stability potential of the GPS receiver and oscillator.
So can we just define the "performance" of a GPSDO as its ADEV/MDEV curve? I personally don't think so. While the stability of a GPSDO as measured by the ADEV/MDEV curve is certainly an important parameter, I don't think it is the only factor to consider when trying to define the overall performance of a GPSDO. Here is a non-exhaustive list of some other parameters that I consider important:
1. Software quality, including the quality of the control loop.
2. Source code availability (Open Source or proprietary).
3. Overall temperature stability.
4. For a DIY GPSDO: is it easy to source all the components? What is the total cost for the BOM? Is it easy to put together and use? Is there a PCB available? Is there good documentation?
5. Information reported every second, on a serial port or other (e.g. Bluetooth, WiFi, Ethernet, etc).
6. What sensors are available, if any.
7. Quality of the display, if any.
8. Support, if any.
9. Price/performance ratio. Here, as always, you get what you pay for.
10. Upgradability / expandability (software and hardware).
11. What other functionalities are provided? (e.g. an "atomic clock" display? A UTC-synchronized PPS during holdover? A frequency counter mode? NTP/PTP server? Portability?)
12. Is it a copy of an older, original design? Or is it a new design?
13. Does the design match the intended use case? Don't expect a commercial GPSDO designed for satellite use to resemble in any way, shape or form a DIY GPSDO designed for experimentation and hobby use.
:phew:
-
...... Here is a non-exhaustive list of some other parameters that I consider important:
1. Software quality, including the quality of the control loop.
2. Source code availability (Open Source or proprietary).
3. Overall temperature stability.
4. For a DIY GPSDO: is it easy to source all the components? What is the total cost for the BOM? Is it easy to put together and use? Is there a PCB available? Is there good documentation?
5. Information reported every second.
6. What sensors are available, if any.
7. Quality of the display, if any.
8. Support, if any.
9. Price/performance ratio.
10. Upgradability / expandability (software and hardware).
11. What other functionalities are provided? (e.g. an "atomic clock" display? A UTC-synchronized PPS during holdover? A frequency counter mode?)
12. Is it a copy of an older, original design? Or is it a new design?
:phew:
Just a side note...
Bolded sentence is the only thing on your list that is actual performance parameter. Maybe number 1 but that is ambiguous what you mean by it.
Everything else are features and characteristics that you find important and desirable by your opinion as a user.
But they are not performance related.
Raison d'etre of GPSDSO is to provide high stability frequency source. And relevant performance parameters are only related to that. Maybe if you need portable one, performance parameters would include antenna sensitivity, time to lock, power consumption etc.
Implementation details and additional features are just that. And I agree that each person should choose one that fulfils most of it's needs.
If you will, one might say ( and you might have meant exactly that and I misunderstood) that when choosing on a GPSDO one should not make a choice simply on performance but also on other desirable parameters, of which you made your recommended list of things to pay attention to...
I believe that is a good approach and actually applicable to many other things too...
-
...
Raison d'etre of GPSDSO is to provide high stability frequency source.
I agree of course, since that's exactly what I wrote. :)
And relevant performance parameters are only related to that.
...
That's tautological on your part. You are defining "performance" as stability, and then you are saying that only stability parameters are related to "performance".
:o
But cool, that's your personal point of view and of course I am not going to contradict you.
I would just ask you to think about the job of a GPSDO designer. If she/he thinks that the sole definition of performance of a GPSDO is its stability, then she/he has very, very little work to do: just buy the most expensive rubidium oscillator the budget allows, wire it to the most expensive latest generation GPS receiver the budget allows, and slap the same old PID control loop that a retired engineer designed 20 years ago. Pronto, mission accomplished. :P
However, I would point out that such a "high performance" GPSDO design, if it existed, would not make any sense, since the cost of such a design would easily exceed the cost of a chip scale atomic clock, which has inherently better stability (hence better "performance") than any imaginable rubidium GPSDO.
Equating performance to just and only stability in a GPSDO is a self-defeating proposition.
Wikipedia page for Chip Scale Atomic Clock (CSAC):
https://en.wikipedia.org/wiki/Chip-scale_atomic_clock (https://en.wikipedia.org/wiki/Chip-scale_atomic_clock)
EDIT: note that Carsten has posted below a link to a superb lab instrument GPSDO, the SRS FS740, designed in the late 2000's, and offered with a TCXO with optional OCXO or rubidium oscillators. Obviously, the main point of this $3,195 lab instrument GPSDO is not the type of oscillator used, but the amazing functionality provided. https://www.thinksrs.com/products/fs740.html (https://www.thinksrs.com/products/fs740.html)
-
The lure of CSACs is not their stability, actually their performance may well be worse than the typical run-of-the-mill Rb reference. For example, the commercial CSAC from Microsemi mentioned in the Wikipedia article is quoted to have "<1E-11 @1000s ADEV", which not really remarkable. Any cheap surplus Rb can do that, if it's not broken. The big advantage is the size and power consumption, which brings atomic clock type stability to many more applications than what is possible with using the "classic" physics package.
Does it make sense to use a classic Rb (or CSAC) in a GPSDO? Perhaps. But then only if your application absolutely needs it for hold-over performance. But if you're not size constrained, or energy constrained, just use a surplus LPRO-101, hook it up to some control circuit and you have your "ultimate GPSDO" for maybe a couple 100€.
But this type of oscillator brings a whole new set of challenges, it's not enough to hook up a good GPS receiver. A Rb is unbelievably "heavy". It just plows along like a train and you really have to work hard to make it change frequency. It's like driving a truck and only being allowed to turn the steering wheel by 1 degree in each direction. If you want to exploit its stability in a GPSDO, other factors like temperature, air pressure, magnetic fields etc. become much more important than the quality of the GNSS. So in most cases it doesn't make sense. But it sure is fun. I made one once and I was very pleased with the performance. Even while it was locked to GNSS, it was usable as a reference to qualify other, "lesser" GPSDOs.
-
Hi,
The next version of the firmware for the STM32 GPSDO (due in mid-May) will come with a new architecture that puts the control loop algorithms in separate files / modules and a new command that allows switching "on the fly" between the different control loops. And the first four control loop algorithms / modules will be:
- The very crude FLL control algorithm that was being used since the early days of the project. It's crude, it does not react well to small disturbances, it reacts very slowly, etc ... but it works (barely, and probably by chance rather than by design).
- A proper PID-based FLL control algorithm.
- A proper PID-based PLL algorithm.
- A "hybrid" PID based FLL+PLL algorithm where each error measurement contributes a weighted response.
And since I am thinking outside the box I would like until the end of the year to work out how a neural network could be used for the STM32 GPSDO control loop, based on this NN library: https://github.com/GiorgosXou/NeuralNetworks
So if you are confident in your C/C++ programming talents and understanding of how GPSDOs work, think about programming your own GPSDO control loop algorithm for the STM32 GPSDO! 8)
-
...
Does it make sense to use a classic Rb (or CSAC) in a GPSDO? Perhaps. But then only if your application absolutely needs it for hold-over performance. But if you're not size constrained, or energy constrained, just use a surplus LPRO-101, hook it up to some control circuit and you have your "ultimate GPSDO" for maybe a couple 100€.
...
Apparently GPSDO manufacturers think it does not make sense to use a rubidium oscillator in any new GPSDO design. And obviously they can't rely on surplus LPRO-101s. Btw Microsemi has a single GPSDO in their current product line (not sure whether they think it's an "ultimate GPSDO") and it is based on their CSAC. They also bought the Vectron line of GPSDOs, and these are all based on OCXOs.
https://www.microsemi.com/product-directory/timing-synchronization/3826-gnss-disciplined-oscillators-gnssdo (https://www.microsemi.com/product-directory/timing-synchronization/3826-gnss-disciplined-oscillators-gnssdo)
Disclaimer: I have zero ties of any kind with Microsemi or any other GPSDO manufacturer.
With all this we are getting very much off-topic in this thread, |O something I will try to avoid in all my future posts.
-
Apparently GPSDO manufacturers think it does not make sense to use a rubidium oscillator in any new GPSDO design.
Sorry for another off-topic comment ;) Stanford Research Systems (SRS) sells the FS740 (https://www.thinksrs.com/products/fs740.html), which is a GNSSDO with an optional Rubidium standard (SRS PRS10) as integrated high-stability source. I use these at work. While bulky, heavy, power hungry, and slow to settle after power on, they work like a charm in a lab environment. However, these are about two orders of magnitude more expensive than your entire BOM cost. Surely not a tool for a hobby project, but an example of a relatively new GNSSDO using a Rubidium timebase.
-
Actually there is a very interesting chart on the SRS website that demonstrates exactly some of my points above. ;)
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1465324;image)
One can notice that whatever type of oscillator is used, the stability of the GPSDO is bound by the intrinsic stability of the oscillator used until it intersects the GPS PPS Allan deviation, and by the GPS PPS stability after that point - just like any other GPSDO, including the Lars' DIY GPSDO or the STM32 GPSDO.
Also note that the design of the SRS FS740 (late 2000's) predates the commercialization of the CSAC (2011).
-
Hi,
So we have seen in some of my previous recent posts that GPSDOs work by "disciplining" a local oscillator using a GPS PPS (which is in fact a "proxy" for the atomic clocks on GNSS satellites). The "disciplining" is done by a closed (feedback) control loop, which can be analog or digital, and implemented in hardware or software. In the STM32 GPSDO the control loop is obviously implemented in software. If the control loop is properly programmed, it should "discipline" the oscillator as "gently" as possible until the Allan deviation curve for the oscillator intersects the GPS PPS Allan deviation slope, and then carefully synchronize the oscillator to the GPS PPS for any larger taus. For the $10 OCXOs we are using, this "intersection" usually occurs before or at around the tau=1,000s point.
As mentioned before, future versions of the firmware will allow changing the control loop algorithm "on the fly", and I will be moving the control algorithms into a separate file to make it simpler to focus on their programming. And anybody can write their own code for the control loop algorithm(s) and test it(them) on the STM32 GPSDO hardware. The STM32 GPSDO "experimentation platform" is 100% Open Source hardware and software, so you can take it in any direction you want. When testing the STM32 GPSDO and new control loop algorithms, the firmware already supports reporting in tab-delimited format, suitable for input into e.g. spreadsheet programs for further processing and charting.
For example:
a) You can program a "random walk" algorithm that will "disturb" the Vctl value at random intervals and see how that affects the OCXO stability, as measured on an Allan Deviation vs tau chart.
b) You can program a genetic algorithm to determine near-optimal parameters for a PID controller. See for example the video on YouTube by Steve Brunton about this.
c) etc.
For PID control loops, I strongly suggest avoiding "reinventing the wheel" and using this Arduino PID library by Brett Beauregard: https://www.arduino.cc/reference/en/libraries/pid/ (https://www.arduino.cc/reference/en/libraries/pid/)
Likewise for neural network / machine learning algorithms there is this Arduino NeuralNetwork library by George Chousos: https://www.arduino.cc/reference/en/libraries/neuralnetwork/ (https://www.arduino.cc/reference/en/libraries/neuralnetwork/)
With this post I am concluding my "Back to the basics" or "GPSDO principles" ramblings and I will now focus on matters directly related to the STM32 GPSDO hardware and software.
-
A neural network that incorporates inputs from environmental sensors, such as temperature and pressure and humidity would be helpful.
-
Also note that the design of the SRS FS740 (late 2000's) predates the commercialization of the CSAC (2011).
Where'd you get that number? The user manual was released early 2017 according to its revision history. And when I was first playing around with the James Miller GPSDO (http://www.jrmiller.online/projects/ministd/frqstd.htm) and SRS FS725 in early 2016 the FS740 was not around, as far as I recall.
Also, just like thinkfat pointed out above, in terms of ADEV neither the SA.45s CSAC nor the MAC-SA5X can compete with full-blown Rubidium standards like the PRS10 or the LPRO-101 (http://www.ke5fx.com/rb.htm). For relevant tau > 1000 s the PRS and LPRO are putting the CSAC and MAC to shame. If you go for a GNSS-locked Rubidium, you likely do that for holdover performance, and tau < 1000 s is irrelevant regarding holdover.
A neural network that incorporates inputs from environmental sensors, such as temperature and pressure and humidity would be helpful.
Presumably, hermetically sealed OCXOs are supposed to be indifferent to atmospheric pressure and humidity. However, I'm curious whether you could still correlate such environmental sensor values with OCXO drift.
-
...
Where'd you get that number?
...
Check the schematic on page 222 of the User Manual. It is dated February 15, 2005 ; similarly, the power supply schematic on page 217 is dated February 9, 2011. This is user documentation that usually follows the initial product design by at least 2 to 3 years, if not longer. So clearly, the SRS FS740 is a superb lab instrument, but its design and development predate the commercial availability of the first CSACs in 2011.
And please... could we get back on topic?
-
Check the schematic on page 222 of the User Manual. It is dated February 15, 2005 ; similarly, the power supply schematic on page 217 is dated February 9, 2011. This is user documentation that usually follows the initial product design by at least 2 to 3 years, if not longer. So clearly, the SRS FS740 is a superb lab instrument, but its design and development predate the commercial availability of the first CSACs in 2011.
The February 2005 date is the schematic of the interface for the PRS10 Rubidium standard. The PRS10 is pretty old, so the interface schematic was likely copied from sth. that predates the FS740. Note that the page layout differs from the remaing schematics. The power supply schematic (date February 2011) was likely also duplicated from another product (why redesign sth. that has proven to work). The remaining schematics' dates (everything that would have to be designed from scratch for a new product) are from July 2014 or later. I highly doubt it took them 12+ years from beginning of development to release.
The CSAC was likely available when the FS740 was designed, but why would SRS
a) pick a part with inferior long-term stability and
b) pick a part from an external supplier if they manufacture an alternative in-house.
And please... could we get back on topic?
Sorry. Absolutely. Getting back on topic now:
How have you measured the resolution of your hardware implementation of Lars' TIC?
I'm actually curious about that. You wrote that instead of the 1 ns resolution claimed by Lars it is actually only 25~30 ns. How did you come to that conclusion?
-
GPSDO working fine with 1.8 inch ST7735 LCD display module, SPI interface.
Thanks to help from Badwater Frank, I was able to refine the display to my choices,
and add more comments to Andre's v0.06b code, and PM email it back to him.
Please don't bother AndrewBCN for help with this, since he does not yet have one of these displays.
I am happy to share if anyone else has trouble getting it going. Here is the screen after ~3 hours of up-time;
(https://drive.google.com/uc?export=view&id=1ILeWaIqH6aWsVY8bj0A-EfXiO3MrDBVI)
This was a China eBay special, but is essentially the same as the Adafruit 1.8 inch ST7735 color LCD with SPI interface.
Regardless of where you buy it, you just want one with the 8-pin interface and the ST7735 controller chip.
Even though the current V0.06b codebase is a simple FLL based GPSDO, and not yet a PLL design, I must say that for casual home lab
and home radio use, this is more than good enough, and has a LOT fewer parts that the more complicated GPSDO's out there.
Anyway, when the PLL code and phase detector schematic changes happen later this year, it is easy enough to modify at that time.
Neal
-
Neal, that looks very, very good. :-+ :-+
Thanks for the improved and well commented ST7735 display code, I'll make sure to merge it by v0.06c. :)
Just a few remarks about the "10,000,000.001Hz" reading on Neal's attractive STM32 GPSDO LCD color display. That translates into a peak-to-peak stability in the +/- 1E-10 range in the tau=1000s range which is more or less where one can expect a $10 (used) OCXO to be, and right around the point where the control loop "gently" regulates this stability using the PPS from the GPS receiver (pay attention to the "uf-" in the display). In other words, despite the very simple and primitive control loop algorithm, Neal's STM32 GPSDO build is behaving exactly as it should. :-+
No "magic trick" exists that would make an STM32 GPSDO have any better stability (or "performance" as some would call it) with the same choice of oscillator and GPS receiver, and spending $250 on a "better" GPS receiver module (e.g. the u-blox ZED-F9T) or $500 on a used rubidium oscillator - if you can find one that actually works for around that price - would bring only marginal improvements in stability. :horse:
So at this stage we can definitely answer Neal's question from two weeks ago when he still didn't have his STM32 GPSDO up and running, about whether he would need a $300,000 caesium atomic clock to measure the performance of his $50 STM32 GPSDO:
- Neal, no you don't, you can save that money for a nice dinner with your family! :)
-
A code snippet listing the various GPSDO control loop algorithms. Right now the selection is done by using a switch statement that calls one of the 10 possible algorithms. This is not elegant at all, an elegant solution would be to put each control algorithm in an object of class "control loop algorithm" and select the object, but again: too many ideas, too little time. :-//
// algorithm selector function
uint16_t adjustVctlPWM(uint16_t previous_PWM_output, uint32_t timer, uint8_t algorithm_no);
// up to 10 different control loop algorithms, in order from 0 to 9
// 0 - primitive, very simple control loop
uint16_t primitive_ctl_loop(uint16_t adjusted_PWM_output, uint32_t lclppscount);
// 1 - not a control loop, we force the OCXO to drift slowly and regularly
uint16_t forced_drift_Vctl(uint16_t adjusted_PWM_output, uint32_t lclppscount);
// 2 - not a control loop, we force the OCXO to "jitter" randomly
uint16_t random_walk_Vctl(uint16_t adjusted_PWM_output, uint32_t lclppscount);
// 3 - FLL PID control loop, coefficients set manually
// 4 - PLL PI (not PID) control loop, coefficients set manually (similar to Lars')
// 5 - PLL PID control loop, coefficients set manually
// 6 - FLL PID control loop, genetic algorithm used to find near-optimal coefficients
// 7 - PLL PID control loop, genetic algorithm used to find near-optimal coefficients
// 8 - FLL + PLL "hybrid" PID control loop, weights and coefficients set manually
// 9 - Neural network MLP driven control loop
I ended up already writing the "forced drift" and "random walk" algorithms, these are just out of curiosity and for testing purposes, and can be replaced with more useful control loop algorithms at any time. The "primitive, very simple" control loop algorithm is the one we have now, unchanged.
-
Not a release yet, this is strictly for the adventurous. Read the WARNING.txt file!
Anyway, this new firmware has the control loop algorithms split in a separate .cpp file, so when you open the main file in the Arduino IDE, you will have three tabs: one for the main .ino file, one for the .cpp file, and one for the .h file.
If you want to write a new GPSDO control loop algorithm, you only need to include the new algorithm code in the .cpp file and add a few lines in the .h file. In other words, you (almost) don't have to worry about the 2,000 lines of code in the main .ino file! :phew:
To try the different control loop algorithms: use the command LA number where number is 0 to 9. If an algorithm is not yet programmed, then trying to switch to it will return to the default algorithm (0).
Now about the control loop algorithms:
0. The primitive_ctl_loop algorithm is what I programmed months ago, and has been the only control loop algorithm until now. It somehow works. It only updates Vctl every 429 seconds. And if you suddenly open the window in a cold winter day, this might be enough to "disturb" the OCXO by + or - 0.01Hz, and you'll notice that the control algorithm reacts a bit too slowly to sudden "jumps" in frequency. The periodicity of the updates can now be changed in the source code, so if you want to try the same algorithm with updates every 100 seconds, go ahead. This is the default control loop algorithm.
1. The forced_drift_Vctl algorithm increments the PWM DAC by 1 bit every 1000 seconds. So in theory the OCXO should slowly and regularly drift up in frequency. What is the use of this? I have no idea, but it was simple and amusing to program.
2. The random_walk_Vctl algorithm randomly increments or decrements or leaves unchanged the PWM DAC every 5 seconds, with equal probabilities. This in mathematical terms is called a "random walk" (see the article on Wikipedia) and I am curious to see how it will affect the ADEV curve of the STM32 GPSDO - when I get around to plotting anything. Again, not particularly useful but it's there as a curiosity.
3 to 9: I'll program these when I have some time. Now I need some :=\
-
The display does look cool 8)
So at this stage we can definitely answer Neal's question from two weeks ago when he still didn't have his STM32 GPSDO up and running, about whether he would need a $300,000 caesium atomic clock to measure the performance of his $50 STM32 GPSDO:
All you can do is measure the stability between two time sources, which you do for OCXO vs. NEO-M8N. The accuracy of the measurement is therefore constrained by the stability of both clock sources. Even if the resolution of your measurement may be 0.001 Hz this doesn't automatically imply that its accuracy is also 0.001 Hz.
// 3 - FLL PID control loop, coefficients set manually
// 4 - PLL PI (not PID) control loop, coefficients set manually (similar to Lars')
// 5 - PLL PID control loop, coefficients set manually
// 6 - FLL PID control loop, genetic algorithm used to find near-optimal coefficients
// 7 - PLL PID control loop, genetic algorithm used to find near-optimal coefficients
// 8 - FLL + PLL "hybrid" PID control loop, weights and coefficients set manually
A word of caution regarding PID control: Derivative control is not typically used for disciplining XOs. Both the NTP reference implementation (see RFC5905 Sec. 11.3 (https://datatracker.ietf.org/doc/html/rfc5905#section-11.3) and Appendix A.5.5.6 (https://datatracker.ietf.org/doc/html/rfc5905#appendix-A.5.5.6)) and PTPd (https://github.com/ptpd/ptpd/blob/master/src/dep/servo.c#L1063) use PI, only. The reason behind this is that without special pre-processing derivation behaves like a high-pass filter and therefore amplifies noise, i.e., the 1PPS jitter. Also, derivative control is typically only required for inert processes that are prone to overshoot, but OCXOs typically have EFC modulation bandwidths that enable instantaneous response to EFC voltage changes.
No "magic trick" exists that would make an STM32 GPSDO have any better stability (or "performance" as some would call it) with the same choice of oscillator and GPS receiver, and spending $100 on a "better" GPS receiver module or $500 on a used rubidium oscillator - if you can find one that actually works for around that price - would bring only marginal improvements in stability. :horse:
0. The primitive_ctl_loop algorithm is what I programmed months ago, and has been the only control loop algorithm until now. It somehow works. It only updates Vctl every 429 seconds. And if you suddenly open the window in a cold winter day, this might be enough to "disturb" the OCXO by + or - 0.01Hz, and you'll notice that the control algorithm reacts a bit too slowly to sudden "jumps" in frequency. The periodicity of the updates can now be changed in the source code, so if you want to try the same algorithm with updates every 100 seconds, go ahead. This is the default control loop algorithm.
Your example is precisely a case where a better GNSS receiver will bring more than marginal improvements. An order of magnitude decrease of 1PPS ADEV, e.g., NEO-M8N vs. ZED-F9T, will enable picking significantly shorter PLL time constants, therefore enabling faster response to external disturbances (like sudden temperature changes).
Update: Added RFC5905 and PTPd source code links as PI controller examples.
-
Hi,
So just a few among the latest developments in the firmware:
1. The source code now includes a long comment explaining how to calibrate the BMP280 sensor using the PO and AO commands:
/**********************************************************************************************************
* A quick note about calibrating the BMP pressure / altitude sensor in two simple steps:
* 1. Get the atmospheric pressure in hPa from the nearest weather station. Then use the PO command to
* adjust the reported value from the BMP280 until it matches that from the weather station.
* 2. Get the altitude for your location from Google Maps or similar service (or the GPS value). Then use
* the AO command to adjust the reported value from the BMP280 until it matches that from Google Maps.
**********************************************************************************************************/
This only works with firmware version 0.06c Alpha. :P
2. I have been working with Neal (nealix) to improve the integration of the ST7735 color LCD display into the hardware and software. Neal has been kind enough to repeatedly test and debug the code and the SPI bus connection to the ST7735 display, and we are reaching the point where I would say this is a fully supported feature. As usual, many thanks to badwater-Frank for pioneering this very neat feature! Check the amazing ST7735 color LCD display pictures posted above!
3. There are many changes coming in version v0.06c, but now the tentative release date is end of May / beginning of June.
// Version v0.06c:
// - The frequency measurement algorithm now uses 8-bit information about frequency offset in a single unified
// ring buffer rather than 64-bit counter data in multiple separate ring buffers. For the 10,000s data set,
// this saves 70kB of RAM, and allows using the STM32F401CCU6 Black Pill variant without any firmware changes.
// - Holdover Mode / Disciplined Mode commands implemented
// Note that in Holdover Mode the PWM DAC value can still be set manually using the SP command
// - Pressure Offset (PO) and Altitude Offset (AO) commands implemented
// - picDIV synchronization control and AP (arm picDIV) command
// - Reading TIC measuring phase difference between GPS PPS and picDIV PPS and discharge capacitor
// - STM32F401CCU6 Black Pill (lower cost version with less RAM and flash) now fully supported
// - TM1637 clock module can show UTC or local time. Local time to UTC time offset can be configured using TO command.
// - Control loop algorithms in separate file and LA (Loop Algorithm) command to choose active control loop algorithm.
For the adventurous, there is an Alpha quality (very preliminary, not fully tested and possibly incomplete) v0.06c source on GitHub, not as a release, but in a separate folder under /software.
I'll be away from the project until end of May / beginning of June, but iannez can push any urgent code fixes to the repository and I feel I can count on those of you that have built the STM32 GPSDO to answer most questions related to e.g. the new ST7735 display and/or other parts of the schematic.
So, let's keep this project going full steam ahead! Thank you all for your enthusiastic support and patience! :-+ :clap:
-
Good day,
wow - a lot of progress on this project over the past week - thanks. :) :-+
I will set some time aside for this and I am looking forward to building a 1st bread board build over the next 10 days or so...
Cheers,
THDplusN_bad
-
Hi,
I am already planning for a few changes in the source code for firmware versions v0.07 (August / September ?) and later:
1. The various display support options and the corresponding code to be moved out of the main source file, into TFT_display.cpp and Mono_display.cpp and respective header files.
2. Monochrome (OLED) display support code will continue to use the u8g2 library.
3. TFT color display support will use the TFT_eSPI library which is optimized for STM32, instead of the rather slow Adafruit GFX library. See https://github.com/Bodmer/TFT_eSPI
4. OCXO auto-calibration will change to two increasing precision steps, with the second step optional. The first step is the one implemented right now, which uses a simple interpolation to find a Vctl that results in an OCXO frequency of 10MHz +/- 0.1Hz. This rough calibration lasts a minute or two. The second optional calibration step will last some 3 to 5 minutes and will find a Vctl that results in an OCXO frequency of 10MHz +/- 0.01Hz (i.e. +/- 1ppb). Note this corresponds to the PLL "lock acquisition" phase in classic PLL designs such as Lars' DIY GPSDO.
5. Control loop algorithms implemented as C++ objects rather than functions. I promise this will make the code simpler and easier to understand and maintain!
-
Hey Andrew -
I've been working on a project on and off for a little bit. Essentially it's a Teensy 4.0 based GPSDO that "i think" has a similar design approach to yours. I started mine without knowing yours was there, but found it today and wanted to ask you some questions!
Here's my code, be warned it's very primitive still. https://github.com/trrriple/teensyGPSDO/blob/master/src/main.cpp
I wanted to ask you about the tuning strategy and see if it made sense to you. _tuneOsc() is my current algorithm in the code.
I am using a DAC8550 (16 bit) DAC to handle the control signal to the OXCO, with a LT1086CT-5 providing the 5v for the OXCO, and DAC vref. The Teensy 4.0 is powered from some random 3v3 LDO.
Fundamentally though, I modified the teensy freqCount library to allow an external interrupt (in this case the 1pps from the GPS) to flag the counter as ready to be read. This counter is connected to the 10 MHz output from a CTI 10 MHz OXCO. So essentially every PPS from the GPS, I read the counter and get the count value. Once stable, it is between 9999999 Hz and 10000001 Hz. I feel like though my frequency is bouncing between these too often, as is shown in the attached picture. Perhaps though I have unrealistic expectations.
Basically I was hoping you could point me in the right direction on what I need to start tweaking next! I'm out of ideas ;D
-
From the graphs I would say you are correcting too often and too heavily.
-
Hello Trrriple!
Seeing that designing GPSDOs is a quite popular sport here, I also started work on a couple of GPSDO designs.
My first design is very similar to yours. I'm using a MSP430 uC and PWM output, everything still in very embryonic state. I guess, you will probably beat me to the finish line with this one :-)
The problem, when using the captured value as the error signal in the PLL loop is, that with the counter running at 10MHz, we get a 100ns "blind zone". One solution I thought of, was to keep the loop on the edge between two values, the quantization error (the "sawtooth") providing the necessary dither. For example, set the VCXO so, that in 100 consecutive captures, half of the captured values will be N, and the other half N+1. Not really sure that would work, haven't yet tried.
Marko Cebokli
-
From the graphs I would say you are correcting too often and too heavily.
Hmm it could be! I'm currently correcting every 100 seconds. My current lowest possible correction (besides zero correction when the average over the last 100 samples is exactly 10 MHz) is
else if (abs(error) <= .02)
{
adjVal = .0001;
}
And .0001 V I think is about as low as I can get with a 16 bit DAC. Maybe when I'm within that bound or .01 I correct even less often?
Hello Trrriple!
Seeing that designing GPSDOs is a quite popular sport here, I also started work on a couple of GPSDO designs.
My first design is very similar to yours. I'm using a MSP430 uC and PWM output, everything still in very embryonic state. I guess, you will probably beat me to the finish line with this one :-)
The problem, when using the captured value as the error signal in the PLL loop is, that with the counter running at 10MHz, we get a 100ns "blind zone". One solution I thought of, was to keep the loop on the edge between two values, the quantization error (the "sawtooth") providing the necessary dither. For example, set the VCXO so, that in 100 consecutive captures, half of the captured values will be N, and the other half N+1. Not really sure that would work, haven't yet tried.
Marko Cebokli
Hey Marko! I'm pretty new to designing electronics, that's why I trying to force this as much as possible to be a software project hah. But to your point, yeah essentially we end up in the middle of the last pulse... it seems to follow pretty consistently when it's +1, the next one will be -1 and vice versa (but sometimes not). I'm a visual learner so I'd have to see your idea in action.
I appreciate the feedback everyone.
-
I will publish my designs in full detail, once I (hopefully) get them halfway working (which probably won't be very soon :-)
As thinkfat noted, maybe you could reduce your loop gain. For example, use a 32 bit accumulator, top 16 bits go to the DAC, the bottom 16 bits providing a "fractional" part, that would allow you to use very small loop gains in a very simple way.
Marko Cebokli
-
Hello Trrriple!
Seeing that designing GPSDOs is a quite popular sport here, I also started work on a couple of GPSDO designs.
My first design is very similar to yours. I'm using a MSP430 uC and PWM output, everything still in very embryonic state. I guess, you will probably beat me to the finish line with this one :-)
The problem, when using the captured value as the error signal in the PLL loop is, that with the counter running at 10MHz, we get a 100ns "blind zone". One solution I thought of, was to keep the loop on the edge between two values, the quantization error (the "sawtooth") providing the necessary dither. For example, set the VCXO so, that in 100 consecutive captures, half of the captured values will be N, and the other half N+1. Not really sure that would work, haven't yet tried.
Marko Cebokli
The "dithering" through the quantization error is not gaussian noise, though. That means it will not average out completely.
-
Hey Marko! I'm pretty new to designing electronics, that's why I trying to force this as much as possible to be a software project hah. But to your point, yeah essentially we end up in the middle of the last pulse... it seems to follow pretty consistently when it's +1, the next one will be -1 and vice versa (but sometimes not). I'm a visual learner so I'd have to see your idea in action.
I appreciate the feedback everyone.
Well, with this type of design, this is the best you can hope for. The control loop now needs to be tuned so that the time between the "bounces" is maximized, i.e. the drift of the OCXO against the GNSS is minimized.
-
I'm curious what the effect or reporting the average of the last two sample counts to timeLab vs always reporting the previous sample count. Or is this cheating somehow? :-//
-
Wouldn't any symmetrical distribution average out? A sawtooth is a quasi uniform distribution, should work?
I see more of a problem when the internal clock frequency passes an integer value in Hz, and the sawtooth slows down, even beyond measurement interval.
Another possibility would be to measure the time between two changes (in the same direction) of the captured value. The inverse value could then be used to do a FLL. But sawtooth could make this a bit hard? Maybe one would be able to keep the pps in the middle of the 100ns window, so that so that a +-10ns sawtooth would not hit the edges (most of the time)?
Marko Cebokli
-
Wouldn't any symmetrical distribution average out? A sawtooth is a quasi uniform distribution, should work?
If it were a perfect, zero mean, coherently sampled sawtooth it would average out over integer multiples of its period. However, in reality it's quite unlikely to meet all of these criteria. GNSS receivers' sawtooths are far from perfect (http://www.leapsecond.com/pages/m12/sawtooth.htm). That's why timing GNSS receivers typically offer additional information to correct the quantization error.
Maybe one would be able to keep the pps in the middle of the 100ns window, so that so that a +-10ns sawtooth would not hit the edges (most of the time)?
Realizing that is not trivial, because you cannot determine where within the 100 ns window the PPS edge is currently located, so within that window you cannot determine the current drift. Like thinkfat pointed out above, you can only try to minimize the transitions.
There really is no replacement for PPS time measurement resolution. A straightforward way to achieve that would be to use your MCU's timer capture, if you can lock its PLL to your OCXO's output. With the black pill that will require some hardware modification, but will give you ten times the timing resolution (10 ns). (https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg4122367/#msg4122367)
-
I've looked at a "sawtooths" from three specimens of ublox NEO 6M modules, and they look even more scrambled that the ones in your link (will attach a graph Monday, when home). However, they aren't that far from zero mean (they don't have the big steps seen in the leapsecond link - those might be specific to the Motorola receiver tested there).
Of course you can not be coherent with the period (most of the time you would be hard pressed to even see a period in there), but who cares - in a longer average, the fraction of a period cut at the beginning/end, will not greatly spoil the result.
I am not suggesting you could get "absolute precision" (like sampling an integer number of periods of a perfect sawtooth), but just about reducing the noise, by say 10 times in a few minutes average.
Yes, it will be a problem when the sawtooth gets "slow", agree there, noted that in previous post. Also saw it in real life on an Oscilloquartz GPSDO (http://lea.hamradio.si/~s57uuu/scdsp/frcomp/index.html#OSAvs5350 (http://lea.hamradio.si/~s57uuu/scdsp/frcomp/index.html#OSAvs5350)).
As for the second method, maybe it wouldn't even be necessary to keep in the middle. Just observing the change of the captured value over longer time would mostly eliminate sawtooth effects, because close to the edge, they would come in +1 -1 pairs, cancelling out most of the time.
Marko Cebokli
-
So here is a recording of the "sawtooth" ("qerr" value from the TIM-TP UBX message).
Clearly, the NEO M6 has a much worse clock oscilator than the Motorola. But that, paradoxically, seems to be better for a GPSDO.
Tomorrow I will try some averaging and maybe a histogram.
Marko Cebokli
-
Forgot to tell, the horizontal scale is one second per pixel (about 12.5 min total graph), and vertical scale is plus minus 12 ns.
-
Question re M8N UBX config message in the code;
In the source code, during startup/setup, a UBX message is sent to the M8N GPS module to set the
mode into "stationary". When I tried installing an M9N gps module on my breadboard, this part
of the project code fails. I can assume that the M9N GPS modules have changed or extended the
code needed to set the mode into stationary?
Does anyone know where I can find an example, or find details of the config commands, for both module
types, so that I can figure out what needs to change in the code? Alternatively, does anyone already
know what command code to send to a M9N module to set stationary mode?
Thanks,
Neal
-
ublox' 9th generation receivers have an entirely new configuration interface (https://content.u-blox.com/sites/default/files/NEO-M9N_Integrationmanual_UBX-19014286.pdf#page=8) and ublox recommends to use it. The old configuration message format is officially deprecated, but still kinda supported. Using the old message to set the stationary mode should still work (https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf#page=62), but I haven't tried it.
IMHO, the new configuration interface is vastly superior to the old format and I ended up rewriting my software to employ the new interface. If you want to use it, too, you have to set the CFG-NAVSPG-DYNMODEL (https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf#page=208) config key to STAT (2) (https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf#page=210). Unfortunately, I don't have the binary message for that available.
-
I made a small program to average qerr (the "sawtooth") and draw a histogram, see below.
The top graph is just the last 12 minutes of raw qerr data from the ublox, the mid graph is a running "boxcar" average over 100 samples. Works quite well!
Below is the histogram of qerr over a few hours. The peak at zero is a program bug, bad rounding (everything from -1 to +1 went into bin zero).
Note that the "scrambledness" of the qerr is not caused by bad GPS reception. I used a good antenna with practically unobstructed view of the whole sky.
On the other hand, when I replaced the ublox's internal 26MHz oscillator with an OCXO, I got a very nice sawtooth, like the Motorola in the leapsecond link.
-
...
Does anyone know where I can find an example, or find details of the config commands, for both module
types, so that I can figure out what needs to change in the code?
...
Hi Neal,
The config commands and protocols are described in detail in the rather long u-blox Receiver Description for the respective GPS receivers.
For the M8 (474 pages) : https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf
For the M9 (252 pages) : https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf
-
Here is qerr with a Telequarz 26 MHz OCXO. Clearly, this would average much worse than the jagged qerr with the original osc.
-
@Carsten and @AndrewBCN:
Thanks for the pointers on the UBLOX M9N GPS module;
CFG-NAVSPG-DYNMODEL config key to STAT (2). for setting stationary mode.
I attempted to work this programming out, for educational value, with only the UBLOX documents mentioned in the post, and a blank sheet of paper. I worked out the M9N CFG NAVSPG DYNMODEL message payload in hex
and wrote it down. Then I decided to validate this learning attempt by doing the same message in U-Center 22.02 and watching the hex message that is actually sent to the receiver module if I command it to stationary mode.
FYI, at this point, I learned that there is a mistake (two actually) in the UBLOX document. UBLOX interrface description, https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf,
on page 87, has the data structure (field definitions) for the UBX-CFG-VALSET message, used to set values in the runtime RAM database. Page 87 is wrong. At payload byte offsets 0 and 1, they claim these are one byte values,
U1 and X1 (one byte each), followed by the two bytes of reserved zeros [U1]2. In fact, while running this config message in Ucenter, the version is 2 bytes, and is equal to 0x09 at byte offset zero, followed by 0x00 at byte 01.
And next, the Layers bitmask, instead of one byte, is actually 0x00 at offset 03, followed by the actual bitmask for RAM, 0x01 at byte offset 4 in the payload. After that comes the two reserved sets of 0x00.
In U-Center I can watch both the sent hexadecimal message for configuration, along with the checksum, and also the CFG-ACK-ACK message that comes back, along with it's checksum bytes.
So U-Center proved to be a useful shortcut, and also a "Document Validation Tool" :-) I hate it when the manufacturer's programming docs are wrong. Apparently not enough employees at UBLOX to actually review
what some other person wrote, BEFORE they ship it :-)
For reference to help others, U-Center shows that it sends this string of bytes to the M9N in order to set STATIONARY mode;
B5 62 06 8A 09 00 00 01 00 00 21 00 11 20 02 EE 4B
U-center also shows that this, below, is the success acknowledge response (UBX-ACK-ACK);
B5 62 05 01 02 00 06 8A 98 C1
FYI only.
Neal
-
FYI, at this point, I learned that there is a mistake (two actually) in the UBLOX document. UBLOX interrface description, https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf,
on page 87, has the data structure (field definitions) for the UBX-CFG-VALSET message, used to set values in the runtime RAM database. Page 87 is wrong. At payload byte offsets 0 and 1, they claim these are one byte values,
U1 and X1 (one byte each), followed by the two bytes of reserved zeros [U1]2. In fact, while running this config message in Ucenter, the version is 2 bytes, and is equal to 0x09 at byte offset zero, followed by 0x00 at byte 01.
And next, the Layers bitmask, instead of one byte, is actually 0x00 at offset 03, followed by the actual bitmask for RAM, 0x01 at byte offset 4 in the payload. After that comes the two reserved sets of 0x00.
In U-Center I can watch both the sent hexadecimal message for configuration, along with the checksum, and also the CFG-ACK-ACK message that comes back, along with it's checksum bytes.
So U-Center proved to be a useful shortcut, and also a "Document Validation Tool" :-) I hate it when the manufacturer's programming docs are wrong. Apparently not enough employees at UBLOX to actually review
what some other person wrote, BEFORE they ship it :-)
For reference to help others, U-Center shows that it sends this string of bytes to the M9N in order to set STATIONARY mode;
B5 62 06 8A 09 00 00 01 00 00 21 00 11 20 02 EE 4B
Neal, you got that wrong.
B5 62: UBX header
06 8A: message class and id
09 00: payload length (4 + 5 configuration values)
00: message version
01: layer = RAM
00 00: Reserved
21 00 11 20 02: 5 configuration values
EE 4B: checksum
It's exactly as specified.
-
@ThinkFat:
Thanks for that. It looks like I misunderstood the "4+[0..n]" shown in the message structure banner in the middle of that page.
I now can see that the "4" applies to the Header and Class and ID fields. The [0..n] part is more vague, and not specifically clear
like the payload fields in the table. It would have been helpful if UBLOX simply called out the length field as 2 bytes, little endian.
Either way, watching what U-Center message bytes that were actually sent, along with your helpful reply, has made it clear.
In U-Center, I was able to issue a read/ get value, to confirm that the receiver has been set into stationary mode.
Thanks for the help,
Neal
-
OK, I found the page in the UBLOX manual that I had missed, page 43, section 3.2, makes the field length in bytes perfectly clear;
https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf
Neal
-
I don't know if it is of interest to this group, but I use a different algorithm to a PLL and it works quite well. The caveat is that the voltage change/frequency change ratio of the OCXO be known. My GPSDO runs a calibration to determine this and writes it to flash memory.
The circuitry receives the 1pps from the GPS module, times it to the nearest 25ns. If the OCXO and GPS are in sync, the difference is called 0. If there is a difference, it is measured in 25ns intervals so a difference of one cycle would be -4 or +4 depending on if the OCXO is fast or slow.
The algorithm accumulates the values in an accumulator array of 16 bit values, the array is 2 x n - n depends on the longest useful accumulation interval, the interval is 3*2^n-1 seconds. The idea is to accumulate information over 3 consecutive time intervals, then try to fit the curve at^2+b^t+c (t=time) to the curve to find out the current deviation of the OCXO. This is done over different time scales, each being 3*2^n seconds.
The shortest time is 3 seconds. The algorithm to fill the array at each scale is:
For the first received difference at the scale, fill in accumulator 1
For the second received difference, fill in accumulator 2, add accumulators 1 and 2 together and hand to the next scale
For the third received difference, do the curve calculation, determine an estimated error at the time, test it against a limit.
If the limit is exceeded, apply a correction to the control voltage. If the limit is not exceeded, make the third difference the new first difference in accumulator 1
The received difference at 2^0 is just the 25ns difference from the circuitry. For higher values of n it is an accumulation over a time period e.g. n=8 uses three intervals of 256 seconds.
In practice it is useful to nominate a maximum n, and if that interval is reached do a correction.
This algorithm has proven unbreakable. It will start disciplining after about 2 minutes of warm up of the OCXO and keeps lock from then on. After 15 minutes with an OSC5A2B02 the OCXO becomes relatively stable and the output is +-1 or 2 parts per billion of 10MHz.
-
Does anyone know of a "completed" DIY GPSDO project that;
1. uses parts or modules that are still available
2. uses a PLL rather than an FLL
3. will share schematics and code?
While waiting for Andrew to return this summer, I thought I would study and educate myself more on the PLL
option, and how it is wired, what low pass filter is used, which frequency is used in the PLL phase detector (not 1 PPS after
reading posts from @ThinkFat), and what the software does since the MCU inserts itself in the PLL loop.
Unfortunately, the more I googled down the rabit-hole, the more that I found unfinished projects, or projects
from someone who had done it but does not wish to share the code or the schematics, etc etc.
I know that LARS uses a PLL and it is a working/finished project, but his PLL is unique in that the two
frequencies compared for phase are not the same. Several other projects try to compare 1HZ and 1PPS,
but the better ones program the GPS module to put out 10Khz or even 100Khz and compare that with
the same divided down output of the OCXO.
If anyone knows of a PLL based GPSDO project that meets the 3 criteria listed above, then that should keep
me busy studying and learning until Andrew returns later on.
Cheers,
Neal
-
@nealix
Since you've had no response so far, I'll point you to a reply I made to bob near the beginning of this topic thread (page 5 reply #123) which may answer all your stated conditions (except for the 'code' since none is used) :)
-
Thanks John:
I reviewed that and it helps.
I guess an honest question for you and the rest of the forum is this: For casual home use, for test equipment and radio use, I certainly don't need more accuracy than +/- 0.001 Hertz, and Andrew's simple FLL GPS already does that just fine.
I can go build the Jame's Miller PLL GPSDO with junk box parts right now, and I might be wrong in thinking that it would also do approx +/- 0.001 Hertz accuracy, or does it's PLL do much better?
I am having trouble understanding the interest in Lar's GPSDO, since it looks like it has taken each builder weeks or months of labor screwing around and adjusting to get it stable and locking and where they want?
Or is that just for fun since they are time nuts searching for supreme accuracy beyond basic need? Certainly by comparison, Andrew's STM32 FLL and James PLL design just simply power up and work, no fuss.
Lar's design appears, to the newbie reader, like an untame race car with a loose steering wheel, sensitive to where you are, what parts you build it with, and many other variables. That reduces the value
proposition, unless it is simply about education and game?
A. No disrespect for Lar's, it is a cleaver and amazing project, but a lot of work and adjusting.
B. Sorry for this off-topic post in Andrew's thread, but I am trying to understand the need, and value, for going much further on this project (such as PLL) if it already works so well with the FLL.
I guess I don't know how to determine if there is a real need to go beyond the simple FLL design, for non-commercial simple at-home use? It seems like I already have more accuracy than I really need?
Opinions, comments, thoughts, reprimands? :-)
Cheers,
Neal
-
Well. If the current solution is good enough, the engineer in me says: "stop right there!". Going further than your needs means you'll be drifting into time-nuts territory quickly, and that's a deep rabbit hole I can tell ya.
-
Hi nealix,
I'd have replied sooner but I've been testing an SA22C which I'll be using as a 'referee' to decide whether my suspicions that the GPS might currently be suffering fall out from the Ukraine war in the form of electronic countermeasures (whether Russian or even American activities or both).
I've been testing the thermal control algorithm of an LPRO 101's base plate temperature running on a Nano3 mcu which controls an 80mm fan cooled heatsink bolted onto said base plate. Early this month, I noticed some peculiar 'one off' 10 to 20 ns phase jumps between the GPSDO's and LPRO's waveform traces. I actually caught one such event in the act!
Initially, I'd suspected a developing problem in the LPRO or the 19v laptop charging brick used to power it but, after taking the lid off the LPRO for the first time almost two years on from its initial purchase to check the lamp and clean some 20 years or more's worth of atmospheric contaminants off the glassware in a successful attempt to raise the lamp voltage and fix the low servo signal amplitude, these random "glitches" still persisted, leading me to consider the possibility that the GPS itself was being effected by the Ukraine war.
Today, I decided to disable the SBAS option which initially had shown a reduction of the ionospheric errors that normally account for most of the 7 to 8ns phase wander in the output from my G3RUH based GPSDO since I suspected this was the 'low hanging fruit' most likely to suffer the attentions of the Russian military's electronic countermeasures division.
After allowing ten minutes for things to settle down, I did see a significant improvement over the 5ns pk-pk phase wander in between the randomly spaced 'transient events' over the past 3 weeks or so. IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernised version of the G3RUH design (in peace time at least!) but bearing in mind that a 1mHz offset requires a sustained 100ps per second phase drift rate (one full cycle slip at 10MHz over a 1000 second interval), you can be the judge of that by examining the 10 screenshots taken over a 20 minute time period started just after the GPSDO had recovered from its loss of SBAS assistance (or hindrance!) that I've attached to this reply.
-
Here's what happened after that screenshot sequence was acquired. Looks like yet another 'random event' to me. >:(
The 'scope displays the date and time in the bottom right hand corner btw.
-
IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernized version of the G3RUH design...
Hi John:
You may have mentioned it previously, but where would I find a schematic for the improved version of the
G3RUH design? I should definitely build one up, as I seem to have enough parts in my bins.
Cheers,
Neal
-
IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernized version of the G3RUH design...
Hi John:
You may have mentioned it previously, but where would I find a schematic for the improved version of the
G3RUH design? I should definitely build one up, as I seem to have enough parts in my bins.
Cheers,
Neal
That reply to Bob that I pointed you to shows a picture of the circuit diagram I'd hand drawn for the MK II version. It's a high enough resolution image if you download it and use a graphics application to view or print it out on an A4 sheet.
https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg3620946/#msg3620946 (https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg3620946/#msg3620946)
Not everything in that circuit is essential to its primary function as I proved when I first lashed up a version of Gyro's minimalistic version of the G3RUH design linked to below and minimised it even further. I left out the cmos RRO opamp because I didn't have one to hand at the time and fed the PLL output straight into the EFC pin of my 13MHz square wave OCXO which fed some TTL magic to produce the required 10MHz square wave locked to the OCXO as a "Proof of Concept" exercise.
https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133 (https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133)
The main improvement arose out the u-blox gps receiver modules we were using in place of the Jupiter-T that James had used to halve the 74390 IC count of the earlier designs that phase locked directly from the 1PPS to just two ICs (actually one and a half versus three and a half 74390 ICs :)). The ublox modules could be programmed to output any frequency to the nearest Hz locked to the received 1PPS over the range of 1 to 16,000,000 Hz plus of course they had better sensitivity and supported a lot more than the Jupiter-T's limit of 12 (or was it 8?) channels.
I, as did Gyro for pretty much the same reasons, chose to PLL at 100KHz since it seemed a reasonable compromise between complexity (only single 74390 required) and odd harmonic spectral power density in the 1.7GHz band that could compromise the GPS signals if the PLL had been run at the OCXO's output frequency. I did actually experiment with PLLing at 1 and 10MHz and observed a reduction in the C/No levels. Admittedly this was with a simple unscreened wire link on a breadboard setup without the obligatory 33 ohm series resistor at the source end to tame the generation of the higher order harmonics - something I took account of when designing the MK II even though I was PLLing at a mere 100KHz via a short piece of co-ax... inside of an aluminium enclosure.
The startup accelerator circuit can be omitted if you're using a PLL TC of 1000 seconds or less and don't mind waiting some 25 to 30 minutes to achieve a stable lock (you really need to allow the OCXO a good 20 to 30 minutes for it to settle down anyway). Also, you can replace the '4046 with a 7486 quad XOR gate - I only went for the '4046 option to allow me to experiment with its three different PLL detector options, discovering that the XOR detector proved to be the best option in this case.
The connection between the OCXO's Vref pin and a resistor network tapped at 1 volt intervals allowed me to use a cheap 9999 counts Mestek on its millivolt range by measuring in my case, how many millivolts the EFC voltage was above the 2 volt tapping (the Vref pin provides an extremely temperature stable reference at low 1mA or less loadings). It's not essential (indeed your OCXO might not even have such a pin to connect to) unless you want to try the same trick to track EFC variations down to a tenth of a mV without tying up a more expensive 4 1/2 or 5 1/2 digit benchmeter).
Anyway, that should be enough to let you make a start on lashing up a gpsdo on a solderless breadboard to experiment with.
I've attached three more screenshots covering the last 5 hours of run time. I have to admit that I succumbed to temptation just after the second screen grab and tweaked it up by about 10μHz some 5 hours back. I don't think it made that much difference because it looks like the GPS swerved itself back on track about 4 1/2 hours ago and it's looked pretty much the same since then on.
I'll clear the persistence in a short while before retiring for the night to see how much it's drifted by the late morning (some 7 or 8 hours' worth of run time).
-
Today, I decided to disable the SBAS option which initially had shown a reduction of the ionospheric errors that normally account for most of the 7 to 8ns phase wander in the output from my G3RUH based GPSDO since I suspected this was the 'low hanging fruit' most likely to suffer the attentions of the Russian military's electronic countermeasures division.
After allowing ten minutes for things to settle down, I did see a significant improvement over the 5ns pk-pk phase wander in between the randomly spaced 'transient events' over the past 3 weeks or so. IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernised version of the G3RUH design (in peace time at least!) but bearing in mind that a 1mHz offset requires a sustained 100ps per second phase drift rate (one full cycle slip at 10MHz over a 1000 second interval), you can be the judge of that by examining the 10 screenshots taken over a 20 minute time period started just after the GPSDO had recovered from its loss of SBAS assistance (or hindrance!) that I've attached to this reply.
I've experimented with using SBAS, too, reasoning that it would help timing accuracy as much as it does for positioning, but I found, like you, that it doesn't help a lot. On the contrary, when I logged the TIC output from my GPSDO over a day or so, I would frequently see phase jumps of the GPS/GNSS time signal against the OCXO in the 15-20 ns range that went away when SBAS was disabled. Now I only enable it during survey-in for faster convergence of the true position. I generally found it to be a bad idea to have too many GNSS constellations enabled in a receiver and I stay clear from GLONASS in particular. GPS and Galileo coexist nicely, though, and help with having good coverage even if you antenna position is compromised.
-
@thinkfat
I'm in total agreement with all of your observations. I had some doubts over the SBAS issue until I disabled it just over 12 hours ago but not any more from what I'm now seeing in the 'scope traces. :palm:
I'd read about similar doubts over SBAS about two years ago (possibly one of your postings) but I was still making do with fake M8N modules back then when I tried testing the use of SBAS before deciding that on balance, it wasn't doing me any favours. The only reason as to why I decided to enable it again was on account I'd acquired a set of three genuine M8T modules for cheap from an Amazon seller (late last year afaicr) and had upgraded the MK II gpsdo with one and three weeks ago thought it might be worth trying the effect of SBAS once more with a timing module.
The test initially suggested this was providing a benefit during the first week but since I was still fine tuning the temperature controlling algorithm, I was probably not able to see these wobbles through those induced by my own testing until more than a week had gone by when I actually witnessed one such event taking place. I'd forgotten about the (seemingly non-) issue of SBAS hindrance by then and started hypothesising about the possibility of electronic countermeasures being used in the Ukraine as a more palatable alternative to my LPRO starting to 'go bad'.
At the time, overlooking the possibility that using the SBAS option was the cause as now seems to be the case, the only way I could prove whether it was the LPRO or some weirdness with the GPS, was to buy another rubidium oscillator, hence my purchasing, literally, the last SA22C in the shop. https://tinyurl.com/258vuuhj
It was quite a shock to discover that the supply of salvaged LPROs and the slightly less desirable second best FEI rubidium oscillators had completely dried up, leaving only the overpriced Temex units with their failing electrolytic caps which I wouldn't give tuppence for, let alone the 500 dollar and up prices being asked. I guess I've only just discovered the reason for the apparent waning of interest in DIYing a rubidium oscillator based home lab frequency standard. :( :palm:
Anyway, here's another sequence of screen grabs taken overnight which seem free of the SBAS nonsense. And, btw, just in case there is any confusion as to what the scope traces are displaying (I didn't explicitly describe them afaicr), the CH1 (yel) is the gpsdo output triggering the timebase (hence it remaining fixed in place despite the 4 to 5ns wobbles it's imposing on the LPRO trace shown in blue on CH3.
Basically, the LPRO is acting as a referee by which to judge the wobbly behaviour of the gpsdo due to mostly ionospheric disturbances that the correction data provided by the gps SV's are unable to fully cancel out. It has the benefit of not being molested by ionospheric disturbances and all the other smaller imperfections of the GPS system as a time transfer system - only the more mundane issues that plague all free running oscillators (temperature, pressure, psu voltage variations etc plus, of course, calibration error).
A rubidium oscillator offers the electronic hobbyist the best chance of generating a reference at least stable enough for the hour or so it takes to observe the disciplining action of all (bar lab grade) gpsdos. In my case, with the effects of temperature and pressure variations being almost completely mitigated, it is more than good enough for the task, even if calibration is not absolutely perfect when the calibration reference happens to be the DUT itself ::)
-
Well, it seems the funny business with the GPS looks very much like it was a consequence of enabling SBAS (hindrance) so my thanks for reminding me of your experience testing out its worth. Disabling it certainly appears to have restored the status quo as the following seven screen grabs covering the remaining four hours of the day (and 40 minutes more) seem to indicate.
I'll resist the urge to twiddle with the calibration knob until at least tomorrow afternoon simply to give the GPS a chance to show its hand.
-
Since we seem to keep hijacking André's thread for topics only peripherally related to his project, how about opening a separate GNSS timing discussion thread?
I've experimented with using SBAS, too, reasoning that it would help timing accuracy as much as it does for positioning, but I found, like you, that it doesn't help a lot. On the contrary, when I logged the TIC output from my GPSDO over a day or so, I would frequently see phase jumps of the GPS/GNSS time signal against the OCXO in the 15-20 ns range that went away when SBAS was disabled.
For the ZED-F9T I'm tinkering with u-blox explicitly warns that using SBAS can degrade timing performance (https://content.u-blox.com/sites/default/files/ZED-F9T_IntegrationManual_UBX-21040375.pdf#page=23), which is why it's disabled by default.
Now I only enable it during survey-in for faster convergence of the true position.
As a superior alternative to SBAS, you can use an RTK reference for survey in, if your receiver supports it. The majority of German states provide these free of charge (https://zentrale-stelle-sapos.de/wp-content/uploads/2022/01/20220101_Uebersicht_OpenData-768x849.png) thanks to open data laws.
-
Did anyone notice a complete 3 or 4 minutes long black out of GPS a few minutes ago (around 14:15 UTC 2022-08-17)?
I wasn't monitoring with U-blox's ucentre at the time - just spotted my gpsdo's 4 per second PPS indication of loss of sync and the consequent wiping out of the rubidium trace against that of the gpsdo with the infinite persistence that normally shows a 30ns band over 24 hour and longer periods.
I connected the usb link and fired up ucentre to check the state of play, by which time service had been resumed with 5 satellites above the 30 deg elevation threshold, suggesting it hadn't been a case of no in service satellites being available to appear above the threshold as has happened in the past when I'd been testing with 45 and 50 degree elevation mask angles.
It took some 5 or 6 minutes to settle back down after the GPS SV's had come back on line, leaving the earlier phase difference between the ruby and the gpsdo within a ns of their previous state recorded just an hour earlier as can bee seen in the attached screen shots (time stamped in BST).
Please note that the 3 or 4 ns drift between the last two screen shots are typical of the +/- 3ns disciplining 'wobble' caused largely by the combination of imprecise wide area ionosphere correction data carried in the GPS message packets and in my case, the limited averaging time of a simple G3RUH based design of gpsdo.
[EDIT]
I've double checked the antenna connections and it looks like it may well have been a connection issue with the cheap Banggood sourced Wilkinson splitter (modified with a DC-block) and/or the half meter SMA ended cables I've kept in line ever since I'd tested out a second M8T module a fortnight or so back in readiness to experiment with a long time constant version of the G3RUH setup to discipline the ruby to deal with its long term ageing drift (circa 1E-13 to 1E-14 per day).
Although antenna connection issues with my setup would appear to be the most likely cause of this loss of GPS signal event, I'd still appreciate any reports that it wasn't due to the GPS system itself dropping out during the time period in question.
In the meantime, I'll use the time honoured method of retensioning the suspect SMA-F contacts with the aid of a jeweller's loupe and a pin.
-
Did anyone notice a complete 3 or 4 minutes long black out of GPS a few minutes ago (around 14:15 UTC 2022-08-17)?
I have a log for that period that would show loss of fix, not even a glitch.
-
Did anyone notice a complete 3 or 4 minutes long black out of GPS a few minutes ago (around 14:15 UTC 2022-08-17)?
I have a log for that period that would show loss of fix, not even a glitch.
Thanks for confirming my belated suspicions. :-[
I have in times past seen half the constellation plunged into an out of service status (blue in u-centre's sky map plot) yet still generating strong signals (40 to 52 dB C/No figures) so a GPS rather than an antenna connection issue in those cases.
My initial thought this time round being that this was yet another one of those (mercifully) rare events or maybe the more common situation where the odd out of service SV had grown from its ever present count of one or two to three or more and had all congregated in the cone of view set by the elevation mask (now a more encompassing 30 deg) with no in service SVs in that privileged patch of the sky to provide a valid timing lock.
By the time I'd linked my gpsdo to my desktop pc's winXP VM via the required 5 metre long USB A to micro B link cable, the problem had gone away. It was only after posting my report and query that it occurred to me to manipulate the connections to the antenna splitter whilst monitoring the signals with u-centre to check for a pesky intermittent connection (so often the most difficult of faults to pin down) to see if I could find a more likely cause for the event that I eventually spotted a strong hint of its true nature - a bad contact in one or more of the three SMA-F connectors used by that Wilkinson combiner/splitter.
Apart from the SMA antenna socket on the gpsdo itself, all other patch cables are terminated with SMA-M plugs both ends. I've let this 'sleeping dog lie' until just this moment since I've only modded that one splitter with a DC blocking cap and wanted to minimise disruption to the GPS reference.
In hindsight, Gawd knows why, disruption is disruption and the gpsdo always resumes its original phase relationship with the ruby +/- a soupcon of disciplining wander and the imperceptible ruby drift over the twenty minutes or so that it takes to retension the contacts and allow it to settle back down after everything has been reconnected.
When I first observed this phenomena using cheap M8N modules, my initial thought had been "What a remarkable coincidence that it should phase lock so close to its earlier phase relationship with my free running OCXO despite the PLL operating at just 1% of its frequency against the 100KPPS output from the M8N.".
My instinctive thought had been to expect it to resume lock with a completely random phase offset but since I've observed exactly the same behaviour time after time over the past two years or so (and with better and better repeatability as each upgrade was applied), I have to assume that this is the mark of a true phase lock loop despite the seeming opportunity for a divide by 100 to add an element of randomness to the amount of phase offset upon resuming phase lock.
I don't know for sure but I suspect disrupting the GPS signal on an FLL based GPSDO against a stable enough independent reference such as a DOCXO or Rubidium oscillator will show a random phase offset upon re-establishing lock with the GPS timing signals. If I'm correct in this hypothesis, it would make for a simple test to check whether a GPSDO is using a PLL or an FLL algorithm to discipline its LO. >:D
-
When I first observed this phenomena using cheap M8N modules, my initial thought had been "What a remarkable coincidence that it should phase lock so close to its earlier phase relationship with my free running OCXO despite the PLL operating at just 1% of its frequency against the 100KPPS output from the M8N.".
My instinctive thought had been to expect it to resume lock with a completely random phase offset but since I've observed exactly the same behaviour time after time over the past two years or so (and with better and better repeatability as each upgrade was applied), I have to assume that this is the mark of a true phase lock loop despite the seeming opportunity for a divide by 100 to add an element of randomness to the amount of phase offset upon resuming phase lock.
I don't know for sure but I suspect disrupting the GPS signal on an FLL based GPSDO against a stable enough independent reference such as a DOCXO or Rubidium oscillator will show a random phase offset upon re-establishing lock with the GPS timing signals. If I'm correct in this hypothesis, it would make for a simple test to check whether a GPSDO is using a PLL or an FLL algorithm to discipline its LO. >:D
Isn't that how PLL work? I confess to not really understanding them, but I think of it like taking two square waves and exclusive or (XOR) them. Both low or both high, low output. opposite phase, high output. If they are out of phase by 1/4 the period of the frequency, 50% output when averaged. If that output is used as the disciplining voltage, and the control voltage required is 50% of the pulling range, then the system will settle with the two inputs offset by that 1/4. If there is an interruption, on resumption the two waves will be offset by something different, but if it is between 0 and 1/2 the period it will be in range for the PLL to take over and drag one of them back to the 1/4.
So only if the two drift apart more than 1/4 the period the frequency the PLL uses for comparison, will it jump to a different cycle to lock.
The system I use is a sort of PLL with a 1 second period. Assuming the OCXO free running with the last known control voltage is within 1 part per million (which is pretty relaxed) then it will take several days for the two to drift apart so far that (in theory) they can't be bought back in phase. In practice if the GPS gives a minute of "no fix" the GPSDO system forces a reboot. Only happened once. What happened was the 1pps is supposed to arrive inside a 1ms window, and is ignored otherwise. The OCXO I was using developed an internal fault and the control voltage input went from high impedance to 5 kohm, the circuitry couldn't correct so the OCXO drifted off eventually going outside the window. Game over.
-
@MIS42N
Your description of the way an XOR gate phase comparator (PC1 in the case of the 74HC/HCT4046 - see attached datasheet) is pretty well spot on. In the case where the PLL is comparing the reference and VCO or OCXO frequencies directly (in our case 10MHz) without the complication of a divide by 100 (1000 in the original G3RUH design), the process is exactly as you've described.
What I couldn't quite get my head around is how, despite this complication, it manages to return to within a ns or two of its original phase offset against a highly stable independent reference after half an hour or more of interruption (either by loss of the GPS/GNSS timing signals or simply from an interruption of power - the result is exactly the same).
One thing I've realised is that I've sort of got the effect of the divide by 100 ass about face as far as the OCXO goes. To slip out of phase, it has to drift by 50 cycles or more before the PLL sees its input stretched to the breaking point at 100KPPS. Even then, if it slips out of phase, it doesn't matter about which particular cycle of the 10MHz corresponds to the locked state (loss of the GNSS timing data or a cold start upon a resumption of power event), the resulting traces will (and do) look exactly the same.
That just leaves me the puzzle as to how the PLL "chooses" the exact same pulse out the 100,000 pulses synchronised exactly (give or take the 48MHz clock jitter) when an M8T (or N) is programmed to output 100KPPS. Clearly the PLL can't make such a "choice" so I'm obviously missing something (probably something blindingly obvious in my case) here. :-//
Having taken a break from writing this reply, I've had time to mull over this "conundrum" a little more and I think the key fact I've overlooked on this side of the problem is that the 100KPPS I'm using is locked and synchronised to the GPS top of the second PPS pulse and that any one particular pulse out of the 100,000 will, like the ones generated by the OCXO's divide by 100 circuit, be aligned to the original PPS top of the second pulse, any of which will repeat the same phase displacement relative to an independent high stability 10MHz reference.
My first instinct had been to expect any random but fixed offset between the GPSDO's output and an independent reference of similar stability (circa 3.32 x 10E-14) after each restart of the GPSDO. The surprising fact that the offset was anything but random after such interruptions left me with a puzzle I couldn't quite figure out without spending the time to properly analyse just what was going on, time quite frankly ICBA to spend in finding an explanation for this observed behaviour so it was just left as an unsolved puzzle until now. It just shows how wrong "instinct" can be when it comes to puzzles like this. :palm:
As for my hypothesis that an FLL based GPSDO will show a random but fixed phase offset after such interruptions, I'll leave that to be tested by those who've built one of Andrew's low cost DIY gpsdos and just happen to have a suitable independent high stability 10MHz reference oscillator to hand (very few if any, I rather suspect in this case :( ).
-
Having taken a break from writing this reply, I've had time to mull over this "conundrum" a little more and I think the key fact I've overlooked on this side of the problem is that the 100KPPS I'm using is locked and synchronised to the GPS top of the second PPS pulse and that any one particular pulse out of the 100,000 will, like the ones generated by the OCXO's divide by 100 circuit, be aligned to the original PPS top of the second pulse, any of which will repeat the same phase displacement relative to an independent high stability 10MHz reference.
I think you have your answer right there. Your 10MHz hasn't drifted perceptibly, and your 100kpps gets pulled back to match the 1pps as soon as it is available. Resume normal service.
-
@MIS42N
Your description of the way an XOR gate phase comparator (PC1 in the case of the 74HC/HCT4046 - see attached datasheet) is pretty well spot on. In the case where the PLL is comparing the reference and VCO or OCXO frequencies directly (in our case 10MHz) without the complication of a divide by 100 (1000 in the original G3RUH design), the process is exactly as you've described.
What I couldn't quite get my head around is how, despite this complication, it manages to return to within a ns or two of its original phase offset against a highly stable independent reference after half an hour or more of interruption (either by loss of the GPS/GNSS timing signals or simply from an interruption of power - the result is exactly the same).
One thing I've realised is that I've sort of got the effect of the divide by 100 ass about face as far as the OCXO goes. To slip out of phase, it has to drift by 50 cycles or more before the PLL sees its input stretched to the breaking point at 100KPPS. Even then, if it slips out of phase, it doesn't matter about which particular cycle of the 10MHz corresponds to the locked state (loss of the GNSS timing data or a cold start upon a resumption of power event), the resulting traces will (and do) look exactly the same.
That just leaves me the puzzle as to how the PLL "chooses" the exact same pulse out the 100,000 pulses synchronised exactly (give or take the 48MHz clock jitter) when an M8T (or N) is programmed to output 100KPPS. Clearly the PLL can't make such a "choice" so I'm obviously missing something (probably something blindingly obvious in my case) here. :-//
Having taken a break from writing this reply, I've had time to mull over this "conundrum" a little more and I think the key fact I've overlooked on this side of the problem is that the 100KPPS I'm using is locked and synchronised to the GPS top of the second PPS pulse and that any one particular pulse out of the 100,000 will, like the ones generated by the OCXO's divide by 100 circuit, be aligned to the original PPS top of the second pulse, any of which will repeat the same phase displacement relative to an independent high stability 10MHz reference.
My first instinct had been to expect any random but fixed offset between the GPSDO's output and an independent reference of similar stability (circa 3.32 x 10E-14) after each restart of the GPSDO. The surprising fact that the offset was anything but random after such interruptions left me with a puzzle I couldn't quite figure out without spending the time to properly analyse just what was going on, time quite frankly ICBA to spend in finding an explanation for this observed behaviour so it was just left as an unsolved puzzle until now. It just shows how wrong "instinct" can be when it comes to puzzles like this. :palm:
As for my hypothesis that an FLL based GPSDO will show a random but fixed phase offset after such interruptions, I'll leave that to be tested by those who've built one of Andrew's low cost DIY gpsdos and just happen to have a suitable independent high stability 10MHz reference oscillator to hand (very few if any, I rather suspect in this case :( ).
I'm not quite sure how your failure case would look like exactly, but a simple XOR PLL obviously cannot deal with a GNSS outage situation at all. As soon as the time signal stops, the control voltage would either become 0 or "VDD", depending on the state of the XOR output. Keeping the time signal running with no GNSS coverage is useless of course, as the output would not be more accurate or stable than the receivers internal reference.
But of course the phase of the output would return to exactly the same offset as before, why wouldn't it? That offset is pretty much defined by whatever duty cycle of the phase comparator (and thus \$V_{tune}\$) represents the target frequency exactly. It would change over time with the aging of the OCXO.
-
@MIS42N
quoted text snipped for brevity to make up for my far from brief reply
I'm not quite sure how your failure case would look like exactly, but a simple XOR PLL obviously cannot deal with a GNSS outage situation at all. As soon as the time signal stops, the control voltage would either become 0 or "VDD", depending on the state of the XOR output. Keeping the time signal running with no GNSS coverage is useless of course, as the output would not be more accurate or stable than the receivers internal reference.
But of course the phase of the output would return to exactly the same offset as before, why wouldn't it? That offset is pretty much defined by whatever duty cycle of the phase comparator (and thus \$V_{tune}\$) represents the target frequency exactly. It would change over time with the aging of the OCXO.
Not only ageing but also a surprisingly sensible ambient temperature effect on the frequency stability of the OCXOs I'm using (I now see the point of using DOCXOs :) ) This manifests itself as a shift of a few hundred μV on the median operating point of the gps disciplining voltage variations holding the ocxo on frequency.
Looking at the datasheet for the 74HC(T)4046A, it seems the other two PDs (PDs 2 and 3) are really only appropriate to keeping a full frequency range VCO locked to a reference frequency - PD1, the XOR detector is the only one suited to this application, keeping an OCXO with its extremely tiny tuning range (a few ppm at most) locked to the averaged long term timing stability of a GNSS. Also, according to the data sheet, the output will rest at half the Vdd voltage in the presence of noise (which includes the 4Hz PPS frequency I'd programmed the U-Blox to emit during a loss of GPS timing lock) or absence of input to the Sig input pin.
I'd thought I might be able alter the duty cycle of this 4Hz pulse to more closely approximate the required EFC to hold the unlocked OCXO frequency closer to the 10MHz than it otherwise does but this proved to be ineffective since it effectively equates to the "noise" condition regardless of duty cycle.
The simple XOR detector (and its software equivalent) is the best option in this case. Of course, the phase displacement whilst locked will vary due to both ageing and temperature effects but by how much is a question I've yet to try and find an answer to.
I'm primarily interested in the magnitude if this phase displacement due to the 3 to 5 degree changes in room temperature since, if this amounts to more than 2 or 3 ns's worth, it'll confuse my frequency stability measurements against the GPS reference since comparing the variation of phase between the ruby and the GPSDO is the only practical way I have to measure frequency drifts at 10MHz that are now down in the μHz range.
My impression of this temperature related shift in phase is that it is well below 5ns, quite possibly less than a ns or two at most but that's only a 'gut feeling' from my observations so far.
I've figured out a way to test my collection of OCXOs for this temperature effect. It's really only a matter of bread boarding a test circuit using a 74HC4046A and a couple of 74HC390s, to divide the ruby and the OCXO frequencies down to 100KHz, , including the LPF values in the feed to the LMV538 cmos RRO opamp that drives the OCXO's EFC pin, to simulate the setup used in my gpsdo but without the troublesome variations inherent to any GNSS derived timing signal.
That setup will give me a fixed phase relationship for a constant temperature applied to the OCXO under test (I could actually use another OCXO held to a constant temperature instead of the ruby), allowing me to test its temperature sensitivity independently of all the other effects in the gpsdo itself. It's just a matter of getting a "round tuit" to set it up.
Although the effect of ambient temperature on the GPSDO's OCXO seems an insignificant one (it gets swamped by the disciplining process), I might find an example in my collection (seven in total) with a much lower tempco that I can swap out to reduce this effect even further.
That being the case, I've even more motivation than merely satisfying prurient curiosity as to the magnitude of this phase offset variation with temperature, to actually put the effort into carrying out this test. I might discover a particularly good example with excellent immunity to ambient temperature changes that will allow me to use an even longer time constant PLL filter to reduce the disciplining induced phase shifts even further.
-
Hi!
I have been following this tread for a while and got two questions.
1. Is there a PCB layout for this project?
2. You have made the design on a STM32F411 Blackpill. Would it be possible to run this on a Bluepill with a propper STM32F103T8C6?
The reason I'm asking about the Bluepill is that i bought a bunch of them when they where 2-3$
-
There is not yet a PCB board layout. The author of the thread has taken the summer off, possibly traveling or work related.
I do not know if it would work on the blue pill. I don't think the code is using all the CPU power of the black pill, in fact
I know that it does not. Larger LCD's might eat up more CPU, but if you stick to a small OLED or even skip an LCD and
use the serial output, I don't know why it could not work. The key might be that the schematic shows 10MHz OCXO
feeding straight into the CPU on a GPIO pin. So that means your STM CPU of choice needs to be fast enough to run all
the program code, but also do so in time to count the next 10MHz cycle coming into the GPIO pin. The other thing
different about the two CPU types; You would need to check that the blue pill has the same counters and interrupt
handlers, or else modify the code.
The two main problems with the project at the moment is that the global supply chain issues have made the STM chips
almost impossible to obtain, and the author of this thread has gone missing.
That said, building the most recent version of the code and the schematic on a bread board, it works JUST FINE
using the existing FLL code and keeps within .002 Hz of frequency, which is far more than good enough for
home radio and lab usage, without the complication and endless hours of fussing around with the lars PLL for example.
This thing works as it currently is, and works well.
When and if Andrew returns to this thread he started, I was going to ask him for the PCB design library files (Kicad symbol and footprint),
for the blackpill, and then was going to have a try at learning Kicad and creating a PCB board.
Hope that helps as far as status goes.
Neal
-
Hi geggi1,
Hi!
I have been following this tread for a while and got two questions.
1. Is there a PCB layout for this project?
Not yet, no. For various reasons : lack of time, the fact that the hardware has not yet stabilized, and also the fact that it works well enough on a $5 breadboard.
2. You have made the design on a STM32F411 Blackpill. Would it be possible to run this on a Bluepill with a propper STM32F103T8C6?
The reason I'm asking about the Bluepill is that i bought a bunch of them when they where 2-3$
No, it won't work on a Bluepill without extensive modifications to the firmware. Also it works on both the STM32F401 and STM32F411 Black Pills, which are available respectively under $5 and under $10.
-
Hi,
Outstanding project thanks for sharing!
I'm currently building one myself and for now all seems running as expected, just a refreshing issue with the spi lcd so I've revert back to the I²C version. Also I've modified the psu circuit to update it with a LM7805 and adding the couple diode and polyfuse for the protection.
About the PCB, someone are currently working on one ? If not I will trying to do one myself and if it seems not too ugly I will share.
Thanks.
Mick
-
Hi,
Here is a v1 of the PCB including :
- LM7805 base psu
- AHT20 sensor
- INA219 current sensor
- SSD1306 LCD
- picDIV 1PPS output
- 10Mhz sine output
- Some status led
- ...
As a newbie on PCB designing... do not hesitate to punch me if any thing is wrong ;)
I will sent it for production and share the sources after testing if all is OK.
Mike
-
Hello team,
first I am following the project for a while and have to say thank you for Andrew and all contributor!!! :-+
Now I have ordered and received nearly all parts. So I would like to start this week with a bread-board test (just waiting for the 20K and 10microH part).
But I recognize that my GPS module has no 1pps signal out (see pic below). The module had a green LED blinking each second when the sats are received in a proper way.
Question: Can I take the 1pps signal from there? It is not buffered and came from PIN3 of the NEO-M8N-chip.
The NEO-M8N data sheet said about PIN3:
Parameter Symbol Min Typical Max Units Condition
Digital IO pin low level output voltage V OL 0.4 V I OL = 4mA
Digital IO pin high level output voltage V OH VCC–0.4 V IOH = 4mA
So just 0,4V for Low level but missing info for High level.
Any good advice?
Many thanks in advance !!!
-
Hi Tom,
Just checked on mine, the pps output pin is directly connected to NEO-M8N's PIN3 so I guess you can pickup the signal directly on NEO-M8N's pin3.
Mick
-
Hi Mick,
thank you for the fast reply and the good news so I didn't need any ops or buffer at that point.
Your PCB looks good to me! Good job!!!
Just one comment, I didn't know the size of the PCB but I would suggest to have it 100mm on one side so it could directly used for some cases (EURO-PCB).
Again thank you and lot of success with your project.
One question to Andrew.
I recognize Frequency Counter on page 3 of the KIDCAD.pdf. Is this still 'work in progress'? Not clear how it will work? I read the messages but couldn't found so much about...
If I had a wish free, (I am HAM radio operator) so I would like to see an option that allow higher/ other frequencies.. like 25/50/100 MHz. More or less a high quality signal generator.
Thank you Andrew, again for your great project.
-
Just one comment, I didn't know the size of the PCB but I would suggest to have it 100mm on one side so it could directly used for some cases (EURO-PCB).
Hi Tom,
Good point! The pcb was 91X94mm, I've updated it to 100X94mm
Thanks.
Mick
-
Team, I have a problem to compile the v 0.05j. Nearly all options are of (marked //), just the OLED is on. (Issue solve by reload of the STM32 package)
Arduino: 1.8.19 (Windows Store 1.8.57.0) (Windows 10), Board: "Generic STM32F4 series, Generic F411CEUx, BMP (Black Magic Probe), Enabled (generic 'Serial'), None, Low/Full Speed, Smallest (-Os default), None, Newlib Nano (default)"
The bold text is in red. I tried also v6 with same result. All libraries are loaded.
Have anyone an idea? Sorry my Arduino knowledge is basic level.
One remark the 'blink-sketch' runs on the board.
But just on the compiling level I run on following errors....
exit status 1
Fehler beim Kompilieren für das Board Generic STM32F4 series.
(I changed the bold area (in Arduino IDE it is red))
-
Hi Tom, hi everybody, and sorry for the long silence, I have been just overwhelmed with work.
...
Question: Can I take the 1pps signal from there?
...
Yes! :)
-
Team, I have a problem to compile the v 0.05j.
...
Did you select Black Pill STM32F411 CEU6 ?
-
Hi Andrew, welcome back :-+
thank you for the quick response.
- Yes, I have a STM32 F411 CEU6 but I guess it doesn't matter because I just test to compile (without sending to the MCU)
- I already successful install the sketch 'blink' and a blue LED blinks every second ;)
- I check all libraries several time and deselect all options except the OLED
So what could the statement 'undefined reference to `Serial1' in the error message mean? The required libraries are installed...
Maybe the Arduino IDE set up is wrong (see pic below) can you please verify?
Many thanks in advance.
-
@TomD
Just a wild guess (I'm still a newbie when using the Arduino IDE) but could it be as simple as an incorrect reference to the nano in the C runtime Library statement?
-
Team,
problem solved. The reason is not clear but after delete and re-installation of the STM32 package (this time 2.2.0) the compilation and load run well. Now I will test and implement the other options. Many thanks
Again Andrew great job! :-+
-
Thank you John,
I am a basic Arduino user and the issue was solve by reload of the STM32 package.
Thank you for your quick reply :-+
-
First test running well :-+
Next steps:
- implementing the options
- testing
- installation in a nice alu-case
;D
-
Hi All,
The PCB is here, but..... not perfect... The footprint I've made for the OCXO was reverted, the connector for the INA219 too and finally I've also reverted the pins GND and VCC on the 74HC14. I need to check if my eyes are not reverted too.... After a surgical operation with some wires all is working as expected.
Attached I've uploaded the schematic and the PCB's Gerber files (with all above issue fixed, but I've not manufactured theses PCB for testing purpose).
I've made 2 versions of the PCB :
- 1st one for 3D printed case, very similar with the version I've already manufactured, I will design a 3D case for printing soon.
- 2nd one to fit on a 100mm large extruded case, all components need to be directly soldered on the pcb except the lcd and the outputs will be connected using u.fl connectors.
EDIT 11-16-2022 : Schematic updated, to correct 74HC14 GND and VCC pins
Hope it will be useful
Mick
-
The PCB is here, but..... not perfect... The footprint I've made for the OCXO was reverted, the connector for the INA219 too and finally I've also reverted the pins GND and VCC on the 74HC14. I need to check if my eyes are not reverted too.... After a surgical operation with some wires all is working as expected.
My first PCB I did the same. KiCad thinks you are looking from the top, you think you are looking from the bottom. Newby error (lesson learned).
Your 10MHz output would stress if connected to a 50 ohm load, and may not survive a short. You put 220 ohm in series for the 1pps output, maybe do the same for the 10MHz.
Your results may be rubbish for a few days. I've found it can take a week for the OCXO to settle down.
Good work. Interested to see the results.
-
The PCB is here, but..... not perfect... The footprint I've made for the OCXO was reverted, the connector for the INA219 too and finally I've also reverted the pins GND and VCC on the 74HC14. I need to check if my eyes are not reverted too.... After a surgical operation with some wires all is working as expected.
My first PCB I did the same. KiCad thinks you are looking from the top, you think you are looking from the bottom. Newby error (lesson learned).
Your 10MHz output would stress if connected to a 50 ohm load, and may not survive a short. You put 220 ohm in series for the 1pps output, maybe do the same for the 10MHz.
Your results may be rubbish for a few days. I've found it can take a week for the OCXO to settle down.
Good work. Interested to see the results.
Hi,
Well noted for the 10MHz protection, I will do some test and update the files on the above post.
Thanks.
Mick
-
Hi ,
some remarks (just for verification purpose):
- The 10MHz rectangle output is not buffered (only the 10MHz sinus one) in the KidCAD schematic, as the 74HC14 have 6 unites I would use two of them
- I am a fan of alu-enclosure (especially for HF frequencies) I would suggest to have 100mm (or 99mm) on one side of the PCB and around 5mm gap to the electronic parts. That will allow to slide the PCB in the EU-design alu-enclosure
without additional mounting-screws. 3d print cases are not a solution for me because of the HF frequencies in my HAM radio shack.
- I would (optionally) have the 1pps/10Mhz pins also as a SMA connector output. On Ali-ex... I bought BNC-Connector to SMA connector and 100mm coaxial-cable in between. This ensure better HF radio handling and easy mounting.
just as remarks not as a critic...
One question: When I power on the OLED show long time ... 'calibrating' and then the DAC value is either very low....4k or very high 56k therefore wrong 10Mhz frequencies about 15HZ too high or low. Then the unit move the frequency in the right direction
but that will take a week to be on target level. Once the DAC was at 35k and the 10MHz was nearly correct. Any suggestion how to optimize the calibration, or deselect and take a start value of 35k? And how?
Thanks in advance
-
Hi,
About the 220 ohm resistor to protect the 10MHz output, I've tried to connect one but I've a strange behavior, the output is not anymore stable, I've about 25Hz swiping around the 10MHz with the resistor but nothing without. Someone have an idea about the issue?
Hi ,
some remarks (just for verification purpose):
- The 10MHz rectangle output is not buffered (only the 10MHz sinus one) in the KidCAD schematic, as the 74HC14 have 6 unites I would use two of them
- I am a fan of alu-enclosure (especially for HF frequencies) I would suggest to have 100mm (or 99mm) on one side of the PCB and around 5mm gap to the electronic parts. That will allow to slide the PCB in the EU-design alu-enclosure
without additional mounting-screws. 3d print cases are not a solution for me because of the HF frequencies in my HAM radio shack.
- I would (optionally) have the 1pps/10Mhz pins also as a SMA connector output. On Ali-ex... I bought BNC-Connector to SMA connector and 100mm coaxial-cable in between. This ensure better HF radio handling and easy mounting.
just as remarks not as a critic...
One question: When I power on the OLED show long time ... 'calibrating' and then the DAC value is either very low....4k or very high 56k therefore wrong 10Mhz frequencies about 15HZ too high or low. Then the unit move the frequency in the right direction
but that will take a week to be on target level. Once the DAC was at 35k and the 10MHz was nearly correct. Any suggestion how to optimize the calibration, or deselect and take a start value of 35k? And how?
Thanks in advance
The alu enclosure, the PCB gerber named "GERBER_ExtrudedCase.zip" is adapted for an extruded alu enclosure, it's 100mm large and made to fit into the case without screws.
For the 3D printed case version, I usually cover the interior of my electronic cases with copper tape grounded to the PCB.
About PWM dac value, I guess you can set it manually to 35k using the serial terminal with the command "SR 35000".
Thanks
Mick
-
Hi ,
some remarks (just for verification purpose):
- The 10MHz rectangle output is not buffered (only the 10MHz sinus one) in the KidCAD schematic, as the 74HC14 have 6 unites I would use two of them
- I am a fan of alu-enclosure (especially for HF frequencies) I would suggest to have 100mm (or 99mm) on one side of the PCB and around 5mm gap to the electronic parts. That will allow to slide the PCB in the EU-design alu-enclosure
without additional mounting-screws. 3d print cases are not a solution for me because of the HF frequencies in my HAM radio shack.
- I would (optionally) have the 1pps/10Mhz pins also as a SMA connector output. On Ali-ex... I bought BNC-Connector to SMA connector and 100mm coaxial-cable in between. This ensure better HF radio handling and easy mounting.
just as remarks not as a critic...
One question: When I power on the OLED show long time ... 'calibrating' and then the DAC value is either very low....4k or very high 56k therefore wrong 10Mhz frequencies about 15HZ too high or low. Then the unit move the frequency in the right direction
but that will take a week to be on target level. Once the DAC was at 35k and the 10MHz was nearly correct. Any suggestion how to optimize the calibration, or deselect and take a start value of 35k? And how?
Thanks in advance
Hi TomD,
First, well done! :-+ :-+
And yes, you can disable the calibration, or increase the OCXO warm up time, or optimize the calibration in various ways, and even set the DAC initial value close to the optimum for your particular OCXO, all these options are available in the source code before compilation, and you also have complete control to set the DAC value after the GPSDO has powered up and configured itself.
Check the source code, it's well commented exactly so people can experiment with it.
I am sorry that I have been so busy at work and that should continue until mid-november. :scared: plus COVID-19 twice...
-
@Scrachi (Mick):
Are you able or willing to share the KiCad footprint and symbol for the STM32 BlackPill?
I have been watching training videos for Kicad and have it installed.
I wish to try designing my first PCB for this also. But AndrewBCN got very busy with
his job before I could receive the actual footprint and schematic symbol for the BlackPill.
I suspect by watching some more videos on youtube, I could learn to make the footprint,
but if you already have it and are willing to share, that would save reinventing the wheel.
Cheers,
Neal
-
Hi Neal,
Yes sure, I've got a STM32 footprint bundle including the black Pill from here : https://github.com/piit79/Kicad-STM32
I've modified the schematic and the PCBs adding a 220ohm protecting resistor in series with the 10MHz output as recommended by MIS42N and I've finished the assembly of the 3D printed box, I will upload all this stuff later.
Mick
-
Hi,
I've finished the last version of the PCB including the 220ohm protection resistor in series with the 10Mhz output. I've also finished the 3D prited case and the assembly of everything.
Find attached the latest version of :
- The Shematic
- The PCB Gerber files for the 3D printed case
- The PCB Gerber files for the 100mm aluminum extruded
- The PDF of the front and back panel for the 3D printed case (Note it need to be printed with a scale of 105%)
- The 3D case STLs can be downloaded here : https://www.thingiverse.com/thing:5582069 (https://www.thingiverse.com/thing:5582069)
The inside of the case is covered by copper tape connected to the GND.
-
Mick, great job looks good and it works!! :-+ :-+
I searching for some support:
Please see the pic below. It seams as it would working well but I have some doubts.
1. The Frequency is the base /default freq. and without the =.xx value.
2. The PWM value is stable at 32400 (I set this value as it was the number that brings my prototype to 10MHz).
3. See the in..it before the voltage measurement
I transferred the elements from the breadboard (see earlier posted pic) to the development board (final version). Just the 74HC driver was added an the 100nF caps and a proper power supply.
I check over 2 days all parts several times ... measured the signals out (1pps/10MHz sinus and 10Mhz rec), Vctl=1,67V and sats=12 and GPS signal is fixed and green led on GPS blinking. :-BROKE
Also SW 0.5j and 0.6c tested.
Always the same ... the program loop on 'Please wait Calibrating...'. The only way is to skip calibrating in the program and than it works like on the picture. I guess without GPS disciplined..
Any hint/idea/tip? Everything is welcome
Thank you in advance
-
Hi Tom:
Personally, I have seen the firmware fail to exit the "Calibrating...." routine if the 1 PPS signal is not
getting into the STM32 CPU on the right pin, or not getting there at all.
Do you have a scope, so you could probe the GPIO pin right at the STM32 module and see if the
1 PPS pulse is showing up? Also double check that the pin# defined in the code for 1 PPS input
is the same physical pin# actually wired up on your STM32 module. (I made that mistake once :-) )
Another mistake that had the same result (failing to exit calibration), is when I connected the 10MHz
output of the crystal oven to the wrong breadboard point (wrong pin on STM32 CPU).
Again, not sure this is YOUR specific problem, but it is a good place to start for diagnosing.
Try to double-check that the 10MHZ and the 1 PPS signals are both getting into the proper pin
on the STM32 module using a scope or some other test instrument. And check that the software
code is set to use those same pin numbers for those signals.
Neal
-
Hi Neal, :-+
thank you, I took your points and measure with a scope the signals direct on the STM32 board. PA15....10MHz check, PB10....1pps check, PB9... PWM out check, PB1...Vctlin check.
Is following line defining PB10?
FreqMeasTim->setMode(3, TIMER_INPUT_CAPTURE_RISING, PB10);
I never found any other PB10 definition so it should be the only one and correct.... Version 006c line 2743
I will now install and test the Bluetooth module to see the serial monitor data under production mode....
Question: I use a DC-DC down converter to get 12V (13,9V) to 6,8V and two LM1084 to have proper 5V and 3.3V. That's a bit over the top but should create proper power.
Is the STM32 sensitive on RF or ripple on the powerline?
-
Question: I use a DC-DC down converter to get 12V (13,9V) to 6,8V and two LM1084 to have proper 5V and 3.3V. That's a bit over the top but should create proper power.
My design also uses the same scheme - nominal 12V->buck converter->7V->two LDOs->5V. The supply is split so the OSC5A2B02 and its control voltage has its own LDO to isolate it from power glitches caused by other bits. It was a worthwhile improvement, so don't think it is 'over the top'. The oscillator now doesn't glitch when equipment under test is attached, previously it was necessary to wait a minute for the system to be stable.
-
Hi MIS42N, thanks for the confirmation.
I will test with double 5V supply , one for the OCXO and one for the STM32.
Another point, I scoped the pin PA15 (10MHZ) on the STM32 coming from the resistor 180ohm and OCXO out. The OXCO is a CTI OSC5A2B02.
I measure 5V rectangle voltage (refer to the pic). Is the STM32 max voltage not 3,3V for the ADC. Did I overload the STM ADC?
As the eff voltage is 2,5V (5v/2) and just the raising signal is used ==>no problem? Right or wrong?
-
Hi MIS42N, thanks for the confirmation.
I will test with double 5V supply , one for the OCXO and one for the STM32.
Another point, I scoped the pin PA15 (10MHZ) on the STM32 coming from the resistor 180ohm and OCXO out. The OXCO is a CTI OSC5A2B02.
I measure 5V rectangle voltage (refer to the pic). Is the STM32 max voltage not 3,3V for the ADC. Did I overload the STM ADC?
As the eff voltage is 2,5V (5v/2) and just the raising signal is used ==>no problem? Right or wrong?
Sorry, can't help you there. My system is very different. Although it uses the same OCXO (the CTI OSC5A2B02) it uses a PIC16F1455 processor with a 74HC04 to buffer the 10MHz. It all runs with 5V (except the signals from the GPS are 3.3V. The PIC is happy to work with that using TTL level inputs). Originally that was the whole system, but there were problems every time the system was attached to something else. Which is why I went to 12V and a split supply (and optocoupler for the serial TX/RX). If you are interested, it's written up here: https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/). The current circuit is attached to Reply #53.
-
Hi Neal, :-+
thank you, I took your points and measure with a scope the signals direct on the STM32 board. PA15....10MHz check, PB10....1pps check, PB9... PWM out check, PB1...Vctlin check.
Is following line defining PB10?
FreqMeasTim->setMode(3, TIMER_INPUT_CAPTURE_RISING, PB10);
I never found any other PB10 definition so it should be the only one and correct.... Version 006c line 2743
Yes, PB10 is the 1PPS input (output from the GPS module).
I will now install and test the Bluetooth module to see the serial monitor data under production mode....
Question: I use a DC-DC down converter to get 12V (13,9V) to 6,8V and two LM1084 to have proper 5V and 3.3V. That's a bit over the top but should create proper power.
Is the STM32 sensitive on RF or ripple on the powerline?
Like any digital part, the STM32 is relatively immune to noise and ripple on its power supply inputs.
-
Hi MIS42N, thanks for the confirmation.
I will test with double 5V supply , one for the OCXO and one for the STM32.
As MIS42N explained, it can't hurt to separate the 5V power supplies for the OCXO and the rest of the circuit.
Another point, I scoped the pin PA15 (10MHZ) on the STM32 coming from the resistor 180ohm and OCXO out. The OXCO is a CTI OSC5A2B02.
I measure 5V rectangle voltage (refer to the pic). Is the STM32 max voltage not 3,3V for the ADC. Did I overload the STM ADC?
As the eff voltage is 2,5V (5v/2) and just the raising signal is used ==>no problem? Right or wrong?
The STM32F411CEU6 has +5V tolerant digital inputs, so no problem there, as far as I can tell. Of course, one should not feed a +5V square 10MHz signal to the STM32 internal ADC.
-
Team, problem identified :-BROKE
I ordered an entire set (GPS/MCU) and use another OCXO to fix the problem (no calibration =>loop/no frequency counting). Build the GPDSO on a breadboard.
I started with 2 resistor 10k (each) to reduce the voltage of the 10MHz and 1pps signal by 50% to the MCU. Same problem... :palm: and my scope didn't show a nice signal.
Then I use the original 100 and 180 ohm and the signal improves significant. This also solve the issue. :-DMM
So a proper handling of the 10MHZ and 1pps signal to the MCU is key otherwise you will have the same issues as I had.
Now I will solve the issue on the ready installation unit (see above). I guess a better shielding and a coax for the signals will solve the issue as well.
Thank you for your support and the great project.
PS. I love the bluetooth capability as you can control the parameter and adjust if required.
-
Team, problem identified :-BROKE
I ordered an entire set (GPS/MCU) and use another OCXO to fix the problem (no calibration =>loop/no frequency counting). Build the GPDSO on a breadboard.
I started with 2 resistor 10k (each) to reduce the voltage of the 10MHz and 1pps signal by 50% to the MCU. Same problem... :palm: and my scope didn't show a nice signal.
Then I use the original 100 and 180 ohm and the signal improves significant. This also solve the issue. :-DMM
So a proper handling of the 10MHZ and 1pps signal to the MCU is key otherwise you will have the same issues as I had.
Now I will solve the issue on the ready installation unit (see above). I guess a better shielding and a coax for the signals will solve the issue as well.
Thank you for your support and the great project.
PS. I love the bluetooth capability as you can control the parameter and adjust if required.
I strongly suspect the trouble you'd experienced lay with insufficient loading on the OCXO's output (less or not true with the buffered square wave output OCXO types). The sine wave OCXOs usually output directly from the oscillator circuit itself which will be designed to operate with a 50 to 75 ohm load (a 100 ohm load proved sufficient in my case to cure the alternating duty cycle effect I'd observed in my own GPSDO which had created a 2ns jitter on the squarer's output). Without that necessary loading, the oscillator amp is most likely to start clipping, introducing a deleterious 'latch up' effect causing a 'pogoing' effect on the sine wave's duty cycle.
Regarding the PPS output from the gps module, placing a 33 ohm 'stopper resistor' in series right at the output pin helps take the sting out of the odd order harmonics such a fast switching signal can generate (circa 2ns rise and fall times - quite impressively fast imo ::) )
-
Would you be able to upload the PCB in scale as PDF or DWG?
I was thinking about etching the PCB at home with the toner acetone method.
Hi,
I've finished the last version of the PCB including the 220ohm protection resistor in series with the 10Mhz output. I've also finished the 3D prited case and the assembly of everything.
Find attached the latest version of :
- The Shematic
- The PCB Gerber files for the 3D printed case
- The PCB Gerber files for the 100mm aluminum extruded
- The PDF of the front and back panel for the 3D printed case (Note it need to be printed with a scale of 105%)
- The 3D case STLs can be downloaded here : https://www.thingiverse.com/thing:5582069 (https://www.thingiverse.com/thing:5582069)
The inside of the case is covered by copper tape connected to the GND.
-
Hi geggi1,
Yes I can try to export it from Kikad if you know how to, please let me know. I guess on the pdf you want only the copper traces?
Mick
-
Hi,
I've exported as SVG the top and bottom layers of both PCB versions. Please see attached.
Let me know if it is ok.
Mick
-
The copper traces and component placement would be nice.
I will try to make the PCB according to the method in the link.
https://www.instructables.com/Heatless-cold-Toner-Transfer-for-PCB-Making/ (https://www.instructables.com/Heatless-cold-Toner-Transfer-for-PCB-Making/)any experiance?
Does anybody have any experience with this metode?
-
Another happy builder here. Thanks Andrew et al for putting this all together. I added a 2004 LCD display with a button that lets you move through various data screens. Your code was a breeze to work with!
-
Another happy builder here. Thanks Andrew et al for putting this all together. I added a 2004 LCD display with a button that lets you move through various data screens. Your code was a breeze to work with!
:-+
Nice build, and it seems to be working fine, plus that large display makes it easy to read. Well done !
-
Completed unit with the display mounted in a repurposed Extron ADA 4 video distribution amplifier purchased on ebay for $22 plus $15 shipping.
20 bncs in the back and 4 added in the front for sine, square, pps and counter input.
GPSDO power was taken from the existing Extron power supply.
-
Well done, very nice build ! :-+ :-+ :-+
-
Hi All,
The PCB is here, but..... not perfect... The footprint I've made for the OCXO was reverted, the connector for the INA219 too and finally I've also reverted the pins GND and VCC on the 74HC14. I need to check if my eyes are not reverted too.... After a surgical operation with some wires all is working as expected.
Attached I've uploaded the schematic and the PCB's Gerber files (with all above issue fixed, but I've not manufactured theses PCB for testing purpose).
I've made 2 versions of the PCB :
- 1st one for 3D printed case, very similar with the version I've already manufactured, I will design a 3D case for printing soon.
- 2nd one to fit on a 100mm large extruded case, all components need to be directly soldered on the pcb except the lcd and the outputs will be connected using u.fl connectors.
EDIT 11-16-2022 : Schematic updated, to correct 74HC14 GND and VCC pins
Hope it will be useful
Mick
Thanks for uploading a PCB layout, I have some on the way. Anyone in the UK wants a board I might have 3 spare ones.
Any chance of a list of parts so I can be sure I am getting the right parts. Going to order enough to make at least two. I have the optional boards just need the PIC and v-reg etc.
-
Hi,
Find attached the BOM extracted from Kikad for both version, the 3D case and the extruded case.
Mick
-
Hi,
Find attached the BOM extracted from Kikad for both version, the 3D case and the extruded case.
Mick
So I have started my shopping list. Just have a few questions.
F1 = PollyFuse = What fuse rating?
L1,L2 = L_Ferrite = Inductor with a Ferrite core. What inductance?
-
So I have started my shopping list. Just have a few questions.
F1 = PollyFuse = What fuse rating?
L1,L2 = L_Ferrite = Inductor with a Ferrite core. What inductance?
Hi,
The PollyFuse is rated 1A and the inductors 10uH
Mick
-
Thanks to @Scrachi I have now just received my boards.
Got a few bits on the post so that I can make them up.
Anyone in the UK wanting a board pls ask. I have 3 going spare at the moment.
(https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/?action=dlattach;attach=1753154;image)
-
So I have got the boards mostly assembled. But I have run into an issue with the Black Pill.
The Arduino software just won't find it. I do the Boot press reset thing and my W11 PC shows it as STM32 BOOTLOADER and the STM software finds it happily.
IDE 2.0.4
stm32duino 2.5.0
-
So I have got the boards mostly assembled. But I have run into an issue with the Black Pill.
The Arduino software just won't find it. I do the Boot press reset thing and my W11 PC shows it as STM32 BOOTLOADER and the STM software finds it happily.
IDE 2.0.4
stm32duino 2.5.0
Hi,
Make sure you have your Arduino IDE properly configured for the Black Pill, and that ambient temperature is between 20 and 25C (yes, I know that sounds odd, but it's like that). Also post a few screenshots, that will help find the problem.
-
So I have got the boards mostly assembled. But I have run into an issue with the Black Pill.
The Arduino software just won't find it. I do the Boot press reset thing and my W11 PC shows it as STM32 BOOTLOADER and the STM software finds it happily.
IDE 2.0.4
stm32duino 2.5.0
I had similar sounding issues, and found that I had to have the STM32Cube programmer application open in the background but not connected before I could program the board. Had other problems using the USB interface to program after initially flashing the board, so use an ST-Link USB interface all the time now.
Anthony
-
It's in a room that is currently 19.4C but I have moved it to onto the PC where it is warmer.
Attached are the screenshots. I think I got it right.
-
Hi mendip_discovery,
Sorry for the very late reply.
I have just re-installed a new (actually refurbished) laptop, a Thinkpad T470, with both Ubuntu Linux 23.04 and Windows 11 in a dual boot configuration.
This will be my main MCU software development machine from now on.
In Ubuntu Linux, I also manually installed both Arduino IDE 2.1.0, the STM32 board support, and STM32 Cube Programmer and tested these on a Black Pill STM32F411CEU6, and this combination works fine, I have verified that I can program the Black Pill using the Cube Programmer DFU method. The Black Pill must be put in DFU mode as usual by pressing the boot button and then connecting the USB-C cable, then releasing the boot button. One can check that the Black Pill has entered DFU mode by checking the Linux kernel messages with the dmesg command. Note that sometimes the Black Pill fails to enter DFU mode on the first try (this time it only worked for me on the second try, but I remember it taking quite a few tries sometimes). Room temperature was 21.5C.
I am next going to test the same software combo but using Windows 11 to come as close as possible to your setup.
I'll add some screenshots ASAP.
Thanks to all of you for your patience ! :-+
Notes :
1. The Arduino IDE 2.1.0 is a free download from the Arduino website.
2. The STM32 board support is automatically installed following the instructions from the STM32duino GitHub Wiki.
3. The STM32 Cube Programmer is a free download from the STM32 electronics website, but requires one to register. The registration is free.
4. To get the Arduino Serial Monitor to have permissions to communicate with the STM32F411CEU6, you have to include yourself in the dialout group, using the command:
sudo usermod -aG dialout <your user name>
-
I used the W10 laptop I keep near the sofa for when the TV is on and I need to look stuff up.
That allows me to use another STM32 driver that does work but sadly that driver won't install on W11 as it's not made for that system.
Anyway I managed to get to talk to the laptop and finally found all the files for it. It didn't like the ++.h filename so had to change the file name. But after all that it gets funny about syntax. At this point I was just pleased i had a working connection.
Tempted to find a Pi to use as that would mean Linix and then a whole new set of fun to get it to talk but at least it would allow me to do it rather than windows yeah I can see the device but I wont let you talk to it.
-
So, I just installed the same combination of software on the T470 laptop but this time in the Windows 11 partition. And it worked out of the box for flashing the STM32F411CEU6 Black Pill. However, I could not get it to talk with the serial monitor at first. After a good 40 minutes of head scratching, I decided to plug the USB cable in another USB port on the laptop, and then the USB serial interface showed up immediately as COM4. Problem solved ! :horse:
Tomorrow I shall post the screenshots for both the Linux and Windows setups.
-
Hi, I am new to designing accurate CLK. Maybe a stupid question but I am wandering why would one need (in conjunction) already very very very accurate OCXO if you have the GPS looked signal that provides even higher accuracy? Is there a specific reason for that?
-
Hi, I am new to designing accurate CLK. Maybe a stupid question but I am wandering why would one need (in conjunction) already very very very accurate OCXO if you have the GPS looked signal that provides even higher accuracy? Is there a specific reason for that?
The way it is sitting in my head it is like using a capacitor on a voltage output. It helps filter out some of the noise/spikes/jitter. Due to a multitude of things that happen with the signal path from there to here the GPS 1pps and even the location flickers about a bit.
Plus also the GPS generated a 1pps signal aka 1 Hz and using the OCXO you can get a 10MHz signal which is what a lot of test gear can accept as a reference signal.
-
Hi, I am new to designing accurate CLK. Maybe a stupid question but I am wandering why would one need (in conjunction) already very very very accurate OCXO if you have the GPS looked signal that provides even higher accuracy? Is there a specific reason for that?
There's a difference between accuracy and stability. An OCXO is stable, provides a constant frequency. But that frequency may not be accurate. A GPS is accurate measured over hours. But not stable second to second.
-
Clear 👍 As what I have seen, in short, that a OCXO is voltage controlled. It would be then a good thing to have some register / memory to remember the right setting, once you have a good GPS reception. In that way the output of the OCXO would stay reasonably accurate until the next "good reception". I have seen one design example where the GPS 10MHz output is the whole time compared with the 10MHz output of the OCXO, and the difference fed back to the OCXO voltage input to adjust the output. But if the GPS output is not stable the whole time you just shift the instability directly from one place to another.
-
Clear 👍 As what I have seen, in short, that a OCXO is voltage controlled. It would be then a good thing to have some register / memory to remember the right setting, once you have a good GPS reception. In that way the output of the OCXO would stay reasonably accurate until the next "good reception". I have seen one design example where the GPS 10MHz output is the whole time compared with the 10MHz output of the OCXO, and the difference fed back to the OCXO voltage input to adjust the output. But if the GPS output is not stable the whole time you just shift the instability directly from one place to another.
I think you have some research to do. There are many designs that have 'hold over' capability - remember the last good control voltage and apply it until it can be verified by GPS.
The short term instability of GPS receivers is overcome by averaging. This can be done by analog means, a phase locked loop, or by digital means (like the method in this thread). It can also be mitigated by using timing GPS modules that are 'surveyed in' to a particular location then they compensate for any apparent deviation caused by atmospheric changes, swapping satellites, etc. This can be further refined by receiving on two bands (L1 and L5? don't remember the detail) which can be used to further reduce uncertainty.
The simplest GPS + OCXO combinations will usually generate a frequency accurate to 1 part in 10^9. Very expensive OCXO may achieve this accuracy for weeks but will eventually drift. With a GPSDO, 1 part in 10^10 is common. Absolute time is not easy as it requires an accurate clock to set the time in another clock. However, GPS will give time to within a microsecond or better. For interval timing GPS + OCXO is much simpler, within 30ns without much trouble.
Did you have an application, or just thinking about it. There are many, many designs so it is unlikely you can raise a question which someone has not already answered.
-
Thanks for elaborate answer. Today I have received the NEO-8 and will start the research with that, as I have no experience with GPS. As this is very popular subject I believe that there are a lot of different designs. It is also interesting to develop your own design.
-
Thanks for elaborate answer. Today I have received the NEO-8 and will start the research with that, as I have no experience with GPS. As this is very popular subject I believe that there are a lot of different designs. It is also interesting to develop your own design.
Yes, see also
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/1150/ (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/1150/)
And
https://github.com/erikkaashoek/Arduino_SI5351_GPSDO (https://github.com/erikkaashoek/Arduino_SI5351_GPSDO)
The added Time Interval Capture using a FF and diode helps improve lock by ‘seeing’ the GPS correction steps, and also lets you see the correction in action. 20 second corrections seemed to be a good trade off, in #2
I ran up a spice variant of that TIC using a 74LVC1G80 !FF and 74LVC1G38 open drain NAND gate that eliminates the diode (but flips the phase polarity, easily corrected in the MCU)
And for a hardware only approach ( no MCU ) PLL this thread has some options
https://www.eevblog.com/forum/projects/gpsdo-question-378182/msg4877936/#msg4877936 (https://www.eevblog.com/forum/projects/gpsdo-question-378182/msg4877936/#msg4877936)
-
I just found this thread recently and decided to give this GPSDO design a try. I acquired an OSC5A2B02 OCXO, a Neo M8N, and a GPS antenna from AliExpress. The Black Pill I already had.
For fun and simplicity, I decided to build an absolutely bare bones, super lazy version of this GPSDO on a breadboard. Picture is attached. It is really is the simplest/laziest version I could put together. It has just the STM32 Black Pill, the Neo M8N module, the OCXO, and six passives. I didn't have any 22k resistors handy for the DAC so I changed it to use 10k resistors and 22uF caps (same time constant as 22k and 10uF). Also didn't have a 180 ohm resistor for the series resistor for the 10MHz so I used a 220 ohm instead. I didn't add any decoupling caps at all. Again, this is super low effort. I commented out most of the hardware options in the sketch (see attached screenshot).
So far, it seems to be working. The only possible issue I've noticed is the averages (10s, 100s, 1000s, 10000s) are always zero. Any ideas what might be happening there?
Back in the first few pages of this thread, someone was very concerned about needing a proper PCB and getting all the exact components, etc. I wanted to put this very minimal version together on a breadboard to show how simple it is to test out this project.
-
So far, it seems to be working.
I started out with a simple design (not this one) and it "worked". But it depends on what you mean by working. Unfortunately it is quite difficult to determine how well a GPSDO works, except by comparison with a better source. Which most people don't have.
I ended up with a more complex design isolating the OCXO with a separate supply and buffering the control voltage. A big improvement.
Of course, it depends on if you want the GPSDO for something, or just messing about. Even a messing about version tends to be more accurate than any standalone oscillator. And that is good enough for many people. I know my first design is being used as a standard by other people. They consider it "good enough".
-
I just found this thread recently and decided to give this GPSDO design a try. I acquired an OSC5A2B02 OCXO, a Neo M8N, and a GPS antenna from AliExpress. The Black Pill I already had.
For fun and simplicity, I decided to build an absolutely bare bones, super lazy version of this GPSDO on a breadboard. Picture is attached. It is really is the simplest/laziest version I could put together. It has just the STM32 Black Pill, the Neo M8N module, the OCXO, and six passives. I didn't have any 22k resistors handy for the DAC so I changed it to use 10k resistors and 22uF caps (same time constant as 22k and 10uF). Also didn't have a 180 ohm resistor for the series resistor for the 10MHz so I used a 220 ohm instead. I didn't add any decoupling caps at all. Again, this is super low effort. I commented out most of the hardware options in the sketch (see attached screenshot).
So far, it seems to be working. The only possible issue I've noticed is the averages (10s, 100s, 1000s, 10000s) are always zero. Any ideas what might be happening there?
Back in the first few pages of this thread, someone was very concerned about needing a proper PCB and getting all the exact components, etc. I wanted to put this very minimal version together on a breadboard to show how simple it is to test out this project.
Very nice minimalistic build, thanks for the pictures.
There is a problem somewhere because the OCXO frequency averages are not being calculated. This task is performed by function calcavg() in the code, once per second since it is called from the interrupt service routine that is triggered by the PPS from the GPS. I'll have to think about it for some time to get an idea about what could be causing this.
As you have proved, the STM32 GPSDO does not require a PCB and has quite good flexibility regarding the analog components values. I would still add at least a couple of decoupling capacitors around the OCXO. ;)
-
But it depends on what you mean by working.
I mean the firmware seems to be functioning (apart from the averaging) and the system as a whole seems to be doing what it's meant to do. Performance testing the system is another matter.
I ended up with a more complex design isolating the OCXO with a separate supply and buffering the control voltage. A big improvement.
I have read through the excellent notes you've posted in your own thread and found it all very educational!
Of course, it depends on if you want the GPSDO for something, or just messing about. Even a messing about version tends to be more accurate than any standalone oscillator. And that is good enough for many people. I know my first design is being used as a standard by other people. They consider it "good enough".
At this exact moment, I'm looking for "good enough". I just installed an ebay OCXO upgrade into my HP 53131A counter and I need a GPSDO to calibrate it. I think this will work sufficiently well for that purpose (for the moment at least). A bit later, I'd like to put a proper PCB together and blend some aspects of Andrew's design and yours to squeeze a bit more performance out. I'm not NIST, just a humble engineer looking to learn something and build myself a nifty tool in the process!
Very nice minimalistic build, thanks for the pictures.
There is a problem somewhere because the OCXO frequency averages are not being calculated. This task is performed by function calcavg() in the code, once per second since it is called from the interrupt service routine that is triggered by the PPS from the GPS. I'll have to think about it for some time to get an idea about what could be causing this.
As you have proved, the STM32 GPSDO does not require a PCB and has quite good flexibility regarding the analog components values. I would still add at least a couple of decoupling capacitors around the OCXO. ;)
Thank you for the effort you've put in to date! I've been on the fence for a while about whether to pull the trigger on buying one of the Chinese ebay GPSDOs. But I much prefer the idea of open source design that can be tweaked to one's specific needs and can incorporate lessons learned from everyone else's experience.
And of course, when I get around to making a PCB, there will be plenty of decoupling caps :-+
Shortly after my post yesterday, I transferred the GPSDO to the basement and hooked it up to my HP 53131A. Both the GPSDO and the counter are connected up to a Raspberry Pi so I can check on them remotely. Pics attached. The 53131A is taking frequency measurements of the GPSDO with a 10-second gate time.
And yes, a scope probe may not be the best way to attach the GPSDO to the counter and I've looked into better ways (https://www.sitime.com/support/resource-library/application-notes/an10028-probing-oscillator-output (https://www.sitime.com/support/resource-library/application-notes/an10028-probing-oscillator-output)).
At the end of the week, after everything has calmed down, I'll run through the calibration for the HP 53131A.
-
Again, I cannot thank you enough for this "minimalistic" build. It's great to see that with a reduced set of components one can still get a GPSDO that can be used as a frequency reference.
However, I still think there is a problem with your build, probably a very small detail that is preventing the GPSDO from working as it should. Are you certain the OCXO is getting effectively "disciplined" ? What I mean by this, is the PWM DAC voltage varying at all? The "disciplining" depends on the average frequency calculations and these don't seem to be happening. So I would guess the OCXO is not getting disciplined, in other words, the GPSDO is not working. Could you perhaps check the PPS pulse from the GPS with your scope, at the B10 pin on the BlackPill? Also there are a few lines in the code in the frequency reporting routine that I had used for debugging and then commented out, but they are still there. Perhaps uncommenting them and recompiling/reflashing the MCU would shed some light on the issue, if it's not too much work?
-
AndrewBCN, to start with I checked the 1PPS signal and it is definitely there.
Next, I started monitoring Vctl with my 6.5-digit DMM and it does indeed seem to be varying, so the PWM is doing something. Here is some example data. I'm not sure if this is varying too much or not enough. This is sampling about once per second:
1.8132967
1.8132742
1.8132219
1.8132194
1.8132643
1.8132418
1.8132917
1.8132992
1.8133116
1.8132169
1.8132593
1.8132692
1.8132393
1.8132568
1.8132817
1.8132842
1.8132169
1.8132593
1.8132269
1.8131371
1.8132443
1.8132368
1.8132343
1.8132219
1.8131795
1.8132293
1.8131895
1.8131895
1.8132618
1.8132842
1.8132792
1.8132169
1.8132742
1.8131620
1.8131720
1.8132368
1.8132493
1.8132443
1.8132393
1.8132593
1.8132119
1.8132044
Finally, I looked for your debugging code and I think I uncommented all of it. Here is the output I'm getting now:
Fix time 994mS
Uptime: 000d 00:18:49
New GPS Fix:
Lat: 38.XXXXXX Lon: -85.XXXXXX Alt: 188.7m
Sats: 7 HDOP: 1.31
UTC Time: 15:35:05 Date: 30/8/2023
Voltages:
VctlPWM: 1.86 PWM: 38229
Vdd: 3.27
Frequency measurements using 64-bit counter:
TIM4 ARR: 47999
TIM4 ch4 CCR: 28000
Most Significant 32 bits (OverflowCounter): 1
Least Significant 32 bits (TIM2->CCR3): 2622916214
64-bit Counter: 6897883510
Frequency: 10000000 Hz
10s Frequency Avg: 0.0 Hz
100s Frequency Avg: 0.00 Hz
1,000s Frequency Avg: 0.000 Hz
10,000s Frequency Avg: 0.0000 Hz
Something else worthy of note: When the micro is reset, the first couple blobs of status output DO show a non-zero value for the 10s average but then it goes back to zero. One time, I also observed a non-zero value for the 10s average after the thing had been running for several hours but it went right back to zero on the next output.
I've checked the schematic to see if I may have missed any connections and I'm continuing to check the breadboard, but so far haven't seen my mistake if it's there.
Appreciate your help!
-
Thank you for the debugging ! An important question: do you see the 64-bit counter increasing by 10 million every second? If you do, that essentially means the OCXO is working and the MCU is correctly counting the OCXO oscillations, which is the basis for the frequency calculations.
If you do indeed see the 64-bit counter increasing by 10 million per second, then I suspect you have found a bug lurking in my code and I'll try to reproduce your build here at home and check whether I have the same problem of missing frequency averages. It's highly likely that I should get exactly the same problem. And then I can start looking for the bug.
Fascinating! In any case, thank you for the build and for launching this investigation. :-+
Just a note: did you check the +5V fed to the OCXO? :-DMM
-
Thank you for the debugging ! An important question: do you see the 64-bit counter increasing by 10 million every second?
It sure is increasing by 10e6 each second, so that part at least is working.
Just a note: did you check the +5V fed to the OCXO? :-DMM
Doh! Good catch! The 5V rail was sitting at about 4.6V. I have it hooked it up to my bench supply now and it's measuring a solid 5V. That's dropped Vctl down to about 1.78V and the output frequency as read by my (still uncalibrated) frequency counter with OCXO timebase is sitting pretty stable at 10000000.912n. Last digit is still slowly wandering by a few 100 micro-Hertz. Even with a possible bug in the code, this still pretty neat! 8)
-
Progress! Averaging is now working!
What I had to do was uncomment a compiler define for a screen. I initially tried enabling GPSDO_OLED, which seemed to sort of working but slowed the serial output down to once every 30 seconds to 1 minute. Not really useable but the averaging did seem to be working. So then I tried disabling GPSDO_OLED and enabling GPSDO_LCD_ST7735. Bingo! Serial update rate is back to once per second and averaging is now working.
Let me just be clear, I did NOT actually connect an LCD. I haven't changed anything from my initial breadboard layout. I just turned on the compiler define for the ST7735 LCD. So it seems maybe there is an issue where averaging isn't working unless one of the LCD or OLED defines is enabled.
With averaging working, I'm observing that the GPSDO seems to be steering the OCXO frequency more noticeably. Things are looking better!
-
Well done! :-+
This proves you have really found a bug in my code. It seems that when the main loop loops too fast, the GPSWaitFix() function concludes (erroneously) that the GPS fix was lost and clears the averaging buffers. :bullshit:
Or at least that's my analysis for now. :o
I am still putting together a minimal build to further debug this issue, but your workaround should work for now and you should be getting a more precise "disciplined" 10 MHz reference frequency.
-
Minimal build assembled and powered, and lo and behold, as expected, all the frequency averages are zeroed. :scared:
I'll be debugging the problem in the coming days. :-/O
-
Well done! :-+
This proves you have really found a bug in my code. It seems that when the main loop loops too fast, the GPSWaitFix() function concludes (erroneously) that the GPS fix was lost and clears the averaging buffers. :bullshit:
Or at least that's my analysis for now. :o
I am still putting together a minimal build to further debug this issue, but your workaround should work for now and you should be getting a more precise "disciplined" 10 MHz reference frequency.
Hehe, let me guess: you rely on counters for timekeeping instead of a constant timer tick ;)
-
I have sort of confirmed my earlier hunch about the bug being triggered by the main loop looping too fast.
I have compiled a debug version of the GPSDO firmware with a
delay(200);single extra line in the main loop. This wastes 200ms inside the main loop.
As expected, the minimal GPSDO now correctly calculates and reports the average frequencies.
But that's not solving the bug, which clearly lies inside the gpsWaitFix() subroutine. I think I'll have to take a good look at gpsWaitFix() and perhaps rewrite it. :-// (meaning this will take some time)
Apart from that, since the temperatures here in France are exceptionally high, I have not managed to enter DFU mode on my various Black Pills, so I am using and recommend a clone or original ST-LINK V2 adapter (around $5) to flash the STM32F411CEU6 Black Pills used in this project. This works like a charm, irrespective of ambient temperature. See picture below.
-
I think I'll have to take a good look at gpsWaitFix() and perhaps rewrite it. :-// (meaning this will take some time)
Appreciate you working on it!
Apart from that, since the temperatures here in France are exceptionally high, I have not managed to enter DFU mode on my various Black Pills, so I am using and recommend a clone or original ST-LINK V2 adapter (around $5) to flash the STM32F411CEU6 Black Pills used in this project. This works like a charm, irrespective of ambient temperature. See picture below.
I flashed WeAct's custom version of the STM32 HID bootloader to my Black Pill a long time ago.
https://github.com/WeActStudio/STM32_HID_Bootloader/releases/tag/2.2.2
You have to hold down KEY while pressing NRST to start the bootloader before pressing Upload in Arduino IDE, but it saves me having to worry about how warm the room is and it means I don't need STM32CubeProgrammer installed.
-
Hi everybody,
Just a quick progress report. So after examining the code for the gpsWaitFix() subroutine and the main loop, I have decided to completely rewrite both, and that actually means rewriting two of the most important functions in the STM32 GPSDO firmware.
And I realized that I had a very serious problem, because I am trying to read and parse the messages from the u-blox GPS module while juggling all the other tasks that are required by the GPSDO, such as displaying the status on various displays, reading the sensors, and transmitting a status report over USB serial every second.
I revisited the FreeRTOS webpage and noticed there is now an STM32duino version of FreeRTOS, meaning it is possible to use the FreeRTOS constructs in an Arduino sketch for the STM32 series of MCUs.
FreeRTOS implements tasks, a scheduler, semaphores, etc and enables the programming of multiple threads on an MCU.
Short story long, the STM32 GPSDO firmware is going multi-threaded and I will be having a lot of fun while rewriting a good part of the STM32 GPSDO firmware using FreeRTOS. So that's what's in the pipeline for firmware version 0.07a. I expect this to take at least a couple of months if not longer, and if anyone wants to join in the fun, please do!
The first step is to reorganize the main loop() and gpsWaitFix() functions into various tasks and schedule these tasks correctly, and also determine how these tasks are triggered, etc.
A final note: I have switched from the "old" Arduino IDE 1.8.13 to the "new" Arduino IDE 2.2.1 as my main development tool for the STM32 GPSDO firmware and it is working 100% fine. Also I am using an ST-LINK V2 clone to flash the STM32F411CEU6 Black Pill, as I found it more reliable (but unfortunately slightly less practical) than the DFU method.
-
FYI- stm32duino supported the FreeRtos some ~7-8years back already..
https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries
-
This is another option you may want to look at in comparison to FreeRTOS:
https://github.com/arkhipenko/TaskScheduler
It may be simpler to use than FreeRTOS. Unless, of course, you just really want to learn FreeRTOS, which is okay too!
-
Short story long, the STM32 GPSDO firmware is going multi-threaded and I will be having a lot of fun while rewriting a good part of the STM32 GPSDO firmware using FreeRTOS. So that's what's in the pipeline for firmware version 0.07a. I expect this to take at least a couple of months if not longer, and if anyone wants to join in the fun, please do!
Welcome to a world of hurt.
-
[attach=8]Thanks to Andrew for this great project! I wanted to share my build. For my use case, I need the GPSDO in a more permanent, rugged box. I designed a PCB to fit a common 100 x 76 x 35mm project box that I use.
The OCXO I used is the OSC5A2B02 that rhb brought to my attention in https://www.eevblog.com/forum/metrology/low-cost-lt1-ppb-10-mhz-oxcos-on-ebay/ (https://www.eevblog.com/forum/metrology/low-cost-lt1-ppb-10-mhz-oxcos-on-ebay/)
The end plates of the enclosure are replaced with custom PCB panels with cut-outs for the BNC jacks, OLED display, antenna, etc.
The trickiest part was fitting in the OLED display. There is just barely enough room to fit it in. I used small black nylon nuts and bolts to mount the display to the front PCB panel.
In the end, I was very happy with how the build turned out!
I've put the Diptrace design files and the gerbers up on Github: https://github.com/vindoline/STM32-GPSDO_build (https://github.com/vindoline/STM32-GPSDO_build)
-
Thank you very much and congratulations, vindoline, this is an absolutely gorgeous build. :-+ :-+ :-+ :-+
I am working again on the firmware these days, hopefully it will upgrade the performance of the GPSDO even further when it is ready! :-/O :-/O
-
Andrew -- cool project. I have all the components on order from AliExpress and will try to put everything together in the next few weeks.
I wanted to chime in regarding your planned switch to FreeRTOS. I would personally try to avoid that, as concurrent execution can be its own can of worms. It's easy to introduce subtle non-deterministic bugs in threaded code, and debugging that code can be hard.
Instead, have you thought about making your gpsWaitFix() function non-blocking? You could essentially call it with every iteration and let it process whatever bytes are available. You could rename the function to gpsProcessData() and return true when a gps fix is available. The main loop could then keep track of how long it has been since gps updated and act accordingly. Something along the lines of:
bool processGpsData() {
if (!Serial1.available()) return false;
while (Serial1.available() > 0)
{
GPSchar = Serial1.read();
gps.encode(GPSchar);
...
}
return (gps.location.isUpdated() && gps.altitude.isUpdated() && gps.date.isUpdated());
}
and in your main loop
if (gpsProcessData()) {
// Got a new fix, handle it
...
gpsStartFix = millis();
} else {
if (millis() - gpsStartFix > gpsWaitTimeMs) {
// Handle missing fix
}
}
Again, the point is to make GPS reception non-blocking, which should hopefully make the main loop easier to reason about. You could make similar changes to other parts of your code, such as sending out USB reports (i.e. you could pre-populate a buffer with the data that you need to send and only transfer as much per iteration as availableForWrite() allows).
Does this make sense, or did I misunderstand the nature of the issues that you are having with the current code?
Hi everybody,
Just a quick progress report. So after examining the code for the gpsWaitFix() subroutine and the main loop, I have decided to completely rewrite both, and that actually means rewriting two of the most important functions in the STM32 GPSDO firmware.
And I realized that I had a very serious problem, because I am trying to read and parse the messages from the u-blox GPS module while juggling all the other tasks that are required by the GPSDO, such as displaying the status on various displays, reading the sensors, and transmitting a status report over USB serial every second.
I revisited the FreeRTOS webpage and noticed there is now an STM32duino version of FreeRTOS, meaning it is possible to use the FreeRTOS constructs in an Arduino sketch for the STM32 series of MCUs.
FreeRTOS implements tasks, a scheduler, semaphores, etc and enables the programming of multiple threads on an MCU.
Short story long, the STM32 GPSDO firmware is going multi-threaded and I will be having a lot of fun while rewriting a good part of the STM32 GPSDO firmware using FreeRTOS. So that's what's in the pipeline for firmware version 0.07a. I expect this to take at least a couple of months if not longer, and if anyone wants to join in the fun, please do!
The first step is to reorganize the main loop() and gpsWaitFix() functions into various tasks and schedule these tasks correctly, and also determine how these tasks are triggered, etc.
A final note: I have switched from the "old" Arduino IDE 1.8.13 to the "new" Arduino IDE 2.2.1 as my main development tool for the STM32 GPSDO firmware and it is working 100% fine. Also I am using an ST-LINK V2 clone to flash the STM32F411CEU6 Black Pill, as I found it more reliable (but unfortunately slightly less practical) than the DFU method.
-
Really neat construction Vindoline! Have you guys run comparisons between one of these very simple GPSDOs and something like a rubidium? I have a James Miller Simple GPSDO (http://www.jrmiller.online/projects/ministd/manual.pdf (http://www.jrmiller.online/projects/ministd/manual.pdf)), A Leo Bodnar GPSDO (https://www.leobodnar.com (https://www.leobodnar.com)) and a Murray Greenman one (https://www.qsl.net/zl1bpu/PROJ/NGPSDO/New%20GPSDO.htm (https://www.qsl.net/zl1bpu/PROJ/NGPSDO/New%20GPSDO.htm)).
The latter was described at great length on this forum, mostly in the Lars Walenius version that it is based on.
While any of them work reasonably well, by using a really good oven and a timing GPS module, the short term stability can be significantly improved. My own Murray Greenman GPSDO with an NEC oven oscillator and a UBlox Neo M8T module, has up to ten times less short term "jitter" than either of the other two, as measured with a phase frequency analyser and a rubidium oscillator. Most of the measurements I see on the web relate to longer term Allan Deviation, I am more interested in the short term stability as mine is used to control amateur radio transceivers and frequency counters.
The Lars or Murray GPSDO is still pretty simple to make...
SJ
-
Thanks for the numerous and excellent suggestions, kff, I still have to set aside a few hourss to go through the code, but unfortunately other matters have higher priority these days. I'll certainly look into your code fix for the GPSWaitFix() function, and I agree that it is much simpler than a switch to FreeRTOS. :-+
-
I found this thread a few weeks ago and have read most of the 36 pages of it. I just got all the bits and pieces and finished bread-boarding it this afternoon. I have run into a problem though. When it is turned on, it goes through the OCXO warmup routine and starts the initial calibration, but then it is stuck on the "Calibrating... please wait" screen interminably. The GPS receiver achieves satellite lock (as evidenced by the LED pulsing once per second and I do have a 1PPS signal when checking on the oscilloscope. I bought the Neo M8N on Aliexpress, but it actually appears to be an M7 labelled as an M8N (both windows and u-center identify it as M7). Could this be the problem? Does the Arduino code for the M8 not work on an M7? if that is not the problem, what else could it be?
-
Regarding Chinese copy fake Ublox modules. I bought a cheap board from eBay which was advertised is “Ublox Neo-M7N”, there was a sticker on the module pretending it was a Ublox Neo-M8N… U-Center reported it as a 7.
As the board suited my purpose, I removed the fake and bought a genuine M8T (the timing version of an M8) from Mouser… not cheap! Removing one of these fakes needs care. Soldering a replacement is easy once you have the fake off the board.
Whether it is worth the effort depends on how deep your pockets are. The difference between the two types is shown in the attached image. The board used in the comparison uses a Chinese copy Neo-M6, which had identical performance to the M7N that was removed.
I setup my modules using U-Center, not via the software commands discussed in this thread.
The setup is:
Lars Wilenius GPSDO with an NEC Toyocom TCO-6703N 10 MHz ovened osc.
Antenna is a roof mounted “mushroom” type.
The M6 uses only GPS satellites, the M8T is configured for fixed location with SBAS turned off, GPS and Galileo satellites both used together.
TinyPFA phase frequency analyser connected to TimeLab software. These are low cost instruments based on the TinyVNA H4 (only difference is user swappable firmware), with a noise floor around 10^13, costing 65 GBP plus postage (https://www.mirfield-electronics.co.uk/ (https://www.mirfield-electronics.co.uk/)).
The comparison oscillator is a rubidium fed into the B input of the PFA.
The magenta trace is using an M8T, the blue is with a fake M6. Longer loop times reduce the frequency excursions, but you see the difference easily with 60 second timing and some averaging in TimeLab.
SJ
-
Yikes, the cheapest M8 module on Mouser is $27. M8T is $96. Is it safe to assume then that any ~$10 M8 module sold on AliExpress is fake? I have two different M8 modules on order, will report back regarding their authenticity. Has anyone here recently bought M8 modules from AliExpress and been able to confirm that they are genuine?
-
Similarly, questioning how the WeAct AliExpress $4 BlackPill can be authentic, when just the STM32F411 microcontroller is $5 on DigiKey in quantity of 5,000. Apparently there are multiple STM32 clones made in China. Any reason not to suspect this is one of them?
-
Hi everybody,
Just a quick progress report. So after examining the code for the gpsWaitFix() subroutine and the main loop, I have decided to completely rewrite both, and that actually means rewriting two of the most important functions in the STM32 GPSDO firmware.
And I realized that I had a very serious problem, because I am trying to read and parse the messages from the u-blox GPS module while juggling all the other tasks that are required by the GPSDO, such as displaying the status on various displays, reading the sensors, and transmitting a status report over USB serial every second.
I don't know anything about your software environment, but this may be useful. My design has the same constraints - parse the GPS messages, detect user input, output data. Some of the interrupts are short enough they can be serviced without stalling other code. An example is the serial output - the interrupt says a character transmission is complete, the ISR just loads the next character - all over in a couple of microseconds at most. Parsing the GPS NMEA messages takes too long (There's an interrupt every 25us that cannot be missed) and is an ongoing task so when the GPS serial input interrupt routine is entered, the CPU status is stashed and interrupts enabled. The input character is put in a message buffer, accumulating a full NMEA message. If an interrupt happens during this, control is returned to the character routine, not the background. If the message is not completed by the character being input, the original status is restored and control reverts to the background. When the message is complete, a new buffer is started, and the original stashed status is moved to a second stash. So now the completed message can be parsed and the parsing routine becomes the background process. It can be interrupted by any interrupt including the character routine. When the parsing is finished, set a flag, disable interrupts, restore the original status from the second stash and do a return from interrupt.
The background process looping every second eventually sees the flag and can process the parsed data (which can be collected from several different NMEA messages. The date, the time, number of satellites, valid fix are the ones that are used but could be anything in the NMEA data stream).
-
Yikes, the cheapest M8 module on Mouser is $27. M8T is $96. Is it safe to assume then that any ~$10 M8 module sold on AliExpress is fake? I have two different M8 modules on order, will report back regarding their authenticity. Has anyone here recently bought M8 modules from AliExpress and been able to confirm that they are genuine?
The two boards I bought from eBay were significantly cheaper than the genuine Ublox modules alone. Certainly the "Neo-M8N" I removed to fit a genuine M8T, shown in the attached photo, is a fake as U-Center reported that it was a "7"... The configuration didn't work quite correctly in U-Center either, although I cannot recall what the issue was.
My other board has a "Neo-M6N" module that will become a doner board for a genuine Ublox module when I need to use it. In the mean time it is working in an old James Miller (G3RUH) Simple GPSDO in place of a failed GPS board. The advantage for me is the doner boards have USB for basic initial config and are complete in their own right for the cost of a pint of beer. If you want to replace a module, de-soldering one is not easy... If you use ChipQuik (low temperature alloy) it is hard to clean the resulting solder/alloy mess completely from the board, any remaining alloy makes for lousy joints. Hot air is better but needs care to not disturb nearby parts.
These Chinese boards do work, I can't say if they will accept the commands in this project.
SJ
-
I bought NEO-M8T boards from "gnss.store". Including shipping they're around $90. However, you get not just the bare module but a complete board with voltage regulator, pin header and antenna connector. Better value, in my book.
-
Here's the link to the M8N board I bought from AliExpress a few months ago: https://www.aliexpress.us/item/3256805352621084.html (https://www.aliexpress.us/item/3256805352621084.html)
U-Center says it's a "u-blox M8/8". Does that mean it's real? Or just a better fake?
It does seem to work as far as finding the correct location, seeing plenty of satellites, etc. Not sure how jittery the 1PPS is and I don't know if I have the right equipment to test that.
Pics attached.
Edit: Anyone know why there's an EEPROM (24C32A) on this board?
-
There's no money in making "better" fakes. It's expensive, you'd need to at least engineer a firmware that passes as an actual M8 in u-center and somehow flash it into the module.
Why do that if all it takes is a fake label and a sucker who thinks he's smart. And those are plenty.
-
...
Edit: Anyone know why there's an EEPROM (24C32A) on this board?
You can save configuration parameters to the EEPROM, and the M8 module will read them back and reconfigure itself when later powered on.
-
Here's an update..
I tracked the "Calibrating, please wait..." problem to a bad cable connecting the 10 MHz output to the STM32 board. After connecting a good cable, I have another problem. The display no longer shows any information other than "STM32" and the version number at the top of the screen. I am not getting the OCXO warmup countdown and I am also not getting the "Calibrating, please wait..." message anymore. I have re-uploaded the code to the STM32 board, but no cigar. Not sure where to go from here. I checked the VCtl voltage and it is there and the 10 MHz output is also there. Any help will be much appreciated. I am using the ST7789-based 1.3" display with the proper libraries included in Arduino IDE.
-
As expected, the two ~$10 M8N modules that I ordered from AliExpress (two different boards from two different sellers) both turned out to be fake. U-Center reports them as u-blox 7, UBX-G70xx. Firmware is from 2012 and not upgradeable as there is no flash.
The sellers were "Simple Robot Store" and "WCMCU Store".
My 5 OSC5A2B02 oscillators also arrived and appear to work ok, except that 2 of the oscillators have weird jitter on the falling edges. Probably out of spec for phase noise, but can still be used for frequency counting and similar applications. The date codes were from 2012 to 2019, and both problematic oscillators were from 2014.
-
My 5 OSC5A2B02 oscillators also arrived and appear to work ok, except that 2 of the oscillators have weird jitter on the falling edges. Probably out of spec for phase noise, but can still be used for frequency counting and similar applications. The date codes were from 2012 to 2019, and both problematic oscillators were from 2014.
Run the OSC5A2B02 oscillators for a week and check them again. They've been bounced, hacked, dropped, and not used for years. They take a while to recover. I've run up quite a few of these, they mostly have weird jumps, instability, drift for up to a week. I have one running now for several months, it is much more stable than when first powered up.
-
“Run the OSC5A2B02 oscillators for a week and check them again. They've been bounced, hacked, dropped, and not used for years”
It’s not just surplus OCXOs from China, the oven in my old Racal counter is mediocre too.
I was lucky to find an NEC Toyocom oven a few years ago, it is superb and is currently in my Arduino controlled GPSDO. The hard part of building a GPSDO is finding a good oven…
My own experience is that a genuine timing GPS module has around half the short term frequency wandering compared to a “fake” Chinese navigation module, although that depends on both the oscillator stability and the control loop timing (it’s easier to control a good oven with a poor GPS module, than a poor oven with a good GPS).
Obviously a good GPS module and a good oven are the best combination.
SJ
-
Obviously a good GPS module and a good oven are the best combination.
SJ
I would add - a GPS antenna with an unobstructed sky view. I tried an M8T with a poorly positioned antenna, the survey-in error was 10m. It seemed the M8T was flipping between two states, possibly direct and reflected signals. Better results with a well positioned antenna and a Neo-7. Best results with well positioned antenna and M8T.
-
When letting the M8T do its survey-in, you can configure two constraints: minimum survey time and maximum location uncertainty. The survey-in will end when both criteria are met. You should put in at least a 1m location uncertainty. It will take very long to complete if you have a bad antenna position, of course.
-
Good advice!
When I first ran a survey in operation a couple of years back with my first M8T on my temporary ballasted metal drawer supported mag mount active patch antenna stuck atop of an eight foot pole to just clear the ridge tiles, I chose the default 24 hour minimum and increased the default 0.01m (it might even have been a 0.001m default!) to a less ambitious 0.1m.
After 24 hours it had only managed to reduce the deviation down to 0.169m with barely any further improvement over the next six hours so I decided to cut my losses and start again with a target deviation of 0.17m, expecting to have to wait another 24 hours in the hope that it would still reach this target. Much to my surprise (and great joy), the act of entering a wider deviation figure resulted in an immediate completion.
So bearing my experience in mind, I'd suggest you try an overly optimistic level of positional accuracy (like 0.1m >:D) to start with and see how close it can get in 24 hours. Assuming the survey in didn't succeed by then, you can either wait it out if it looks very close to completion or else enter a deviation value just slightly larger than what it has managed to reach so far to bring the process to a satisfactory conclusion.
Putting a timing module into overdetermined mode is better than leaving it operating in navigation mode, even if you have to settle for a metre or more of positional deviation since not only will this give you more stable timing, it will also obviate the four SV minimum requirement and allow it to maintain a lock with just one good SV signal.
-
I bought the AliExpress M8 module that caiser01 recommended, and it is unfortunately also fake. Despite identifying itself as UBX-M80xx, it is actually a version 7 module with an off-brand 512KB flash chip. Firmware is from 2013 and cannot be upgraded because there is not enough flash space.
The reason I know it's a 7 generation chip is that it only supports GPS and Glonass (GNSS configuration for BeiDou and Galileo fails). Version 8 should support all 4 constellations. Version 6 is GPS only.
This made me realize that my previous 2 AliExpress modules, sold as M8 and identifying as UBX-M70xx, where actually M6, as they can only do GPS.
I suspect that there are no genuine M8 modules on AliExpress. There are only older versions with fake labels and modified firmware.
Best bet is probably to buy an M9 module from Digikey ($27) and swap it into a cheap AliExpress board. M9 has lots of improvements over M8 and is pin compatible with the older versions.
Here's the link to the M8N board I bought from AliExpress a few months ago: https://www.aliexpress.us/item/3256805352621084.html (https://www.aliexpress.us/item/3256805352621084.html)
U-Center says it's a "u-blox M8/8". Does that mean it's real? Or just a better fake?
It does seem to work as far as finding the correct location, seeing plenty of satellites, etc. Not sure how jittery the 1PPS is and I don't know if I have the right equipment to test that.
Pics attached.
Edit: Anyone know why there's an EEPROM (24C32A) on this board?
-
I bought the AliExpress M8 module that caiser01 recommended, and it is unfortunately also fake. Despite identifying itself as UBX-M80xx, it is actually a version 7 module with an off-brand 512KB flash chip. Firmware is from 2013 and cannot be upgraded because there is not enough flash space.
The reason I know it's a 7 generation chip is that it only supports GPS and Glonass (GNSS configuration for BeiDou and Galileo fails). Version 8 should support all 4 constellations. Version 6 is GPS only.
This made me realize that my previous 2 AliExpress modules, sold as M8 and identifying as UBX-M70xx, where actually M6, as they can only do GPS.
I suspect that there are no genuine M8 modules on AliExpress. There are only older versions with fake labels and modified firmware.
Best bet is probably to buy an M9 module from Digikey ($27) and swap it into a cheap AliExpress board. M9 has lots of improvements over M8 and is pin compatible with the older versions.
Yeah, I've been going down the rabbit hole of identifying fake/clone/counterfeit u-blox modules. Digging a little deeper into U-Center, I saw that my AliExpress M8N was identifying itself as an M8J (plain crystal instead of TCXO) and who knows if that's true or not at this point. I still like the form factor of that AliExpress board though and now I'm thinking I might just try to clone the PCB design and stick it on GitHub. That way folks could make a board and put whatever genuine module they like on it.
I'm designing an overall PCB for this GPSDO right now and thought about integrating the u-blox module directly on to the board but ultimately decided against it. My goal is to have a board design for the GPSDO that most people could assemble easily with cheap, easily sourced parts. While it wouldn't be hard for me to solder a u-blox module, others might find it challenging enough to discourage them from trying a build. I want the opposite to be true so I'm sticking with having a header socket for connecting the GPS module. Then people can plug in whatever module they like. Personally, I'd rather have a genuine u-blox module but the cheap counterfeits work well enough to at least verify basic functionality. Then you could easily "upgrade" to a genuine module later by unplugging the fake and plugging in the real one, no soldering rework required.
-
Guys, beware of getting over enthusiastic about fake vs genuine modules… using a genuine timing module in fixed location, compared to a likely fake 6M navigation mode module, only shows a small improvement in my “Lars” board. Both measurements were using an outdoor “mushroom” antenna. Don’t confuse genuine vs fake with navigation vs timing modules, a timing module is designed to give more accurate time (and by inference frequency).
Another (completely different) issue is whether “marking your own homework”, by plotting your Arduino control output in TimeLab gives anything useful in terms of short term frequency stability. In my humble opinion, it is not a valid measurement. I noted a Keysight calibration lab having a GPS disciplined rubidium standard that was described as being within 1 part in 10^15 95% of the time… no plots of Allan Deviation. My own measurement technique is to use a phase frequency analyser to compare the frequency of my free running rubidium against one of my 3 GPSO units (a James Miller, Leo Bodnar and a Lars one). While there is the stability of the rubidium to consider, it at least allows me to run comparisons between loop settings, damping and between GPS modules on the same board.
The attached image shows a plot of a Chinese M6 module (blue trace) and a genuine M8T (magenta) in fixed mode, both fitted to a “Lars” board with the same outdoor “mushroom” antenna, same loop time of 60 seconds and a damping of 6. How much frequency wandering is due to the rubidium is unknown, but repeated tests give the same results.
SJ
-
Guys, beware of getting over enthusiastic about fake vs genuine modules… using a genuine timing module in fixed location, compared to a likely fake 6M navigation mode module, only shows a small improvement in my “Lars” board. Both measurements were using an outdoor “mushroom” antenna. Don’t confuse genuine vs fake with navigation vs timing modules, a timing module is designed to give more accurate time (and by inference frequency).
That would IMHO also depend on you antenna placement.
I have to use Timing modules, as my "Home location" antenna isn't optimal. And I often don't have 3 SV's in sight.
But i always have one - That's where my need for a timing antenna with a static position comes in. As it can supply timing pulses with just one "Bird" in sight.
/Bingo
-
Actually, you will see at least a 10-times better stability with an M8T module, provided you use the quantization error correction.
-
Thank you AndrewBCN, you are doing a great project and excellent information and communication work.
After reading all the comments for 2 days (a lot of information to process) I can understand the advantage of using FLL vs PLL due to its ease of adjustments, power supply noise and temperature immunity, etc.
However, it is not very clear to me the advantage/disadvantage of FLL vs PLL from a performance, accuracy or precision point of view.
Please can you explain it briefly?
Also, understanding that small problems will be solved, what difference in performance has a commercial industrial-grade GPSDO compared to this STM32 GPSDO that cannot be achieved using a good GPS (with quantization correction?) and a good OCXO or Rb?
What things would you suggest improving or adding to use STM32 GPSDO reliably in a real industrial environment?
-
Also, understanding that small problems will be solved, what difference in performance has a commercial industrial-grade GPSDO compared to this STM32 GPSDO that cannot be achieved using a good GPS (with quantization correction?) and a good OCXO or Rb?
What things would you suggest improving or adding to use STM32 GPSDO reliably in a real industrial environment?
As mentioned earlier, beware of becoming fixated on obtaining the very best accuracy/stability... A GPSDO is just a tool to enable you to run radio equipment on frequency, use a frequency counter/signal generator at good accuracy regardless of it's own oven/TCXO, or to calibrate counters and signal generators.
The Leo Bodnar GPSDO can output any frequency from 400 Hz to 810 MHz and is stable within a minute, or so, of being switched on, making it very useful for a variety of purposes... Despite their claim of being low jitter, it has around 10 times less short term stablity than a Lars DIY GPSDO which has been fitted with a good oven and a timing GPS board. Having said that, I use one every day as it is very convienient and quick to use.
By comparison, both a Lars Walenius GPSDO and a James Miller Simple GPSDO, can take 20 to 30 minutes to settle once the oven has warmed up. They also only output a fixed frequency (10 MHz, 5 MHz, 1 MHz, etc). Most users of these units will leave them powered all the time.
Building a GPSDO is both fun and not particularly difficult, but don't lose sight of what you want to do with it at the end of the day.
For comparison see the attached image showing the difference between a Lars DIY GPSDO and a Leo Bodnar.
SJ
-
Thank you AndrewBCN, you are doing a great project and excellent information and communication work.
After reading all the comments for 2 days (a lot of information to process) I can understand the advantage of using FLL vs PLL due to its ease of adjustments, power supply noise and temperature immunity, etc.
However, it is not very clear to me the advantage/disadvantage of FLL vs PLL from a performance, accuracy or precision point of view.
Please can you explain it briefly?
Hi, and thank you. To answer your question to the best of my knowledge, the performance/accuracy/precision of a GPSDO is determined by a variety of factors and the PLL vs FLL method of "closing the loop" is just one of these factors and perhaps not the most important one. So I would say it doesn't really matter that much.
Also, understanding that small problems will be solved, what difference in performance has a commercial industrial-grade GPSDO compared to this STM32 GPSDO that cannot be achieved using a good GPS (with quantization correction?) and a good OCXO or Rb?
What things would you suggest improving or adding to use STM32 GPSDO reliably in a real industrial environment?
That's a very difficult question, but basically a simple STM32 GPSDO that can be assembled on a breadboard in an afternoon will never compare to a modern "industrial" GPSDO. One of my objectives with this project was to design a GPSDO that would be fun and easy to experiment with, something you just can't do with any closed source commercial/industrial GPSDO.
-
Hi AndrewBCN
I started this interesting project some years ago! Reply #272. However, family and life in general conspired to interfere with its completion. Found it in the cupboard the other day so felt inspired to have another go. I have re-read replies up #430 and still lots to go.
Meanwhile, I tested the GPS Ublox 8 receiver module using Windows MTTY and GPSmonitor and was able to receive 11 satellites with GPS data so am happy that this works.
I tested the output of the OCXO and found a distorted 10MHz sinewave, so this looks OK.
I measure the 10MHz frequency directly off the OCXO pin using a 12 digit counter locked to a HP 10811A 10MHz reference oscillator.
I then ran the GPSDO from an 8v supply through a 5v regulator and noted that the Ublox 8 LED was blinking as well as the ST32 blue LED, so this seems to be working.
Never saw any indication from D1 LED connected to pin 16 of the ST32.
The ST32 firmware was still the one loaded from 2021, v.04.
I monitored the Vctl both with and without the Ublox 8 in circuit to see what affect that had. The voltage varied around 2.6v but the OCXO frequency did not seem to change much, being about 1.5Hz below the magic 10MHz aim.
I don't think my frequency meter is that far out of cal but I am not sure. Is it possible that the circuit cannot supply the correct Vctl for my OCXO?
An suggestions on how to proceed from here?
enut11
-
Hi enut11,
There are two ways to debug the STM32 GPSDO:
1. Connect it to a computer throught the USB-serial interface and check the messages.
2. Connect a small OLED display and check the messages.
Remember that this is a software driven GPSDO, so we must have some idea of what the MCU is doing to debug it. Also I suggest updating the firmware to the latest stable version which you can find on GitHub. And note that there are a few configuration options that have to be set before compiling the firmware, these are very relevant when debugging.
-
I monitored the Vctl both with and without the Ublox 8 in circuit to see what affect that had. The voltage varied around 2.6v but the OCXO frequency did not seem to change much, being about 1.5Hz below the magic 10MHz aim.
I don't think my frequency meter is that far out of cal but I am note sure. Is it possible that the circuit cannot supply the correct Vctl for my OCXO?
An suggestions on how to proceed from here?
enut11
Have you tried the oscillator running with a variable resistor to adjust the control Voltage? You should be able to set it to 10 MHz +/- whatever the specification is. I was given a CTI oven, and while I prefer to use an NEC one, it was easy enough to test the CTI one. There is an interesting web page covering running a stand alone reference oscillator using a CTI oven here:
http://www.sadarc.org/xenforo/upload/index.php?threads/build-a-10mhz-ocxo-for-the-shack-for-less-than-40-00.138/ (http://www.sadarc.org/xenforo/upload/index.php?threads/build-a-10mhz-ocxo-for-the-shack-for-less-than-40-00.138/)
Note the reference to needing to run old oscillators for several days in order to obtain the best stability, this is also mentioned in the user manuals of test equipment that uses ovened oscillators.
SJ
-
@Solder_Junkie, yes, I am OK with trimming a 10MHz OCXO, that is how I built the HP Standard. What I do not know is how the supply voltage affects an OCXO.
The data sheet for the Type 131 that I am using in this project says it is a 12v oscillator but I know it can run from 5v in this circuit. How does this affect stability and control? Should I just dump the 131 and try another OCXO?
-
@Solder_Junkie, yes, I am OK with trimming a 10MHz OCXO, that is how I built the HP Standard. What I do not know is how the supply voltage affects an OCXO.
The data sheet for the Type 131 that I am using in this project says it is a 12v oscillator but I know it can run from 5v in this circuit. How does this affect stability and control? Should I just dump the 131 and try another OCXO?
The 12V is the supply to the heater, rather than the oscillator. If you only supply 5V, the crystal may not be warm enough, and therefore more susceptible to ambient temperature variation in your laboratory (just like a standard non-oven crystal).
-
I isolated the 131 OCXO and powered it from 12v. Current drops from 170mA to 77mA but the 10MHz output goes up to 2.15vRMS (approx 6v PP). Is this a problem for the ST32?
-
I checked the frequency of the Type 131 OCXO in stand-alone mode and it was a couple of Hz lower than when it was in the GPSDO circuit. Compare picture below with Reply #923.
No attempt was made here to manually alter the Vctl signal into the OCXO.
So, maybe the GPSDO circuit is working but there is not enough voltage available to pull the Type 131 OCXO up to 10MHz?
Is there a way to extend the Vctl range beyond 2.64v max which is what I measured previously in Reply #923?
enut11
-
So, maybe the GPSDO circuit is working but there is not enough voltage available to pull the Type 131 OCXO up to 10MHz?
According to the 131 datasheet, the tuning voltage range is 0 to 8V.
You can manually test the OCXO by applying 8V at the control pin to confirm whether the frequency increases. If not, then the OCXO is faulty.
-
Yes, I am confident the OCXO frequency increases with applied voltage. What I am concerned about is whether the GPSDO software can generate enough voltage for my OCXO.
EDIT: in stand-alone mode and running from 5v as it would in this project, the Type 131 OCXO needs 3.114v Vctl to achieve 10MHz on my counter.
Does anyone know the range of Vctl that the GPSDO software can deliver?
-
Yes, I am confident the OCXO frequency increases with applied voltage. What I am concerned about is whether the GPSDO software can generate enough voltage for my OCXO.
EDIT: in stand-alone mode and running from 5v as it would in this project, the Type 131 OCXO needs 3.124v Vctl to achieve 10MHz on my counter.
Does anyone know the range of Vctl that the GPSDO software can deliver?
The maximum Vctl is the STM32 Vcc. In other words, the maximum Vctl is 3.3V
-
Thanks @Andy Chee.
So, the hardware limit is 3.3v which is higher than I need by about 0.2v.
Are there any voltage limits in software?
-
I believe the software has full range 0-100%, though I haven't investigated the code to confirm.
-
enut, there is a fundamental problem with using the OCXO you have... Let me explain:
1. The data sheet covers two different Voltage types, if yours has a label showing it is a 12 V one, the supply is 11.4 to 12.6 Volts, not 5V
2. The frequency adjust/control Voltage is 0 to 8 Volts, nominally 4 Volts (at time of dispatch from the factory) for zero offset from 10 MHz.
3. The reference pin is a fixed output Voltage for use when you use it as a stand alone oscillator, and use that Voltage with a trimming resistor to set the output to 10.0000 MHz
Assuming the OCXO is a 12 Volt one, you cannot run it from 5 Volts. Also, 3 Volts max on the control pin is not going to put it on 10.0000 MHz, it is likely to need 4 Volts or higher...
SJ
-
Hi @Solder_Junkie
Yes, I made this project difficult by using a 12v OCXO but I have confirmed that it runs at 5v too.
At the lower voltage, the Vctl requirement is also lower. In my case I was able to pull in 10MHz with 3.11v at the Vco pin using a variable precision voltage reference.
I suspect the GPSDO software does not allow the Vctl to go beyond about 2.64v (see last picture Reply #923) but I am not sure. I am waiting for someone to confirm that.
If software is the limit it may be possible to change it to allow the slightly higher Vctl that my rogue OCXO needs.
enut11
-
I ordered 3 used 5v 10MHz sq wave OCXOs but those will take some time to arrive.
While I am waiting I will still play around with this project as I might learn something new.
I am not a programmer but will have a look at the GPSDO code to see if I can spot something obvious wrt to limiting the Vctl to some max value.
Any suggestions here on what to look for would be appreciated.
enut11
-
You could run the existing OCXO from 12V and increase the control Voltage swing using the circuit from a James Miller GPSDO, as in this article:
http://www.jrmiller.online/projects/ministd/manual.pdf (http://www.jrmiller.online/projects/ministd/manual.pdf)
SJ
-
Thanks. Will have a look at that circuit. Seems to be many ways to skin this cat...
-
enut, there is a fundamental problem with using the OCXO you have... Let me explain:
1. The data sheet covers two different Voltage types, if yours has a label showing it is a 12 V one, the supply is 11.4 to 12.6 Volts, not 5V
2. The frequency adjust/control Voltage is 0 to 8 Volts, nominally 4 Volts (at time of dispatch from the factory) for zero offset from 10 MHz.
3. The reference pin is a fixed output Voltage for use when you use it as a stand alone oscillator, and use that Voltage with a trimming resistor to set the output to 10.0000 MHz
Assuming the OCXO is a 12 Volt one, you cannot run it from 5 Volts. Also, 3 Volts max on the control pin is not going to put it on 10.0000 MHz, it is likely to need 4 Volts or higher...
SJ
That isn't necessarily true for all brands of ocxo as I discovered with the very first one I'd purchased at the NARSA mobile rally in Blackpool some four years ago. This was a 13MHz sq wave cmos output version of the 10MHz sine wave output AEL (CQE) ocxos I later purchased from an Ebay seller I'd discovered during my fruitless searches for a datasheet on that first one.
Now armed with seven examples of the latter, I felt I could take a risk to test one of them out with a 12v supply (a risk I hadn't been prepared to take with my one and only ocxo example which I'd purchased at the radioham rally), discovering that these 10MHz versions were 12v types. By then, I'd already breadboarded a simple gpsdo running that first ocxo off a 5.15v supply through a divide by 1.3 chain of noisy TTL chips to generate the required 10MHz.
My initial tests with the 4.85v supplied by the breadboard kit's Y-Robot power supply adapter showed a very sluggish start up of the 13MHz ocxo (several seconds before a lowish amplitude stable 13MHz sq wave began to appear on the 'scope trace which fully stabilised after another 20 seconds or so. This voltage was unfortunately just within the +/- 10% specification typically applied to 5 volt parts so I wasn't entirely convinced that I'd purchased a 12 volt ocxo. Discretion being the better part of valour (it was at that time after all, my one and only ocxo example), I decided to assume it was a 5 volt ocxo especially since using a 5.15v supply rail gave it an instant (less than a second) startup characteristic. Until proven otherwise I'd carry on using it as such in my MK I gpsdo build.
Startup current on a 5v supply was 280mA (as it turned out, exactly the same as the 10MHz 12v units and also, as I later determined, at any voltage between 5 and 14 volts). The current would dip down to 14mA a minute or so later, pausing at this level for several seconds before zooming back up again, eventually stabilising around the 120/150mA mark some 7 or 8 minutes later. Of course, with only a 5v supply, the Vref pin was only outputting 3.2v instead of the 5.114v it would have otherwise output on an 11 to 14v supply which was below the required vfc of 3.43v to trim it exactly to 13MHz.
Another reason to run it off a 5.15v rail was simply to eliminate the need to use a boost converter off the 5.15v (trimmed with fixed resistor) buck converter output rail - less risk of accidentally overvolting 5 volt parts. I ran it for about a year quite successfully before replacing it with a MK II which did initially include a 12v boost converter to power one of my 10MHz ocxos.
This now sports a total of three dc-dc converters cascaded to provide a 3.85v float charging voltage to a 1.6AH protected LiPo cell from an input voltage supply that can range from 4.5 to 24 volts. This powers the 12v (adjusted to 11v) boost converter which supplies the ocxo and another buck converter which provides the 5v required by the logic and Ublox M8T receiver module.
The reason for all this extra complication? is on account of one teensy weensy shortcoming in these otherwise excellent AEL/CQE ocxos which only afflicts us DIYers (not a problem for their main customer, Symmetricom), namely their "Shoot first, ask questions later" startup algorithm which assumes a totally cold (as in thermally cold) startup regardless of whether it's an actual power up from cold event or a power glitch (a 10 to 20 ms or so supply interruption) induced reset which leaves the DIYer having to wait just as long as if it had been powered up from stone cold (a 15 to 20 minutes wait for it to settle back down).
This a very frustrating feature when having to temporarily unplug from the 19v laptop charging brick (or 5 to 24v wallwart or powerbank) in order just to reroute a tangle of cabling or swap to another DC power source. The 1.6AH rating is overkill for my 5 to 10 minute autonomy requirement, a 250mAH cell would have done the job just fine - I simply happened to have a couple of these protected pouch cells to hand which proved to be a neat fit inside the case.
The major downside of using an undervolted 13MHz ocxo being the need to add a 10MHz xtal in series with the output to get rid of the noise generated by the combination of a divide by 1.3 TTL chip assembly and the use of veroboard. The 1.2MHz switching frequency from the 5v buck converter was only just visible in a noise spectrum dominated by TTL induced noise on the Vcc rail by virtue of my knowing exactly where to look.
IOW, switching frequency ripple noise from a small (same size as a 7805 TO220 packaged regulator) buck regulator designed to power a drone's avionics will be the least of your problems. 8).
@enut11, if your experience with that type 131 ocxo corresponds with my own experience of running that 13MHz AEL/CQE unit off a 5v rail, you should be able to continue successfully with a stable 5 volt rail and a simple restive attenuator will take care of excess 10MHz output voltage. The only downside being the absence of a thermally stabilised Vref - you'll need to look elsewhere for a similarly stable reference voltage. The one remaining downside in your case being the need to buffer the ST32's PWM with a fet powered from a 5 (or even a 12) volt rail (I'm assuming Andrew's circuit is using a PWM form of analogue output - if not, then an RRO opamp fed from a 5v rail can be used to boost the ST32's analogue output to the required voltage level)
However, what I did notice when I tested the tuning range at this supply voltage using a 9v PP3 to test the upper frequency tuning range limit, was that the Vfc input was effectively clamped to the supply pin's input voltage. In my case, this wasn't an issue. Indeed, when comparing the 10MHz ocxos' startup characteristics on a 5.2v supply, they all fired up ok but with more reluctance than the 13MHz unit had demonstrated and all could be tuned with less than 5 volts on their Vfc pins (typically ranging from a low of 2.341 for the one in my MK II, to a maximum of 4.49 volts).
Although a Vfc upper voltage tuning limit for 12v ocxos is typically some 8 to 10v, I rather think you'd be terribly unlucky to land up with one that needs in excess of 5 volt on the Vfc pin. You get the maximum tuning rate going from zero to 1v with the tuning rate dropping off in the 7 to 8 volt range and I suspect most ocxo manufacturers would aim for an initial mid frequency factory trim which will almost certainly place the nominal frequency Vfc below the 5 volt mark.
Hopefully, armed with all that information, you'll be able to make a better informed decision as to how to proceed with your project. >:D
-
I bought the AliExpress M8 module that caiser01 recommended, and it is unfortunately also fake. Despite identifying itself as UBX-M80xx, it is actually a version 7 module with an off-brand 512KB flash chip. Firmware is from 2013 and cannot be upgraded because there is not enough flash space.
The reason I know it's a 7 generation chip is that it only supports GPS and Glonass (GNSS configuration for BeiDou and Galileo fails). Version 8 should support all 4 constellations. Version 6 is GPS only.
This made me realize that my previous 2 AliExpress modules, sold as M8 and identifying as UBX-M70xx, where actually M6, as they can only do GPS.
I suspect that there are no genuine M8 modules on AliExpress. There are only older versions with fake labels and modified firmware.
Best bet is probably to buy an M9 module from Digikey ($27) and swap it into a cheap AliExpress board. M9 has lots of improvements over M8 and is pin compatible with the older versions.
Here's the link to the M8N board I bought from AliExpress a few months ago: https://www.aliexpress.us/item/3256805352621084.html (https://www.aliexpress.us/item/3256805352621084.html)
U-Center says it's a "u-blox M8/8". Does that mean it's real? Or just a better fake?
It does seem to work as far as finding the correct location, seeing plenty of satellites, etc. Not sure how jittery the 1PPS is and I don't know if I have the right equipment to test that.
Pics attached.
Edit: Anyone know why there's an EEPROM (24C32A) on this board?
Just looking at this project. If you are right -and I think you are- there are $27 "M8" modules on Aliexpress whose marketing, mostly in chinese, only mentions GPS and GLONASS. So, no matter how much you pay, it seems everybody is gonna be "scammed" there.
Matter is, IMO, are you guys getting good results with these fake modules? If so, then I could go for one of them, eventually. Period. I don't care how many constellations it could work with, as long as my GPSDO outputs 10,000,000.01 Hz or so. And I would like to get that result the cheapest way possible. I thought that was at least one of the main points of this project.
If I have to pay, say, $90 for a real "good" GPS module... well, not that interested, I fear.
I just read this 38 pages and fake modules don't appear until the last three pages, say a month ago. First post is from May 14, 2021, however. About 30 months. People have been reporting good results all that time. So, I guess, good results could be obtained with M7, perhaps even M6 modules. What about that?
Anyway, kudos to the people here. Guys, I think you really did something big here.
-
The issue with regard to GPS modules is that cheap eBay, and similar unofficial sources, are likely to be selling boards with fake copies of Ublox modules. Whether that bothers your conscience is one thing, but (and it's a big but), they might not work as expected.
The other issue relates to using navigation modules for timing purposes, the difference between a cheap Chinese "Ublox 6" navigation module and a genuine Ublox M8T timing module is that on the same outdoor antenna you are likely to have half the short term frequency deviation/wobble/jitter when using the timing module. Myself and others have noted the difference. Do not confuse short term stability with long term "accuracy", as that is going to be close to the overall GPS satellite accuracy. The attached image shows the comparison in a Lars Walenius Arduino controlled GPSDO, the reference is a rubidium oscillator used with a TinyPFA (phase frequency analyser) and TimeLab.
The cheap 10 GBP eBay module is probably good enough for most purposes, it can always be swapped later if you want.
SJ
-
Thanks Solder Junkie and Johnny B Good. Your hardware solutions would probably work but would go against what AndrewBCN envisaged when he started this thread.
If a software solution is not possible then I will use a 5v OCXO as I should have done in the first place. My only defence is that at the time I had no idea I had the wrong oscillator.
enut11
-
If a software solution is not possible then I will use a 5v OCXO as I should have done in the first place.
It seems that my HP8640B wants a 5V external reference. So yesterday I looked for one of these. Unable to find even one on Ali. Found a few on eBay, but these all output a sinusoidal waveform, not a squared one. And, for some reason I still have to look closer at, this project seems to need OCXOs outputting square waves.
Should you find any 5V, square wave OCXO while I'm on the ICU digesting yesterday reading, please give a heads up. I would really appreciate it.
-
Should you find any 5V, square wave OCXO while I'm on the ICU digesting yesterday reading, please give a heads up. I would really appreciate it.
You can convert a sine wave to a square using a Schmitt trigger IC, typically a 74HC14 with a 4K7 to ground and a 4K7 to +5V on it's input (half supply). Feed your sine wave oscillator via a series capacitor to the input and also ground unused gate inputs.
SJ
-
Thank you, man.
-
Thanks Solder Junkie and Johnny B Good. Your hardware solutions would probably work but would go against what AndrewBCN envisaged when he started this thread.
If a software solution is not possible then I will use a 5v OCXO as I should have done in the first place. My only defence is that at the time I had no idea I had the wrong oscillator.
enut11
Hello enut11,
Indeed I would strongly suggest you buy a 5V square-wave 10MHz OCXO, these are available used/recycled for less than $15 these days or even less sometimes from AliExpress or the bay thingy. I bought one batch of 3 that required me to desolder them from a sawed-off piece of PCB, so that took some extra work but in the end they were all functional.
-
Thanks Solder Junkie and Johnny B Good. Your hardware solutions would probably work but would go against what AndrewBCN envisaged when he started this thread.
If a software solution is not possible then I will use a 5v OCXO as I should have done in the first place. My only defence is that at the time I had no idea I had the wrong oscillator.
enut11
Hello enut11,
Indeed I would strongly suggest you buy a 5V square-wave 10MHz OCXO, these are available used/recycled for less than $15 these days or even less sometimes from AliExpress or the bay thingy. I bought one batch of 3 that required me to desolder them from a sawed-off piece of PCB, so that took some extra work but in the end they were all functional.
I'm with Solder Junky on this one. The issue of converting a sine wave ocxo output into a perfect 1:1 ratio square wave is almost as simple as he describes, however, I'll add to that advice that the bias level needs to be tuned to the actual mid point to ensure a 1:1 ratio and further, you may need to add a loading resistor across the ocxo's output to eliminate clipping in the oscillator's feedback amplifier which induces jitter (some 2 to 4 ns in my case) in the resulting square wave.
It's possible that some brands of sine wave ocxos might not require such loading but at least one other member has experienced the same issue and used the same method to fix it.
In short, use a trimpot (5 to 100K will do) wired between gnd and Vcc with a 10 to 33K resistor connecting its wiper to the input of the schmitt trigger stage used to square up the sine wave from the ocxo. Since this will be feeding another 3 or 4 gates directly to drive the LPF used to recreate the sine wave output from the gpsdo, this will bias those gates to their mid point as well (the die manufacturing process ensures a very close match between all six schmitt triggers in the IC package in regard of their mid point bias requirements).
If you see a similar jitter issue on the resulting square no matter the bias trimpot's setting, load the ocxo's output directly with a 50 to 75 ohm resistive load and link it via a 1 to 10nF capacitor to the now biased schmitt trigger input pin.
I'm belabouring this point simply because the use of 5 volt square wave cmos output ocxos is not an overriding requirement - using the best quality ocxo you can afford/find regardless of type should be your aim since it's this which has the most effect on any gpsdo's overall performance.
Of course, in this case where you're experimenting with Andrew's DIY GPSDO, you can start with the cheapest / most cost effective ocxo regardless of type but I'd suggest that you include the option to use a sine wave type in your circuit board layout along with room to accommodate a TO220 sized 2.6 to 5.5 volt input to 12v output 7 watt peak rated boost converter to allow future experimentation with other types of ocxo. The reason for Andrew's recommendation to use a 5 volt square wave output ocxo is simply that it helps to minimise the complexity and the BoM costs which meets his aim to create a low cost DIY gpsdo.
I've attached a photo of my hand drawn MK II GPSDO circuit which shows the relevant circuitry of a sine to square wave converter stage on the left hand side. In this context, you can ignore the rest of the diagram since it relates to the James Miller (G3RUH) based analogue PLL control circuitry.
You might notice the 150 ohm in series with the 1nF DC blocking/coupling capacitor which I hadn't mentioned in my description. I'd only added it out of consideration of the possible stress on the 74HC14's input clamp diodes. I doubt it is really needed but I was being overly cautious (it won't do any harm by adding what's most likely an unnecessary resistor in this case). IOW, that 150 ohm resistor is optional.
The reasoning behind this cautiousness is neatly explained by the note in the top right corner. The circuit had worked perfectly fine without that 1.5K resistor until I decided to increase the time constant of the PLL by replacing the caps (including C2) with ten times larger values. I'd overlooked the effect of instant Vcc volt drop on power down with the larger charge now available from C2 to blow the RRO opamp. The first 'mystery failure' had created a cascade of damage (the 74HC14 and the 2.1A max rated 'mini 360' 5v buck converter. had been 'taken out' as a result). It had taken a second opamp failure before the penny finally dropped. :palm:
-
Thanks Solder Junkie and Johnny B Good. Your hardware solutions would probably work but would go against what AndrewBCN envisaged when he started this thread.
If a software solution is not possible then I will use a 5v OCXO as I should have done in the first place. My only defence is that at the time I had no idea I had the wrong oscillator.
enut11
Hello enut11,
Indeed I would strongly suggest you buy a 5V square-wave 10MHz OCXO, these are available used/recycled for less than $15 these days or even less sometimes from AliExpress or the bay thingy. I bought one batch of 3 that required me to desolder them from a sawed-off piece of PCB, so that took some extra work but in the end they were all functional.
@AndrewBCN, I have ordered the 5v Sq wave OCXO. It will take a month or more to arrive. Have you caught up with my tests leading me to this conclusion? I discovered what appears to be a limit to how high Vctl is allowed to go, approx 2.64v (Reply #923). Do you have a software limit to Vctl?
enut11
-
@Johnny B Good. Thank you for your generous input. Your knowledge of OCXOs and GPS is way ahead of me. I am a novice here so am happy to take baby steps for the time being. That is why I was attracted to the apparent simplicity of @AndrewBNC's GPSDO. If I can get this to work, it may lead to other similar projects - who knows?
-
@Johnny B Good. Thank you for your generous input. Your knowledge of OCXOs and GPS is way ahead of me. I am a novice here so am happy to take baby steps for the time being. That is why I was attracted to the apparent simplicity of @AndrewBNC's GPSDO. If I can get this to work, it may lead to other similar projects - who knows?
I was pretty much in that position about four and a half years back myself with regard to ocxos and gpsdos. You'd be surprised as to where even a vague fascination in "Electronics" (to give the subject its generic all encompassing label) will lead you to these days.
I started with a one valve (vacuum tube) radio kit based on the DK91 (90v HT and 1.5v heater) that had been donated/sold to my dad by one of his workmates (probably an unwanted gift) when I think I must have only been 11 or 12 years old way back in the early sixties. As to whether I managed to get it working is now lost in the mists of time. :(
However my one abiding memory of what had sparked off my interest in electronics is of a "child safe" 3 volt powered transistor based multiproject electronics kit I'd received as a Christmas present shortly thereafter which was based on a hardboard pegboard which used schematic overlay sheets with holes matching the pegs on the plastic mountings onto which the components had been soldered to spring clips allowing solderless assembly (an early form of plug in solderless breadboard if you will). ISTR it having 7 such schematic overlays all of which I tried out, inventing a few extra variations of my own into the bargain, mostly in the (fascinating to me) subject of wireless communication.
Afterwards, I gained an (one might say unhealthy) interest in the technical section of my local library on the subject of electronics, specifically, transistor based material (well, there was much less risk of electrocution than that inherent in the more classic thermionic valve based technology). From then on, I was doomed to a lifelong interest in the rapidly evolving subject of electronics (audio amps opamps, simple logic, hybrid valve/transistor MF transmitters, audio magnetic tape technology, microprocessors (of the Z80 kind) and so on. I won't go into any more detail since this almost certainly echoes the experience of many, if not most of this forum's membership.
Suffice to say that, despite my lifelong experience, I'd still had something new to learn when I strayed into this particular rabbit hole of metrology. I too had to take 'baby steps' when I moved onto upgrading the crappy 50MHz smd oscillator in my much modified Feeltech FY6600 arbitrary wave generator to a 50MHz 0,1ppm tcxo board that had been my first step onto this particular road to 'metrology madness' (the second step being the upgrade to an ocxo that I could frequency inject stabilise to an external 10MHz reference), followed of course, by an inevitable search for 'perfection' in the form of building gpsdos and purchasing a couple of rubidium oscillators. :palm:
You can take this relatively short (by my standards) missive as a hint as to what you may be letting yourself in for with this recently acquired interest in this project. Don't say you haven't been warned. >:D
-
@AndrewBCN,
I want to start building a second GPSDO and I have an STM32 type 401 (instead of type 411). Will this project work with a type 401? It will only be a basic setup with no options.
enut11
-
@AndrewBCN,
I want to start building a second GPSDO and I have an STM32 type 401 (instead of type 411). Will this project work with a type 401? It will only a basic setup with no options.
enut11
Short answer: yes it will work with a 401.
Long answer: read the source code. ;)
-
I finally got around to designing a PCB for this GPSDO. It's functional so far but I know there are improvements that can be made, so I'm interested to read what people smarter than me may have to say about this design ;D
Here's what I did:
- SMD design with mostly 1210 size components. So far in this thread, I've only see through-hole designs. I prefer SMD when possible so that's the path I took. I chose larger 1210 size components where possible so that people could easily hand solder if desired. However, I freely admit that I "cheated" and had PCBWay populate the SMD components when the boards were fabricated :P The through hole parts are just connectors and test points except for the OCXO itself and the hex inverter (more on this later).
- Two 5V linear power regulators (1117): one for the OCXO and another for everything else. This was just me copying what I've seen some other people doing with having the OCXO supply separately regulated from the rest of the circuit. The power supply is also where I made my most serious goof. In my rush to get done and use up my expiring coupons at PCBWay, I forgot to add heatsink pours for the regulators. This isn't the end of the world but the regulator for the OCXO will get painfully hot to the touch if the input voltage is above 10V or so. In the 7.5V-9V range, the regulator is just "warm" so I'm just keeping my input voltage in that range for now. I've revised the PCBs to include heatsink pours :P
- INA219 current monitor integrated on the board. I did this just because I feel like all the available breakout boards for this are a bit clunky. There is a jumper footprint inside the sense resistor footprint to allow you to jumper out this section if you don't plan on populating the INA219.
- MCP9808 temperature sensor. I added this to the bottom side of the board directly underneath the OCXO to give a good reading on how warm that area is getting. Since the rest of the sensors in the firmware use Adafruit libraries, I followed suit here making it pretty simple to integrate the new sensor into the code.
- Optional I2C pull-up resistors (R9, R10). My OLED display and AHT20/BMP280 breakout both have pull-ups integrated but in case someone else wasn't using such an arrangement, I've left this provision for adding separate I2C pull-ups.
- Three buffered outputs (10MHz square, 10MHz sine, 1PPS). I made the hex inverter a socketed through-hole part to make it easy to experiment with different logic families (more below).
- Header provisions for either (both?) an SPI or I2C type display.
- PCB form factor designed to fit the Hammond 1598 enclosure. This was to make things (hopefully) easier for me personally. People with the appropriate tools, skills, and time can likely do better.
Been testing this on and off for a week or so. It is functional as my breadboard version was.
Fix time 767mS
Uptime: 000d 04:40:25
New GPS Fix:
Lat: 38.XXXXXX Lon: -85.XXXXXX Alt: 191.5m
Sats: 12 HDOP: 0.65
UTC Time: 21:23:51 Date: 7/3/2024
Voltages:
VctlPWM: 1.82 PWM: 36064
Vcc: 5.00
Vdd: 3.30
OCXO voltage: 5.02V
OCXO current: 177mA
Frequency measurements using 64-bit counter:
64-bit Counter: 168163190756
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 9999999.997 Hz
10,000s Frequency Avg: 9999999.9868 Hz
AHT10 Temperature: 27.63 *C
Humidity: 35.97% rH
MCP9808 Temperature: 35.94 *C
I do have one thing nagging me. There is a "twitch" in the 10 MHz square wave output that coincides with the occurrence of the 1PPS pulse:
https://www.youtube.com/watch?v=ywNmsfOrtcM (https://www.youtube.com/watch?v=ywNmsfOrtcM)
The "twitch" phenomena mostly seems to impact the amplitude of the ringing at the edge transitions and not so much the edges' occurrence in time.
I'm buffering both the 10MHz OCXO output and the 1PPS GPS signal through different gates of the same hex Schmitt trigger inverter. Connections details in the attached schematic. Since I flagrantly lifted that part of the circuit from other people's designs in this thread, I was wondering if anyone else had observed the same thing?
The video above was taken with a CD74HC14 populated. Of the chips I have, this one has the least "twitch". The 74AC14 and SN74AHCT14 both had much more noticeable "twitch" (and lots more ringing at the transitions but I believe that's characteristic of those respective logic families). Maybe it's nothing to be concerned about but since the point of a GPSDO is to have a precise timing reference, I was concerned.
The sine output is not impacted by the "twitch", although it does pick up a fair amount of ringing noise from the square wave. Perhaps it would be better to separate the output signals into different ICs for buffering?
The board files are all up on my GitHub (haven't yet committed the change for the heatsinks) for folks to peruse along with the files attached to this post
https://github.com/caiser01/BlackPill-GPSDO (https://github.com/caiser01/BlackPill-GPSDO)
Feedback is welcome!
-
Here's a more extreme close up of the "twitch":
https://www.youtube.com/watch?v=FIGRHWWcpwM (https://www.youtube.com/watch?v=FIGRHWWcpwM)
-
I finally got around to designing a PCB for this GPSDO. It's functional so far but I know there are improvements that can be made, so I'm interested to read what people smarter than me may have to say about this design ;D
Here's what I did:
- SMD design with mostly 1210 size components. So far in this thread, I've only see through-hole designs. I prefer SMD when possible so that's the path I took. I chose larger 1210 size components where possible so that people could easily hand solder if desired. However, I freely admit that I "cheated" and had PCBWay populate the SMD components when the boards were fabricated :P The through hole parts are just connectors and test points except for the OCXO itself and the hex inverter (more on this later).
- Two 5V linear power regulators (1117): one for the OCXO and another for everything else. This was just me copying what I've seen some other people doing with having the OCXO supply separately regulated from the rest of the circuit. The power supply is also where I made my most serious goof. In my rush to get done and use up my expiring coupons at PCBWay, I forgot to add heatsink pours for the regulators. This isn't the end of the world but the regulator for the OCXO will get painfully hot to the touch if the input voltage is above 10V or so. In the 7.5V-9V range, the regulator is just "warm" so I'm just keeping my input voltage in that range for now. I've revised the PCBs to include heatsink pours :P
- INA219 current monitor integrated on the board. I did this just because I feel like all the available breakout boards for this are a bit clunky. There is a jumper footprint inside the sense resistor footprint to allow you to jumper out this section if you don't plan on populating the INA219.
- MCP9808 temperature sensor. I added this to the bottom side of the board directly underneath the OCXO to give a good reading on how warm that area is getting. Since the rest of the sensors in the firmware use Adafruit libraries, I followed suit here making it pretty simple to integrate the new sensor into the code.
- Optional I2C pull-up resistors (R9, R10). My OLED display and AHT20/BMP280 breakout both have pull-ups integrated but in case someone else wasn't using such an arrangement, I've left this provision for adding separate I2C pull-ups.
- Three buffered outputs (10MHz square, 10MHz sine, 1PPS). I made the hex inverter a socketed through-hole part to make it easy to experiment with different logic families (more below).
- Header provisions for either (both?) an SPI or I2C type display.
- PCB form factor designed to fit the Hammond 1598 enclosure. This was to make things (hopefully) easier for me personally. People with the appropriate tools, skills, and time can likely do better.
Been testing this on and off for a week or so. It is functional as my breadboard version was.
Not smarter but been down this track a bit.
I went the dual supply route and used a buck converter to get the input to the regulators at 7V to reduce the heatsink problem. A tradeoff between heat control and flexibility of input voltage, and complexity. Technically, no heatsink was needed as the dissipation is less than 1W per regulator but little ones were added to keep temps in the touchable region. What I didn't do was take care to isolate the earth for the OCXO and the earth to the rest. They should share an earth only at the earths for the regulators. Because I didn't do that, relying on the earth layer to have insignificant resistance, plugging a load into the BNC altered the control voltage fractionally causing a frequency change (less than 1ppb and corrected after a few minutes but still something that should have been designed out).
I'd say the "twitch" as you describe it may also come from the shared earth of the inverter IC. It doesn't look like it affects the leading or trailing edges of the output, so may not be significant.
The ringing can be controlled by impedance matching. My design used 5 x inverter outputs each into 270 ohm resistors combined to give an approximate 50 ohm source. If it then went through 50 ohm coax to a 50 ohm terminated load the ringing was small. Unterminated, there was significant ringing. The signal was over 2V p-p which was rather more than needed. I was thinking to redesign with only two inverters (as you have) with a pair of 270 ohm to the BNC and an 82 ohm (I think that was the right standard value) across the BNC (to give some sort of load if the output is unterminated, and look like a 50 ohm source if terminated in 50 ohm). I was using 270 ohm to limit current if the BNC is accidentally short circuit. There's probably a place for a couple of small caps (a few pF) to damp any residual ringing, but outside my pay grade to bother working them out.
A good idea to design with a particular enclosure in mind. My first PCB didn't, I got negative feedback.
-
I built the Budget GPSDO designed by @MIS42N and found an improvement in performance by adding an additional voltage regulator for the GPS Rx. That mod may also work for this project.
enut11
https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/msg5348666/#msg5348666 (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/msg5348666/#msg5348666)
Reply #93
-
I've been watching the "twitch" on and off over the last 6 hours, and it doesn't seem as though it's affecting the leading and trailing edges in time. For now, I'm not going to worry too much about it. I'm eager to collect some long term data on this thing and see what that tells me.
@MIS42N, your point about grounding is a good one. I do tend to take the lazy approach with big ground planes on top and bottom but a device such as this one probably deserves more careful consideration of the grounding. A star ground may be a good alteration for a future revision of this PCB. If someone's is looking for an interesting design challenge, these GPSDO's certainly seem to fit the bill. I appreciate you sharing your experience in this thread and in the one for your own design.
@enut11, interesting results there when separating the GPS receiver on a separate regulator. As you and others have shown, stabilizing the OCXO control voltage is critical.
My next step is to set up a long term test and collect data, data, data.
Of course, before I do that I have to get my workbench cleared of all the spring cleaning junk it's collected recently ::)
-
Hi caiser01,
First, thank you for sharing your wonderful PCB and implementation of the STM32 GPSDO project.
Regarding the ringing and "spikes" you are observing: ringing is mostly due to impedance mismatches and the fast rise/fall rates of modern digital logic gates. The spikes you have observed I believe are due to not enough capacitor decoupling and crosstalk between logic gates in the 74HC14 IC.
AFAIK one can somewhat mitigate these issues using various tricks, but I am not qualified enough so I defer to other people with more knowledge and experience.
However as you noted, these circuit noise issues don't seem to prevent the STM32 GPSDO from working decently enough.
Please keep us posted about your data collection and experimenting, these are the exact reasons I created this project.
Cheers and again, bravo.
Andrew
-
Hi,
Thanks for the nice toy Andrew - can't stop playing with it!
Few points:
1. in Linux (found it by accident) once the chip in DFU mode (it can be triggered with one finger), I have 100% success flashing using the line:
dfu-tool write GPSDO_V006c.ino.bin -d 0483:df11
I had mixed results with dfu-util with this Blackpill. While with the tinysa devices the dfu-util works ok.
2. I have extremely poor sky view, but I got cheap ebay salvaged M8T module which handles the situation pretty well as far as I can see. Does anybody have played/have ubx magic strings to send to M8T to work optimally in limited sky view? (managing survey mode)
3. Andrew, are there any steps towards FreeRTOS? (I don't "pushing" for it)
Zilvis (LY2SS)
-
Hi,
Thanks for the nice toy Andrew - can't stop playing with it!
...
3. Andrew, are there any steps towards FreeRTOS? (I don't "pushing" for it)
Zilvis (LY2SS)
Hi Zilvis and thanks for your post. Glad you are playing with it, that is/was one of my objectives. Unfortunately I have not had the time to work on this or any other project for the last year, I am going through some difficult times on many different aspects of my life.
So, no progress on moving the firmware to FreeRTOS. But still interested in doing it someday...
-
2. I have extremely poor sky view, but I got cheap ebay salvaged M8T module which handles the situation pretty well as far as I can see. Does anybody have played/have ubx magic strings to send to M8T to work optimally in limited sky view? (managing survey mode)
Have you done the survey-in for using the timing mode? U-Center would be a good help here. Apart from this, not much else you can do. You can play a little with the elevation mask and with the maximum number of SVs to use for time calculation, but in my experience, they're not really improving things when you have a limited sky view anyway.
-
I still haven't managed to clear a space at home to set up my long term test but I have done some other tinkering to try and reduce the ringing on my square wave output.
I spent some time messing about with several different hex inverters, both CMOS and TTL, but ended up back with CD74HC14 as this had the lowest amplitude ringing of any of the CMOS parts. The TTL 74AS04 was slightly better but being TTL had the disadvantage of not being able to give a full 5V swing with the output loaded. After much research and experimentation, my ultimate solution was to bodge in a couple of 39pF shunt capacitors, one for each of the two paralleled outputs I'm using for the square wave. These shunt the higher frequency ringing to ground at the expense of rise/fall times, which I'm fine with for my use cases. It also eliminates the aforementioned "twitch" since that phenomena was only present in the ringing.
When terminated into 50 ohms, the square wave is looking pretty good I think. There's just a bit of overshoot in each transition, which could be eliminated by increasing the shunt capacitors to 43pF or 47pF. I happened to only have 39pF on hand and can live with the results. Going straight into the scope without termination the square wave output is only "square-ish" but again, good enough for me tinkering in the basement.
Of course, all of this is simply treating the symptoms and not the illness, which as others have pointed out is the impedance mismatch between the OCXO output and the first inverter input. The "real" fix for my design is either to move the hex inverter right next to the oscillator to reduce the length of the 10MHz track to virtually zero or control the impedance of the 10MHz track to eliminate the mismatch. It'd be a good learning experience to go through the design work for this but I've already gone a bit over budget on PCBs for this hobby project. I'm also not keen on ending up with a house full of "reject" board designs. I can be happy with what I have at this point and the files are on GitHub if someone else wants to take a crack at it.
I've found a small bug with the OLED display code today: When the date rolled over from 31/3/2024 to 1/4/2024, it came out as 1/4/20244. Picture below for proof but should be an easy fix; just need to add some spaces at the end of the date string to blank out the previous characters or left pad the month and day with zero to make them fixed length.
I've test fit the board into a Hammond 1598CBK and the fit is good. At this point, I just need to cut the holes for the connectors and the display. I'm also considering constructing a small insulated box for the OCXO to see if I can reduce its power consumption by keeping more of the heat inside. I have a bit of ceramic fiber insulation left over from a repair kit for my kitchen oven; might see what I can do with that.
But the big thing is still to get my damn workbench cleaned up so I can start a long term test with this thing.