NOW MS747 MCP Passed CMC-PSX Ground Test via Frankenrouter

[MinsooPark]

Hello everyone,

As a short follow-up on my previous post, I'd like to share a quick development update.

From now on I'll refer to my unit as MS747 MCP (MS = my initials, Minsoo).

Before showing the final production version, I'm pleased to report that the MS747 MCP now works cleanly with Aerowinx PSX 747-400 via Frankenrouter, and has successfully passed the CMC-PSX ground test for the Mode Control Panel.





Following voipmeister's suggestion, I connected the MS747 MCP through macroflight's Frankenrouter, not directly to PSX. The router correctly recognizes the device as:

clientName=MS747MCP

With this setup, I then ran CMC-PSX → Ground Tests → Autopilot Flt Dir → Mode Cont Panel as proposed by Avi Adin. The MCP completed the test successfully, and the procedure helped me uncover and fix a few minor issues along the way.



Demo video (MS747 MCP + Frankenrouter + CMC-PSX test):  https://www.youtube.com/watch?v=_qc3RvrzoOw



Once again, my sincere thanks to Hardy for an outstanding simulator, to macroflight for providing such a powerful and flexible router, and to everyone in this community who has offered guidance so far. In particular, I'd like to thank Avi Adin for creating such a practical test tool, voipmeister for the valuable suggestions on integration and acceleration, and Hans for his thoughtful advice on naming conventions and ecosystem compatibility. Your input is directly reflected in how the MS747 MCP is evolving.

Best regards,
Minsoo Park


P.S.
While testing the MCP through Frankenrouter, I noticed something I'd like to ask the community about:
the MASTER CAUTION lamp illuminates, and at the same moment, a red "FRANKENROUTER" message appears on the upper EICAS.
I'm not sure whether this is normal behavior during certain router events or if it indicates an issue with my connection setup.
If anyone has experienced this before or knows what typically causes it, I would greatly appreciate your insight.

[Jeroen Hoppenbrouwers]

Just for your assurance: EICAS can only show the messages that are 747-real, except for one free text per message type (warning, caution, ...). So this is not a PSX effect, this is 100% sure a specific text message set there by the Frankenrouter.  Now just wait for "why."   :-)

[Avi]

Wonderful,
Thank you.

I have to ask:
On the right side, on the EICAS side, there are no labels for any of the buttons (except for one). Is there a reason for that?

Thanks again and great work.

Avi

[macroflight]

P.S.
While testing the MCP through Frankenrouter, I noticed something I'd like to ask the community about:
the MASTER CAUTION lamp illuminates, and at the same moment, a red "FRANKENROUTER" message appears on the upper EICAS.
I'm not sure whether this is normal behavior during certain router events or if it indicates an issue with my connection setup.

Short answer: you do not need to worry about this.

Long answer:

Today, the FRANKENROUTER message is activated when there is more than one or less than one shared cockpit slave sim sending elevation and traffic information to PSX. In the future, it could possibly be used to indicate other kinds of serious problems with the router setup (overload, high forwarding delay?)

It is a master caution because it is a critical failure; without a single elevation source very bad things happen (e.g the PSX ground level and the MSFS one differing by thousands of feet(*)). The traffic injection is less critical, the worst that can happen there is that you see no TCAS symbols on the ND or is that they move around more than would expect, but it's bundled into the same check.

The router defaults are chosen to make it easy to use it in a shared cockpit slave sim (replacing the PSX main server), therefore some of the default values are not suitable for e.g what you're doing here (a PSX-only setup without MSFS providing elevation data).

It's on the TODO list to document other use cases besides shared cockpit better, but for now I think you can get rid of the message if you

- use the latest version of the router
- add a [sharedinfo] section to the config with "master = true"
- in the [psx] section of the config file, add "filter_elevation = false", "filter_traffic = false" and "filter_flight_controls = false"

(*) actually that's not 100% correct. The router will actually re-enable PSX's built-in elevation database if no Qi198 injection has been seen for 60 seconds, but it still makes sense to tell the shared cockpit pilot that his setup is incorrect.

[Gary Oliver]

(*) actually that's not 100% correct. The router will actually re-enable PSX's built-in elevation database if no Qi198 injection has been seen for 60 seconds, but it still makes sense to tell the shared cockpit pilot that his setup is incorrect.

Which I very much appreciated when testing out my simulator at the weekend without visuals running and it just automatically fixed everything.  Loving the franken router at the moment!

[MinsooPark]

Just for your assurance: EICAS can only show the messages that are 747-real, except for one free text per message type (warning, caution, ...). So this is not a PSX effect, this is 100% sure a specific text message set there by the Frankenrouter.  Now just wait for "why."   :-)

Hi Hoppie,

Thank you very much for the clarification.
As you predicted, Macroflight's explanation below made the reason perfectly clear.

