Yet another DIY GPSDO - yes, another one

[daddioo]

Thanks for your answers, I connected a 15V 3A power supply, I made a small circuit with two transistors and two LEDs, one red that indicates heating and one green that indicates the RB is in Lock, I used Pin 3 Bit Lock, I put it in ON, the red LED immediately turned on, after about 5 minutes the green LED turned on, I connected an oscilloscope and I got 10Mhz and 2.5V peak to peak.
I tried to connect it to the GPSDO Project, connected in this way 10Mhz output to the 100 ohm resistor and Pin 8 (Freq. Adj) to the pwm dac unfortunately it does not work it always remains in Calibration, I was curious to see the Rubidium controlled by the GPSDO, if I connect the ocxo it works as you saw in the previous photo, then I tried to connect it to BG7TBL it works very well in 35/50 minutes it went into Lock, I do not understand in the AndrewBCN project it does not work.

[Johnny B Good]

Assuming the freq adj pin option is enabled, The tuning rate is likely to be in the region of 167 volts/Hz!

[EDIT]
 I'd missed the reference to the BG7TBL. If that's the rubidium version then you've proved that the freq adj pin is at least functioning and your problem is the totally mismatched tuning rates between the gpsdo project and the AR60A. Given enough time, the gpsdo may eventually finish re-calibrating itself to the rubidium oscillator's requirements.

 The total tuning range for each of the internal trimpot and the external C field connection (electrical frequency adjust) for the LPRO 101 is given as +/- 1.5 E -9 which for the 0 to 5 volt tuning range covers a +/- 15mHz tuning range (in volts per Hz tuning rate, this equates to ~167 volts per Hz). IOW, the tuning requirement of the AR60A is a gross mismatch to what the gpsdo is expecting.

 First thing you need to do is compare its output against another reference such as a gpsdo using an oscilloscope so you can test whether it can be adjusted using the external frequency adjust pin connection (and the internal trimpot if it has one - the manual implies it doesn't when the external frequency adjust option is installed/enabled (it's probably there regardless of what that poorly written manual implies though).

 The priority for you is to ascertain whether it's even possible to adjust the frequency electrically through that freq adj connection. If not, then it's game over as far as you're concerned unless you can find a way to modify it to re-enable this "option".

[daddioo]

Thanks for the reply, I will do more tests if I get a good result I will let you know.

[TomD]

Hello Vindoline,
thank you for your great PCB setup. I ordered some PCBs and install the HW. I use the FW 0.06c but I have a issue. As long as I didn't 'activate' the BMP280/AHT20 the device run well, but when the BMP/AMP20 is 'defined' I got just the header line on the OLED. Can you please advice how you get the OLED and the BMP280/AHT20 (the small sensor on a mini PCB) running at the same time? Did you redefine the connection for the sensor /or use I2C and SPI?

Please support. Many Thannks in advance.

Again thank you for the great set-up/PCB.

[daddioo]

Hello everyone, today a strange thing happened to the GPSDO v0.06c, everything was working ok, suddenly the display screen became all white, but I noticed that the gpsdo continues to work I checked with the Terminal with the mobile phone, I ask if it is possible to add a button in the code for a display reflash without resetting everything every time, the display used is ILI9341.
Thanks, Giuseppe

[vindoline]

Hello Vindoline,
thank you for your great PCB setup. I ordered some PCBs and install the HW. I use the FW 0.06c but I have a issue. As long as I didn't 'activate' the BMP280/AHT20 the device run well, but when the BMP/AMP20 is 'defined' I got just the header line on the OLED. Can you please advice how you get the OLED and the BMP280/AHT20 (the small sensor on a mini PCB) running at the same time? Did you redefine the connection for the sensor /or use I2C and SPI?

Please support. Many Thannks in advance.

Again thank you for the great set-up/PCB.

