PSX WINCTRL PFPx

[roccod]

Hi Jamie, yes I moved it to the applications folder. Not only does it give me the message above, but the config file is jibberish?  It is the M1 Pro chipset.  Also just tested it on my MacBook Air with the M4 chip and the same result.  Previous non-GUI version 1.30 working fine.

[Jamie]

Just got home, good thing: I get the same error So I look further into it.

You can solve it by opening a terminal: Applications/ Utilities/ Terminal

then type (copy/paste):
chmod +x /Applications/Aerowinx\ PFPx\ GUI.app/Contents/MacOS/psx_winctrl_pfp

Try again: it opens a popup > Choose Done

Settings -> Privacy & Security -> scroll a bit down and click Open Anyway -> again Open Anway on the popup. You might need to enter your password. Done.

This is all because the 'App' is not signed by Apple, macOS is extra cautious here. That's why I included the source code as well. You can check the source.


Edit: wierd, it should stay on top if you use the mini version. Doesn't do that.

[Jamie]

I uploaded 1.54 I found the download link contained a version without "stay on top" when switching to the Mini-controls.

[roccod]

Thanks as always Jamie!  Working now.

[Jeroen Hoppenbrouwers]

Having loads of fun with over-engineering this thing, assisted by Claude to keep the documentation up and to do the boring work.

My goal is to get the thing to be useful as a real MCDU, connected to a real piece of avionics feeding it 429 (ARINC 739A). I'm about 99% there, the limitation is mostly that the avionics I have are not FMCs so they don't play with annunciators et al.

Yesterday at sunset I tuned in the ambient light sensors. I followed what I read here and aimed for a trim setting (the -BRT+ scale) of centered for auto-brightness all the way, from pitch black dark room to bright sunshine. And then the trim can do -11 to +11 for adjustments, with -11 == min brightness (tech level 1; 0 is really off, nothing visible, it's an LCD after all) and +11 == max brightness (255) and in between auto gets blended in. This works nicely.

I added a steep gamma correction because at near-dark of course a small step is much better visible than in the sun.

And I balanced out the keyboard backlight against the display backlight. Above a given ambient level there is no need any more for keyboard light.

I would probably not have gone this deep without the Claude (co-work) assistant. It makes dull things feasible.

Its report:

Two ambient sensors (0–4095) are averaged and smoothed, then a perceptual curve maps that light level to an auto brt (1–24). The BRT rocker sets a persistent trim T (−11...0...+12). These blend into the effective BRT: at T=0 the auto value owns the display; pushing T toward −11 or +12 overrides it down to BRT 1 or up to 24 regardless of light. That BRT then maps through a second perceptual curve to an actual backlight level (1–255). The display backlight uses that level fully; the keyboard backlight follows the same curve but switches off above BRT 7, since a bright display needs no key lighting.

Also I had it rescale the fonts that came with the original implementation (the encrypted stuff) and merge in a few Aerowinx font glyphs and move the raster around and made it much nicer.

I will put this code out "soon," there is so much to pick up for others.

As a side effect, this thing obviously will also be kicked to become a PSX MCDU. Not to compete :-) but just because it's so simple now.


Hoppie

[voipmeister]

Sounds great Hoppie! It's very nice to see the progress you and Jamie are making with this unit. I got mine to work on macOS earlier this week and it's SUCH an upgrade from the iPad RemoteCDU app, which already was a giant upgrade from 'mousing around' on the desktop.

Fun times! Looking forward to any and all iterations

[Jeroen Hoppenbrouwers]

Moved the stuff from a PC to a RasPi4 -- just works. This Pi actually fits under the panel. Not bad for an extra EUR 80 or so.

[voipmeister]

Moved the stuff from a PC to a RasPi4 -- just works. This Pi actually fits under the panel. Not bad for an extra EUR 80 or so.

Funny, I was considering the same to address the growing USB cable spaghetti - better to have ethernet spaghetti as I am used to that...

Do you think a RasPi3B would suffice as well and do you think that it could drive 3 CDU's?

[Jeroen Hoppenbrouwers]

CPU likely yes. Power, probably not. You may need external feed, but the MCDUs can take that.

[voipmeister]

Thanks, I leaning towards an extra USB hub for that setup. On the other hand, might as well use 2 RasPi's to mimic redundancy

[Jeroen Hoppenbrouwers]

I should stop this.
The MCDU head now has full auto-brightness from in the sun down to total darkness, with trim option if needed anyway, can display any monochrome (1 bit) square image (minimum 132x132) during its RESET screen, and has a completely revamped font file that has all ISO-5 ARINC 739A glyphs and renders beautifully on its native display. It also lists all WinCtrl units found on the USB, picks one if there is only one MCDU, or lets you select which one you want with a --pid switch. Color mode, monochrome mode (green default, all other colours available).

