WwHomeCDU - Revision history

Fabo at 18:31, 10 June 2025

2025-06-10T18:31:51Z

← Older revision		Revision as of 18:31, 10 June 2025
Line 49:		Line 49:
	=== Current state of being ===		=== Current state of being ===

	[[File:~~250515 cduwithcontroller~~.~~jpg\|frame~~\|~~center\|800px\|alt=~~CDU ~~showing Hello REVSPACE! text~~ with a ~~laptop screen showing in~~-~~development~~ version of Windows ~~Controller\|In development version of HomeCDU Controller~~, ~~first step done]]~~		<gallery widths=300 heights=200>
			File:250610_737cdu_helloworld.JPG\|737 CDU with the MobiFlight/Postman based controller
			File:250610_mcdupython.JPG\|Airbus MCDU connected to a Python-based controller set up for X-Plane TOLISS Airbus
			</gallery>

			Just after I came back from my holiday, the 737 version of the CDU arrived. Between the EXEC light and button, Menu, Prev Page and Next Page buttons, I think this one is a bit more suited to the task, actually.
			While printing the stand, I've used the MCDU to explore the other thing I've found - a multiplatform controller meant for Linux/Mac for use with X-Plane. The controller is based on Python, and I was easily able to extend it to work on Windows.

			I decided to move forward with this implementation, skipping the Windows driver, as I expect to eventually drive the CDU from a RasPi and not from a Windows PC. A Python based solution will be easier to port, and if I write it from start as a thin client (still unsure if it should be, or should it have some independent functionality) it should be easy to test by just running it locally and pretending to be the flight simulator for starters.

			The problem with that is that while the driver works well with the Airbus MCDU, it does nothing with the 737 CDU. There are some differences in the protocol I need to find.

	I've carried on with the software now, the initial version only generates a payload (simple green text of normal size) that I can copy to Postmaster, now I need to decide if I will bother implementing WebSocket or go straight for the driver.
	~~I've added a link to GitHub repo where I will be maintaining this software to the bottom of the page.~~

	=== Current next steps ===		=== Current next steps ===
Line 60:		Line 68:
	# Improve aforementioned human friendly interface to generate payloads		# Improve aforementioned human friendly interface to generate payloads
	# Figure out what to do with buttons and LEDs.		# Figure out what to do with buttons and LEDs.
			# Investigate communication differences between 737 and Airbus CDUs

	== Past state of being ==		== Past state of being ==

			=== May 15th, 2025 ===

			[[File:250515 cduwithcontroller.jpg\|frame\|center\|800px\|alt=CDU showing Hello REVSPACE! text with a laptop screen showing in-development version of Windows Controller\|In development version of HomeCDU Controller, first step done]]

			I've carried on with the software now, the initial version only generates a payload (simple green text of normal size) that I can copy to Postmaster, now I need to decide if I will bother implementing WebSocket or go straight for the driver.
			I've added a link to GitHub repo where I will be maintaining this software to the bottom of the page.

	=== May 14th, 2025 ===		=== May 14th, 2025 ===

Fabo at 19:36, 15 May 2025

2025-05-15T19:36:54Z

← Older revision		Revision as of 19:36, 15 May 2025
Line 51:		Line 51:
	[[File:250515 cduwithcontroller.jpg\|frame\|center\|800px\|alt=CDU showing Hello REVSPACE! text with a laptop screen showing in-development version of Windows Controller\|In development version of HomeCDU Controller, first step done]]		[[File:250515 cduwithcontroller.jpg\|frame\|center\|800px\|alt=CDU showing Hello REVSPACE! text with a laptop screen showing in-development version of Windows Controller\|In development version of HomeCDU Controller, first step done]]

	I've carried on with the software now, the initial version only generates a payload that I can copy to Postmaster, now I need to decide if I will bother implementing WebSocket or go straight for the driver.		I've carried on with the software now, the initial version only generates a payload (simple green text of normal size) that I can copy to Postmaster, now I need to decide if I will bother implementing WebSocket or go straight for the driver.
	I've added a link to GitHub repo where I will be maintaining this software to the bottom of the page.		I've added a link to GitHub repo where I will be maintaining this software to the bottom of the page.

Fabo at 19:32, 15 May 2025

2025-05-15T19:32:35Z

@@ Line 28: / Line 28: @@
 # estabilish connection from a windows PC to the device that allows to write to the display ✓
-# write software that will allow easy generation of payloads to the device
+# write software that will allow easy generation of payloads to the device ✓
 # integrate available driver directly with this piece of software
 # re-write driver from scratch or find a free alternative
@@ Line 48: / Line 48: @@
 === Current state of being ===
 [[File:CDU with a benchy.jpg|thumb|left|CDU with a Hello World type message, and a benchy I was experimenting with]]
@@ Line 60: / Line 76: @@
 <div style="clear: both"></div>
-=== Current next steps ===
+== External references ==
-Not yet
+Github repo with all the software:

Fabo at 10:14, 15 May 2025

2025-05-15T10:14:22Z

← Older revision		Revision as of 10:14, 15 May 2025
Line 27:		Line 27:
	=== Initial goals ===		=== Initial goals ===

	1. estabilish connection from a windows PC to the device that allows to write to the display ✓		# estabilish connection from a windows PC to the device that allows to write to the display ✓
	2. write software that will allow easy generation of payloads to the device		# write software that will allow easy generation of payloads to the device
	3. integrate available driver directly with this piece of software		# integrate available driver directly with this piece of software
	4. re-write driver from scratch or find a free alternative		# re-write driver from scratch or find a free alternative

	=== Hardware integration ===		=== Hardware integration ===
