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.

[tom66]

Could also use Time from NPL;
https://en.wikipedia.org/wiki/Time_from_NPL_(MSF)

Usable in UK and most of France, Spain and a bit of Germany, from memory.

The OP hasn't specified whether the solution can be geographically locked or if it has to work anywhere.  If it has to work anywhere, then GPS (or internet) is really the only option, and an internet connection requires an access point to be set up or a 4G worldwide SIM.

[nctnico]

Actually, using a mobile network as a time source is also an option. Unless a device is really installed in a remote location, you'll have some coverage. The pro is that a mobile network has a much better indoor coverage.

[Someone]

The OP hasn't specified whether the solution can be geographically locked or if it has to work anywhere.  If it has to work anywhere, then GPS (or internet) is really the only option, and an internet connection requires an access point to be set up or a 4G worldwide SIM.

No sim required:
https://wsts.atis.org/wp-content/uploads/2023/03/06-Andrea-Dalla-Torre.Accurate-Time-Distribution-Using-Cellular-Radio-Signal.pdf

OP is cost reducing their highly profitable commercial product on your time...

[SiliconWizard]

OP is cost reducing their highly profitable commercial product on your time...

To be fair, a number of regular users of EEVBlog are doing just that, using the forum as free R&D for their company.

[Someone]

OP is cost reducing their highly profitable commercial product on your time...

To be fair, a number of regular users of EEVBlog are doing just that, using the forum as free R&D for their company.

Its a feature of the forum and openly encouraged, but the posters tend to be coy about their details/motivations which is unfortunate.

[5U4GB]

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?

Or just do an HTTP GET to a local web site and read the date and time from the header?  There's still nowhere near enough information to provide a useful response.  In particular the two examples above are so different it sounds more like "I want to play with GPS, and I'll figure out what to do with it eventually".  Which is perfectly fine, but you then need to say so.

[peter-h]

Guys, I am asking to learn, not because I am developing a product. This is such a generally applicable issue... I've been looking at this for 30-40 years.

I have indeed developed a product just recently but that uses GPS time, using a U-BLOX GPS module (as I posted). It is 12/24V DC powered so power is not an issue, and actually neither is the £5-10 cost of that module.

Actually, using a mobile network as a time source is also an option. Unless a device is really installed in a remote location, you'll have some coverage. The pro is that a mobile network has a much better indoor coverage.

I was about to post that I read somewhere years ago that one can get time from GSM (no need for GPRS/3G/4G/5G) without needing a paid-up SIM card, and now I see that Someone has posted something that I slightly doubt the assertion in that PDF that no SIM card is required, but (obviously) if you emulate one (how much is that module??) then you don't need to buy one

One great thing about GPS is that you get UTC, always. I am not sure if GSM tower time is UTC; it may just be local time... otherwise how does your phone switch to local time (it definitely uses GSM; this worked with phones 20+ years ago) when it doesn't know its location i.e. the time zone? Maybe the tower sends out the TZ too.

If you can get to some web server then you can do NTP, so that doesn't help.

[5U4GB]

Guys, I am asking to learn, not because I am developing a product.

Actually if you did want to work on something specific, because having a concrete goal is always a motivator :-), you could look at an update to this which seems to be along the lines of what you've been talking about.

[nctnico]

AFAIK the time is in de mobile signal. No need for a sim card.

[shapirus]

Receiving time over GSM without even a SIM card (as, apparently, the time information is available in the broadcasted signal) is very interesting. Are there any existing modules that could be used for this?

I have an idea of taking an old nixie tube clock that is quite inaccurate to be used comfortably as it is, and replacing the internals with a decent crystal oscillator and RTC (+MCU) that would be periodically auto-adjusted, including initial setup, based on precise (and +/- 0.5 s is precise enough!) time acquired one way or another. This could be: a) NTP over WiFi; b) GPS; c) GSM (?).

