10MHz GPSDO by "BH3SAP"

[fredo_]

OK so the display is an LCD-0802 with a classical HD44780 LCD controller driven in 4 bits mode.
Contrast cannot be changed with the LCD controller but is adjusted with pin V0 as mentioned by @G4ELJ.
So easy firmware fix, as suggested, by PWM driving pin A10 on the blue pill board...
Anyone ? 

[daddygo]

Hi @Ghostrider66

Did you buy the BluePill board(s) in the EU?
Does it have the original STM32F103C8T6 (with 64K) on it?

thanks

[Ghostrider66]

My experience with such displays is that once the contrast has been set correctly, it no longer needs to be changed.
So I solved the problem with a soldering iron, three wires and a little poti (as shown in the attached photo).

[Ghostrider66]

Hi @daddygo,

yes I bought a set of five from amazon, but these are (chinese?) clones with 128 KB flash and wrong CPUID (at least for openocd).
I bought another set of three from a german distributor. These boards seem to be original (correct CPUID and 64KB flash).
The firmware from dankar runs without any problem on the clone boards.

[fredo_]

My experience with such displays is that once the contrast has been set correctly, it no longer needs to be changed.
So I solved the problem with a soldering iron, three wires and a little poti (as shown in the attached photo).

Yeah that's the hardware way of doing this for sure, but I'm more of a software guy ;-)
I managed to modify and compile dankar's firmware and add contrast setting.
I need to do some more tweaking and I'll post a new version here.
If anyone has other enhancement suggestions for the alternative firmware, feel free to ask !

[daddygo]

Hi @Ghostrider66

Thanks for your info.

I had 4 BPs on my shelf, all clones with 128K and none of them can be flashed with dankar FW, and even the original BH3SAP FW can't be...  .
Real useless units, only good for blink_led, ok this just a joke...

There's a good tool you can test to see if it's genuine ST:
https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html

Now 5pcs. of them are arriving from China, the seller claims they are original STM32, I'll see.
After, I may need the address where you bought the dankar flashable BPs if you can help me with this.

Thanks

[daddygo]

Hello @fredo_

@fredo_ : "I managed to modify and compile dankar's firmware......"
Just yesterday I managed to put everything back into a CubeIDE, you say you are a software guy (super news) because I'm just a mix of SW/HW.

Thanks for continuing to work on the "new" FW project, - I think @dankar has been busy for a while, I haven't gotten a reply from him on GitHub yet.
So, if you are interested in anno raised by @dankar, a 1PPS output generated &/or conditioned with MCU but controlled by GPS module 1PPS signal.

We need the original 1PPS from the GPS, because we need to connect / synchronised devices in different parts of the world, a stable MCU generated PPS signal is not enough, because we need synchronisation between several devices.

What do you think about this option, it is not as complicated as it sounds?

Some thoughts:


* It might be interesting to generate the output PPS from the MCU instead of from the GPS module. The GPS module can skip pulses and have some phase jitter, but the MCU output would be rock solid since it's clocked by the OCXO. One could also add a buffer amplifier/schmitt trigger to fix the impedance issue. But then again, at that point it might be more reasonable to build one of the many open source GPSDOs.

* If

[Ghostrider66]

Hi @Ghostrider66

Thanks for your info.

I had 4 BPs on my shelf, all clones with 128K and none of them can be flashed with dankar FW, and even the original BH3SAP FW can't be...  .
Real useless units, only good for blink_led, ok this just a joke...

There's a good tool you can test to see if it's genuine ST:
https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html

Now 5pcs. of them are arriving from China, the seller claims they are original STM32, I'll see.
After, I may need the address where you bought the dankar flashable BPs if you can help me with this.

Thanks

Hi  @daddygo,

Thanks for the link to the test tool. Sadly it did not work with my "chinese" clones (USB interface not recognized). With the BPs from my german distributor it worked and they are using genuine ST MCUs.

