Quick Questions, Short Answers - No Debate

Can anyone help me get a look at this? Thanks.

Edited by Dr Adequate, : No reason given.

Edited by Dr Adequate, : No reason given.

I'm a software engineer doing embedded programming. Our products provide precise time and frequency outputs that are needed by communications networks, including cell-phone networks -- some of our products would go into cell towers. Our products use GPS receivers to obtain that precise time and time duration. GPS depends on highly precise time, which makes it ideal for our purposes. The GPS satellite constellation gets its time from the National Institute of Standards and Time (NIST), one part of the team of "Time Lords" who maintain Coordinated Universal Time (UTC) -- the others are the US Naval Observatory (USNO) and the France's International Bureau of Weights and Measures (BIPM -- formerly by their International Bureau of Time (BIH)). NIST still broadcasts time through the shortware stations WWV and WWVH. Computers set their time through the Network Time Protocol (NTP), which is ultimately synchronized to UTC albeit possibly through several strata -- some communications security protocols require timestamps being close enough, so having your time synchronized with the network can be important.

OK, having access to precise time, that gives me something to set my digital watch to. That's when I noticed that my phone (Windows Phone 8.1) is about 5 seconds slow. I checked my PCs at work and they were both on the right time within a second. I called WWV (you can do that; follow the chain from Wikipedia to the WWV external site) and our product was right on time. My car has GPS; when I checked its time it was right on time (within a second).

Our cell phones should be getting their time from the cell tower, which in turn should be getting its time from the GPS system. So why would my phone be five seconds off?

ABE:
On a hunch, I just power-cycled my phone. Now it's 10 seconds slow.

Take Two:
Since I'm on my home's WiFi, I turned WiFi off on my phone and power-cycled it again. The idea is to force it to connect to the local cell tower for the time. And it's still 10 seconds slow.

What's going on here?

Our cell phones should be getting their time from the cell tower,

It probably is

which in turn should be getting its time from the GPS system.

That's the part you should not count on.

I just checked my smart phone, and it seems to be spot with time. But it hasn't always been. It sometimes looks as if a human sets a clock on a whim for the regional center of the carrier, and that is sent out to all cell phones.

That would be odd, since they must have GPS units in the cell towers. From where else would they get their precise one-pulse-per-second (1PPS) signal with which to synchronize their time-based multiplexing and demultiplexing?

They don't have to use the same clock for setting human time as they use for their electronics.

Internally, the cell phone probably uses UTC, with the tower sending an offset from UTC.

No, the GPS/UTC offset, AKA "leap seconds", is currently at 17 seconds and will become 18 seconds at the next leap second event at midnight at the end of 31 Dec 2016. No correlation with what I'm observing.

