PSX native CPDLC for Hoppie's ACARS

[macroflight]

Testing now. Going M.90 towards the FIR border so I can get the handoff.

Handover did not work properly. Or maybe I didn't handle it correctly...

Code Select Expand

20550537    VATSIM    BAW32N    ESO3    cpdlc    23-19:16Z    23-19:16Z            /data2/0/36/N/WILCO
20550425    VATSIM    EFIN    BAW32N    cpdlc    23-19:11Z    23-19:11Z          /data2/37//NE/HANDOVER @ESO3
20550424    VATSIM    EFIN    BAW32N    cpdlc    23-19:11Z    23-19:11Z          /data2/36//WU/CONTACT @ESO3 131.130@_@SWEDEN CTL
20550002    VATSIM    BAW32N    EFIN    cpdlc    23-18:52Z    23-18:52Z          /data2/0/29/N/WILCO
20549986    VATSIM    EFIN    BAW32N    cpdlc    23-18:51Z    23-18:52Z          /data2/29/4/WU/CLIMB TO @FL400
20549976    VATSIM    BAW32N    EFIN    cpdlc    23-18:51Z    23-18:51Z          /data2/4/0/Y/REQUEST CLIMB TO@FL400
20549944    VATSIM    EFIN    BAW32N    cpdlc    23-18:50Z    23-18:50Z          /data2/28/3/NE/MESSAGE NOT SUPPORTED BY THIS ATS UNIT
20549939    VATSIM    BAW32N    EFIN    cpdlc    23-18:50Z    23-18:50Z          /data2/3/0/Y/REQUEST CRUISE CLIMB TO@FL400
20549739    VATSIM    BAW32N    EFIN    cpdlc    23-18:42Z    23-18:42Z          /data2/0/23/N/WILCO
20549726    VATSIM    EFIN    BAW32N    cpdlc    23-18:42Z    23-18:42Z          /data2/23/2/WU/PROCEED DIRECT TO @TADOX
20549717    VATSIM    EFIN    BAW32N    cpdlc    23-18:41Z    23-18:41Z          /data2/22/2/NE/STANDBY
20549699    VATSIM    BAW32N    EFIN    cpdlc    23-18:41Z    23-18:41Z          /data2/2/0/Y//REQUEST DIRECT TO@TADOX
20549591    VATSIM    EFIN    BAW32N    cpdlc    23-18:37Z    23-18:37Z          /data2/21//NE/CURRENT ATC UNIT@_@EFIN@_@HELSINKI CTL
20549588    VATSIM    EFIN    BAW32N    cpdlc    23-18:37Z    23-18:37Z          /data2/20/1/NE/LOGON ACCEPTED
20549577    VATSIM    BAW32N    EFIN    cpdlc    23-18:37Z    23-18:37Z

I got the "HANDOVER @ESO3" printout but no "CONTACT @ESO3 131.130@_@SWEDEN CTL" printout. The "CONTACT @ESO3 131.130@_@SWEDEN CTL" showed up in the message log. I then responded WILCO to it but that message was sent to the next controller (ESO3, which was probably discarded by the controller software since I was never logged on there).

The ACT CTR changed to ESO3, but as no logon request was sent to ESO I was never actually logged on.

Here's a random handover for another aircraft:

Code Select Expand

20549560    VATSIM    ESMM    SAS2646    cpdlc    23-18:36Z    23-18:36Z          /data2/37//NE/CURRENT ATC UNIT@_@ESMM@_@SWEDEN CTL
20549555    VATSIM    ESMM    SAS2646    cpdlc    23-18:35Z    23-18:36Z          /data2/36/7/NE/LOGON ACCEPTED
20549541    VATSIM    SAS2646    ESMM    cpdlc    23-18:35Z    23-18:35Z          /data2/7//Y/REQUEST LOGON
20549540    VATSIM    SAS2646    ESO3    cpdlc    23-18:35Z    23-18:35Z          /data2/6//Y/LOGOFF
20549520    VATSIM    ESO3    SAS2646    cpdlc    23-18:34Z    23-18:34Z          /data2/27//NE/HANDOVER @ESMM
20549423    VATSIM    ESO3    SAS2646    cpdlc    23-18:30Z    23-18:30Z          /data2/24//NE/CURRENT ATC UNIT@_@ESO3@_@SWEDEN CTL
20549420    VATSIM    ESO3    SAS2646    cpdlc    23-18:30Z    23-18:30Z          /data2/23/5/NE/LOGON ACCEPTED
20549416    VATSIM    SAS2646    ESO3    cpdlc    23-18:30Z    23-18:30Z          /data2/5//Y/REQUEST LOGON

