Client PFD altitude

[JP59]

Hello Hardy,

After weeks of trying to understand what's wrong with my PFD indicated altitude, I found something interesting. In my cockpit, the PSX server is aside of the flight deck, so I never look at it during the flight. But today, I don't know why, I had a look, and discovered my issue may be network related.

Flying since about 8 hours, without any problem, at 38000ft cruise altitude, my CPT and FO PFD indicated altitude suddenly jumped from 38000ft to 37060ft. PFD client's flight director bars command a pitch of +7°, but aircraft attitude stays at 3°. Still on the PFD clients, flight commands display at the top left of the screen shows the control column fully aft, but nothing moves on the client. It stays locked at 37060ft. In my cockpit, PFD's are displayed with 2 PSX client sessions running on the same computer (netStart feature).

So I had a look at the PSX server display, and discovered that PFDs indicated 38000ft ! Everything looks like normal at the server side. I tried to restart PFD client session, without success. Reboted computer and restart session, without success.

I attach the SITU file, pictures of server and client displays. Sorry for the bad quality.

SITU : http://www.hoppie.nl/forum/var/CLIENT_BELOW_CRZ_ALT.situ

SERVER SCREENSHOT : https://www.dropbox.com/s/8y680r1cnn6tqui/20160111_175551.jpg?dl=0

PFD CLIENT SCREENSHOT : https://www.dropbox.com/s/ympszqdx4gmfi2j/20160111_172902.jpg?dl=0

Best regards,

[Hardy Heinlin]

Hi Jean-philippe,

it's hard to reproduce this error. I was able to reproduce it once by doing the following steps:

1. Start PSX A, activate server mode, and load your situ.
2. Start PSX B, activate client mode.
Result: PSX B's altimeter is ca. 1000 feet higher.

I checked the baro pressure on the planet weather page (there is no focussed zone). The data displayed was synchronized across the network. I changed 1022 hPa to 1021, and the PFDs then synchronized as well. Looks like it needed a "refresh event". Changing it back to 1022 or to any other value didn't cause further problems. Also any other network actions and situ loadings etc. worked perfectly.

The question is now: How could this sync error initially occur? I have no answer yet. It never happened to me. I don't know if it's add-on related; perhaps it needs some extra protection.

If it happens again on your system, you may change the baro setting by 1 hPa, up and down, on the active weather page on the Instructor to wake up the resync process. Just for testing.


Cheers,

|-|ardy

[JP59]

Thanks Hardy. Wilco and feedback if it reproduces again.

Cheers,

[Hardy Heinlin]

Maybe it has something to do with the slow mode and the fast mode of the baro drift simulation. As you know, injected baro data must not promptly change the physical weather; it must slowly drift to the target pressure. Perhaps the slow mode activation signal just reached the server, but not the client, due to a timing problem.


|-|ardy

[JP59]

It makes sense. But what about the FD bar and flight controls indicator on the client picture ? It is very strange. It is like if client own autoflight system was trying to recover altitude without success.

[Hardy Heinlin]

No, that's not strange. That's plausible. The client's AFDS uses this "wrong" baro altimeter as well. Flight direction commands are not directly synchronized; that would require a data stream at 20 Hz or higher. The client computes its own aerodynamics as described on page 83. The client's AFDS reacts on the client's aerodynamics which depends on the client's weather data, and which influences the client's ADC data and probes and sensors.

The client's Instructor weather data may agree with the server's Instructor. But the Instructors just display the target data, not the slow-drift data currently applied in the physical model (which affects aerodynamics and instruments).

The client's A/P will not reach the wrong altitude because the server is injecting the true altitude into the client at 5 Hz. This synchronizes the true altitude, but not the baro pressure in the client's static probes. The instruments don't know what a "true altitude" is. They use sensors like on the real aircraft. And these sensors may fail.

[JP59]

So if it is a synchronization or timing problem, why restarting the client didn't update the client's PFD ?

