10MHz GPSDO by "BH3SAP"

[KungFuJosh]

I got this 10MHz GPSDO in today, and it's pretty cool for the ~$60 I bought it for. Given the price, I wasn't expecting a lot, but it seems good to me so far.

It looked pretty stable on the SDS2504X HD:




But was much better on the SDG2122X:




The device doesn't come with instructions or a power adapter. It uses a 12V center positive DC adapter...they also didn't bother to note polarity anywhere.

Control with the single knob is a little weird at first. A single press will bring up the menu, and turning the knob counter-clockwise will scroll through some options. Press the knob again to change the selected setting...which appears to do nothing. 🤣

There's a frequency offset option which starts with 0.0Hz. I tried it at -10Hz, -100Hz, it set itself for some reason to 6543.6Hz, and none of them had any effect on the output frequency. Correcting it from the 6543.6Hz thankfully went faster than if it was actually set that high since spinning the knob takes forever.




The inside says "Made By BH3SAP" but that didn't help with any searches for more info. The attached board looks like an [edit] STM32 Blue Pill. If anybody is good with those, it might be a fun thing to mess with.




Thanks,
Josh

[squadchannel]

https://www.qrzcq.com/call/BH3SAP
BH3SAP seems to be Chinese. You might be able to find him if you search the forum somewhere.

[jasonquin]

BH3SAP is a Chinese call sign. This guy made some HAM radio stuff on Chinese internet.

And that is a STM32 Blue pill.

[KungFuJosh]

BH3SAP's design seems pretty cool. I was surprised by the stability.

This thread is the only thing that comes up searching for his callsign on this site. I'm curious if there's a firmware variation out there.

[daddygo]

Hello,

We bought two pieces for FM transmitters SFN sync... for test only now.
As long as you're measuring with a 1M ohm oscilloscope input impedance, you'll be just fine. (Not a nice sine wave, but acceptable, the 1PPS signal is not beautiful either, a bit noisy)

Once you plug it into a standard 1PPS/10MHz inputs (that expects you to use cca. 3Vpp and 50 ohm imp.) everything goes wrong.
This is more Chinese rubbish, pardon the expression...

I would suspect the source impedance of the 1PPS output being too high and when loaded with 50R input impedance load the level drops below valid threshold.

Br, D

[KungFuJosh]

We bought two pieces for FM transmitters SFN sync... for test only now.

What device did you buy? Your screenshots look nothing like what mine shows.

[daddygo]

Exactly like yours, only the GPS unit is different, uBlox Neo-6M...
What causes the problem is that the 1PPS output is directly connected to the SMA from the uBlox panel, no impedance control element

[KungFuJosh]

What causes the problem is that the 1PPS output is directly connected to the SMA from the uBlox panel, no impedance control element

Were your screenshots from the 1PPS output?

Either way, I don't think it's fair to call a $60 item "Chinese rubbish" when you can easily spend hundreds or thousands of dollars on one depending on the quality you need. I wouldn't be happy comparing a $400 oscilloscope to a $4000 oscilloscope either.

[daddygo]

Yes from 1PPS you can see this from the frequency 1Hz...
We bought the two units on AliExp for $210 e.g. 105 / pcs. and were refunded 75% after submitting the measurement results, we now have two "toy" GPSDO units.

You're lucky if you got it for $60, but it's not a serious tool 

We work with Trimble tools, but we were tempted to try this one as well, as it comes in a factory box and we box the Trimble stuff ourselves, like this on teh picture...

The impedance matching minimum requirement!
You can see on the pictures (attach.) that the PIN 1 of the GPS unit runs directly to the SMA connector, only one pulse LED with 150R more...

When you connect it to an $18 000 FM transmitter where everything is standard 3 - 3.5Vpp / 50R with the 1PPS mark drops to 1Vpp, the 10MHz also halves and you get this horrible distorted sine wave.

It's not the Chinese thing or origin that's the problem, the problem is that some people are selling it in bad faith

[KungFuJosh]

Of course it's a toy for $60! That's why I bought it. I was thoroughly impressed with it's performance because it's a $60 toy. I was also unwilling to spend the $$$ on a "real" GPSDO since I have absolutely no need for one.

You connected what you paid $25 for after discount, to an $18,000 piece of equipment, and weren't impressed with it. I'm not shocked by that. 😉😉

It almost goes without saying people sell stuff in bad faith, especially on AliExpress. Go buy a TinySA Ultra (which is a great tool for what it is). It's still on the toy end of the spectrum, and yet, lots of people sell mediocre clones in bad faith. I don't expect any of them, be them real or fake, to compete with a $1500 or $15,000 spectrum analyzer.

[daddygo]

I see you're a big fan of lab instruments, -I have been using them for 30 years 

Well, we'll stick with the Trimble or something like this:
https://tomverbeure.github.io/2023/07/09/TM4313-GPSDO-Teardown.html

 as it is also available for 80USD and this work properly and have impedance matching...

[KungFuJosh]

Stop it! I don't need another GPSDO! I'm not gonna buy it. I'm not gonna buy it. I'm not gonna buy it. 🤣🤣

Damn it, it even looks cooler.

[daddygo]

Ours is already on its way 

[KungFuJosh]

Seems like there are issues with the 1PPS on that one too: https://www.eevblog.com/forum/testgear/tm4313-gpsdo-strange-behavior-after-a-night-of-poor-reception/

I'll avoid the topic for now, since I really don't need one. I'll probably return the one I already have too.

I've seen some other variations in this lower budget range that have LCD displays and give more info, but I have to keep reminding myself, I have no use for this. 🤣

[nctnico]

BH3SAP's design seems pretty cool. I was surprised by the stability.

Did you reference your oscilloscope to a Cesium clock? If not, your measurement results mean very little (to put it mildly).

Best thing you can do in your own lab (without a Cesium clock) is to get 2 known-good GPSDOs and compare them to the GPSDO under test using a time interval counter (with better than 1ns resolution) over a period of 48 hours. You'll need to 3 take of those measurements. Then you can do a 3 cornered hat comparison and draw some kind of conclusion.

[daddygo]

Together with this divider it will work fine, I started to build it, have GERBER and everything, the author (Oleg) also has TM4313

https://olegkutkov.me/2021/04/10/1pps-square-clock-8-channel-distribution-amplifier/
https://olegkutkov.me/2021/02/28/1pps-distribution-circuit/

[nctnico]

Together with this divider it will work fine, I started to build it, have GERBER and everything, the author (Oleg) also has TM4313

https://olegkutkov.me/2021/04/10/1pps-square-clock-8-channel-distribution-amplifier/
https://olegkutkov.me/2021/02/28/1pps-distribution-circuit/

I don't like the way you split the signals at all. Better put resistors as close as possible to the chip driving the output amplifiers and match the impedances of each trace individually at least at 1 end. Otherwise you get a whole bunch of reflections.

Also, when dealing with 1PPS, termination is actually more important because it is a pulse. 10MHz is typically a sine wave which doesn't have trouble with reflections where it comes to deformation of the edges.

Another thing to keep an eye is adding input / output protection against ESD by adding some high-speed TVS diodes.

[flash2b]

Mine arrived today and has a purple PCB (date code 240617 so pretty new!) opposed to the green PCB (date code 231024) of the KungFuJosh

The GPS/Beidu module is a ATGM 336H-5N-31, where as the red module (on the PCB of daddygo above) is a NEO-6M.

Main controller ARM cortex STM32F103C8T6 (Blue-Pill, "Performance" version) with micro USB (the topic starter (KungFuJosh) has USB-C Blue-Pill version)

Result on the Racal-Dana 1998 (Option 04E)

Hope some new firmware arrives someday.

Did anyone attach an USB-TTL module to STM32, PA9  TX    —->   Rx of USB-TTL and  PA10  RX   —->   Tx of USB-TTL to see if there are things/text coming out from the controller ?

Manual from the QR code on the package
 GPSDO使用说明 英文.pdf (1348.16 kB - downloaded 155 times.)

[Gertjan]

Did anyone attach an USB-TTL module to STM32, PA9  TX    —->   Rx of USB-TTL and  PA10  RX   —->   Tx of USB-TTL to see if there are things/text coming out from the controller ?

Indeed a pity that this GPSDO does not have a serial interface with NMEA output....

It means no opportunity to see a lot of information that makes the use of a GPSDO more reliable, and makes it better to understand what is going on. Such as info on number of satellites received, their SNR., Azimuth and Elevation Graph, HDOP and VDOP) parameters etc.
See for an example of a NMEA monitor: VisualGPSView
It also precludes the use of Lady Heather.

Normally I would expect NMEA output on the TX terminal of the GPSDO module, but I do not know this ATGM 336H module.
Probably the STM32 also uses this port for communication. But as NMEA is a read-only data stream, it might be possible to read out the TX port in parallel. When the STM32 communicates only at startup with the GPSDO module (to set the module up), there might still be a clean NMEA stream at the TX output.

And, maybe, BH3SAP made the NMEA data available at an output pin of the STM32.
This, as well as the output of the GPS module, is easy to check with an oscilloscope.

Regards, Gertjan.

[flash2b]

I will do some probing on the ATGM 336H-5N-31 (datasheet attached) and the STM32 and let you know.

[KungFuJosh]

This was one of the reasons I returned mine. I couldn't set any offset, and when I tried, it set itself to this the next time I checked the offset. 🤷

[mianos]

I got one, it was something 10kHz out and could not be adjusted. As the above post, I sent it back. I wonder if they sent him mine.

[flash2b]

The bug only occurs when applying a negative offset, it does not occur applying to a positive offset. It is however a display bug since saving a negative offset does apply the value to the GPSDO. After re-powering, the saved value is not displayed correctly in the menu, but the saved value is applied correctly to the GPSDO. You only have to set and save the offset once.




The picture above shows the offset value displayed after re-powering. If you look closely to the value it is 65533 which is 3 less that 65536 which is the maximum value of 2^16 = 16 bit max. The bit16 is usually set for a negative value of a signed int so its value -3 which should be displayed -0.3 adding the decimal point after the 4th digit. Therefore I recon it is a display error. You should not save the value again since then the original is overwritten incorrectly.

[KungFuJosh]

The bug occurred on mine no matter what offset I tried, positive or negative. The offset also never had any effect at all on the frequency output.

[flash2b]

So your unit didn't apply the value to the output frequency of the GPSDO which seems a hardware failure. Your experience with the OFFSET seems the same as my unit has, but on positive and negative so maybe other firmware version with my unit.



I did enter the menu after PPb reached 0.0. (antenna needs to be connected and satellites need to be 'seen'). Once adjusted to an OFFSET value the PPb comes back with a + or - number and PWM will count up/down so that PPb will be 0.0 again. Its fiddly and not so easy as described in the manual, but the manual steps are described. The OFFSET function is not described so maybe the manual is for an older version. At the end the output is adjusted up or down according to the setting. Range is +/- 100Hz.