It looks to me like we need to respond to a HANDOVER differently:

- send LOGOFF
- send REQUEST LOGON to the next station
- on LOGON ACCEPTED, set the next station as the active one

And personally I would like the "CONTACT @ESO3 131.130@_@SWEDEN CTL" message printed too. It's easier to miss an EICAS message than a paper, and that message is the only way I know that I need to call the next controller on voice.

[macroflight]

Console log for the handover:

Code Select Expand

  acars:   peek to server:
  acars:   next peek in 45 seconds
  acars:   peek to server:
  acars:   next peek in 56 seconds
  acars:   peek to server:
From ACARS:
Send ID: 36
Resp ID: -1
Up/Down: UPLINK
Type:    REQUEST
Status:  NEW
Resp Rq: WU
Text:    ['CONTACT', 'ESO3 131.130', '_', 'SWEDEN CTL']
From ACARS:
Send ID: 37
Resp ID: -1
Up/Down: UPLINK
Type:    REQUEST
Status:  NEW
Resp Rq: NA
Text:    ['HANDOVER', 'ESO3']
FANS HANDOVER to ESO3
  psx: FansBasics 9;ESO3;EFIN;e;2;0;0;EKCH;-1;165;40000;;;;;;;;;;-9999;;0;0;0;r;0;0;;;b;;;;;;;262160;
  acars:   next peek in 53 seconds
  psx: FansBasics 11;;ESO3;e;2;0;0;EKCH;-1;165;40000;;;;;;;;;;-9999;;0;0;0;r;0;0;;;b;;;;;;;262160;
FANS is logged on to ESO3 as BAW32N
  acars:   peek to server:
  acars:   next peek in 57 seconds
  acars:   peek to server:
  acars:   next peek in 58 seconds
  acars:   peek to server:
  acars:   next peek in 49 seconds
  acars:   peek to server:
  acars:   next peek in 57 seconds
  psx: FansDnResp 36;2;1761246968;;
  acars:   cpdlc to ESO3: /data2/0/36/N/wilco
  acars:   peek to server:
  acars:   next peek in 47 seconds
  acars:   peek to server:
  acars:   next peek in 54 seconds
  acars:   peek to server:
  acars:   next peek in 49 seconds
  acars:   peek to server:
  acars:   next peek in 58 seconds
  acars:   peek to server:
  acars:   next peek in 46 seconds


[Kurt]

As a supliment to Mats experience above I have flown a bit this evening fighting closing controlers but managed to get some interactions. (no handover unfortunately)

Things I noticed was that a logoff message from ATC station was not picked up by CPDLC - had to manually chose ATC COMM SELECT OFF even though logoff message from ATC was automatically printed out and also categorized as a CPDLC message on the hoppie netrwork log. (see GTI74L callsign)

Other than that the basics seem to work-  I am a bit surprised that ATC does not support requests like "When can we expect xxxx" but I guess that might differ from controller to controller

Thanks

[Jeroen Hoppenbrouwers]

Handover did not work properly. Or maybe I didn't handle it correctly...

It looks more like the controller did not handle it correctly.
 - Handover always was (well, in my 2001 code) AUTOMATIC. No logoff. No logon. Handover. The ATC stations themselves coordinate it. You see a blip on a display. And then your airplane is on the next ATC.
 - This obviously is no longer how things are being done out there.
 - Note that real life systems such as KUSA implement the handover like I do -- there is zero pilot interaction and certainly also no logoff/logon sequence. It is all done internally on the ground system.
 - Sending "please contact X on voice" and then handover means you definitely do not get the opportunity to even reply wilco to the controller, as he just handed you over. He must wait until you reply wilco and THEN handover.

So I may need to fundamentally change the interface and drop many things PSX does and generate my own CPDLC display and system.

I will see what I can do but for now, avoid handover, do everything manually. Log off, log on manually.

Concerning the message ... do I understand it correctly that the system gets it but there is no printout? I am unaware of printout. What is this?

Not seeing a logoff from ATC may also be a PSX thing but I will look at that.

[macroflight]

Concerning the message ... do I understand it correctly that the system gets it but there is no printout? I am unaware of printout. What is this?

