As everyone knows, amateur radio operators must log each QSO (communication session) due to the nature of their activity. However, since radio waves travel at the speed of light and can transmit information globally in a matter of seconds, it's essential to use a standardized time reference. Different regions around the world use different times, so to ensure consistency, amateur radio operators typically use Coordinated Universal Time (UTC).
The time difference between UTC and Beijing time is 8 hours, making calculations relatively straightforward. However, it can be difficult to quickly estimate the time in UTC each time, so I thought about creating a clock to easily check UTC time. Also, knowing the QTH (location) is important, and people often exchange QTH information during QSOs (communications). With the popularity of digital modes like FT8, the MDG (Madden-Hildebrand Grid) coordinates are widely used. However, obtaining MDG coordinates can be inconvenient, so I also wanted to create a small device that could quickly display the current grid coordinate. But due to other commitments at school, this plan was temporarily put on hold.
Later, when I saw my friend BG5ABL using a GNSS module, it reminded me of the project, and I started working on it. The first step was selecting key components: for the GNSS module, I chose the Air530Z from Huatuo, because this module is easy to use and has native support for active GPS antennas, which provides good performance.Additionally, the information is presented entirely in Chinese, making it easy to read and understand.。

Secondly, the MCU is important to me because it simplifies development and having ample resources is a key factor. Therefore, I decided to choose the STM32 series. While the prices of other STM32 models had been high recently, the STM32G0 offered a more affordable option, with prices consistently below 5 yuan. After estimating the required resources, I ultimately chose the STM32G030F6P6 MCU.

The overall design is finalized, so I've started working on the PCB layout. So far, I've created three versions of the PCB. The reason for each iteration was that I discovered some minor issues that had previously been overlooked, which were causing problems. However, all three versions are functional.

I used EasyEDA to design the PCB. While it may not be as powerful as some of the established commercial EDA software, it is quite user-friendly for someone like me who is designing small toys.
Regarding the software, thanks to the previous experience with GNSS modules, I was able to quickly develop a basic, functional program without much effort.

Initially, I had planned to use the RT-Thread real-time operating system. However, after further consideration, I felt it wasn't necessary, so I opted for a bare-metal programming approach. It turned out that without additional storage, the screen's character library consumes a significant amount of Flash space. With the current version and O1 optimization, the program size has reached 31.54KB, which is just one step away from filling my 32KB ROM MCU. The MCU has two serial ports: one for communication with the module and another for communication with the host computer. The data flow between the module and the host is continuous, so I used DMA to receive data on the serial port to reduce the load on the CPU while also preventing data loss.

Now that the program is ready, we can proceed with preparing the PCB for assembly and soldering.

Using a barbecue grill for the entire meal is definitely the most comfortable option.After completing the welding and programming, we achieved the desired results.

When using the Air530Z module with an active antenna and a backup power supply, hot start positioning is very fast. It can be considered almost instantaneous. However, cold start positioning takes slightly longer after exceeding the validity period of the historical data stored within the module.
Currently, I have divided the program into several interfaces. When you first turn it on, you will see a welcome screen.

Upon starting up, the system will automatically display the detailed information interface.

In this interface, the system will display the current time, speed, latitude and longitude, as well as the Meedenheide grid. The top status bar indicates the current location, system temperature (measured by an internal MCU temperature sensor using factory-calibrated values), and battery remaining power level (estimated voltage, not using a coulomb meter, so it is not precise; it can only be used for reference).
The right-hand button on the top allows you to navigate between pages. The second page displays a timeline of dates and times. The left-hand button allows you to switch between UTC time and CST (Beijing Time).


The next page displays speed data, with three sets of values: km/h, m/s, and knots. Currently, there is no conversion to imperial units, so the left-side button currently has no function. At this time, I am inside the house, and it's possible that weak signal strength is causing inaccuracies in the location data, which are then reflected as speed readings.

The next page displays system information, including the current system temperature (which matches the one shown in the status bar), the current system operating voltage, the current battery voltage, and the firmware version (I have updated it six times, so it shows 1.5).

The final page displays the raw GNSS data. For ease of parsing, I have configured the module to only use GNRMC information. The GNRMC information is sufficient for my needs, but it lacks altitude and satellite count data. I plan to add support for other data types in a later version.

While the MCU communicates with the host computer and transmits GN/RMC data, the serial port remains active. It continuously forwards the GN/RMC data packets received from the module. This allows us to connect the device to a computer (which includes a CH340N chip) and use software like BktTimeSync to synchronize the computer's time using the GNSS system. This is particularly helpful for applications that require precise timing, such as FT8 operations in remote locations.
Currently, I've only implemented these features, and I plan to continue refining this small project. For example, I want to add more parsing of messages and customize the display of call signs on the startup screen. I also want to improve the overall GUI design. Ideally, the remaining ROM will still be sufficient for my needs, otherwise I'll have to switch to the STM32G031F8P6, which offers 64KB of ROM, double that of what I currently have.(Or just give up completely)
I'm also learning how to use SolidWorks software, and I'm planning to design a 3D-printed case for this little toy.
Thank you for reading my diary. I believe that embedded systems and amateur radio are closely related. Creating interesting toys through embedded system development can also be beneficial to amateur radio enthusiasts.
We welcome your suggestions and look forward to working together to build a thriving new community.
BH8PHG 2022-08-16