WiFi requires initial setup (and reconfiguration when the connection settings change). GPS has poor indoors reception. GSM, if at all feasible, sounds like a perfect solution that would allow to build a clock with zero effort setup: just plug it in, wait for the time sync, done. The signal is available almost everywhere and can be received indoors, save for places like cellars etc. Well, maybe a button to set the time zone offset. And DST.

[SeanB]

GSM almost always likelty is running with UTC, as the signal has to go all over the planet, so all having time in UTC will work better, with the local mobile phone only getting, likely once the SIM provisions it, an offset to localise it for the carrier and region, allowing it to show local time and date. My phone at least does this, getting UTC time and offset from the tower, or you can manage it locally and set the offset manually. Likely going to be set on a tower to tower basis, especially in countries with lots of time zones, though I can bet it can be a hassle where you are sited at the border of the zones, and the phone wants to flip between zones.

[tom66]

Receiving time over GSM without even a SIM card (as, apparently, the time information is available in the broadcasted signal) is very interesting. Are there any existing modules that could be used for this?

I have an idea of taking an old nixie tube clock that is quite inaccurate to be used comfortably as it is, and replacing the internals with a decent crystal oscillator and RTC (+MCU) that would be periodically auto-adjusted, including initial setup, based on precise (and +/- 0.5 s is precise enough!) time acquired one way or another. This could be: a) NTP over WiFi; b) GPS; c) GSM (?).

WiFi requires initial setup (and reconfiguration when the connection settings change). GPS has poor indoors reception. GSM, if at all feasible, sounds like a perfect solution that would allow to build a clock with zero effort setup: just plug it in, wait for the time sync, done. The signal is available almost everywhere and can be received indoors, save for places like cellars etc. Well, maybe a button to set the time zone offset. And DST.

GSM is an interesting one.  I don't know enough about it to say for sure but it is possible the SIM card / eSIM tells the module which bands it is allowed to use?  If that information is not available it may well not be able to listen and/or transmit (legally, as some GSM bands in some countries are reserved for private functions, like military).

But that's just speculation on my part.

[peter-h]

AFAIK the time is in de mobile signal. No need for a sim card.

If that is so, it's amazing this is not widely used.

but the posters tend to be coy about their details/motivations which is unfortunate.

Another reason for not posting much is that after a while it becomes very obvious that almost nobody will read a long initial post, especially if it contains source code So how much info to "feed in" is a matter of judgement...

[switchabl]

New designs should almost certainly target 4G or 5G. GSM is not a viable option most markets any more: https://www.emnify.com/blog/global-2g-3g-phase-out

[peter-h]

AFAIK, all "data" starts with a GSM connection, via a Hayes-like protocol, where you send ATDT*99# and you then get a TCP/IP connection and you connect your TCP/IP stack to the modem, and you get a "socket" interface. The data rate is automatically selected. I was doing that on the Siemens / Cinterion MC52/etc modems.

The above works the same way whether it is GPRS ("2G"), EDGE (basically double speed GPRS), 3G, HSPA (basically 3G but faster), 4G or 5G.

Voice and SMS still runs over GSM. AFAIK nobody runs voice or SMS over 4G etc. although the cellular system is free to do what it likes internally, and it probably runs everything over some IP protocol.

So, no GSM, no data. But in terms of coverage, you always have GSM. You never have say 4G coverage but no GSM coverage. What you do often have is GSM and no data, or GSM and only GPRS (which is too slow for "internet" use these days since even the HTTPS certificate exchange takes too long).

I did a search and could not find out what the towers transmit continuously.

[tom66]

I don't think that's true at all.  Three (UK provider of 3G, 4G and 5G services) for instance don't have any licenses for the GSM band, so the connection wouldn't work if it required GSM to set up.

And many providers do run voice over 4G though often times that only works in-network so you can get HD calls inside EE's network but not EE to Vodafone (that may be changing).

[nctnico]

Nowadays there is a whole flurry of frequency bands in use for 4G/5G and later on 6G. For receiving the time, you don't need to transmit. Only listen. A relatively simple SDR combined with Gnuradio + lte decoding software is all you need to get started.