Ignore the printout complaints.

BACARS prints all messages it receives, and it's still picking up CPDLC messages. Not sure why it missed that one. Timing issue - psc-acars.py got to that message first?

[Jeroen Hoppenbrouwers]

Well no, if PSX-ACARS is run in Stealth Mode, it won't grab messages at all. Instead it only "peeks" at the uplink queue so that BACARS can fetch everything when it gets to its turn. BACARS cannot pre-determine whether to pick up ("poll") a specific message or not, so there's nothing to fix here.

But maybe the problem lays somewhere in the content of that message. As I said before, the underscore "_" that has been inserted by ATC for some reason, is not part of the supported character set of the MCDU. I tried and PSX is smart enough to just replace it by a space, unlike real MCDUs that would instantly reset. Maybe the BACARS auto-printout cannot handle this one. Just guessing.

--- update ---

Concerning the auto-handover, even if I would implement a hard logoff-logon sequence, the response to the still pending "contact X on voice" would be lost. Only if I refuse to handoff until the pilot has responded to the "contact X" request this would work. It really is a controller problem. Adding an explicit pilot action "yes, now you can handover" is very not CPDLC. I don't know what to do about this (yet).

[macroflight]

Adding an explicit pilot action "yes, now you can handover" is very not CPDLC. I don't know what to do about this (yet).

VATSIM (not sure about real world ATC) often (but not always, the intra-Sweden handover in my example above did not, but my own Finland-to-Sweden handover did) requires that you contact the next controller on voice once even when using CPDLC. That might be why they send the "contact ... on ..." message.

The "contact ..." message is not a "yes, you can now handover" message. You are handed over to the next controller on CPDLC automatically, but you are expected to call the new controller once on voice "BAW32N, FL320, CPDLC", then you can continue on CPDLC.

What if your code did like this instead?

- remember the text and timestamp of the last "contact ..." message
- when a HANDOVER is received and there's a recent "contact..." message, you send "HANDOVER, CONTACT ... on .... and LOGOFF/LOGON MANUALLY" to PSX, which will then be shown to the pilot
- when a HANDOVER is received and there's no recent "contact ..." message, you send "HANDOVER, LOGOFF/LOGON MANUALLY" to PSX which is then shown to the pilot

[Jeroen Hoppenbrouwers]

VATSIM (not sure about real world ATC) often (but not always, the intra-Sweden handover in my example above did not, but my own Finland-to-Sweden handover did) requires that you contact the next controller on voice once even when using CPDLC. That might be why they send the "contact ... on ..." message.

This is correct. Also in the real world, CPDLC requires voice contact on standby. Often it is not "contact X on" but "monitor X on" to reduce the level of chatter, but it happens all the time. The CPDLC system may hand over the datalink automagically, but the radio needs to be tuned manually.

The "contact ..." message is not a "yes, you can now handover" message. You are handed over to the next controller on CPDLC automatically, but you are expected to call the new controller once on voice "BAW32N, FL320, CPDLC", then you can continue on CPDLC.

Yes, exactly. However, if the controller already hands you over before you even wilco that you will contact the next controller, the system breaks down. It is a timing issue. Handover at CPDLC level should not happen before the controller has received the wilco. There can be only one ATC authority, the thing is not supposed to send the wilco to the previous authority.

I agree this is not necessarily clear or intuitive.

What if your code did like this instead?

- remember the text and timestamp of the last "contact ..." message
- when a HANDOVER is received and there's a recent "contact..." message, you send "HANDOVER, CONTACT ... on .... and LOGOFF/LOGON MANUALLY" to PSX, which will then be shown to the pilot
- when a HANDOVER is received and there's no recent "contact ..." message, you send "HANDOVER, LOGOFF/LOGON MANUALLY" to PSX which is then shown to the pilot

Yes something like this. We need to cover for a few cases where controllers may not realize the immediate effect of some of their CPDLC transmissions. It would be nearly impossible to get everybody trained to use the system "as logic dictates".

I will study the real world process to see how it "should" be done, and then attempt to come up with a practical workaround for the virtual variant.

[J D ADAM]

Still having problems connecting the new BACARS to PSx

Getting a message now Quote:-

'Unhandled exception occured in your application.
Contiuing with the application will ignore the error
and will attenmt to continue. If  the  you press quit the application
will close immediately."
The process cannot access the file BACARS 8.0.8 because it is being used by another process.

