10MHz GPSDO by "BH3SAP"

[fredo_]

Great, thank you for the feedback!
OK, I'll set the default contrast value to 80 in the next release.

Did you match PC13 LED to this?

Yes, LED0 will switch on and off synced on the MCU controlled PPS output.

[daddygo]

Did you match PC13 LED to this?

Yes, LED0 will switch on and off synced on the MCU controlled PPS output.

Tomorrow (or on Sunday) I'll measure this (PB1) with a d-osciloscope and report back if I find anything.

Now I'm working on a new impedance driver in KiCAD, I had no idea it was such a big question and not much literature, I went with this and it's very instructive:
(especially if you have a long coaxial cable to drive - as in our case):

50 Ω driver circuits for digital signals

https://pmc.ncbi.nlm.nih.gov/articles/PMC8342968/#bib5
https://data.mendeley.com/datasets/zj4fxws38x/2

[fredo_]

Tomorrow (or on Sunday) I'll measure this (PB1) with a d-osciloscope and report back if I find anything.

Once synchronized, you should get ~450us delay between the GPS PPS output and the PB1 output.

[daddygo]

Tomorrow (or on Sunday) I'll measure this (PB1) with a d-osciloscope and report back if I find anything.

Once synchronized, you should get ~450us delay between the GPS PPS output and the PB1 output.

Should you keep it at this level (at value) or can you reduce it?

[fredo_]

Should you keep it at this level (at value) or can you reduce it?

Can't be reduced much: it's the time needed for the few lines of code to execute and for the timer to reload...
I'll see if I can move code to improve it a bit, but don't expect much less.

[daddygo]

Should you keep it at this level (at value) or can you reduce it?

Can't be reduced much: it's the time needed for the few lines of code to execute and for the timer to reload...
I'll see if I can move code to improve it a bit, but don't expect much less.

Yeah, I thought your hands were tied by the code.
Whatever you can get out of this I thank you...

BTW:
So I'm no longer worried about 8 - 12nS propagation time in the impedance matcher. hihihihihi

[fredo_]

Good news, I finally got delay between the GPS PPS output and the MCU controlled PPS output down to ~30us.
There was LCD update code slowing down the interrupt routine, it should never have been there in the first place!...
Just released v0.1.2 with that fix: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.2

[daddygo]

Good news, I finally got delay between the GPS PPS output and the MCU controlled PPS output down to ~30us.
There was LCD update code slowing down the interrupt routine, it should never have been there in the first place!...
Just released v0.1.2 with that fix: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.2

That's great news, I'll flash it up tomorrow and measure PB1, because I haven't done that yet.
I have a semi-finished Schmitt trigger + 4 parallel gates for 50ohm line drive, which will be a sandwich layout (like Daughter Board concept),
below is the impedance matching PCB and above is any version of GPS module.
Matched to 50ohm and with U.FL terminals.

[fredo_]

I just released v0.1.3: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.3
Changes are:
- Display update logic optimization
- New auto-save PWM and auto-resync features when PPB reaches 0 (PPB menu)
- New 'Force sync' option in PPS menu

[fredo_]

And finally a v0.1.4: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.4
- Use of hardware timer TIM1 for PWM contrast control (should solve flickering display issue when rotating encoder)

[HappySundays]

Thank you @fredo_ You have made magnificent improvements to the GPSDO firmware and taken on board many suggestions. I'll try out 0.1.4 today.

[daddygo]

And finally a v0.1.4: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.4
- Use of hardware timer TIM1 for PWM contrast control (should solve flickering display issue when rotating encoder)

Hi fredo_

I have tested the last FW so far all good.
We would deploy this GPSDO in an environment where there are usually mobile operators, these are different transmission towers with mobile antenna systems.
Tests so far show high LTE interference to the GPS module.

So I am designing our own NEO-M9N base module for the unit.
(this has a factory installed LTE notch filter)

However, based on the attached hardware design guide page, - UART baud rate not 9600, like neo-6m & ATGM336H.
According to the note, it is not advisable to go below 38400 baud because of buffering problems.

FW tunning:
Would it be possible to avail. set a baud rate in the GPS menu or somewhere?
(could be two fixed values because it is easier code, 9600 (for original modules), 38400 for M9N)

THX

[fredo_]

