PSX native CPDLC for Hoppie's ACARS

[Gary Oliver]

Haha in our case we flew 4 flights last night, each with a different callsign.

Yes only 4 print outs but just a bit annoying

Cheers
G

[Jeroen Hoppenbrouwers]

As usual over the holidays, I caught a virus and have been out for a few days. So no progress. Hopefully something happens next weekend.


Hoppie

[Jeroen Hoppenbrouwers]

Hardy: is there a way to convince the PSX side that FANS CPDLC is currently logged off? As far as I can see the only way to wipe the system clean is by pushing the ATC COMM <SELECT OFF key. This sets the FansBasics variable to a fixed string, but if I inject that string in the hope of forcing the whole thing off, it won't.

I try to achieve a full reset so that I am not stuck with the ACT CTR from a previous session, for example. I want to do this both on initial connection of my add-on to PSX, and just before breaking connection from PSX.

Also, is there a way to fill in NEXT CTR, and/or to change ACT CTR bypassing the pilot? This is needed for handoff to the next CPDLC station which is half-automatic. I can already fake this by forcing PSX to timer==1 ("sending") with a new ATC callsign in the FansBasics so it does the complete logon cycle, but this is not so pretty.

Hoppie

[Hardy Heinlin]

Hardy: is there a way to convince the PSX side that FANS CPDLC is currently logged off? As far as I can see the only way to wipe the system clean ...

I'm not sure I understand. Why "convince"? Against what? What exactly do you mean by "system" and "wipe clean"?


|-|ardy

[Jeroen Hoppenbrouwers]

I don't want PSX to have any memory of a previous CPDLC session when before a live session is opened. So I want to force the whole PSX CPDLC to zero, null, empty, off. Manually that is easy: hit ATC COMM <SELECT OFF. But can I get the same effect over the network?


Hoppie

[Hardy Heinlin]

It's been almost 15 years since I wrote this :-) I'm looking at my my code right now. "NEXT CTR" is always blank by design. The CPDLC robot doesn't simulate any station transfers (there's no database). I guess it should be possible to externally overwrite "ACT CTR" in the FansBasics Qs without changing the simulation phase, i.e. without restarting the logon process. The PSX server reads FansBasics at 1 Hz (if the Qs has changed). PSX only overwrites the "ACT CTR" in the moment when the logon is established.

These are the variables in FansBasics:

.append( (int) logonTimer ).append( ';' )
        .append( logonTo ).append( ';' )
        .append( actCtr ).append( ';' )
        .append( adsEmergOn ? 'E' : 'e' ).append( ';' )
        .append( adsMode ).append( ';' )
        .append( offsetNorm ).append( ';' )
        .append( offsetEmerg ).append( ';' )
        .append( emergDivert ).append( ';' )
        .append( sob ).append( ';' )
        .append( fuelMinutes ).append( ';' )
        .append( mcpAlt ).append( ';' )
        .append( reqAltStr ).append( ';' )
        .append( reqStepToStr ).append( ';' )
        .append( reqSpdStr ).append( ';' )
        .append( reqOffsetStr ).append( ';' )
        .append( reqOffsetAtStr ).append( ';' )
        .append( reqDirToStr ).append( ';' )
        .append( reqHdgStr ).append( ';' )
        .append( reqTrkStr ).append( ';' )
        .append( reqProcStr ).append( ';' )
        .append( reqAltFeet ).append( ';' )
        .append( repWhenStr ).append( ';' )
        .append( repWhen ).append( ';' )
        .append( repWhenAlt1 ).append( ';' )
        .append( repWhenAlt2 ).append( ';' )
        .append( isRepWhenArmed ? 'R' : 'r' ).append( ';' )
        .append( whenCanYou ).append( ';' )
        .append( whenCanWeAltMode ).append( ';' )
        .append( whenCanWeAltStr ).append( ';' )
        .append( whenCanWeSpdStr ).append( ';' )
        .append( whenCanWeBackOnRte ? 'B' : 'b' ).append( ';' )
        .append( posRepTo ).append( ';' )
        .append( posRepNext ).append( ';' )
        .append( posRepSpd ).append( ';' )
        .append( posRepEta1 ).append( ';' )
        .append( posRepEtaD ).append( ';' )
        .append( coRte ).append( ';' )
        .append( bitmask1 ).append( ';' );


