[HN Gopher] 2021 GPS Accuracy Issue Impacting Some Garmin, Suunt...
___________________________________________________________________
2021 GPS Accuracy Issue Impacting Some Garmin, Suunto, other GPS
Devices
Author : dll
Score : 216 points
Date : 2021-01-03 08:02 UTC (14 hours ago)
(HTM) web link (www.dcrainmaker.com)
(TXT) w3m dump (www.dcrainmaker.com)
| tomglynch wrote:
| Can someone reply to me when a root cause is found :) Thanks
| SftwreEngnr wrote:
| Yes
| ben_bai wrote:
| Human error: somebody sometimes did something they were not
| supposed to do. But they didn't know so they've done it
| anyways.
| swayson wrote:
| I recently read an article (sorry, can't find it now), that one
| of the risks with 5G is that it may adversely impact navigational
| systems. Wonder if this may be having an impact on GPS as it
| grows in market share?
| drmpeg wrote:
| That was about radar altimeters, not GPS. That 5G band hasn't
| been occupied yet, it's still being auctioned (and it's already
| the largest auction in US history).
|
| https://auctiondata.fcc.gov/public/projects/auction107
| mikewarot wrote:
| Auctioning off a public resource like this is a bad idea. All
| it does is effectively tax the eventual public use of the
| resource that was free to begin with, whilst creating niches
| for rent seekers in the process.
| redis_mlc wrote:
| There's also a US company suing (for the past 5 years) to use
| a mobile phone frequency adjacent to an aviation frequency.
| Not sure if the proposed interference was related to GPS or
| not.
| new23d wrote:
| _Tomorrow Never Dies_
|
| So, it can happen.
| rootsudo wrote:
| Use an hackRF, yes you can.
| throw0101a wrote:
| GPS signals are actually quite weak (though will be boosted
| with GPS III satellites), and so can be overwhelmed (and
| jammed):
|
| * https://arstechnica.com/information-
| technology/2013/07/profe...
|
| The USN has brought back celestial navigation (sextants) as a
| backup mechanism in recent years:
|
| * https://www.npr.org/2016/02/22/467210492/u-s-navy-brings-
| bac...
|
| US is examining backup systems for GPS/GNSS, including bringing
| back (e)LORAN:
|
| * https://www.defenseone.com/ideas/2020/12/we-need-backup-
| gps-...
|
| * https://en.wikipedia.org/wiki/Loran-C
| PoachedSausage wrote:
| I believe it was a mistake to decommission eLORAN (both US
| and Europe), for the reasons you mention. Thankfully we still
| have terrestrial frequency and time standards (although there
| was talk of shutting down WWV).
|
| Now that the UK has been kicked out of Galileo, perhaps the
| government might think about reinstating eLORAN, it would be
| a good use for some the Longwave AM broadcast infrastructure
| that will be surplus in the next 10 years or so.
| throw0101a wrote:
| The UK had a go of it with eLORAN for a while, but no one
| else (France, Netherlands) seemed to have been interested,
| and so it was shelved AFAICT:
|
| * https://www.trinityhouse.co.uk/notice-to-
| mariners/27-15-enha...
|
| * https://www.maritime-executive.com/article/europe-gives-
| up-o...
|
| South Korea is having a go at it:
|
| * http://www.digitaljournal.com/tech-and-
| science/technology/sh...
|
| A government or three (NATO?) have to decide on a system
| (eLORAN or other), publish standards, and buy a bunch of
| equipment (transmit and receivers) to kick start things.
| jaimex2 wrote:
| Definitely not a glitch you'd want on missile targeting software.
| alinspired wrote:
| I might have run into this on a few systems, which started
| reporting first days of new year as 53rd week of 2021, instead of
| 2020.
|
| Most systems behave as expected: $ date +%G.%V
| --date="03 Jan 2021 00:00:15" 2020.53 $ date
| +%G.%V --date="04 Jan 2021 00:00:15" 2021.01
| [deleted]
| arpinum wrote:
| More fascinating to me is that Garmin uses Sony for GPS chips.
| Given their long history and penetration in marine and aviation,
| I'm surprised they can't or don't want to compete with Sony. Sad
| if this means Garmin is on the decline.
| nradov wrote:
| Garmin hasn't designed their own wearable devices GPS (GNSS)
| chips for many years. They used MediaTek chips since about
| 2010. Then a couple years ago they switched to Sony for better
| battery life.
| mthoms wrote:
| I think they only use the Sony chips in their watch line up.
| Hopefully someone else can confirm.
| stevehawk wrote:
| They wouldn't be used in their aviation devices, its a
| different type of GPS
|
| https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System
| jcrawfordor wrote:
| A surprising number of consumer GPS receivers use WAAS -
| it's pretty inexpensive to add since the WAAS corrections
| are downlinked as part of a GPS datastream you need to
| decode anyway for ephemeris.
| maxerickson wrote:
| The description in the article makes it sound like Sony came
| out with a much better low power chip. I'm not sure how big a
| factor battery size is for these watches, but they might not
| have had much choice.
|
| I have a Garmin 645 Music and wouldn't get anything bigger to
| replace it.
| imglorp wrote:
| More likely they use Sony for cheap consumer items. Garmin also
| makes high accuracy survey and aviation products which I'd bet
| are custom.
| zackify wrote:
| I went for a run yesterday and the first half of a 5 miler was
| completely offset by a few hundred meters. So interesting to find
| out the cause!
| phkahler wrote:
| I didnt realize GPS devices needed internet access. This trend of
| everything needing the net is IMHO a bad thing.
| lukeschlather wrote:
| I just looked at the gps from my bike ride on New Year's day.
| The GPS is off by about 30 meters at the start of the route but
| corrects itself after about 10 minutes. No Internet required. I
| am surprised it can take 10 minutes for the GPS to get a proper
| lock. I guess it's a power saving measure.
| nradov wrote:
| Yes Navstar GPS and other GNSS constellation satellites have
| limited power from solar panels and thus the almanac data is
| transmitted at a low bit rate.
| cnorthwood wrote:
| I don't think they require it - the data in question allows it
| to optimise startup otherwise it can take many minutes to
| successfully acquire enough data to compute your location
| jonluca wrote:
| I'm not sure they actually need the internet - I was under the
| impression this was a precache of where to look for satellites.
| It'll still find it without them, it just won't happen as fast.
|
| Someone more knowledgeable than can correct me though.
| [deleted]
| eknkc wrote:
| They don't.
|
| Normally, an initial GPS fix takes some time if the device does
| not know about the precise arrangement of satellites at that
| time. It can take up to 15 minutes in case there is no almanac
| data.
|
| Most devices use data obtained from internet for faster GPS
| fixes. They should function properly offline too.
| phkahler wrote:
| >> It can take up to 15 minutes in case there is no almanac
| data.
|
| That sounds terrible and unacceptable these days. Correct is
| often more important than fast. This bug resulted in
| incorrect location and apparently didn't correct itself over
| an entire journey. That's poor design.
| lights0123 wrote:
| If I'm leaving my house to go somewhere that I'm unfamiliar
| with, I will absolutely take a once-in-forever error that's
| immediately obvious over waiting 15 minutes for my phone's
| GPS to resolve--especially since the former will resolve
| itself in the same time that it would take to download data
| without internet assistance.
| labcomputer wrote:
| Well... hop in your time machine and set the date for 1970.
| Tell the designers of GPS that 15 minutes is too long, and
| you expect better from them.
| apaprocki wrote:
| I can't imagine it taking 15 minutes. I used to play with
| serial connected dumb dongles back in 2000-ish. These only
| communicated with my software on the other end of the serial
| cable and a pure cold-start was spec'd at 45 seconds. I
| imagine maybe that figure has improved.
| worewood wrote:
| It's not dependent on the device. The satellites themselves
| send their position data but on a very low data rate (I
| think its just a couple bits per second) so if the device
| doesn't have the data it does take 15 or so minutes. Maybe
| the "cold-start" you are referring to wasn't so cold, it
| may have the almanac data saved from a previous
| utilization.
| eknkc wrote:
| Yeah, there are 3 possibilities.
|
| If there is absolutely no data cached in the device, it
| requires the almanac. Basically a map of all satellites
| in the constellation. Takes roughly 15 minutes because
| satellites transmit data really slow. This data is valid
| for a couple of months so a device can cache it a long
| time.
|
| If the almanac is present, it provices the coarse
| information. The device still requires precise status of
| the satellites it is receiving signal from. Each
| satellite transmits that within something like 30
| seconds. So it would take 30 seconds for a precise fix.
|
| If the device knows everything about the constellation,
| can process the satellite signal immediately and pinpoint
| the location. If you are using a mobile phone, it should
| always be in this state because the required data is
| provided fast via internet.
|
| In case of other devices like offline watches, the
| almanac might be synchronised from time to time when you
| connect it to your phone or computer. And the fix would
| take up to 30 seconds.
| makomk wrote:
| I don't think it generally should for modern devices. They
| generally just throw compute at the problem, attempt to
| acquire every possible satellite at every possible location
| in parallel, and then download all their ephemeris data in
| parallel (which is more precise than the almanac, but only
| available once you've actually acquired the satellite).
| Makes the almanac kind of redundant, and typical
| acquisition time is anout 45 seconds doing it that way
| since the ephemeris data is broadcast much more often.
| jcrawfordor wrote:
| You'd be surprised how many GPS devices never cold start.
| I've worked with multiple serial GPS receivers that stored
| the last solution in nonvolatile memory as a start point.
|
| A quick way to check: buy a brand new one, plug it in, and
| see if it starts offering (low-quality) fixes for Shenzhen
| or wherever it was QAd. Unfortunately some receivers won't
| actually provide NMEA sentences until the quality flag goes
| on, so it's not quite this obvious, but I just recently
| bought an industrial cellular modem with onboard GPS and
| experienced a 30 minute or so wait before the quality flag
| came on and I started getting NMEA sentences. Presumably it
| was busy discovering it wasn't in Kansas any more.
| reaperducer wrote:
| I built a GPS rig for my car from a Palm III, a bunch of
| serial adapters, and a GPS antenna liberated from a minivan
| back in 1999. It took every bit of 15 minutes to get usable
| locks and data. It probably took longer. Sometime I'd be at
| work before the map started moving.
|
| I have a little clip-on geotracker I bought in 2010 that I
| use for cross-country train trips. It takes at least 10
| minutes to lock on, and since it can only be either "on" or
| "charging," but not both, there are long gaps in the tracks
| on the maps.
| londons_explore wrote:
| I used some mid 90's GPS receivers in the military, and
| they could take up to an hour for an initial fix. They
| required an antenna on a pole and cryptographic keys to be
| loaded too (for the unjammable encrypted signal)...
|
| They didn't have maps - you had to use coordinates on the
| screen to look up your location on a paper map... Everyone
| thought they were kinda pointless, because why not just
| triangulate off some hilltops which would take 5 mins
| rather than waiting an hour...
| tjoff wrote:
| Lots of devices take a really long time to do this. Most
| devices have internal battery backup that keep the almanac
| between sessions, at which point it can be really fast. But
| the (admittedly somewhat old) watches I've had get a really
| long time to lock if the almanac is out of date or you have
| traveled a lot since last it was used.
|
| It takes 12.5 minutes for the almanac to get propagated.
| Not sure how much of the almanac you really need or if you
| can download multiple at the same time. But from practical
| experience 12.5 minutes seems about right with the devices
| I've used.
| sokoloff wrote:
| If I cold start a Raspberry Pi attached GPS in an airplane
| moving at 175 knots, it can easily be 20-30 minutes before
| it will determine a fix.
| Too wrote:
| Phase 1: No internet cache, developers optimize for faster
| offline GPS fixes
|
| Phase 2: Someone comes up with smart idea to use internet to
| optimize initial fix. Performance get faster.
|
| Phase 3: PM thinks that offline scenario is not worth
| optimizing for since most users have internet anyway,
| performance and features degrades.
|
| Phase 4: Some developer forget that offline is even a valid
| scenario, device becomes useless without connection.
|
| Phase 5: Company servers broken. Device useless.
|
| We've seen this happen to multiple products. We would like to
| believe that things top at phase 2 but here again i think we
| reached all the way to 5. Useless might be an overstatement
| since it still points somewhat in the vicinity but it
| certainly not working as intended. Do they have some kind of
| meter showing how good accuracy it has so you know when it's
| inaccurate or not?
| matsemann wrote:
| Yes, most Garmins will show bars on connection status
| similar to how a phone does for phone towers or at least
| some kind of status. It will also beep when it has a good
| enough connection. Usually (because of the cache) that's
| only like a second so one doesn't care/notice and may
| easily skip waiting for it in the cases the gps lock isn't
| ready.
| labcomputer wrote:
| > We would like to believe that things top at phase 2 but
| here again i think we reached all the way to 5.
|
| Frankly, I think you're way off base here.
|
| * First:
|
| In an offline cold-start scenario, it is literally
| impossible to compute a first fix in less time than it
| takes for the satellite to send the relevant parts of the
| navigation message.
|
| For Navstar's (the US brand of GPS) L1 C/A (civilian)
| signals specifically, that means you must receive an entire
| frame, which is transmitted once every 30 seconds. So 30
| seconds is the lower bound, assuming you receive it
| correctly the first time. And L2 doesn't contain any ECC,
| so you'd want to receive it at least twice and take a
| majority vote for each bit...
|
| The story is the same for the new L2-CNAV and L1C CNAV-2
| signals (which have ECC, so once is enough), except that
| the repetition rate is every 12 and 18 seconds,
| respectively (but they have lower S/N ratio). If you want
| the entire GPS almanac, that takes a minimum of 12.5
| minutes of airtime for exactly the same reason.
|
| So, the idea that GPS chip manufacturers have already
| forgot how to do offline cold starts is a bit silly.
|
| * Second:
|
| Devices already use cell tower and wifi AP locations to
| make fast, low-accuracy, low-energy position estimates. GPS
| is used specifically in the scenarios where internet
| connectivity is not available and/or when more accuracy is
| needed. I've met a lot of dumb PMs, but I'm having trouble
| imagining a PM who wouldn't understand that _not having
| cell towers available for a gross position_ is one of the
| prime scenarios for powering up the GPS chip.
|
| * Third:
|
| GPS absolutely requires up to date orbital parameters for
| each satellite it's using. Who is going to constantly ping
| the server for up to date ephemerides every 30 seconds when
| the GPS chip can give you them for free? Bandwidth is
| cheap, but it's not free, especially when you have millions
| of devices in the field. The problem with this approach
| would be immediately obvious in testing, the first time a
| device tries to roam across wifi networks.
| codys wrote:
| I'm not sure this comment responds to the parent
| comment's statements very effectively.
|
| The parent comment is primarily about the non-internet
| case becoming uncommon enough that it isn't tested (or
| tested as effectively) as the internet case.
|
| The "first" point here gives some very interesting
| details on the various timing of data necessary for a
| fix. But then it confusingly makes the claim that "the
| idea that GPS chip manufacturers have already forgot how
| to do offline cold starts is a bit silly". This claim
| doesn't appear to follow from the details about the
| offline cold starts. Perhaps some information about when
| these various methods of offline cold starts might help
| support the claim being made, but even then we'd have to
| keep in mind that those introducing new offline cold
| start methods aren't all gps manufs. We should also be
| careful not to discount offline warm starts or offline
| semi-warm starts. (iow: handling various pieces of
| information necessary for bootstrapping and effectively
| using all components possible without, say, requiring a
| full almanac download if a partial had been obtained
| previously).
|
| The parent comment doesn't make a specific statement
| about what type of timing for fix when offline (either
| cold or warm) is reasonable. This makes it a bit funny to
| talk about the minimums/etc for offline cold start at
| all. The general thrust is that offline has become the
| uncommon case.
|
| I would similarly be more cautious in the "second" point
| here for that reason: because of the proliferation of GPS
| into cell phones, I would be unsurprised if the majority
| of GPS devices were in devices that are "online". The GPS
| in those devices is primarily used for fine position
| information. While it's true that it can be used when the
| gross position estimation fails (due to lack of wifi
| signals or cell towers), because of the additional power
| consumption of the GPS radio it is less likely to be used
| for gross position. I would hesitate to describe this as
| a "prime scenario".
|
| On the "third" point, I think we're ignoring that it's
| fairly easy to break offline cold starts (or make them
| very bad) without necessarily breaking ongoing
| ephemerides data. Certainly, it's very possible to break
| both, (given that the data is separate subframes), but
| one could imagine something breaking almanac assembly
| (for example), without breaking ephemerides subframe
| reception/decode/handling/etc.
| unilynx wrote:
| > In talking to another person in the industry dealing with the
| issue, they noted that technically 2020 had 53 weeks, and this is
| the 53rd week. As such, the suspect Sony data file issue might
| actually be tied to that complexity.
|
| Wouldn't be surprised
|
| On a positive note, this is the first year in a row of 4 where I
| _didn 't_ see CI errors related to the year currently being 2021
| but the 'week-year' still being 2020.
|
| (Did find one recent test that hardcoded 2020 instead of just
| taking the current year though, but at least that doesn't take
| any further investigation)
| grenoire wrote:
| Hitting up the classic article,
| https://infiniteundo.com/post/25326999628/falsehoods-program...
| dingaling wrote:
| If Sony are doing anything other than just relaying the current
| almanac then they're doing something wrong:
|
| https://www.navcen.uscg.gov/?pageName=gpsAlmanacs
|
| So it's more likely to be something related to the software
| implementation rather than the data.
| notacoward wrote:
| > the year currently being 2021 but the 'week-year' still being
| 2020
|
| Strava seems to have a similar problem. When I pull up
| leaderboard data for a segment I've just done, "this month" and
| "this year" and "all time" show my result but "this week"
| doesn't. Checking now for three segments, each "this week" only
| includes the part of the week that was in December.
|
| BTW, for any other Strava users here, be aware that it's also
| pretty stupid about years in which you go from one age group to
| another (in my case from 45-54 to 55-64). AFAICT only your
| annual CR gets considered for leaderboards, and if that's
| before your birthday then it'll act as though you've never even
| done that segment in your new age group.
| vesinisa wrote:
| Relatedly, I had my Android phone set to the en-US locale. I
| noticed Calendar was showing 2020 had 52 weeks and all week
| numbers of 2021 were off by one. I changed to en-UK locale and
| the issue got resolved.
|
| Which begs the question: what on Earth week numbering system
| the en-US locale was using? I am not aware of any US-specific
| week numbering system, so it would seem logical for the en-US
| locale to use the ISO system.
| strombofulous wrote:
| First day of the week in the US is Sunday, first day of the
| week in the EU is Monday.
| vesinisa wrote:
| That does not explain it. In US weeks _more_ of W53 /2020
| lies in 2020 than in ISO weeks, but my phone still labels
| it W1/2021.
| masklinn wrote:
| > In US weeks more of W53/2020 lies in 2020 than in ISO
| weeks
|
| Your error is in assuming every week is uniquely
| identified as a week-year, but that's only true in ISO
| week numbering.
|
| In ISO, every week-year is exclusive and whichever week
| contains January 4th is the first of the year, so
| 2020-12-28/2021-01-03 is 2020-W53 and
| 2021-01-04/2021-01-10 is 2021-W01
|
| But in the US whichever week contains Jan 1st is the
| first... and whichever week contains December 31st is the
| last of the previous year. Meaning the same week can be
| _both_ X-W53 and X+1-W01 (aka the US system has
| overlapping / partial weeks at both start and end of
| year).
|
| This is exactly the case this year (and most years,
| really), the week from December 27th (Sunday) to January
| 2nd (Saturday) contains both January 1st and December
| 31st, meaning it's both the last week of 2020 and the
| first week of 2021.
| vesinisa wrote:
| Right, I figured something like this had to be in play.
| But by whom and where is this US week numbering system
| actually defined?
|
| I can see it is probably implemented in Java by
| java.time.temporal.WeekFields#SUNDAY_START, but there is
| no reference to any standard that actually defines it in
| the documentation. Just this (oddly worded) claim: "This
| week definition is in use in the US and other European
| countries."
| masklinn wrote:
| > But by whom and where is this US week numbering system
| actually defined?
|
| I don't think there is any formal definition, it's just
| customary. AFAIK americans don't really use week
| numbering so it's not really a thing. OTOH ISO defines a
| very strict week-based calendaring system.
|
| Anyway SUNDAY_START defines that weeks start on sunday
| _and the first week-of-year needs only contain a single
| day_ , so I expect you can never get the "overlapping"
| information from the JDK, it just considers that W01 is
| whichever week contains 01-01 and forgets about the
| overlapping last week of the previous year, if any.
| vesinisa wrote:
| So, we have the en-US locale returning arbitrary week
| numbers in a system that is not really well-defined or
| even used by anybody - in lieu of using the one and only
| standardized week numbering system. If a person asks a
| computer for a "week number 23 of 2021", the only
| sensible solution in any culture I think would be to use
| the ISO system. Only locale dependent thing should be on
| which "ISO week number" the Sunday falls.
|
| My point is the "customary US system" seems to actually
| have nothing to do with week _numbering_ - or has anyone
| actually heard someone say "23rd week of 2021" or such?
| This system seems to only make sense when talking about
| ordinal weeks in and around the New Year, meaning terms
| like "first week of 2021", "second week of 2021" or "last
| week of 2020". But those are ambiguous, even in cultures
| that use ISO weeks.
|
| In my country ISO weeks are used extensively in business,
| but if you were talking about "first week of 2021"
| (ordinal), I would think you're talking about the week on
| which January 1 falls - same as the "US customary"
| system. But if you said "week 1 of 2021" (cardinal) I
| would understand immediately it as the ISO week 1 of
| 2021, which I know from experience is not always the same
| as "first week of 2021".
| jcrawfordor wrote:
| My experience in the US is that week numbering is used
| principally by finance to keep track of weekly
| operations, which is usually only payroll. So it makes
| perfect sense to me that the week containing Jan. 1
| should always be week 1 - in fact otherwise is rather
| unintuitive. This results in some confusion around the
| new year but this is kind of an intrinsic problem with
| weekly payroll and is one of the reasons that payroll
| closing tends to be a specific and somewhat complex
| process, as the year totals are calculated more or less
| independently from the pay schedule.
|
| Outside of payroll, I have seen very little use of week
| numbers for any purpose in the US. Far more common to
| write "the week of Jan. 18" where the date given is
| typically, but not always, the Sunday or Monday in that
| week. Week numbers are not displayed on most calendars to
| most people would be pretty frustrated if you told them a
| week number.
| jbay808 wrote:
| Especially since, if week numbering isn't common in the
| US, you might only be looking it up when you're trying to
| collaborate with someone in Europe!
| Shared404 wrote:
| > this is the first year in a row of 4 where I didn't see CI
| errors related to the year currently being 2021 but the 'week-
| year' still being 2020.
|
| Wow, kinda crazy to see that exact problem for four years in a
| row.
|
| /joke
| Risse wrote:
| These GPS bugs are fascinating, just last year my Suunto watch
| had a bug where the 1.1.2020 started on wrong weekday (Friday,
| was supposed to be Wednesday)
|
| https://twitter.com/suunto/status/1213128281253392387?lang=e...
| Rebelgecko wrote:
| There was a fun one on the Galaxy Nexus phone where the time
| was off by 12 hours starting in March on leap years
| matsemann wrote:
| As someone that logs to Strava everyday, I've seen a lot of weird
| maps the last days. Not seen anything weird on my FR945 (as the
| author), but many of those I follow have noted it in their
| descriptions of their skiing trips. Their out and back tracks are
| the same but like offset 100 meters.
| cx4life wrote:
| I run (almost) every day around Greenlake in Seattle. I use a
| Garmin watch to track those runs, and sure enough after the 1st
| my route appeared to be not so much around the lake as on the
| lake.
|
| Side note, DCRainMaker is an incredible resource, and has
| dictated every one of my fitness device purchases for the last...
| 5 years? It's awesome they're so plugged in to the device
| landscape that _they_ have a root cause for this bug, while not
| working directly on the fix.
| jhowell wrote:
| > Side note, DCRainMaker is an incredible resource...
|
| Agreed. His thorough reveivews have allowed me to make
| technical purchases with confidence. Most recently in a new
| power meter for my bicycle.
| C19is20 wrote:
| Based on DCR and GPLama, I got the assioma pm pedals and then
| did the MTB pedal mod. DCR also (in effect) got me a new
| wahoo trainer. I also regularly recommend Hambini, Peak
| Torque and Durianrider (everyone mentioned is a youtuber) as
| honest brokers in a very shady world.
| kevin_thibedeau wrote:
| Durian is a problematic person. Best to ignore him.
| Raidion wrote:
| Hambini can be almost too honest. He's obviously a great
| engineer and really knows his stuff, but dang he rips
| people a new one.
___________________________________________________________________
(page generated 2021-01-03 23:01 UTC)