Cheapest way to get date/time from GPS

[peter-h]

I've looked at this topic from time to time over past 30 years...

You need to receive just 1 satellite. Experimentally, it is clear this works even with a really poor signal which is nowhere near getting a position fix.

But what is the minimum hardware, and does it exist?

For maybe $5 (in 10k+ volume) you can get a GPS module e.g. u-blox which will do this out of the box. But it is quite big, draws quite a lot of current (10s of mA), and exposes you to a short production life of a "fashionable" component.

It would be nice if one could use some cheap RF chip, with a short PCB track as the antenna, and with some cunning software extract just enough to get the UTC time.

The opinion I've got over the years, from apparent GPS experts, is that this is not possible.

[nctnico]

I've looked at this topic from time to time over past 30 years...

You need to receive just 1 satellite. Experimentally, it is clear this works even with a really poor signal which is nowhere near getting a position fix.

But what is the minimum hardware, and does it exist?

Something like a MAX2769 should get you going provided you can do the IQ demodulation and decoding in software. Likely there are similar chips from other vendors which are more price friendly.

[jc101]

The newer U-Blox M10 chips draw just over 10ma during acquisition, dropping to 5ma once signal aquired.  Not the cheapest though, but easy to integrate.
No idea of the price for 10k+, but the UK distributer would no doubt give you a quote - https://alphamicro.net 

[soldar]

For what purpose? Because if it is anything that needs to work indoors then it will not work.

[peter-h]

I buy u-blox from Mouser etc - same price as any disti, below 1k or so But still pricey.

The MAX2769 is interesting but expensive. If it was say £1, that would be really handy for this job. As an interesting aside, the Marconi patent on fractional-N has expired, hence this...

You can get GPS indoors if there are any windows. Certainly will be a problem if deep in some bunker but most office/factory scenarios are workable.

And then there are scenarios where there is no signal but running a coax to an antenna elsewhere is entirely acceptable e.g. in GPS to NTP boxes which are used in specific scenarios where for security reasons an internet connection must not be made. I make a product which (among other features) does GPS to NTP and it works great. It uses a NEO-M9N module which draws some tens of mA (warm to touch).

[tom66]

The problem is to receive just one satellite you need to acquire the full P(Y) code at 1.023Mbit/s and decode it.  With the typical received signal level of GPS (-140dBm or something like that) this is not a trivial problem to solve.

What you could of course do is use a regular cheap GPS module to train an RTC.  Many of them offer PPS outputs which could be used to precisely sync the second if absolute accuracy is what you need.  I have used this chip in the past, it is quite brilliant:

https://ambiq.com/artasie-am1815/

It genuinely has almost un-measurably low operating current and will drive a crystal at 32.768kHz on sub 100nA.  A sleeping u-blox module will use much more, but you could totally cut the power to it if you needed.

u-blox availability is quite good now.  Also their modules are pin-compatible and generally forwards compatible.  NEO-M5x through NEO-M9N are all pin compatible.  So design in isn't such an issue.  IIRC they also have time-only products but they probably cost more as they will be geared towards precision acquisition.

[Jackster]

Could you consider using MSF radio time signal instead?
Pretty dam accurate to around 1ms and has great penetration at 60kHz.

The modules back when I was looking at them draw around 1mA and are quite small.

[peter-h]

I have used this chip in the past, it is quite brilliant:
https://ambiq.com/artasie-am1815/

14nA RTC!! Amazing. Finally after about 35 years (DS1302) we have a big improvement.

Could you consider using MSF radio time signal instead?

Not yet.

The problem is to receive just one satellite you need to acquire the full P(Y) code at 1.023Mbit/s and decode it.  With the typical received signal level of GPS (-140dBm or something like that) this is not a trivial problem to solve.

How do U-BLOX solve it?

What you could of course do is use a regular cheap GPS module to train an RTC

Isn't that back to U-BLOX or similar and lots of current?

[hans]

Ah yes, the AM1805 RTC is quite a nice chip. It surely beats many (modern low-power) MCU RTCs which are about on par with the DS1302. E.g. the RTC on a STM32U5 uses around 300-400nA from LSE.

The problem with the GPS receiver chip is probably the lock time. Modern GPS receivers can have hundreds of channels to search for many C/A codes at the same time. The spreading code is quite long and the bitrate is quite low, so you'll need to be looking for quite some time to get a lock. Especially if you would only implement a few correlators to run at a time.. if you're looking for the wrong C/A code, it could take ages to find a GPS lock.
How often do you want to time sync? Once a day? And is then a MCU running at several MHz for potentially minutes fine? Then go ahead. But I think the C/A correlation will also be very fiddly to get right.. GPS is below noise floor and has over a dozen concurrent users on the same channel.

[SiliconWizard]

