STM32 GPSDO

[dannyf]

i happened to be sitting in front of a pic32 so here is a piece of code that I ran on it:

Code: Select all

		//double math errors
		x=10000.123456;
		x=x*10000;
		u2Print("tick0=                    ", tick0);
		u2Print("tmp0 =                    ", (uint32_t) x);

the display:

Code: Select all

tick0= 1,544,000,000      tmp0 = 0,100,001,232      

you should expect something worse on the stm32.

floating math is just evil

[dannyf]

out of curiosity, the code here:

Code: Select all

		x = 10000.123456;
		tmp0=x*100000;

tmp0 (uint32_t type) takes on a value of 1000012288, vs. 1000012345.

[AndrewBCN]

Hi dannyf,

Very interesting discussion! So I wrote the code below, compiled it and uploaded it to an STM32F411, and got the results I sort of expected.

Code: Select all

/* Floating point math test on the STM32
 * Do I need to worry? 
 */

// Some global variables
double dbten=0, dbhun=0, dbtho=0;
// uint64_t x1, x2;
// uint64_t y1, y2;
// uint64_t z1, z2;
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200); // USB serial
}

void loop() {
  // put your main code here, to run repeatedly:
  Serial.println(F("Floating point on STM32, precision test"));
  
  // One decimal
  uint64_t x1 = 200000123;
  uint64_t x2 = 100000120;
  dbten = double(x1 - x2) / 10.0;
  Serial.println(F("One decimal test"));
  Serial.println(dbten, 1);

  // Two decimals
  uint64_t y1 = 2000000123;
  uint64_t y2 = 1000000100;
  dbhun = double(y1 - y2) / 100.00;
  Serial.println(F("Two decimals test"));
  Serial.println(dbhun, 2);  

  // Three decimals
  uint64_t z1 = 20000000123;
  uint64_t z2 = 10000000000;
  dbtho = double(z1 - z2) / 1000.000;
  Serial.println(F("Three decimals test"));
  Serial.println(dbtho, 3);
 
  delay(5000);
}

And the results on the serial monitor:

Code: Select all

Floating point on STM32, precision test
One decimal test
10000000.3
Two decimals test
10000000.23
Three decimals test
10000000.123
Floating point on STM32, precision test
One decimal test
10000000.3
Two decimals test
10000000.23
Three decimals test
10000000.123

[AndrewBCN]

Tested to four decimal places, works fine!

[AndrewBCN]

