Why didn't GPS crash?
Вставка
- Опубліковано 21 жов 2024
- More on the GPS roll-over.
www.theregiste...
"In the Future the Modernized GPS Navigation (CNAV and MNAV) message has a 13-bit week number, which for all practical purposes solves this ambiguity"
www.gps.gov/cg...
See me turn on my TomTom:
/ 26065751
If you want to see more hilarious tales about roll-over errors then, well, READ MY BOOK.
Get it from Maths Gear and be guaranteed a signed first edition hard back.
mathsgear.co.u...
But it is also available on Amazon.
www.amazon.co....
CORRECTIONS
Sorry: I used “overflow” to refer to when the value bursts into the adjacent memory as opposed to just rolling back to zero. But an overflow can simply mean it has rolled over.
I add the extra week bits to the wrong side of the number! Unbelievable. I even point to the other side of the screen in the video. Somehow I totally missed this until it was too late. I’m surprised loads of people are not pointing it out. So far only Kyle K has noticed. Good on you, Kyle.
Let me know if you spot anything else!
Thanks to my Patreon supports who do support these videos and make them possible. Here is a random subset:
Vojtěch Mělnický
Fernando Gaete F.
James Dexter
Colin Williams
Alan McNea
Support my channel and I can make more maths videos:
/ standupmaths
Music by Howard Carter
Filming and editing by Matt Parker
Design by Simon Wright
MATT PARKER: Stand-up Mathematician
Website: standupmaths.com/
Maths book: wwwh.umble-pi.com
Nerdy maths toys: mathsgear.co.uk/
It affected Prague public transport, ticket validating machines were printing August 23, 1999 on tickets
Were people being denied transport because of this?
How cool is that! Thanks for the info!
@@EweChewBrrr01 Don't know, but I would expect not. All the ticket inspectors would know about the problem pretty quickly!
@@EweChewBrrr01 obviously not
Jan Sten Adámek wh6 the 23rd specifically though
The little graphic of connecting to the satellite is adorable
Looks like in the specifications for CNAV (IS-GPS-705) whenever they mention week numbers they direct you to IS-GPS-200 paragraph 6.2.4. Which states the weeks start at January 5, 1980.
So the new system uses the same start point
@@Kelan-pn6em Actually, not quite, since we need to calculate 8191 weeks from January 5, 1980. This gives us the result of Saturday, December 29, 2136, which will be the last day of the new first epoch, meaning that the GPS date will roll over on Sunday, December 30, 2136.
@@krustykrabpizzzza !Remindme 2136-12-29T23:59:59+00:00UTC
@@gff655 /r/lostredditors
@@krustykrabpizzzza Great ! Now we know when the end of the world will for sure happen.
@@justpaulo It does often turn into that, doesn't it? It'll be Y2K all over again. Or someone will make a new system a couple of years before then, and the Matt Parker of 2136 will grab a GPS from the ancient year of 2019 just to show it still working but the date displaying as January 5, 1980, and then explaining the reason no one has heard of it is because the problem was already fixed, and new systems already have nothing to worry about.
"It does not overflow, it just resets to zero" - literally what unsigned integer overflow is :D.
Well most people think of overflow as signed overflow going into the negative, that's probably why he said that.
An overflow is when it writes to the next bit over (in some other data or op field); a rollover is when it correctly zeros out the current data field without an unwanted write elsewhere.
@@MAlanThomasII No, not really. That doesn't happen unless you read out and write back multiple numbers in the same word and perform the math without isolating the number you want.
This basically never ever ever happens because nobody does that.
@@THB192 No, an overflow can happen any time the program doesn't perform sufficient bounds-checking. A badly-written program in a language that doesn't enforce sufficient bounds-checking can write outside of the intended word. That this would require a lot of idiocy and work to accomplish and yet happens anyway just proves the aphorism that "If you make something idiot-proof, someone will just make a better idiot."
@@MAlanThomasII You're thinking of an out of bounds access. Arithmetic on a word in memory is performed by loading that word to a register, doing the operation, and writing it back. Adding to a memory word can't just "spill over" into the next.
To answer your title question. The GPS did not crash because it was the phone you dropped in the water.
Came here to make this comment, along with something about the epitome of Parker Audio, but the standupmaths crew is already on it!
"On behalf of all of us in the past, we're sorry."
Too real
Well, nobody expects people from the past to have a crystal ball and be able to predict the future... Well, I dunno. There are some stupid, naive people out there. I mean, just look at how many people take the enormous successes of our modern-day civilization completely for granted, like we live in some kind of shithole that hasn't been improving over the last thirty years on almost every metric you could measure it with.
Improved? to me it has decayed.
We could make infinite videos with that line.
@Mytheroo it could survive (alongside these comments) in an internet archive.
@@L0j1k "almost every metric"
Except the ones that actually matter, like rates of depression, suicide, income inequality, addiction, incarceration, obesity, blood-lead content, job satisfaction, poverty, redlining, foreclosures, bankruptcies, homelessness, CO2 emissions, temperatures, hate crimes, etc.
But I mean sure, a tech company told me that we're the best society there has ever been as long as I keep upgrading the computer in my pocket, and I believe them. After all, how could we *not* be the pinnacle of mankind!? We're *awesome*
Clearly the pessimists are the naive ones here...
So the WEEK number was a weak number.
sorry ;-)
We are sorry!
Should have used real weeks
"And today is saturday". Wait wtf Matt don't take my friday night away from me!
We need Rebecca Black to tell us the right order of the days, we're slipping!
The Friday night you're spending watching maths videos?
I’m watching this on Saturday morning, but hey, he didn’t take your Friday night away from you, he just gave you an extra weekend! It’s actually _last_ Saturday now.
@@bonecanoe86 no
ARFSY It took Matt 6 days to finish his holiday, and to upload the video. So 6 modulo 7 means you lost a day, but gained a week.
The Garmin etrex was developed in the first epoch, as evidenced by the copyright dates. Although it seems it was only on sale after that week number rollover. So it may very well have been coded to assume that the largest week numbers were still in that first epoch, the smaller week numbers in the second epoch. Perhaps the upper 255 weeks in the range were before 21 August 1999 (first epoch) and the lower 769 weeks were 22 August 1999 and after (second epoch). Without knowing the cut-off week number they chose, who knows when Matt's unit actually switched from calculating assuming epoch two to epoch one.
This feels likely! I should have turned it on a few years in advance and monitored its progress.
So... the reason things didn't crash is that the week number barely matters to the functionality of the GPS. Kind of underwhelming.
It barely mattered to the functioning of GPSs prior to 2010. There may be more recent devices that care more, but those will be out of use by the 22nd century when the problem comes back.
@@OriginalPiMan We hope.
Nobody thought we'd still have machines from the 1970's in active use in 2000, but we did.
So... There's no saying what will happen.
Though, to be fair, the estimated lifespan of electronics with no moving parts consisting primarily of integrated circuits is about 200 years at best.
And that's assuming it doesn't contain flash memory (estimated lifespan for data retention of 10-50 years depending on variant) and that the capacitors don't all die. (estimated lifespan about 30 years, but can last longer. Generally also easy to replace if something is being actively maintained.)
So... Never say never, but yeah, that does seem like an unlikely timespan for a device to remain in active use.
(plus the satellites using the current method would have to last just as long, which is even less likely. - if they don't it isn't all that relevant anymore whether any receiving hardware still works.)
Kerico Actually week number is critical to functioning of GPS, because the satellite almanac is valid for exactly one week. When the time comes, the next week's almanac must be downloaded. As long as the satellite and receiver have the same week number, the system works.
@@gordonrichardson2972 First off, if the week counter were to check that one uses the current almanac, then the week counter rolling over wouldn't be a problem. (Unless one is a novice at programming.)
Secondly, the full current Almanac is sent out ever 12.5 minutes. With orbit status and everything. (The week counter isn't even part of this.)
The week counter is part of the GPS time standard. This isn't used for positioning, but rather to tell what time and date it currently is. With a 1.5 second resolution. (in other words good enough to replace the real time clock in battery powered GPS products.)
Actual time critical applications that "could" care about the GPS time, are normally using GPS disciplined oscillators/clocks, these are usually accurate to within +/- 10ns.
The only thing the week counter has to do with GPS positioning and GPS almanacs is when booting up a device. Since the satellites can provide up to 60 days worth of future information about satellite orbits, then this can greatly help in finding the satellites and thereby reduce the time needed for the GPS receiver to give an actual location.
It can take 10-20 minutes to get a initial lock if the device has no clue where the satellites are. Compared to literal seconds if one knows where to look. This is really important in navigation of for an example an airplane that suffers a minor power glitch. Then getting GPS back quickly is a fairly good thing.
@@todayonthebench a naive implementation of a GPS disciplined clock would have exact timing from second to second, but suddenly send out the wrong date. GPS is usually considered authoritative so it could have caused a bunch of problems if not accounted for.
I'd like to try to clarify about the term 'overflow' used in a computing context. For most modern computer processors, 'rollover' and 'overflow' are the same thing at a basic level: when it happens, the processor sets some flag---often actually called the 'overflow' flag---and it is up to the software to either look at the flag and respond to it (perhaps with some kind of error) or just ignore it. You might term responding to it as 'overflow' and ignoring it as 'rollover'. It is a frequent mode of software failure for the programmer (or compiler or support library) to fail to respond appropriately (or at all).
Matt, I have exactly the same model of Garmin etrex that you have, and mine is showing the correct date today (April 12, 2019). I may have updated the software at some point, but I don't remember. Mine is running software version 2.20. You can check yours by going to the menu then choosing "Setup" and then "System". I'd be curious to know which version you're running.
Mine is 2.14 and is showing time, date, sunrise and sunset correctly.
Mine is running version 2.11 and has the correct time and date.
@@JoanLu Miine to too, I just put a battery in (x2) after about 5 years without. It took a while to get a fix but the time and date are correct.
I've got one that looks like that. Picks up sats outdoors but I can't give it right date. Suspect out of support, and I don't have programming cable anyway.
My TomTom VIA 280, bought new about 5 years ago, failed. It thought the time was 10:00am all day and calculated my position to be about 30m (at a guess) from where I really was, so depending on the direction I was travelling it spent most of its time recalculating.
To be fair, TomTom sent me an email warning me it would fail, but I preferred to watch it happen.
Anyway, I’ve since updated the firmware and it works again, but that’s a lesson for Matt about claiming that “a fix has been available for ages, so there’s no problem”. Proposed fixes are only useful if they’re implemented and tested.
I can predict a lot of "Parker audio" jokes
It'd have to almost work for that.
His accent. hmmm.... . What's a " 'working' holiday" ?
Parker Saturday
The term is Parker square audio. It's not just Parker.
Matt's audio crashed more than the GPS
Ah yes, the good old garmin etrex. Also still got this beauty. After long times of no battery it can take up to half an hour to find proper satellites. Nice to know it would still work.
Frotty Zaoldyeck Search for time-to-first-fix.
Frotty Zaoldyeck I still have mine that I bought in 2002. I use it very regularly & it still works perfectly.
I have mine too but I haven't looked at it in over a decade! Oh the memories!
The fact that it displayed the 21st August 1999 (the last day of the first epoch) on the 6th April 2019 (last day of the second epoch) suggests that it is doing some sort of windowing on the date which is another reason why it didn't "crash". This was a technique developed for Y2K, as one of the ways of fixing the code. Basically, instead of going chronologically from week 0 to week 1023, it moves the earliest date to a different week. I strongly suspect that it has a piece of code which says "if the week number is greater than [a particular number] then the date is in the first epoch, otherwise the date is in the 2nd epoch". the copyright date says 1999 - 2002, which suggests that the code was originally written in 1999, so my hunch is that the code says "if the week number is greater than 999 then it is the first epoch otherwise it is the second epoch".
Though if it was going to crash, it would probably have crash at exactly midnight between 6th April and 7th April, when one satellite would be sending a first epoch date and time and another satellite would be sending a second epoch date and time, rather at some random point during the day on the 7th April when both are sending times from the same epoch
The GPS epoch is still defined as 00:00 UTC, 6 January 1980. As such, the 13-bit CNAV week number can be thought of as being a 3-bit "LNAV epoch" number (with 0 being the first epoch) followed by a 10-bit LNAV week number. For example, 12:00 UTC, 7 April 2019 is in the first week (LNAV week number 0) of the third "LNAV epoch" (epoch number 2), so the CNAV week number in binary is 010 0000000000.
Mr Parker: Let's go on a hiking vacation to Isle of Wight.
Mrs Parker: Yay!
Mr Parker: I'm just gonna play with my 13 year old GPS for a video.
*I did not notice this dog...or this dog.*
Mr Parker: Lucy... Lucy? Luuucy?
So the L5 (CNAV) GPS signal uses the same 1980 epoch if I understand correctly. IS-GPS-705E “20.3.3.1.1.1 Transmission Week Number.
Bits 39 through 51 of message type 10 shall contain 13 bits which are a modulo-8192 binary representation of the current GPS week number at the start of the CEI data set transmission interval (see paragraph 6.2.4 of IS-GPS- 200).” In IS-GPS-200J “6.2.4 GPS Week Number.
The GPS week numbering system is established with week number zero (0) being defined as that week which started with the X1 epoch occurring at midnight UTC (USNO) on the night of January 5, 1980/ morning of January 6, 1980. The GPS week number continuously increments by one (1) at each end/start of week epoch without ever resetting to zero. Users must recognize that the week number information contained in the Nav Message may not necessarily reflect the current full GPS week number (see paragraphs 20.3.3.3.1.1, 20.3.3.5.1.5, 20.3.3.5.2.4, and 30.3.3.1.1.1).” Sources: www.gps.gov/technical/icwg/IS-GPS-705E.pdf#page59 and www.gps.gov/technical/icwg/IS-GPS-200J.pdf#page59
How bored must you be to do this
@@kuro13wolf Not bored, just curious. And _maybe_ typing all of that out would be boring, but I'd bet money that @Jeremy Mayeres just copy-pasted it.
So: Not at all. Of course.
Very fine, then the first 8192 week epoch ends on the midnight between January 5th and 6th of 2137. Funny coincidence 7*8192=57344 is just .25 off 157*365.25 and just ~1 day off 157*365.2425 = ca. 57343
Do mobiles get GPS directly from satellites or via their internet connection? If the latter is the case I fear you (or some Parker grandchild) won't be able to use any of today's phones to make that same rollover check again.
@@OlafDoschke They use internet-assisted GPS. Basically they use the internet to download the orbital parameters of the satellites, so they don't have to wait until they receive it from the satellites themselves (which, as shown in the video, takes forever).
They can still function without internet though, it just takes much much longer to acquire a gps signal.
@@demoniack81 Thanks, that (especially the second part) explains to me, why you would call GPS a feature of a phone. When it would just get GPS data from some server and not have receivers for the GPS signal itself, that would just make it a software feature of being able to interpret the GPS data. And it couldn't work that way as servers have static locations and not your location. The way it is, explains why it can be instant, as it instantly knows GPS satellite positions and also works without an internet connection, albeit slower when it needs several minutes to get exacter satellite positions.
This is good to know. I have the same GPS and I'm happy to find out that it should work just find... just not the date of sunrise/set times which is not a deal breaker.
The reason It took soo long the first time to gain a signal is because it has been so long since you used it, and you likely used it a few hundred kms away from last point of use.
So, dropping your audio phone in some water is a Parker mic drop?
And given where he was at the time, that would be known as a Wight wash.
denelson83 Parker wight wash
Most phones are rectangular, so that's kind of like a square, or a Parker Square.
@@buddyclem7328 Haha! Parker Square. That's a good joke. But not perfect....
"Locating satellites" :-) I remember my old eTrex Venture I used for geocaching. It took easily several minutes to find the location, even outdoors in completely open area. But it didn't matter, those good old, slow paced times.. :-D
Matt Parker: Remembers to take batteries out of electronics for long term storage.
Me: *R U A GOD??*
Adding extra bits to the time signature just sounds an awful lot like the Futurama global warming solution of putting a bigger and bigger ice cube into the ocean every time temperatures get out of hand, thus solving the problem once and for all.
But...
ONCE AND FOR ALL!
The thing is, MAYBE in the past few decades we've learned to do better, but in a lot of currently live systems, the IRS for example, modern applications and interfaces are patched into old hardware, or old software running on emulated hardware. While 157 years is a long way off to us, now, I can definitely imagine a case in the 22nd century where some legacy system relies on our present-day CNAV standard, and is going to have trouble with the rollover.
In consumer devices, probably not a big issue. Consumer devices go in the bin when a shinier one is released, anyway, but with more and more services moving to cloud servers, I can definitely envisage some descendant of Gmail or something being reliant on spaghetti code and legacy hardware standards.
@@NoobixCube Forget CNAV, I'm waiting to be defrosted from an ice cube in late 9999 along with millions of other developers only for someone to tell us we have a few months to fix an ungodly pile of databases and assorted supporting software which handle dates as a YYYYMMDD character string...
I was surprised they didn't decide to just use a 64-bit timestamp (or a 64-bit integer with the current week, if seconds aren't a precise enough measurement.) 64-bit numbers are what's typically used for time nowadays, and will last so long they wouldn't overflow until after the supposed heat death of the universe, so there would be no argument to be had at all.
150 years is better than 20 but when you can get exponentially more time by adding just one bit, and considering this was in 2008 when the idea of a 64-bit number wasn't too outlandish... it seems a bit silly not to take advantage. Bear in mind the Y2K problem started in the 60's or so when it seemed unlikely the same tech would be in use a century later. 150 years isn't even two centuries from now.
I have the exact same GPS unit. I bought it around 2006 to log locations to do geolocation for my DSLR.
You helped me with some maths for my dissertation 8-9 years ago. I was working in the press office at Assembly in Edinburgh where you had a show. I got a 1st, thanks!
5:20. Matt: “I am recording my dialog”.
?? When Matt is speaking it is almost an unstoppable monolog.
Those old simple Garmins are rugged and reliable as hell. I've dropped my little tiny Garmin eTrex 10 down rocky hillsides numerous times, and it's always kept chugging just fine. And it does indeed work today after week reset. Well designed little thing.
This leaves me with 2 questions:
1. Why 13 bits???
2. Why this stupid system with weeks?? My calculations show that the 10 bits would have done better work alongside the already needed 20 bits for measuring seconds into the week. With 30 bits for seconds since 1980, the rollover would be 34 years. For completeness sake, adding three bits to that would increase the range to 272 years. Alas, weeks are simply stupid
Our entire Gregorian calendar is the most stupid and archaic system! We should have 13 months with 28 days each, and January 1st should be numbered "zero" and occur on the winter solstice.
For your second question: Weeks are used for the receiver to predict the location of the satellites. The satellite doesn't give out its own exact position. Instead, we take its initial position, velocity, and acceleration (which we know is accurate at the time of measurement) and save that. The receiver then predicts the motion of the satellite based on those initial conditions and the satellite's known orbit. That prediction is used to calculation the position of the receiver BUT it is only accurate for about a week after the first measurement so we need a new set of measurements for position, velocity, etc. The choice to use weeks isn't about computer space, it's about measurement accuracy.
I was a really early adopter of GPS. I had a Lamar attached to a laptop in a fixed station in my truck. God how I remember those long weights for for that third and fourth satellite. I don't miss it one bit.
Joseph DESTAUBIN There's your problem right there! The receiver should have been outside the truck...
@@gordonrichardson2972 Actually, the biggest problem was that the maps were rarely adequately accurate.
An interesting thing to do would be to film the GPS date and time (to the second) around the time the next leap second is inserted into UTC (Usually on the last day of December at midnight UTC) the clock should show 58,59,60,00 seconds rather than the normal 58.59,00 however many systems have problems with coping with leap seconds . You need to be careful about your reference time as that may be off by 1 second for a period before or after the leap second. Time is wonderful when we get an extra second in UTC ! Of course the number of seconds in GMT remains the same for every day but the length of the second changes compared to UTC seconds !
When I saw your GPS I thought "That looks familiar"
And then you turned it on and I was the guy walking around and the satellite connect screen and I realized - my parents own that GPS!
I used it when I was like 7! This video has been pure nostalgia.
I used to love those animations XD
Garmin announced that legacy units would only get the time and date wrong. The positioning functionality isn’t affected. If you want a GPS that crashes, try Garmin’s current handheld, the GPSMAP 66S, or 66ST.
I also happen to have a yellow eTrex Basic as well, and got inspired to pull it out for a spin this weekend after watching this video first time shortly after upload. As soon as I turned it on, it started counting at January 2012, and after some time to catch up it shows the correct date. Software version is 3.5, so it appears the unit in the video is a few versions behind.
But the content of the video is still rather important, as this will happen across a lot of other devices that will not have software updates available. For instance, this video explained something I've been twisting my head around for a long time. My old Garmin nüvi car GPS seemed to malfunction a few years ago and always show the wrong date, and even Garmin customer support wasn't able to explain this.
It seems to me that Garmin had actually coded week roll over into the device, because the copyright statement on its screen says it was released during the first roll over. It assumes that big week numbers at the end of the epoch belong to epoch 1 instead of epoch 2.
I actually have that same GPS and still use for field work in Montana. Good to know it will still work.
Global Parkersitioning System.
It was a Parker location.
I like to think you have dogs following you around all the time, but you never notice they're there until you video yourself.
Lycoris Sound Dogs navigate by smell, not GPS...
@@gordonrichardson2972 o... k...
Parker's dogs. They are there and they are not there until he films himself to find out.
@@error.418 I'm getting weird "UM ACTUALLY" vibes from Gordon.
@@General12th it do be like that
Since the signal is never required to store an old date this would mean a device would never be required to decode a date before its manufacture.
So if a device was manufacturered 1 year before the binary rollover, it may have be coded with an offset such that the displayed rollover is much later. So your device may have displayed the correct date for quite some years after the last binary rollover
Was worried about my old handhelds. My own tests proved they were still bunny hopping along. Good to see your confirmation. Thanks!
My Garmin GPS from 2007 worked fine on Saturday, the day of the roll-over. It worked again when I turned it on at home on Wednesday. But then when I turned it on again at the start of my skiing trip, it could not get a position. Even after it had locked on to 11 satellites, it still had no idea where it was. Fortunately, *I* knew perfectly well where I was, I just use the GPS to tell me how far I have skied. Strangely, it was OK again next morning.
Bjorn P. Munch Interesting! Sounds like bad software.
3:08 - That's what's known as a GPS "cold start". It has to download the entire almanac and all of the ephemerides from the visible satellites.
3:49 - That's Brading railway station.
5:25 - Did you ever think to talk to Louis Rossmann about your water-damaged phone?
denelson83 Yes. Search for time-to-first-fix.
IoW is a beautiful place to go walking. I used to love hiking along the cliffs around Sandown as well as other parts of the island (whose names have slipped my memory) years ago. Hope you had a wonderful time there!
plane carrying our basketball team lost nav during this, probably because of this. 72 hours later it was still grounded. looks like it made some diving or something too. could not land back in the same airport due to weather, it was misalign on mutiple retries. it landed on another one, guess that one had better visibility for visual approach.
Matt Parker: time traveling maths comedian
A few things to add, some receivers used in commercial use (like in older planes) already had a solution to this, keep a record of previous week number if new week number - previous week number is negative (one can even ad a threshold for how negative) then one updates a counter as to what epoch one is in, and this whole issue goes away however this does require some persistent storage to store counter and last received week number.
I do wonder what the TomTom reports, as it was TomTom that was pushing the buy new GPS narrative.
I love your inner peace with the audio challenge you had
Thanks for your interessting test. I did test it on saturday, when it was supposed to still work :-)
Renault TOMTOMs (built in at least up to 2015) needed a software update. They built the update in July 2018 and notified customers in March 2019 :-(
The clifftop footpath between Sandown and Shanklin, to answer your first location query ;)
Sandown pier clearly visible in the background there.
main takeaway here is: if you stare at screens all day you miss all of life's dogs
honestly not noticing the dog was the biggest tragedy of this video, not anything to do with integer overflows/rollovers
Thank god for screens
Well done sir making do with what you had. I don’t mind a little bit of terrible audio from time to time. The content was worth it. And your ‘redo’ of the first part with no audio was pretty impressive. The timing with the cuts was great and the whole thing was rather enjoyable and funny how you handled it. :)
Thanks for the great video! (I wonder how many things I have that I haven’t used in over ten years... plenty for sure!)
The company I work for also builds and sells GPS clocks for special purposes.
In the weeks before the rollover, I got only a few requests if our clocks are prepared for this. Of course, we had resolved this already years ago and so far I have no reports of problems with our clocks after the GPS week rollover.
But it needed this video for me to check my trusty Garmin Dakota 20 that I use for hiking. I bought it in 2010, so theoretically it could have been a candidate for being affected. But I also kept the firmware current and the latest version was 5.80 from 2014.
There are no issues with the week rollover with my Dakota 20, the date is correctly calculated.
I just fired up my Garmin GPSmap 76S, circa 2002. It took a while to cold start - unsurprisingly - but showed the date just fine. Once I had set the time zone the time was fine too. Nae problems.
I've got the same model, a 76S, and it handled the rollover just fine too.
OK, I just turned my old Garmin eTrex Vista (bought in 2007) on. It too said it was August 1999 when I turned it on. However, having had it on for a few minutes, it has corrected itself to 13 April 2019. So not sure if I've updated the firmware / software somewhere along the line that might have fixed this - or if it's getting a correction from somewhere else?
The exact date and time are transmitted by the GPS satellites, but the week number is downloaded first, so that is probably what you saw happen.
Given that it rolled into the second epoch when the week number reset, I suspect it knew that it had gone from a large week number to a small one, took that into account and so kept moving forward.
Chances are if you'd had it turned on in August 1999 it would have been corrected at the time, and thus have been accurate going into the third.
When you doing a cold start you shouldn't move the unit for the first 12 minutes so that it can download the almanac.
Actually, it doesn't take nearly as long to download a complete almanac after a cold start. Not all the GPS satellites are transmitting the same piece of the almanac at the same time. The transmissions are staggered so a GPS receiver can obtain many parts of the same almanac at the same time.
My understanding is that the GPS picks the date that is closest to the manufacturing date of the device. So it "picked" the end of the first epoch because it was closer which is why is said 99 even before the second reset
But did you Make A Shape Out Of The Things You Found Around The Place You're Staying While On Holidays?
u didn't capitalize DID YOU
But don't you need to know the location of the satellites in their orbit to use the timing differences to calculate your location? And don't you need to know the time to know their location? or do they broadcast their own position ?
arrow in my gluteus maximus Both methods work, but the GPS satellite data rate is very slow (1500 bits per second), so it takes a few minutes to download the almanac after a 'cold' start.
Every summer we can rent a cottage
In the Isle of Wight, if it's not too dear.
Lyrics from "When I'm 2^6"
Will you still need sticks,
Will you still need bricks,
When I'm 2^6?
On a side note, virtually all "GPS" receivers these days actually use not only the US GPS, but also Russia's GLONASS, China's BeiDou-2/COMPASS and Europe's Galileo system.
Edgar Brucke True. And the mapping function is not GPS, but an entirely separate package. The satellites do not trasmit the maps!
I really enjoy your videos. Thanks for the educational laughter!
I love how the text on screen changes in sync with the devices when you compare the coordinates.
2:54 One satellite. HAHAHA.
Two satellites. HAHAHA.
Pierre C. 😂 He’s Count Von Count
Me: Why not just store a variable telling which Epoch we're in?
Me later: Well, what do you do when the Epoch counter overflows?
Me: We add an Epoch-counter-epoch (or an Epoch-counter-counter, or Epoch-epoch-counter?)
G. W. v Leibniz: I think you just independently discovered* counting in different bases, just a blink of the eye too late for fame and recognition. I hate when that happens! Maybe come up with some jazzy notation?
I thought of that too, but that's literally just adding another bit to the number. Which is what they did. Three of them in base two, to be exact.
(Also, it would be epoch-counter-counter. It's counting the epoch counter.)
My similar eTrex works. Startup screen shows (c) 1999-2002. SW version is 2.14. It was last started in 2011 and as soon as it found the satellites it started to show correct date&time.
Your new book arrived, thanks Matt 👍
I like the way you still used the video and remade the audio :)
My commitment to real video! I wanted to use the actual footage and location data from the day (and not re-film on a different day).
I had your music stuck in my head for some random reason and the intro of this video helped finish it :D
I recently pulled out my Etrex Legend to get back into Geocaching and then read about the epoch issue and thought it would be bricked, but mine did the same thing and I'm good to go.
On top of banks and stuff a lot of scientific instruments also use GPS for timing, basically anything that needs to be synchronized. Like I guarantee the telescopes used to create the black hole image were coordinated using GPS time.
Daniel Jensen can you give some details about how GPS timekeeping was used for the VLBI calculations to create the black hole image? I’m under the impression that GPS was *not* used because it’s not precise enough. GPS clocks are only stable to about 10^-9s on a 1s basis and 10^-14s over 1day, whereas H-maser clocks as used at most radio telescopes for local timekeeping are stable to 6x10^14 at 1s, so while GPS may be used for traceability to UTC it’s not sufficient for the actual data collection.
I freely admit that I’m not up on the latest VLBI techniques and am genuinely interested to know more, so if you can expand on your comment I’m interested.
@@jpe1 You are partially correct, but actually the best time keeping is done with a combination of both. Basically Hydrogen mazer clocks (or most cesium/rubidium/quartz oscillators) are more accurate in the short term (seconds/minutes, usually hours), but they will eventually accumulate small errors and drift apart. GPS time on the other hand is less accurate on a second to second to second basis, but it has been designed to self correct so that it doesn't drift. So typically over days, and definitely over weeks/months/years GPS time is more accurate. There are different ways of doing it but basically the idea is that you periodically want to correct the drift in your oscillatior clock with GPS.
I don't actually know the exact setup they are using, but I'm a graduate student designing basically a lower frequency version of a radio telescopes array, except that we use it to look at lighting. So I spent a year or two researching timing synchronization like this before I concluded that GPS alone would be much simpler and good enough for what we're doing.
Daniel Jensen fascinating! I’m jealous for the cool research you are doing. Years ago I dug pretty deep into the inner workings of NTP (network time protocol) but I have to admit not only have I not kept up but I’ve forgotten much, but using GPS to correct the drift in local atomic clocks makes perfect sense.
I would have loved to see a navigation system that produce a convoluted path for a short distance because it makes you arrive on the day after. Which is in the past.
Basically: "Take this path, it brings you to the 90's".
Even in 1999 it was pretty much a non-issue - tuning up for Y2K issues sensitized a lot of people to it and many GPS receivers (or client equipment) had volatile or non-voliatile storage flags to indicate a new "epoch" and would self update - possibly needing a cold start. Receivers built since then mostly are able to deal with it even w/o the updated (13 bit week) specification. That said, my old TomTom, despite a s/w update, failed to work properly. (It received sats but could never resolve a position - I bought that around 2008).
To all the GPS, navigation, and map nerds in UK I advise you to visit Iford (just East of Brighton).
You can also visit hilly area just NE from Herbesetin in Spain, and rural areas East from Bakpoli in Ghana. :)
Now I gotta dig out my old pre fix GPS and check it out.
would there be a tiny chance that if somethign received location just during the exact fraction of a second the rollover happened it would get messed up location data because it receives one satellite as rolled over and the other as not yet rolled over?
though I guess that would get you unsovlable location data
Tracking time in computer systems with the GPS may not need the correct date returned by a receiver. What is most precious for such systems is the PPS (pulse per second). Once you've got it implementing a counter outside of a receiver is trivial.
I do love looking at the standards being set up in technology and the investigations about what happens when those standards are eventually broken. Thanks for this video. I was just barely old enough in 1999that I remember hearing people talk about how the GPS system was going to crash and how it was going to be Y2k part 1. And then... nope. If you want to do some video about Y2k from a historical perspective, I'd love to see it now that I'm an actual adult and more able to understand the implications.
In case you are not aware, a similar issue will then happen at "03:14:07 UTC on 19 January 2038" for computers too, quite similar to what this video is about, but instead with the internal signed 32bit timer in all computers run out at that time
It looks like Lucy disapproves of Matt's internet life.
That satnav you promised to...turn on...for your Patreon followers - I still use one every day for work. £20 on ebay. It's not like roads change that much. This does explain why it stopped keeping the time earlier this year.
Garman has a Windows 98 utility that lets you reset the clock to the one from the computer, then as long as you keep batteries in it the time will be set correctly from GPS.
I have a much older Garmin GPS-89 unit. I took this unit to New Zealand in 1997 and Australia in 1998, and it has never had a firmware update. It has been powered off more most of the last twenty years. A few weeks ago I pulled it out and put new batteries into it, and it works just fine, and the time and date are correct. It took the better part of a half-hour to get GPS lock, but otherwise appears to be working correctly. I've no idea if/how it compensates for GPS time/leap seconds, so it might be a second or twelve off...
I think my dad might have had a Trex model GPS. That screen for when it is locating satellites looks really familiar.
I remember when handheld GPS blew my mind. May I live long enough to be mind blown again.
Actually this made the video more interesting. Got an insight into how much we're connected to technology. And also shows that the little built in microphone in the GoPro doesn't match the video quality, hence why people use a separate mike and mix the audio later on, and why some videos on UA-cam therefore have syncing issues. It's all coming together....
What happened when you remove the battery and put it back?? Will the time reset and back to the first epoch??
I waited more than 4 minutes for this video's load of Parker happenings. In the end however this didn't disappoint.
Happy New Epoch!
It should be easy to find out which GPS epoch we are in simply by asking the user what's the current date. Even if they enter the date wrong by a few days (or even a few years), the device would be able to correct it using the info it's getting from the GPS satellites
We still use this same model of GPS tracker )). So many kilometers done with this little thing.
I've got the exact same model somewhere in a draw in the house. I'm going to find it and confirm your findings :)
I do software development for aircraft. We had to do some updates for aircraft that didn't handle this correctly a few months ago. Was an interesting upgrade. GPS was still accurate but time was an issue as you saw with your unit.
Pigeoncraft Honeywell GPS units on the B787 gave incorrect date information. Some flights were grounded for updates.
Oh man, I can't WAIT to play some Command and Conquer while listening to Alice Deejay on this wonderful day of August 29, 1999!
You should see if the date on the device changes when turned on and off after a few weeks, because some devices go to an manufacture date because they cant keep up with the date
7:04 - The roll over has caused *real trouble.* The third decimal has disappeared. Third decimals has been replaced by fourth ones so some how *fourth decimals has rolled over the third decimals!*
I thought the concern was at midnight on rollover day when the difference between any two signals could very briefly be very large and would (again briefly) confuse a satnav.
strange so see an Etrex Yellow in such prestine condition. Mine looks beaten up like ran over by a car... multiple times. How did you keep the screen and rubber in such shape?
You can also read those extra 3 bits as the epoch number. Extending it to only 8 epochs.
You ideally don't want to be moving if you are waiting for satellites for the first time in a while as it takes a while to download the almanac and if it gets interrupted, you have to do it all over again (though maybe newer devices work around this now).
Chaos Corner Much less of an issue with newer receivers, which are multi-channel, and can process several satellites simultaneously.
@@gordonrichardson2972 They've definitely come a long way.
When they go wrong, the results can be surprising. Last year during the O2 network outage in the UK, about 30 million mobile phone navigation units failed temporarily, due to missing A-GPS data initialisation.
@@gordonrichardson2972 Oh, that's not good. You'd hope they would only use that stuff as an optimization and be able to run fully from satellite contact alone.
Chaos Corner True, I'm not sure of the exact details of how many were affected. Probably a bug on some receivers which didn't validate the A-GPS data, or kept waiting forever for a download. In theory it could be worked around by switching off mobile data, but many people have no idea how to do this. Dependency on technology.