bitmask1 may contain these bits:

  static final int BIT1_MAYDAY = 1 << 0;
  static final int BIT1_PAN = 1 << 1;
  static final int BIT1_DIVERT = 1 << 2;
  static final int BIT1_DES_TO = 1 << 3;
  static final int BIT1_EMERG_ON = 1 << 4;
  static final int BIT1_CANCEL_ON = 1 << 5;
  static final int BIT1_FUEL_TIME = 1 << 6;
  static final int BIT1_EMERG_FL_MODE = 1 << 7;
  static final int BIT1_EMERG_MT_MODE = 1 << 8;
  static final int BIT1_REQ_BLOCK = 1 << 9;
  static final int BIT1_REQ_CRZCLB = 1 << 10;
  static final int BIT1_REQ_VMC = 1 << 11;
  static final int BIT1_REQ_PILOT_DISC = 1 << 12;
  static final int BIT1_REQ_ALT_DUE_PF = 1 << 13;
  static final int BIT1_REQ_ALT_DUE_WX = 1 << 14;
  static final int BIT1_REQ_SPD_DUE_PF = 1 << 15;
  static final int BIT1_REQ_SPD_DUE_WX = 1 << 16;
  static final int BIT1_REQ_OFS_DUE_WX = 1 << 17;
  static final int BIT1_REQ_RTE1 = 1 << 18;
  static final int BIT1_REQ_RTE2 = 1 << 19;

[Jeroen Hoppenbrouwers]

I can get "ACT CTR" to flip, that is okay.

The only thing still missing is now how to get the thing to not accept CPDLC requests etc.

After I load situ "Basic 004 Cleared for Takeoff" and push "ATC", "<INDEX", "<REQUEST", "370", "<ALTITUDE", "VERIFY>", I see that there is no option to actually request the altitude change, as expected. I am not logged in, so I cannot make the request: "NO ATC COMM".

Send a logon and the option appears: "REQUEST SEND>".

I now need a way to make this option disappear again, accompanied by the appropriate appearance of the "ATC LOGON/STATUS" page. I can set the "ACT CTR" to nothing, which appears fine, but it does not disable the requests and then PSX simply sends requests to a "" station. Probably I need to make "ATC COMM <SELECT OFF" to go away.

For now I will handle this situation in the same way as when a logon request is actively denied: let the add-on fake a CPDLC uplink "computer says no".

[Hardy Heinlin]

When you as a human play the role of the controller, you need to deactivate the robot on the Instructor by selecting "External control". (Or "Manual control" if you use the PSX console.)

If the checkbox is set to "Random control - no restrictions", the robot will be active and will accept all requests.

[Jeroen Hoppenbrouwers]

I don't know how to explain it in a different way.

How to log off?

How to return the CPDLC system to "no ATC connection"?

From the add-on, not by the pilot pushing "<SELECT OFF"?

This is almost like the situation when timer=0 but apparently this isn't a valid state to set. It's a logon timer, not a state indicator.

[Hardy Heinlin]

In PSX the logon timer is a state setter. Each value sets a certain state.

static final int LOGON_OFF = 0,
LOGON_SENDING = 1,
LOGON_SENT = 5,
LOGON_ACCEPTED = 8,
LOGON_ON = 11;

The values in between may increase automatically at 1 Hz, but each value sets a certain state. (I call it phase instead of state.)

[Jeroen Hoppenbrouwers]

Understood. There is no such thing as a real state enforcer that will push CPDLC to the logged off state.

I now work with a logged on state with "ACT CTR" set to "". It is not ideal as PSX will happily send requests to "", but at least I can catch these requests and craft a fake response "NO ATC CONNECTION" to close the conversation.

