CPDLC Logon Code Variation

[Alexander Arlow]

Hi Juha,

with "the other network" implementing CPDLC in their client as well, we will surely run into situations where our default logon codes are being used by others. We have alternate codes for each and every station, see https://wiki.vacc-austria.org/index.php?title=CPDLC_Guide#My_logon_is_taken , but this is a hassle for the controllers logging in. Also, if a neighboring station is using an alternate code, handoffs of data authority will not work seamlessly and pilots have to logon again.

Also, to differentiate between stations we have the rule, that for example when APP provides top-down service including DEL, that APP shall use the ICAO-code as logon (for example LOWW), but when TWR/GND or DEL are online, this LOWW-codes falls to them and APP uses LOWA for CPDLC only.

Therefore I would propose the following change in the handling of the virtual Topsky CPDLC logon code handling:

-) Allow the definition of several logon codes per station with different priorities.

-) When logging in with a certain CPDLC code and the logon is unsuccessfull (a definable amount of times) due to callsign being in use, automatically change the code to the next in prioritysequence. 

-) Optional, depending on how much and what data you can exchange between different topsky-stations: Broadcast the current CPDLC-logon to adjacent topsky users

-) Optional, depending on how much and what data you can exchange between different topsky-stations: Allow automatic handoff of a CPDLC code between topsky-stations. For example: LOWW_APP uses LOWW as code because no one else is online. LOWW_TWR tries to log-in with the code LOWW as well. Now if the logon is unsuccessful, check adjacent Topsky-users if they are using LOWW as logon and trigger a popup, if they want to release the code and take the next one in prioritysequence.

A config line could then look like this:

LOGIN:LOWW,LOWA,LOAW:WIEN:WR 

which means LOWW_APP (WR in our sectorfile) will look if LOWW is available - of not, try LOWA and so on.

Kind regards,

Alex

Edited January 13, 2021 by Alexander Arlow

[Juha Holopainen]

Hi,

generally speaking, I can exchange no data whatsoever with other clients unless very specific conditions exist (for example one or more suitable tracks exist whose scratchpads I can use to transmit data).

The Hoppie network is - to put it nicely - 'challenging' in many ways, one of them being its independence from the VATSIM network, causing the issue you describe. There is also no "logon" process as such, so a logon in the plugin can't fail for any reason other than failing to establish a connection to the Hoppie server or the server rejecting the connection due to an invalid Hoppie network password.

As there is a project in the works for a VATSIM-specific datalink solution, I will not be putting much effort in developing Hoppie-specific code until more information about the project such as a rough timeframe for its implementation is available.

As there's no way to automatically inform other controllers about a nonstandard logon, all the changes would need to be done manually. I have plans to introduce a warning about the logon code having been used recently (within the previous couple of minutes) by someone else when connecting to Hoppie - more specific information than that is just not available - and providing the ability to manually override the VATSIM callsign to Hoppie logon mapping, but all that is on hold now, waiting for more information on the VATSIM project.

Edited January 14, 2021 by Juha Holopainen

[Jan Doehring (1356262)]

@Alexander ArlowI approached the German part of the other network back in the early stages of CPDLC establishment in Germany (~Q2/2020). In that mail, I asked about their CPDLC usage and they said it was close to none and they would like to know our CPDLC logon codes to prevent conflicts. Maybe you want to talk to the Austrian guys then?

Edited January 16, 2021 by Jan Doehring