[SiliconWizard]

Just tested with one of the GPS modules I talked about, still have a couple in a drawer, to confirm.
Definitely not the cheapest stuff around. It's based on a u-blox EVA-M8. It receives GLONASS on top of GPS.

I can confirm that I get UTC time within just a couple seconds after power-on, indoors. (It has again a "big" patch antenna, but no need for a large external antenna either.)
The first type of NMEA sentence that appears shortly after power-on and contains UTC time is a $GNRMC. From what I know, the "N" is indicative of the information coming from GLONASS satellites. The equivalent sentence for GPS is usually $GPRMC. The "position status" field will of course give you "invalid" until you get a proper fix, which could take much longer, but the time is still valid.

I usually get GLONASS signals much faster than GPS in my area. Will depend on the location of course. But a combined receiver like this will give you better odds of getting UTC time in a short amount of time in any case.

[peter-h]

Yes; the RMC packet.

You need to do a sanity check on the time though, IIRC, because the packet checksum is always right. Or maybe the date comes back as 00000000 before it received it... I spent a lot of time on that code a couple of years ago.

Code: [Select]


case RMC:

// We have INBUF_SEARCH_LEN in inbuf, so get data up to a '*' and then the 2 checksum bytes, with a timeout

i = INBUF_SEARCH_LEN;

do
{
#ifdef TEST_DATA
if (true)
#else
if ( gps_ipqcount(g_gps_port)>0 )
#endif
{
#ifdef TEST_DATA
ch=ffgetc();
#else
ch=gps_kfgetc(g_gps_port);
byte_count++;
#endif
loadtimer(TIMER_END, TIMEOUT_END);
inbuf[i++] = ch;
}
else
{
osDelay(1); // yield to RTOS
ch = 0x00; // for test below
}
}
while ( ( ch != '*' ) && ( i < (PKT_BUF_LEN-2) ) && ( readtimer(TIMER_END) > 0 ) );

if ( ( ch == '*' ) && ( i < (PKT_BUF_LEN-2) ) && ( readtimer(TIMER_END) > 0 ) )
{
#ifdef TEST_DATA
inbuf[i++]=ffgetc(); // Get 2 checksum bytes
inbuf[i++]=ffgetc(); // CRLF is left in the rx queue and gets dumped into the shuffle buffer
#else
inbuf[i++]=gps_kfgetc(g_gps_port); // Get 2 checksum bytes - blocking calls!
byte_count++;
inbuf[i++]=gps_kfgetc(g_gps_port); // CRLF is left in the rx queue and gets dumped into the shuffle buffer
byte_count++;
#endif
}
else
{
err_count++;
return(false); // '*' not found -> buffer overrun, or a timeout
}

