Yet another DIY GPSDO - yes, another one

[Renate]

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.

[AndrewBCN]

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/

[MIS42N]

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.

[AndrewBCN]

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.

[Renate]

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?

[MIS42N]

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?

[FriedLogic]

  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.

[rodpp]

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

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.

[Renate]

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.

[MIS42N]

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.

[Renate]

Just saying.

[felixd]

@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

[iannez]

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.

Code: [Select]

// 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:

Code: [Select]

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:

Code: [Select]

   // 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.

[thinkfat]

sizeof(uint64_t) == 8

[iannez]

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:

Code: [Select]


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]

@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.

[AndrewBCN]

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:

Code: [Select]

   // 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.

[iannez]

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.

[iannez]

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:

Code: [Select]

  // 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.

[AndrewBCN]

...

# 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.

[Renate]

Eh, 20% accuracy is not bad for a GPSDO.

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.

[iannez]

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.

[bob91343]

I have given up on the project.  I have a box of parts and don't know how to proceed.

[iannez]

Hello bob91343,
what's your problem?

if I can help you I'm here

bye, A.

[mendip_discovery]

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.