I think it will even be useful as a cockpit-themed StreamDeck this way. And competes in price, even with a RasPi3 or 4 included.

Currently it speaks "my" MCDU language (https://www.hoppie.nl/mcdu/design.html) but it's trivial to add a PSX adapter to it. I don't want to compete with Jamie's variant though.  :-)

So I built the WinCtrl base driver separately and use that to make a MCDU that listens to "my" language and has all the smart features.

I will announce when it is available as beta.

[Jamie]

Currently it speaks "my" MCDU language (https://www.hoppie.nl/mcdu/design.html) but it's trivial to add a PSX adapter to it. I don't want to compete with Jamie's variant though.  :-)

I dont mind

I did not implement this auto-brightness, because real life you don't see much of a difference. I filmed it in flight, will upload to youtube when I have the time.

[Jeroen Hoppenbrouwers]

I did not implement this auto-brightness, because real life you don't see much of a difference.

Which may be because it does work so well... it aims to never need a trim (-BRT+) and apparently it succeeds.
At least it does here  :-)


Hoppie

[Jamie]

Which may be because it does work so well... it aims to never need a trim (-BRT+) and apparently it succeeds.
At least it does here  :-)


Hoppie

That is probably true :-)

[Jeroen Hoppenbrouwers]

Got the perfect excuse to get the Airbus variant as well: I need both Boeing and Airbus for work.

The one I already have is a 747-400 variant for sure, sold as "PFP4". However it hard-reports that it is a "PFP3N" both in the USB name string and the vendor software. You can change left-center-right as a nonvolatile bus ID for easy device assignment independent of plugin location, but not the "PFPx" assignment.

Questions for WinCtrl owners:
* What model do you have (PFP3N, PFP4, PFP7, MCDU)?
* How does it report itself, both in SimAppPro and by its USB name?

I want to make sure that what I have here (the PFP3N) does not accidentally have the wrong firmware on it. I know the Boeing-style models are largely the same anyway, the Airbus-style one has different and more annunciators.

Once I have a reasonably complete library (Python module with documentation) I will put that out, so that others can use it and learn. Or teach their AI. This library isn't PSX-specific, though there is another library that will bridge to the PSX library.

The library is also helpful in determining exactly what WinCtrl hardware you have connected, where, and what it calls itself. And it has a mapper function to figure out what a new model can do if you run the module as if it were a program.


Hoppie

[PanosI]

MCDU : WINCTRL MCDU-32, WINCTRL 32 MCDU-CAPTAIN
PFP3N : WINCTRL PFP-3N, WINCTRL 3N PFP CAPTAIN
PFP7 : WINCTRL PFP-7, WINCTRL 7 PFP CAPTAIN

[Jeroen Hoppenbrouwers]

I think the WinCtrl factory firmware loading department had a weak moment.
Nonetheless the Boeing panels are pretty much alike, and keys report numbers instead of mnemonics, so... not going to bother too much.   :-)

[Jeroen Hoppenbrouwers]

I defected to the Dark Side and got myself also an "Airbus" blue MCDU panel. After a few hours figuring out the new lamps, keys, etc. everything works there, too. It isn't intended for PSX but for work.

The main issue I encountered was that although they look quite alike, the "Airbus" variant has 8 mm less vertical display bezel space. The line select keys are exactly the same at exactly the same spacing, but the top row and bottom row of the display get squeezed against the bezel, while "Boeing" has 4 mm glass free above and below. Obviously the addition of 5 lamps and 2 light sensors above the display had an effect on the available space. The display is the same, mounted in the same place, but the bezel shrunk.

Esthetically the Boeing layout comes across much better, I got all glyphs to align perfectly. The Airbus layout had to be shifted 6 pixels up to align, which is just a raster font re-alignment (2.6 ms during loading, duh) but the very top and bottom lines get visually clipped a pixel. There is nothing I can do about this except by re-rasterizing the whole font and make all glyphs smaller vertically, so that I gain those pixels back at the expense of overall character size.

Did the original MobiFlight software come with a "Boeing" font and an "Airbus" font? That may be for this reason then.

For now ... Airbus loses  :-)


Hoppie

[Jamie]

Yes it comes with 3 fonts Boeing, Airbus ams default.

[andrej]

Hoppie,
maybe it is too late, but Moza (another hardware supplier to flight- and race-simmers) released their own versions of MCDU and Boeing 737 CDU. I was considering WINCTRL for MCDU (I do have FlightSim Labs A321/A21N), but now I am thinking about Moza's option.

737 layout is the older version (not suitable for B777s and 747s): https://us.mozaracing.com/products/mb7f-fcd
MCDU: https://mozaracing.com/products/ma3f-fcd