GPS satellite signals transmit GPS time (week number and time of week in seconds since start-fo-GPS-time, 1980Jan06 -- only ten bits in the week number, which caused the "1999Aug22 Bug" and led to ad-hoc solutions involving keeping track of which "week-number epoch" we're in) along with the "UTC offset" and associated information about possible upcoming leap-second events. It's up to the receiver to use that data to obtain UTC time to output as well as to generate the 1PPS signal which it outputs within a few nanoseconds of the start of each second.

That 1PPS signal is crucial for the time-division multiplexing of cell-phone signals, because both ends need to know exactly when to start. We have worked with several different GPS receivers over the years. A very few only output GPS time and the UTC offset, requiring you to generate UTC time. Most will output both or either, depending on how you set it up. The newer ones tend to only output UTC time, requiring you to use the UTC offset to generate GPS time if it is needed.

UTC is human-usable time. The whole reason for leap seconds is to keep it synced up with mean solar time (my page on the creationist leap-second claim, DWISE1'S CREATION /...TION PAGE: Earth's Rotation is Slowing, describes how time-keeping works and why we use the length that a second was in 1900). We know that the exact time is known by each cell-tower because they have valid 1PPS signals, without which they could not pass phone traffic between each other. I cannot think of any reason why a cell tower would be designed to add a meaningless offset to UTC.

Now, the discrepancy by where I work is 5 seconds, while the discrepancy at home is 10 seconds. Maybe it's a latency problem, possibly caused by some kind of round-robin polling activity that discovers and pings the phones within the tower's range. That's all I can think of at this point.

UTC is human-usable time.

As far as I know, there is a proposal to stop applying leap seconds to UTC. So GMT will then differ from UTC, because GMT will still get leap seconds.

We know that the exact time is known by each cell-tower .... Now, the discrepancy by where I work is 5 seconds, while the discrepancy at home is 10 seconds. Maybe it's a latency problem, possibly caused by some kind of round-robin polling activity that discovers and pings the phones within the tower's range. That's all I can think of at this point.

Some people have noted that their Windows phone is at least a few seconds, usually more, off when set to Auto update time.

The best hypothesis seems to be that your phone is setting itself to the time your Carrier sends out. This time is not important for electronic synching. This means local configs may vary and latency issues can be human noticeable.

This is a windows MP8 issue that is a near universal bugbear for Windows phone users. People have tested Windows vs Android in the same location on the same carrier and the Android version is basically spot on, suggesting they are using different sources for the time. This has been an issue with those phones for so long I wonder if doing it in this way is fundamental to the functionality of the OS in some daft way.

The grille of the air conditioner upstairs should be held to the frame by several little nuts. The nuts are missing. The bolts they go on are not detachable. How can I ensure that when I'm in the hardware store I buy the right nuts to fit the bolts?

Obvious answer is to hunt around everything you own for a nut that might fit, then take it to the store.

They tend to be standard thread sizes for the diameter of the bolt - particularly in the US where you don't have the metric/imperial problem (unless it's a European model...). So a crude method would be to push a lump of bluetack onto the bolt, then find a bolt that just fits the hole at the store. It'll be crude try it and see stuff. Luckily nuts don't cost anything so you can buy a couple of sizes. Don't forget the washers.

micrometer?

Clay? Remember the movies where the spy/burglar surreptitiously presses the key into clay so that he can go back to his base/lair and make a copy of the key? One thought would be for you to use clay to make two impressions: 1) of the side of the bolt in order to get the thread count, and 2) straight in to get the bolt's diameter.

Or if you know somebody who has a tap-and-die set you could carefully try different dies to see which one fits. As I recall the terminology (I last used one over 40 years ago), a tap is used to cut threads into a hole drilled through metal (you would use a tap on a blank nut) and a die is used to cut threads onto a metal rod in order to turn it into a bolt. Although I worked mainly in carpentry, we did have occasion to re-cut the threads on a stripped bolt, which is why I said "carefully" in the first sentence. A tap-and-die set would be standard equipment in the tool chest of a machinist or of an auto mechanic.

