PSX native CPDLC for Hoppie's ACARS

[Jeroen Hoppenbrouwers]

Just a few remarks so that people have more toys to play.

Both the CRT and the LCD MCDU types are supported. On LCD you get colours. But colours alone should not be operationally important.

I did a lot of work on the EICAS displays when things do NOT work. Sabotage your ACARS (bad logon code, no callsign (you can DEL it), duplicate callsign, ...) and see what both upper and lower EICAS do. In theory you would not need to plug in a diagnostic PC to figure out what is going wrong when parked between flights with 20 minutes for the tech to fix it. Also, stop and restart the ACARS program. I did not support the CMC -- because that support needs significant support on the CMC side as well and I am not in a position to enforce other people to change their software instantly. Hey is this my work shining through? Nooooo...

Polling is done as I recommend for Hoppie's ACARS, so nothing really happens (except for the invisible "does it work?" ping at the beginning) until you actually request something.

All MCDUs are fully synchronized so if you operate two, they should show the same data.

For fun I inserted the 400 ms blanking after each key press. I do feel it is more comfortable. What are the opinions about this? Modern MCDUs are fast enough to not need this (to prevent you seeing the repainting of the display at their low bus speed) but I consider it neat.

For the Python freaks: please have a look at the code. I'm always interested in learning how other people perceive this style.


Hoppie

[Hardy Heinlin]

Code Select Expand

a = amber
[...]
y = gray background -- where is yellow?
Yellow is "amber" :-)


|-|ardy

[Jeroen Hoppenbrouwers]

I referred to the ARINC 739A colour table:

Code Select Expand

  Bits    Color
23 22 21
 0  0  0  Black
 0  0  1  Cyan
 0  1  0  Red
 0  1  1  Yellow
 1  0  0  Green
 1  0  1  Magenta
 1  1  0  Amber
 1  1  1  White


Hoppie

[Hardy Heinlin]

In PSX, like on the IDUs, there is no yellow, just amber. When the brightness is turned up, amber looks like yellow; and when turned down, it looks like orange.

Does the real CDU screen actually make any physical difference between amber and yellow, or is it just another variable for the same physical color? It's unusual. There are 6 colors with equal hue intervals and direct complementary colors: RGB and YMC. -- The 7th color ("amber") is an unusal exception, hue-wise.

[Jeroen Hoppenbrouwers]

There is no Blue in the colour mix; it's Red-Green-Cyan. I think they played with the phosphors to provide some colours that are actually useful. If the system is as simple as I think it is, then Red+Cyan=Yellow and Green+Red=Amber.

I've not yet played with an LCD MCDU to figure this out. Next time I encounter one I will run a few demos and see what they actually produce.

Next to the colour bits in the control word, there are three additional bits:

Code Select Expand

  Bits    Function
16 15 14
 0  0  1  Reverse video (optional)
 0  1  0  Underscore
 1  0  0  Flashing

I know that reverse video is supported by the 744 (and probably most other) MCDUs, but the underscore and flashing I never saw. Boeing is hard against anything flashing on the flight deck.

On the Airbus MCDU below you can see both yellow and amber but this is a sim, so no guarantees. The bottom image seems to be a real one.


Hoppie

[Will]

Beginner's question... I have never used the original Hoppie, so I don't know what this (is it called HACARS?) does. Once the new "HACARS" is fully functional, is it this:

HACARS allows a human who is simulating pilot... to exchange messages with another human who is simulating an air traffic controller?

Is that correct?

If there isn't a human simulating a controller out there, what happens? I.e., is there any HACARS functionality independent of humans simulating the other side of the conversation? Where does the weather (Linköping*, in the screenshot above) come from?

Thanks!

*) BTW, I have a good friend (since 1986) who grew up in Linköping, nice city!

[Jeroen Hoppenbrouwers]

I came up with "HACARS" just to differentiate it from Hardy's ACARS.   :-)

As the "<HACARS" prompt sits in the place of "<ACARS" I wanted something to show what is active, but this is probably temporarily.

You're basically correct that (H)ACARS is just an instant message system between people or machines, superficially quite similar to what is nowadays available for everybody on their phones. But then 1970-style.

Next to flight crew and airline staff, the original targets for ACARS, relatively recently also air traffic services have entered the mix. You can send a weather request to the system and it is picked off before it would reach your airline and answered by the server system. Most servers will get the weather from NOAA.

So in your particular case, Hoppie's ACARS does not offer much on top of Hardy's ACARS, as PSX natively already does the weather and there are usually no multiplayers.

But for the online flying community, Hoppie's ACARS turned out to be the missing link in getting many different simulators (airplanes, radar scopes, dispatchers, ...) to share the same virtual planet. PSX had access to this via the many add-ons that route through MSFS, except for the CPDLC part. I'm aiming to get that connected to Hoppie's ACARS, but the infrastructure needed for this is extensive and I built a simple demo interface on top to get that tested.

To see Hoppie's ACARS in action:
https://www.hoppie.nl/acars/system/log.html


Hoppie

PS. The "BOAS FESTAS A TODOS" is a message that I currently send to each station at their first appearance. It demonstrates nicely how much variability there is on the system, given the fairly constant total number of users. If you have 1000 people online that means every minute quite a few leave and others join.