I also tried to restart the client computer, thinking about an issue at my own network side, but client's PFD restarted with last wrong indication.

[Hardy Heinlin]

Perhaps because the last stored baro setting was the same, preventing a proper refresh signal. It may have something to do with the way the weather data is written in the last stored situ. Were any add-ons running during the restart?

[JP59]

PSXAloft, PSXseecon, VisualPSX and TrafficPSX 

All running on the server computer, which wasn't restarted. If it happens again, I'll disconnect all this stuff before to restart the client.

[Greg Hateley]

Not sure if this is exactly the same fault, but I have observed (very very very rarely) a mismatch between the FO and Capt altitude even when the QNH is set the same on both.
Then I opened up another networked instance of PSX (instructor station) to see that the Altitude is as it should be, the same on both the FO and Capt.
On my system the FO PSX instance is the server, and the Capt another client on the same computer.
I also noticed that if I saved the situation with the fault, it would be saved that way, and when reloaded faulty again. Hope that helps.
Regards
Greg

[Hardy Heinlin]

Has this ever occured in a PSX version older than 10.0.5?

Maybe it has something to do with modification 0.5.0048 which introduced the new Qi variable "WxSlowTransit". This allows add-ons to determine whether a new baro data injection is to be applied promptly or slowly. The true aircraft altitude is always synchronized. And the target weather data is always synchronized. But the baro altitude that the avionics use may disagree across the network if the server applies the target data promptly while the client applies it slowly.


Regards,

|-|ardy

[JP59]

Hello Hardy,

I use 10.0.6c. Honestly I can't remember if this problem came right after this Qi creation, but the timing could match. From what I can remember, every time I get this altitude mismatch between server and clients :

- I was flying outside a focused zone (planet default weather) along very long haul flights. Aircraft can stay sometimes up to 1 hour outside weather zones with the same "static" QNH setting (planet QNH). It makes me thinking about absence of "wake up events" don't you ?
- I was testing or using PSXAloft which injects Qi243=500, then right after Qs327 with tropopause data (A.....T..W....). These two variables are sent every 5 seconds. That's all. PSXAloft do not inject anything else related with METAR or QNH... I only use Qi243 to command a slow transition of winds and OAT. This data is sent to the server of course.

Some questions come to me. Maybe you could check how PSX handles these situations :

- What happens if the server and/or clients are in a slow transition process when a new slow transition command is received from an add-on ?
- Can be related with the first scenario : could something (add-on injection, new WX zone,...) disturb the network synchronization and make the server stay in slow mode while clients are switching to fast mode (and "vice versa") ?
- Why I never saw this issue when flying inside focused zones and zones are focused, transitioned, changed frequently along my route every time I get close to a new WX station ? Because QNH is refreshed more frequently ?

Edit : one more question though. Why do you include baro data injections within WxSlowTransit process ? Should an add-on modify the QNH setting, it will do that using a METAR string injection, which will by design be automatically smoothed (if I understood how PSX works well). Maybe this redundancy could lead to problems. Just my newbie idea 

Cheers,

[Hardy Heinlin]

Hello Jean-philippe,

I'll test a few things in the next weeks.

Edit : one more question though. Why do you include baro data injections within WxSlowTransit process ? Should an add-on modify the QNH setting, it will do that using a METAR string injection, which will by design be automatically smoothed (if I understood how PSX works well). Maybe this redundancy could lead to problems. Just my newbie idea 

Add-ons can also inject planet weather data, and for that there is no METAR text field, i.e. no automatic slow transit. That's why I added the "WxSlowTransit" control for add-ons.

It's also useful for those local zone variables which are not in the METAR, e.g. turbulence or inversion. Any change there activates the prompt transit mode. If another slow transit is in progress in that moment, that slow progress will promptly jump to the target data as well.


Cheers,

|-|ardy

[Sylle]

I have noticed this multiple times in the past too.
Mainly happens in cruise when using internet weather (directly in PSX - no addons).
It normally goes away when you come close to your destination...

