PSX native CPDLC for Hoppie's ACARS

[Jeroen Hoppenbrouwers]

An assertion error probably actually means something. Can you paste that here please?

[Kurt]

An assertion error probably actually means something. Can you paste that here please?

Forwarded to your email as I cant post pictures easily here

Thanks

[Jeroen Hoppenbrouwers]

Problem solved ... wrong kind of command window was used to start it.

[Kurt]

Problem solved ... wrong kind of command window was used to start it.

Yes - thought that running a command in "Windows+R" was the same as typing the same command in a command prompt window.

Thanks Hoppie for the support.

[Kurt]

Hey Hoppie.

Just a gentle request if there is any update on the development on the native PSX CPDLC integration?

Thanks in advance

Cheers

[Jeroen Hoppenbrouwers]

I'm currently off base for business but I still do want to fix up stuff sufficiently for the rest to become routine...

[Jeroen Hoppenbrouwers]

Ok, I'm back to it (don't know for how long...).

The CPDLC logon works fine and I have exchanged requests, clearances, and pilot responses.

Gary:
I notice that the ACARS side of it and the CPDLC side of it should be two different things, if people want to run BACARS next to CPDLC. And this stops the ability to just use the same callsign for both sides.

If I completely disable the "HACARS" part (no more AOC ACARS, with a switch), would it be acceptable to feed the ATC callsign "BAW123" to the ATC LOGON/STATUS page, and something derived such as "BAW123B" to the BACARS page? This assumes that only your dispatch office (and anonymous weather/ATIS services) would need to know your AOC callsign.

I have no idea how much BACARS manipulates EICAS and other things except for the <ACARS prompt. If it does, then this needs some coordination as we cannot have two captains on the same ship.

Hardy:
If the pilot requests FL370, which happens to be message 12 as generated by PSX, and then I inject an uplink "climb to FL370" in response to this using the correct ID 12, two conflicting things seem to happen.

1. The CLIMB TO FL370 message in the log, when opened, has a <REQUEST prompt that correctly leads to the request. But:
2. The log retains the request separately and it remains open forever.

2. Does NOT happen when I use the built-in CPDLC editor for the instructor. So I probably miss something. While I keep looking, any clue?

Probably I need to better read
     https://aerowinx.com/board/index.php/topic,6944.msg74832.html
which explicitly states what needs to happen if the controller responds to a request by uplinking a clearance...

Hoppie

[macroflight]

@Hoppie: will you handle PDC requests in this new "PSX-to-CPDLC bridge" (does it have a name yet?)?

If BACARS no longer needs to handle PDC (and oceanic, but I doubt anyone uses that) requests, it will probably be relatively easy to let BACARS use its own callsign when connecting to Hoppie's ACARS. It already has a flight number that is separate from the one entered into the RTE page.

There is a "CLEARANCE>" option on the ATC INDEX page in PSX, but the resulting message in the instructor station does not look like a VATSIM PDC request.

[Hardy Heinlin]

Probably I need to better read
    https://aerowinx.com/board/index.php/topic,6944.msg74832.html
which explicitly states what needs to happen if the controller responds to a request by uplinking a clearance...

Does it work?

First: Qs469="FansUpResp"
Then 1 second later the detailed instruction with: Qs467="FansUp"

[Jeroen Hoppenbrouwers]

@Hoppie: will you handle PDC requests in this new "PSX-to-CPDLC bridge" (does it have a name yet?)?

This "CPDLC for PSX" thing (no real name yet) does exactly what PSX does, in only connects the PSX CPDLC to Hoppie's ACARS with some required translations in between. If you can do what you want to do by pushing the ATC key on the MCDU than this thing will do it.

PDC is not part of this CPDLC environment as far as I know; the CPDLC DCL (who invents these acronyms?!) is something that was added much later.

So this may be a Problem™

[Gary Oliver]

