Not so sure.
My recollection is that when a GPSs firmware is written it has the (at the time) the current value of leap seconds hard coded in. So when anther leap second is added …
If the GPS sent out time strictly in GPS time, it would be 18 seconds out from UTC time until leap seconds was updated. That might be noticeable …
The module is dated 2011. So it should be 3 sec off if it is a missing leap problem. And then time would be late, not early.
When I look into https://time.gov/ web applet, it’s time is in partial second ahead relative to NMEA time from NEO Ublox receiver.
Which one is most accurate ? 
Once again i examined the source coder of the packet forwarder, and i think i found the reason why the GPS time is 1 second off. The code is written for Ublox 7 module and is using a special UBX message NAV-TIMEGPS. I has as fallback to an NMEA parser, if no UBX message is detected in the GPS data stream. In NMEA the message “RMC” is evaluated, but this message can be late after pps trigger, depending on GPS module, and in this case the next second will be grabbed for a pps pulse.
So i will change to an Ublox NEO 6M, which supports NAV-TIMEGPS. My expectation is that it will work precise then.
This could be an explanation why some gateways are seen 1 second off: they use legacy semtech packet forwarder, but don’t have Ublox GPS chip.
/* The current implementation relies on proprietary messages from U-Blox /
/ GPS modules (UBX, NAV-TIMEGPS…) and has only be tested with a u-blox 7. /
/ Those messages allow to get NATIVE GPS time (no leap seconds) required /
/ for class-B handling and GPS synchronization */
Great investigation work & analysis guys
Some minutes suggests a less than ideal position, that GPS ought to get a fix from cold in around 45 seconds out doors with a decent view of the sky.
A battery (to backup the GPS) would help for short term power interruptions, but if power is lost for periods of longer than an hour say, the GPS can still take an extended time to get a fix on power up, so a battery may make little difference in these circumstances.
But for pps signal a fix is not mandatory, right?
for pps signal a fix is not mandatory
Time and space are mutually dependent in GPS and very nearly the same thing such that you can’t know one without the other. GPS measures the time delay between you and (at least) four satellites, and finds the position where those delays converge and thus knows your time as well - which is to say, it produces a fix in time and space. Getting enough information from satellites to resolve an answer is what it means for GPS to get a fix.
Any PPS output without a fix would be garbage, meaningless in absolute and no more accurate incrementally than whatever oscillator is on the board.
If something tried to give you an output based on less than four satellites it would have to guess at the propagation delay, which means that the output timing would then “jump” when an actual fix was received, something that would be rather disruptive to anything trying to lock to the PPS signal. You’ll have to check the documentation to see what a unit actually does - ironically, a one satellite PPS output might work for you, but it seems dubious that this would be generated as it would be misleading for most uses of GPS PPS.
Well you are right in that you can get a GPS sending the PPS signal before it starts reporting an actual fix, the Ubloxes can do that for sure.
But the PPS has to be related to location, so to assert that the PPS edge is accurate, you would be wanting to check that the GPS reported position is close to its known surveyed location.
100% agree.
Anyway, many of today’s GPS have (configurable) mechanisms to deliver still pps if lock is gone. Because on mobile devices it can happen that they have bad or no reception. And GPS should have quite high quality oscillators which are better than the ones in microcontrollers…
u-blox Reference
Carrying a signal into a loss is a far less complicated process than inventing one with no initial information. Carrying it into a loss, you only have to worry about drift during the time of loss which is likely to result in a small correction when signal is re-acquired.
Starting from nothing means making a guess, which would result in a large correction. Do you then “jump” to the right time, confusing whatever is watching, or fade in the correction slowly, delaying the time until an accurate output is achieved even longer? That dilemma makes such a thing dubious in general, and only really viable if tuned to a specific need.
Stepped into the next pitfall: I tried to change the “Global Top” GPS module by an U-Blox. Had two china boards on stock, one with U-Blox Neo6M and one with U-Blox Neo7M. Took me some hours to find out, why the gateway did not get time with these modules. It turned out, that both modules are counterfeits which support the chinese “CASIC” protocol, but not the U-Blox UBX. 
The UBX-message “NAV-TIMEGPS”, which is evaluated by the semtech packet forwarder, ist not delivered by these modules. Thus no time in the gateway.
The stickers look pretty original, no chance to reveal the fakes by eye. But the init string proves, that the module has at AT6558 chip.
Both modules are fake, but different boards from different sources. I suspect that most china boards like TTGO etc. use “U-Blox” counterfeits. It’s annoying.
I ordered a NAVILOCK-NL-731ETTL today. Price is 5 times higher, so i hope to get a real u-blox with it…
I dont recall having a ‘fake’ with the Ublox7 or Ublox8. These at least accept the standard UBX commands for turning off sentences, going into backup mode and going into high altitude mode.
I tried two different china modules, one labelled Neo6M, the other.Neo7M. Both are fakes.
What would be the most basic, most simplest way to test if a u-blox module is genuine or a fake?
Following link unfortunately does not provide any information for how to check:
https://www.u-blox.com/en/counterfeit-products-and-u-blox-brand-misuse
I change the variable stat_timestamp into ISO 8601 format through string conversion method, and then insert it into the time field of the uplink data, and the server can receive the time signal. Of course, this is not accurate, because stat_timestamp does not contain milliseconds, so I can only customize a constant.
This may be a relatively desirable alternative without GPS.