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.
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.
Does this mean he tweeted something “mean” and got on a discord hate list, or is there actually something problematic with regard to paid sponsorships / reviews?
> 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)
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.
> 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.
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."
> 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.
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".
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.
> 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.
No, because it wouldn't match american the expectations of people not using ISO calendars, despite and regardless of weeknumbers not being routinely used by them.
It is an argument that maybe weeknumbers should not be a thing / available in all locales, but not that they should be renumbered to match an other locale, regardless of that other locale making more sense.
But ... haven't we established that the en-US locale week numbering system is not really based on anything sensible. So how the user can have any sensible expectation of what they get as a reply when they ask for a week number?
I tried to research the glibc version control history of how it came to be like this. I think it's completely arbitrary, and at times en-US did use ISO 8601 weeks.
> 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.
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.
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.
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.
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.
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)
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.
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?
> 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.
> 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?
I agree with the general point you're making, but this is wrong. The main benefit to getting ephemerides data is to get reasonably up-to-date orbital paths, you don't need it every 30 seconds.
The GPS device needs to project future paths anyway up to 30 seconds into the future even in the best-case scenario, so it's already making predictions based on past data.
The devices in question were already caching this data for days or weeks. It only became a problem when the server-side data was wrongly generated for whatever reason.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
>> 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.
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.
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.
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.
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.
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
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.
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.
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.
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?
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).
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.
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.