|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at email@example.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
For novel ideas about building embedded systems (both hardware and firmware), join the 28,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
GPSes Will Fail in April
February 14, 2019
Here we go again.
Remember Y2K? Back when memory was expensive developers shortened dates to two digits to save space, which resulted in massive recoding effort to prevent the end of the world at the turn of the century. Doom was averted and computers didn't wind up as smoking ruins.
Thankfully, we learned much from that event. Except, well, we didn't. The GPS system stores dates using a ten-bit number which represents the number of weeks since the constellation went active. After 1023 weeks it rolls over to zero, so the system's ephemeris data is all wrong and receivers present faulty time and position info.
On April 6, 2019, the ten-bit rollover will occur. Older receivers will likely fail.
Various web sites suggest that receivers built in the last decade or so should be immune from this problem. I presume they look for the rollover and add 1024, but that sure seems like a kludge. What happens in another 20 years? No doubt the assumption is made that the products are disposable junk that won't last long.
One would think that this very obvious bug would have a workaround. Like a menu where one can set the epoch to manually correct for the rollover. I checked: the two GPS units on my boat don't have such an obvious fix.
But the problem is more insidious. According to https://www.spirent.com/blogs/positioning/2018/january/gps-rollover-week some receivers track the date from the time the firmware was compiled. I'm not sure at all how that works as the satellites broadcast the simple ten-bit number, but, if true, this suggests a GPS could fail at some random time after April 6.
The seamanlike mariner takes his departure from port and checks the GPS against the chart, and finds both agree. Days go by and suddenly the GPS squirts out crazy numbers. Mid-ocean, no landmarks for thousands of miles, and our hero is lost at sea.
I guess the solution is to prophylactically toss all old GPSes, chartplotters, and the like just in case something like this happens. That sure sounds like a lousy solution to a simple-to-fix problem.
I come at this from a seafaring perspective, but a ton of equipment relies on GPS for accurate time, time that will become corrupt, for some systems, starting in April. I hope vendors are on top of the problem.
Unix time, for systems and programs representing time with a 32 bit integer, rolls over in 2038. The problem is known as the Y2K38 apocalypse. Not the Y2K2038 apocalypse, but the Y2K38... wait, didn't we make this mistake in Y2K? We're still dropping digits to save what? Typing two additional characters?
I bought my sextant in 1973 and it has never had a date roll-over problem and has never needed a firmware upgrade.
Aside: A lot of folks ask about celestial navigation. Is it really possible to navigate with a sextant just by observing the stars, planets, moon and/or sun? Well yes, but one has to know the time pretty accurately; a four second error throws your position off by a mile. We use WWV to sync on-board clocks and carefully "rate" (determine their drift) those clocks in case we can't get a radio signal or the radio fails. With practice, in reasonable sea states, it's pretty easy to get about two mile accuracy, though in gales I find that degrades to about five miles.
In the almost half-century since I bought this, it has never needed a firmware upgrade
The idea is simple. Suppose the Earth stopped rotating for a bit and you measure, with the sextant, the angle between the horizon and, say, the sun. That puts you on a huge circle on Earth; anyone on that circle would measure the same angle. Walk closer to the sun and the angle increases; walk away and it decreases. Observe another body at the same time and that puts you on another circle. Where they intersect is your position. The circles are huge with two intersecting points, but presumably you know at least which ocean you're on to pick the right point.
The math is solving for a spherical triangle, which is beyond most simple sailors, and it's impractical to plot this on a reasonably-sized chart. So we buy books of tables of pre-computed solutions of the triangle (in the picture the sextant is on one of these books). You also need to know where the heavenly body is at the exact moment of the observation. The Nautical Almanac is a book that is replaced every year which has tables of the positions of all useful bodies for every hour of the year. You do some interpolation using more tables in the back of the Almanac to get the declination and hour angle (sort of like heavenly latitude and longitude) for the body down to the second. And there are corrections for temperature, barometric pressure, atmospheric effects, and even parallax for the moon, which is very close to Earth in astronomical terms.
Bottom line: there's a fair amount of computation required, though it's all simple arithmetic. And a lot of plotting is involved, too, before one comes up with a position. You wouldn't want to do all that plotting on a real chart as it would quickly become a thicket of pencil lines, and the scale of an offshore chart is too crude to get accurate plots. Instead, we construct mini-charts every couple of days using plotting sheets. All calculations and plotting are done on these, and the final position transferred to the main chart each day at noon.
A few days of work on a plotting sheet
Feel free to email me with comments.
Back to Jack's blog index page.
If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."
Recent blog postings:
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.