AI Traffic query

[pointy56]

Hi John,

I'm hoping that you might be able to cast some light on a problem that I have recently been having with AI traffic data via FSUIPC:

A couple of us have noticed that PF3 sometimes spells out the airline name rather than reading it out - so 'Echo Alpha Sierra Yankee' instead of 'Easy'.
I'm using MSFS, but the other guy is using P3D, so other than PF3 the common factor seems to be FSUIPC.

I made a test flight yesterday where this happened, and I used Paul Henty's example code to capture the AI traffic at the time (screenshot attached).
You will see that although some of the flights have complete callsigns, some of them have just the airline name - for PF3 to work properly we need the full callsign.
You will also see that others seem to have the flight number in the 'To' field, which seems rather curious.

Are you aware of any problems with FSUIPC in this area?  Is there any tracing/debugging that I can run that could help identify the cause of this problem?

Thanks,
Martin

[John Dowson]

10 minutes ago, pointy56 said:

A couple of us have noticed that PF3 sometimes spells out the airline name rather than reading it out - so 'Echo Alpha Sierra Yankee' instead of 'Easy'.
I'm using MSFS, but the other guy is using P3D, so other than PF3 the common factor seems to be FSUIPC.

I don't think this can be anything to do with FSUIPC, as this will just be supplying/holding the string "Easy", and it will be up to the software to interpret this.

12 minutes ago, pointy56 said:

I made a test flight yesterday where this happened, and I used Paul Henty's example code to capture the AI traffic at the time (screenshot attached).
You will see that although some of the flights have complete callsigns, some of them have just the airline name - for PF3 to work properly we need the full callsign.
You will also see that others seem to have the flight number in the 'To' field, which seems rather curious.

That looks rather strange but I do not know the software you are using - could this be at fault? Could you try the TrafficLook program instead - do you see the same?
FSUIPC just stores the information received, so if there i no callsign then none has been provided.
 

15 minutes ago, pointy56 said:

Are you aware of any problems with FSUIPC in this area?  Is there any tracing/debugging that I can run that could help identify the cause of this problem?

I do not know of any issues. You can log AI traffic by using a Log->Custom value of x10000, (Logs AI data), x40000 (Logs additional AI data) or x50000 (logs both).

I will take a look here later to check the callsigns and flight number / to field - this does look like data is being misinterpreted but I am not sure if this is in FSUIPC or in the program you are using...

John

[John Dowson]

By the way, where is your TCAS ID coming from (in Options->Miscellaneous)? It should be set to Flight (the default), but you could try Tail to see if that improves things. I am not sure where that example program is getting the callsign information from...

Just looking at traffic with TrafficLook and I see no issues with the flight number in the 'To' field:

Note for the logging, start with a custom value of x10000 and look for the following strings in the log:

Quote

   139813 AIRCRAFT ADDED: Ref=469 [x01D5],OnGnd=1,Tail="G-PWXJ",Airline="",Flight="1123",Type="Airbus"
   139813    Lat=51.4713,Lon=-0.4772,Alt=77,Gnd=0, GS=0,AS=0,VS=0,Pch=0.0,Bnk=0.0,COM1=2485
   139813    State="STATE_SLEEP" [1], Runway="", From="EGLL", To="UUWW"
   139813    Airborne count = 365

This will show you the data that FSUIPC is receiving regarding the identification of the AI aircraft and its to/from fields.

Edited October 1 by John Dowson
Further info added

[pointy56]

Thanks John, I'll give this a go later - my TCAS Id is set to 'Flight', so I'll try running with some logging.
 

[pointy56]

Hi John,

I've managed to reproduce the problem with FSUIPC logging enabled, which has given me some very useful information; I am now trying to correlate all the data that I have.
Please can you remind me how the timestamp on each FSUIPC log entry works - I seem to recall that it's milliseconds since FSUIPC started, is that correct?

Thanks,
Martin

[John Dowson]

42 minutes ago, pointy56 said:

Please can you remind me how the timestamp on each FSUIPC log entry works - I seem to recall that it's milliseconds since FSUIPC started, is that correct?

Yes

42 minutes ago, pointy56 said:

I've managed to reproduce the problem with FSUIPC logging enabled, which has given me some very useful information; I am now trying to correlate all the data that I have.

Ok, that's good. Do you see the same issue in the FSUIPC TCAS tables then (or in TrafficLook)?