[KungFuJosh]

You definitely have a different firmware, I don't recall that setting existing in mine.

[flash2b]

The PPb / PWM menu starts after powering up with a connected antenna after PPS on the  ATGM 336H-5N-31 starts blinking in Red (1Hz). This means the unit receives GPS/Beidu information from the satellites. This may take some time and the antenna position must be ok to receive signal but for my unit it starts very quickly.

If no satellites found, the unit stays on the "10.00Mhz / GPSDO" main screen.

The PWM adjusts the 1 unit PWM = 0,000076 V adjustment voltage to the OCXO. Saving needs to be done so that the next time the unit starts it goes more quickly to 10MHz output.

[KungFuJosh]

I saw the PWM screen. I never paid attention to it after startup, and never saw a PPB value. Oh well, too late now.

[flash2b]

I see you're a big fan of lab instruments, -I have been using them for 30 years 

Well you did not spend much on you FNIRSI 1014D for the PPS measurement which is also a "toy" compared to a real oscilloscope, while the topic starter had a Siglent SDS2504X HD.

[flash2b]

Today I had some time left to examine the start-up behavior of this GPSDO. For this i warmed up (about 4h) my Raca-Dana 1998 (Option 04E) and played around with TestController. It took longer than expected, since I am not a TestController expert, to produce the graph that is attached below but it was a success.



The GPSDO was already calibrated and config saved. It shows that the output stabilizes after about a minute, before that the PPS is already blinking (unit is open) so satellites are found, the GPS modules and antenna work very good with this unit.

[KungFuJosh]

TestController is great, but there's definitely a learning curve, especially when making a chart. Look at my settings for chart screenshot, specifically at the SDM3065X Vdc values for some hints at getting clearer info & better details.

[flash2b]

Yesterday, after a very long measurement session where a friend of mine brought a Miller GPSDO, we hooked up all our counters to the Miller GPSDO on the Ext Ref input and the BH3SAP GPSDO to the counter input with the following result:
 

The difference was 0.001Hz, so not bad  at all. Apart from the quirky controls this GPSDO is actually very good value for money and accurate as well.

[montecri]

Wondering if somebody got the firmware code for it. Can think of several improvements that can be made.

[flash2b]

montecri, do you also have this GPSDO?

If yes, do you have the same version and what is your accuracy compared to other standards. What improvements are you looking for.

[montecri]

Yes, got the exact same model, purple PCB.

Unfortunately, I don't have a standard against which to compare it yet. I used it to calibrate a CTI OXCO using an oscilloscope to put both channels in sync by adjusting the CTI trimpot.

I'd like a richer interface, with lock status, number of satellites in view, uptime, etc.

[807]

I noticed the gravitational effect on the xtal oscillator while playing with this unit.

Using the Leo Bodnar Mini GPSDO as an external reference of my frequency counter & measuring the frequency of this unit, it varies slowly between +2mHz & -2mHz when sitting on a level surface. When the unit is tilted upwards so that the display is uppermost, the frequency increases by around 30mHz. When tilted so that the display is downwards, the frequecy decreases by a similar amount.

It can be seen more noticably when using a 2 channel scope. When left in any orientation it gradually recovers over 2 to 3 minutes.

I have the purple PCB with date code 240705.

The display could have been made much more user friendly.

[dankar]

I bought one of these recently and ended up taking it apart, doing some reverse engineering, and writing a new firmware for it: https://github.com/dankar/gpsdo-fw

I'm not sure if my calibration against the GPS PPS is correct, but it seems to work. I started to reverse engineer the original firmware but that ended up taking too much time.

More information on how the firmware works is in the README.md. Please feel free to try it out. Suggestions and contributions welcome.

There are currently no build/flash instructions, but it's a cmake project using arm-none-eabi-gcc. I used stm32cubeMX to generate a lot of the init code, the project file is "gpsdo.ioc". The Blue Pill dev board inside has SWD connector which can be used to flash it.



Displays shows, from top left to bottom right: PPS indicator, number of satellites, current measured PPB error and UTC time.

EDIT: Oh, and this was quickly thrown together. The code can definitely use more love.

[flash2b]

Hi dankar, thank for you effort for new firmware. Is it possible to add a "bin-file" on your GitHub file so that we can prepare an empty bluepill for easy programming ?

[dankar]

Sure: https://github.com/dankar/gpsdo-fw/releases/tag/v0.0.1

"release.zip" contains both an elf and a bin. This is your reminder to backup the current firmware before flashing this one. I have the original one saved, but uploading it somewhere is probably not okay.

EDIT: Btw, if you plan on replacing the bluepill, you need to know that there is a wire under it, attaching to one of the legs of the xtal. On mine I can lift the bluepill from the headers without cutting the wire, but only barely.

[montecri]

For sure following and testing this project. Thank you!

@flash2b Can you work your magic with the frequency counters on this new firmware?

[montecri]

Just flashed your 0.0.2 version. Testing...
Just flashed your 0.0.3 version. Testing...

[dankar]

Yeah, I did some changes and is now up to v0.0.3. Doesn't mean it's better though Second "page" accessible via the encoder now shows more digits of the measured PPB.

Some thoughts:

* The VCO is controlled with a simple PWM DAC. In case you want to run the USB peripheral to get a virtual serial port with comms/NMEA you would need to run the timers at 10MHz. We get a bit more resolution when measuring the frequency when running at 70MHz (assuming the PLL maintains a good lock). But running at 10MHz and using 16 bits of the PWM, we only get 150Hz out. This might be a bit low for the DAC circuitry, which I haven't investigated closely (it's a couple of low pass filters, but I haven't checked the values of the components). At 70MHz and 16 bits we get 1kHz. It would be possible to run USB and get PWM at 1kHz with 13 bits precision instead. Does this matter? I haven't done the math to check that.

* It might be a good idea to switch to some averaging for the adjustments once it's close to stable.

* The 128 seconds averaging to show ppb on the display is perhaps a bit overkill, but from some quick math it's needed to get down to mHz range. On the other hand, it's currently just an indication and is not used for the adjustments.

* 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 my measurements are correct, it seems to be sensitive to ambient temperature changes. Insulation around the OCXO might be a decent idea.

[montecri]

I don't have yet the equipment needed to test the accuracy of the device. For now, can contribute with functionality tests and suggestions only.

Mine has been running solid on 0.0.3 for the past 3 hours. Slow to reach the desired precision, but that is more or less given on a long-running device like this one. Some time to reach the working temperature and settle on the desired PPB is kind of expected.

Suggestion: How about making the PPS screen indicator a "spinning bar"? Like, alternating in sequence the characters | / - \  |  / - \ to create the illusion of a bar spinning?

[dankar]

I don't have yet the equipment needed to test the accuracy of the device. For now, can contribute with functionality tests and suggestions only.

Mine has been running solid on 0.0.3 for the past 3 hours. Slow to reach the desired precision, but that is more or less given on a long-running device like this one. Some time to reach the working temperature and settle on the desired PPB is kind of expected.

Suggestion: How about making the PPS screen indicator a "spinning bar"? Like, alternating in sequence the characters | / - \  |  / - \ to create the illusion of a bar spinning?

It shouldn't be that slow. If my memory serves, the original FW reaches it much faster, and there's a lot that could be improved in that department.

Suggestions on the UI are very welcome! It's hard to squeeze in meaningful information on 8x2.

[dankar]

I've now also added access to the GPS module via two pins on the bluepill. The module (ATGM336H version) can be configured via GnssToolkit and it seems like you can configure it for stationary usage. Not sure exactly how to do it though, and I don't think it would matter that much for this device.

EDIT: Firmware should now also work if you have a ublox-module, which it seems like someone had.

EDIT2: README is updated with current state of the firmware. I don't have any other ideas on what to implement for the moment, unless anyone tests the firmware and finds that the calibration isn't working, or something along those lines.

[Jdw1953]

I also have newer purple board (240705) and agree the menu is not very robust. Anyone figure out what is intended by adjusting CONTRAST? The number changes with rotation of knob but nothing I can see is changing with it.

[flash2b]

Even newer than my purple board (240617) so getting popular ?

Contrast on my GPSDO seems also have little effect turning the knob. Since there is no additional info on the firmware on the internet available we can only guess.

[montecri]

