4 ms·

> 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:

> 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 6y ago
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.
avar 6y ago
> 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.

codys 6y ago

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.

avar 6y ago

> 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.