CPDLC, ACARS

[Alexander Cohrs]

Same here, played around with it on Central Africa Control yesterday.

 

Now trying to understand the pilot client which looks a bit more difficult to me. But by the way: As I am running X-Plane on my iMac, right now I run it without any connection to the sim on my secondary Windows Laptop. Any chance to integrate X-Plane connection some day? I am no expert for it, but as far as I understand, writing data from X-Plane to another application should be quite easy...

 

Alex

[Andrew Heath]

I am not sure if this point has been brought up, but I have a problem with the ACARS/CPDLC software from the controller's side.

 

When I give PDCs out of JFK, I need the ability to add some of my own variables to the clearances. The pre-programmed controller phrases do not work for many of things I need to do. I noticed there is an "EMPTY" slot on the controller communications panel. Am I able to program my own phrases for loading? If so, how?

[Charan Kumar]

You probably could send a "Clearance by TELEX" and then use the TELEX to send your custom clearance msg

[Andrew Heath]

Never mind, I figured it out. You have to go to "uplink.txt" and modify it.

[Charan Kumar]

Never mind, I figured it out. You have to go to "uplink.txt" and modify it.

Just realized that too. Gave it a shot with one of ZOA ctrlrs when he was flying and we were pretty darn successful. We resorted back to vox for taxi and t/o, other than it was neat!!

[Jeroen Hoppenbrouwers 8114]

As I am running X-Plane on my iMac, right now I run it without any connection to the sim on my secondary Windows Laptop. Any chance to integrate X-Plane connection some day? I am no expert for it, but as far as I understand, writing data from X-Plane to another application should be quite easy...

I am currently under time constraints but yes indeed, it should be a lot easier to interface X-Plane than MSFS. Anybody who can dump out position info and a few other items (see the pos report page for them) can inject them into the Broker with a plaintext TCP stream.

 

This one stays on my radar.

 

 

Jeroen

[Jeroen Hoppenbrouwers 8114]

When I give PDCs out of JFK, I need the ability to add some of my own variables to the clearances. The pre-programmed controller phrases do not work for many of things I need to do. I noticed there is an "EMPTY" slot on the controller communications panel. Am I able to program my own phrases for loading? If so, how?

The PDC contains so many variables that this is, also in real life, not often done by CPDLC but indeed by telex instead. You may also have noticed that the PDC comes in as a telex, as it does not travel over the specific CPDLC connection. Planes do not log on to CPDLC before they are airborne as far as I know.

 

The telex window offers you the opportunity to greatly save on typing. If you get a PDC request, click Reply, and then click on the last equivalent PDC that you sent out from the Uplink list. It will appear ready for editing. Bump up the squawk and off it goes.

 

Within reason you can modify the UPLINK.TXT file in the etc folder of your ATC client. This will allow you to add messages. But: since CPDLC is highly standardized, be careful not to break the standard. In reality, nobody has this option: CPDLC messages are encoded in simple numbers with variables. Theoretically you could translate them to French

 

On the pilot side, the program can cope with nearly everything you throw at it. However you cannot add messages. There is an etc\report.txt file which should be kept in sync with the relevant part of the ATC file, but these report requests are not very often used anyway.

 

Here's the inside of all the stuff:

http://www.eurocontrol.int/link2000/gallery/content/public/files/docomeents/DLS%20ES%2028_01_2009%20v2.1%20released_signed.pdf

I presume that sticking to these docomeents (and all others from the LINK2000+ Project) makes sense.

 

 

Jeroen

[Jeroen Hoppenbrouwers 8114]

Now trying to understand the pilot client which looks a bit more difficult to me.

