PSX WINCTRL PFPx

[Jamie]

Crazy times, right? I used to be a "professional" programmer after dropping out of university. Back in the '80s and '90s, that was simply what you were called: a programmer.

I wrote database conversion software for law firms and notary offices, as well as software to archive unlimited numbers of documents and individual files in modern databases. It included OCR scanner support and automatic generation of official legal documents. Happy times.

Later I moved more towards the hardware side and became a systems engineer, working with data buses and networking. I collected just about every MCSE certification Bill Gates had to offer. Unix, Novell, got all the papers and the experience!

After that I got into embedded systems, tracking & tracing, GPS systems and vehicle CAN buses.

Then I made a rather abrupt career change: I've been flying professionally for more than 25 years now.

I still really miss the programming and software development world. It was a wild time.

AI definately brought back the fun in programming: I got rusty, spend hours googling how certain functions work. Now with AI you just ask "hey I want this to be done, give me some options."
But I still cannot beleive the 'Pro's' (I still know many) burn $$$$ on tokens. I mean... why!?

[Jamie]

I also threw out the encrypted Boeing fonts and used the original Martin/Hardy "Aerowinx MCDU Large and Small" TTF fonts to live-create a bitmap font for on the unit.

So I choose another route: create the Base64 from the two TTF files. Works like a charm. I'm not sure how to continue. I probably need to ask permission from Hardy+Martin?

I also choose not to use the light sensors: in the real Boeing they hardly do anything (is my experience).

[Jeroen Hoppenbrouwers]

I did wire up the light sensors (well I asked for a test of them and waved my hands and the thing said it could see me and gave numbers that made sense) but have not yet connected them. Both display backlight and keyboard backlight are independently controllable; I have now all hardware features under software control. Will experiment a bit with the sensors and the backlights; I know that on the real aircraft, the sensors only give a bias, the -BRT+ buttons are leading. The Boeing idea is that you set them once for what you like and then you should not need to touch them when the sun sets. We'll see  :-)

I think the Aerowinx fonts are already in the free domain. Ack the authors and it should be ok.

"Pros" spend major funds on tokens because of two reasons, as far as I know.

1. There are actually things that AI can do really well today, so that is just money spent on not hiring somebody to do pretty dumb but time-consuming work. Classical automation.

2. Fear Of Missing Out. "If we don't get proficient with these AI tools, then we will be overtaken left and right in 6 months, so we need to invest in our people to understand and benefit from these tools."

It will eventually hit a wall when the AI companies estimate they have enough of a stranglehold on customers to start increasing prices or force ads upon them for a discount.

And I also abrubtly changed career... from being forced to behave like a scientist "just write papers, don't do anything" to an avionics engineer.   :-)


Hoppie

[Hardy Heinlin]

I probably need to ask permission from Hardy+Martin?

Sure, you can use the font. But I don't know where it is :-)

I guess the font is stored on Hoppie's web site somewhere.

(PSX uses hard coded vector curves for all texts on the deck.)



|-|ardy

[Jamie]

Sure, you can use the font. But I don't know where it is :-)

I guess the font is stored on Hoppie's web site somewhere.

(PSX uses hard coded vector curves for all texts on the deck.)



|-|ardy

Thanks Hardy I have it already. It's in the Windows/Fonts directory. It comes with Hoppie's MCDU program. I (read-> AI) managed to implement it.

@Jeroen: yeah I choose for brightness control on display + keyboard specifically. Had it de-coupled in previous versions. I know in the real thing the keyboard backlight is controlled at the (well the 777) overhead centrally.
Maybe I'll change that to be controlled within PSX as well (Glareshield panel?). For now I found it more convenient to bind the two together.
Currently checking the possible colors. Not many, I count only 10 and I do miss inverted characters e.g. when loading Winds in RTE DATA.

[Hardy Heinlin]

In your local Aerowinx/Developers/ folder there are these two documents:

Power Sources for Panel Lights.txt
Power Sources for Indicator Lights.txt
(and Network Documentation.txt)

They describe the Q vars for the various simulated voltage values for all devices on the flight deck.
Your add-on just needs to read the respective voltage value for the related hardware brightness.

Of course, the values imply potentiometer settings and system related effects and malfunctions.

|-|ardy

[Jamie]

Thanks! From a cockpit builders point of view, this is probably what you want. I don't know if there are many (winctrl users) right now. I guess it will be optional in an upcoming version.