Hi Tom, I'm sorry it took so long to respond - I'm just seeing this message today.
First off, I'm just a keen hobbyist, not an engineer. And I am DEFINITELY not a software guy.
I looked at the code, and my BMP280 is defined as I2C. I don't remember having any difficulty with the BMP280, but I probably had to go into the software and un-comment some code blocks to activate it.
I do remember that it took me a really long time to figure out how to talk to the unit with the Arduino software that I use. I think it was several days of playing around to get it to work.
If you are having trouble, I would suspect that it is an I2C address conflict or that the BMP280 board is bad.
If you're still having trouble, I would recommend reaching out to Andrew - he has been really helpful and knows his software inside out!

[TomD]

Thank you Vindoline, I will try to fix the possible I2C address problem. Thank you again

[Sergii]

Hello, everyone!
Thank you for the excellent project. Based on the comments in the BUG LIST from uflex, I fixed most of the bugs directly in the gerbers:
FIXED: 1. Increase the footprint of C32 (MLCC) from 0603 to 0805. 
FIXED: 2. Footprint C39 (MLCC) 0603 should be increased to 0805 for KEMET C0805C102J5GACTU. 
FIXED: 4. **CRITICAL BUG:** Unintended connection between the wiper of P1 (Balance) and the non-inverting input of U2. 
FIXED: 5. The ‘GAIN’ and ‘BALANCE’ labels on the PCB are swapped. 
FIXED: 7. The nRST line capacitor to GND is missing in the layout but not used anyway because of the following: The MCU reset needs to occur relatively slowly to allow enough time for the OCXO to stabilize. To address this, resistor R58 (47k/0603) has been added from nRST to Vcc, and MLCC C51 (10uF/0805) from nRST to GND. The resistor ensures the capacitor discharges quickly enough for immediate restart after power-off. A reverse diode across R58 and a smaller capacitor for C51 could also be considered as alternatives. 
FIXED: 8. The uP-clock from the 74ACT04 is 5Vtt. Although STM32 OSC_IN is 5V tolerant, a voltage divider of 1k8 - 3k3 has been added to prevent clipping against the internal diodes in the STM32 and avoid distortion/ringing, bringing the max voltage to around 3.2V. In the current layout, the 1k8 resistor (R60) replaces C36. The 3k3 resistor (R61) has been improvised and placed to the ground of a nearby MLCC. 
FIXED: 11. Additional decoupling MLCC's at 3V3 around the STM32 chip.

The result is pcb version 1.1, which is now fully ready to order from JLC. (what I have already done)

[Shadback]

Hi, so recently I decided to build my own GPSDO project since I'm very interested in building one now my idea was to use lars design with the 4046 but for someone without a lot of background there is a lot I don't know.
in my project I'm using:
STM32H723ZGT6
GPS ZED-F9T Module
AOCJY-10.000MHZ-F-T VCOCXO
and the lars GPSDO PLL using HC390 and 74HC4046
questions:
1. my gps module has a 3.3V PPS output as well as my OCXO I am using the 4046 with a 3.3 vcc i know it is possible but im worried because the RC value would change and unlike lars i cant use lower voltage reference with my STM...
2. I have tried to read lars files and code but it is still not enough is there a good explanation of his PID somewhere?
3.in lars project he used his Arduino to count 5MHz now in my STM i want to count the original 10MHz but I don't understand it well enough can it count without interrupts as an external clock?

Hope you can help...

[lucido]

Hi everyone.

After a bit of work, I managed to get it working.
Thanks, AndrewBCN
Thanks daddioo

Happy gpsdo.

lucido

[lucido]

Good morning everyone.
A small update! I replaced the Ublox M8N GPS receiver with a Ublox Lea-6T. I'm waiting for the Ublox M8T to arrive. I want to see how it works with GPSDO. I added the Bluetooth module. With Android, it works without problems with the Serial Bluetooth app. With Windows 11, it gives me problems, but I think it's a driver issue. Regarding stability, it's excellent, even though I don't have the right tools to measure it. The accuracy isn't bad, as you can see from the frequency counter. As for the oscillator, I'm using a Toyocom TCO-627VC. It works properly, you can find it on eBay. I'd say the whole system is working fine!
Let's keep this interesting post alive.
Greetings everyone.
Happy GPSDO.
lucido

