New ES 3.2.3 ICAO Equipment format

[Max Kuhla (1157125)]

Hello,

After an update to the newest Euroscope version of 3.2.3 i get (using the Swedish setup) lots of P. R and W indications in row 0 of the Tags, it seems many aircraft get an incorrectly converted ICAO Equipment code string from the FAA format. Is this something new on VATSIM, server side, or a problem of Topsky not having been updated to support this?

In 3.2.3 there is a new option that appeared  "Get FP equipments in ICAO formats", maybe turning it of could solve the problem, I did not try that when having this problem yesterday.

[Juha Holopainen]

Nothing new on VATSIM. It has just been hidden for some time as EuroScope wasn't getting the ICAO codes at all. Now that it does again, all the fantastic ways pilots file their flightplans are once again visible to controllers. Some examples of filed aircraft/equipment-strings at the moment:

"A320/M-RNVD1E2A1RNP2/SDE3FGIKRWXYS"

Yes, you're seeing that right... The plugin will flag W and Y.

"CRJ7/M-VGDW/C"

That's a fairly common equipment string for some reason. Unfortunately it also happens to be completely ridiculous. The plugin will flag Y.

In both cases R and/or P may be flagged as well depending on the contents of the PBN entry in the remarks (if any).

If the indicators themselves or equipment-related issues such as MTCD or STCA alerts related to non-RVSM status cause problems, the short-term solution is to turn off the equipment code use (Setup>Local Settings>Used equipment codes>None). The long-term solution would be a better FPL form on VATSIM - maybe providing reasonable default values, tick-boxes instead of a text entry field, etc. - and alerting of the most common issues before accepting the plan. Given that a minority of controllers ever see the issues from the imaginative equipment codes, this is probably not a high priority item for VATSIM tech.

 

[Max Kuhla (1157125)]

CRJ7/M-VGDW/C

Is a string I highly doubt that pilots actually file. Isn't there some sort of a conversion being done by the VATSIM servers, from FAA to ICAO standards, resulting in that nonsense of an equipment combo.

Of course, when most pilots have no idea about it and VATSIM not making it better, ignoring the codes altogether might be the best solution, but the case mentioned above can not possibly be filed by so many pilots, it must have been "converted" somehow by the servers, or ES?

[Juha Holopainen]

Currently over 400 flightplans on the network are "VGDW/C", so it's almost certainly a result of some automated action. My guess would be an automatic conversion from the filed FAA equipment suffix (either by the pilot client or the network servers), but I'm not sure why anyone would set up a system to convert "/L" or any other FAA suffix into "VGDW/C".

[Juha Holopainen]

After a quick test, at least the VATSIM prefile system does indeed create a converted ICAO equipment string of "VGDW/C" when filing a plan with FAA suffix "/L". I have to admit I'm bit curious as to why exactly that conversion has been chosen as the best representation of the originally filed "/L" 

[Jannik Vogel (1432304)]

I just wrote with someone from the VATSIM tech staff. They can easily change this. What would be your suggestion as an accurate conversion for FAA code "L" into "ICAOish"?

[Jannik Vogel (1432304)]

What do you think about "SDE2E3FGILORWXY/HB1"?

[Bernardo Reis (1096507)]

3 hours ago, Jannik Vogel (1432304) said:

What do you think about "SDE2E3FGILORWXY/HB1"?

You can scrap L and O as those are included in the S(tandard) equipment.

Maybe add H too because in VATSIM HF is related to VHF...

The transponder I would change from H to L

Edited March 8, 2023 by Bernardo Reis (1096507)

[Ricardo Sousa (1110850)]

SDE3FGHIJ1J3RWXYZ/LB1D1

E3 for DCL, H for HF, J1 and J3 for CPDLC, B1 for ADS-B out and D1 for ADS-C. The rest is pretty self explanatory, /L basically means modern airliner and these are more or less the capabilities of any FBW/Fenix/iniBuilds/PMDGkindabutnotreallybuttheyshoudlreally/etc out there

Edited March 8, 2023 by Ricardo Sousa (1110850)

[Bernardo Reis (1096507)]

@Ricardo Sousa (1110850)I would add E2 too for the basic metar fetching via ACARS. D1 might be a stretch but no objections

Edited March 8, 2023 by Bernardo Reis (1096507)

[Jannik Vogel (1432304)]

So