Regards,
Sylvain

[JP59]

Hello Hardy,

Just a new feedback to help you for investigations. I made a very long haul flight yesturday (13h flight time) without time acceleration (I know I'm crazy  ). I took a great attention monitoring CPT anf FO PFD altitude which is run on a client computer as said before. Starting from WMKK enroute to EGLL. Everything works fine during the first 2 hours. Weatehr zones are transitionned smoothly along my route (Set weater along flight track and downloaded METAR box checked).

Problems starts when arriving in the default planet weater zone over bengale gulf (no WX stations available so PSX switches to planet WX). My CPT and FO PFD altitude (client computer) starts to dirft up to 300ft above cruise altitude, while PFD altitude on the server computer remains rock stable at 32000ft.

I decided to let PSX do its own job and do not touch anything, waiting for PSX to focus on the next available WX zone. After about 1 hour, PSX switched from planet WX to a new focused WX zone, and client PFD altitude resynchronized with server. During the next 9 hours of flight, everything was OK (always flying above focused WX zones).

After that, I tried to load the SITU over a testing server / client setup. I reproduced the issue one time. Changing planet QNH on the server's WX page resynchronized server and client PFD altitudes.

Here a the SITU and 2 pictures of server and client. All 3 "saved" at the same time :

SITU : http://www.hoppie.nl/forum/var/Outside_WX_zone.situ

SERVER : https://www.dropbox.com/s/t9cnq18dpwwcl4m/20160114_122357.jpg?dl=0

CLIENT : https://www.dropbox.com/s/tzpv2y3shbtc61m/20160114_122409.jpg?dl=0

In my opinion, it confirms it is a server / client synchronization issue, and that it only happens when aircraft is overflying default planet WX weather zone.

I hope this helps.
Cheers,

[Hardy Heinlin]

OK, thanks, Jean-philippe.


Cheers,

|-|ardy

[Hardy Heinlin]

Hi Sylvain and Jean-philippe,

when this problem occured, did the server's Instructor and the client's Instructor both show the same baro pressure on their planet weather pages?

I've been unable to reproduce this problem. It would help if I knew where the disagreement lies: in the target pressure data (Instructors disagree, PFDs disagree) -- or in the slow transit variable (Instructors agree, PFDs disagree).


Cheers,

|-|ardy


Also, what about the other weather variables on the client, aside from the baro pressure? Wind, clouds, etc. displayed on the client's Instructor -- do they agree with the server's Instructor? Are the weather zones in the tabs identical to those on the server? Do both instances use the planet weather, or a certain local zone?

[Hardy Heinlin]

One more question, just to be on the safe side: When the PFDs disagree, do both the server's and the client's Instructor show the same true aircraft altitude on Situation > Position (aircraft altitude edit field)?


|-|ardy

[JP59]

Hi Hardy,

I need to run my simulator for a long haul trip to return in a server/client configuration and be 100% sure to reproduce the situation. I'll do this and report as soon as possible.

Cheers,

Edit : I will try to reproduce on my laptop with the SITU saved from the simulator. It will be faster and easier. The simulator takes 30-45 minutes only to be ready for pushback 

[JP59]

Hi Hardy,

Bingo ! After only two attempts I reproduced the issue, just after connecting the client. Here are some screenshots of both server and client. On the situation/position instructor pages, true altitudes were synchronized.

https://www.dropbox.com/s/29gmheob7hxy0jg/Capture%20d%27%C3%A9cran%202016-01-20%2020.30.03.png?dl=0

https://www.dropbox.com/s/x6s3j25olo46vsq/Capture%20d%27%C3%A9cran%202016-01-20%2020.30.28.png?dl=0

https://www.dropbox.com/s/ga02qsann66pqba/Capture%20d%27%C3%A9cran%202016-01-20%2020.30.38.png?dl=0

I hope this helps.

Cheers,