Bolts have standard sizes. They are measured by their diameter and by their thread count (AKA "pitch"). The US Standard has become the Unified Thread Standard (https://en.wikipedia.org/wiki/Unified_Thread_Standard) and uses threads per inch (eg, 32, 24). The terms coarse, fine, and extra fine are also used; I would assume you need fine, which the hardware store should be able to spot looking at your clay impression. And there's also metric. Again, the hardware store would be able to figure that out from your impression.

I do have an M8 phone and have not yet been in a position test another type of phone. At least the problem is not in the cellular system infrastructure (or would you call that the "mobile system"?).

It shouldn't be a matter of them using different sources of time. For example, if the Windows phones were set to use an NTP server such as time.windows.com then it would be on-time -- my PC and laptops use that server and are all on-time when freshly synced. Apparently for reasons unknown to us, the phone's clock gets set an appreciably long time after receiving time from the cell tower.

It doesn't cause me any problem. Just a technical puzzle that I, being a geek, needed to solve. Thanks.

As far as I know, there is a proposal to stop applying leap seconds to UTC.

There's a discussion of that in Wikipedia at https://en.wikipedia.org/...Proposal_to_abolish_leap_seconds.

Mainly, leap seconds causes problems for computer systems and networks and adds complexity by requiring them to know when a leap-second event will occur and how to handle it. The bottom of that section linked to lists instances where it caused a problem. Our units are designed to handle it both because we are aware of leap-second events (most programmers are not even aware of leap seconds) and because we can query our GPS receivers for when the next one will be (it starts to be included in the GPS signals at least a few months in advance). Most computer systems get their time from NTP servers and I am not aware of any field in an NTP packet that provides that information.

A leap-second event customarily occurs at the end of June or December as needed. It could possibly occur at the and of March or September, but that has never happened. Because of variations in the earth's rotation and other factors, the need for a leap second arises irregularly (eg, they normally occur every 18 months, but there was a seven-year gap between leap-second events from 1998Dec31 to 2005Dec31). The French Time Lords at BIPM (formerly BIH) determine when one is needed and releases a bulletin announcing the upcoming leap-second event. From there, it gets uploaded to the GPS constellation and all GPS receivers are informed.

Systems that don't tie into GPS or whose sysadmins don't read BIPM's bulletin will not know that they will suddenly be hit with an extra second. There are a number of applications where suddenly being off by a second can cause a lot of problems (timestamping and guarding against delays greater than transmission time is a common network security technique). So some argue that syncing up with solar noon (a moving target during the year anyway) is not important enough to cause computer problems. I think that no longer adding leap seconds would result in an error of about one minute after a century; hardly even detectable on your sundial.

So GMT will then differ from UTC, because GMT will still get leap seconds.

Does GMT even exist anymore? The term still gets used, just as locals still call the old WWII Naval Air Station Santa Ana lighter-than-air base the "LTA" even though it was a Marine Corps helicopter station from the 1950's to the 1990's. Or how some will still use the verb "tape" when they take a video. We get too attached to old obsolete terminology.

My understanding is that GMT is no longer maintained. When the term is used, it is intended to refer to UTC (maintained through atomic time) or to UT1 (maintained through astronomical observation -- solar observations were not mentioned). If we stop adding leap seconds to UTC, I can see no reason to continue to add them to UT1.

ABE:
Above, I said:

DWise1 writes: I am not aware of any field in an NTP packet that provides that information.

At the Wikipedia link given above I just now found this:

quote:

---

The NTP packet includes a leap second flag, which informs the user that a leap second is imminent. This, among other things, allows the user to distinguish between a bad measurement that should be ignored and a genuine leap second that should be followed. It has been reported that never, since the monitoring began in 2008 and whether or not a leap second should be inserted, have all NTP servers correctly set their flags on a December 31 or June 30. This is one reason many NTP servers broadcast the wrong time for up to a day after a leap second insertion, and it has been suggested that hackers have exploited this vulnerability.

---

Furthermore, looking up the NTP message format in RFC 2030, we find that the first two bits of the packet are the "Leap Indicator":

quote:

---

Leap Indicator (LI): This is a two-bit code warning of an impending
leap second to be inserted/deleted in the last minute of the current
day, with bit 0 and bit 1, respectively, coded as follows:

LI Value Meaning
-------------------------------------------------------
00 0 no warning
01 1 last minute has 61 seconds
10 2 last minute has 59 seconds)
11 3 alarm condition (clock not synchronized)

---

Though as indicated in Wikipedia, many servers neglect to add that information.

So I stand corrected.

Edited by dwise1, : ABE: correction of my statement regarding NTP support of leap seconds

Edited by dwise1, : Forgot to add my "mea culpa" at the end.

Does GMT even exist anymore? The term still gets used, just as locals still call the old WWII Naval Air Station Santa Ana lighter-than-air base the "LTA" even though it was a Marine Corps helicopter station from the 1950's to the 1990's. Or how some will still use the verb "tape" when they take a video. We get too attached to old obsolete terminology.

The historical use of GMT leads to a mildly confusing ambguity today. Here we use Central European Time. In the summer, CET changes by an hour. Through an incredibly sensible piece of international agreement, all of Europe changes their clocks simultaneously. In Portugal, which keeps the same time as the UK, West European Time changes by an hour at exactly the same time as CET does. However, due to the historical legacy of GMT as an international reference time, GMT does not change. Instead the UK switches to BST (British Summer Time). This kind of technicality bothers no one most of the time, except when a client based outside the UK asks me to call them at 15:00 GMT in June, and I'm left baffled if they mean British time or UTC.