Separately, I've learned a lot from your Python source code and it has been a great help in my own development work — thank you for making it available.

Best regards,
Minsoo

[MinsooPark]

Wonderful,
Thank you.

I have to ask:
On the right side, on the EICAS side, there are no labels for any of the buttons (except for one). Is there a reason for that?

Thanks again and great work.

Avi

Hi Avi,

Great observation — you're exactly right.

The DSP panel shown in the photo is from an early prototype using a 777 / 747-8–style layout, where the labels were intended to be engraved directly onto the buttons themselves (similar to the real-world style).



At the time, I chose that design because it included every essential function found on the 747-400 DSP panel (except for combining CANCEL/RECALL), while also offering good cross-compatibility for -8 and even 777-style setups.

However, thanks to Swiss Mark — who shared the perspective of several PSX users — I re-evaluated my approach.
Since PSX is a pure 747-400 simulator and the upcoming PMDG 747 for MSFS is also a -400, it became clear that the 744 layout should take priority for the initial release.

So I'm currently waiting for the newly revised 747-400 DSP panel PCB, which will replace the prototype design you saw.
Fortunately, the DSP section is electrically independent from the main MCP board, so offering a 747-8 upgrade kit later will be very easy — users will be able to swap panels without replacing the entire MCP.

Thanks again for your sharp eye and thoughtful question.

Best regards,
Minsoo Park

[MinsooPark]

Short answer: you do not need to worry about this.

Long answer:

Today, the FRANKENROUTER message is activated when there is more than one or less than one shared cockpit slave sim sending elevation and traffic information to PSX. In the future, it could possibly be used to indicate other kinds of serious problems with the router setup (overload, high forwarding delay?)

It is a master caution because it is a critical failure; without a single elevation source very bad things happen (e.g the PSX ground level and the MSFS one differing by thousands of feet(*)). The traffic injection is less critical, the worst that can happen there is that you see no TCAS symbols on the ND or is that they move around more than would expect, but it's bundled into the same check.

The router defaults are chosen to make it easy to use it in a shared cockpit slave sim (replacing the PSX main server), therefore some of the default values are not suitable for e.g what you're doing here (a PSX-only setup without MSFS providing elevation data).

It's on the TODO list to document other use cases besides shared cockpit better, but for now I think you can get rid of the message if you

- use the latest version of the router
- add a [sharedinfo] section to the config with "master = true"
- in the [psx] section of the config file, add "filter_elevation = false", "filter_traffic = false" and "filter_flight_controls = false"

(*) actually that's not 100% correct. The router will actually re-enable PSX's built-in elevation database if no Qi198 injection has been seen for 60 seconds, but it still makes sense to tell the shared cockpit pilot that his setup is incorrect.

Thank you very much for the detailed explanation — that clears things up perfectly.

As you said, it's now clear that the problem is simply a consequence of my current setup not matching the shared-cockpit defaults, rather than a real connection fault. Your description of how elevation and traffic sources are handled made the logic very easy to understand.

I'll update my configuration as you suggested
– using the latest router build,
– adding a [sharedinfo] section with master = true, and
– setting filter_elevation = false, filter_traffic = false, and filter_flight_controls = false in the [psx] section,
and then continue testing in a pure PSX setup.

In addition, I'm planning to set up a proper shared-cockpit test as well, using my desktop and an extra laptop to simulate a multi-sim environment. That should help me verify that the MCP behaves well not only in a simple single-PC setup but also in more complex router topologies.

Thank you again for taking the time to write such a thorough reply.

Best regards,
Minsoo Park

[Jeroen Hoppenbrouwers]

Just thinking aloud.

Many of the MCP controls are essentially just event generators -- they have no visible physical position. So when PSX, or the remote cockpit, changes a MCP setting, the physical MCP just follows.

But there are many rotaries and switches that have a position. Without a motorized backdrive, they remain static while the rest of the system switches away from under them. Since most if not all of these controls generate change events instead of continuous positions, this probably is going to work, if the non-manipulating pilot uses the displays for information and not the knob positions. And when they move the controls anyway, the system should link up quite well.

Would we want to adopt a system in which a misset switch or knob causes a local EICAS message or such, directing the local pilot to fix it?

Or do we adopt flight deck conventions where the control division between PF and PM is followed precisely and depending on autopilot engagement some controls are not to be touched by one or the other pilot? This may cause a bit of confusion which switch sits how, when roles are handed over. I am sure this has been discussed by actual dual cockpit pilots before.


Hoppie

[Hardy Heinlin]

I think the only absolute positions are the F/D switches, the A/T switch, the disengage bar, and the bank limit selector.

On most flights:
• The disengage bar remains up.
• The bank limit remains in AUTO.
• The A/T remains in ARM. – The A/T disconnection is done by the disco switches on the levers (event), and it's engaged by mode selection (event).
• The F/D switches can be in OFF, but the F/D can still be engaged by TOGA selection (event).