The point I don't quite get is why the power draw of a GPS receiver module (which, for just getting time, shouldn't draw all that much) would be an issue for any practical purpose?
Just use a decent RTC and update time once or twice per 24h from GPS (depending on application, a bit less frequent than this is probably still fine), that'll give you ample accuracy for maybe 20-30mA drawn for a few seconds. With "normal" reception conditions, you should get time/date from GPS just within a couple seconds, way before a "fix" has been acquired. Say, 30mA for 5s per 24h, that's an average current of 1.7µA.
Just a thought.

I've used DCF77 in past projects for this (there are equivalents in various parts of the world), but even if the power consumption of a DCF77 receiver looks attractive at first sight, the full picture needs to be known. While it draws less than a GPS receiver for sure, you'll need to power it for much, much, much longer to, maybe, if weather is ok and stars are aligned, and having to wait for a full minute cycle at each attempt, finally get the time and date. Maybe. Believe me, it will definitely draw a lot more current on average.

[tom66]

I have used this chip in the past, it is quite brilliant:
https://ambiq.com/artasie-am1815/

14nA RTC!! Amazing. Finally after about 35 years (DS1302) we have a big improvement.

Be careful, the headline figure of 14nA is for an onboard RC oscillator.  For the crystal it comes in around 55nA.  Still good but maybe not quite as amazing!  It has some onboard routine to switch from crystal to RC occasionally, keeping the RC in tune... never used it though as it seemed like a micro-optimisation for us.

The problem is to receive just one satellite you need to acquire the full P(Y) code at 1.023Mbit/s and decode it.  With the typical received signal level of GPS (-140dBm or something like that) this is not a trivial problem to solve.

How do U-BLOX solve it?

With an ARM microcontroller with some kind of DSP block.  It's obviously part of their secret sauce because they do a lot of additional processing on the data and have to detect more than one band at once, so exactly how is probably only known to their engineers.

What you could of course do is use a regular cheap GPS module to train an RTC

Isn't that back to U-BLOX or similar and lots of current?

Depends on how accurate you need it?

If you only need +/-1 second per day drift then I would say you would get away with powering the receiver up for <1 minute every 24 hours.   Power consumption would be pretty negligible as SiliconWizard points out.

If you need something like +/-1 second per hour then you start getting a little more aggressive and may need to power up the receiver more often and spend some effort on tuning the crystal to get the 1 second timepulse in absolute sync with the RTC's timepulse.

[soldar]

I've used DCF77 in past projects for this (there are equivalents in various parts of the world), but even if the power consumption of a DCF77 receiver looks attractive at first sight, the full picture needs to be known. While it draws less than a GPS receiver for sure, you'll need to power it for much, much, much longer to, maybe, if weather is ok and stars are aligned, and having to wait for a full minute cycle at each attempt, finally get the time and date. Maybe. Believe me, it will definitely draw a lot more current on average.

Years ago I bought a LIDL Auriol Z31055a clock, temperature, etc. which, supposedly, syncs with DCF77, except that it just doesn't. At least from Madrid it doesn't. When I change the batteries it will not set the correct time. When Daylight Saving Time arrives it will not change.

I have a special window with qibla to DCF77 marked so that the LIDL clock can better send its prayers and receive the necessary blessings but it can still take days or weeks if it happens at all. (One more reason to hate Daylight Saving Time.)

Maybe in Germany it works but I do not consider it a reliable thing in Spain.

[alex_]

I was already struggling with DCF77 in the south of France indoor with the cheap antenna, so it must not be better in Madrid.
Do you have better results outside ?

[peter-h]

How often do you want to time sync?

My current GPS to NTP product syncs the RTC every minute (secs=00). It is free after all once the module is running and picking up >=1 sat, once the customer has paid for the U-BLOX module option

This is not fantastically hi-tech (like the super precise 1Hz signal you can get from some 4 digit priced boxes) but it is down to a fraction of a second, and (this is important) is monotonic.

As others have posted above, the timecode solution is unreliable. I have a clock on the wall here, lots of windows everywhere, and sometimes it gets no sync signal for days.

[5U4GB]

For what purpose?

I think this is the most important question, without any context pretty much any answer could be completely wrong or completely right but there's no way to tell.  What are you trying to do?

[peter-h]

To get date/time.

Or to periodically sync a standard 32768Hz xtal RTC.

[tom66]

To get date/time.

Or to periodically sync a standard 32768Hz xtal RTC.

...to what required accuracy?  Is there a good reason strobing power to the GPS module as has been proposed here not practical?

[peter-h]

Well, unless you have an external time source, "accuracy" will be rubbish eventually. It just depends on what "eventually" means...

Even a TCXO (I have a big 10MHz one right here, destined for a Marconi sig gen) is only just barely good enough for lip sync over a number of hours of video recording if the recorder is separate from the camera. And that is a really expensive approach.

