Lucius wrote:
When I saw the discrepancy, it was in a pressurized airplane. Since iPad Mini 4 has a pressure sensor it is conceivable that the pressure is used to augment, or cross-check the GPS altitude.
That makes sense.
Peter wrote:
However, nobody seemed to know the exact answer as to how GSM is used to assist a GPS fix, and how much SIM functionality is required.
The main thing is that the GPS and LTE / GSM functionalities live on the same chip. You don’t have one without the other. I don’t think (but am not sure) that a SIM is actually required.
172driver wrote:
The main thing is that the GPS and LTE / GSM functionalities live on the same chip. You don’t have one without the other. I don’t think (but am not sure) that a SIM is actually required.
Usually the SIM isn’t needed for access to the GPS chip.
Also, if there was no access, there would be absolutely no fix whatsoever. (Unless Harry Houdini himself designed it…)
Lucius wrote:
When I saw the discrepancy, it was in a pressurized airplane. Since iPad Mini 4 has a pressure sensor it is conceivable that the pressure is used to augment, or cross-check the GPS altitude.
Looking like a prime suspect right there…
Next test: throw it out the window with a string and see if it holds altitude correctly :)
172driver wrote:
Interestingly, mine shows the correct altitude when I’m sitting at home and am connected to WiFi. How that works, I have no idea…
The main thing is that the GPS and LTE / GSM functionalities live on the same chip. You don’t have one without the other. I don’t think (but am not sure) that a SIM is actually required.It’s not.
When I saw the discrepancy, it was in a pressurized airplane. Since iPad Mini 4 has a pressure sensor it is conceivable that the pressure is used to augment, or cross-check the GPS altitude.I frequently follow the flight’s path on SkyDemon while on intra-Europe flights (flight mode cuts all emissions but not GPS reception), and on the ground it is never 1800ft off.
SD does have an indication of the GPS accuracy. Does FF or the other GPS apps you tested show it as well?
Was it a permanent or transient issue? Remember it take 12.5 minutes to receive the full GPS frame. Hence the long time to acquire a position when you power on a GPS receiver far away from where you last powered it off. Or when the internal battery dies in even a certified GPS.
I find an error of 1800ft too large, even for in iPad GPS. Most likely it has to do with the signal reception. Either your iPad internal GPS antenna isn’t working correctly, or your iPad is located in a position during flight where it doesn’t receive the signals necessary for a lateral / vertical fix. You need at least 4, better more satellites in an even distribution across the sky, and you need their signals error corrected. And there are lot of errors possible. These devices just don’t cut it. After all that CBIR radio nav theory that’s one of the things now clear to me.
EuroFlyer wrote:
Most likely it has to do with the signal reception.
If this were true, the location service API would likely not return and indicate “High Accuracy”. I did another flight in an un-pressurized plane, and the vertical inaccuracy did not reproduce. This suggests that the iPad Mini 4 pressure sensor may indeed be used for integrity checking and augmenting the iPad’s altitude solution. This would also mean that GPS altitude could not be trusted in a pressurized airplane, despite indicating “High Accuracy”, say in ForeFlight. It would be good to know if pilots in pressurized airplanes are able to repro.
That would be a really crappy GPS implementation however, because lots of people are likely to use an Ipad on an airliner.
But perhaps if it is 1800ft off, none of them will notice. That’s quite funny 
Never seen that problem with altitude with an iPad mini or pro in a pressurised plane.
Yeah, I can see them using sensor fusion in the iPad… easily.
Deriving altitude changes from Barometric pressure is incredibly precise, even if not accurate. That’s why most avionics were based on them for 100 years…
If that’s true though, there should definitely be an option or a SW switch somewhere to disable the baro sensor.
If I were writing a navigation algorithm, I’d use Baro input in a Kalman Filter for smoothing altitude readouts. Makes sense to me.
But if written incorrectly, it could result in a lock-on to the baro input, which would give this result.
Longshot, but possible.
I’ve been playing around with an new iPad Mini 4 (on the ground, in a car) for a few days now. I haven’t checked the altitude error carefully, but definitely less than 100 feet.
I recently changed from an iPad 2 to a 4. The 4 has a baro sensor, the 2 does not. The 2 always gave me correct altitude, pressurized airliner or own plane. But, no baro information. I haven’t tried it on the 4…..
