Getting time from a GPRS modem

I have absolutely no experience in this area but it strikes me as unlikely. Consider it from a user perspective - you still need to set the time and date on a GPRS equipped handset.

As for "making arrangements" for NTP - what are you on about? They're open access servers. Or is there some licensing condition against "productising" the service? I haven't checked and I'll admit I don't know for sure.

Yes, you have to re-set the time on your phone each time the battery runs out. I always thought this was weird. I always assumed there must be some time information available in the GSM/GPRS signal. But it seems it's not there or at least not available for use somehow.

Server administrators may object if you point commercial embedded devices to their servers without consulting them first. If it's only a few, I guess there's no problem, but if it's tens, or even hundreds of thousands, things may be different. See for example this page on the NTP Pool website:

Furthermore, if you just pick a server, it may cease to exits in the future, leaving your embedded devices without a time server. You can ofcourse specify multiple well known servers to make this less likely.

Am 11.03.2011 12:47, schrieb Stef:

Forget about using NTP over GPRS Networks if you need to rely on seconds. This won't work as expected because the latency is in the range of 0.4 to 30 seconds and more, BTDT. Using ntpd leads also to excessive data traffic, obviously NTP tries to correct the errors with additional requests.

Cheers, Bernhard

Being a few seconds off is not a problem. We have done NTP over GPRS before and did not experience any problems with that. In that case we had our own NTP server. We also implemented our own NTP client that only sent out a single request during each communication attempt, so no excessive data traffic.

Do you know of an alternative to get somewhat accurate time (lets say less than 1 minute error) on a remote embedded device with no user interface and only GPRS connectivity?

Am 14.03.2011 11:48, schrieb Stef:

Ok, i must say that the GPRS signal level on our location was a bit low. As an alternative, here (Germany, also ok for central Europe) we use a DCF77 longwave receiver as a timebase for ntpd. Works like a charm, ntpq says offset < 1ms. I other areas, consider WWVB, MSF, JJY, TDF...

GPS is even more accurate, but requires an external antenna with an unobstructed view to the sky, and is overkill for your application.

Greetings, Bernhard

Yes, considered this as well, but requires additional hardware. I heard that there must be some single chip DCF77 receiver/decoders that require little or no antenna. So far I only found receiver chips with no decoder and requiring a ferrite antenna. Any suggestions?

I don't yet know if the additional cost is acceptable and it introduces a second source for reception problems.

Yes, GPS would give the time nicely. But as you say, it would not always work in a building, not even with the so-called "indoor GPSes". And adding GPS adds some considerable cost.

nd

You probably know it but for the record, rfc868 is also an option. Adds the complexity of tcp (ntp works over udp) but what is inside the tcp transaction is as simple as it gets. Frankly I think you will stick to ntp as it can't get much simpler than that, especially since you are connected to the internet anyway.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Am 14.03.2011 14:35, schrieb Stef:

Have a look at

They sell complete receiver modules, some with decoder. We use here a now obsolete module from HKW. In contrast to cheap receivers of unknown origin, they offer superior reception quality. Despite the ubiquitously internet, there are still reasons to use radio clocks...

Greetings, Bernhard

Didn't know that one, thanks.

This is even simpler than SNTP (Where I earlier said NTP, I actually meant SNTP, sorry for the confusion). And according to the RFC it can also work over UDP. But as this protocol also requires a server (are there RFC868 servers?) and SNTP is also not too hard, I guess there's no real benefit for this application.

So if there is no way of getting time from a GPRS modem directly (which seems to be the case), I think you are right and we will stick to (S)NTP. Probably with a dedicate NTP server or posibly DHCP assigned ones if the network provider gives those.

I think RFC868 is the shortest RFC I've seen so far, only 2 pages. It looks nice and simple, but there seem to be some inconsistencies:

• Time in Seconds from 1900-01-01 (like NTP)
• 32 bit binary number (signed or unsigned?)
• Will serve till 2036 (ah, must be unsigned then)
• But the there is this example: -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT. So it is a signed 32 bit afterall? But that would limit the range from 1832 - 1968 :-(

HKW has some nice little modules, but they do require the external ferrite. The cost of the modules and no SMD mounting may be a problem, but I will have a look at them when we do want DCF77.

The C-max CME8000 comes very close to the single chip solution, but still that antenna. Maybe that antanne-less chip only exists in my imagination. But still, there are DCF77 wristwatches.

At 60 kHz (MSF) and 77.5 kHz (wavelength several kilometers), any practical antenna is going to be minuscule compared to the wavelength.

The ferrite is a good way to concentrate the magnetic field.

The other attestative of using a capacitive probe will require a very high input impedance inputs (megaohms).

At what distance does such devices work ?

A cigarette package sized (with a ferrite core) receiver will pick the Mainflingen DCF77 signal sometimes above the Arctic Circle, but how often does such small wristwatch sized receiver actually synchronize outside Germany ?

Yes I know, but adding a ferrite is not very practical in miniature SMD fabrication. So if there are no receivers with tiny SMD antenna's, we may just rule out DCF77.

Here's the manual of such a watch:

The watch tries to synchronize once a day if I read it right.

And what about the French time transmitter (TDF)? I did not come across that one until I got here:

With it's 2MW of power, it is way more powerfull than any of the other time transmitters (2.5 - 70 kW). So you would expect it to have a large range and widespread use.

Just found this: Official TDF range is 3500km (2000km for DCF77). The phase modulation is more difficult to decode than the DCF77's amplitude modulation, making DCF77 much more popular for cheap receivers.

And if you want accuracy, use TDF: Its the official world time and uses the (then) most accurate atomic clock. See also this page (German):

A receiver can TRY to do anything (without success).

I have heard the 60 kHz transmission from the UK and the 77.5 kHz transmissions in Germany, but I have never heard of any LF transmissions by the frogs.

less

e and

y by mail)

Hah, hadn't noticed that. The servers I have talked to worked unsigned, so does the DPS server I wrote (does ntp and rfc868). I vaguely remember servers which were advertised as ntp only did after all serve rfc868 as well, but it is being abandoned IIRC. Has been in that state for >30 years I guess :D . Well, just tried it on a server which I think used to work a few years back - only NTP today.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

For your global server, resolve it via a domain name within a domain you own. IOW, look up time.mycompany.com, and have that resolve to the active name server(s). That way, you can change which name server you're using just by changing where time.mycompany.com points (and this could be either a public time server or a private one you set up for this application).

You can use one of the many DNS hosting services so that you're not stuck running the mycompany.com name server yourself.

This also gives you users a way to hack in the use of their preferred time server, simply by providing a resolution for time.mycompany.com on their local name servers.

You might also consider resolving timeforyourproduct.(localdomain) (where the local domain comes from the DHCP server), which would also allow users to use their own name server, with a slightly less hackish DNS implementation. This may be easier for some users to set up than extra DHCP info.

my Casio PRW-something synchronised in Tunisia, but rather unreliable.

Oliver

Yes, using an owned domain is the way to go.

That's for later to worry about. We'll probably host the server somewhere, let the hosting company provide DNS as well.

I think that will be quite difficult when using GPRS modems. You will have to hack the mobile phone service providers DNS, not sure they like that. ;-)

Same here, no control over DHCP when using GPRS so you're stuck with the provided info on DNS and possibly time servers. Do mobile phone operators provide NTP server info in the DHCP reply?

Yes, I think they meant unsigned but got carried away in the examples section. RFC868 is from 1983 and is superseded by NTP. Just posted the above comment on faqs.org, it's an RFC afterall. :-)

Also found this NIST page:

On some handsets on some networks time is set automatically.

I think you want NITZ:

See if your modem supports AT#NITZ

Theo