The problem is we need to handle ACARS messages in BACARS sent to the Callsign connected to VATSIM for an array of use cases, the internal stuff with BACARS to server can be fixed with a dot at the beginning of the callsign.  For example  .BAW47C is BACARS and BAW47C is CPDLC but then I cant get messages sent to us by other telex stations.

Could we have a fetchtype= option on the acars server end?

BACARS can do fetchtype=telex and PSX.NotNET.Hoppie.CPDLCBridge does fetchtype=cpdlc ?

The only problem then is the clearance messages which are CPDLC type which BACARS needs so they will have to be handled differently.

Do we need some kind of client side proxy which bacars or cpdlc app run to share the data between the two programs.

One to think about I think about a bit more.

Cheers
G

[Jeroen Hoppenbrouwers]

... update ... I got the PSX responses to ACARS ATC uplinks working, indeed just by properly reading the docs. Now I am running loads of tests to see where things still break. Fortunately CPDLC isn't a huge thing as there are just a handful of basic message types. I focus first on the most common use cases.

I don't have bandwidth now to bypass BACARS for some message types, I'm sorry. Getting to work these two programs together, and fork CPDLC to my one, everything else to BACARS, and then the exceptions, will need to wait a bit.

[Jeroen Hoppenbrouwers]

Beta 1 released

 * AOC ACARS only supports receiving telex and requesting METAR for one station.
 * PSX CPDLC (ATC key on MCDU) fully implemented as far as I can see.
 * However this does not mean there are no more rough edges.

https://www.hoppie.nl/psx/python/psx-acars.html

The more reports I get (this thread please) the quicker this will become truly usable.

Gary: one of the crude workarounds is not to use poll but instead peek. This returns not only the unread messages but the whole queue (which is ugly but not impossible to handle, with the message identifiers available), and also does not register the queue entry as "relayed."

So maybe this is the best way?

* No changes to BACARS.
* The CPDLC client gets an option "BACARS MODE: CPDLC ONLY, REQUIRES BACARS FOR AOC".
* If in BACARS mode, the CPDLC client will send CPDLC messages normally, but only peek at the uplink queue and only respond to any message type that is "cpdlc".
* Let me know if there are keywords in "cpdlc" messages that I should ignore while in BACARS mode.


Hoppie

PS. To get the other side working you may want to install this stone-age thing:
https://www.hoppie.nl/acars/prg/atc/
Any other more modern CPDLC ATC client should also work. If not, please try to figure out what they do differently (use the ACARS logs) and report it here.
Be sure that you don't step on a VATSIM or IVAO ATC station. Use the None subnetwork on Hoppie's ACARS to be double sure.

[Kurt]

Thank you SO much Hoppie - Installing and testing now

[Gary Oliver]

Excellent work Hoppie!

I'll get what we look for in the cpdlc data packet for you later in the week..

I think we look for "CLRD TO" but will check.

Cheers
G

[Kurt]

A little feedback after an evening of testing:

No BACARS running for the testing.

Initial observations:

1: Starting the beta1 works fine with HACARS registering as expected on Center CDU - Weather request only worked once this evening despite many requests to different stations..

2: As soon as a new situation is loaded HACARS connection to PSX is lost - I had to ctrl-c on PSX-ACARS and restart it again with "python psx-acars.py (my hoppie code)" every time I loaded a new situ.

3: PSX did not show the "accept" logon to an active CPDLC station on VATSIM on the ATC page in the CDU before quitting the psx-acars with ctrl-c on many occations - the ">no comm" indication on the EICAS was indicatin correctly (not shown) when loged on to a station via VATSIM despite ATC page showed no successfull login.

4:PSX-ACARS kept on displaying the "acars: error {no callsign set}" error through out all sessions. I have tried GTI74L (callsign) and 5Y88 (flightnumber) but the error message persists

5: I talked with different VATSIM controllers offline and they did indeed recieve some logons from me but time ran out late sunday evening and they had to log off so we could not test any further..

I have sent a full log from the Python interpretter to your email if it is usefull

Will test further tomorrow monday.

Thanks Hoppie !!!

BR

Kurt

[Jeroen Hoppenbrouwers]