[jmnlabs]

Hi everybody,
Just a quick progress report. So after examining the code for the gpsWaitFix() subroutine and the main loop, I have decided to completely rewrite both, and that actually means rewriting two of the most important functions in the STM32 GPSDO firmware.
And I realized that I had a very serious problem, because I am trying to read and parse the messages from the u-blox GPS module while juggling all the other tasks that are required by the GPSDO, such as displaying the status on various displays, reading the sensors, and transmitting a status report over USB serial every second.
I revisited the FreeRTOS webpage and noticed there is now an STM32duino version of FreeRTOS, meaning it is possible to use the FreeRTOS constructs in an Arduino sketch for the STM32 series of MCUs.
FreeRTOS implements tasks, a scheduler, semaphores, etc and enables the programming of multiple threads on an MCU.

Short story long, the STM32 GPSDO firmware is going multi-threaded and I will be having a lot of fun while rewriting a good part of the STM32 GPSDO firmware using FreeRTOS. So that's what's in the pipeline for firmware version 0.07a. I expect this to take at least a couple of months if not longer, and if anyone wants to join in the fun, please do!

The first step is to reorganize the main loop() and gpsWaitFix() functions into various tasks and schedule these tasks correctly, and also determine how these tasks are triggered, etc.

A final note: I have switched from the "old" Arduino IDE 1.8.13 to the "new" Arduino IDE 2.2.1 as my main development tool for the STM32 GPSDO firmware and it is working 100% fine. Also I am using an ST-LINK V2 clone to flash the STM32F411CEU6 Black Pill, as I found it more reliable (but unfortunately slightly less practical) than the DFU method.

Hello everyone.
My name is Jarosław, I live in Poland, I'm 60 years old, and this is my first post on this forum. I've been following this thread for a while now, and I even made prototypes based on the PCBs shared by Scrachi – thank you very much. I think AndrewBCN did a really good job. In one of his posts, which I'm quoting, he mentioned his plans to port the software to FreeRTOS. This seemed like a good idea to me, and I decided to try it out. I won't deny that I'm not the best programmer – I spent a few years writing software for the 8051 and AVR families in C, and I haven't worked on it for a long time. However, with the help of AI and a bit of determination, I managed to create working and, hopefully, slightly improved code. I've added a few new features that seemed useful, and there are new algorithms.
I invite anyone interested to check out the code on my GitHub: https://github.com/jmnlabs/GPSDO_FreeRTOS.

Best regards, Jarosław


P.S. I added a few photos

[lucido]

Hi Jarosław.

Congratulations on the excellent work you've done. Fantastic. I tried version 0.29 and everything's fine. Now I'm trying version 0.47 with the LCD display. Everything's fine, since version 0.47 supports the 9341 display. I'm trying to set it up but I haven't succeeded yet.
I'm 65 and I'm having a bit of trouble understanding.
Congratulations again on the excellent work.
Let's keep this post active.
Thank you very much.
lucido

[jmnlabs]

Hi lucido.

Thank you for your kind words. I'm glad the firmware is working for you. You're the first person to confirm that my software works. Please describe exactly what problem you're having with the ILI9341 driver—is it a hardware issue or a problem with the compilation settings?
I’d be happy to help you with that. If you have any questions, feel free to ask.
Best regards,
Jarosław

[lucido]

Hi Jarosław.

Thanks for your very quick reply. I think the problem stems from the settings in the Arduino library file TFT_eSPI.h. I'm not sure what to set, and the display always stays white. The LCD display works properly. If you had the file already configured to post, it would be helpful. The default connections between BlackPill and the ili 9341 TFT are:
SCK → PA5 (SPI1 SCLK)
SDI → PA7 (SPI1 MOSI)
RES → PB15
D/C → PB12
CS → PB13
But I'm not sure what the problem is, I'm working on it.

Thank you so much for your great work.

lucido

[jmnlabs]