First a new version with the MCDU fonts plus I found an error translating the font color inversion (Qs5xx=wwwyyywww etc).

[Jamie]

Uploaded v1.30

Fallback v1.24 also still available.

[Jeroen Hoppenbrouwers]

I (AI) decoded absolutely all inputs and outputs of the thing and made a hardware-only class. In case you're interested.

Hoppie

[Jamie]

Actually I'm more interested in the color codes :-)

[Jeroen Hoppenbrouwers]

Stuck elsewhere now. Tomorrow. I've them all.

[voipmeister]

And ...

This is a real avionics SATCOM unit (ok, my own design I admit) mounted on the roof of our office in Miami, linked via Ethernet (like on the airplane) to a remote data concentrator on my desk in Miami, then via a bundle of ARINC 429 wires to another RDC in Miami, and from there via Ethernet to my PC in Lisbon. The WingCtrl MCDU is plugged into that PC using one USB-C cable, and a Python script converts the 429 words to what WingCtrl wants.

This is not a simple thing, with probably 12 software layers, but hey.
...
Hoppie

Very cool! Thanks for sharing - I bet no WinWing MCDU ever got this close to the real deal 

I am looking forward to my unit, might even get 2 more (or 3, keep a spare in case there's a stupid dispute over warranty  ).

@Hoppie, how does it compare to the real MCDU buttonwise?

[Jeroen Hoppenbrouwers]

USB / HID — VID 0x4098; PID selects panel/seat; a 2-byte destination (DID)
is fixed per family (PFP3N=31BB, MCDU=32BB, PFP7=33BB, PFP4=34BB). Report ids:
0x01 input (keys + sensors), 0x02 control (LED/backlight/palette), 0xF0
display commands, 0xF2 pixel stream.

Font — bitmap, not TTF. Glyph = 23x32, MSB-first, byte-aligned rows (3
bytes/row) behind one leading pad byte, padded to 100 bytes; 116 slots;
slot = codepoint − 0x20.  (No lead byte → glyph shifts 8 px left; continuous
23-bit packing → shear/italic.)

Display — cell = [colorLow, colorHigh] + utf8(char). First cell +1, last
+2 (start/end markers). Small-font bank = +0x16B, invert = +0x1B. Stream chunked
63 bytes per 0xF2 report. 0xF0 commands are packed with a rolling counter,
length at byte 3, and a timestamp injected at command bytes 8/9/10. The 1801
"origin" bytes (origin_x/origin_y) had no visible effect — grid position
is not movable that way.

Colours — text colour value = index × COLOR_STEP (0x21): 0 off/inherit
(unusable base) · 1 amber · 2 white · 3 cyan · 4 green · 5 magenta ·
6 red · 7 yellow · 8 blue · 9 grey · 10 grey/khaki. +0x16B =
small-font bank (same colours). Black = unlit background (no paintable black
text). FORMAT_TABLE: a=amber, w, c, g, m, r, y, o=blue, e=grey, k=khaki. The
unit is a full palette (most likely a resistor-ladder DAC per channel), not a
3-bit RGB on/off CRT — amber plus two greys require intensity control. ARINC's
set = the 8 CRT on/off colours minus blue (too dark on a flight deck) plus
amber.

Keys — 0x01 report, bytes 1-16 bitmask, (byte,bit)→name via KEY_MAP.
BRT+=(3,2), BRT-=(3,1).

Ambient sensors — same 0x01 report: two 12-bit little-endian values
(0 = dark ... 0x0FFF = bright). SENSOR_LEFT_OFFSET=17 (bytes 17-18, the
sensor left of the MENU key); SENSOR_RIGHT_OFFSET=19 (bytes 19-20, right of
the E key). Each value is mirrored again at bytes 21-24; the driver reads the
first copy. Exposed via read_sensors() → (left, right).

Annunciators & backlight (0x02 control channel) — fixed 14-byte
message: 02 <destHi> <destLo> 00 00 03 49 <channel> <value> 00 00 00 00 00.
Lamp channels (value 0/1): DSPY=0x03, FAIL=0x04, MSG=0x05, OFST=0x06,
EXEC=0x07. Backlight channels (value 0-255): keyboard=0x00,
LCD/screen=0x01. LCD and keyboard are independent; the driver links them by
default (link_backlights) so one call drives both and BRT trims them in
lockstep.

Display init / clear (0xF0 command lists) — init: 1E01, 1801 (grid
origin/size: 0x0E=14 rows, 0x18=24 cols), an 1901 palette-load block
(index → RGBA in BGR(A) byte order, copied verbatim from a working unit),
1A01, 1C01. Clear: 0401 / 0301 / 1201 / 1301 / 1001 / 0301. Fonts
upload as a 0601 head (id, 23×32 matrix, 100-byte glyph stride, 116 chars,
total size) then 0701 data in 512-byte chunks.

Brightness (BRT+/BRT-) — BrightnessControl: bias 1-24 maps to the LCD
backlight (min_level...255). A tap steps once; holding past ~1 s autorepeats,
sweeping 2-24 in ~2 s. A scratchpad block bar (an 80%-cell glyph injected
over the not-def code @/0x40) shows the level for ~2 s, then the row is
restored.

[Jeroen Hoppenbrouwers]

The keys are a bit softer in touch (rubber-like compared to very hard plastic) but the tactile click is quite close to the original. Overall the experience is great. The only thing clearly different is the resolution of the display. The original LCD MCDUs have outrageous resolution for their time and the display size (see below); this one clearly shows that it is less and since the display cannot do half-tones, antialiasing is not possible. It is not as good as PSX, obviously. But quite ok.



Note that these Aerowinx fonts were designed to mimic a real vector-drawing CRT. So they are not the best choice for a LCD MCDU.

The "Boeing" font that comes from other software is slightly larger and fatter. Both work, they need to be loaded at LRU startup by the software and there are various ways of doing this. Of course the glyph mapping is different so the software must know what to use where.



Below is a real A330 MCDU shot so you can zoom in and see the actual resolution of the LCD displays.




Hoppie

[Jamie]

I also threw out the encrypted Boeing fonts and used the original Martin/Hardy "Aerowinx MCDU Large and Small" TTF fonts to live-create a bitmap font for on the unit. Calibrated all colours, calibrated the light sensors, cleaned up, and made documentation. All in about 6 hours I guess.

I was referring to this: calibrated all colours. You can preload the color scheme, so I was wondering if you changed them.

The font conversion is not ideal, but the result is quite oke. I needed some time to align the fonts in this 23x32 glyph, ended up using 40px sized for the large fonts. I guess the result is 'ok'.
I've put it in the code as un-encrypted Base64 encoded binary. I like to keep things simple. Loads fast, result is quite good.

This needid optimizing for example:



corrected (40px):

[Jeroen Hoppenbrouwers]

Abusing the AI fast cycle to project stuff on the display, tell the thing what's wrong ("all cells are 8 pixels too far to the right and the first 8 pixels also are shifted one up"), works great.
Figuring out the correct way to get the correct colours also was done like this.

One of these days I will spend some quality time to perfect the fonts (small and large) with the correct glyphs and publish that. For today what we have is good enough.

I'm not going to miss having to fumble for days with unclear docs on outdated libraries to speak low level stuff. I realize now that software development was my tool to get things done, but not the goal of my life.  :-)  That said, I am making very, very sure that what comes out is understandable so that I could change it if required. I don't want to deliver black magic that is as unchangeable and opaque as a block of solid or even encrypted machine code.


Hoppie

[Jamie]

Well said 

[voipmeister]

Well said indeed. I do fear that some people won't have enough black box phobia and just #shipit.

Thank you both for your efforts in bending the bits for our pleasure 

[Jamie]

Note that these Aerowinx fonts were designed to mimic a real vector-drawing CRT. So they are not the best choice for a LCD MCDU.

I found some confirmation by looking at a recent post (some instagram account) these Aerowinx MCDU fonts closely represent the ones used in the 747-4 and even the -8 series. The "fatter" Boeing font which came with Mobiflight are typical 777/787 fonts. Happy to have the 747 fonts now.

Thanks Jeroen and thanks Martin and Hardy.

[Hardy Heinlin]

If I recall correctly, I used a high resolution photograph of a 744 CRT CDU screen as a reference to shape the vector graphics for the CDU fonts (the big and small fonts). Martin then fine-tuned every character even more.

Do the 777/787 LCD CDUs have antialiasing? On the CRTs the brightness control does not only set the font's brightness but also its boldness. If modern LCDs can do antialiasing, they theoretically can also vary the boldness.

Anyway, if you compare photos, Jamie, you need to compare the brightness settings as well. It's not only a photographic exposure effect but also a variable in the screen systems, I think.


Regards,

|-|ardy