if ( nmea_checksum() && ( i < PKT_BUF_LEN ) ) // sanity check on #bytes to potentially copy
{
led_flag_gps=true;
pkt_count++;
rmc_count++;

// Extract the date out of the RMC sentence
// Currently we use RMC just for the date/time
// Note that strtoul stops at the first non-digit character.

uint16_t i=0;
uint8_t ch=0x00;
uint16_t comma_cnt=0;
uint8_t status = 0;
uint32_t gps_date_value = 0; // temp value until status = 'A' or 'D'
uint32_t gps_utc_value = 0; // as above

do
{
ch = inbuf[i++];
if ( ch == ',' )
{
comma_cnt++;
}

// at 1 commas, extract UTC - we assume it is hhmmss.ff where ff is tens of ms
if ( ( comma_cnt == 1 ) && ( ch == ',') )
{
gps_utc_value = (uint32_t) strtoul(  (char *) &inbuf[i], NULL, 10 ); // get hhmmss (up to '.')
gps_utc_value = gps_utc_value*1000;
i=i+7;
gps_utc_value = gps_utc_value + ( 10*(uint16_t) strtoul(  (char *) &inbuf[i], NULL, 10 ) ); // get .xx & extend to ms
}

// at 9 commas, extract date - we assume it is ddmmyy
if ( ( comma_cnt == 9 ) && ( ch == ',') )
{
gps_date_value = (uint32_t) strtoul(  (char *) &inbuf[i], NULL, 10 ); // get ddmmyy (up to ',')
}

/*
* One should look for 'A' or 'D' but that will give you a valid date/time only once
* a GPS fix is obtained, which may not happen for a while, or may never happen indoors, so in the RMC-only
* version (the NTP server) we just do a sanity check on the year (2021 or later)
*
* At 12 commas, extract status.
*
*/

if ( ( comma_cnt == 12 ) && ( ch == ',') )
{
status = inbuf[i]; // get status byte
rmc_status = status; // save it to gps struct for debug etc

#ifdef RMC_ONLY
if ( (gps_date_value%100) >= 21 )
#else
if ( ((status == 'A')||(status=='D')) && ( (gps_date_value%100) >= 21) )
#endif
{
gps_date_temp=gps_date_value; // update date
gps_utc_temp=gps_utc_value; // likewise for time
gps_datetime_valid=true; // mark this for RTC setting
//g_rmc_pkt_length=i; // i holds rmc packet length
g_gps_time_pkt_delay=(i*8000000L)/g_gps_baud_rate; // and time delay due to pkt size
#ifdef RMC_ONLY
// This is just a flag saying "we have data" even if there is no position data
g_gps_data_updated = true;
// Load date/time here since we have no other packets so it won't be done elsewhere!
gps_date = gps_date_temp;
gps_utc = gps_utc_temp;
#endif
i = PKT_BUF_LEN; // force while test below to terminate the loop
}
else
gps_datetime_valid=false;
}
}
while ( ( ch != '*' ) && ( i < PKT_BUF_LEN ) );

return(true);
}

break;


[SiliconWizard]

Well, unfortunately, I'm pretty sure it depends almost 100% on the specific GPS SoC you use. On the one I'm talking about, once I get a RMC sentence, the time is always correct. But probably on some other chips, that's not the case.
Likewise, the supported NMEA sentences vary a lot from chip to chip. So it's hard to write perfectly generic code.

And with that said, the module I'm refering to (u-blox EVA-M8 series) has really fantastic performance. The best I've ever tested so far.

[peter-h]

AFAIK the RMC packet is very standard - it is the most basic bit of NMEA.

What I do (above code) is check for the year being 2021 or higher. Well, I should now change that to 2024

I am using the NEO-M9N which should be very similar to your M8.

[dietert1]

Yesterday i happened to connect a MnO2/Li cell to the VBAT pin of a Nucleo64-L476 evaluation board - after removing jumper SB45. When implementing the basic realtime clock functionality i found that the MCU includes a charger. After activation it slowly raised cell voltage from 2.80 to 3.18 V. The MCU also has an ADC circuit to measure cell voltage. Also the realtime clock includes a 128 byte memory ("backup memory"). So it's pretty easy to find out whether the time is reliable or the clock needs to be set. Accuracy appears to be about or better than 10 ppm out of the box without additional tuning. The STM32 RTC logic supports continuous digital tuning. It has some reference clock input, so tuning may be automatic, but i didn't try that yet.

A nice result and i think i will add those MnO2 cells to some other projects, too.
If USB (as a replacement of ethernet) had the actual time in its protocols, that could be a convenient way to set the realtime clock automatically.

Regards, Dieter

[peter-h]

Yes this seems to be a feature of a lot of STM 32F4 chips.

There is actually no way to be sure the RTC time was not corrupted by a power failure. The method I use is to store a 32 bit "magic number" in that memory area and if corrupted then the RTC is re-initialised. Same if the date/time is obviously silly. This method works for my common scenario of selling a product with a supercap which lasts only a few days, so every unit the customer gets will get re-initialised.

The RTC draws of the order of 1uA which is too much for a lithium battery like a 2032, however.

You can charge a battery or a supercap with a resistor

[dietert1]