Guys, check out dankar's firmware v0.0.12 for this GPSDO. For me, it's much better than stock (to which I'm never going back).

[Gertjan]

I've now also added access to the GPS module via two pins on the bluepill. The module (ATGM336H version) can be configured via GnssToolkit and it seems like you can configure it for stationary usage.....

Hi dankar,
Do you think it is possible to get NMEA data out of this GPSDO?
It would be a big improvement to be able to monitor reception (number of satellites, signal strength) etcetera. That would make one more confident in the quality and reliability of it's output signals...

[dankar]

I've now also added access to the GPS module via two pins on the bluepill. The module (ATGM336H version) can be configured via GnssToolkit and it seems like you can configure it for stationary usage.....

Hi dankar,
Do you think it is possible to get NMEA data out of this GPSDO?
It would be a big improvement to be able to monitor reception (number of satellites, signal strength) etcetera. That would make one more confident in the quality and reliability of it's output signals...

That has been done, but you need to solder wires onto two of the pins of the MCU board (PA2 (TX) and PA3 (RX), 9600 baud). Unfortunately there is no easy way to use the USB port on the board for that. My firmware also shows the number of satellites on the display. But be warned, I don't think anyone has tested the accuracy of my calibration code yet.

[Jdw1953]

I’m continuing to review comments about this specific GPSDO on eBay reviews as well as here. Some are saying that the OFFSET AND PWMSET values that you save via menu are only used as initial values whenever doing your next GPS calibration. A completed calibration is active only as long as GPSDO remains powered up (and locked by saving it in menu at that time) the next power-up however you first need to do another GPS calibration before use (but happens faster this time because you have the previous values for the calibration procedure to start with).

Some people (like myself) have tested this GPSDO with Oscilloscope/Frequency counter and not seen any change in output by just saving the offset (say like 80 Hz for example) but no way it influences measured output but the GPS calibration procedure takes longer to complete when starting with a large saved offset.
These crystal oscillator circuits change some with age, temperature, etc. so makes sense that whatever is learned during calibration is trusted by whatever application that is needing a near perfect 10 MHz at that point in time. Just do not power it down until you are finished using it.

These are just my observations and thinking so far.

[flash2b]

I have tested the accuracy (see some posts above) against a Miller GPSDO and it was within 0.001Hz.

I have also tested the OFFSET function and that changed the output accordingly (see some posts above). I used -0.3Hz. There is however a bug for negative offsets stored, and I do not really use it since I want 10MHz output exactly. I believe the OFFSET should be saved -after- PWMSET is saved. There is no mention of OFFSET in the manual whatsoever.

The PWMSET value after correctly saving, so dial to PWMSET, push the knob, dial to EXIT, push the knob, works and the value is stored. This is however for use after power up without the antenna, so as a "normal" XO. Then this value is used a reference. Once you reconnect the antenna, the GPSDO starts to align the PWMSET again. This is described in the manual (which I posted above).

Above all applicable to the stock firmware.

[Gertjan]

I've now also added access to the GPS module via two pins on the bluepill. The module (ATGM336H version) can be configured via GnssToolkit and it seems like you can configure it for stationary usage.....

Do you think it is possible to get NMEA data out of this GPSDO?
It would be a big improvement to be able to monitor reception (number of satellites, signal strength) etcetera. That would make one more confident in the quality and reliability of it's output signals...

That has been done, but you need to solder wires onto two of the pins of the MCU board (PA2 (TX) and PA3 (RX), 9600 baud). Unfortunately there is no easy way to use the USB port on the board for that. My firmware also shows the number of satellites on the display.

Excellent news that serial communication is available on pins of the MCU board!
Indeed a pity that the standard USB port can not be used. But this is easily overcome with a small Serial to USB board wired to those RX/TX pins.

Off coarse NMEA is not the only way to monitor a GPSDO. Setup and monitoring software of the GPS module manufacturer would probably work too. But still you need access tot the data stream out of the GPS module...

Do you think the signal on the RX/TX pins on the MCU board you mentioned are a direct copy of the serial data out of the GPS module? (Or are these pins simply the MCU pins where the serial port of the GPS module is connected to?  )

regards, Gertjan.

[dankar]

Excellent news that serial communication is available on pins of the MCU board!
Indeed a pity that the standard USB port can not be used. But this is easily overcome with a small Serial to USB board wired to those RX/TX pins.

Off coarse NMEA is not the only way to monitor a GPSDO. Setup and monitoring software of the GPS module manufacturer would probably work too. But still you need access tot the data stream out of the GPS module...

Do you think the signal on the RX/TX pins on the MCU board you mentioned are a direct copy of the serial data out of the GPS module? (Or are these pins simply the MCU pins where the serial port of the GPS module is connected to?  )

regards, Gertjan.

The RX/TX pins is specific to my alternative firmware, and it's a direct copy of the communication with the GPS module. So anything sent will be sent directly to the module and anything out of the module will be sent directly back. You can probably attach directly to the GPS module as well, or at the pins where it's connected to the MCU (should work with the original firmware), but I felt it was safer to "relay" the communication via the MCU.

Using this it's possible to connect with GnssToolkit3 (for the atgm336h module) or u-center (for any u-blox) and test/configure the module.

[tvmanmarks]

hi
  i am a very old hobbyist who needs an accurate 10 mhz standard to set up my frequency counter because i no longer receive wwv at my location.  now i'm having doubts about this device. will it do that simple task ?
                                            barry

[flash2b]

Yes it will do. My GPSDO had a difference of only  0.001Hz compared to known-to-accurate counterpart as well as a rubidium XO.

[tvmanmarks]

i saw a difference in price of almost double if purchased through an Ebay vendor VS direct from china. i guess with Ebay you are guaranteed satisfaction.
              anyone know why WWV at any freq is almost not available here in south fla ?

[flash2b]

I am in Europe, we have DCF77 instead so I cannot help you with that.

Ebay = AliExpress + Markup for new chinese goods. For discount buy them on single's day 11-11, sure there will be some vendors or coupons on Ali.

[Solder_Junkie]

hi
  i am a very old hobbyist who needs an accurate 10 mhz standard to set up my frequency counter because i no longer receive wwv at my location.  now i'm having doubts about this device. will it do that simple task ?
                                            barry

I built a GPSDO based on the Lars Walenius circuit elsewhere on this forum. I am puzzled about the "offset" adjustment on the BH3SAP GPSDO, surely the whole idea of a GPSDO is that it is locked to GPS and is inherently self calibrated.

Like many low cost GPSDO units, this Chinese one uses a basic navigation GPS module, you can obtain a noticeable improvement in short term stability by using a timing module. I see many constructors refer to stability over many tens of seconds, or even over a day or two... Not of much relevance when you want a reference for a frequency counter or signal generator where you want short term stability too.

The GPSDO I built is this one, which adds time/date display to the original Lars design:
https://www.qsl.net/zl1bpu/PROJ/NGPSDO/New%20GPSDO.htm

This is the main thread on the eevblog forum:
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/


SJ

[tvmanmarks]

i received mine and because i have read all posts, i had a basic understanding of how to operate it. one matter not discussed here or mentioned on the instructions was proper antenna placement to receive satellite signal indoors etc. just for fun i stuck my antenna to the side on my microwave oven and the search began. i stopped when it settled down to 0.0 .  imagine that
                                                                 barry

[tvmanmarks]

update is not good.   
 I purchased the gpsdo because i already knew my frequency counter was a bit off.  Before today counter at 10mhz after warm up read 10000.140 . so leaving it connected to gpsdo i expected frequency counter display  to change as a warmed up gpsdo went through its paces. when its display read PPB 0.0  i went to menu found pwmset pressed button to save value. pressed button again, rotated and turned to exit.
 exact same reading on freq counter as was before, during and after the adjustment of sat. receiver. tomorrow with an extension cord i'll take it outside and place sat receiving ant on roof  of my car and start over. after i'm done i'll leave  12 volt connected and with sat rcvr still on  reconnect my frequency counter.  even though at start counter display was wrong it should have changed +/- of the current display regardless.
                                                                      barry 

[bingo600]

update is not good.   
 I purchased the gpsdo because i already knew my frequency counter was a bit off.  Before today counter at 10mhz after warm up read 10000.140 . so leaving it connected to gpsdo i expected frequency counter display  to change as a warmed up gpsdo went through its paces. when its display read PPB 0.0  i went to menu found pwmset pressed button to save value. pressed button again, rotated and turned to exit.
 exact same reading on freq counter as was before, during and after the adjustment of sat. receiver. tomorrow with an extension cord i'll take it outside and place sat receiving ant on roof  of my car and start over. after i'm done i'll leave  12 volt connected and with sat rcvr still on  reconnect my frequency counter.  even though at start counter display was wrong it should have changed +/- of the current display regardless.
                                                                      barry

Or you just have an accurate gpsdo , that has the error correction better than -1e9 , and your counter can't display the change.

[tvmanmarks]

update is not good.   
 I purchased the gpsdo because i already knew my frequency counter was a bit off.  Before today counter at 10mhz after warm up read 10000.140 . so leaving it connected to gpsdo i expected frequency counter display  to change as a warmed up gpsdo went through its paces. when its display read PPB 0.0  i went to menu found pwmset pressed button to save value. pressed button again, rotated and turned to exit.
 exact same reading on freq counter as was before, during and after the adjustment of sat. receiver. tomorrow with an extension cord i'll take it outside and place sat receiving ant on roof  of my car and start over. after i'm done i'll leave  12 volt connected and with sat rcvr still on  reconnect my frequency counter.  even though at start counter display was wrong it should have changed +/- of the current display regardless.
                                                                      barry

Or you just have an accurate gpsdo , that has the error correction better than -1e9 , and your counter can't display the change.

which makes you an optimist and confirms me to be a pessimist :+)
   Saturday i  will take everything outdoors and place the antenna on the roof of my car (just like my sxm ant) and with my gpsdo andport freq counter preheated i'll have it another go at it.    hope you are right
                                                                      barry

[flash2b]

My Racal Dana 1998 using its internal OCXO is also a little bit off. However I use the BH3SAP after warming up as Ext Std so that measurements made with the 1998 are referenced that GPSDO instead. The 1998 sees if an external reference is connected, but on some freq counters you need to push a button.

In the photo I showed above, with the 3 counters, the BH3SAP is compared to a Miller GPSDO on the Ext Std. The difference is very very little.

[tvmanmarks]

went outdoors Saturday, warmed up rcvr and then placed antenna on car roof .  i allowed the setup screen time to do its thing.
right away i saw the difference as it was running its numbers to 0.1 etc.
 after finishing and 12 volts on it i checked the frequency on my un calibrated frequency counter. the reading was even more than  it was the day before but i was able to calibrate to 10mhz w/a bunch of zero's to follow.
 so your assumption was correct. disciplined or not the receiver seems to have a very accurate crystal osc. to begin with.
                          thanks again, Barry

[Pilatus]

I received this BH3SAP gpsdo last week, and so far it looks quite good on my Racal Dana 1999C frequency counter (stable to the 1 mHz over a 20s period).

I do get a gpsdo "PPb display" excursion of +/- 0.5 or so. This number seems to be updated every second on that display. Typically it is +/- 0.2 (alternating between positive and negative every couple of seconds), but I have seen it as high as 0.7 PPb.

The unit has been running for several days. My lab is located on the 2nd story of a 2 story house, sloped roof. I was thinking this may be due to poor antenna reception so I  tried moving the antenna closer to the window (on a steel plate, tried other locations within the house) with no noticeable improvement. It is snowing here so going outside is not an option for now.

I see other people's displays for this device showing a solid 0.0 PPb. Is this (a solid "0.0 PPb" display) what I should be expecting?

edit: corrected 20s counter average from 1 Hz to 1 mHz.

[tvmanmarks]

what made it work for me was first placing antenna on my micrwave but better yet my  suv's roof. with an extension cord for the receivers power supply i allowed it to warm up before adjusting settings.
                                   barry

[Pilatus]

Thanks for the reply Barry. I will try your suggestion when the weather improves.

Still, an impressive little device for the money (paid $52).

[HappySundays]

Hi all. I just received my GPSDO and was overjoyed to see that new firmware was available. I have the latest binary, but I'm not at all familiar with the bluepill. I own all manner of programmers including SWD-based ones for ST development. Haven't touched them for years though and am rusty!  A lot of sites mention the ST-Link V2 but that seems to be just a USB to SWD interface. Is the SWD interface the only way to program it? Does that USB port have no programming capability? No bootloader in there? Do I need to move any of those jumpers from the BOOT position? So sorry for the noob questions.

[HappySundays]

Update: I put on my big boy pants, did some research and used a J-Link and the ST cube programmer to get it done with no issues. New firmware works… but I might volunteer some tweaks over the break. On my unit, the default contrast is way off and there doesn’t appear to be a contrast adjustment. Not a show stopper. Initial settling time is still ongoing after an hour. I understand that once the PWM start value is saved, it will be quicker in the future. Certainly not as wobbly as the original. Happy days, and one more firmware project to work on.

[G4ELJ]

Just programmed up the alternative firmware and it is working well.

Same issue though with lack of display contrast.

Tracing the pin outs.

