-
#25 Reply
Posted by
tom66
on 27 Feb, 2024 22:43
-
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.
-
#26 Reply
Posted by
nctnico
on 27 Feb, 2024 22:48
-
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.
-
#27 Reply
Posted by
Someone
on 27 Feb, 2024 22:48
-
-
-
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.
-
#29 Reply
Posted by
Someone
on 27 Feb, 2024 23:14
-
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.
-
#30 Reply
Posted by
5U4GB
on 28 Feb, 2024 02:17
-
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.
-
#31 Reply
Posted by
peter-h
on 28 Feb, 2024 08:07
-
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.
-
#32 Reply
Posted by
5U4GB
on 28 Feb, 2024 12:05
-
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.
-
#33 Reply
Posted by
nctnico
on 28 Feb, 2024 14:03
-
AFAIK the time is in de mobile signal. No need for a sim card.
-
#34 Reply
Posted by
shapirus
on 28 Feb, 2024 14:38
-
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.
-
#35 Reply
Posted by
SeanB
on 28 Feb, 2024 14:55
-
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.
-
#36 Reply
Posted by
tom66
on 28 Feb, 2024 15:20
-
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.
-
#37 Reply
Posted by
peter-h
on 28 Feb, 2024 15:24
-
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...
-
#38 Reply
Posted by
switchabl
on 28 Feb, 2024 15:51
-
-
#39 Reply
Posted by
peter-h
on 28 Feb, 2024 16:50
-
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.
-
#40 Reply
Posted by
tom66
on 28 Feb, 2024 17:06
-
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).
-
#41 Reply
Posted by
nctnico
on 28 Feb, 2024 21:08
-
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.
-
-
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.
-
#43 Reply
Posted by
peter-h
on 29 Feb, 2024 08:14
-
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.
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;
-
-
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.
-
#45 Reply
Posted by
peter-h
on 29 Feb, 2024 09:48
-
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.
-
#46 Reply
Posted by
dietert1
on 17 Mar, 2024 12:55
-
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
-
#47 Reply
Posted by
peter-h
on 18 Mar, 2024 07:20
-
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
-
#48 Reply
Posted by
dietert1
on 18 Mar, 2024 08:04
-
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
-
#49 Reply
Posted by
tooki
on 18 Mar, 2024 08:25
-
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.