v15.1.2

CYYZ this morning, 11:20 - 11:30UTC

A lot of freezing AI, especially on start-up , two frozen planes on RNY 23 for T/O. Taxiing planes are cutting corners, appearing, then again disappearing. CYYZ used to be a staple for good quality PSXT stream. 

13 hours ago, netshadoe said:

So, what I'm trying to wrap my head around is why would PSXT stop using the data from the same target that remained on the map in RT - it was there - it didn't change or glitch out - it flew for 40 miles from takeoff until the 737 was deleted.

This is exactly what I am seeing at the airports I have visited.

9 hours ago, G-YMML1 said:

 

v15.1.2

CYYZ this morning, 11:20 - 11:30UTC

A lot of freezing AI, especially on start-up , two frozen planes on RNY 23 for T/O. Taxiing planes are cutting corners, appearing, then again disappearing. CYYZ used to be a staple for good quality PSXT stream. 

Same at UK airports.

14 hours ago, netshadoe said:

It's hard to convey in words what I'm seeing. But, are you saying that the data in RealTraffic is ignored by PSXT when certain parameters and factors are involved?

Yes, for instance if the data is so irregular that PSXT cannot produce vectors for the aircraft.

A vector is a path that is constructed by PSXT between two RT data points, that normally, ideally, arrive in PSXT every 3 seconds..

Another constraint, PSXT needs at least 3 RT datapoints in a 30 seconds time frame (the buffer).

Edited May 14May 14 by kiek

Is it possible to develop some sort of real-time quality measurement for the RT stream and reflect it on PSXT to stop speculation whether it's RT or PSXT?

1 hour ago, G-YMML1 said:

Is it possible to develop some sort of real-time quality measurement for the RT stream and reflect it on PSXT to stop speculation whether it's RT or PSXT?

That's what I wrote yesterday:

"I've discussed this with Balt. I will implement a continuous RT data quality measurement, mainly by counting irregularities in the RT data stream, and display that figure in the main window. Hopefully that will provide more insight into the quality of the incoming data."

Worked on that this morning.

Since you’re working on it, I’ll wait unless you need something from me, such as logs. I had another instance yesterday where a Porter Air E2 froze on the taxiway C at CYOW, but the target in RT looked “OK” from the data tag I could see, and took off on Rwy 07 and turned west toward Toronto. The E2 stayed there until the timeout.

I get that the data tag is RT’s internal info and may not reflect what PSXT is receiving from the API. It more to point out that RT has a target, and there is a miscommunication somewhere in the system.

Thanks again Nico for all you do for the hobby!

5 minutes ago, netshadoe said:

Since you’re working on it, I’ll wait unless you need something from me, such as logs. I had another instance yesterday where a Porter Air E2 froze on the taxiway C at CYOW, but the target in RT looked “OK” from the data tag I could see, and took off on Rwy 07 and turned west toward Toronto. The E2 stayed there until the timeout.

Let me ask you a question - did this "incident" happen in the beginning of PSXT session, i.e. as E2 loaded at the initial phase OR it noticed this behavior 20-30 min later?

I'm seeing a lot of "frozens' in the beginning of PSXT session. 20 min later things tend to settle, hence I think that perhaps PSXT does not handle the initial RT data buffer correctly? Just a guess.

18 minutes ago, G-YMML1 said:

hence I think that perhaps PSXT does not handle the initial RT data buffer correctly?

The inital buffer is only 30 seconds, so no that is not the cause.

14 minutes ago, kiek said:

The inital buffer is only 30 seconds, so no that is not the cause.

Correct.

* All active planes loaded within first 20-30 seconds stay frozen.
* Other active planes loaded after 30-45 seconds behave normally.

Hi guys,

Although it is Ascension Day, I have added a continuous test to monitor the quality of the RT traffic data. Quality here means whether data arrives regularly and continuously. I am not testing the validity of parameters such as altitude, latitude, longitude, and so on.

Large gaps between incoming data updates can cause aircraft on the ground to enter a holding state for the number of MaxHoldingMinutes you have set in the UI.

After every 15 RT data batches received, roughly every 1 to 1.5 minutes, you will see something like this in the message line of the UI (and in Log.txt):

RTQ samples : 1674 gap_avg : 5.2 gap_sd : 4.1 gap_min : 1.0 gap_max : 44.6

Interpretation :

samples: 1674 → number of update intervals collected during the aggregation period (15 * the number of aircraft in a data batch)

gap_avg: 5.2 → average time between actual RT updates

gap_sd: 4.1 → variability of update intervals (= standard deviation)

gap_min: 1.0 → shortest observed update interval

gap_max: 44.6 → longest observed update gap

Gap times are expressed in seconds. They represent the difference between the timestamp of newly received data and that of the previous data packet.
Do note that you need to measure for at least an hour or so to obtain meaningful results.

The 15.1.2 version of PSXT (MSFS) with this monitor can be down loaded from here.
This update only contains the .exe, just overwrite your existing one.

Nico

So, gap_sd and gap_avg are two most critical parameters to judge about the quality of the stream, right? The smaller the values, the better the data.

You were talking a

48 minutes ago, G-YMML1 said:

So, gap_sd and gap_avg are two most critical parameters to judge about the quality of the stream, right? The smaller the values, the better the data.

Indeed, but especially gap_sd. And if gap_max <= 30 seconds you will not have any freezing.

I have not spent much time at KSFO yet, but the initial results show that the Quality here is better then at EHAM.

Edited May 14May 14 by kiek

On 5/12/2026 at 1:26 AM, Harrier77 said:

Hi Nico,

This is not exactly what the OP reported, but over the last few weeks, I have noticed a deterioration in the quality of the PSXT live traffic. These observations have been noticed at many UK airports, but not exclusively in the UK. The airports where I have seen this behaviour have good RT coverage.

This is what I have observed:

1. Many live taxiing aircraft 'cut corners'. i.e., they do not follow the airport taxiways. I know PSXT does not know the airport layout, except the parking positions, but up until recently, live taxiing aircraft would largely follow the routes expected, but this happens less often now.

2. Many live aircraft now 'freeze' during taxi out, and in particular on the runway, and therefore do not take off. These frozen aircraft eventually get removed by PSXT or by another live aircraft moving over their position.

3. The incidence of live aircraft failing to park on stands properly has increased (i.e., they do not transition to live parked status).  Live aircraft not parking properly is seen as either not stopping in the correct position and then being removed, or they end up in the correct area but start to rotate in a position and then get removed.

I appreciate that a lot of this depends on the quality of the RT data, but the change in what PSXT is showing now compared to what I have seen previously is very noticeable.

Peter

also the 787s n crjs floatin in air when on aproach for landing

On 5/12/2026 at 10:53 AM, kiek said:

Then it points in the direction of RT ...
I'm at EHAM and KSFO the whole day, and no problems at all. Aircraft diappearing  during takeoff I do not see. I remeber these things to happen at EGLL often, even before 14.0

 

chek other sceneries katl,kmem,klax etc.