The technology involving xtals is simply too poor to deliver a product whose clock accuracy will manage a year without being bloody annoying. The mfgs get away with it because in most applications the users don't really care.

So many products could be enhanced with external time sync.

Re strobing a GPS module, that would deal with the power issue but not the cost.

And it addresses all sorts of issues e.g. loss of time via battery replacement, or even via a power cut (even the clock in a $1000 domestic oven has no battery, so goes back to 12:00 after every 1 sec power cut).

To some extent my Q is rhetorical; I am amazed somebody has not done an RTC chip which takes in a GPS antenna on one pin

Other thread:
https://www.eevblog.com/forum/microcontrollers/cpu-crystal-pull-range-and-how-critical-are-the-caps-for-e-g-usb-fs/

[soldar]

I was already struggling with DCF77 in the south of France indoor with the cheap antenna, so it must not be better in Madrid. Do you have better results outside ?

As I said, I place it in the open window facing qibla DCF77 and it still will not work reliably. It can take days or weeks to sync.

[switchabl]

I am amazed somebody has not done an RTC chip which takes in a GPS antenna on one pin

Well, that describes most GPS chipsets which can usually run an RTC in standby mode (if you connect a crystal). Having an approximate time and position as well as a recent almanac massively speeds up subsequent satellite acquisition. The difference between a regular GPS chip and the one you envision would mostly be the firmware.

GPS is basically a lot of far away (below the noise floor) transmitters all broadcasting on the same frequency with code division multiplexing, at ~1 Mbit/s chip rate. In order to get any data at all, even from a single satellite, you need to sample the downconverted signal at several MSa/s and, after a cold start, run it through a bank of correlators covering a range of possible codes, code phases and Doppler frequency shifts. This needs significant DSP power and running (pseudo-)trilateration for positioning once a second is really cheap by comparison.

It is possible to trade off processing power against acquisition time. But if power consumption is a priority, the need to have the receiver active for prolonged periods doesn't make this a very attractive option.

[Peabody]

I've used the DS3231SN RTC, which has an Aging register to permit calibrating the built-in crystal oscillator.  The register value adjusts units of capacitance on the crystal legs, and a change of +/- 1 adjusts the crystal about 0.1ppm at room temperature, so if you find the right setting, you're good to 3 seconds per year or less.

I wrote an Arduino sketch that takes as inputs the 1PPS output of a cheap GPS module and the 1Hz squarewave output of the DS3231SN, and adjusts the Aging register until the two are nearly as possible the same frequency.  The DS3231SN also has an automatic temperature adjustment that uses the same capacitance adjustment mechanism.

So with an initially calibrated RTC, the frequency of syncing to GPS might me as seldom as once a month or so, depending on how accurate you have to be, and how important GPS power consumption is.  I think temperature would have the biggest impact on how often syncing needs to be done.

Edit: Is there any chance the British MSF broadcast would work better than DCF77?  In theory it shouldn't because it's lower power, but in a particular location it might.

[nctnico]

The problem with any RTC is that you'll need a battery which needs swapping at some point. And an RTC still doesn't solve the time sync issue so it is back to square one.

A modern day microcontroller has a significant amount of processor power so I expect it can do GPS decoding in software. Remember GPS was developed in the 1970's; it is very old technology made for slow electronics. If you can find a low power SDR frontend, it should be doable to build your own receiver, especially if you only need time.

[antenna]

I found an old microsoft streets and trips GP module, found a website that shows the pinouts, and was able to read it via arduino with serial monitor in the arduino app.

[SiliconWizard]

I was already struggling with DCF77 in the south of France indoor with the cheap antenna, so it must not be better in Madrid.
Do you have better results outside ?

It has gotten way, way worse in the past decade.
The DCF77 signal is always noisy, so the decoder needs to be a bit "smart" to get reliable data - I implemented this on MCUs - but around 10 years ago, when I did this, it usually took only a few minutes to get a valid time and date, indoors, with a relatively small antenna. These days, the same devices, in various parts of Europe (unless close to the transmitter), fail to get any signal reliable enough to get valid data over the course of, sometimes, several weeks in a row. There's probably much too many interferences now for this to be practical. That's unfortunate.

GPS works rather well outside for this, but indoors, it's not that great. Even when close to a window, not all receivers are made equal. I've used receivers with surprisingly good performance even indoors, but these had a rather chunky patch antenna (like 40x40mm) and were based on the most expensive chipset that was available (don't remember which exactly, I can look that back.)

[alex_]

To get date/time.

Or to periodically sync a standard 32768Hz xtal RTC.

What about a wifi module (ESP32 or other)? Get the header of a webpage to get a UTC time and date.
That's how I resync daily my scheduling devices. Not ns accurate of course, but cheap and 0 power between polls.