The MnO2/Li cells i found in our junk collection or the Vanadium-Lithium cells offered nowadays have a capacity of about 20 to 100 mAh. Those batteries also appear at ebay (DIY repair of car remotes).
The RTC circuit of the L476 i mentioned takes about 400 nA, so a 50 mAh cell will last about 125000 hours or 14 years. Optimistic due to self discharge, yet this demonstrates the correct solution. As the battery is rechargable it should last "forever". For many consumers it's acceptable to replace the complete device after 5 or 10 years (except a car).
At 10 ppm accuracy the clock deviation after 5 years would be 26 minutes, so a method to readjust the time is still required.

Regards, Dieter

[tooki]

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.

Why do this when you can use NTP (or SNTP) instead? NTP on ESP32 takes just a few lines of code.

[Jeroen3]

Can't you pull time from RDS (FM), DAB or a LoraWAN network?

[dietert1]

Recently i commented about a RTC test using a STM32 Nucleo-L476. I estimated the out of the box frequency offset as about 10 ppm.
Meanwhile i connected a ublox 6M GPS module to the board and implemented capture of its one second pulse output using timer 1 running from LSE with a 32768 cycle (channel 3). Then i implemented frequency measurement over spans of 65 seconds (linear regression of captured timings). The diagram shows the measured frequency offsets over about 4 hours in units of the RTC smooth calibration unit = 0.954 ppm. Average offset is 9.764 ppm with a standard deviation of 0.031 ppm.
So the clock noise can be as little as one second per year.
This means the clock is much better than 10 ppm once it gets calibrated. It even justifies using kind of delta-sigma algorithm, setting the CALR calibration register to 10 more often than to 11 for an average compensation of about 10.235 CALR units. I implemented and verified this using PB2 as 1 Hz RTC calibration output, capturing it on timer 1 channel 4.
While the MCU is off, CALR should be 10, and then with some extra time at 11 once the MCU is back on.
Also missing is temperature dependent calibration and a model for crystal aging.

Regards, Dieter

[peter-h]

I don't pretend to understand what you did but there are two things people use GPS time for: the UTC time (I am doing that) and the 1 second pulse (there is a market for that but I have never been involved in it).

How accurately the U-BLOX modules implement the pulses, I don't know.

[dietert1]

The datasheet jitter spec for the M6 module 1 sec pulse is 60 nsec (€ 5.79 at ebay). Power consumption including patch antenna is 45 mA.
60 nsec is much better than the timer capture resolution (30 usec at 32768 KHz clock). The 1 sec pulse is perfect for calibrating a clock. My intention was learning how to do it and whether it's worth the effort. It is worth it, but yes, it requires some patience to implement that. Even from a metrology point of view i think it's amazing how this 10 € STM32 MCU performs.

To be honest i connected the GPS to automate adjustment of height above sea level for another application. Standard deviation with the GPS roof antenna is about 2 m.

Regards, Dieter

[dietert1]

Meanwhile there is a 100 h log of STM32L476 LSE frequency measurements with GPS as frequency normal. Ambient temperatures are from a SHT40 sensor subject to about 1 K self heating. The log shows some trend and three "temperature sweeps" of 1 to 2 °C. These are caused by our heating system that turns off at night. Plotting the temperature sweeps one gets about 0.2 ppm/K as temperature coefficient.
In order to determine aging in a two parameter fit, more data are necessary. And maybe i can put the setup into an oven in order to see TC over a wider temperature range. That should reproduce the parabola shown in some datasheets.

Regards, Dieter

[EPAIII]

I know that today everything is about satellites and the internet, but is there some reason why you wouldn't use WWV? It has been used for over 100 years as a world time standard.

I have a digital clock sitting here in my office that synchronizes with their broadcast signal. I bought it at Walmart for around US$35. It runs with battery power and always has the correct time. I am sure there are more professional receivers that can easily provide the time in electronic/digital form.

It is my understanding that the WWV signals (they have five transmitters on different frequencies) do reach world wide. The five different frequencies ensure that the signal can be received almost anywhere. They are run by the US Naval Observatory and have an accuracy of 100 ns of UTC. The time is encoded in the signal in a simple manner. They also provide accurate frequency signals.