Line 64:		Line 64:
	I have two things to do next:		I have two things to do next:

	1. Aforementioned human friendly interface to generate payloads		# Aforementioned human friendly interface to generate payloads
	2. Figure out what to do with buttons and LEDs.		# Figure out what to do with buttons and LEDs.

	== Past state of being ==		== Past state of being ==

	Not yet		Not yet

Fabo: Created page with " {{Project |Name=Winwing HomeCDU |Picture=CDU.jpg |Omschrijving=Multipurpose Home Computer Display Unit (smarthome et al.) on basis of Winwing MCDU/PFP3N |Status=In progress |Contact=Fabo }} == Intro == The Winwing CDU series is a range of affordable flight simulator peripherials based on flight management computer interfaces in modern(ish) airliners. The MCDU is based on a Thales MCDU used in Airbus aircraft (A320 family), while the PFN 3N is based on..."

2025-05-14T22:36:07Z

Created page with " {{Project |Name=Winwing HomeCDU |Picture=CDU.jpg |Omschrijving=Multipurpose Home Computer Display Unit (smarthome et al.) on basis of Winwing MCDU/PFP3N |Status=In progress |Contact=Fabo }} == Intro == The Winwing CDU series is a range of affordable flight simulator peripherials based on flight management computer interfaces in modern(ish) airliners. The MCDU is based on a Thales MCDU used in Airbus aircraft (A320 family), while the PFN 3N is based on..."

New page

{{Project
|Name=Winwing HomeCDU
|Picture=CDU.jpg
|Omschrijving=Multipurpose Home Computer Display Unit (smarthome et al.) on basis of Winwing MCDU/PFP3N
|Status=In progress
|Contact=Fabo
}}

== Intro ==
The Winwing CDU series is a range of affordable flight simulator peripherials based on flight management computer interfaces in modern(ish) airliners.
The MCDU is based on a Thales MCDU used in Airbus aircraft (A320 family), while the PFN 3N is based on a Smiths Industries unit used in Boeing 737NGs.

That translates to a small but readable display, which can display 336 characters over 14 lines (24 chars each), a full alphanumeric keyboard with a smattering of special characters, some page selection buttons which are not relevant to the project, and 6 Line Select keys on each side of the display, which are used normally to interact with options displayed on screen.

The device connects to a PC over a USB-C cable, and presents as USB HID device, by default a game controller on Windows.

== Goals of the project ==
=== Overal goals ===

My eventual goal is to be able to use either/both these devices as hubs for all manner of (smart)home stuff. Being mounted at a convenient place (or places) in the house to use for tasks like
* displaying information from various sensors available, such as temperature, humidity, state of windows/doors, etc.
* timers for cooking and similar
* daily reminders for things like medication, planned events
* smart home control via Home Assistant and downstream devices e.g. zigbee lights
* maybe recipe following?

=== Initial goals ===

1. estabilish connection from a windows PC to the device that allows to write to the display ✓
2. write software that will allow easy generation of payloads to the device
3. integrate available driver directly with this piece of software
4. re-write driver from scratch or find a free alternative

=== Hardware integration ===

The eventual goal is to drive the device(s) from a RaspberryPi. This will necessitate integrating the hardware with whatever version of (most likely) Linux will run on the Pi. It seems that there are already available some Python drivers for Winwing devices built on top of PyUSB so platform-agnostic development should be OK.

=== Software integration ===

There is one relatively large decision to be made here. I have a home server. Do I consider the device with a pi as a thin client and run the logic on the home server, or do I run the logic on the Pi itself? The obvious advantage is that it's self-contained and can work independently. The disadvantage is in the maintenance, and, perhaps, performance (though I doubt that).
I will need to also have a think about designing the software to run. I definitely know already I want it to be modular.

=== Mounting ===

At some point, I will have to design a mount for the device, ideally such that will allow the Raspberry Pi to exist in the mount permanently, while the Winwing CDU can be easily detached.

== Latest progress ==

=== Current state of being ===

[[File:CDU with a benchy.jpg|thumb|left|CDU with a Hello World type message, and a benchy I was experimenting with]]
I have received the MCDU on May 13th, and started messing with it the next day.

What I have initially found, is that MobiFlight, an open-source platform for hardware controls integration with flight simulation software, already has support for Winwing CDU in beta. Unfortunately, while the platform itself is open-source, it seems that it is using a closed-source driver to drive the device (hence the goals to first integrate the existing closed driver and then replace it). At least figuring out how to interface with the driver will be easy.

For starters, I have used Postman to make a connection to websocket interface that MobiFlight is exposing to outside world to drive the display.

Unfortunately the format used for this is... not great. A JSON array of 336 arrays, each of them corresponding to a single character, each character being either empty, or having 3 elements - character to be displayed, color, size (small or large). Hence, the need to have something more user-friendly to generate payloads for testing.

<div style="clear: both"></div>

=== Current next steps ===

I have two things to do next:

1. Aforementioned human friendly interface to generate payloads
2. Figure out what to do with buttons and LEDs.

== Past state of being ==

Not yet