Weird -- literally everything you experienced, I do not.   :-)

Sounds like some fundamental little bit having been skipped somewhere. Try this:

 * Completely ignore the <HACARS prompt.
 * Hit ATC
 * Fill in both the ATC station and your flight ID (anything goes).
 * Hit SEND>

Then switch to the Message Log page of Hoppie's ACARS:
https://www.hoppie.nl/acars/system/log.html
and see what came out. It should be a normal REQUEST LOGON message.

Hoppie

PS. If you let me know the callsign you use, or the (fake) ATC callsign, I can easily trace the traffic.

[Jeroen Hoppenbrouwers]

1: Starting the beta1 works fine with HACARS registering as expected on Center CDU

and on the L and R CDUs, too?

1b: Weather request only worked once this evening despite many requests to different stations..

Look in the ACARS log on my web site. If nothing appears there, there is a problem on the PC side.

2: As soon as a new situation is loaded HACARS connection to PSX is lost - I had to ctrl-c on PSX-ACARS and restart it again with "python psx-acars.py (my hoppie code)" every time I loaded a new situ.

I spent a lot of time making sure this would not happen, so I wonder. I literally reload situs 100 times per work session. What does HACARS say in the console log? Do you start it in a CMD window or in another way (which I never tried)?

3: PSX did not show the "accept" logon to an active CPDLC station on VATSIM on the ATC page in the CDU before quitting the psx-acars with ctrl-c on many occations - the ">no comm" indication on the EICAS was indicatin correctly (not shown) when loged on to a station via VATSIM despite ATC page showed no successfull login.

There certainly is something missing. I will add some more debug messages on the console log, some of these I accidentally removed too early when shipping beta-01.

4:PSX-ACARS kept on displaying the "acars: error {no callsign set}" error through out all sessions. I have tried GTI74L (callsign) and 5Y88 (flightnumber) but the error message persists

You can set it either on the ATC page (Flight ID) or on the <HACARS prompt. But it needs to be there. If the No Callsign Set error appears, it has not been set or it has been deleted in some way. When you see this, there's no hope it works, nothing got sent to the ground.

5: I talked with different VATSIM controllers offline and they did indeed recieve some logons from me but time ran out late sunday evening and they had to log off so we could not test any further..

Once they get one logon request, it should work fine, but...

I have sent a full log from the Python interpretter to your email if it is usefull

It was stupid of me to delete those debug messages prematurely...


Hoppie

[Hardy Heinlin]

I spent a lot of time making sure this would not happen, so I wonder. I literally reload situs 100 times per work session.

Perhaps Kurt uses a special router software and perhaps this doesn't pass certain PSX network data which would keep the CDU add-on registration intact after situ reload? Before I check my own code details in this case, Kurt may want to tell us if that is the case.


|-|ardy

[Jeroen Hoppenbrouwers]

Next beta (#2) is available.
https://www.hoppie.nl/psx/python/psx-acars.html

01. Start PSX and load something. I use "00 Parked 001 - Sydney".
02. Clear EICAS to have a clean sheet.
03. Start psx-acars.py in the usual way, on the command line.
04. If everything is OK, EICAS now comes up with >NO COMM to indicate ACARS does not work yet.
05. Push ATC on any MCDU.
06. Logon To: fill in the ATC station, like TEST.
07. Flt No: fill in your flight number or tail number or whatever.
08. Push Logon Send>.
09. After a while ACARS comes to life and your logon request is sent out.
10. On the ATC side, accept the logon.
11. When PSX picks this up, the display flips to the logged on status. Cancel the FMC message.
12. Request FL370 or so: push ATC, Request, Altitude 370, Verify, Send.
13. ATC must respond, typically with a clearance.
14. PSX gets that, now accept the clearance.
15. ATC gets the Wilco, everybody happy.

To log off: ATC, Logon/Status, ATC COMM SELECT OFF.
Or just Ctrl-C the PSX-ACARS program.

Reloading the Situ should reset everything nicely.


Hoppie