I have just pushed to GitHub version v0.03i and tagged it.
This is the final version in the 0.03 series.
Implements 10,000 seconds ring buffer (that's 2h 46m 40s), tested and working.
All known bugs have been fixed.
32-bit counter code was removed and entirely replaced with 64-bit code.
Yellow LED status now corresponds to GPS fix: blinking means no fix, off means fix.
Three separate GPSDOs have been built on separate breadboards and operated simultaneously,
with practically identical performance (better than +/- 1ppb stability over 100s),
validating the general hardware and software design.

The 10,000 seconds ring buffer gives the STM32 GPSDO a frequency measurement resolution of 0.01ppb (10E-11). Note that this is not the accuracy of the GPSDO, but the resolution to which it can measure the frequency of the 10MHz OCXO during a period of 10,000 seconds. Accuracy and resolution are two different things in scientific measurements.

Well, development is over in the 0.03 series, since I have achieved all my objectives and implemented all the features I wanted for it. I'll have to think for a few days/weeks about what I want to develop for version 0.04 and subsequent.

Not to brag, but the STM32 GPSDO is to the best of my knowledge and as of May 2021, the most feature complete and sensor-rich DIY GPSDO described on the net since Brook Shera's July 1998 GPSDO design*, and compares well to any commercial GPSDO available for less than $1k. And that's in no small part due to the choice of the tiny $5 "Black Pill" development board with its 100MHz STM32F411CEU6 MCU, and the great development environment provided by the Arduino IDE and STM32 Core package.

*: see https://www.qsl.net/n9zia/wireless/QST_GPS.pdf

And here is what the STM32 GPSDO firmware version v0.03i prints once per second on the Arduino IDE serial monitor:

Code: Select all

Wait for GPS fix max. 5 seconds...
Fix time 884mS
Uptime: 000d 03:43:58
New GPS Fix: 
Lat: 48.xxxxxx Lon: 7.xxxxxx Alt: 145.3m Sats: 10 HDOP: 1.13
UTC Time: 18:04:17 Date: 28/5/2021

Vctl: 1.94  DAC: 2403
VctlPWM: 1.85  PWM: 35677
Vcc: 5.03
Vdd: 3.30

Using 64-bit counter implemented in software
Most Significant 32-bit Count (OverflowCounter): 31
Least Significant 32-bit Count (TIM2->CCR3): 1220126755
64-bit Count: 134364112931 Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 9999999.998 Hz
10,000s Frequency Avg: 9999999.9912 Hz
BMP280 Temperature = 22.8 *C
Pressure = 1019.7 hPa
Approx altitude = 59.8 m
AHT10 Temperature: 19.69 *C
Humidity: 68.84% rH

[dannyf]

*: see https://www.qsl.net/n9zia/wireless/QST_GPS.pdf

that level of complexity may be needed then but probably not now.

GPSDOs are simple:
1. you need a way to measure a frequency source against the 1pps signal;
2. you then need a way to convert that into a control signal.

that's pretty much all there is. you can fit it into a small mcu today.

Re his approach of using a phase comparator: I was actually thinking about this the other day. Use a divid-by-N device (a mcu for example) to divided your local oscillator to a 1pps, and run it into a phase comparator (4060 or an xor) and the resulting voltage can be used to control the LO.

[AndrewBCN]

...
Re his approach of using a phase comparator: I was actually thinking about this the other day. Use a divide-by-N device (a mcu for example) to divided your local oscillator to a 1pps, and run it into a phase comparator (4060 or an xor) and the resulting voltage can be used to control the LO.

Yes, that is the phase-locked loop (PLL) control method. I am using a frequency-locked loop control method. Both methods work and achieve the same result, while each method has its advantages and disadvantages.

If you want the absolute minimum complexity GPSDO you can take a look at the Lars' DIY GPSDO thread here:
https://www.eevblog.com/forum/projects/ ... ution-tic/

This is how my design compares with Lars':
- It's based on a powerful 32-bit STM32F411 MCU running at 100MHz, instead of a 16-bit AVR MCU.
- It uses a digital FLL, not a digital/analog PLL.
- 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.
- It has an optional Bluetooth interface, so you can control it from your smartphone.
- The BOM is very short and all the bits and pieces are easy to find and order.
- Total cost is < 30€ (that's about US $35).

I don't think it makes much sense to design another minimal DIY GPSDO these days, since Lars' design is as basic as it can get. And unfortunately "basic" does not mean "easy to understand/maintain", at least when it comes to embedded software. If you compare Lars' Arduino sketch to mine, you'll immediately notice they are miles apart in terms of software design. The spirit is completely different. For one, one of my objectives was to get from start to the finish line (design, development, implementation and testing) in a matter of weeks, not months/years like Lars'. For that, I decided very early to use as many readily available libraries as possible, whereas Lars' uses exactly none...
Another objective was to write code that is highly "maintainable": easy to understand, modular, abundantly commented, and as short as possible, and again, that relies on libraries and functions that simplify the program logic. Some DIY GPSDO projects use thousands of lines of PIC or AVR assembly language code...

[dannyf]

he already have the phase differential information out of the phase comparator so why not just use that to drive the vco? what does the pro mini do there?

I think the design can be much simpler than that.

[AndrewBCN]

he already have the phase differential information out of the phase comparator so why not just use that to drive the vco? what does the pro mini do there?

The MCU is programmed as a low pass filter on that phase differential information, as well as various other auxiliary functions.

A Low Pass Filter (LPF) is used in Phase Locked Loops (PLL) to get rid of the high frequency components in the output of the phase detector. It also removes the high frequency noise. All these features make the LPF a critical part in PLL and helps control the dynamic characteristics of the whole circuit.

I think the design can be much simpler than that.

Actually it's extremely difficult to come up with a simpler design than Lars', if you use the PLL control method. Likewise, it's very difficult to come up with a simpler design than mine, if you use the FLL control method.

[dannyf]

you can build a LPF from a rc network -> he has the lpf on the output from the phase comparator.

Likewise, it's very difficult to come up with a simpler design than mine, if you use the FLL control method.

I have done a few, from a pic16f based one to LM4F120-based. I may just pick it up - I'm thinking about a ATtiny85 or ATmega328p, given how inexpensive the arduino boards are.