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