Cheers
Derek

PS this question  could be transferrred to the relevent forum!

[Jeroen Hoppenbrouwers]

The process cannot access the file BACARS 8.0.8 because it is being used by another process.

A common reason for this one, is that accidentally BACARS was (attempted to be) running two times. Or possibly that the main file was being updated in the background. Just guessing.

[Jeroen Hoppenbrouwers]

By The Way.

Here's some FAA doc (L3Harris is the contractor that does most of the system integration on the ground) that illustrates CPDLC.
https://www.l3harris.com/sites/default/files/2024-02/Pilot-Handbook-%20US-Domestic-En-Route-CPDLC-013024-Final.pdf
Look at the illustrations of MCDU displays. Like on pages 12, 14, 16.

IS THAT... ? ? ?

[Jeroen Hoppenbrouwers]

Beta 5 is out:
https://www.hoppie.nl/psx/python/psx-acars.html

- Replaced the silent handover by an explicit instruction to log on to the next ATC station.
- Added ATC-induced logoff.

Since I no longer drop the CPDLC connection automatically on a handover, you should be able to normally respond to the typical CONTACT XXXX message before you log on to the next station. The actual handover message does not need a CPDLC response.

When you are not logged on at all and receive a CPDLC message, this message is simply disregarded.
When you are logged on to ATC "XXXX" and you receive a CPDLC message from "YYYY", a silent handover is performed to "YYYY". I am not entirely sure this is the most practical solution on the virtual networks, but I can imagine this is how some controllers catch you when you stroll into their airspace. I could add a generated fake uplink "ATC CHANGED TO YYYY" but first I need to know what really goes on out there.

There is work going on to implement one single KUSA "station" where the individual controllers do not directly talk to the airplanes, but relay all their traffic through one central station, and all handovers are implemented internally. This is exactly how the real KUSA works. The airplane and the ACARS system have no clue about this and will work as if there is one single KUSA. For this station you will need to retune your VHF radios when switching controller, but nothing on CPDLC.


Hoppie

[Jeroen Hoppenbrouwers]

I could add a generated fake uplink "ATC CHANGED TO YYYY" but first I need to know what really goes on out there.

What I see a lot online, is that an airplane requests a clearance using telex, after which the controller sends that clearance via CPDLC, without any logon happening at all. Then the airplane accepts the clearance and then logs on.  *boggle*

So this won't work at all with my current implementation. Take care that you MUST log on to some ATC somewhere before anything will work on CPDLC. Once you have been logged on, unexpected ATC stations that start messaging you will cause a silent handoff, but you can always manually logon to whatever station you wish to talk to.

[macroflight]

What I see a lot online, is that an airplane requests a clearance using telex, after which the controller sends that clearance via CPDLC, without any logon happening at all. Then the airplane accepts the clearance and then logs on.  *boggle*

Apart from the "then logs on" part, this is as far as I know how PDC works on VATSIM using your network.

Telex from the aircraft, then a cpdlc type message from the controller which contains the clearance, then a reply from the aircraft accepting the clearance, then a "clearance confirmed" from the controller.

PDC is usually only offered by Delivery, Ground or Tower. They almost always logon to your network with the airport ICAO code.

"Enroute CPDLC" is different, then you need to log on, and this service is mostly provided by Center and occasionally Approach, and often only above a certain FL. The callsigns can be the FIR name, the name of the sector or something like that.

If you only want to see non-PDC traffic, filter out stations whose callsigns are actual airport ICAOs, what's left should be mostly enroute CPDLC.

[macroflight]

Beta 5 is out:
https://www.hoppie.nl/psx/python/psx-acars.html

I tested handover again with beta 5, seems to work OK now.

- Got "CONTACT @EDWA 126.325@_@BREMEN CTR", accepted that
- Got the "LOG ON TO NEXT ATC EDWA" message
- Opened the LOGON/STATUS page, entered EDWA as LOGON ON, pressed LOGON SEND
- Got "CURRENT ATC UNIT EDWA"

A handover to unicom also worked:

- Got "ATC SERVICE TERMINATED MONITOR 122.8", accepted that
- Got "ATC COMM TERMINATED" and PSX' CPDLC then was logged off, so no manual step needed

[Jeroen Hoppenbrouwers]

Which callsign did you use? I then can track the communication (need this within 24 hours because the log queue moves forward).

Any other remark?