... edit ...

No, a response isn't appropriate as this is interpreted as a clearance or request to the airplane, and now the pilot needs to respond to that.

So my only option is to return UNABLE and that's it.

I think I have no possibility to pop up an FMC message on the scratch pad such as "NO ATC CONNECTION", as extra indication what happened?

[Hardy Heinlin]

What is the difference between "logon" and "ATC connection"?

Is "logon" the connection to the ATC computers? And is "ATC connection" the connection to human beings?

Yes, you can generate a scratchpad message.

Would the real FMC generate the message "RE-LOGON TO ATC COMM" in this case?

[Jeroen Hoppenbrouwers]

An ATC connection is the result of a successful, accepted logon by the ATC station.

We are not on the real ATC system, so in 80% of all cases (I see online) a logon request goes unanswered. This is because many virtual pilots blindly assume that there is ATC and that the ATC uses CPDLC. In reality, such a reject will never happen. However also in reality the datalink CAN fail, which means a timeout on the response -- and that is the same effect.

I know that the real-world system has issues if, for example, you attempt to log on as BA123 while the flight plan was filed as BAW0123. The ground system rejects your logon attempt and there is some on-board work required to reset the thing and try again.

So I need to cover the three most common cases:
1. There is no such ATC station.
2. The ATC station is there, but rejects your logon request (because you are on the other side of the ocean, or it does not know your flight plan).
3. There is no working ACARS link.

With the possibilities I have now, I can reliably return the onboard system to a state that on the LOGON/STATUS page looks very much like not logged on, and I can catch any pilot request made to the empty ATC CTR and respond with UNABLE.

If the FMC can pop up only a limited set of messages, we would need to figure out what "unable because..." FMC message would be most appropriate. If there is a way to pop up just anything, I would say:
1. NO ATC STATION <ICAO>
2. LOGON REJECTED BY <ICAO>
3. NO DATALINK   (ideally this would be with the DATALINK READY prompt not appearing)

This is all sugar, but "computer says no" tends to be an unsatisfactory answer if you try to get things to work...


Hoppie

[Jeroen Hoppenbrouwers]

Too many other things to do, but today I got a lot to work. I pulled out my 2007 software for PS1.3 and to my amazement it all still works (also without PS1.3, it's pretty much standalone but it needs the old Broker and external MCDU etc.). I also think that the PSX implementation of ACARS and FANS is very much like that old software which makes things easier.

I have a few trips to the US in the coming weeks so not so much will move but the project is still ongoing.

[andrej]

Hello Hoppie,
Thank you for the update as I am very much looking forward to the initial release. Have a successful trips and hope to read another update soon. :-)

Best,

[Kurt]

Hey Hoppie

Any chance for a small update on the progress?

Thanks in advance

Kurt

[Jeroen Hoppenbrouwers]

I've been out four weeks and now have domestic "extra tasks" because my wife has broken her foot and is in a wheelchair for quite some time ... so that is the update ... but project is not shelved.

[Kurt]

I've been out four weeks and now have domestic "extra tasks" because my wife has broken her foot and is in a wheelchair for quite some time ... so that is the update ... but project is not shelved.

Ohh - best wishes for a speedy recovery for your wife.

Thanks for the update Hoppie.

Cheers

[Will]

Same, best wishes for a speedy and uncomplicated recovery. Ouch.

[Kurt]

Finally managed to get python to work and run PSX-ACARS in my sim - works on all 3 CDU´s simultanously (both native in PSX but also on my 3 CS CDU´s

One note so far is that I can only start HACARS by importing the py code in IDLE and run it from within there - seems the psx-acars.py file is blocked in win11 but cant unblock it under properties like I can do with DLL´s - it gives an assertion error and a bit of troubleshooting, google searches did´nt give me hints for a fix - will research more on this as it seem it is a win 11 generic issue.

Anyway - Hacars fundamentally works - Thanks Hoppie - I am SOOOO ready to test further functionality if you need it going forward.

Cheers