Hi lucido.
You need to configure the TFT_eSPI library via User_Setup.h in the library's folder.
Rename the original file to something like User_setup.h.bak and copy the file I've attached there—it should work.
The original file from the library is heavily commented and includes usage examples.
The process for configuring the TFT_eSPI library is described in detail in readme.md
Best regards,
Jarosław

P.S. If you give me your hardware configuration—what you're using (Bluetooth, sensors, type of GPS module)—I can compile and send you the finished .hex file.

[lucido]

Hi Jarosław.

Thanks for your reply. I use the Lea M8-T-10 GPS module. I'm not using any other sensors at the moment. I've configured the LTIC Picdiv and the Ili 9341 module. If you could send me the .hex file, that would be fine.

Thanks a lot.

lucido

[lucido]

Hi Jarosław.

A clarification: removing the comments from line 103 #define GPSDO_TFT_ILI9341 from the GPSDO_FreeRTOS.ino file. With the configuration file you sent me, the ILI 9341 display now works. If you can, please send me the .hex file.

Thank you very much.

lucido

[jmnlabs]

Hi, lucido.
I’m sending you two files—one with LTIC support enabled and one without. Both files have support enabled for all I2C sensors and the LED display for the HT16K33 clock (also I2C). If these peripherals aren’t detected, the program won’t use them. But if you want to expand the hardware, the support is already built into the code. The LEA-M8T module is a timing module, so I enabled SURVEY-IN support—after a longer observation period (depending on the antenna; an external one is best), it should switch to TIME mode, which will be indicated as HDOP:TIME. Of course, the ILI9341 320x240 display is also configured. The connections you provided earlier are correct. I’m also attaching gpsdo_config.h.
Best regards,
Jarosław

[lucido]

Hi Jarosław.

I received your files. You're a wonderful person, as well as talented. I'll work on them and let you know.

Thank you so much.

lucido

[jmnlabs]

Hi lucido,
I'm glad you were able to get this display up and running. Version 0.47 features significantly improved algorithms compared to version 0.29, as well as new options—enjoy testing it out. Everything is in the readme.md and changelog.md files. By the way, what do you think of the startup screen?
Best regards,
Jarosław

[lucido]

Hi Jarosław.

The startup screen is a summary of a frequency reference.

Thank you very much.

lucido

[lucido]

Hi Jarosław.

I'm testing the firmware, and everything's fine so far.
As for the splash screen, the first time I saw it, I was thrilled and thought it was art put into electronics.
There's a problem: I'm 65 years old, and besides not understanding the instructions in the files, my eyesight is getting worse, even with glasses. I noticed that the Arduino libraries for STM32 also include those for the 3.5-inch ILI 9488 display  SPI with a resolution of 480x320. This is the most readily available model on eBay, priced around €20, and is about twice the size of an ILI 9341. If you can support it in the next version, that would be great.

I'll add a photo.

Thank you so much for your patience.
lucido

[jmnlabs]

Hi lucido,
I suspect that English isn't your native language—it isn't mine either, for that matter. I've also been thinking about adding support for larger displays, but the thing is, I don't have one available for testing right now. But I'll try to add support for screens with a resolution of 320x480. Please note that this is an untested version and there may be issues with adjusting the elements for display. The supported displays have been tested on actual hardware. I'm attaching the Spanish README_ES.md—maybe it will be helpful to you. Also, from what I can see in the photo, the GPS is operating in TIME mode, which is great, but the frequency hasn't stabilized after 3 hours of operation. You should perform calibration using the CT command and, once it’s complete, save the settings to EEPROM using the ES command. You should also use the PLL algorithms (4, 5, or 7)—the original algorithm 0 by Andre is a relatively simple step-by-step algorithm; the algorithms I’ve added work better. Take a look at the photo: the 7-hit algorithm and frequency are shown in green. I’m using the LEA-M8T module, but since I’m running the tests at home with an indoor antenna, it doesn’t enter TIME mode. With an outdoor antenna, TIME mode works without any issues. Interestingly, the older-generation LEA-6T module enters TIME mode at home using the same antenna. The OCXO I'm currently testing is the Vectron c4550a1-0213 without any additional thermal insulation. I saw the photos in your previous posts, and you have a good OCXO, so I'm a little surprised by the frequency reading; I think calibration will help. As well as the readme in Spanish.