[pointy56]

Thanks for the confirmation.
And 'Yes' I am seeing the same issue with TrafficLook; here's a screenshot which shows both missing flight numbers, and flight numbers in the 'To' field.
I'm using FS Traffic, so I've also logged a support query with Just Flight.

[pointy56]

OK, I've just made a short flight with FSUIPC logging set to 0x50000 and noticed something strange:
Look at the attached screenshot from TrafficLook and slot 10 'Shamrock' (Id 3894) which is shown as Enroute, but with no From or To.
If you now look in the FSUIPC log, every AI Update for Id 3894 shows 'STATE_SLEEP' and OnGnd=1 - so why is it in the airborne list?
The same is true for slot 11 and probably also slots 12 thru 21; they all have an altitude of 203/204, suggesting to me that like slot 10 they are actually on the ground.

This might explain the problem that I have been seeing. Am I missing something here, or is this a bug?

Regards,
Martin

FSUIPC7-20241004.zip

[John Dowson]

1 hour ago, pointy56 said:

I'm using FS Traffic, so I've also logged a support query with Just Flight.

Ok, thanks - I was going to ask if you use any traffic add-ons. I have seen no issues when using standard MSFS AI traffic. I am not familiar with FS Traffic though...

44 minutes ago, pointy56 said:

Look at the attached screenshot from TrafficLook and slot 10 'Shamrock' (Id 3894) which is shown as Enroute, but with no From or To.
If you now look in the FSUIPC log, every AI Update for Id 3894 shows 'STATE_SLEEP' and OnGnd=1 - so why is it in the airborne list?
The same is true for slot 11 and probably also slots 12 thru 21; they all have an altitude of 203/204, suggesting to me that like slot 10 they are actually on the ground.

This might explain the problem that I have been seeing. Am I missing something here, or is this a bug?

There is certainly an issue somewhere....but lot 10 'Shamrock' (Id 3894) (and others) maybe in the STATE_ENROUTE_AS_FILED state, so are Enroute. If you look at the log entries, e.g.

Quote

   982719 UPDATEAI: Ref=3894 [x0F36],State="STATE_SLEEP" [12],OnGnd=1,Alt=203,Gnd=0,GS=0,AS=0,VS=0,Flags=03FF, Park=104/10/10
   982719    after: State="STATE_SLEEP" [12],OnGnd=1,GS=0,VS=0
   982719 UPDATEAI: Ref=3896 [x0F38],State="STATE_SLEEP" [12],OnGnd=1,Alt=204,Gnd=0,GS=0,AS=0,VS=0,Flags=03FF, Park=106/10/10
   982719    after: State="STATE_SLEEP" [12],OnGnd=1,GS=0,VS=0
   982719 UPDATEAI: Ref=3898 [x0F3A],State="STATE_SLEEP" [1],OnGnd=1,Alt=203,Gnd=194,GS=0,AS=0,VS=0,Flags=03FF, Park=11/10/10
   982719    after: State="STATE_SLEEP" [1],OnGnd=1,GS=0,VS=0

See the number in brackets after the state string - this is the state number, where 1 is STATE_SLEEP and 12 is STATE_ENROUTE_AS_FILED. So it looks like there is certainly something wrong somewhere ...for that aircraft, the state seems to change here:

Quote

   952609 UPDATEAI: Ref=3894 [x0F36],State="STATE_SLEEP" [1],OnGnd=1,Alt=203,Gnd=194,GS=0,AS=0,VS=0,Flags=03FF, Park=104/10/10
   952609    after: State="STATE_SLEEP" [1],OnGnd=1,GS=0,VS=0
,,,
   952687 UPDATEAI: Ref=3894 [x0F36],State="STATE_SLEEP" [1],OnGnd=1,Alt=203,Gnd=0,GS=0,AS=0,VS=0,Flags=03FF, Park=104/10/10
   952687    after: State="STATE_SLEEP" [12],OnGnd=1,GS=0,VS=0
   952687 ---AIRCRAFT addition: Ref=3894 [x0F36], fGround=0, Range=19.7
...
   952766 UPDATEAI: Ref=3894 [x0F36],State="STATE_SLEEP" [12],OnGnd=1,Alt=203,Gnd=0,GS=0,AS=0,VS=0,Flags=03FF, Park=104/10/10
   952766    after: State="STATE_SLEEP" [12],OnGnd=1,GS=0,VS=0

