QLG2 and QLG3 date roll bug fix

Print
Details
Hits: 440

Summary

All QLG2 with the smaller module, and all QLG3 shipped after 20-Aug-2025, do NOT have this issue, and this article does not apply! The earlier QLG1 which uses a different GPS module, also does NOT have this issue!

Contents

Affected units
Issue background
Investigation
QLG3: Installing the new GNSS firmware on the E108 using QMX+ and Windows software
QLG2: Installing the new GNSS firmware on the E108 using QLG2 and Windows software 

Affected units

Any QLG3 shipped before 20-Aug-2025 has an E108 module with the firmware bug. 

Any QLG2 with the older E108 module, which is called E108-GN01, and is a Rev 1 QLG2 PCB. These QLG2 GPS modules look like this

PROBLEM QLG2:

 

The more recent QLG2 modules are Rev 2, these use the smaller 10 x 10mm E108-GN02 module, as pictured below. These modules DO NOT have any firmware problem! This article does NOT apply to these recent QLG2 modules!

Issue background

On 17-Aug-2025, QLG2 and QLG3 GNSS receiver modules show an intermittent incorrect date from January 2006.

Apparently the way GPS satellites keep time, is the number of seconds in a week, and the number of weeks since a particular epoch. The week counter is a 10-bit variable, which means it rolls over to zero every 1024 weeks, being 19.6 years. Apparently, newer systems have 13-bit week codes which means they roll over far less often. See: https://en.m.wikipedia.org/wiki/GPS_week_number_rollover 

See also: https://uniguardgps.com/mt2503/ 
and https://github.com/traccar/traccar/issues/5634 

Both the QRP Labs QLG2 and QLG3 use the eByte E108 module which itself contains the GK9501 GNSS chip. The older QRP Labs QLG1 uses a YIC GPS chip and doesn't have any problems. The E108 module can track two satellite constellations, by default GPS (US) and Beidou (China). 

I believe what happened is that the older GPS system or some satellites in it, are using a 10-bit week code which recently rolled over to zero. The module firmware notices this and corrects for it. However it appears the newer Chinese Beidou satellites use a 13-bit week code. My feeling based on my observations is that as soon as a Chinese satellite joins the position fix calculation, the whole thing goes wrong because the module firmware is applying the same rollover compensation offset to dates from both systems (US and Chinese). Within a few seconds the firmware experiences some kind of internal error and resets itself, restarting the whole satellite acquisition process. Unfortunately the 1pps signal is present only for a few seconds, after the 3D fix and before the recurring self-respect that repeats the whole cycle. So this issue affects not only the date, but also the 1pps signal.

It can easily be observed that there is no fault in any of the QRP Labs firmwares, by observation of the raw serial data. It has also been demonstrated that issuing the command to the E108 module to switch off the Beidou (or GPS) constellation resolves the problem: there is only the incorrect date and recurring reset when both satellite constellations are used (which is the default).

Investigation

The problem was easy to see on a QMX+ with installed QLG3, running the GPS Viewer screen in the terminal. We tried to replicate it also with a QLG2 but the QLG2 behaved correctly! This is good news and showed that the current batch of QLG2s being shipped has no issue, which are the Rev 2 PCB with the smaller E108-GN02 module (10 x 10 mm module). 

Ebyte technical support were very helpful and provided a Flash Tool executable and a new firmware binary, to flash into the misbehaving E108 chips. Our QRP Labs intern Cem did a lot of work on this too.

I devised a way to make the QMX+ be the hardware interface between a PC running the Flash Tool, and the QMX+ installed in it. The normal connection of a QLG3 in QMX+ has only two signals from the module: Serial data out, and 1pps out. There is no connection to send serial data IN to the E108 GNSS module on the QLG3 board. So this was the first problem to overcome. The solution to this is to connect a wire from the TX pin of the neighboring AUX connector at the rear of the QMX+, to pin 3 (RX data). I wrote code in firmware 1_02_005 to be able to route incoming  data from the USB Virtual COM port, to the AUX Serial port and from there to the E108 module. The data in the other direction travels the normal way via the regular GPS data streaming feature in QMX+. So this is a bit weird since one UART peripheral is doing the data transmit, and another is doing data receive; but from the top level perspective (the Flash Tool running on a Windows PC host), it doesn't care. 

