10MHz GPSDO by "BH3SAP"

[fredo_]

Hi @Me,
When your GPSDO frequency is stabilized (i.e. the 256 second PPB running average reaches 0) it will automatically :
- Save PWM value to eeprom, so that this value is used as a starting point after next boot
- Sync the MCU controlled PPS Output to the GPS PPS output (see here : https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#mcu-controlled-pps-output )
The 'PWM&PPS DONE !" message you saw indicates that the two actions above have been performed.

[ME]

Hi @Me,
When your GPSDO frequency is stabilized (i.e. the 256 second PPB running average reaches 0) it will automatically :
- Save PWM value to eeprom, so that this value is used as a starting point after next boot
- Sync the MCU controlled PPS Output to the GPS PPS output (see here : https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#mcu-controlled-pps-output )
The 'PWM&PPS DONE !" message you saw indicates that the two actions above have been performed.

Does that mean its locked at 10MHZ and ready to use then?.

[fredo_]

Yes that's it.

[daddygo]

- anyone have any ideas or requests on what else should be on this rethought new BP?

Could you make a "breakable" pad on the Vdd(a) Analog voltage Ref ,  allowing for breaking the PCB Vdd(a) , and allowing for an external ref input ?
Or just make it possible/easy to break the VCC feed to the Vdd(a) circuit.



.

After much research and reading... f.e.: AN2834

-I added a solder jumper (VDDA/VREF, but I removed it because on the H503 the two inputs cannot be separated.
I was thinking about a separate LDO to feed the VDD and VDDA, but many people advise not to use it despite the system diagram below.

The delta of two voltages (dig/ana) must not be more than 0.3V during start-up and otherwise during operation, - as this could destroy the chip.
I have considered using the EN (enable) PIN of the seconds LDO, but there is no guarantee that the two LDOs or say SMPS will start in sync.

That's why I stuck with the tried and tested LC filtering for feeding the VDDA/VREF, - trying to get it right on the PCB.
The literature on this is a little controversial, but in the end practice has provided the answer.

BTW:
"star network" with GND implemented, the bottom layer of the 4 layer PCB is full GND and In2Cu is the power supply layer, the other two layers are for signals
BOOT0 I have put out a jumper, many people don't use it in this form anymore, but it is necessary for a development board

I'm still struggling a bit with the OSC circuits and soon I'll have a finalizable format for this H503 project.

Any more ideas, anything?

PS:
@bingo600 2011 was even earlier 

[bingo600]

After much research and reading... f.e.: AN2834

-I added a solder jumper (VDDA/VREF, but I removed it because on the H503 the two inputs cannot be separated.
I was thinking about a separate LDO to feed the VDD and VDDA, but many people advise not to use it despite the system diagram below.

The delta of two voltages (dig/ana) must not be more than 0.3V during start-up and otherwise during operation, - as this could destroy the chip.
I have considered using the EN (enable) PIN of the seconds LDO, but there is no guarantee that the two LDOs or say SMPS will start in sync.

Hmmm ... Strange one would expect VDDa to be a separate net.
But STM prob knows best 

Thank you for giving it a shot ...

I have no further input 

Well besides : I'm impressed with your HW & PCB skills     

[daddygo]

After much research and reading... f.e.: AN2834

-I added a solder jumper (VDDA/VREF, but I removed it because on the H503 the two inputs cannot be separated.
I was thinking about a separate LDO to feed the VDD and VDDA, but many people advise not to use it despite the system diagram below.

The delta of two voltages (dig/ana) must not be more than 0.3V during start-up and otherwise during operation, - as this could destroy the chip.
I have considered using the EN (enable) PIN of the seconds LDO, but there is no guarantee that the two LDOs or say SMPS will start in sync.

Well besides : I'm impressed with your HW & PCB skills 

@bingo600 - Thank you for these words, it is worth working for 

a little follow-up...

- I can say that ERC and DRC error free by now this PCB
- OSC zones completed on both F.Cu and B.Cu, with separate GND-REF on on the bottom layer for quartz - (after a job like this, you realise that the PCB is not that big  )
- PSU side and USB side zones are ready, with separate F.Cu GND layer

- still to come, the most "tedious" task, is the placement of labels and designators in silkscreen layers
- and at the end comes the generation of production files, gerber, bom, CPL, etc...


I usually look at it for a week afterwards, because after a good night's sleep I have more redemptive thoughts and the usual redesigns, hahahaha


BTW:

on the bottom layer I built the options, such as the OSC IN pad (for GPSDO use), and the caps of the quartz, so that don't have to de-solder them, I put a solder jumper on the bottom layer, so that the caps are disconnected from GND and vice - versa
(this is also for GPSDO use, for other applications these must be connected)

[daddygo]

After much research and reading... f.e.: AN2834

I usually look at it for a week afterwards, because after a good night's sleep I have more redemptive thoughts and the usual redesigns, hahahaha

I think I have reached the end, or at least I am very close...

Since STM32H503 has two Vcap PINs, PB11 and PB9 do not exist on this MCU.
GPSDO uses these PINs in the FW &/or HW

PB9 = LCD_RS
PB11 = GPS_RX

I "pushed" PB2 and PA15 from H503 to 20 PIN HEADER instead of PB9 and PB11, to the corresponding PINs.
PB2 was needed for BOOT1 on the original BP, but not used by H503, so it was free.

I don't see PA15 in the source code assigned to anything, pls. @fredo_ confirm this for me, I don't see it in gpsdo.ioc either.

Well with these small changes have an old BP compatible but higher horsepower board that is also PIN compatible with this GPSDO main PCB.

In CubeMX, these will have to be taken into account PB2 / PA15

I made the 2x20 PIN labels a bit more readable, don't need a magnifying glass anymore 

I call it RED Pill for lack of a better idea, - -anyone have a better name?

BTW:
the size is the same as the original BP

[daddygo]

Since STM32H503 has two Vcap PINs, PB11 and PB9 do not exist on this MCU.
GPSDO uses these PINs in the FW &/or HW

PB9 = LCD_RS
PB11 = GPS_RX

I "pushed" PB2 and PA15 from H503 to 20 PIN HEADER instead of PB9 and PB11, to the corresponding PINs.
PB2 was needed for BOOT1 on the original BP, but not used by H503, so it was free.

Hi @fredo_

I'm not a CubeMX virtuoso, but I put together something for the STM32H503 as initialization code for GPSDO.

I followed your HW/PIN modifications from FW to FW like TIM1 for LCD contrast, PA0/PA1 lock outputs (GPIO), etc (I may have missed something  ) and put together a Cmake startup library for this MCU.

In the attached picture you can see the actual PIN assignment.
There are some differences within the chip, even if it looks PIN compatible, but these are rather inside improvements.
(we need to rethink these)

f.e.:

- TIM2 no longer has 16 bit resolution, but 32 - I do not think this is a problem - the other timers remain 16bit
- I could not assign PB2 to GPS_RX because there was no AF (Alternate functions) for this PIN, so I had to put the GPS_RX on the PA12, which requires some jumper wiring on the GPSDO mainboard bottom side (short 2-3cm - by the way, on this side it's right next to the GPS module, I don't understand why it wasn't here originally), because I want to remain this MCU PCB BP compatible
-PA15 LCD_RS could be and BP PIN compatible, no problem here

-The H503 does not work with the eeprom emulation like for the F103:
https://github.com/nimaltd/ee/tree/e99f7e9792e727e8204eb3c69e27c99a7c2657f0

I found this solution particularly good for the H503: https://www.st.com/en/embedded-software/x-cube-eeprom.html
it's a bit tricky, but here's a good description and files (.c/.h) I've already put in the src/inc libs...
https://community.st.com/t5/stm32-mcus/porting-and-using-x-cube-eeprom-with-any-stm32/ta-p/570539

there are a bunch of new HW code features, -which you may have to experiment with, now what I knew and thought was good I turned on

-128K flash with ECC & Dual-bank operating modes - (ECC not turned on)
-SRAMs, - SRAM1 16Kbytes / SRAM2 16Kybytes / BKPSRAM 2 Kybetes (for backup) - (ECC not turned on)
-ICACHE 2-way set

the rest are broadly similar...
it would be good if you could check it when you have time to do so, to see if it can be used


42M size of the CubeMX project so I will PM you a link to download it

[fredo_]

Hi @daddygo ,
Thanks for the project bootstrap, I was able to integrate it in dankar's project structure and have it compile :

[build] [104/104] Linking C executable gpsdoh5.elf
[build] Memory region         Used Size  Region Size  %age Used
[build]              RAM:       20448 B        32 KB     62.40%
[build]            FLASH:       68924 B       128 KB     52.58%

That's a good start !

-The H503 does not work with the eeprom emulation like for the F103:

How is so ? I can see H5 directives in nimaltd's code : https://github.com/nimaltd/ee/blob/215929b4573f1d8f6535e99d8259fe9ae4b44b19/ee.c#L47

[daddygo]

Hi @daddygo ,
Thanks for the project bootstrap, I was able to integrate it in dankar's project structure and have it compile :

[build] [104/104] Linking C executable gpsdoh5.elf
[build] Memory region         Used Size  Region Size  %age Used
[build]              RAM:       20448 B        32 KB     62.40%
[build]            FLASH:       68924 B       128 KB     52.58%

That's a good start !

-The H503 does not work with the eeprom emulation like for the F103:

How is so ? I can see H5 directives in nimaltd's code : https://github.com/nimaltd/ee/blob/215929b4573f1d8f6535e99d8259fe9ae4b44b19/ee.c#L47

Hi @fredo_

It's a great start!!! 
(Usually, - I work only with audio DSPs / FPGAs code initialization - it's a bit different, I'm glad that CubeMX is okay, maybe...)

I didn't delve into the emulation of the eeprom on case H5, I just saw that I couldn't integrate it into the project (via package manager) and I immediately looked for another solution

Now that you show the code (nimaltd), it should work and it's simpler than the X-Cube-eeprom solution, otherwise this needs to be investigated further, as somewhere on the ST forum someone else had a problem with nimaltd, also on H5.

I could not add it (nimaltd eeprom emu) as an external package to CubeMX, there's a "clever"  Youtube video ),

but it's likely that the newer ST embed. developer restrictions mean that it no longer works, please see the attachment picture.
Maybe I should write to nimaltd on GitHub.

It would be much simpler to use the original eeprom emulation...

Would you try running it on a Nucleo64 factory board? (I have on a shelf)
Or the other option is after your current code check I will manufacture via JLCPCB the designed PCB wich is BP PIN compatible and you run it on that.

I have waited until now to produce it, as I was curious to see how runnable it would be, but I no longer see any obstacles to us moving forward.

What do you think?


+++edit1:
anyway, on second thought, it is not necessary for CubeMX to integrate the nimaltd package into the code, we could follow the original F103 code in this respect
-although this requires manual code editing


+++edit2:
like many people on the ST forum, I thought that x-cube-eeprom could be installed as "middleware" and added to the code in this way, like say RTOS, unfortunately not, it can only be edited manually ):

[fredo_]

but it's likely that the newer ST embed. developer restrictions mean that it no longer works, please see the attachment picture.
Maybe I should write to nimaltd on GitHub.
It would be much simpler to use the original eeprom emulation...

Well I used Stm32Cube IDE and was able to import the library, go figure...
Yes we will try to stick to nimaltd's lib, it will be much easier.

Would you try running it on a Nucleo64 factory board? (I have on a shelf)
Or the other option is after your current code check I will manufacture via JLCPCB the designed PCB wich is BP PIN compatible and you run it on that.
I have waited until now to produce it, as I was curious to see how runnable it would be, but I no longer see any obstacles to us moving forward.
What do you think?

I was thinking, before launching manufacturing, would it be possible to add some pads or jumpers on your board to allow routing PA12 to the original PB2 location, to avoid modifying the original GPSDO mainboard ?
Anyway, if you have a spare Nucleo64 board available, sure, I can try and run the code on it, I'll PM you my address.

+++edit1:
anyway, on second thought, it is not necessary for CubeMX to integrate the nimaltd package into the code, we could follow the original F103 code in this respect
-although this requires manual code editing

Yes I think that's what Dankar originally did: he used CubeMX to generate the project code once and then integrated it in a different project structure with LCD and eeprom libaries.
When working on the project, I never used CubeMX to add new IOs, and just patched to generated code and IOC file myself (not sure it's the right way to do, but it worked!...

[daddygo]

When working on the project, I never used CubeMX to add new IOs, and just patched to generated code and IOC file myself (not sure it's the right way to do, but it worked!...

Hi @fredo_

Yes I saw that you edited the .ioc manually, not a bad solution after all.
The only problem with it is that backwards when you load it into CubeMX your changes are not displayed/realized and I had to manually enter a lot of things for the new I/Os.
Finally, we now have a place close to the final I/O rollout, it is not possible to add much more as PINs are slowly running out and there are also restrictions that certain PINs cant used for multiple functions, as the AF for PINs is not endless & PIN position dependent.


@fredo_ "I was thinking, before launching manufacturing, would it be possible to add some pads or jumpers on your board to allow routing"


I worked a lot on this... this is a tougher nut to crack
I originally designed PB2 as GPS_RX, but only after the PCB design I checked in CubeMX that this PIN cannot take USART3_RX, I could only go to PB12.

I'm using a 4 layer PCB, but it's still hard to find a way to drive this one PIN to the original GPSDO BP position, it would also lose the original BP PIN compatibility.
I haven't given up on this and I'm still thinking hard about a solution...

the first thing that came to my mind was this short jumper on the bottom side and very close to the GPS module
PB2 on the original BP is not derived to the 20PIN header because it is used for BOOT1

The PCB design rules also tie my hands to get a good noise free PCB, EMI and many other parameters in place, I'll show you a picture of the current routing,
so I'm going to sit on this for a bit and see what....

PS:
I will send you the Nucleo board this week

[bingo600]

@fredo_
Thought .....
Now that we have a 32bit timer (T2)
Could it be used (repurposed) for generating the 1PPS or other "clean" frequencies , would be output compare match (hw). And therefor 100% correct (apart from pll jitter)

Could you find another H5 timer that can do the "old" T2 function ?
Then we could have a "selectable" freq output from T2, selected from a "menu" 

What H3 pin would be optimal for such an output ?



@daddygo ... If yes to above, we (you) might have to route a T2 output pin to :
Either a "Socket" pin , or even just to a "Topside PAD" - If a PAD it would be nice to have a GND PAD also to solder a SMA coax pigtail too ... Sorry 

Hmmm ... Just looked at the topside traces ... Seems crowded , but you're a Magician 
Else bottom side  ...


/Bingo

[daddygo]

@fredo_
Thought .....
Now that we have a 32bit timer (T2)
Could it be used (repurposed) for generating the 1PPS or other "clean" frequencies , would be output compare match (hw). And therefor 100% correct (apart from pll jitter)




@daddygo ... If yes to above, we (you) might have to route a T2 output pin to :
Either a "Socket" pin , or even just to a "Topside PAD" - If a PAD it would be nice to have a GND PAD also to solder a SMA coax pigtail too ... Sorry 

Hmmm ... Just looked at the topside traces ... Seems crowded , but you're a Magician 
Else bottom side  ...


/Bingo

Hi for all,

Well, as I'm sure you've read - there's a complete blackout in Portugal and Spain, around noon we run from our solar panels, I routed pfSense to Madrid (via CDN77), so I have internet and power from the solar.
People have bought up all the toilet paper (again)
Good thing that GPON is a passive network. (at least until OLT)

I was already thinking about this 32bit timer when I configured the H5 .ioc, there is still plenty of empty TIM (5,6 & LPTIMs) and 32bit would be a good resolution for PPS,  - yes.

@fredo_ do you think we should move to the empty TIM5, - say? , - is this causing problems in the code for you?

I've also been trying the SMA pigtail thing (attached 3D view), we're thinking alike, - I'm trying to get a U.FL connector right place, -
currently under USB con., but I move it daily.....


plus.... the B.Cu layer (bottom) is global GND, so I don't think USB is EMI interfering, here in the actual GPSDO conf. we can't even start to use USB because it conflicts with USART3 (this is inherited from @dankar FW / PIN configs)

USART3 originally GPS_RX / TX - and already having trouble finding free PINs and keeping them compatible with original BP & GPSDO main board.

I attach the .ioc for you to see @bingo600 (STM32H503-GPSDO.zip)
@fredo_ has already checked (.ioc) and integrated it into the code, but anything is possible......(!?)

[bingo600]

USART3 originally GPS_RX / TX - and already having trouble finding free PINs and keeping them compatible with original BP & GPSDO main board.

Now that would be Crazy ...
Not to move USART3 to ie USART1 if possible.

One of the things that i would have hoped to get w. the H3 , was USB Serial & fw upgrade.

I would even say "ditch" USART2 (gps passthrough) , and do that via USB (serial) .. Then use USART2 foe GPS in

Why isn't USART1 in play ?

 
@daddygo
I'll have a look at the IOC

Edit: Neat trick with the pfS , and CDN77 

[daddygo]

USART3 originally GPS_RX / TX - and already having trouble finding free PINs and keeping them compatible with original BP & GPSDO main board.

Now that would be Crazy ...
Not to move USART3 to ie USART1 if possible.

One of the things that i would have hoped to get w. the H3 , was USB Serial & fw upgrade.

I would even say "ditch" USART2 (gps passthrough) , and do that via USB (serial) .. Then use USART2 foe GPS in

Why isn't USART1 in play ?

 
@daddygo
I'll have a look at the IOC

I'd regret the USB too, so let's work on that, if you load the .ioc you'll see better what AF are still free.

USART1 may still be in play, but it cannot be driven out to all PINs due to AF (alternate function)
you can see this in the H503 PDF, from page 52.


I have a ready-made, sandwich-mounted impedance driver designed for this GPSDO, which handles the GPS module with its own USB via CH340 chip...

all ideas are welcome 


BTW:
many of the limitations come from wanting to keep the original BP (F103) compatibility as well

[bingo600]

@daddygo
I see what you mean wrt. keeping BP compatibility , and the GPSDO layout   
And being "locked in" by BP Pin constraints.

Dang ....

The nice functionality(s) , only seems possible if you relax the BP compatibility and make a H5 PCB with "adapted pinout" for the GPSDO socket.
And then your initial goal : A "BP on Steroids" PCB for other uses.

[fredo_]

I'm using a 4 layer PCB, but it's still hard to find a way to drive this one PIN to the original GPSDO BP position, it would also lose the original BP PIN compatibility.
I haven't given up on this and I'm still thinking hard about a solution...

Yeah pretty crowded there!...
Regarding BP PIN compatibility, since PB11 does not exist on H5 anyway, maybe you could manage to route PA12 to both PB11 and PA12 header pins ?

Could it be used (repurposed) for generating the 1PPS or other "clean" frequencies , would be output compare match (hw). And therefor 100% correct (apart from pll jitter)
I was already thinking about this 32bit timer when I configured the H5 .ioc, there is still plenty of empty TIM (5,6 & LPTIMs) and 32bit would be a good resolution for PPS,  - yes.
@fredo_ do you think we should move to the empty TIM5, - say? , - is this causing problems in the code for you?

Well the PPS output is already (software) controlled by TIM2, so it will benefit from the 32bit resolution.
We could probably also configure another IO to be hardware controlled by TIM2 (e.g. PB2 with TIM2 Ch1) to have an even more precise PPS output.


P.S.: Good luck for the situation in Portugal @daddygo, hope power will be restored soon!

[bingo600]

Well "while waiting" .....

I changed the 7805CV 5v regulator, and built in a pre-switcher to take down the input voltage to 8v.

The 5v regulator is now Micrel MIC2940A-5-BT.
Should be a bit quieter, and should have a better tempco.

The buck switching module i used is this one, MP1584EN based.
https://www.aliexpress.com/item/1005005870392716.html?

I adjusted the output to 8.2v,but think i could go lower, maybe around 7.2v Since the MIC2940 is an LDO.
But you also have to take the "reverse voltage" diode drop into account ... I think i lost almost 1v there.

Lets see how performance is now.
Maybe the switcher is creating some noise....
Maybe it should have been applied outside the box... Would have been easier, as i would not have to do the "creative wire mods" inside the box.

We will find out ...


Edit:
Well the switcher doesn't seem to have any bad influence.
I have 16 Sats , and the PPB is shifting between 0.11 and 0.00

/Bingo

[bingo600]

Well the stability does absolutely not seem to be affected.
Look at counters average 
Not that bad for a FLL ...

Counter 10S gate time , and ext-ref from a Thunderbolt.

[daddygo]

I'm using a 4 layer PCB, but it's still hard to find a way to drive this one PIN to the original GPSDO BP position, it would also lose the original BP PIN compatibility.
I haven't given up on this and I'm still thinking hard about a solution...

Yeah pretty crowded there!...
Regarding BP PIN compatibility, since PB11 does not exist on H5 anyway, maybe you could manage to route PA12 to both PB11 and PA12 header pins ?

Could it be used (repurposed) for generating the 1PPS or other "clean" frequencies , would be output compare match (hw). And therefor 100% correct (apart from pll jitter)
I was already thinking about this 32bit timer when I configured the H5 .ioc, there is still plenty of empty TIM (5,6 & LPTIMs) and 32bit would be a good resolution for PPS,  - yes.
@fredo_ do you think we should move to the empty TIM5, - say? , - is this causing problems in the code for you?

Well the PPS output is already (software) controlled by TIM2, so it will benefit from the 32bit resolution.
We could probably also configure another IO to be hardware controlled by TIM2 (e.g. PB2 with TIM2 Ch1) to have an even more precise PPS output.


P.S.: Good luck for the situation in Portugal @daddygo, hope power will be restored soon!

Hi @fredo_

THX, - but I am the son of fortune, - with my family 

I hate cell phones because they are data thieves, so this was not missed during the total blackout...
by the way, I don't have a mobile internet subscription on my phone - I may be the only one in the world with this, no problem anthropologists of the future will show me in a museum,  like a Pharaohs... hahahahaha

I had power and internet throughout the event, I have a 12.5KW Growatt battery system and internet from a nearby data center...

So here's what we (chatting in PM with @bingo600) came up with, since original BP compatibility is hard to maintain if I'm converting to this GPSDO, these are the PINs and the physical size of the PCB itself.

I will finish the BP power tuning with the H503 and use it as a starting point for a special MCU PCB development for this GPSDO, which will remain 80 - 85% compatible with the PCB I have designed so far.

I'm reworking this power BP a bit to use the remaining space in the GPSDO box and to more freely route the MCU pins to the 20PIN headers.

We can start the USB, which now collides with USART3 async. and other circuits can be added to further improve the quality of the signals...

any ideas for this version, of course the PCB area may still be a limitation, but I'll switch to 6 layers if I have to

it would be like installing our own engine 

yesterday I used a caliper to measure the inside of the GPSDO I can gain space

------- of course I'll keep the BP tunning and if anyone needs it I'll be happy to give it to you, I'm making a few of this version with the JLCPCB, I'll measure it instrumentally to see if it's good and can be used instead of the old BPs  ------

[daddygo]

Well "while waiting" .....

I changed the 7805CV 5v regulator, and built in a pre-switcher to take down the input voltage to 8v.

The 5v regulator is now Micrel MIC2940A-5-BT.
Should be a bit quieter, and should have a better tempco.

The buck switching module i used is this one, MP1584EN based.
https://www.aliexpress.com/item/1005005870392716.html?

I adjusted the output to 8.2v,but think i could go lower, maybe around 7.2v Since the MIC2940 is an LDO.
But you also have to take the "reverse voltage" diode drop into account ... I think i lost almost 1v there.

Lets see how performance is now.
Maybe the switcher is creating some noise....
Maybe it should have been applied outside the box... Would have been easier, as i would not have to do the "creative wire mods" inside the box.

We will find out ...


Edit:
Well the switcher doesn't seem to have any bad influence.
I have 16 Sats , and the PPB is shifting between 0.11 and 0.00

/Bingo

@bingo600 - nice work  and for clock sensitive circuits is this expected, has been bothering my eyes for a long time this very simple 78xx PSU and if we add a new motor to the GPSDO now, these were in my head....

just couldn't remember where I saw these (buck converter + LDO in same package), no wonder because 2014 article...

https://www.digikey.com/en/articles/combining-a-switching-converter-with-multiple-ldos-in-the-same-package-increases-design-options

&

from 2023 TI:

https://www.ti.com/lit/ta/sszt239/sszt239.pdf?ts=1746026814858&ref_url=https%253A%252F%252Fduckduckgo.com%252F

---of course we don't need multiple LDOs just one channel (5V), I've been looking for the right part

[bingo600]

@bingo600 - nice work  and for clock sensitive circuits is this expected, has been bothering my eyes for a long time this very simple 78xx PSU and if we add a new motor to the GPSDO now, these were in my head....

just couldn't remember where I saw these (buck converter + LDO in same package), no wonder because 2014 article...

https://www.digikey.com/en/articles/combining-a-switching-converter-with-multiple-ldos-in-the-same-package-increases-design-options

&

from 2023 TI:

https://www.ti.com/lit/ta/sszt239/sszt239.pdf?ts=1746026814858&ref_url=https%253A%252F%252Fduckduckgo.com%252F

---of course we don't need multiple LDOs just one channel (5V), I've been looking for the right part

Wouldn't it preferrable to get an external LDO, to "dampen" pre-switcher noise.

And having 2 x 5v LDO isn't such a bad thing ... One should be dedicated to power the OCXO, it's having the highest power fluctuation (heater on/off).
But maybe we're saved a bit by the BP 3v3 regulator, making (stabilizing) the PWM output.
But we are talking super sensitive changes on the OCXO Vctrl.
If it's a 16bit PWM every uV counts 

Some of the designs are "buffering the PWM" via a HC04/AC04 (or single buffer)  that is powered by a "very stable" (unloaded) Voltage.

.
/Bingo

[daddygo]

Wouldn't it preferrable to get an external LDO, to "dampen" pre-switcher noise.

And having 2 x 5v LDO isn't such a bad thing ... One should be dedicated to power the OCXO, it's having the highest power fluctuation.
But maybe we're saved a bit by the BP 3v3 regulator, making (stabilizing) the PWM output.
But we are talking super sensitive changes on the OCXO Vctrl.
If it's a 16bit PWM every uV counts 

Some of the designs are "buffering the PWM" via a HC04 that is powered by a "very stable" (unloaded) Voltage.

.
/Bingo

external LDO question...

-this "structure" is designed to dampen the noise and bad parameters of the DC/DC converter inside a package with built-in LDO or LDOs
for me it would be good from a design point of view because I could develop a small PCB module and use the current pads and Vin jumper header
like... TI
https://www.ti.com/lit/ta/sszt239/sszt239.pdf?ts=1746026814858&ref_url=https%253A%252F%252Fduckduckgo.com%252F

-I was thinking about a multi-channel built-in LDOs, but for that I need to modify the main PCB 

-I use the factory-recommended ST LDO, but there may be a better one from the TI collection
this seemed to me a good choice for quiescent current and PSRR aspects, so I stuck with it:
https://eu.mouser.com/datasheet/2/389/ld39100-1849679.pdf

-I would definitely like to implement HC4046, but I have not yet looked into it in depth in our case 

[bingo600]

external LDO question...
..
..
..

You're the HW Guru ... I trust you
Just "throwing balls in the air"

-I would definitely like to implement HC4046, but I have not yet looked into it in depth in our case 

That would be nice along w. the diode & MLC Cap.

Do you have any numbers on the H5 PLL Jitter, or is that still not specified in the DS/RM ?

I wonder if the 1MHz instead of 10MHz HC4046 clocking in the Lars design, was due to HC4046 max freq , or easier filtering on PFD output.