SDE2E3FGHIJ1J3RWXYZ/LB1D1

it is. I just wrote the VATSIM Tech Team our solution, will give a quick heads up as soon as they adjusted it

[Juha Holopainen]

16 hours ago, Jannik Vogel (1432304) said:

I just wrote with someone from the VATSIM tech staff. They can easily change this. What would be your suggestion as an accurate conversion for FAA code "L" into "ICAOish"?

For the TopSky plugin specifically, if I remember correctly, only the following capabilities are actually checked from the FPL:

NAV/COM: 8.33 capability, RVSM capability, UHF capability, RNAV1 and RNAV5 capability

Surveillance: altitude reporting capability, mode S capability, EHS capability, flight id downlink capability

Out of those, the RVSM capability is the most important one as it affects a number of safety nets (the altitude reporting capability naturally as well if some brave soul has allowed non-altitude-reporting transponders in the plugin settings). The mode S availability affects some data display, the rest are mainly eye candy in the form of alerts in the track labels.

In the plugin I've converted FAA codes into ICAO NAV/COM as follows:

X, T or U: SF

D, B or A: SDF

M, N or P: DFILTUV

Y, C or I: SDFIRY

V, S or G: SDFGRY

W: SDFWY

Z: SDE2E3FIJ1RWY

L: SDE2E3FGIJ1RWY

The MNPS "X" could probably be added to the Z and L conversions.

