Yet another DIY GPSDO - yes, another one

[iannez]

Tnx AndrewBNC,
its more clear now.

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

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()

Code: [Select]

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:

Code: [Select]

flush_ring_buffers_flag = true;


For example in my case every two / three cycles are above 1000ms:

Code: [Select]

Fix Time 1004ms

So I had to increase the variable to 2:

Code: [Select]

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.

[Badwater]

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

Code: [Select]

#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



[iannez]

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.

Code: [Select]

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.

[AndrewBCN]

Hi,
I have (finally!)  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?

[AndrewBCN]

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.

[iannez]

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. 

See you soon, I think we're all testing your soft!

bye, A.

[AndrewBCN]

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.

[iannez]

yeah

tnx

[mendip_discovery]

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?

[AndrewBCN]

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. 

[mendip_discovery]

I was thinking more basic than that. Let the complicated stuff be done on the main board when it gets made.

 

[mendip_discovery]

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.

[AndrewBCN]

I just uploaded to GitHub the STM32 GPSDO code Version v0.05b "Omicron". 

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.

[AndrewBCN]

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

[thinkfat]

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

"Don't Panic!"
  - The HGTTG

[Badwater]

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

If this is interesting for "our" project I can share the code and details once the concept is tested on my side.

.... stay tuned ....

[iannez]

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.

[AndrewBCN]

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. 

[bob91343]

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.

[AndrewBCN]

So as pre-announced, I have published Version v0.05d which is essentially v0.05c + ST7735 SPI color LCD support by Badwater-Frank. 

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. 

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.

[AndrewBCN]

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.  As usual, please test when you have some time and kindly report any bugs.    or 

Moving on to Version v0.05f... 

[Badwater]

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:

Code: [Select]

  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:

Code: [Select]

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

[AndrewBCN]

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:

Code: [Select]

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

[Badwater]

Hi AndrewBCN,

... may be ....

ver 0.05e
initial value:

Code: [Select]

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

Code: [Select]

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:

Code: [Select]

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

[bob91343]

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!