[macroflight]

Which callsign did you use? I then can track the communication (need this within 24 hours because the log queue moves forward).

Any other remark?

BAW32N, flight was evening October 26th.

No other remarks, it's sometimes hard to find ATC that provides CPDLC. I use it whenever I can.

But overall I think it is in good shape now. Assuming it always works like it did on this flight I'm happy with your code. I can live with semi-manual handover.

The only annoying thing right now is that BACARS picks up a new CPDLC message almost instantly and prints it, but it then takes a number of seconds before ATC MESSAGE is shown on EICAS and I can actually see that message in the PSX ATC menu. This breaks immersion somewhat.

But the best fix for that is probably to get BACARS to ignore CPDLC messages, but that might not be trivial since the PDC traffic that BACARS needs to handle is also type CPDLC...

[Jeroen Hoppenbrouwers]

https://www.hoppie.nl/acars/system/callsign.html?network=VATSIM&callsign=BAW32N
(will be available for 24 hours since the message was received)

In the real world, there are two systems in use. Most CPDLC "out there" is between separate centers that hand over between themselves in the classical way using whatever ground systems they have, but they do not trigger auto-handover in airplanes that use CPDLC. You need to manually logon to the next center as far as I know. Within a center, which may cover multiple sectors, the CPDLC handover is invisible to the airplane.

As far as I know the only large area that has multiple centers that still use the same ground system, is the USA. They created a virtual center "KUSA" where the auto-handover at CPDLC level is not done by the airplane at all, but all on the ground. You get to retune your radios all the time but never to log on to the next center, it remains "KUSA" for as long as you are in their domestic airspace. Online there is some motion to develop a virtual "KUSA". In the real world there is also motion to develop "EURO" or whatever it will be, but since in Europe every country runs their own ground system, this won't be any time soon. MUAC (Maastricht) leads the way here. Maybe "EUAC" :-)

So for now the manual logon at handover is exactly what you would see in reality, as far as I know.

BACARS only processes specific CPDLC messages, so it "should" be able to filter for these, I think.

[Gary Oliver]

BAW32N, flight was evening October 26th.

No other remarks, it's sometimes hard to find ATC that provides CPDLC. I use it whenever I can.

But overall I think it is in good shape now. Assuming it always works like it did on this flight I'm happy with your code. I can live with semi-manual handover.

The only annoying thing right now is that BACARS picks up a new CPDLC message almost instantly and prints it, but it then takes a number of seconds before ATC MESSAGE is shown on EICAS and I can actually see that message in the PSX ATC menu. This breaks immersion somewhat.

But the best fix for that is probably to get BACARS to ignore CPDLC messages, but that might not be trivial since the PDC traffic that BACARS needs to handle is also type CPDLC...

Maybe one more thing on my pre world flight todo list

[macroflight]

So for now the manual logon at handover is exactly what you would see in reality, as far as I know.

I like that. Please don't change it. We just need to remember that its different than other clients.

One thing I'm wondering about if is the long (if feels longer than with other CPDLC clients) delay between the time the controller sends the message and the time I can reply "WILCO".

Is it realistic?

If it is realistic, will VATSIM ATC know this or will they assume we're just slow to respond?

Looking at the log from yesterday, it seems it took 1-2 minutes between instruction and WILCO. I'm pretty sure I replied promptly, because I was forewarned by the BACARS printout that there would be an ATC MESSAGE soon.

Code Select Expand

20604792    VATSIM    BAW32N    EDWA    cpdlc    26-21:01Z    26-21:02Z          /data2/0/46/N/WILCO
20604772    VATSIM    EDWA    BAW32N    cpdlc    26-21:00Z    26-21:00Z          /data2/46/5/WU/CLIMB TO @FL360

20604649    VATSIM    BAW32N    EKDK    cpdlc    26-20:53Z    26-20:53Z          /data2/0/52/N/WILCO
20604633    VATSIM    EKDK    BAW32N    cpdlc    26-20:52Z    26-20:52Z          /data2/52//WU/CONTACT @EDWA 126.325@_@BREMEN CTR

20604580    VATSIM    BAW32N    EKDK    cpdlc    26-20:49Z    26-20:50Z          /data2/0/49/N/WILCO
20604564    VATSIM    EKDK    BAW32N    cpdlc    26-20:48Z    26-20:48Z          /data2/49//WU/PROCEED DIRECT TO @RIMET