Best regards,
Jarosław

Hola, Lucido,

Sospecho que el inglés no es tu idioma nativo — ni el mío tampoco, por cierto. También he estado pensando en añadir soporte para pantallas más grandes, pero el problema es que ahora mismo no tengo ninguna disponible para probar. Sin embargo, intentaré añadir soporte para pantallas con una resolución de 320x480. Ten en cuenta que esta es una versión no probada y puede haber problemas con el ajuste de los elementos en la pantalla. Las pantallas compatibles han sido probadas en hardware real. Adjunto el README_ES.md en español — quizás te sea de ayuda.
Además, por lo que puedo ver en la foto, el GPS está operando en modo TIME, lo cual es genial, pero la frecuencia no se ha estabilizado después de 3 horas de funcionamiento. Deberías realizar la calibración usando el comando `CT` y, una vez completada, guardar los ajustes en la EEPROM usando el comando `ES`. También deberías usar los algoritmos PLL (4, 5 o 7) — el algoritmo 0 original de André es un algoritmo de pasos relativamente simple; los algoritmos que he añadido funcionan mejor. Echa un vistazo a la foto: el algoritmo 7 en estado "hit" y la frecuencia se muestran en verde.
Estoy usando el módulo LEA-M8T, pero como estoy realizando las pruebas en casa con una antena de interior, no entra en modo TIME. Con una antena de exterior, el modo TIME funciona sin ningún problema. Curiosamente, el módulo LEA-6T de la generación anterior entra en modo TIME en casa usando la misma antena. El OCXO que estoy probando ahora es un Vectron C4550 A1 0213 sin ningún aislamiento térmico adicional. He visto fotos de tus publicaciones anteriores y tienes un buen OCXO, así que me sorprende un poco la indicación de frecuencia; creo que la calibración ayudará.

Saludos cordiales,
Jarosław

[jmnlabs]

Hello, everyone.

At the request of user lucido, I am posting a version of the program with added support for larger 3.5“ and 4.0” 480x320 ILI9488 TFT displays. Please note that this version has not been tested on actual hardware. The interface scaling may contain errors. Despite the code being well-optimized and only refreshed elements being updated, some refresh delays may be noticeable due to the higher resolution and support for 18-bit color. I invite everyone with access to this TFT to test it. I’d also like to point out the 320x240 displays available in a maximum size of 3.2". Of course, they use the SPI interface.
I’m also including User_Setup.h for the TFT_eSPI library. The package contains readme files in English, Polish, and Spanish. For now, I won’t be posting this code on GitHub; I’m waiting for feedback from the tests and the display.

Best regards,
Jarosław

Hola a todos.

A petición del usuario lucido, publico una versión del programa en la que se ha añadido compatibilidad con pantallas TFT ILI9488 de mayor tamaño (3,5« y 4,0») con resolución 480x320. Tened en cuenta que se trata de una versión que no se ha probado en hardware real. El escalado de la interfaz puede presentar errores. A pesar de que el código está bien optimizado y solo se actualizan los elementos que han cambiado, debido a la mayor resolución y al soporte de color de 18 bits, pueden observarse ciertos retrasos en la actualización. Invito a todos los que tengan acceso a esta pantalla TFT a que la prueben. También quiero destacar las pantallas de 320x240 disponibles en un tamaño máximo de 3,2". Por supuesto, con interfaz SPI.
Adjunto también el archivo User_Setup.h para la biblioteca TFT_eSPI. El paquete incluye archivos Léeme en inglés, polaco y español. Por el momento no voy a publicar este código en GitHub; estoy a la espera de comentarios sobre las pruebas y de recibir la pantalla.

Un cordial saludo,
Jarosław