I don't know if they still do, but in the past they distributed tables of the error at different times and locations so an event that was recorded at different locations could have the time differential calculated to a high accuracy at some time after recording those observations. It is older technology, but it is still there. And it is free to all.

https://en.wikipedia.org/wiki/WWV_(radio_station)

https://www.nist.gov/pml/time-and-frequency-division/time-distribution/radio-station-wwv

https://nortonsafe.search.ask.com/web?q=wwv%20receivers&ssdcat=321&lang=en&source=nag&year=2015&locale=en_us&geo=us&version=22.23.10.10&plang=sym:en&buildname=retail&heartbeatid=4ae3d98c-56e4-4df2-adf1-00b1d085e47e&eapenabled=false&env=prod&vendorid=1014930&plid=866&plgid=41&skup=21389648&skum=21376863&skuf=90001202-fa&endpointid=4ae3d98c-56e4-4df2-adf1-00b1d085e47e&lic_type=2&lic_attr=17059858&psn=7jjxx287wjvq&templatecat=sbu_w_1000_5039_n360dsp_retail&schemacat=sbu_w&schemaver=1.0.0.0&olpchannel=retail&osvers=10.0&oslocale=iso:usa&oslang=iso:eng&os=windows&showuninstallsurvey=1&installstatus=updated&vendorsrc=firefox&machinelocation=us&sw=0&3in1=0&npw=0&hp=0&dsp=0&cdest=nag&annot=false&vendorConfigured=ask&o=APN12178&prt=ngc&ver=3.21.0.6&tpr=111&chn=1014930&guid=4ae3d98c-56e4-4df2-adf1-00b1d085e47e&doi=2023-11-26&browser=FireFox&prod=DS&doi=2023-11-26&installSource=nag&cmpgn=oct23&darkMode=false&sameTabLaunch=false

[fourfathom]

Recently i commented about a RTC test using a STM32 Nucleo-L476. I estimated the out of the box frequency offset as about 10 ppm.
Meanwhile i connected a ublox 6M GPS module to the board and implemented capture of its one second pulse output using timer 1 running from LSE with a 32768 cycle (channel 3). Then i implemented frequency measurement over spans of 65 seconds (linear regression of captured timings). The diagram shows the measured frequency offsets over about 4 hours in units of the RTC smooth calibration unit = 0.954 ppm. Average offset is 9.764 ppm with a standard deviation of 0.031 ppm.
So the clock noise can be as little as one second per year.

I don't know much about the STM32, but FYI I was running a SAMD controller off it's internal oscillator (no xtal) and marveling at how accurate and stable it was.

Uh, no.

I had the controller hooked up to USB, using USB serial to communicate.  Turns out that the USB is used to monitor and adjust the internal uC clock.  When I unplugged the USB connection the internal clock became pretty awful.  It was in spec, no problem there, but the amazing accuracy was no longer so amazing.

[dietert1]

In Germany we also have DCF77. The advantage with GPS is availability of cheap and easy to use receivers. To make a good DCF77 receiver with similar accuracy one probably needs a rubidium local oscillator, so it can't be competitive.

I don't have that USB confusion in my results on the STM32L476 LSE crystal oscillator. It's a free running crystal oscillator and it serves as a clock. Typical accuracy i see using the "smooth calibration" RTC feature is 0.1 sec per day and this may still improve after implementing aging and ambient temperature correction.
Depending on required accuracy one could turn on GPS maybe once per week or once per month.

Regards, Dieter

[nctnico]

In Germany we also have DCF77. The advantage with GPS is availability of cheap and easy to use receivers. To make a good DCF77 receiver with similar accuracy one probably needs a rubidium local oscillator, so it can't be competitive.

DCF77 will never get you an accurate clock like GPS as DCF77 doesn't / can't compensate for varying propagation delay through the atmosphere and other interferences.

[dietert1]

