CLLocation.altitude under CarPlay reports 0.0 with a positive verticalAccuracy, and a second altitude outlier, both reproducible in Apple's Compass app

Question

Created 3h

Replies 3

Boosts 0

Participants 2

Hello,

I'm Greg, the developer of EV Dashboard, an app for electric vehicle owners. I'm extending it with features that help drivers understand their efficiency, including elevation and grade along a drive. It works for most of my beta testers, but two behaviors have me stuck, and they raise the same question: both hand my app an altitude that is wrong by hundreds or thousands of meters while reporting a small, positive verticalAccuracy, so I have no field I can test to distinguish a measurement from a value that is not one.

Both also reproduce in Apple's Compass app on a tester's phone, with none of my code in the path.

A 35-second screen recording he sent me, at the same spot in Eagan, Minnesota, shows Compass reading 889ft (the true elevation, 271m), then 5996ft for about a second, then 889ft again, and then 0ft at the moment the "CarPlay - AirPlay Connected" banner appears. Screenshots attached.

Setup in my app: one CLLocationManager per active scene, desiredAccuracy kCLLocationAccuracyBestForNavigation, standard location updates (not significant-change), authorization When In Use or Always depending on the tester. Elevation comes from CLLocation.altitude, with CMAltimeter relative altitude used to carry a known altitude between fixes.

Case 1: accessory fixes under CarPlay report altitude 0.0 with a positive verticalAccuracy (FB24778173)

On several vehicles, every fix whose sourceInformation.isProducedByAccessory is true arrives with altitude exactly 0.0 and a verticalAccuracy that is positive and constant for the whole session (19.0 on the cars I have traces from). In the same drives, the phone's own fixes read the true altitude, around 1,345m on one tester's route. ellipsoidalAltitude does not distinguish them either: it comes back as the geoid correction applied to the 0 (-16.5 to -17.4), so both fields agree on sea level.

This is not fleet-wide, which is what makes it testable. Other vehicles deliver real altitude on accessory fixes, on the same app build, with verticalAccuracy 9.5 and values that agree with the phone within a few meters. So it appears to depend on the head unit, and an app cannot ask iOS for the phone's own fix while CarPlay is connected.

The Compass recording above is the same behavior in a first-party app: 889ft before the connection, 0ft after it.

Case 2: a fix with an altitude about 1,550m too high

The same tester's iPhone has twice delivered fixes with altitude 1823.8 where the true elevation is about 271m, an error of roughly 1,552m, with verticalAccuracy 30.0 and horizontalAccuracy 5. These fixes report no speed and no course. The same value appeared on two separate days five days apart, at the same coordinates, identical to the tenth of a meter in both altitude (1823.8) and ellipsoidalAltitude (1796.4). Both times it was the first fix after a location manager started, with the vehicle at rest. Every other fix at that spot in his logs, 76 of them across a week, reads between 269.2m and 272.6m, most with verticalAccuracy 3.0. Compass showed 5996ft (1,827.6m) at that spot in the recording, within 4m of the value my app receives.

Because the value repeats exactly across days, it does not look like a measurement.

What I'm asking

Are either of these known issues?
My reading of the documentation is that a positive verticalAccuracy means the altitude is valid, with that value as one standard deviation. In both cases the error is 50 times the stated accuracy or more. Is there any supported way to recognize an altitude that CoreLocation did not measure? Should an accessory that supplies no altitude produce a negative verticalAccuracy, as an invalid altitude does elsewhere in CoreLocation?
Is a fix with no speed and no course a reliable signal that it is not a live GNSS solution, and are cached or non-GNSS positions expected to carry an altitude at all?
More generally, is there current guidance for obtaining elevation along a drive that I may have missed, particularly how CLLocation.altitude and CMAltimeter are intended to be combined, and what to expect from accessory-produced fixes under CarPlay?

Happy to provide traces, the recording, or sysdiagnose for either case.

Thanks, Greg

Answer 1

DTS Engineer OP

Apple

2h

Thanks for the post, this is really interesting when the iPhone is connected to CarPlay the altitude reported is 0! Thanks for filing a bug. However I think is by design as you are getting the values from an external device?

I believe, when an iPhone connects to CarPlay, iOS often defers to the vehicle's onboard GPS. However, the quality of the data sent by the head unit depends entirely on the automaker's firmware. Many head units only compute a 2D fix (latitude/longitude) and simply zero out the altitude in the NMEA/protocol payload sent to the iPhone. So this is not the data from the iPhone is the external device. verticalAccuracy > 0 is the supported way to know if an altitude is valid. When the underlying source a CarPlay head unit or a Wi-Fi database, Core Location passes that lie up to your app.

https://www.apple.com/privacy/docs/Location_Services_White_Paper_Nov_2019.pdf

https://developer.apple.com/videos/play/wwdc2018/213/

Albert  WWDR

Answer 2

gburlingame OP

1h

Hi Albert,

Thank you for the reply. That makes sense -- a 2D fix with the altitude zeroed out would explain what I see. What I can't tell from my side is whether the zero originates in the vehicle's firmware or somewhere in the handoff, and I'd rather establish that than guess.

Is there a way for me to see what the vehicle actually transmits? Are there any logs that capture the location payload coming from the head unit?

I think this is a worthy exploration, because impacted testers have reported that their own vehicle's native GUI (not CarPlay) is correctly reporting altitude -- that may be a 3D fix or it could be terrain lookup approach, I don't know. I would like to rule out something on the transport side from the vehicle to CarPlay.

I have a cooperative and enthusiastic EV owner community that would be glad to send any logs that I request. 😀

One more question, separate from where the zero comes from. While CarPlay is connected, is there any supported way for an app to obtain the device's own GNSS altitude? On an affected vehicle the phone knows the right value and my app receives what CoreLocation passes along from the vehicle, with no way to ask for the other.

Greg

Answer 3

DTS Engineer OP

Apple

45m

@gburlingame

Thank you for your inquiries. I am not sufficiently familiar with external devices, their integration with CarPlay, or the associated log collection procedures. I recommend reviewing the location logs to identify the data source. I invite engineers from the relevant teams to join this thread and provide further assistance.

Albert  WWDR