[Will]

You can send a weather request to the system and it is picked off before it would reach your airline and answered by the server system. Most servers will get the weather from NOAA.

So if I send a weather request via (H)ACARS, from where does the weather information come from?

This is significant for me, because I'm not flying with PSX's online weather anymore. RealTraffic does a great job of injecting weather for winds aloft (which PSX doesn't do) and for ground stations. PSX ends up with the "real" weather, just through RT instead of through itself. The downside is that the PSX ACARS won't respond to weather queries, but that's not a problem because real-time weather is available to me through a number of other apps that I have open (RT, Navigraph, etc.).

If H(ACARS) fetches weather from some database, that would be good to know.

[Jeroen Hoppenbrouwers]

Hoppie's ACARS (the HACARS is just a temporary thing, let's forget about it) uses the following information sources for inforeq API requests:

METAR: NOAA
TAF: NOAA
SHORTTAF: NOAA
VATATIS: VATSIM
PEATIS: Pilot Edge

I never adjusted the weather to use the VATSIM proxy (if the logon code has been linked to VATSIM), so the PSX service to swap weather requests from NOAA to VATSIM (which may have slightly older data) is not yet available on Hoppie's ACARS.

Other items, such as load sheets, performance calculations, crew schedules etc. are provided directly by the virtual airline dispatchers. There are facilities to allow pre-flight upload of these items so that the dispatcher does not need to be live online when the airplane requests the data.

In reverse many airplanes report things like OOOI and positions to their virtual airlines automatically.

So to answer your question: it's very likely that the original source of RT and "my" weather reports is exactly the same. And PSX natively also gets weather from the NOAA servers.


Hoppie

[Jeroen Hoppenbrouwers]

Ok ... let's see whether I can get this to work.
https://aerowinx.com/board/index.php/topic,6944.msg74832.html

Before I actually connect anything to live ACARS I need to build code that essentially can replace the PSX Instructor CPDLC.

[Jeroen Hoppenbrouwers]

Is there a specific reason why the letter "o" (Oscar) is not capitalized in the Instructor interface for manual messages? It also comes through as a degree symbol. Intentional?

Enter all lowercase and press TAB:
THIS IS A TEST ABCD MNoP

But I can go back and change the "o" to "O" and then it works all fine. Does not feel like an accident.

Hoppie

[Hardy Heinlin]

In which Q variable?

[Jeroen Hoppenbrouwers]

This is when using the Instructor CPDLC page directly. It is reflected in the FansDn Qs466 as well.

[Hardy Heinlin]

This is intentional. On the PSX console, the automatic conversion to upper case is just a little extra feature in case the user forgets to type upper case text directly. It doesn't work for the "o" because in the PSX CDU that's the degree symbol. If you look at the ATC LOG message pages you will see that every "o" is turned into a degree symbol.

On the PSX console, you should directly enter upper case text and use the "o" for the degree symbol.

[Jeroen Hoppenbrouwers]

I'm not spending whole days on it but it is moving.   :-)

[Jeroen Hoppenbrouwers]

Referencing:
https://aerowinx.com/board/index.php/topic,6944.msg74832.html

Question... for obvious reasons the PSX native CPDLC never rejects a logon request. It either works all the time, or it stops (when set to External Control) waiting for the go-ahead.

Is there a neat way to let PSX know that the ground system/controller/bot explicitly rejected the logon request, or that the request timed out because there is nobody listening?

My current alternative is to fake the first uplink ATC message to reflect the actual result of the logon request.


Hoppie

[Hardy Heinlin]

Would that be the message "RE-LOGON TO ATC COMM"? That's currently not implemented, I'm sorry.

Is that just a timeout function?


|-|ardy


Messages that are not simulated are listed in the PSX manual on page 438+.

[Jeroen Hoppenbrouwers]

It's mostly to cover for two common cases:

1. There's nobody there.
2. Airplane contacts a station not able to provide cover.

Typical online ATC issues. Not likely in real life. I will simulate something.


Hoppie

[Gary Oliver]

Hoppie,

Before I have to order more paper is there any chance of stopping the test messages when we connect?

Cheers
G

[Jeroen Hoppenbrouwers]

Gary, do you mean the BOAS FESTAS PARA TODOS message which the current ACARS system sends to each new login, where "new" means "I have not seen this logon code and callsign combo for the last five minutes"? Or something entirely different?

If it is the BOAS FESTAS we need to figure out why your system does not maintain online presence. Unless you actually restart it a few dozen times per day and every time a printer thinks it's nice to print the same greeting card. I would consider that something more alike a British local custom and follow the Prime Directive  :-)

The combo (logon_code+callsign) is retained in the cache for 300 seconds. Every time the system receives any connect() call except for PING or PEEK, which are designed to be invisible and don't affect the message queue, this combo timeout is moved ahead for another 300 seconds. So as long as you send something or POLL every 299 seconds you should get the BOAS FESTAS only once.

I had one user who was over-friendly with a backend virtual airline service and only polled every 15 minutes as that was sufficient for his application. This obviously did not play well. If you have a special requirement for whatever you are doing, let me know and we can work it out. The cache expiration is important, not only for the MOTD but also for the other parts of the system.


Hoppie