(Y is included based on the plugin's 8.33 capable FAA codes list, the list above is based on the default value for that setting)

Z is added to the equipment list if the FPL remarks contains "COM/", "NAV/" or "DAT/"

For any resulting string containing "R", a PBN string in the remarks will be necessary as well to avoid an unknown PBN capability alert. "PBN/B1D1" is the simplest way to avoid the non-RNAV1 and non-RNAV5 alerts, so the server should probably add that if no other PBN string has been entered by the user. More realistic PBN strings based on the equipment string could also be used, but even this simple one would be better than nothing.

"H", "J3" and the surveillance "D1" would probably be good for widebodies, perhaps not as often found in smaller aircraft (maybe put them in if the wake turbulence category is heavy or super?).

 

The plugin converts the surveillance codes like this (again, slightly depending on the modeS-capable FAA codes setting, these being based on the default value for that setting):

X, D, M, Y or V: /N

T, B or N: /A

C or S: /I

U, A or P: /C

I, G, W, Z or L: /H

If the resulting code is /H, it may be changed into /L based on the FPL remarks (probably best to use "/L" in any case here). B1, D1 and U1 may also be added based on FPL remarks (maybe "B1" for Z and L, and "D1" as well for wake turbulence heavy and super?).

Easy and simple, right? 

 

Since the system seems to convert all the FAA codes into something, it's best to define the conversions for the other codes besides L as well - and perhaps use the L conversion when an undefined FAA code is entered.

[Ricardo Sousa (1110850)]

10 hours ago, Juha Holopainen said:

"H", "J3" and the surveillance "D1" would probably be good for widebodies, perhaps not as often found in smaller aircraft (maybe put them in if the wake turbulence category is heavy or super?).

I considered D1 because to my knowledge all oceanic airspaces in vatsim consider all aircraft as being ADS-C equipped.

It's also a bit of a geographical thing, I suppose most aircraft in eastern europe don't care much about ADS-C, while as you keep going west the more and more common it is for anything A319 and bigger, due to the likelihood of needing to operate in the NAT HLA , to the point where down here the aircraft that aren't ADS-C equipped are the exception.

10 hours ago, Juha Holopainen said:

M, N or P: DFILTUV

I'd remove I, if it's got an INS it can do RNAV even if its just 5 or 10.

 

Side question, if the fpl is already filled with icao codes, the plugin won't overwrite it with a translation, right? I had some issues where I suspected it was overwriting but honestly didn't bother too much with it.

[Jannik Vogel (1432304)]

29 minutes ago, Ricardo Sousa (1110850) said:

Side question, if the fpl is already filled with icao codes, the plugin won't overwrite it with a translation, right?

Correct, only FAA code as input is overwritten.

[Juha Holopainen]

14 hours ago, Ricardo Sousa (1110850) said:

It's also a bit of a geographical thing, I suppose most aircraft in eastern europe don't care much about ADS-C, while as you keep going west the more and more common it is for anything A319 and bigger, due to the likelihood of needing to operate in the NAT HLA , to the point where down here the aircraft that aren't ADS-C equipped are the exception.

Absolutely. What is the norm regarding stuff like HF radios, MNPS, datalink equipment type and ADS equipment type is very much dependent on area of operations, the operator's route structure and the aircraft type. Your average equipment strings for short-haul airliners in Peru, Portugal, Poland and Papua New Guinea might be very different.

14 hours ago, Ricardo Sousa (1110850) said:

On 09/03/2023 at 10:37, Juha Holopainen said:

M, N or P: DFILTUV

I'd remove I, if it's got an INS it can do RNAV even if its just 5 or 10.

It's not necessarily so. These would be military aircraft not updated to modern standards whose INS installations would not qualify for RNAV operations. But yes, the suffix would at minimum imply an ICAO equipment of "TV", whatever is added on top of that will be right or wrong depending on the situation.

[Max Kuhla (1157125)]

On 09/03/2023 at 09:22, Jannik Vogel (1432304) said:

So

SDE2E3FGHIJ1J3RWXYZ/LB1D1

it is. I just wrote the VATSIM Tech Team our solution, will give a quick heads up as soon as they adjusted it

I am still contemplating updating ES, has this change been made? 

[Jannik Vogel (1432304)]

Negative, there has not been any change yet. I am starting this discussion again on the vatsim dev discord.

[Max Kuhla (1157125)]

Still no progress on this? 

Would be great to activate the capabilites for reading ICAO Equipment without getting a screen full of red letters

[Max Kuhla (1157125)]

On 21/03/2023 at 16:50, Jannik Vogel (1432304) said:

Negative, there has not been any change yet. I am starting this discussion again on the vatsim dev discord.

How are the Devs looking, busy being Americans loving the FAA style format? 

If you let me know where to do it, I'd be up for having your back, also pushing this issue 

Edited July 4, 2023 by Max Kuhla (1157125)

[Juha Holopainen]

VGDW/C still seems to be the norm regarding FPL equipment. @Jannik Vogel (1432304), was the change proposal rejected or is this just VATSIM taking forever with any change?

[Jannik Vogel (1432304)]

Sorry, i forgot to give you an update on this.

Vatsim Developers are not planning on changing the standard conversion to a practical one, but insist on using the "official FAA conversion".

[Jannik Vogel (1432304)]

However i have noticed, that if you open a FPL with VGDW/C in the Topsky Menu and click Modify and apply without changing it, the correct FAA equip code is being loaded in (L in this case). TopSky thereafter uses the system internal conversion instead of the VATSIM one. Is there a way to achieve this without having to open the FPL and "modifying" it without any changes?

[Max Kuhla (1157125)]

1 hour ago, Jannik Vogel (1432304) said:

Sorry, i forgot to give you an update on this.

Vatsim Developers are not planning on changing the standard conversion to a practical one, but insist on using the "official FAA conversion".

There has to be a way to make them understand that VGDW is a nonsense string, just because they do not care over there doesn't mean all of Europe should have to suffer... 

Any ideas?

[Juha Holopainen]

Well that's great... I can understand the need for the ICAO->FAA conversion, and maybe even the attempt at a FAA->ICAO conversion as well even though it's bound to be inaccurate at best, but can't think of any reason to mess up the conversion like this on purpose.

TopSky changing the used codes from ICAO to FAA (and then displaying its own conversion) is not an intentional feature, and can't be activated in any way. The plugin can't choose from the two sets, it only gets one from EuroScope. I would be interested in finding out what is causing the change though, so if anyone has a logfile that shows it happening, I'd like to take a look. I haven't been able to make it happen offline so it may be something that only happens online.

[Ricardo Sousa (1110850)]

On 06/10/2023 at 13:57, Max Kuhla (1157125) said:

There has to be a way to make them understand that VGDW is a nonsense string, just because they do not care over there doesn't mean all of Europe should have to suffer... 

Any ideas?

For what is worth, the current state of the equipment codes is so broken we are forced to ignore the code completely, or at best just /L at everyone. We can't use the topsky features because of it, every now and then there's an aircraft that is legitimately RNAV 5 only or not RNAV capable at all, and the controller only finds out when the pilot says so. And I am positive this is happening everywhere else too. Perhaps if others share their experiences someone might come to reason, they did with 8.33 after all.