Yet another DIY GPSDO - yes, another one

[iannez]

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.

[Renate]

Here you go, use this. See if there are any big jumps in your printout. You can print as you have, but add this.

Code: [Select]

/* 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);
}

[bob91343]

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.

[felixd]

[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



Microcontroller: STM32F411CEU6
GPS module: Icofochina ATGM332D 5N31
OCXO: Morion MV89A
EFC control DAC: PCM5102A <-- That's interesting. 32bit DAC

[iannez]

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.

Code: [Select]

    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.

[Renate]

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

[iannez]

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.

[thinkfat]

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.

[AndrewBCN]

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.

Code: [Select]

    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!

[bob91343]

Perhaps someone wants to volunteer to finish my unit.  I would pay for postage at least if someone can get this thing working.

[iannez]

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.

Code: [Select]


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.

[thinkfat]

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.

[iannez]

 thinkFat  you are perfectly right,
 thanks for the clarification

bye, A.

[AndrewBCN]

circbuf_ten64[11]: 28485109

Yes, that's an out-of-bounds memory access.

[felixd]

@bob91343

Do You have already Arduino IDE? If not, install it from here:
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

PM me when You finish this step. Do You use Discord? This is offical EEVBlog channel there: 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)

[Badwater]

Got it working 

... but commands are not recognized
Any ideas why?
I am more a HW guy ...

Code: [Select]

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


[AndrewBCN]

Got it working 

... but commands are not recognized
Any ideas why?
I am more a HW guy ...

Code: [Select]

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.

[felixd]

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

[Badwater]

... recognizing commands .....
-> reading the comments in the code helps a lot (well done )

Code: [Select]

//  "\n" means only newline needed to accept command
... works fine 

Tnx, Frank

[felixd]

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

Code: [Select]

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!

[bob91343]

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.

[AndrewBCN]

...

We have received simillar messages like one below.

Code: [Select]

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.

[felixd]

uC was powered up before GPS All fixed.

Code: [Select]

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

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.



------------

[UPDATE] We have working 10000000.00 Hz Since hardware is working fine I will now have time to look at software

Code: [Select]

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


[iannez]

Good work felixd !!!

[bob91343]

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.