For some reason, the ground altitude of the AI aircraft is changing from 194 to 0, which seems to be the problem. When an AI aircraft' altitude is more than 100 above the ground altitude, then FSUIPC will automatically change the state (internally) to Enroute if it is currently in STATE_SLEEP or STATE_WAIT_FOR_ENGINE_START. So this issue seems to be due to the ground height being received (or misinterpreted).

Of course, this may also be an FSUIPC issue - I will check your log further and look into this more over the weekend, when time permits, and/or next week.

John

[pointy56]

Thanks John.

Are you saying that FSUIPC uses a different mechanism rather than the OnGnd flag for Ground/Airborne filtering?

Martin

[John Dowson]

2 hours ago, pointy56 said:

Are you saying that FSUIPC uses a different mechanism rather than the OnGnd flag for Ground/Airborne filtering?

The OnGnd flag is used as received, except when the AI aircraft state is sleeping or waiting for engine start (states 1 and 0). When an aircraft is in one of these states, FSUIPC will look at the difference between the ground altitude and the aircraft altitude, and if this is < 100 it will set/change the OnGnd flag to 1 (internally, regardless of the value received), and if >=100 it will set the OnGnd flag to 0 and change the state (internally) to show the aircraft as Enroute. This is why it is shown as airborne.
I am not sure why FSUIPC does this - maybe the OnGnd flag (plus other data fields which are also changed) cannot (or could not) be trusted for such aircraft - I am not sure.
I can remove this feature, or maybe add an ini parameter that can enable/disable this functionality.

But the real issue is why is the Ground altitude changing to 0 for these aircraft when they are sleeping?

 

[pointy56]

Looking at the Simvars list in the SDK, Ground Altitude is not settable, so I'm not sure what's changing it.
With my current scenery set-up EGKK (where I was flying from) has an elevation of 203 feet, so 203/204 for aircraft altitude would seem to be correct - they're on the ground.

[John Dowson]

5 hours ago, pointy56 said:

With my current scenery set-up EGKK (where I was flying from) has an elevation of 203 feet, so 203/204 for aircraft altitude would seem to be correct - they're on the ground.

203 is the elevatiuon of the aircraft, and the ground elevation was 194. This is normal. However, what changed was that the ground elevation received at timestamp 952687 changes the ground elevation to 0, hence the issue - as I previously showed:

21 hours ago, John Dowson said:

 952609 UPDATEAI: Ref=3894 [x0F36],State="STATE_SLEEP" [1],OnGnd=1,Alt=203,Gnd=194,GS=0,AS=0,VS=0,Flags=03FF, Park=104/10/10
   952609    after: State="STATE_SLEEP" [1],OnGnd=1,GS=0,VS=0
,,,
   952687 UPDATEAI: Ref=3894 [x0F36],State="STATE_SLEEP" [1],OnGnd=1,Alt=203,Gnd=0,GS=0,AS=0,VS=0,Flags=03FF, Park=104/10/10
   952687    after: State="STATE_SLEEP" [12],OnGnd=1,GS=0,VS=0
   952687 ---AIRCRAFT addition: Ref=3894 [x0F36], fGround=0, Range=19.7

So the ground elevation of the aircraft IS changing, as received via simconnect. So something somewhere is changing this...
I can change FSUIPC to ignore the difference between ground and aircraft altitude, so it doesn't change the state or the OnGrnd flag. I will provide you with a new version to test this when I have time....

[John Dowson]

Can you try the attached version - please add
    AIAboveGroundLimit=1000
to the [General] section of your FSUIPC7.ini file. 

I need to go out now so haven't had time to test this version - please let me know how it goes and also attach your log file.
I am also now logging the to/from ICAO codes, so should be able to see when/if that changes.

John

FSUIPC7.exe

 

[pointy56]

Thank you John, will do.

Martin

[pointy56]

42 minutes ago, John Dowson said:

I am also now logging the to/from ICAO codes, so should be able to see when/if that changes.