A particularly difficult issue was that the Flash Tool specifies an initial baud rate of 9,600 baud (the E108 default at power-up) but then the firmware flash speed has a set of selectable speeds, the slowest of which is 115,200 baud. So at some point the communication has to change the UART baud rates. But WHAT point, was the question... 

To get this working I had to develop tools to monitor serial port traffic in both directions. I used two channels on my oscilloscope to observe the serial traffic. I added a log of the serial traffic to another Virtual COM serial port so I could see where the problems occurred. 

We had observed that command string $PGKC75*1D<CR><LF> was sent to the module by the Flash Tool. Unfortunately no EByte documentation on the GK9501 chip listed this command. But famous QRP Labs intern Cem did research and found this Quectel documentation on the firmware update procedure for their LC76F GNSS module: https://www.quectel.com/content/uploads/2024/02/Quectel_LC76F_Firmware_Upgrade_Guide_V1.0.pdf - this document was absolutely key to unlocking the mysteries of this firmware update procedure. The observed data traffic between the E108 and the FlashTool host did NOT exactly match the Quectel document but it was close enough that it eventually helped us solve all the issues. 

In the screenshot (right), the byte hex data written in Yellow is sent from the PC Host (Flash tool) to the E108; the replies from the E108 to the PC host are in blue. This was actually at the FINAL point of the investigation - at this point the Flash Tool had transferred to the module the "Burn Engine" code and the highlighted commands are what tells the module to change its baud rate to 115,200 baud. The 0x6B answer from the module is the acknowledgement. After this, both the QMX+ Send and Receive UART have to be re-configured from 9,600 baud to 115,200 baud because this is what the E108 module is subsequently using. In the remaining lines of that screenshot there is some confusion, the module apparently replies to host commands with echo of the sent command, which is NOT the expected response (and in fact I don't even understand how that response is possible), and finally the Flash Tool aborts the attempt. As soon as I watched for the sequence 0xE1 0x04 0x00 from the host, and the 0x6B response from the module, the Flash process completed successfully (new firmware installed!). 

So bit by bit, with oscilloscope and USB serial log assistance, we were able to iron out the difficulties one by one, and make the QMX+ firmware now able to act as the interface between the E108 and the PC Host. 

It should be noted that another way to do this would probably (not tested!) be with one of those FTDI or similar USB to Serial converters, which have proprietary drivers and are able to change the baud rate of their UART based on commands from the PC host. This doesn't apply to the Virtual USB COM serial port device in QMX+, which is why it has to monitor the serial traffic looking for that baud rate change command, then action it on the QMX+ peripherals. It was important to do it this way because now anyone with a QLG3 in a QMX+ can easily update the E108 module firmware. 

Key summary: 

Special thanks to Helen at EByte and our QRP Labs intern Cem.

QLG3: Installing the new GNSS firmware on the E108 using QMX+ and Windows software

Here I will document the steps to install the new firmware on the GK9501 chip in the E108 module which is in the QLG3 module which is in the QMX+. For fixing a QLG2 module, this is dealt with in a subsequent section of this page.

None of this is DIFFICULT, anyone can easily do it, but it does require that the following steps are followed precisely and carefully. Any incorrect configuration, will probably result in failure. If you follow these steps precisely, you should be able to update the firmware in your QLG3 module. 

 

READ CAREFULLY!!!

 

1. Install QMX+ firmware 1_02_005 or above

You at least version 1_02_005 (released on 23-Aug-2025). You can download this here. Follow the instructions in the QMX operating manual to update the firmware. 

 

2. Download the EByte Flash tool and firmware update 

The Flash Tool and firmware update are a .zip file, if you click this link below, you should be able to download the file:
https://e.pcloud.link/publink/show?code=XZDK0OZb7ujj920vYQWGNIGbRB7RF5bUBzX 

On clicking this link you should come to a web page looking something like the screenshot below. Click the download icon circled in the picture, to download the zip file.

Note that this Flash Tool is a Windows Executable. It does NOT run on Linux, not even under WINE. I do not know if there is any equivalently capable tool available for Linux; the EByte technical support did not have anything available. Note that this Flash Tool and the firmware update binary file are hosted at this shared location with permission from Helen at EByte. 

Anyway, download the .zip file and unzip it to some convenient location on your computer. 

 

3. Connect a wire from the AUX TX pin to the QLG3 E108

You need to connect a piece of wire (I used the usual QRP Labs 0.33mm enameled copper wire) from pin 3 of the E108 module, to the middle pin of the adjacent AUX jack pin header connector, as shown in the photograph below. Then re-assemble the QLG3 and QMX+. 

 

4. Configure QMX+

Remember that you MUST have firmware 1_02_005 or greater. You also need to connect the USB cable to your Windows PC before switching on the QMX+. So do all that, power up your QMX+; and connect a terminal emulator to your QMX+ (such as PuTTY); if you have not done this before please refer to the operating manual. 

Navigate to the Configuration / System config / GPS & Ser. ports screen:

You need to configure several settings in this screen correctly, to make this work. 

Note that this can be done with ONE USB serial port, you do not need to enable 2 or 3. But since it does involve switching on streaming of GPS NMEA data to the USB Serial port *USB 1", you will not then be able to connect with a terminal and edit the configuration back to disable this subsequently. You can still do it on the QMX+ LCD. But if you want to be able to do it on the QMX+ via a terminal connection then it would be best to enable multiple serial ports (2, or 3). 

It's a good idea to take a screenshot of this screen before you edit it - so that later on you can put things back to how they were. 

The critical settings are:

Other settings in this menu are not relevant to this procedure, and can be left alone. Only the five items listed above need to be set up exactly this way. Again: this has to all be set up EXACTLY like this, otherwise the process is not going to work! Furthermore, after making changes in this menu, always remember to switch QMX+ off and on again, because some of the settings in this menu only take effect on power-up. 

 

5. Run the Flash Tool program sent by EByte

Double clicking the program in whatever folder you unzipped it to, should run the FlashTool. The configuration of this tool is also critical to success! You need to do the following configuration:

The DataBits, Parity and StopBits settings are of no consequence and can be left at their defaults. 

When all is done, your FlashTool program will look something like the below. Your COM port setting and your Flash Img. file location will be different to mine, depending on your system. 

 

6. Run the Flash tool

When you are 100% sure that you have done all previous steps correctly, really, 100% sure (please re-check twice), take a deep breath, and hit the "Burn" button on the Flash Tool. Now don't breathe, don't blink, don't think of anything, just watch anxiously... and if all is well, you should see a green progress bar, ever expanding. In the end after a little less than 2 minutes, you should get a popup message that the Flashing has successfully completed. 

 

7. Power down QMX+ and restart it

This is necessary because after the Flash process, the QLG3 module is still in 115,200 baud rate mode. Rebooting will set everything back to the usual 9600 baud. You can also now edit the "GPS & Ser. ports" menu items to put them back to how they were before you played with all this. Make sure that the "USB TX > QLG3 RX" must be set to "NO" now. You may also remove the wire from the AUX connector to the QLG3 E108 module pin 3. Finally, when making any changes in the serial config menu, switch QMX+ on and off again, since some changes only take effect at power-up.

Now you can go to the GPS Viewer screen and verify that the QLG3 is now functioning correctly, without any date error or reset cycle restarting the satellite acquisition. 

QLG2: Installing the new GNSS firmware on the E108 using QLG2 and Windows software

PENDING! This requires a similar procedure to the above, but now I need to update the QLG2 firmware to be capable of correctly burning the new Flash contents into the E108 module. STANDBY for news in coming days (edit 23-Aug-2025).