No, sorry, years ago i did some research and using a rubidium clock and only daytime reception i got down to 10 ** -11 using DCF77. Our lab is about 200 km from the station.
Except the receiver wasn't a small module that you order at ebay for under € 7. And there is no redundancy in case they turn it off one day in the future. I didn't propose to use DCF77 instead of GPS.

Regards, Dieter

[fourfathom]

I know that today everything is about satellites and the internet, but is there some reason why you wouldn't use WWV? It has been used for over 100 years as a world time standard.

There are several reasons why you might not want to use the WWV (and WWVH from Hawaii, and CHU from Canada, and a few others) broadcast GPS time/frequency signals:
* Propagation can be world-wide, but usually isn't. 
* Even with good propagation, this is usually only on some frequencies (WWV broadcasts on 2.5, 5, 10, 15, 20 MHz), and which frequencies you can receive depends on time of day and location.
* Ionospheric propagation (skip) causes of course delay, and this delay varies hourly, daily and seasonally, causing Doppler shift of the received signals.  This shift can be several Hz.  Not a big deal for general time-of-day stuff, but if you need better accuracy this matters.
* Antenna size, available receivers, etc.

GPS is not without faults and vulnerabilities, but it is usually the better solution.

[Peabody]

In the US you would use WWVB, which is the low-frequency transmission.  It transmits the coded "exact" date and time every minute.  You can use the $7 eBay receiver module and an Arduino decoder, so the cost would be very modest.  But you still have the propagation delay problem, so the short-term accuracy isn't good.  But over the long term, as long as you can receive the signal, you would always be within one second of the correct time.

[nctnico]

No, sorry, years ago i did some research and using a rubidium clock and only daytime reception i got down to 10 ** -11 using DCF77. Our lab is about 200 km from the station.

200km is pretty close. But the 10 ** -11 is compared to what? Does the lab you work at have a direct (land line) connection to the clock driving the DCF77 transmitter for comparison purposes?

[dietert1]

There is a german paper here: http://cadt.de/dieter/dcf/Praezisionsfrequenzmessungen.pdf
In Figure 12 you can see the 10 ** -11. This doesn't mean there was a determination of time to 10 psec, but the clock speed (in that case the rubidium oscillator) could be calibrated to that precision using DCF77. In my tests i actually saw agreement between a GPS and DCF77 (resp. the disciplined oscillators) at the 2E-12 level. Maybe they are using a GPSDO at the DCF77 station. Nowadays we better say GNSS.

Regards, Dieter

[tom66]

DCF77 uses a Caesium atomic reference.  It will be pretty close in frequency accuracy to GPS, with the only differences being due to special and general relativity (I assume the correction for this is done in any module for both time and position, but I do not know for sure.)  GPS also has ionospheric correction via the almanac data.  Of course, DCF77 is not particularly subject to relativity, but it doesn't provide any ionospheric correction, so the absolute accuracy of time information cannot be as good as GPS.  But for applications outside of metrology, it's perfectly fine.

[nctnico]

There is a german paper here: http://cadt.de/dieter/dcf/Praezisionsfrequenzmessungen.pdf
In Figure 12 you can see the 10 ** -11. This doesn't mean there was a determination of time to 10 psec, but the clock speed (in that case the rubidium oscillator) could be calibrated to that precision using DCF77. In my tests i actually saw agreement between a GPS and DCF77 (resp. the disciplined oscillators) at the 2E-12 level. Maybe they are using a GPSDO at the DCF77 station.

But as I understand it, that is frequency synchronisation only, not time. For frequency synchronisation, you can use a cell tower or FM radio station as well as these are typically synchronised to a Cesium clock or at least GPS + Rubidium.

[dietert1]

But for this thread relativistic corrections don't matter. Also it doesn't matter whether the DCF77 station has a Caesium clock or not. And it doesn't matter if there is a millisecond delay due to atmospheric propagation over 300 km. These arguments were superfluous.
Making a good clock for an embedded system requires a way to synchronize with some other good clock and calibration of the clock frequency in order to get the correct time between synchronizations. Both is important but somehow the second aspect was lost until i wrote about the STM32L476 measurements and calibration.