I think that you may be outputting the 'From' in both fields as all those log entries appear like this:

  1638938 UPDATEAI: Ref=2982 [x0BA6],State="STATE_LANDING" [14],OnGnd=0,Alt=368,Gnd=0,GS=135,AS=135,VS=-245,Flags=03FF,From='LIBR',To='LIBR', Park=0/0/0
  1638938 UPDATEAI: Ref=4091 [x0FFB],State="STATE_GO_AROUND" [16],OnGnd=0,Alt=13,Gnd=0,GS=172,AS=172,VS=-3,Flags=03FF,From='EGPH',To='EGPH', Park=0/0/0
  1638938 UPDATEAI: Ref=4194 [x1062],State="STATE_ENROUTE_AS_FILED" [12],OnGnd=0,Alt=30000,Gnd=350,GS=320,AS=320,VS=0,Flags=03FF,From='EIDW',To='EIDW', Park=0/0/0
  1638938 UPDATEAI: Ref=4450 [x1162],State="STATE_TAXI_TO_PARKING" [17],OnGnd=1,Alt=203,Gnd=194,GS=0,AS=0,VS=0,Flags=03FF,From='GCRR',To='GCRR', Park=104/10/10

Aside from that it's looking good; I restarted FSUIPC with MSFS running, so I'd like to make another test flight with a clean start before providing new logs.

Thanks,
Martin

[John Dowson]

16 minutes ago, pointy56 said:

I think that you may be outputting the 'From' in both fields as all those log entries appear like this:

Yes, corrected in the attached version (version number unchanged at 7.4.18b).

John

FSUIPC7.exe

[pointy56]

Here's a log from the previous version (with To & From the same), but it seems to be doing what's required - I didn't hear any spurious ATC calls.

There are a couple of strange AI aircraft all from EGSS to LEVC which you can see in the attached TrafficLook screenshot (1440, 1441 & 1442).
I think I need to ask Just Flight about those.

I'll try to make another test flight tomorrow with the updated version (7.4.18b).

Thanks,
Martin

FSUIPC7-20241006.zip

[John Dowson]

17 hours ago, pointy56 said:

There are a couple of strange AI aircraft all from EGSS to LEVC which you can see in the attached TrafficLook screenshot (1440, 1441 & 1442).
I think I need to ask Just Flight about those.

Strange how? Those are all a very long way away (not that that should matter)...have you set a very high or unlimited TCAS air range?
Some of he VS values look very strange as well...

I think I will make this setting the default, so you don't need to set that ini parameter. I will also update the latest beta release (see Announcements sub-forum) to this version in the next few days.

John

[John Dowson]

4 hours ago, John Dowson said:

I think I will make this setting the default, so you don't need to set that ini parameter. I will also update the latest beta release (see Announcements sub-forum) to this version in the next few days.

I have done this now if you would like to try the latest beta (InstallFSUIPC7.4.18beta.zip). You can remove that new ini parameter with this version.

John

 

[pointy56]

5 hours ago, John Dowson said:

Strange how? Those are all a very long way away (not that that should matter)...have you set a very high or unlimited TCAS air range?

Three similar aircraft, always with incomplete flight details, apparently flying from EGSS to LEVC, but in completely different directions - they've appeared each time I start MSFS. 🤔

I'll give the latest beta a try shortly, but all looked good last time - and the three 'strange ones' are well outside my TCAS air range so don't cause a problem.

Martin

[pointy56]

OK, that seems to be working well - thank you.  I've attached the latest log (it's over 200MB unzipped) if you want to take a look.

Also, you will see from the attached TrafficLook screenshot that my favourite 3 'strangers' appeared once more, and the data for them looks a bit weird.
I'm not worried about them as they didn't interfere with the flight, but I will pursue it with Just Flight as they are creating them (actually a 4th one, 310, appeared later).

I may be pushing my luck, but might a similar fix be possible for FSUIPC6?  Another PF3 user (with P3D) is seeing the same sort of problem.

Best regards,
Martin

FSUIPC7-20241007.zip

[John Dowson]

18 hours ago, pointy56 said:

but might a similar fix be possible for FSUIPC6? 

I can't see how I can fix this in FSUIPC - how would I detect such aircraft in the first place?

[pointy56]

45 minutes ago, John Dowson said:

I can't see how I can fix this in FSUIPC

Sorry, I should have been clearer - would you be able to put the same 'ground altitude' fix into FSUIPC6?

[John Dowson]

5 minutes ago, pointy56 said:

I should have been clearer - would you be able to put the same 'ground altitude' fix into FSUIPC6?

Ah, yes, sorry - I can certainly do that...