Agreed. It has two complications. One is the IT side -- it consists of four programs and yes, you need all four (unless, as in your case, you don't use MSFS, so you can drop WFAcars). This ACARS/CPDLC system originated as one of many inside a large motion platform sim, so you need some extra stuff.

 

The other complication is that in real life, CPDLC is most often interfaced onto MCDUs and these boxes are not exactly built according to modern interface standards. So the whole menu and command structure is crammed into small pages. You need some training to get proficient. But hey, it's as real as it gets

 

Now I'm talking anyway. In real life, the distinction between ACARS (FMC COMM button on the 747-400 MCDU) and CPDLC (ATC button) is huge. ACARS is a nonstandard system which basically is different for each and every airline. The underlying transport protocol is standard, but the message content, format, and all interfaces are nonstandard. ACARS is mostly used for company-internal messaging and everybody builds/buys their own system. CPDLC is highly standard and although various vendors have offerings, they are extremely interoperable.

 

ACARS traditionally travels over some kind of packet radio VHF network or satellite links. CPDLC in Europe has been put on VDL mode 2 VHF links, despite the availability of Inmarsat and Iridium satellite links. Maybe these get added as an option later on. The simulated ACARS and CPDLC disregard the transport link and all run over the internet, but they do not cross.

 

 

Jeroen

[Andrew Heath]

Jeroen,

 

So should we be doing the PDCs via Telex? I know the initial PDC request comes in via Telex, but I honestly rather have the pilots connect to CPDLC. I cannot modify or have preloaded messages via Telex and this is VERY undesirable. At ZNY, we have SWAP routes and many other modifications that we would like to have at our disposal. Using CPDLC, I can program those modifications into the UPLINK.TXT file. I can send you my modified UPLINK.TXT if you are interested to see what I am talking about.

 

The formatting issues of CPDLC that you speak of, are you talking about the max character counts and what not? I have noticed this and have formatted my messages accordingly.

 

The problem I have is, are pilots going to realize to connect to CPDLC or will I have to constantly tell them via Telex to connect to CPDLC? In addition, how many people are actually using this software? I love the idea because it seems like it will minimize my workload and be more realistic for the pilot.

 

One other question I have. If we send a clearance via CPDLC, can they plug that into their FMC and use the new routes given right from there?

[Jeroen Hoppenbrouwers 8114]

So should we be doing the PDCs via Telex? I know the initial PDC request comes in via Telex, but I honestly rather have the pilots connect to CPDLC.

This is fully up to you (and your ARTCC). You could also use an undocomeented trick: if you send a pilot an unsolicited CPDLC message, you will automagically log him on. This was meant to quickly recover lost connections after a plane sim crash. But in this case, if a pilot uses the (ACARS) PDC request, and you reply by CPDLC, you establish everything in one go. Not realistic, but darn handy.

 

I cannot modify or have preloaded messages via Telex.

Yes you can: send the message template to some random sink (callsign SINK for example, or DUMP, or whatever you want). It will stick in your UPLINK list, ready for immediate callup when needed.

 

The formatting issues of CPDLC that you speak of, are you talking about the max character counts and what not? I have noticed this and have formatted my messages accordingly.

Technically, CPDLC uses a single byte code to transmit the message and then a few trailing bytes to transmit the variables in that message. So in reality, there is zero option to extend the message set: all equipment contains these byte codes and is certified, i.e., unchangable without recertification.

 

The problem I have is, are pilots going to realize to connect to CPDLC or will I have to constantly tell them via Telex to connect to CPDLC?

The dirty trick from above solves this neatly. However remember it is a dirty trick. In reality, pilots use plain old ACARS to a dedicated PDC station for their PDC, and only connect on CPDLC when airborne and instructed by voice to do so.

 

In addition, how many people are actually using this software? I love the idea because it seems like it will minimize my workload and be more realistic for the pilot.

Not so many, as the system was not introduced widely until a week ago. It has been in use for years by a limited group, simply because nobody was really interested. By now the real world is introducing CPDLC on a much larger scale (all new aircraft for above FL280 in Europe must have CPDLC from Januari 2011, and the retrofit to all other jets is scheduled two years later). This overview is a nice indication of use:

http://www.hoppie.nl/acars/system/log.html

 

One other question I have. If we send a clearance via CPDLC, can they plug that into their FMC and use the new routes given right from there?

In reality, this is also not possible. FMCs can only download canned routes from the plane's company via ACARS (and winds and several other files). Inflight mods are always done by the pilots. You can also not update their selected MCP altitude by CPDLC, for the same good reason.

 

Experimental equipment is out there that allows ATC to peek at the MCP altitude settings and sometimes the FMC route, to verify that the plane will do what ATC expects, so they can clear other planes to otherwise too dangerous altitudes and/or routes. But nothing allows ATC to either set FMC/MCP or offer new settings to the pilots.

 

 

Jeroen

[Andrew Heath]

This is fully up to you (and your ARTCC). You could also use an undocomeented trick: if you send a pilot an unsolicited CPDLC message, you will automagically log him on. This was meant to quickly recover lost connections after a plane sim crash. But in this case, if a pilot uses the (ACARS) PDC request, and you reply by CPDLC, you establish everything in one go. Not realistic, but darn handy.

 

I guess I haven't used this enough... I wasn't aware you could reply via CPDLC if you only got a Telex. Doesn't the pilot have to request login to be displayed on your plane list?

 

Yes you can: send the message template to some random sink (callsign SINK for example, or DUMP, or whatever you want). It will stick in your UPLINK list, ready for immediate callup when needed.

 

This is useful for one individual controller, but we need a preloaded set of clearances for all of our controllers to use for standardization and ease of use. The fact that I can transfer "uplink.txt" to other controllers makes the world of difference because now they have a standard set of clearances to use.

 

If you created a way to preload Telex messages that I could transfer to other controllers, then I would be more inclined to use it.

[Jeroen Hoppenbrouwers 8114]

I guess I haven't used this enough... I wasn't aware you could reply via CPDLC if you only got a Telex. Doesn't the pilot have to request login to be displayed on your plane list?

As I told you, it is a hack. You will have to manually transfer the callsign into the "Add Demo" box of your plane list, so that it appears, after which you can send it a message. CPDLC is not technically meant to reply to ACARS (telex) messages, but it can be done. And in some situations it may be handy.

 

This is useful for one individual controller, but we need a preloaded set of clearances for all of our controllers to use for standardization and ease of use. The fact that I can transfer "uplink.txt" to other controllers makes the world of difference because now they have a standard set of clearances to use.

This indeed smells more of an extension to the PDC side of ACARS (PDC via telex). It would not be over the top to add this list of precomposed telex messages. I'll chew on it today.

 

 

Jeroen

Edited August 31, 2010 at 08:04 AM by Guest

[Andrew Heath]

Do you have to manually add the aircraft to the list like a demo aircraft to use CPDLC without them logging in?

 

EDIT you just answered it. I got it, thanks.

[Jeroen Hoppenbrouwers 8114]

Somebody stepped on your transmission, say again?

[Andrew Heath]

I will send you the uplink.txt I have created for our ARTCC. Hopefully you can determine if this is the best way of creating preloaded clearances.

[Alexander Cohrs]

it should be a lot easier to interface X-Plane than MSFS. Anybody who can dump out position info and a few other items (see the pos report page for them) can inject them into the Broker with a plaintext TCP stream.

This one stays on my radar.

 

Excellent, thank you. Looking forward to it!

 

Alex

[Alexander Cohrs]

One is the IT side -- it consists of four programs and yes, you need all four (unless, as in your case, you don't use MSFS, so you can drop WFAcars).

 

In fact I found the IT side rather simple - you made good explanations on your homepage. Where I need more pratise is the MCDU modul, but as you mentioned, it surely comes with the time.

 

Alex

[John Golin]

Hoppie, some feedback on the application -

 

If I resize some windows I can lose information:

- Resizing the aircraft list to a small box I lose the 'add demo' line

- Resizing the TAAATS interface I lose some of the buttons

- Resizing the main program window I lose the status bar

 

I like being able to resize, but is there a way to prevent losing bits?

 

Also is it possible to have an option box to set the colour of the message / plane list background? Users can then set it to something similar to their normal displays. (e.g. TAAATS uses grey )

[Michael Benson]

Hello,

 

A slight problem with using telex currently is that it doesn't allow the pilot to accept or reject the PDC, in essence you are giving a clearance without a pilot accepting it.

 

At Heathrow when the crew send their PDC request the strip turns blue, when the system has sent out the clearance the strip turns salmon, and finally once the crew accepts the clearance the strip turns white again.

 

All the PDCs are done automatically (the system knows the aircrafts flightplan, squawk, routing, ATIS, etc) so 9 times out of 10 we don't even do anything when a PDC request comes in. I realise this is likely to be outside the scope of this programme and maybe could be incorporated into an ES plugin or the like.

 

There is a good link here which towards the bottom shows the PDC process from the aircrew side.

[Jeroen Hoppenbrouwers 8114]

If I resize some windows I can lose information:

- Resizing the aircraft list to a small box I lose the 'add demo' line

- Resizing the TAAATS interface I lose some of the buttons

- Resizing the main program window I lose the status bar

I like being able to resize, but is there a way to prevent losing bits?

About the only way would be to limit the minimum size of the whole thing, which sort of defeats the purpose. I could reduce the minimum size of certain widgets such as the list windows, but it is only postponing the inevitable. When too small, something needs to give.

 

The TAATS interface wasn't meant to be resized, but I didn't block it out either.

 

I'll look at it, but there is not much room to play.

 

Also is it possible to have an option box to set the colour of the message / plane list background? Users can then set it to something similar to their normal displays. (e.g. TAAATS uses grey )

Does making the background transparent work? That would be the ultimate similar colour. System menu, "No Background". I can add a colour selection window, but maybe transparent is even better.

 

 

Jeroen

[Jeroen Hoppenbrouwers 8114]

A slight problem with using telex currently is that it doesn't allow the pilot to accept or reject the PDC, in essence you are giving a clearance without a pilot accepting it.

Correct. What I saw happening is that at first voice radio contact time, ATC asks the pilot to confirm their squawk so that ATC knows the plane has received the PDC. When the clearance was not accepted, the pilot at this time states the rejection and they work it out via voice as there obviously is something nonstandard going on. PDC is only used for standard stuff.

 

But...

 

At Heathrow when the crew send their PDC request the strip turns blue, when the system has sent out the clearance the strip turns salmon, and finally once the crew accepts the clearance the strip turns white again.

This obviously is not a plain telex-style clearance system, but one where there is a clear dialog implemented. The CPDLC part does exactly this, including the colour changes of the strips and limited reply options for pilots. The ACARS (telex) variant is literally a brainless exchange of text and not meant to be part of a dialog. It's either/or.

 

Could you find out exactly what is used at Heathrow? Is this CPDLC or a dedicated application which must be installed in all participating aircraft?

 

All the PDCs are done automatically (the system knows the aircrafts flightplan, squawk, routing, ATIS, etc) so 9 times out of 10 we don't even do anything when a PDC request comes in. I realise this is likely to be outside the scope of this programme and maybe could be incorporated into an ES plugin or the like.

Not now, but there certainly are options here.

 

There is a good link here which towards the bottom shows the PDC process from the aircrew side.

Ah! That is a good reference. Will chew on it.

 

As far as I know, ACARS and all implementations of operational stuff on top is 100% company-specific, so I am surprised that there seems to be consensus on PDC via ACARS. Could you find out which part exactly is so standard that more than one company system participates in it? Or is this a typical home-base choice, where just the most important airline got interfaced into the ATC system and this by itself saves 50% or more of standard comms?

 

Currently my ACARS is nearly completely free text from the inside. I could add reply options with accept/reject choices only, but I hesitate to do this unless there is a common standard out there in the real world to follow.

 

 

Jeroen

[Michael Benson]

Morning Jeroen,

 

Unfortunatly there isn't a lot in our manuals about how PDC works, well above the interlect of a simple controller! What I have found is the following:

 

Upon receipt of a datalink Request Clearance (RCD), the strip appears in the DCL section of the stripbay and is blue (BTW we use electronic flight progress strips).

On datalink clearance issed (CLD), the strip turns salmon.

On receipt of a datalink Clearance Acknowledged (CDA), the strip automatically moves to the cleared section of the stripbay and the colouring is removed.

 

We also have the option to send a message "revert to voice" which tells the crew to just call us on the frequency, useful for when they have put the wrong stand, aircraft type, etc in.

 

I believe it is done over ACARS, however that is not definate. Also I do believe that it is an airline/software option as not every aircraft/airline does PDC us.

 

I'll do some more digging and see if I can find out some more.

[Jeroen Hoppenbrouwers 8114]

Upon receipt of a datalink Request Clearance (RCD), the strip appears in the DCL section of the stripbay and is blue (BTW we use electronic flight progress strips).

On datalink clearance issed (CLD), the strip turns salmon.

On receipt of a datalink Clearance Acknowledged (CDA), the strip automatically moves to the cleared section of the stripbay and the colouring is removed.

These colours seem to agree with the colours I put into the CPDLC ATC station, on request by a (real) Aussie controller. Maybe this part is sort of standard.

 

Also I do believe that it is an airline/software option as not every aircraft/airline does PDC us.

This would make a lot of sense. ACARS isn't formally standardised but on busy airports, the airport/ATC can of course create their own standard and if a company puts this in their own system, they may create business benefits (getting clearance earlier, etc.).

 

I'll do some more digging and see if I can find out some more.

Yes, please! Somewhere must be some spec of the underlying protocol. I [Mod - Happy Thoughts]ume it is a relatively simple plaintext protocol that happens to be masked by pretty interfaces on both sides. And if so, we can mimic it.

 

 

Jeroen

[David Zhong]

All the PDCs are done automatically (the system knows the aircrafts flightplan, squawk, routing, ATIS, etc) so 9 times out of 10 we don't even do anything when a PDC request comes in. I realise this is likely to be outside the scope of this programme and maybe could be incorporated into an ES plugin or the like.

Not now, but there certainly are options here.

 

I have noted that VATSIM-UK have developed a EuroScope plugin that allows automatic [Mod - Happy Thoughts]ignment of squawk code, SID and initial altitude. The CPDLC/ACARS transport protocol implemented by Hoppie is based on HTTP GET requests, which can be easily sent by a EuroScope plugin. As such, I think it would be an excellent opportunity for the division (if it so wishes) to integrate these two applications.

[John Golin]

I do know it's on the wish list for the TAAATSMod plugin to Euroscope...