So it looks like there isn't much potential for hardware position disagreements.


|-|

[asboyd]

Hi Minsoo,
Is it going to be a requirement to use frankenrouter, or will the MCP be able to connect directly to the PSX server?

I am currently not looking at frankenrouter as it is not necessary in my stand alone sim.

Cheers,
AlexB

[MinsooPark]

Just thinking aloud.

Many of the MCP controls are essentially just event generators -- they have no visible physical position. So when PSX, or the remote cockpit, changes a MCP setting, the physical MCP just follows.

But there are many rotaries and switches that have a position. Without a motorized backdrive, they remain static while the rest of the system switches away from under them. Since most if not all of these controls generate change events instead of continuous positions, this probably is going to work, if the non-manipulating pilot uses the displays for information and not the knob positions. And when they move the controls anyway, the system should link up quite well.

Would we want to adopt a system in which a misset switch or knob causes a local EICAS message or such, directing the local pilot to fix it?

Or do we adopt flight deck conventions where the control division between PF and PM is followed precisely and depending on autopilot engagement some controls are not to be touched by one or the other pilot? This may cause a bit of confusion which switch sits how, when roles are handed over. I am sure this has been discussed by actual dual cockpit pilots before.


Hoppie

I think the only absolute positions are the F/D switches, the A/T switch, the disengage bar, and the bank limit selector.

On most flights:
• The disengage bar remains up.
• The bank limit remains in AUTO.
• The A/T remains in ARM. – The A/T disconnection is done by the disco switches on the levers (event), and it's engaged by mode selection (event).
• The F/D switches can be in OFF, but the F/D can still be engaged by TOGA selection (event).

So it looks like there isn't much potential for hardware position disagreements.


|-|

Hoppie, that's a very sharp observation.
You're absolutely right — in a shared-cockpit environment, if two pilots are using my MCP (or one uses mine and the other uses a different hardware MCP), positional mismatches could certainly occur. Knobs and momentary switches are safe since they only generate delta-events, but as Hardy summarized, the absolute-position components deserve attention: the F/D switches, A/T ARM switch, disengage bar, and bank limit selector.

At the same time, as Hardy mentioned, during most real-world operations those controls are rarely touched once the aircraft is set up, so the practical impact may be small. Still, in situations where pilots frequently load different scenarios, train multiple phases of flight, or start from cold-and-dark together, those discrepancies could appear more often.

I agree that providing some form of local notice — subtle enough not to break immersion, but clear enough to prompt correction — could be a helpful solution. Similar in spirit to how "FRANKENROUTER" appears on EICAS when the router detects an issue.

Thank you both, Hoppie and Hardy, for the valuable insight.
This gives me a lot to think about for improving usability in shared-cockpit scenarios.

Minsoo Park

[MinsooPark]

Hi Minsoo,
Is it going to be a requirement to use frankenrouter, or will the MCP be able to connect directly to the PSX server?

I am currently not looking at frankenrouter as it is not necessary in my stand alone sim.

Cheers,
AlexB

Hi Alex,

Not at all — it will work exactly the way you prefer.

The MCP does not require Frankenrouter.
The only change I made was adding optional input fields in the GUI so users can manually enter an IP and port if they want to. But if the user leaves these fields untouched, the MCP will automatically connect directly to PSX on localhost:10747, exactly as a standalone setup expects.

If someone does want to connect through Frankenrouter or another network setup, they can simply enter a different IP/port — the MCP will reconnect accordingly.

This preview included the Frankenrouter demonstration only because several members requested confirmation that it could work in such setups. The previous preview video showed the MCP connected directly to PSX with no router involved.

So rest assured — for a standalone sim like yours, it will connect to PSX directly with zero additional configuration.

Cheers,
Minsoo Park

[asboyd]

Thank you Minsoo,
I actually use 5 PC's in my setup. 4 run the cockpit screens (PSX) and one for scenery (P3D) and at present one is a hardware interface unit, but may expand to two for hardware I/F.

I use OpenCockpits SIOC and Nico's PSXseecon to run switches, LED's digital displays and encoders.

I have accumulated some add-on hardware like FDS CDU's x 2 and one OC CDU.

All the panels  am designing around the views from PSX to make it as close a match as possible.

The scripts I am building for SIOC and have provided a small java add-on for PSX users to run a thermal printer in the cockpit (available for free on the forum web site, just search for ACARS print)...

Cheers,
AlexB

[voipmeister]

If someone does want to connect through Frankenrouter or another network setup, they can simply enter a different IP/port — the MCP will reconnect accordingly.

Thanks for adding this, as the CPFlight FS COM software doesn't have this option I have to work around it (it will only connect to 127.0.0.1:10747 apparently), moving other stuff around...

Cheers,