Sure, why not!
I'll take a look at that as soon as I'm finished with the graphic trend display (shouldn't be long)

[fredo_]

Hi GPSDO users,
I just released v0.1.5 of the alternative firmware: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.5
This one focuses on a dedicated trend display to monitor PPM progress over time: https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#trend-screen
It was a bit challenging but much fun to manage graphical display on a character LCD screen   

[fredo_]

@daddygo this one is for you!: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.6
v0.1.6 of GPSDO alternative firmware with GPS baud-rate setting.
Please let me know if this works for your 38400 baud GPS UART.
Best.

[HappySundays]

It was a bit challenging but much fun

Hi Fredo,
v0.1.6 looks great. I might be able to use the new trend line graph to visualize any further improvements to the algorithm.
One suggestion now that you have so many submenus. The Trend menu now has an "exit" but for the others, you have to know which is the "home" or starting screen so you can click to go back up one level. It's not immediately obvious, so I would prefer the "Exit" on each submenu.

[daddygo]

@daddygo this one is for you!: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.6
v0.1.6 of GPSDO alternative firmware with GPS baud-rate setting.
Please let me know if this works for your 38400 baud GPS UART.
Best.

Hi fredo_

Thanks for your effort!!!!

Already on the way to me, from JLCPCB, the completed PCBs, the host card with a USB connection and 50ohm driver and a separate NEO-M9N module.
I flashed the new FW, it works fine, but I can test 38400 baud only with arrived PCBs, then I'll get back to you with the results...

Edit1:
the next big leap would be to add an NTP server, hihihihi
jah plus ethernet and the like...

my old favourite with STM32F107:
https://partiallystapled.com/hardware/laureline/

The MCU might need to be upgraded to one of these, it handles eth., - STM32F756ZG
NUCLEO-F756ZG

Yes this is beyond the upgrade limits of this GPSDO 

[fredo_]

One suggestion now that you have so many submenus. The Trend menu now has an "exit" but for the others, you have to know which is the "home" or starting screen so you can click to go back up one level. It's not immediately obvious, so I would prefer the "Exit" on each submenu.

And here you go for the "Exit" menu-items!: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.7

[fredo_]

Dear fellow GPSDO users, I'm about to close the case of my GPSDO (I mean literally;-)).
If you have any further alternative firmware improvement request, now would be a good time .
Once the screws are be back on, my will of making changes will be greatly slowed down by the laziness of reopening the case and finding the right connections on the JTAG header to upload a new firmware version

[G4ELJ]

Hi fredo,

Your updated firmware is working beautifully for me.

One thought.

I have been using the pass through, via a USB to TTL serial converter to set my computer clock using bkttimesync, https://www.maniaradio.it/en/bkttimesync.html

I am seeing an approx. a 0.87second delay between bkttimesync GPS time and NTP time, presumably a combination of the PPS to GGA output time delay with the ATGM336H and time to hit the computer at 9600baud through the USB-TTL converter.

I wonder if it is possible to sync GPS time to the PPS and have a settable, saveable delay to account for the time lag.

I can set the correct delay in bkttimesync but wondering if there is a better solution.

Thanks for your work (and dankar).

Duncan 

[HappySundays]

Hi Fredo,

I've spent a while making tweaks to the tuning algorithm but I find that the original is hard to beat. I have just re-enabled the optional 180s warm-up timer on mine, as I think that's technically the better way to start up, but that's mostly my preference. It's not worth pushing to your repo.

You've done an amazing job!

David

[2A03]

Hi.
This is a great alternative firmware project!

Today I tried updating to the firmware on github.
My GPSDO hardware is the same as https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/msg5605867/#msg5605867

I suddenly noticed that the screen display was distorted, random numbers were displayed, and other strange behavior made it unusable.
When I reverted to the original firmware, it worked fine, so I don't think there's a major problem with the hardware.

The sequence of events leading up to the hang-up is as follows:
1. PPB suddenly becomes 0.00 (the sooner the OCXO is warm, the quicker this happens)
2. Random numbers or letters start to appear on the LCD (an 8-digit number appears in UPTIME. See attached image)
3. The green LED on the BluePill stops flashing (usually a little after 2.)
4. Sometimes the rotary encoder also becomes unresponsive

This is just my hunch, but I think that memory corruption is likely occurring when this behavior occurs.

Is there anything I can do about this?

[2A03]

Hi.
This is a great alternative firmware project!

Today I tried updating to the firmware on github.
My GPSDO hardware is the same as https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/msg5605867/#msg5605867

I suddenly noticed that the screen display was distorted, random numbers were displayed, and other strange behavior made it unusable.
When I reverted to the original firmware, it worked fine, so I don't think there's a major problem with the hardware.

The sequence of events leading up to the hang-up is as follows:
1. PPB suddenly becomes 0.00 (the sooner the OCXO is warm, the quicker this happens)
2. Random numbers or letters start to appear on the LCD (an 8-digit number appears in UPTIME. See attached image)
3. The green LED on the BluePill stops flashing (usually a little after 2.)
4. Sometimes the rotary encoder also becomes unresponsive

This is just my hunch, but I think that memory corruption is likely occurring when this behavior occurs.

Is there anything I can do about this?

I remembered that I had a Linux virtual machine, so I decided to build it myself.

I made the following modifications based on my predictions and then did a release build.

menu.c: line 364-
static void menu_draw()
{
static char screen_buffer[32];
static char ppb_string[16];

I uploaded the firmware to BluePill.
No strange characters have appeared even after more than 30 minutes!
I plan to do some more load testing, but I think it was probably a buffer overrun.

The source code makes extensive use of sprintf, but I recommend using snprintf or sprintf_s.

[Edit] It's been working fine for over 12 hours. I think the problem is solved.

[daddygo]

Dear fellow GPSDO users, I'm about to close the case of my GPSDO (I mean literally;-)).
If you have any further alternative firmware improvement request, now would be a good time .
Once the screws are be back on, my will of making changes will be greatly slowed down by the laziness of reopening the case and finding the right connections on the JTAG header to upload a new firmware version

Hi @fredo_

This GPSDO is miles better than how it arrived with the original FW.
Thanks for all your hard work.

I'd be glad if you don't put the torx wrench deep in your toolbox  , now I have to travel within the EU for one week then I'll have the NEO-M9 in my hands to test it, I might have some more ideas about the FW.

[2A03]

Although I confirmed that the operation was stable for a long time, I noticed that the number of satellites and the time were occasionally not displayed correctly, so I investigated.

I found that when communication with the GPS module was 9600bps, the NMEA sentence sometimes overran.
I tried to set the GPS module to 19200bps or higher, but it did not work properly.

After further investigation, I found that only one of the two UARTs was set, so I corrected it. In addition, I modified it so that the baud rate setting is automatically changed and saved when the GPS module is ATGM336H.
I also modified sprintf to use snprintf.
As an additional element, I added an hour offset to the GPS menu so that the local time can be displayed.
Since the year, month, and date are not displayed, it does nothing, and daylight saving time is not taken into account.

I don't know much about github, so I've attached a zip of the modified source code and the bin file.
The version name has been slightly changed to make it easier to distinguish.
I hope it will be helpful to someone.