Regards, Dieter

[switchabl]

Calibrating RTC frequency, i.e. compensating clock drift dynamically, can be done for specialized applications. But for most embedded systems, picking a suitable combination of crystal and synchronization interval is sufficient.

In the context of this thread, DCF77 accuracy is certainly a non-issue. The problem really is the lack of global availability and poor reliability of off-the-shelf receivers in the presence of metal objects/structures and EMI.

For metrology applications, time synchronization using DCF77 is only accurate to ~1e-05 s even with PM receivers. This is limited by the low chip rate and the variability of LF propagation conditions. Modern commodity GPS receivers are several orders of magnitude better than that. For frequency transfer, DCF77 can more or less compete with basic GPSDOs. But there are specialized GPS-based systems that perform much better (especially using PPP). TAI, from which UTC itself is derived, is established largely using GPS transfers.

There was a nice article about DCF77 (available in english) from PTB some years ago: https://www.ptb.de/cms/fileadmin/internet/publikationen/ptb_mitteilungen/mitt2009/Heft3/PTB-Mitteilungen_2009_Heft_3_en.pdf

[dietert1]

Calibrating RTC frequency, i.e. compensating clock drift dynamically, can be done for specialized applications. But for most embedded systems, picking a suitable combination of crystal and synchronization interval is sufficient.
..

No, i think there is a good reason that STM32 MCUs include circuits for calibrating their RTC. As we have seen this may reduce the need for clock synchronization by a factor 100. Not everybody can ignore a factor 100.

Regards, Dieter

[switchabl]

I think the main use-case is factory calibration, which is common-ish, particularly for applications where synchronization is not usually available (e.g. battery powered long-term data logger).

Beyond that, I'm sure you can sometimes make a case for dynamically adjusting based on synchronization error as well. Say if synchronization is only possible sporadically or very expensive (in terms of power or otherwise). It's just that for things that regularly use a network connection or cellular modem or GPS anyway, I usually wouldn't bother.

[Peabody]

For remote battery-powered data logging, if it's really required that the timestamp be accurate, I think it's possible to use an RTC and have an extended sync interval - maybe up to a year.  But you have to take into account the things that are most likely to prevent that - variations  in temperature and power supply voltage.

Even if the RTC can be powered by the battery directly, with no regulator, it may make sense to use one to avoid any change in voltage as the battery discharges.  So for example a 3.0V, or even 2.8V, regulator might make sense for powering from a single LiPO, or multiples in parallel.

But the big thing is temperature, particularly if "remote" means outside.  The DS3231 RTC has built-in automatic temperature compensation, but I've never tested how well it works, and have not been able to make sense of the datasheet diagrams on that.  But I have a setup that sets the aging register to the value that comes closest to having the RTC's 1Hz squarewave output match the frequency of GPS PPS.  If I can rig it up so the GPS antenna is in the clear, I need to see if the aging solution changes in the freezer, and by how much.

But even if the built-in adjustment isn't all that great, it may be possible  to apply your own formula that makes it work better.  You can read the temperature from registers on the DS3231, and calculate an adjustment.  I think this would have to be set up in advance for each individual part, so getting a logger ready to deploy might require a good bit of testing.

The big cost with GPS is in power.  Mine runs at 45mA.  So you don't want to be powering it up very often.  A DCF77 or WWVB receiver would use less power, but reception would be less reliable.  For most uses though, I think it's possible to rely primarily on the RTC and still have really good timekeeping.

[dietert1]

The M6 module and its patch antenna also  takes 45 mA. Using our roof antenna it becomes more like 60 mA. Ublox are advertising their M10 revision with 16 mA.
Recently we had some cold nights and the correlation plot of frequency offset over ambient temperature now exhibits the expected parabola shape. It is centered at 22.8 °C, with a 1 ppm margin of +/- 5 °C.

Regards, Dieter