Pin 3 of the LCD display does to R8/C17 as an RC filter. The other end of R8 goes to Pin A10 on the Blue pill board.
Presumably in the original BH3SAP firmware a PWM voltage output from A10 is smoothed by the RC filter and gives a decent adjustment of the contrast.
Currently there is only ~100mV on pin 3 of the LCD.

Unfortunately I am not a programmer :-(

Of course one could remove R8 and just use a 10K preset with Pins 1, 2 and 3 on the LCD display to manually set the optimum contrast voltage on Pin 3.
 
Might be nice to also activate the PC13 LED to flash the PPS. One would then have another visual way of knowing that the code is running even if one can't read the display very well.

Duncan

[daddygo]

Hi @dankar

This is some frenetic work with FW, thanks.
I will now take both of our units off the shelf during the break and convert to 0.0.12 FW and they will get a buffer for their 1PPS outputs..
1PPS via MCU is also a great idea. (if you have the time)

With these modifications I look at these units with a much better eye. 


+Edit: (4ch driver on the way).... - Schmitt trigger + Quad buffer /w 3-state out


+++Edit2: under reconstruction (yes the pin headers are a bit high, 90 degrees should be installed next time)

[daddygo]

Dear  @flash2b

This osciloscope (FNIRSI) is a "undemanding - punchy unit" unit that we use in the field to avoid having to carry millions of dollars worth of lab equipment into dirty transmitter towers 
Otherwise we have one of these for more serious things:

Teledyne LeCroy Digital Oscilloscope WAVEPRO 960.

Yes I know that the other is a toy  , but suddenly measuring something 40 metres up in a tower is mostly appropriate..

[Ghostrider66]

I got mine last week and changed the firmware immediately. Nice work, many thanks for that.
For all of you who want to replace the BluePill Board before flashing the firmware from dankar:
- beware of the wire below the board, which connects the output of the OCXO with the OSC-IN Pin of the STM32 Controller (Pin 5) - or should connect
- Check the soldered wire. On my board it was soldered to the OSC-Out Pin (Pin 6). This only worked because the 8 MHz crystal was still in place. On my replacement board I removed the crystal and the two caps to gnd (not needed). Took me a whole weekend to figure out, that the controller did not get the necessary clock signal.

[fredo_]

Got mine today and flashed @dankar's firmware.
Thanks for the great job @dankar !
I put the original firmware binary file here in case someone needs it.

Same issue here with contrast being set to maximum, making it impossible to read in direct sight :-/
@dankar, I didn't see a "setContrast()" method in the LCD driver you used.
Any idea of the LCD type that is used ?

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

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

[daddygo]

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.

Hi All,

@fredo_ can you merge this on github?

@2A03 how about displaying the date in day/month/year format in the UTC time row on the main display, if this data is already avail from the GPS module, you can change the time / act. date values on the display with 5s shift for example...

- if I understand correctly only the ATGM336H setup is automated?
-  ATGM336H has 2 UART int. but NEO-6M does not
- the NEO-M9N I am developing with is also built with two UARTs

the original Chinese GPSDO comes with two types of modules, NEO6M and ATGM336H

@fredo_ & @2A03 what do you think about adding a GPS module selection menu?


I start my trip on Thursday, so I can test the FW mods until then.

THX

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

Hi All,

@fredo_ can you merge this on github?

@2A03 how about displaying the date in day/month/year format in the UTC time row on the main display, if this data is already avail from the GPS module, you can change the time / act. date values on the display with 5s shift for example...

- if I understand correctly only the ATGM336H setup is automated?
-  ATGM336H has 2 UART int. but NEO-6M does not
- the NEO-M9N I am developing with is also built with two UARTs

the original Chinese GPSDO comes with two types of modules, NEO6M and ATGM336H

@fredo_ & @2A03 what do you think about adding a GPS module selection menu?


I start my trip on Thursday, so I can test the FW mods until then.

THX

Hi. @daddygo

I couldn't add the date because the firmware only parsed the time part of the NMEA sentence.
Also, you probably won't have enough code flash to add the correct timezone.

The ATGM336H detection and configuration is in gps.c. It's a short code, so it shouldn't be difficult.
If the ATGM336H is not detected, the UART baud rate will simply be set as before.

The two UARTs are BluePill's UART2 and UART3.
It has nothing to do with whether the GPS module has two UARTs or not.

[daddygo]

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.

Hi All,

@fredo_ can you merge this on github?

@2A03 how about displaying the date in day/month/year format in the UTC time row on the main display, if this data is already avail from the GPS module, you can change the time / act. date values on the display with 5s shift for example...

- if I understand correctly only the ATGM336H setup is automated?
-  ATGM336H has 2 UART int. but NEO-6M does not
- the NEO-M9N I am developing with is also built with two UARTs

the original Chinese GPSDO comes with two types of modules, NEO6M and ATGM336H

@fredo_ & @2A03 what do you think about adding a GPS module selection menu?


I start my trip on Thursday, so I can test the FW mods until then.

THX

Hi. @daddygo

I couldn't add the date because the firmware only parsed the time part of the NMEA sentence.
Also, you probably won't have enough code flash to add the correct timezone.

The ATGM336H detection and configuration is in gps.c. It's a short code, so it shouldn't be difficult.
If the ATGM336H is not detected, the UART baud rate will simply be set as before.

The two UARTs are BluePill's UART2 and UART3.
It has nothing to do with whether the GPS module has two UARTs or not.

Hi @2A03,

Thanks for clarifying that.

The most STM32F103C8T6 nowadays has 128K FLASH (not ST???), there is a lot of discussion/info about this, but the original one does not 128, i.e. there is a hidden 64 + 64K version...

-not sure what this means in terms of implementation "correct timezone" ? 128K
(I'm more into HW stuff)


UART(s), so that's ok, but if I'm right UART3 is for the GPS module and UART2 is for the pass-through function???

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

Hi All,

@fredo_ can you merge this on github?

@2A03 how about displaying the date in day/month/year format in the UTC time row on the main display, if this data is already avail from the GPS module, you can change the time / act. date values on the display with 5s shift for example...

- if I understand correctly only the ATGM336H setup is automated?
-  ATGM336H has 2 UART int. but NEO-6M does not
- the NEO-M9N I am developing with is also built with two UARTs

the original Chinese GPSDO comes with two types of modules, NEO6M and ATGM336H

@fredo_ & @2A03 what do you think about adding a GPS module selection menu?


I start my trip on Thursday, so I can test the FW mods until then.

THX

Hi. @daddygo

I couldn't add the date because the firmware only parsed the time part of the NMEA sentence.
Also, you probably won't have enough code flash to add the correct timezone.

The ATGM336H detection and configuration is in gps.c. It's a short code, so it shouldn't be difficult.
If the ATGM336H is not detected, the UART baud rate will simply be set as before.

The two UARTs are BluePill's UART2 and UART3.
It has nothing to do with whether the GPS module has two UARTs or not.

Hi @2A03,

Thanks for clarifying that.

The most STM32F103C8T6 nowadays has 128K FLASH (not ST???), there is a lot of discussion/info about this, but the original one does not 128, i.e. there is a hidden 64 + 64K version...

-not sure what this means in terms of implementation "correct timezone" ? 128K
(I'm more into HW stuff)


UART(s), so that's ok, but if I'm right UART3 is for the GPS module and UART2 is for the pass-through function???

Hey @daddygo

The STM32F103C8T6 is 64KB, the STM32F103CBT6 (B instead of is 128KB. The fonts are similar, so it's confusing.

I think this is a good reference for how to handle timezones correctly.
https://www.ryanthomson.net/articles/practical-guide-timezones/

That's right. UART3 is for GPS, and UART2 is for pass-through.

[daddygo]

Hi 2A03,

@2A03 "The STM32F103C8T6 is 64KB, the STM32F103CBT6 (B instead of is 128KB. The fonts are similar, so it's confusing."


If only it were that easy to tell the difference between these MCu's, ST forums are full of descriptions of "fake" BP boards and MCUs 
I have quite a few on the shelf, marked STM32F103C8T6, but with 128K flash, most work fine, but some are only good for blink LED 

show you some CubeProgrammer "prtsc" with 64K & 128K flash

or f.e. from the ST & EEV forum:

https://community.st.com/t5/stm32-mcus-products/stm32f103c8t6-with-128kb-of-flash-instead-of-64-fake-or-genuine/td-p/267742
https://www.eevblog.com/forum/microcontrollers/cheap-bluepill-very-likely-it-has-fake-stm32-right/150/

[2A03]

Hello @daddygo

I opened the case and took a photo.
Is this okay?

[ME]

I tried reprograming my gpsdo blupill with stlink v2 and cube programer, It throws a msg error no     stm32 target found, do i need to change the blupill jumper settings?.

[daddygo]

Hello @daddygo

I opened the case and took a photo.
Is this okay?

Is this okay???

I do not want to disappoint you, but the BPs I have seen and I mean by that in this GPSDO are all equipped with fake MCUs, but they work...

I've already suggested this link to someone in this topic, you should try it too...

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

The market is also full of BP boards with 128K flash and they work well, so I thought there would be more headroom for further development of FW 

[daddygo]

Hi @ME,


nope, in this case you don't have to (SWD header), just follow this:

https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#flashing-the-firmware

+++edit1:
in the unfortunate event that ST-Link V2 is fake and the MCU is fake, well you know....

buy one of these, they are only pennies and later you will know that at least "programmer" is original, I use it too, and/or V3
https://eu.mouser.com/ProductDetail/STMicroelectronics/ST-LINK-V2?qs=H4BOwPtf9MC1sDQ8j3cy4w%3D%3D

The CUBE Programmer runs with a fake ST-Link V2 (in most cases), but CubeIDE, for example, will not

[2A03]

Hello @daddygo

I opened the case and took a photo.
Is this okay?

Is this okay???

I do not want to disappoint you, but the BPs I have seen and I mean by that in this GPSDO are all equipped with fake MCUs, but they work...

I've already suggested this link to someone in this topic, you should try it too...

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

The market is also full of BP boards with 128K flash and they work well, so I thought there would be more headroom for further development of FW 

Hi @daddygo

I'm using a translation tool, so my intention may not be conveyed well.

I understand that there are many fakes from Chinese clones. I tried the tool you told me about, and it seems that the STM chip is genuine and there is 128KB of flash. I've attached a screenshot.

Well, I'm happy with the firmware I modified, so I don't plan to make any further improvements even if the flash increases.

[daddygo]

Hello @daddygo

I opened the case and took a photo.
Is this okay?

Is this okay???

I do not want to disappoint you, but the BPs I have seen and I mean by that in this GPSDO are all equipped with fake MCUs, but they work...

I've already suggested this link to someone in this topic, you should try it too...

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

The market is also full of BP boards with 128K flash and they work well, so I thought there would be more headroom for further development of FW 

Hi @daddygo

I'm using a translation tool, so my intention may not be conveyed well.

I understand that there are many fakes from Chinese clones. I tried the tool you told me about, and it seems that the STM chip is genuine and there is 128KB of flash. I've attached a screenshot.

Well, I'm happy with the firmware I modified, so I don't plan to make any further improvements even if the flash increases.

Hi 2A03,

Yes, most visual "originality" check say if the PIN1 marking on the MCU is not concave inwards, it is original, like yours.
There are still plenty of fakes on the market, but at least yours is OK 

128K question, - it just came up when you wrote that flash would be low for date display, but 128 would be fine, if still need room for the code.

@fredo_ did a huge and concrete job (THX), I think FW is fine in this state, - yes we agre on it...

I just add the NEO-M9N and a 50ohm driver and that's the end of it for me also 

[ME]

well this is odd, My bp from my gpsdo gives errors and wont connect using st-link v2 but my spare bp connected and seemed to program ok!.

[ME]

Well i downloaded and flashed the attached bin , All i get is a blank display now, Any ideas?., Had to change the file extension to .doc to attach here so needs swapping back to bin ok.

[ME]

heres the log file after erasing then programing the new bin, Still a blank display tho.well it says i cant upload the file even tho its a .txt file!.

[daddygo]

heres the log file after erasing then programing the new bin, Still a blank display tho.well it says i cant upload the file even tho its a .txt file!.

Hi @ME,

I'll try to outline a sequence for you to do (watch the screen shots, pls.):

1. download the gpsdo.bin file from github, do not modify the file name (to gpsdo fredzo.bin, leave so gpsdo.bin)
2. make sure that the CubeProgrammer program and the FW of ST-Link are the latest, I currently have a new version for CUBE Prg. (v2.19.0)
3. if you want(?), but I suggest you do a full chip erase
4. then open the downloaded (github) gpsdo.bin under the pencil icon menu (top left) + Open File sign (task bar)
5. press the Download button close to the top left
6. go to the Device memory tab again and Read the uploaded FW for check only...
7. notice, check where it starts, - it should be 0x0800000000

Well, if you have a good BP and good ST-Link, even if not original, STM32 is still programmable....
if not buy a good ST-Link V2, or replace the BP 
(that's why I said it's good to buy your ST-Link from a safe place, because then you know it's OK - so much shorter troubleshooting time)

more prtsc in the next post

[daddygo]

more prtsc.....

- the last picture is the programmer settings!

Cheers DG

[ME]

Hi @ME,


nope, in this case you don't have to (SWD header), just follow this:

https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#flashing-the-firmware

+++edit1:
in the unfortunate event that ST-Link V2 is fake and the MCU is fake, well you know....

buy one of these, they are only pennies and later you will know that at least "programmer" is original, I use it too, and/or V3
https://eu.mouser.com/ProductDetail/STMicroelectronics/ST-LINK-V2?qs=H4BOwPtf9MC1sDQ8j3cy4w%3D%3D

The CUBE Programmer runs with a fake ST-Link V2 (in most cases), but CubeIDE, for example, will not

can you link the cube programer sw, is there a version of it for ubuntu?. Thank you.

[daddygo]

Hi @ME,


nope, in this case you don't have to (SWD header), just follow this:

https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#flashing-the-firmware

+++edit1:
in the unfortunate event that ST-Link V2 is fake and the MCU is fake, well you know....

buy one of these, they are only pennies and later you will know that at least "programmer" is original, I use it too, and/or V3
https://eu.mouser.com/ProductDetail/STMicroelectronics/ST-LINK-V2?qs=H4BOwPtf9MC1sDQ8j3cy4w%3D%3D

The CUBE Programmer runs with a fake ST-Link V2 (in most cases), but CubeIDE, for example, will not

can you link the cube programer sw, is there a version of it for ubuntu?. Thank you.

Hi @ME,

Find all OS versions here (ST reg. account required):
https://www.st.com/en/development-tools/stm32cubeprog.html#overview

I suggest if you are not experienced enough in Linux, you should use the Win version instead, there will be less headaches (works smoothly).

Yes, the linux installer runs on Ubuntu (I use Ubuntu Desktop 22.04LTS), so with some configuration tricks CUBE Programmer works fine under Linux.
I use it f.e. when I use IDE and MX at the same time, or say... need to do CMAKE, which is not a wizard under Windows.
(for a smooth FW upload via SWD, I stay under Win)

-as you can see in the screenshot the Linux ver. is now updated to v2.19.0 also, like the Win version yesterday

BTW:
if you are running Ubuntu on a VM env., as I am, make sure you have the correct USB pass to Linux VM for ST-Link!!!

[flash2b]

Sorry it has been a long time since I posted into this thread.

I see there is a lot of progress made with the alternative firmware, which I also want to try. I have some experience with BPs (and the fakes they sell on AliExpress) and also a working ST Link from WeActStudio (I have used it couple of times with good success). I have the STM32Cube programmer software up-to-date on my Win PC and I know to operate it.

I have the following questions:
- If I want to backup the existing firmware, do I need to downloaded this from the original BP with the GPSDO switched on ?
- What size the original firmware should be ?
- If I want to write the 2A03 version (I have an ATGM336H in my GPSDO) of the firmware, v0.1.7.1 into the existing BP, should the GPSDO be switched on ?
- If I want to compile a version myself, what software do I need additionally ?

I do not want want to end up with a bricked GPSDO, so hence my questions.

[daddygo]

Sorry it has been a long time since I posted into this thread.

I see there is a lot of progress made with the alternative firmware, which I also want to try. I have some experience with BPs (and the fakes they sell on AliExpress) and also a working ST Link from WeAcct (I have used it couple of times with good success). I have the STM32Cube programmer software up-to-date on my Win PC and I know to operate it.

I have the following questions:
- If I want to backup the existing firmware, do I need to downloaded this from the original BP with the GPSDO switched on ?
- What size the original firmware should be ?
- If I want to write the 2A03 version (I have an ATGM336H in my GPSDO) of the firmware, v0.1.7.1 into the existing BP, should the GPSDO be switched on ?
- If I want to compile a version myself, what software do I need additionally ?

I do want want to end up with a bricked GPSDO, so hence my questions.

Hi @flash2b

1.- If I want to backup the existing firmware, do I need to downloaded this from the original BP with the GPSDO switched on ?
2.- What size the original firmware should be ?
3.- If I want to write the 2A03 version (I have an ATGM336H in my GPSDO) of the firmware, v0.1.7.1 into the existing BP, should the GPSDO be switched on ?
4.- If I want to compile a version myself, what software do I need additionally ?

I will try to answer point by point:

1. you can download the original FW from BP if you are connected to it, but it is also uploaded to this thread by @fredo_ on third page in the thread
2. original-gpsdo.zip (16.06 kB - downloaded 23 times
3. no, don't turn on the GPSDO PSU, the BP through SWD header is powered by ST-Link (3.3V)
4. the fredo's github page describes how to edit the code, everyone does it differently, but the VSCode might be good for you under win
https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#building

if you also want HW changes, CubeMX first

only dependency: arm-none-eabi
https://developer.arm.com/downloads/-/gnu-rm

[ME]

Well i found another bp, I flashed it ok but when fitted to my unit ii get just a backlight with a blanc display,  See the bin as read after flashing fredzo 1.7 fw Any  ideas.

[ME]

Well i finally managed to flash the fredo 1.7 fw, Since loading the fw it seems i get no sat rx , sats listed as 0 ,Is the baud rate different for the gps on the new fw?, I programed a new bp and fitted it , My gpsdo works fine if i refit the original bp!, any ideas?, Thanks in advance.

[fredo_]

Hi ME,
Is the time displayed correctly ? If seconds are changing, it means that the serial connection with the GPS is OK.
You need to wait long enough for the GPS to get a fix, especially if you have bad reception.
Maybe check that the GPS antenna is well connected to the GPS board too, it might have moved while changing the bluepill board.
Also did you make the necessary modifications on the new bluepill board ? I never did that, but I think you need to remove a capacitor or a resistor around the crystal and you need to connect the wire from the TCXO to the bluepill board.
That should not affect satellite reception though.
Is the PPS led on the GPS module blinking ? If not, that means that your GPS was not able to get a fix.

[ME]

Ok in answer to your questions fredo, Firstly the time displays a row of zeros with an alternating minus and equal displayed top lh side of the display , The bp resistor value was ok so didnt require swapping, The gps led flashes,at about 1 hz, All connections are good on the gps board, Also the display doesent always come on, The backlight illuminates with nothing displayed, There are 2 led's on the bp red and green, When the display shows info the red led illuminates and the green one flashes, When it does that it seems to do it in a sequence sort of with the gps pcb led, The gps led flashes about 10 times with the bp green led on, Then the green bp led goes off for another 10 flashes of the gps board and the cycle continues, If i power cycle the whole unit it shows no display and the bp green led stays off, If i leave it powered off for 10 mins and power it on the  bp green comes on and flashes and the display shows info ,The wire from the main pcb to the bp xtal is connected ok, Thanks for taking the time to reply 73.   

[ME]

Just to add, When the unit first powers on when the bp green led comes on and the display works , It displays an exclamation mark followed by a flashing question mark on the lh side of the display, after about 10 seconds it changed and displays
-/= flashing alternating 00  0.00
                               ----
                           -         .----
Hope that helps.

[daddygo]

Hi @ME,

@fredo_  says that the BP, if not this original GPSDO supplied, -  PCB mod. requires, - as described in previous pages in this thread (3).

The BP will not start correctly from the main PCB TCXO 10MHz clock if these conversions are not done!!!

@ME "The bp resistor value was ok so didnt require swapping,...."
they are not resistors they are capacitors

1. pls. remove C13 and C14 (from new BP) and connect the short wires to the OSCIN pin towards the baseboard
this is the soldering point (PIN) next to the C13 cap, !!! in my picture it is not soldered over because the original quartz is in place, but you better move it..


if you do these, please come back and report back on how it went 

[ME]

So do i leave the wire from the main board still connected to the leg/pin of the bp xtal and completly remove c13+14 from the bp?,  ps i cant find the thread you talk about (3) can you llink it?, thanks.

[daddygo]

yes, remove the two caps C13 and C14, solder the small wire to the OSCIN which is the solder point next to the C13 cap (this is original 8MHz quartz OSCIN PIN to STM32), you don't have to remove the original quartz, it stays on the PCB, but it will be inactive


sorry, -  it's on the fourth page of the thread and my post, top third of the page, it's an old forum software and difficult to give an exact link
https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/75/

[ME]

Thank you removing thos caps cured it.

[ME]

Can the bp still be programed after c13+14 have been removed using st link v2?.

[fredo_]

Hi,
I just released v0.1.8 : https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.8
Changes :
- Merged potential buffer overrun fixes from 2A03
- Merged Time Zone support from 2A03
- Added 'Model' entry in GPS menu to show detected GPS module
- Added baudrate setting command for ATGM336H GPS module
- Added 'Frame' entry in GPS menu to show first characters of last received GPS frame
- Added 'Date' and 'Date/Time' screens

[ME]

nice work but againe, Can the bp still be programed after c13+14 have been removed using st link v2?.

[fredo_]

nice work but againe, Can the bp still be programed after c13+14 have been removed using st link v2?.

I can't help you here, I never did that mod, but assuming it's the same mod as performed on the original bluepill board, I can confirm that I can reflash the original board with no issue.

[ME]

Heres what happened, I flashed fredo 1.7 to the bp and I would have no display at random, As if the bp was not starting/oscillating everytime on power on, Then i removed c13+14 and it started with a display everytime, I then removed the bp to flash dankar fw to try out, the flash seemed to go ok using stlink or cube programer, However since i did that i am back to no display,i since reflashed the new fredo 1.8 with the same result ie no display,any ideas?.

[fredo_]

Heres what happened, I flashed fredo 1.7 to the bp and I would have no display at random, As if the bp was not starting/oscillating everytime on power on, Then i removed c13+14 and it started with a display everytime, I then removed the bp to flash dankar fw to try out, the flash seemed to go ok using stlink or cube programer, However since i did that i am back to no display,i since reflashed the new fredo 1.8 with the same result ie no display,any ideas?.

Maybe try a full chip erase before flashing ?: https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/msg5838749/#msg5838749

[G4ELJ]

I had that happen once on an earlier firmware.

While still powered up I pressed the reset button on the blue pill board and the firmware then booted up fine and has done ever since.

Duncan

[G4ELJ]

Hi,
I just released v0.1.8 : https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.8
Changes :
- Merged potential buffer overrun fixes from 2A03
- Merged Time Zone support from 2A03
- Added 'Model' entry in GPS menu to show detected GPS module
- Added baudrate setting command for ATGM336H GPS module
- Added 'Frame' entry in GPS menu to show first characters of last received GPS frame
- Added 'Date' and 'Date/Time' screens

Hi Fredo,

In and running fine on 2 units.

All menus working as you say. Of course over here in the UK I would prefer the date to read 11th March rather than how we read that format as 3rd November .

Many thanks to you, 2A03 and Dankar

[fredo_]

Great, thank you for the feedback @G4ELJ!
Believe me here in France mm/dd/yy was not my first choice either, but I figured I should line-up with "rest" of the world 
Maybe I should add a configuration menu for date format... 

[ME]

Heres what happened, I flashed fredo 1.7 to the bp and I would have no display at random, As if the bp was not starting/oscillating everytime on power on, Then i removed c13+14 and it started with a display everytime, I then removed the bp to flash dankar fw to try out, the flash seemed to go ok using stlink or cube programer, However since i did that i am back to no display,i since reflashed the new fredo 1.8 with the same result ie no display,any ideas?.

Maybe try a full chip erase before flashing ?: https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/msg5838749/#msg5838749

Did that as per instructions with the same result,guess removing the caps 13+14 must kill correct programing?.

[ME]

I forgot to mention i extended the osc wire from the mainboard to the bp to make it easer to fit, Its about 8cm long,could that cause the not running/blank display issue i  have?.

[fredo_]

Here is v0.1.9 : https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.9
Changes :
- Added date format setting in GPS menu (This on is for you @G4ELJ ;-))
- Added manual GPS model selection (press encoder un GPS/Model menu) in case automatic detection fails (this can happen if baudrate is not set properly)

[G4ELJ]

Heres what happened, I flashed fredo 1.7 to the bp and I would have no display at random, As if the bp was not starting/oscillating everytime on power on, Then i removed c13+14 and it started with a display everytime, I then removed the bp to flash dankar fw to try out, the flash seemed to go ok using stlink or cube programer, However since i did that i am back to no display,i since reflashed the new fredo 1.8 with the same result ie no display,any ideas?.

Maybe try a full chip erase before flashing ?: https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/msg5838749/#msg5838749

Did that as per instructions with the same result,guess removing the caps 13+14 must kill correct programing?.

Removing the capacitors does not affect programming. I have been re-programming up to four modified Blue Pills, which I swap alternately into two GPSDO's, as new firmware comes out without any problems.

I do however keep the wire to the oscillator pad as short as I can.

Duncan

I program and then verify, just to be sure.

[ME]

I wondered if the longer osc wire can cause a slight delay and stop the fw from running?.I made the wire longer with a male+female dupont connector in it so i can change the bp without soldering.

[daddygo]

I wondered if the longer osc wire can cause a slight delay and stop the fw from running?.I made the wire longer with a male+female dupont connector in it so i can change the bp without soldering.

Hi @ME,

sorry, I was away for a few days...

-nope, - removing C13 and C14 does not affect programming
-yes, do NOT lengthen the OSC wire because it will introduce parasitic stuff into the system, it was not so short for nothing 

[daddygo]

Here is v0.1.9 : https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.9
Changes :
- Added date format setting in GPS menu (This on is for you @G4ELJ ;-))
- Added manual GPS model selection (press encoder un GPS/Model menu) in case automatic detection fails (this can happen if baudrate is not set properly)

Hi @fredo_

thanks for this too...
see, you still have something to add and you'll never close the cover of the box, hihihi 

[ME]

A couple of newby questions 1 is it ok to program the bp with it stil in the mainboard and 2 will the fw run when the bp is fitted and the stlink connected to the bp but not plugged into the pc usb, If that makes sense?.

[daddygo]

1. -YES, -I never take the BP out of the slot during programming, ergo I program it in the base board (what to look out for to avoid starting the GPSDO PSU!)
these are minimally configured BPs for the STM32F103... MCU and have no galvanic isolation or other protection to the PSU(s)

2. - again the answer is yes, to rule out my mistake, I always disconnect the ST-Link 3.3V connector so that if I'm stupid and switch on the main PSU there's no problem

the other 3 cables on the SWD header have no effect on the operation!
as you progress in your electronics knowledge, you will see that you will have paranoid things to protect your electronics and yourself

imagine doing this not with 3.3V DC and with a penny of value BP, but with a motor driver at 230 or 400V with a 1500 dollar electronics, so be paranoid and stay safe!!! 

[ME]

Wel i erased the bp the flashed with fredo v1.9fw also removed the dupont connector and shortened the osc wire, It now works, can someone explaine the gps passthru more and explaine what programs to use with it after using a usb 3.3volt usb converter?, thanks.

[daddygo]

- these GPS modules (defa. in this GPSDO u-blox NEO-6M & ATGM336H) are configurable and you can read data directly from them... f.e. with: u-blox u-center SW:
https://www.u-blox.com/en/product/u-center

these are unicum things, so they do not affect the original purpose of the GPSDO

use a USB to serial converter to access the GPS module directly - this is not necessary in principle, because the MCU will acquire the necessary data itself
there is a pass-through from the GPS module directly to the BP PIN(s) RX/TX from the MCU with unmodified GPS data
(someone asked for this at the beginning of the thread and it was implemented)
- in fixed, never-changing GPS positions, you can configure the GPS module to work with fixed data or change the pulse width of the PPS signal, etc. etc. etc.

in most cases you don't need this 

I have built an impedance matcher/driver (50ohm), to which I added a USB to serial converter, so that it can communicate directly with the GPS module

if you don't use this like me, you can get this GPS RX/TX data on BP PINs to send/receive to your own external USB to serial converter


+++edit:
rather, --- the big lesson now was that at 10MHz (specifically for oscillators) you can't use wires of the length you had in mind 

[ME]

does the ublox u center sw work with ATGM336H gps moduals then?.

[G4ELJ]

does the ublox u center sw work with ATGM336H gps moduals then?.

Yes. But you will need a TTL to USB serial converter (3.3V) for any PC etc.

The other one that works is GnssToolkit3

https://github.com/zxcwhale/GnssToolKit3-binaries/releases

Duncan

[daddygo]

does the ublox u center sw work with ATGM336H gps moduals then?.

-nope u-center only works with u-blox modules...

these Chinese "wonder" GPS modules (only 32 ch.), (note though that this is a good module) - require a different SW, as you can see in the attached picture
"GNSSToolKit"

not bad, but I'll stick with u-blox

[G4ELJ]

does the ublox u center sw work with ATGM336H gps moduals then?.

-nope u-center only works with u-blox modules...

Hmm, U-center works for me with the Chinese ATGM336H GPS module.

Duncan

[daddygo]

does the ublox u center sw work with ATGM336H gps moduals then?.

-nope u-center only works with u-blox modules...

Hmm, U-center works for me with the Chinese ATGM336H GPS module.

Hmm,  this is an old 8.28 u-center (I'm surprised you were able to get it), try the current one(24)..... 

u-blox no longer supplies modules to china due to trade restrictions and because of the copying 


DG

[ME]

is the gnss toolkit3 have anyway to change its menu to english?,mine is in chinese!.

[ME]

On my unit on the menu that gives the time, it displays when first entering the menu but stays fixed ie if it reads 01.01:22 ten mins later it still reads that same time, Is that normal?.

[daddygo]

I have these Chinese GPS moduls on the shelf, but I don't really use them, nor the gnss toolkit3, but this git ver. may have an English menu:
https://github.com/zxcwhale/GnssToolKit3-binaries/releases

@ME "it reads 01.01:22 ten mins later it still reads that same"
I haven't tested the new FW yet, so I don't know your second question, I'll be back in the our lab in a few days... & check it

[ME]

Can an led be added to this to show gps lock?.

[daddygo]

the LED is unnecessary in my opinion, because there is more info on the display, plus in the GPS menu

what would you use the LED for (exactly)?

[ME]

having an led mounted on the front would be better to see if it has gps lock at a  glance rather than faff in menus, I think most of the time mines not in lock hence the frozen time readout.,just a bp in getting pulled low when in lock would be ideal just to sink current to drive an led,can this be done in the fw?.

[G4ELJ]

Hi,
I just released v0.1.8 : https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.8

- Added baudrate setting command for ATGM336H GPS module

Hi @fredo, I don't think that is working. Only tested with v1.9.

If I change the baud rate to say 19200 I lose the ATGM336H GPS connection. Clock stops.

Changing back to 9600 and all is fine.

Whilst at 9600baud if I use GnssToolkit and send the appropriate code to the GPS module for 19200 baud then change the GPSDO also to 19200 baud, everything is connected and working at 19200 baud.

Very repeatable up to 112500 baud providing one changes the GPS module baud rate first! 

This is what GnssToolkit says it is sending to the ATGM336H GPS module

115200 = $PCAS01,5*19
57600 = $PCAS01,4*18
38400 = $PCAS01,3*1F
19200 = $PCAS01,2*1E
9600 = $PCAS01,1*1D

Duncan

PS @me if one loses GPS lock the date menu stops showing the date. If you are not bothered with time just leave it on that menu screen.

[fredo_]

If I change the baud rate to say 19200 I lose the ATGM336H GPS connection. Clock stops.

Did you check if the "Model" menu entry show "ATGM336H" before changing baud rate ?
The firmware will only send the commands if the model is detected to be ATGM336H, and I noticed that model detection can fail if you switch the device off and on to quickly (the GPS module has battery and will not send boot sequence with model number). If it failed, you can set it manually.
It worked OK for me, I was able to move from one speed to another without losing the connection.

@ME, on all screens you have an indicator of the GPS fix state, inferred from the PPS output of the GPS module, at the top left corner of the screen.
If a signal progress icon is shown, it means that the GPS has a fix. If it shows a blinking "!" or strikeout signal icon, it means that there is no fix.

[daddygo]

having an led mounted on the front would be better to see if it has gps lock at a  glance rather than faff in menus, I think most of the time mines not in lock hence the frozen time readout.,just a bp in getting pulled low when in lock would be ideal just to sink current to drive an led,can this be done in the fw?.

Hi @ME

-look in the github source code for the file gpsdo.ioc - lib/stm32
-open with CubeMX
-find a free GPIO_Out for this LED func.
-make a LED driver circuit if required for the type of LED you want to use
-ask @fredo_ to mod the FW for you or do it yourself if you know the code
-on the PIN of the BP (PA.. / PB../ PC.. /PD.. with GPIO) you get the signal for the LED, connect it to your circuit and wire it to the front plate


as the @fredo_ say, there's a lot of information on the display that's more intuitive than an LED but it's not impossible to have an LED

[ME]

If i knew howto mod the code to have it sink current for an led on a spare bp pin i would do it, i dont know, thats why i'm asking here ok.

[daddygo]

If i knew howto mod the code to have it sink current for an led on a spare bp pin i would do it, i dont know, thats why i'm asking here ok.

OK, well, if you really need it, send @fredo_ a message to ask him to help you with this request in question FW mod.

-as I look at the last .ioc the PA15 is empty and there is a meaningful place to exit on the BP PIN(38) as well...
unfortunately the loadable pins are not usable in this BP configuration (are in use) PC13 BP board LED (fredo PPS), PC14 & PC15 for OSC, so you need a small circuit in front of the LED
(otherwise there are only 3 open drains (only 3mA)

this can be many things, but use a single TI Schmitt-Trigger Buffer SN74LVC1G17 to give the right current to any type of LED (cca. 24mA enough for all)

In CubeMX, need to generate the STM32 HW configuration to the corresponding C code, then write a code (@fredo_) to raise (high) the PA15 in GPS lock state and the buffer will drive your LED

[fredo_]

If i knew howto mod the code to have it sink current for an led on a spare bp pin i would do it, i dont know, thats why i'm asking here ok.

That's not a very kind way to reply to @daddygo, that spent so much time helping you, with long an detailed answers, screenshots and step by step explanations.
You know that we're not paid four our contributions on this forum right ?
English is not our native language, unlike you. At least make the effort of writing kind and free of spelling mistakes phrases when you're asking for help.

[ME]

If i knew howto mod the code to have it sink current for an led on a spare bp pin i would do it, i dont know, thats why i'm asking here ok.

That's not a very kind way to reply to @daddygo, that spent so much time helping you, with long an detailed answers, screenshots and step by step explanations.
You know that we're not paid four our contributions on this forum right ?
English is not our native language, unlike you. At least make the effort of writing kind and free of spelling mistakes phrases when you're asking for help.

I fully understand what you are saying, I had a brain hemorage a few years ago so like to get to the point as i find typing difficult ok, Hence my shoer questins and answers, Please dont take things the wrong way, offending folks is not meant in any way.

[daddygo]

If i knew howto mod the code to have it sink current for an led on a spare bp pin i would do it, i dont know, thats why i'm asking here ok.

That's not a very kind way to reply to @daddygo, that spent so much time helping you, with long an detailed answers, screenshots and step by step explanations.
You know that we're not paid four our contributions on this forum right ?
English is not our native language, unlike you. At least make the effort of writing kind and free of spelling mistakes phrases when you're asking for help.

I fully understand what you are saying, I had a brain hemorage a few years ago so like to get to the point as i find typing difficult ok, Hence my shoer questins and answers, Please dont take things the wrong way, offending folks is not meant in any way.

I'm a very patient person after 5.X + few months, I don't take it as an offence 
but for the community, it's better to listen to each other and to get the emphasis right

I'm sorry you had to go through difficult things health is the most important!!!!

[ME]

Thank you all for your help and understanding, I still need a way to trigger an led tho when the gpsdo has  got lock.

[fredo_]

Thank you all for your help and understanding, I still need a way to trigger an led tho when the gpsdo has  got lock.

No worries, thank you four your explanations.
I'll take a look into driving a led to show gps lock state.

[ME]

Salut+merci bien fredo.

[daddygo]

Thank you all for your help and understanding, I still need a way to trigger an led tho when the gpsdo has  got lock.

Hi @ME

and I'll dev. you a ready-to-manufacture small PCB design with the necessary parts, which can be precisely matched to the interior space and the front panel dimensions
note, there is a very small space just above the rotarry for this purpose

would a 3mm LED be suitable for you?
you make the hole a bit narrower and the LED would hold the small PCB

[flash2b]

I have successfully installed firmware v0.1.9 from fredzo/fredo_ into my BH3SAP GPSDO 

First I did make a backup of the original firmware and compared this to a file shared within this topic. They were identical so that was a success. I used a WeActStudio STM32 Mini Debugger on the original BP. I was unable to read stable when the BP was still in the socket (sometimes lost connection to the target), so I pulled it out the socket carefully while I did the reprogramming. I noticed that when I tried the programming while the BP was still in the socket, the GPS module was also powered since the LED was lit.

Flashing the BP was easy and took 2 seconds to complete.

Here are some pictures:



The most satellites I got were 24 using the antenna stuck to the window of my loft.

Thank you Dankar, 2A03 and fredzo/fredo_ for all you effort and daddygo for the tips.

[ME]

Thank you all for your help and understanding, I still need a way to trigger an led tho when the gpsdo has  got lock.

Hi @ME

and I'll dev. you a ready-to-manufacture small PCB design with the necessary parts, which can be precisely matched to the interior space and the front panel dimensions
note, there is a very small space just above the rotarry for this purpose Thanks any size led is good.

would a 3mm LED be suitable for you?
you make the hole a bit narrower and the LED would hold the small PCB

[ME]

any size led is good,its the fw modding to indicate lock is needed more tho .73

[flash2b]

I noticed on my unit that the green led on the BP, so PC13, is never lit or blinking (PPS) using v0.1.9. For the rest everything is working properly.

Have others the same experience or is maybe my led is defective ?

Edit: Confirmed that the led on my BP is physically damaged (not by me )

[daddygo]

Thank you all for your help and understanding, I still need a way to trigger an led tho when the gpsdo has  got lock.

HI @ME,

something like this might be good for your Lock LED project, this is sized above the rottary switch, with a 3mm LED

[daddygo]

I have successfully installed firmware v0.1.9 from fredzo/fredo_ into my BH3SAP GPSDO 

First I did make a backup of the original firmware and compared this to a file shared within this topic. They were identical so that was a success. I used a WeActStudio STM32 Mini Debugger on the original BP. I was unable to read stable when the BP was still in the socket (sometimes lost connection to the target), so I pulled it out the socket carefully while I did the reprogramming. I noticed that when I tried the programming while the BP was still in the socket, the GPS module was also powered since the LED was lit.

Flashing the BP was easy and took 2 seconds to complete.

Here are some pictures:
(Attachment Link)
(Attachment Link)

The most satellites I got were 24 using the antenna stuck to the window of my loft.

Thank you Dankar, 2A03 and fredzo/fredo_ for all you effort and daddygo for the tips.

Hi @flash2b

the reason you couldn't program in the slot might be that the WeActStudio STM32 Mini Debugger couldn't drive 3.3V well,
if drop the voltage, normal to a certain extent, even at 2.6V the programming can be faulty...

ST-Link V2 which I use, so I don't have to remove the BP from the slot

[daddygo]

I noticed on my unit that the green led on the BP, so PC13, is never lit or blinking (PPS) using v0.1.9. For the rest everything is working properly.

Have others the same experience or is maybe my led is defective ?

just tested with the latest FW (v0.1.9) the PC13 LED is blinking, anyway, it's driven by the MCU PPS signal since @fredo_'s FW mod
this signal exists even if there is no GPS PPS signal, as it is generated by MCU and synchronized with the GPS PPS if there is incoming PPS from GPS

[flash2b]

Thanx for you photo. Seems my led is dead 

I am however not so much worried by that since everything else is working great, a super improvement compared to the original firmware.

Your comment on my WeActStudio STM32 Mini Debugger could be true, popping the BP out of the socket I did carefully since I knew about the wire at the bottom.

Edit:
Just confirmed with a magifying glass that the led is damaged no transparent case and does not have any bond wires so therefore no light. The red power led is working ok.

[HappySundays]

Hi @fredo_

I've loaded up 0.1.9 and love the time offset mode but... when I set 11 hours to get the time correct for my time zone (GMT +11), it has yesterday's date. We live in the future here in Australia. It's already the 17th but the date is shown as the 16th.
Should it not be +/-12 instead of 0 to 23? Both should take care of dates rolling over/under.

David

[ME]

Do these use an active antenna?, My time screen just has a sort of flashing wave/search icon followed by  TIME:   but no time displayed, does that mean no sat lock?.

[ME]

Can the original gps modual be replaced with one of these? https://www.ebay.co.uk/itm/356533964466?_skw=Neo-M8+module&itmmeta=01JPHHGVMMTYBCXE9HM8K3F0Z1&hash=item5303148eb2:g:rIwAAOSwKBRnogaF&itmprp=enc%3AAQAKAAAA0FkggFvd1GGDu0w3yXCmi1dI7B5KL24X5kdZraYGLZRwd1N7Mahc7kDXVNA0wHi1WQBFoOvCcRNY2iQ9UgBzuK%2FDOOWsLFzpd%2B21iDB%2BGicESk6gvG6IQZ2auGCNglymN5ZDA97q3YV39wxpWJnXSSZze7pDYMkfZ0l5AwAto0WtVk8ZPp8eMXKhwzNd299B%2Ba0M7NsHzKUboNieE%2BK%2BHGOpUtVwaP2sletzyD7ztPeumFmx0kNIE8PLoianhUHYlIMaHeBep4nt19KXF502kfw%3D%7Ctkp%3ABk9SR8C6w7G0ZQ
 Sorry but its the only way i see of showing the link.

[daddygo]

Do these use an active antenna?, My time screen just has a sort of flashing wave/search icon followed by  TIME:   but no time displayed, does that mean no sat lock?.

Yes these are active antennas, fed by the VCC_RF pin of the u-blox or ATGM (CH) module, depends on the type, but usually up to 50mA
pls. flip the magnetic antenna from the factory GPSDO package over and you will see that it can supply up to 3-5V DC from NEO or ATGM modules

after the icon you mentioned, you can see the number of SAT(s) you have reached, this will tell you if you have a connection to GPS modul / SAT
usually if you have no time display you have no GPS lock

[daddygo]

Can the original gps modual be replaced with one of these? https://www.ebay.co.uk/itm/356533964466?_skw=Neo-M8+module&itmmeta=01JPHHGVMMTYBCXE9HM8K3F0Z1&hash=item5303148eb2:g:rIwAAOSwKBRnogaF&itmprp=enc%3AAQAKAAAA0FkggFvd1GGDu0w3yXCmi1dI7B5KL24X5kdZraYGLZRwd1N7Mahc7kDXVNA0wHi1WQBFoOvCcRNY2iQ9UgBzuK%2FDOOWsLFzpd%2B21iDB%2BGicESk6gvG6IQZ2auGCNglymN5ZDA97q3YV39wxpWJnXSSZze7pDYMkfZ0l5AwAto0WtVk8ZPp8eMXKhwzNd299B%2Ba0M7NsHzKUboNieE%2BK%2BHGOpUtVwaP2sletzyD7ztPeumFmx0kNIE8PLoianhUHYlIMaHeBep4nt19KXF502kfw%3D%7Ctkp%3ABk9SR8C6w7G0ZQ
 Sorry but its the only way i see of showing the link.

you can't use this module because there is no PPS output to PIN header

two more things:

1.this is a "fake" relabeled NEO-M6 module PCB anyway, I've been dealing with a lot of u-blox stuff these days and immediately know that the NEO 8 series has built in EEPROM in the modules, this fake NEO 8 PCB has an eeprom which is unnecessary, the label underneath it is definitely a NEO6
(in addition, the NEO-M8L module in the picture is more for automotive use, DEAD RECKONING module + the 3D sensor in GPSDO is pointless)

2. it's pointless to choose a newer NEO series for this GPSDO, because they are not really better or more stable for this purpose
there are u-blox moduls / chips that are specifically designed for timing that can be a step forward, but the price starts at $250
https://www.u-blox.com/en/time

I made a PCB with NEO-M9N module (in production now) for this GPSDO unit, because we use GPSDO in the transmitter environment and there was a lot of interference with mobile operators' systems
the NEO-M9 series has a built-in LTE notch filter and this is an advantage for us, and we use special "mushroom" GPS antennas with 25-40m coax cable so I also designed an external LNA drive with 5V PSU

Oh and yes I almost forgot another big advantage of the NEO-M9 is that it runs on TCXO and is more stable.

SUM: for simple purposes, it is not worth installing a GPS module more serious than the original NEO-M6 or ATGM336H

[fredo_]

I just released v0.1.10: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.10
Changes :
- [@HappySundays] Changed time offset management to fix date display (offset now ranges from -14 to +14 hours and date is calculated accordingly)
- [@ME] Added two additional GPIO outputs :
  - PA0 can be used to drive a led to display GPS lock status (active when low)
  - PA1 can be used to drive a led to display GPSDO lock status (based on the PPM threshold setting in PPM menu, active when low)
- GPSDO lock status is also shown in the main screen with a padlock icon

If someone has the time to check the date calculation logic for possible bugs: https://github.com/fredzo/gpsdo-fw/blob/d2f90bad53e456235a9e02e673a8f621ccd348b7/src/gps.c#L360

[flash2b]

I flashed it. The time was set to -13 at first (was +1 with 0.1.9) but I could adjust it to my timezone again.

GPSDO is running again... thank you fredo_ !

[daddygo]

I just released v0.1.10: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.10
Changes :
- [@HappySundays] Changed time offset management to fix date display (offset now ranges from -14 to +14 hours and date is calculated accordingly)
- [@ME] Added two additional GPIO outputs :
  - PA0 can be used to drive a led to display GPS lock status (active when low)
  - PA1 can be used to drive a led to display GPSDO lock status (based on the PPM threshold setting in PPM menu, active when low)
- GPSDO lock status is also shown in the main screen with a padlock icon

If someone has the time to check the date calculation logic for possible bugs: https://github.com/fredzo/gpsdo-fw/blob/d2f90bad53e456235a9e02e673a8f621ccd348b7/src/gps.c#L360

Hi fredo_

thanks again 

now that you've "pushed out" these two GPIOs, you're encouraging me again not to stop and even though one half of me is resisting, so I decided to put the two LEDs on the front panel 
I'll check the two LEDs and the new FW version in the evening

hmmm, it never ends, just when you think you have nothing more to add it turns out you do

PS:
you write that the GPIOs are active at "low" level, so need an inverted buffer

[flash2b]

I like the little padlock overlayed icon. It was shown before PPB was 0.00 and the save message was shown, is that OK ?

The PPB was 0.22 at that time. I also noticed that PPB goes from 0.78 -> 0.66 -> 0.55 -> 0.44 ->0.33 ->0.22 -> 0.11 -> 0.00 so always those numbers, is that related to the precision of the calculation ?

[fredo_]

now that you've "pushed out" these two GPIOs, you're encouraging me again not to stop and even though one half of me is resisting, so I decided to put the two LEDs on the front panel 

Well send us a picture if you do so, I'll add it to the documentation!

you write that the GPIOs are active at "low" level, so need an inverted buffer

I figured we would drive the led directly from the GPIO like it's done with LED1 on the bluepill board.

[fredo_]

I like the little padlock overlayed icon. It was shown before PPB was 0.00 and the save message was shown, is that OK ?

Yes, the lock threshold is configurable in the PPB sub-menu ("PPB Lk" entry), default is 0.50.

The PPB was 0.22 at that time. I also noticed that PPB goes from 0.78 -> 0.66 -> 0.55 -> 0.44 ->0.33 ->0.22 -> 0.11 -> 0.00 so always those numbers, is that related to the precision o the calculation ?

Yes that's because this value is a 128 second running average.
The bluepill board is running at 70Mhz and we count the number of clock cycles over a 1 second period, so the smallest PPB value we can measure is 1000/70 = 14.28 (you can check the instant PPB value in the PPB sub-menu).
We get more precision by averaging this instant values over time.

[daddygo]

If someone has the time to check the date calculation logic for possible bugs: https://github.com/fredzo/gpsdo-fw/blob/d2f90bad53e456235a9e02e673a8f621ccd348b7/src/gps.c#L360

@fredo_

I don't believe in Ai yet, it's too early for this planet, but I pushed your "date calculation logic" request to ChatGPT, it came out as I'm not a SW guy at this level, maybe full of crap...

the GPT screen responses are in a .docx and the resulting code is in *.txt(s) in the whole in ZIP

ChatGPT:
Would you like me to add alarm-based auto-increment (e.g., auto-increment at midnight)? 🚀

here I have gone no further

might be good for a bit of exploration, but I say there might not be a point to it  - it's a machine, even may contain code ideas

[ME]

Does the led on pb13 illuminate when gps has lock or unlock?.

[fredo_]

I hate AIs because they give you a bunch of wrong answers around correct ones, and you spend more time checking which answer is correct than figuring it out by yourself...
ChatGPT didn't disappoint me on this one 
5 remarks, 4 wrong or irrelevant in the context BUT one was correct! I mistakenly added September in the list of 31 day months...
I'll fix it in the next release, thx @daddygo!

[daddygo]

now that you've "pushed out" these two GPIOs, you're encouraging me again not to stop and even though one half of me is resisting, so I decided to put the two LEDs on the front panel 

Well send us a picture if you do so, I'll add it to the documentation!

you write that the GPIOs are active at "low" level, so need an inverted buffer

I figured we would drive the led directly from the GPIO like it's done with LED1 on the bluepill board.

Yeah, - this can also be a good solution (like LED1 on BP) and the simplest, but limits the type of LEDs that can be used
I haven't even looked at how much the peripherals so far load the BP with something like 20mA / recom. I see 8mA as PIN

for example, most LEDs, and my favourite Lite-On blue LEDs have a voltage drop of 3 - 3.5V, which schema. is limited by the 3.3V PSU
so as I would put the LEDs on a mini PCB anyway for correct mounting, it doesn't take long to add a small circuit and power the LEDs from a 5V PSU base board + SN74LVC2G06

to avoid the need to fix the mini PCB, two 3mm LEDs would hold it in place

[daddygo]

I hate AIs because they give you a bunch of wrong answers around correct ones, and you spend more time checking which answer is correct than figuring it out by yourself...
ChatGPT didn't disappoint me on this one 
5 remarks, 4 wrong or irrelevant in the context BUT one was correct! I mistakenly added September in the list of 31 day months...
I'll fix it in the next release, thx @daddygo!

I absolutely agree with you, it's too early for humanity,  but, you know, there's money to be made from everything in this current mess,
kids can't even learn to read / count but they have the AI controled gadgets in their hands 

at least we caught the end of September, hihihih

[fredo_]

Does the led on pb13 illuminate when gps has lock or unlock?.

The led for GPS lock is on PA0 (see here: https://github.com/fredzo/gpsdo-fw?tab=readme-ov-file#gps-lock-and-gpsdo-lock-outputs).
PA0 is pulled low when the GPS is locked so that you can drive a LED with it like this:

[2A03]

Hi, fredo_

Thank you for merging my source code.
The date display is also good. It would be even more perfect if it had the ISO 8601 format (YYYY/MM/DD).

It seems that the code to save the ATGM336H baud rate setting to the EEPROM of the ATGM336H was deleted when it was merged.
It would be helpful if you could modify it so that the command to save to the EEPROM is sent after the baud rate change command for the ATGM336H model.

I checked the time it takes for the settings to be lost with another ATGM336H. The baud rate setting was only retained for about 30 minutes.
Therefore, if you shut down for a certain period of time, there should be a discrepancy between the baud rate of the BluePill and the ATGM336H.

I also think it would be better to save to the BluePill when the GPS model is detected. Currently, it is only saved when some setting change is written to the BluePill.

[ME]

Did this topic get moved ? , can only get this page via a saved link!.

[fredo_]

Hello there,
v0.1.11 has been released: https://github.com/fredzo/gpsdo-fw/releases/tag/v0.1.11
Changes are:
- Added ISO date format (yy/mm/dd) [@2A03]
- Added config save command for ATGM336H GPS module after baud rate change [@2A03]
- Added GPS module model save after auto-detection [@2A03]
- Fixed day calculation (for month = September)

[2A03]

Hi, fredo_

I tried v0.1.11 and it seems fine.
Thank you so much.

[daddygo]

Two LED versions PCB with inv-buffer and sized above the rotarry...