EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: rcbuck on August 21, 2021, 05:41:57 pm
-
I built a large digit clock driven by a NEO-6M module so the time would be "exactly" right to within a couple of hundred milliseconds.
I've been pulling my hair out for the last 2 days trying to figure out why the clock was always 3 seconds fast on startup. The clock would correct itself within 3 to 10 minutes. I have spent hours looking at my code and could not find any errors.
Since the NMEA string is updated every second it didn't make sense why the seconds count was wrong. It is possible it would be wrong for the first second. But when the second NMEA string came in the clock should have self corrected.
Finally I decided to connect the NEO-6 module output to both the clock and the input of a terminal program on my PC. I started the terminal program and placed it next to the clock on the PC so I could watch both at the same time. When the NEO-6 started sending data it was 3 seconds faster than the PC clock.
So I just kept watching. After about 3 minutes I saw the terminal program output and the PC clock all at once were in sync. I clicked the disconnect button on the terminal program so I could examine the NMEA strings.
I saw the GPS module second output count 07, 08, 09, 07, 08, 09, 10, ...etc. That is where the module got in sync with actual world time. Once the module is in sync it will stay in sync until the next cold start. I have let it run for over a week and it stays in sync with real time. I have confirmed this by listening to WWV a few times per day.
Has anyone else experienced this problem with a NEO-6M module? I tested 3 modules and they all behave the same way. So I have to assume it is a bug in the module firmware. I am just glad to prove to myself there wasn't a problem in my code.
The attached file shows where the module syncs up.
Edit: One other note: When the module syncs up it is always at the 07, 08, 09 second count.
-
This might be of interest...
https://portal.u-blox.com/s/question/0D52p00008HKCecCAH/neo6m-modulerom-703-gpgga-time-data-is-always-faster-2-seconds-why
NEO-6M module(rom 7.03) gpgga time data is always faster 2 seconds, why?
Did you wait up to 13 minutes for the leap-second values to be updated? The stored time difference between UTC and GPS for u-blox 6-based receivers is smaller than the current time difference between UTC and GPS because of leap-second events that occured after the u-blox 6 was built. The difference between UTC and GPS time is updated at some point within the 12.5 minute (under good signal conditions) GPS data download cycle. When the UTC-GPS time difference update occurs, you should see a jump in UTC time in the NMEA messages.
If the datecode on your unit is fairly old (2011) there have been 3 leap seconds since then, so you might be 3 seconds 'fast' until the leap second data is received. Grab the API manual for the NEO-M from u-blox and query the default leap second counter to see what it has pre-loaded.
-
jc101,
Thanks, that was the answer I was looking for. The best I can determine is the modules were manufactured in week 10 of 2015. The label says 1510. I looked at photos of the module on other sites. They have dates like 1736 or 1622 so the second 2 digits must be the week. I tried to find out what the numbers on the label mean but was unsuccessful. The data sheet only decodes the product type number and none of the other numbers.
It is no big deal as the leap second data updates between 4 and 10 minutes. I guess if I left the module powered down for a week or so it might take the full 13 seconds to update.
I just noticed I typed NEMA instead of NMEA in my post. I will edit and correct.