my.vatsim.net and equipment code

[ThaweK]

VATSIM launched my.vatsim.net where prefile is (finally) in ICAO FPL 2012 format. Unfortunately, it puts aircraft equipment within AC Type in this format: https://ibb.co/wMqvkJZ Plugin is not giving 1000 code for correct equipment code.

[kusterjs]

Fully supporting the intention, however I also hope this will be available native in ES As I expect the plugin will be updated earlier, I would highly appreciate an option to restrict the plugin to assign squawk 1000 only for the ICAO FPL types

[ogruetzmann]

There is a pre release available that supports the new format. Not enough testing, but it should work :)

https://github.com/ogruetzmann/ModeS/releases/tag/1.3.10e32-pre

[ogruetzmann]

@kusterjs the pre release should be able to recognize both formats.

Since the whole system is currently broken (ES will consider the WTC as equipment suffix), I see no point in offering the MSCC to ICAO FPL only.

The pre release is there, but I'm not going to fix things that need to be addressed elsewhere before the plugin can work correctly.

[kusterjs]

Then maybe I misunderstood how the plugin works. Does the plugin just "cope" with the ICAO FPL format? Or does it really decode the information and correctly assess whether Mode S capabilities are available or not?

[ogruetzmann]

Before ICAO FPL, the plugin would take the equipment code Euroscope presented via the plugin environment. This is a simple char variable, so only a single character is possible, meaning that with the new ICAO type string, the WTC is taken as equipment suffix (A320/M-SD...).

What I do in the pre release is to throw a regex on the whole type string to check which format it is, and either use the suffix ES provides or use the first character of the transponder type in the ICAO string (/LB1 -> L = Mode S transmitting the aircraft ID...)

Of course, this still leaves Euroscope with the wrong suffix (L,M,H,J). Unfortunately, this change came without any software being compatible, so for now we'll need to wait for the clients to catch up.

[kusterjs]

But how does the ES equipment code create an issue? I thought this was all about why this plugin was created? So the ES equipment code shouldn't bother you, or does it?

[ogruetzmann]

The plugin is for code assignment, based on the equipment only. All the rest is Euroscope. That means that for people using professional mode, there are aircraft squawking 1000 without being Mode S (coming in uncorrelated).

The equipment suffix is not an issue for the plugin (obviously, as it already works with the ICAO FPL format), but for Euroscope itself.

[kusterjs]

I see the issue with the professional mode of ES, so there might be squawk 1000 assignments based on the new ICAO FPL format, but ES does not consider this aircraft mode S capable. But this can also happen with the old system when different sets of "considered mode s" equipment codes are used among different controllers. But if I understand you correctly, this is not an issue affecting user working with the squawk 1000 set in the VFR codes field to suppress duplicates that way. I expect it will still be something to be changed by the user when an update of ES is released, but fortunately, the ICAO SUR codes are quite clear regarding the mode S capability.

[ogruetzmann]

That's indeed the reason I stopped working with professional mode.

Anyway, for the time I'm not going to end support for the old equipment suffix. If you like to have the assignment of code 1000 for aircraft using the new ICAO format, try the pre release linked above. I wasn't able to test it enough, but it should work with either format.

[ThaweK]

Hi again Oliver,

I have a suggestion regarding S-mode and plugin. We both know that first of all, ES cannot properly identify/correlate S mode FPLs with the new, icao formatted codes. We also know that Gergely, with all the honesty towards him, is not usually rushing with the updates of es, especially recently. Would it be possible to ask the plugin to force correlation when ac with new code is detected? This should be possible because plugins can determine the correlation AFAIK (according to header file), so that may be a thing? I know not many actually use professional mode, but yeah, would be fun to try it. Also, "correlate only" shouldn't cause any issues for those using Easy VATSIM or so, but I am not extremely experienced in cpp. Cheers!

[ogruetzmann]

I'll think about that one. I'm really hoping that ES implements the new format sooner rather than later, but in the meantime this might be a quick fix. The main problem with the pro mode is, that everyone can configure the mode S suffixes as they wish and Easy Mode users won't detect those. I've been using pro mode for many years, but switched to easy due to the overwhelming workload starting with corona (and that was even before ICAO entered the stage).

[ThaweK]

Great.

What is the issue with different codes used by different atc? You see somebody correlated or not who shouldn't be?

For us, it's not a big deal as we deliver entire controller package and basic setup is there - selected codes (as this plugin Readme suggests) by default (not to mention, that 90% of our controllers use easy vatsim)

[ogruetzmann]

Aircraft coming from easy mode controllers or controllers using different mode S suffixes will likely give you a big headache. I've had plenty of uncorrelated aircraft being handed over to me (which were, of course, correlated for the other controller). Simply unrealistic. Try it yourself, I've given up on pro. It doesn't work in our environment with the current traffic levels.

[ThaweK]

Okay, got it. So maybe forcing the correlation by the plugin for both ICAO and FAA codes that we all agreed on here might be thing, question is - once correlated, is ES can try to uncorrelate it? I doubt, and we'd become independent from ES/other ATC weird behavior