Ross Carlson

I'll try to remember to do that, but I may not if enough time passes between now and then. You could update it now anyway to reflect how it works in all other VATSIM clients, and in other online networks. (I also develop clients for a couple other networks, and none of them use indicated alt on radar scopes, for the obvious reason that it's not realistic.)

I checked with one of the other pilot client devs (swift) and they derive pressure alt from true alt using local sea level pressure. That's probably what xPilot should do too, to be compliant with the spec and provide more realistic behavior. I've asked Justin about it.

I suppose this kind of thing could easily escape detection during testing because as long as the pilot is setting their altimeter correctly, indicated altitude is the same as pressure altitude above transition layer. And above transition layer is the only time the pressure altitude value is displayed, in ATC clients. Pilot clients only use the true altitude value, for rendering aircraft models in the sim.

I suppose xPilot could derive pressure altitude by looking at indicated altitude and the kollsman window setting?

A little googling suggests that there is no dataref for pressure altitude. If that's the case, I guess indicated alt is the next best thing. It's just not realistic, because if the pilot doesn't dial the right altimeter setting, the controller won't see them at the wrong altitude, and it'll affect where other pilots see them, too.

Yeah, so that's a bug in xPilot. You can even see that he's storing it in a field called AltitudePressure.

Which field in the data packet are you referring to here?

I'm the developer of several of the VATSIM clients (vPilot, VRC, vSTARS, and vERAM) and it works as I described. Note that vPilot is only for P3D/FSX/MSFS, so I can't speak for the developers of the various clients that work with X-Plane, but if they are sending indicated altitude instead of pressure & true altitude, they are going against the VATSIM protocol specification. And it seems like we would have noticed issues way before now. I know for sure that the xPilot client is sending two different altitudes because I can see in the data stream that the two fields in the data packet (true alt and pressure alt) have different values. (I can't say for sure that one of them isn't indicated alt, but as I mentioned, that would be a violation of the protocol spec.) I was watching a couple pilots today when I was trying to track down reports of a similar issue with MSFS. I noticed a couple X-Plane users who were several hundred feet off of their cruising altitude on my radar scope. They were both flying the Challenger 650. I watched their data packets in the stream of data from the server. (One of them pointed me to this thread.)

A slight correction on this ... online clients don't send indicated altitude. They send both true altitude and pressure altitude. Other pilots' sims will render your aircraft at the true altitude. ATC radar clients will display your true altitude in your data block if you are below the transition layer. If you are above the transition layer, the ATC client will display your pressure altitude in the data block. If I'm understanding the the 650's more realistic altimetry simulation correctly, then it should only affect what a controller sees if the aircraft is below the transition layer. Above TL, the controller will see your pressure altitude, which should match your indicated altitude, assuming you have set 29.92/1013 in your altimeter, as you should when flying in the flight levels. (Once the bug discussed in this thread is fixed, of course.)