What exactly means "...none of them can be flashed with dankar FW, and even the original BH3SAP FW can't be..." ? Which tool you use to flash the BPs ?
When using openocd with an ST-Link programming adapter, with most clone boards you will get an error that the CPUTAPID is wrong (0x2ba01477 instead of 0x1ba477). You can override the ID on the command line or by changing the used config file.
With the st-link tools (you can install when using ubuntu/debian style Linux OS) the ID does not matter. My clone boards work with dankar's firmware.

And also be aware that the firmware (original or dankar's) expects an external 10 MHz clock signal, You have to remove the caps C13 and C14 on the bottom side and inject the 10 MHz Signal from the OCXO (to pin 5 of the MCU, which is the pin of the 8 MHz crystal near C13 / GPIO Pin B6).

[daddygo]

Hi  @daddygo,

Thanks for the link to the test tool. Sadly it did not work with my "chinese" clones (USB interface not recognized). With the BPs from my german distributor it worked and they are using genuine ST MCUs.

What exactly means "...none of them can be flashed with dankar FW, and even the original BH3SAP FW can't be..." ? Which tool you use to flash the BPs ?
When using openocd with an ST-Link programming adapter, with most clone boards you will get an error that the CPUTAPID is wrong (0x2ba01477 instead of 0x1ba477). You can override the ID on the command line or by changing the used config file.
With the st-link tools (you can install when using ubuntu/debian style Linux OS) the ID does not matter. My clone boards work with dankar's firmware.

And also be aware that the firmware (original or dankar's) expects an external 10 MHz clock signal, You have to remove the caps C13 and C14 on the bottom side and inject the 10 MHz Signal from the OCXO (to pin 5 of the MCU, which is the pin of the 8 MHz crystal near C13 / GPIO Pin B6).

Hi @Ghostrider66

I got a few pieces of BP from China on Friday I haven't tested it yet...
I have read many descriptions of how to tell if a chip is a clone by its physical appearance.
Well, they don't have the recessed spherical "circular shape" PIN1 marking, but flat, but that's just this first look.

I always check and flash in several ways - I usually work with Ubuntu (22.04LTS desktop), but I have everything under win10 too.

I use original ST-Link V2 and V3 from Mouser, I also have original Black Magic Probe and SEGGER J-Link on hand, but in this case I used ST-Link V2 (not USBpen type) for these clone BPs
https://www.st.com/en/development-tools/st-link-v2.html

Quartz still in place, C13 / C14 removed - I know C13 is OSCIN, but the original PCB is also soldered to C14, I don't understand the reasoning, as long as the quartz is in place it's fine.
I'm really considering to make "original" BP in KiCAD and equip it with original STM32, I just need to know how many STM32F103C8 I need in the future to make it worth it :-).

Well, these clones that don't work well show 128K as flash by default in CubeProgrammer, they work when tested with a blink LED,, but if I load dankar 0.0.12, they won't start, if I reload BH3SAP FW, they are stuck on the "10MHz GPSDO" screen and and does nothing to move on. I haven't done any serious debugging, because it should just work out of the box...
(I probably caught a really hellish clone, as it was only 0,79 USD / pcs)

So the method was: under Ubuntu --- CubeProgrammer --- ST-Link V2 (original) --- clone BP --- I tried from .bin and .elf, --- then I repeat this on win10 with similar results.

After the new BP tests, I may need the address of the German shop,, if they send a package to the EU at all

[HappySundays]

@fredo_ I’ve been unable to get his code to compile. I’m totally down with added the contrast feature and fixing a couple of bugs you’ll see soon, but cannot. If you are able to get some code running and can publish steps to do so, I’d appreciate it.

[fredo_]

@fredo_ I’ve been unable to get his code to compile. I’m totally down with added the contrast feature and fixing a couple of bugs you’ll see soon, but cannot. If you are able to get some code running and can publish steps to do so, I’d appreciate it.

Realy, are you ? We might be working on the same subjects, we should synchronize and share ! 
Here is my current state: https://github.com/fredzo/gpsdo-fw
I added the contrast menu and PPS out on PB1.
I need to run some tests and update the doc.
What bugs have your fixed ?
About building, I had no issue with original project on Windows with msys64/CMake and VSCode (you need to pacman install arm-none-eabi-gcc toolchain as mentioned in the readme).
What OS are you using ?

[HappySundays]

Hi @fredo_ yes I have flashed the updated code but very much want to fix a few things. I've added my github link below if you are interested. Thanks for adding back the contrast menu. I have two bugs that are problematic for me.
1. There is a function to automatically pop up the "Press to save" screen when the PPb gets to 0.00. Unfortunately on mine this locks up and pressing the button will not release from this screen. Some state machine screw-up I think. No need to keep doing this once the PWM has been saved once so this can easily be improved.
2. The Uptime display is bugged. Leave it for a while and you may get an enormous, impossible number there. I need to look at that.

However I'm embarrassed to say that I cannot get the code to compile using Cmake and the eabi toolchain. I'm more an IDE person and I really don't know why this is not working for me. The author and even my firmware experts here at work are like "hey just install run this then that, and it will work"  If you can give any lips/links to specific downloads I would appreciate it. I'm on Win 10 for my development stuff.

https://github.com/happyhappysundays

[fredo_]

1. There is a function to automatically pop up the "Press to save" screen when the PPb gets to 0.00. Unfortunately on mine this locks up and pressing the button will not release from this screen. Some state machine screw-up I think. No need to keep doing this once the PWM has been saved once so this can easily be improved.

The "Press to save" does not pop up when PPB gets to 0.00 (at least I don't see anything in dankar's code that would do that) but rather appears when you press the encoder.
I already fixed the bug where the menu stayed locked on "Press to save" after saving.
That saved value is only used as a starting PWM value after next boot (or as long as no GPS data is available).

2. The Uptime display is bugged. Leave it for a while and you may get an enormous, impossible number there. I need to look at that.

I did not reproduce that issue, will try to let it run longer and report.
That being said, the timer configuration for the uptime count was wrong (too long), I figured that out when using it for MCU PPS output: it was giving me 1.003 seconds or so.
That's been fixed in my fork too.
I want to check dankar's PWM adjustment algorithm too, to see if there is not the same kind of mistake.

However I'm embarrassed to say that I cannot get the code to compile using Cmake and the eabi toolchain. I'm more an IDE person and I really don't know why this is not working for me. The author and even my firmware experts here at work are like "hey just install run this then that, and it will work"  If you can give any lips/links to specific downloads I would appreciate it. I'm on Win 10 for my development stuff.

I'll add some directions in the Readme of my fork.

https://github.com/happyhappysundays

I don't see a fork of dankar's repo here, have you pushed your changes to github ?

[HappySundays]

The "Press to save" does not pop up when PPB gets to 0.00

Wow - that is so weird. On mine it definitely pops up automatically. I assumed it was when the PPB got to zero, but maybe my encoder is noisy? The control is a bit sloppy so I might look at that as well.

I'll add some directions in the Readme of my fork.

Thank you!

I don't see a fork of dankar's repo here, have you pushed your changes to github ?

Nothing there yet, just posted it in case you were interested. Once I get it to compile I will push any suggested updates to Github.

Thanks again for your help.

[daddygo]

 Hi @fredo_

I'm following your work on Github, and today I'm testing FW v0.1.0, after I managed to get a working BP with a non-clone chip.

your FW works as expected in every other aspect, however there was an assumption here that it works with uBlox module, but no
https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/msg5655451/#msg5655451

GSP module (NEO-6M) communicates independently with u-center, but not with BP... or passthrough on BP to Pins PA2 (TX) and PA3 (RX)

@dankar also just assumed that it works with uBlox modules, and I've only just been able to test it due to BP purchases

any idea why not?

BTW:
a few quick questions that came up...

-Is the PC13 LED synchronized with the 1PPS because it is currently out of sync with the GSP module PPS LED?

on this basis, there should be no discrepancy...
https://github.com/dankar/gpsdo-fw/commit/dd00fe7d59f407a57d27a8005d6d36ec38330513

or is it currently the lack of communication with the GPS module (6M)?
is there a PPS output from the MCU even if there is no synchronous PPS signal from the GPS? (I did not measure this now)
perhaps a good solution would be for the MCU to send a PPS signal to PB1 only if there is a control PPS signal from the GPS

thanks again for working on this alternative FW, you added nice things, it's looking better and better

[fredo_]

GSP module (NEO-6M) communicates independently with u-center, but not with BP... or passthrough on BP to Pins PA2 (TX) and PA3 (RX)
@dankar also just assumed that it works with uBlox modules, and I've only just been able to test it due to BP purchases
any idea why not?

Hi @daddygo,
Thank you for testing the firmware!
That's strange, I checked the GGA frame in your screenshot and it seems to have the same format as the one from ATGM336H module, it should work.
Did you wait long enough for the GPS to get a fix ?

BTW:
a few quick questions that came up...
-Is the PC13 LED synchronized with the 1PPS because it is currently out of sync with the GSP module PPS LED?

No it's not: LED1 is synchronized to the MCU controlled 1PPS output (as requested here if I understood well https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/msg5799531/#msg5799531 ).
This PPS output on pin PB1 differs from the one at the back of the GPSDO: it uses a timer from the Bluepill board to get a 100ms pulse every second based on the MCU clock (which is itself disciplined by the GPS).
This allows to have a consistent PPS out from boot time, even if the GPS antenna is not connected.
So it's perfectly normal to have a delay between GPS PPS pulse and the LED / MCU PPS output (depending on the time at which the GPS gets its fix after boot), this delay should remain constant over time (as soon as the VCO has stabilized).

is there a PPS output from the MCU even if there is no synchronous PPS signal from the GPS? (I did not measure this now)

Yes, see above ;-)

thanks again for working on this alternative FW, you added nice things, it's looking better and better

You're very welcome!
I'm currently working on the documentation.

[daddygo]

GSP module (NEO-6M) communicates independently with u-center, but not with BP... or passthrough on BP to Pins PA2 (TX) and PA3 (RX)
@dankar also just assumed that it works with uBlox modules, and I've only just been able to test it due to BP purchases
any idea why not?

Hi @daddygo,
Thank you for testing the firmware!
That's strange, I checked the GGA frame in your screenshot and it seems to have the same format as the one from ATGM336H module, it should work.
Did you wait long enough for the GPS to get a fix ?

Of course it ran all day on the test table, during operation, repeatedly tested (with u-center) the GPS TX/RX pins on the GPS module and also on the PB10/11, the GPS is long locked but the MCU is not processing the data.
Some data, certainly different compared to Chinese GPS module  (I haven't dug into it yet, I need a Chinese module too), should I collect data from the module (6M) for you?

BTW:
a few quick questions that came up...
-Is the PC13 LED synchronized with the 1PPS because it is currently out of sync with the GSP module PPS LED?

No it's not: LED1 is synchronized to the MCU controlled 1PPS output (as requested here if I understood well https://www.revolutionpermanente.fr/Magouille-Dupont-Moretti-a-achete-une-Maserati-100-000EUR-avec-l-argent-d-une-societe-offshore ).
This PPS output on pin PB1 differs from the one at the back of the GPSDO: it uses a timer from the Bluepill board to get a 100ms pulse every second based on the MCU clock (which is itself disciplined by the GPS).
This allows to have a consistent PPS out from boot time, even if the GPS antenna is not connected.
So it's perfectly normal to have a delay between GPS PPS pulse and the LED / MCU PPS output (depending on the time at which the GPS gets its fix after boot), this delay should remain constant over time (as soon as the VCO has stabilized).
[/quote]

I don't really understand the link to the Maserati in French lang., that must be what you meant 

I understood the principle, but in our installation we would place such GPSDO units in several places in Europe to control FM transmitters and they have to run in complete synchronism with each other, so the MCU is not the boss in the formula, but the 1PPS signal from the satellite, which is possibly conditioned by the MCU only, but the triggger signal is the GPS PPS output.

This allows that if the GPS PPS signal is a bit unstable (for a short time), it will be corrected by the MCU over a few pulses, but the "boss" should be the GPS PPS signal when it is stable again, thus maintaining full synchronisation.

give you an example of what I mean:
SFN Single-Frequency Network in FM broadcast:
https://www.fmradiobroadcast.com/product/detail/single-frequency-network.html
https://www.worldcastsystems.com/en/c148p215/solutions/fm-single-frequency-network

uMPX SFN sync: https://www.thimeo.com/micrompx/

is there a PPS output from the MCU even if there is no synchronous PPS signal from the GPS? (I did not measure this now)

Yes, see above ;-)

thanks again for working on this alternative FW, you added nice things, it's looking better and better

You're very welcome!
I'm currently working on the documentation.
[/quote]

Yes I'm also following this on Github, THX

[daddygo]

GSP module (NEO-6M) communicates independently with u-center, but not with BP... or passthrough on BP to Pins PA2 (TX) and PA3 (RX)
@dankar also just assumed that it works with uBlox modules, and I've only just been able to test it due to BP purchases
any idea why not?

Hi @daddygo,
Thank you for testing the firmware!
That's strange, I checked the GGA frame in your screenshot and it seems to have the same format as the one from ATGM336H module, it should work.
Did you wait long enough for the GPS to get a fix ?

Of course it ran all day on the test table, during operation, repeatedly tested (with u-center) the GPS TX/RX pins on the GPS module and also on the PB10/11, the GPS is long locked but the MCU is not processing the data.
Some data, certainly different compared to Chinese GPS module  (I haven't dug into it yet, I need a Chinese module too), should I collect data from the module (6M) for you?

BTW:
a few quick questions that came up...
-Is the PC13 LED synchronized with the 1PPS because it is currently out of sync with the GSP module PPS LED?

No it's not: LED1 is synchronized to the MCU controlled 1PPS output (as requested here if I understood well https://www.revolutionpermanente.fr/Magouille-Dupont-Moretti-a-achete-une-Maserati-100-000EUR-avec-l-argent-d-une-societe-offshore ).
This PPS output on pin PB1 differs from the one at the back of the GPSDO: it uses a timer from the Bluepill board to get a 100ms pulse every second based on the MCU clock (which is itself disciplined by the GPS).
This allows to have a consistent PPS out from boot time, even if the GPS antenna is not connected.
So it's perfectly normal to have a delay between GPS PPS pulse and the LED / MCU PPS output (depending on the time at which the GPS gets its fix after boot), this delay should remain constant over time (as soon as the VCO has stabilized).

I don't really understand the link to the Maserati in French lang., that must be what you meant 

I understood the principle, but in our installation we would place such GPSDO units in several places in Europe to control FM transmitters and they have to run in complete synchronism with each other, so the MCU is not the boss in the formula, but the 1PPS signal from the satellite, which is possibly conditioned by the MCU only, but the triggger signal is the GPS PPS output.

This allows that if the GPS PPS signal is a bit unstable (for a short time), it will be corrected by the MCU over a few pulses, but the "boss" should be the GPS PPS signal when it is stable again, thus maintaining full synchronisation.

give you a few examples of what I mean:
SFN Single-Frequency Network in FM broadcast:
https://www.fmradiobroadcast.com/product/detail/single-frequency-network.html
https://www.worldcastsystems.com/en/c148p215/solutions/fm-single-frequency-network

uMPX SFN sync: https://www.thimeo.com/micrompx/

is there a PPS output from the MCU even if there is no synchronous PPS signal from the GPS? (I did not measure this now)

Yes, see above ;-)

thanks again for working on this alternative FW, you added nice things, it's looking better and better

You're very welcome!
I'm currently working on the documentation.



Yes I'm also following this on Github, THX

[fredo_]

I don't really understand the link to the Maserati in French lang., that must be what you meant 

Oupsy, copy/paste error, original post has been fixed! 

Of course it ran all day on the test table, during operation, repeatedly tested (with u-center) the GPS TX/RX pins on the GPS module and also on the PB10/11, the GPS is long locked but the MCU is not processing the data.
Some data, certainly different compared to Chinese GPS module  (I haven't dug into it yet, I need a Chinese module too), should I collect data from the module (6M) for you?

Yes if you can send me raw data from the module, I'll see if I can find what's going wrong.

I understood the principle, but in our installation we would place such GPSDO units in several places in Europe to control FM transmitters and they have to run in complete synchronism with each other, so the MCU is not the boss in the formula, but the 1PPS signal from the satellite, which is possibly conditioned by the MCU only, but the triggger signal is the GPS PPS output.
This allows that if the GPS PPS signal is a bit unstable (for a short time), it will be corrected by the MCU over a few pulses, but the "boss" should be the GPS PPS signal when it is stable again, thus maintaining full synchronisation.

OK I think I understand where you want to go, but honestly I don't see how to achieve this...
I mean we could wait for the GPS PPS signal to come up and start the MCU PPS right at this time, but then, it the GPS goes unstable how would we know when we are supposed to re-sync with the GPS ?
I think the best/only way to achieve what you want to do is to use the GPS PPS Output which should eventually always go back in sync with other GPS in different locations.
You have that 1PPS output straight from the GPS available at the back of you GPSDO next to the GPS antenna connector right ?

[daddygo]

I don't really understand the link to the Maserati in French lang., that must be what you meant 

Oupsy, copy/paste error, original post has been fixed! 

Of course it ran all day on the test table, during operation, repeatedly tested (with u-center) the GPS TX/RX pins on the GPS module and also on the PB10/11, the GPS is long locked but the MCU is not processing the data.
Some data, certainly different compared to Chinese GPS module  (I haven't dug into it yet, I need a Chinese module too), should I collect data from the module (6M) for you?

Yes if you can send me raw data from the module, I'll see if I can find what's going wrong.

tomorrow I will record a RAW data and share it with you

I understood the principle, but in our installation we would place such GPSDO units in several places in Europe to control FM transmitters and they have to run in complete synchronism with each other, so the MCU is not the boss in the formula, but the 1PPS signal from the satellite, which is possibly conditioned by the MCU only, but the triggger signal is the GPS PPS output.
This allows that if the GPS PPS signal is a bit unstable (for a short time), it will be corrected by the MCU over a few pulses, but the "boss" should be the GPS PPS signal when it is stable again, thus maintaining full synchronisation.

OK I think I understand where you want to go, but honestly I don't see how to achieve this...
I mean we could wait for the GPS PPS signal to come up and start the MCU PPS right at this time, but then, it the GPS goes unstable how would we know when we are supposed to re-sync with the GPS ?
I think the best/only way to achieve what you want to do is to use the GPS PPS Output which should eventually always go back in sync with other GPS in different locations.
You have that 1PPS output straight from the GPS available at the back of you GPSDO next to the GPS antenna connector right ?
[/quote]
so the GPS based 1PPS synchronisation is important to have the TXs at the same moment and in sync everywhere, that's what we are working with f.e.:
https://aquabroadcast.co.uk/files/attachments/2f4496cf7a9defd997d0a458e1894aad29e0359a.pdf
if you look at the datasheet you will see that they also get 10MHz and 1PPS + via 50ohm termination (broadcast standard)

at the beginning of the thread I "pulled down" this GPSDO because the 1PPS is high impedance the 6M PPS output is directly connected to the backplane (and it's untreated, even though it would have been cheap and easy on the original PCB), ergo not loadable with 50ohm, so I added a Schmitt trigger + buffer amp. when I saw that you & @dankar started to develop the FW, so it will be usable for us in the long run

now I further simplify this impedance driver/buffer to 1ch only

BTW:
to your question, everything is the same as your unit with 2 SMA + 1 BNC signal connector on the back panel

[HappySundays]

Hi @fredo_ I just saw your updated build instructions on GitHub. 10000% improvement on the original! I will download the suggested tools and give it a try.

[fredo_]

I just released a 0.1.1 version : https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#alternative-firmware-for-the-bh3sap-gpsdo
Documentation has been updated with new features:
- Contrast setting
- Comprehensive menu system with:
    - PPB sub menu to see mean and instant PPB values along with measured MCU clock frequency and PWM correction
    - GPS sub menu to display various GPS ingormation (latitude, longitude, altitude, HDOP etc.)
    - PPS sub menu to monitor and configure MCU controlled PPS output
    - Version menu to show firmware revision
- LED1 blink every second (as on the original firmware)
- Fixed PWM save menu
- 'X' icon blinks when the GPS module is not locked

@daddygo I updated the MCU Controlled Output as you requested: https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#mcu-controlled-pps-output
Let me know if it fits your needs.

Please feel free to report any bug or feature request.

[daddygo]

I just released a 0.1.1 version : https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#alternative-firmware-for-the-bh3sap-gpsdo
Documentation has been updated with new features:
- Contrast setting
- Comprehensive menu system with:
    - PPB sub menu to see mean and instant PPB values along with measured MCU clock frequency and PWM correction
    - GPS sub menu to display various GPS ingormation (latitude, longitude, altitude, HDOP etc.)
    - PPS sub menu to monitor and configure MCU controlled PPS output
    - Version menu to show firmware revision
- LED1 blink every second (as on the original firmware)
- Fixed PWM save menu
- 'X' icon blinks when the GPS module is not locked

@daddygo I updated the MCU Controlled Output as you requested: https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#mcu-controlled-pps-output
Let me know if it fits your needs.

Please feel free to report any bug or feature request.

@fredo_
You said a while ago that you didn't know yet how to solve what I raised, but you really know how to do it, hihihi 
I haven't tested it yet due to lack of time, but it's very close to what I need.

The FW is getting better, definitely a huge improvement over the original, ----, big thanks

BTW:
yesterday I collected data from the NEO-6M module, I'll PM it because it contains the coordinates of the our lab in the office and I don't want to post it here
in the meantime 5 Chinese GPS modules (ATGM336H) are on their way to me, can be cross tested...

[HappySundays]

Hi @fredo_
By the time I've managed to compile this you would have made it perfect! I've PM'd you with a question so that I don't clog this thread with unrelated stuff. Thanks for your help.

[daddygo]

I just released a 0.1.1 version : https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#alternative-firmware-for-the-bh3sap-gpsdo


@daddygo I updated the MCU Controlled Output as you requested: https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#mcu-controlled-pps-output
Let me know if it fits your needs.

Please feel free to report any bug or feature request.

Hi @fredo_

Thanks for the PM, but I'll come back here so others can see the conclusions...

NEO-6M GPS module works without problems now, - so this can also be used if you have this version.

Edit1.....
In answer to your PM question:

Before that I tested with v0.1.0 FW, measured continuity with multimeter and as I mentioned above (prev. post) TX to PB11 and RX to PB10 were no problem, I also monitored these PINs with USB-TTL converter and had data in u-Center. (but I could not get any data on the GPS UART Passthrough PINs in u-Center)

Conclusion, since the code is unchanged, the problem must have been with the v0.1.0 flash process, because today I just uploaded v0.1.1 and everything works fine.
Thank you for looking at this so quickly for me .

One observation, - after flashing the current FW, the contrast value is 75. But at this value the display flashes, at 80 this is ok maybe the initial value should be set to 80 by default this is just a cosmetic issue.
(for less experienced users, we save a problem detection  )

Question, - the sync and method of 1PPS signals can be followed perfectly in the intuitive PPS menu, it was a super development.
Did you match PC13 LED to this?

Thanks


Edit2:

Oh yes, and I tested GPS UART Passthrough without any problems by installing an Olimex BB-CH340T module to placed above BNC port, so we can access the GPS data from the outside.
https://www.olimex.com/Products/Breadboarding/BB-CH340T/open-source-hardware

Note: converter must be 3.3V compatible, because of PA2 and PA3, - not 5V tolerant!!!