Today (2023-01-15) at around 20;30z over KONRI on the frontier between Northern Argentine (SACF) and Northern Chile (SCFZ) two aircraft crossed in opposite directions.
LPP3126 FL340 - direction NW and UPS1976 FL327 direction SE.
The pilot on flight UPS1976 with XP12 was flying at FL330 according at his cockpit indications.
That is not the first time that happens with pilots flying XP12, so I allowed him to continue flying as is.
BUT the problem was that at the crossing point LPP3126 was BELOW UPS1976 and for a short margin… BOTH pilots concurr on this situation!!!
I think the situation is COMPLICATED to say the least and I would put it here for discussion and review of VATSIM and EUROSCOPE.
The issue highlighted on the post is how XP12 and MSFS simulate temperature and pressure, and how that affects altitudes on Vatsim for ATC and pilots on different simulators.
It’s not really an XP12 issue, and more of an issue of how the altitude is sent to other simulators/radar clients.
The post from Ross suggests a possible way to mitigate it, that was implemented on vPilot last year.
I assume the same idea is planned for XP12 clients, that’s all.
“So with MSFS sending true altitude to VATSIM, and that true altitude does not match indicated altitude, you get the possibility of VATSIM ATC seeing an altitude in your data block that does not match what you as the pilot see on your altimeter.”
This is not the case…MS2020 reporting FL is the same as on the tag.
XP12, on the other hand:
TAG differs about 200-400 LESS than indicated on the cockpit,
It was the case before the fix implemented on vPilot. I had multiple pilots on MSFS with altitudes > 1000ft off what the pilot could see. The fix implemented by vPilot corrected it.
While we wait for a similar thing to be implemented on xPilot, I just add an “Unreliable altitude” to the TAG, and give some extra separation from everybody else, since the issue won’t be just on my radar screen, and could cause a TA/RA.
This should already be fixed in xPilot (beta 40, released on December 18). This is the first I’ve heard that it’s still broken since I released the update. My testing has yielded no issues with the pressure altitude reporting.
If there are xPilot users still sending incorrect altitudes (and they’re using the most current version - beta 43 as of writing), then I need to know. Information such as their aircraft type (and the developer of said aircraft) would be helpful in further debugging. If they can reach out to me on the xPilot Discord, that would be preferred.
Sorry Justin, the original post didn’t specify xPilot, so it could be Swift, and I assumed the update for xPilot was still pending.
Personally, haven’t seen any issues with reported altitudes recently.
Yes, swift pilot client is still suffering from this issue and at present us at swift are almost ready to release a new version that corrects this. It’s a matter of days until you will be able to get your hands on the latest version.
While I could not reproduce problems sim->ATC with xPilot any more, it seems that some select XP12 add-on planes are using different altitudes for their displays/auto pilot systems.
Here’s a report about the FlightFactor A350 for example. I am just adding that here to keep in mind when triaging reports about “wrong altitude”…
++ also ask about used add-on plane (FF A350 seems to be off currently; earlier Zibo versions had problems but fixing coincided with the mid-December xPilot-fix so not sure which side resolved it)
@1215759 has added a new commit for the upcoming beta.44 that might fix the relative altitude to other planes in the sim? That’s great, thank you! I’ve ignored these reports for now until the sim->ATC problem has been solved for all