Worldflight 2024

[Jeroen Hoppenbrouwers]

Concerning ACARS: don't connect two clients with the same callsign.

The only good way is to mirror one client to the other flight deck by some external thing at the display level. The original line protocol of Hoppie's ACARS makes it complicated for some messages to be relayed to both clients, especially METAR and ATIS etc. as these were not programmed as separate downlinks and uplinks (alas).

So I need to get back to work on my PSX-native ACARS (CPDLC) client, which should be perfectly fine on a shared cockpit as it shares the displays but not the ACARS link. Run the client on one cockpit, and the displays of the other cockpit should pick it up.

Somebody could try that today ...
https://www.hoppie.nl/psx/python/psx-acars.html


Hoppie

[macroflight]

This is a very interesting Idea. In a shared flight with 2 cockpits in different locations, how do you manage the Vatsim connection? Can you connect 2 clients to the same flight (very unlikely)....and how would you be sure the sent data to Vatsim matched and was in sync? Maybe the concept would only be possible with one connection to Vatsim....is there a way to get the Vatsim audio in and out of the other cockpit? Maybe a dedicated VOIP circuit between the 2 locations carrying received Vatsim to the remote cockpit and remote cockpit pilot audio back to the connected site?
A lot to think about, but a great idea.
Cheers, J.G.

I will make sure we write a PSX-shared-cockpit HOWTO once we have ironed out the kinks.

Right now, we're doing it like this:

- PSX Sim A becomes the shared cockpit master sim.

- PSX Sim B becomes the shared cockpit slave sim.

- The master sim will run one PSX instance in server mode

- The master sim needs a public IPv4 address. Connections to this IP port 10747 must be forwarded to the master PSX instance port 10747. Most home routers can do this kind of port forwarding.

- All other PSX instances (and addons that use the PSX network protocol such as BACARS, Remote CDU, ...) in both sims connect to the master PSX instance. To make this easier, we will initially use a TCP relay (e.g winsocat) in the slave sim that will forward connections to port 10747 to the master sim's port 10747. My using the relay in the same place the sim would normally have its server PSX instance the rest of the sim needs no reconfiguration. Later we might replace the TCP relay with a PSX router if we can find one that is available and working.

- Each sim runs the boost server on one (or more) PSX instances. PSX does not need to be the main server to run a boost server.

- We run a single copy of BACARS (which also gives us PDC through CDU C) to fetch flight plans from the master sim owner's Simfest portal account, fetch and print ATIS, etc.

- Navigraph charts/Volanta/etc - talks to each sim's local MSFS, so no change needed there

- PSX.NET.MSFS.Router: runs in both sims. It talks to both the PSX server and the boost serverm but no reconfiguration is needed since we use the TCP relay.

- PSX.NET.MSFS.Client: runs in both sims, no config change needed

- vPilot: we use the recommended VATSIM shared cockpit setup: one vPilot in each sim. One sim connects in normal mode with the correct callsign. The other sim connects in observer mode with the same callsign but with ONE random letter added at the end (e.g "BAW47CX"). The extra single letter will tell vPilot of the "BAW47CX" sim to not show "BAW47C" in the sim (otherwise that sim will display two 747s in the same location). Both pilots will be able to transmit to VATSIM ATC. The normal PSX-NET PSX/vPilot radio frequency sync will ensure that both vPilot instances are set to the same VATSIM frequency.

- PSX.NET.vPilot: only needs to run in one sim's vPilot (not sure if running it in both will break anything). This will inject the closest 7 VATSIM aircraft into the main PSX instance. All PSX instances will then see those planes and can display them on TCAS.

- Communication on the flight deck: we use a Discord voice chat (voice activated PTT). We also configure "push to mute" in Discord using the same PTT button as vPilot so that VATSIM transmissions are not also sent to the other pilot over Discord (causing echoes).

I realise the above sounds complicated, but in order to be the "slave sim" very few changes are needed to your existing PSX sim. It would be something like this:

- Install winsocat
- Start your sim normally
- Switch the main PSX instance from server to client
- Start the winsocat relay in a powershell window: "winsocat TCP-LISTEN:10747,fork TCP:<<MASTER_SIM_IP>>:10747"
- Make sure all PSX instances and addons have reconnected to "PSX" (in reality the master sim's PSX through winsocat relay)
- Stop addons we only want a single copy of (BACARS)


Given the nature of PSX, maybe I should add that if you have actual hardware in your sim, e.g movable switches - things might be less straight forward. There is of course no way that the master sim can make the fuel cutoff levers in the slave sim move... For me and QuadFan this is not an issue (as long as we agree on who is allowed to move the yoke and throttles

[Hardy Heinlin]

In a shared flight with 2 cockpits in different locations, how do you manage the Vatsim connection?

I don't know the VATSIM system, but I can tell that the PSX network will not represent two cockpits. It remains one and the same. One user is the server and the other user on the other continent is the client. It's just like adding another monitor to your local cockpit. If you change your SELCAL under the gear lever, both users will get the change. If you press the left PTT button, both users get the push. If you get an engine failure, both users get it. Etc. pp. You are in the same cockpit. Every switch action, every yoke movement, every weather parameter and every 744 system action are in sync.


|-|ardy

[macroflight]

Concerning ACARS: don't connect two clients with the same callsign.

No, we won't. If we just need PDC we will use BACARS. If we want CPDLC, the pilot-not-flying's sim can run a single instance of e.g EasyCPDLC (and with a BACARS config that does not connect to Hoppie).

But I look forward very much to being able to test your new CPDLC client. Both me and (I think) Quadfan have written a bit of Python code, so hope we can be useful beta testers.

[Kurt]

Somewhat related to Kurt's post: me and QuadFan managed to connect our sims today for our very first shared cockpit flight.

Surprisingly easy (thanks Hardy), and surprisingly good for a first attempt.

Maybe we could do something organized for WF2025? Perhaps not necessarily at the "stream 24/7 and collect money" level, but maybe a way for people to sign up for one or more legs, with or without shared cockpit or maybe even a real-life shared cockpit if Kurt and any willing locals join?

Anyone interested?

Ohh yes indeed - count me in - I have already booked vacation the whole week so I can dedicate my time to the full worldflight event this year.

Cheers

[Kurt]

So I need to get back to work on my PSX-native ACARS (CPDLC) client, which should be perfectly fine on a shared cockpit as it shares the displays but not the ACARS link. Run the client on one cockpit, and the displays of the other cockpit should pick it up.

Somebody could try that today ...
https://www.hoppie.nl/psx/python/psx-acars.html


Hoppie

Yes this works fine as it is "just" a normal Psx server - client setup where the CDU's always are in sync.

So happy if we could get the native PSX cpdlc fixed as it - at least for me - is one of the last functions of the 744 that I really miss. Using easycpdlc is very immersion breaking.

Thanks a million.

Cheers

[macroflight]

Ohh yes indeed - count me in - I have already booked vacation the whole week so I can dedicate my time to the full worldflight event this year.

Do you have a Discord account (or email) we could use to discuss this? If you don't want to post it here, send it directly to me at mats.kronberg.game(at)gmail.com and I'll get in touch.

[voipmeister]

I realise the above sounds complicated, but in order to be the "slave sim" very few changes are needed to your existing PSX sim. It would be something like this:

- Install winsocat
- Start your sim normally
- Switch the main PSX instance from server to client
- Start the winsocat relay in a powershell window: "winsocat TCP-LISTEN:10747,fork TCP:<<MASTER_SIM_IP>>:10747"
- Make sure all PSX instances and addons have reconnected to "PSX" (in reality the master sim's PSX through winsocat relay)
- Stop addons we only want a single copy of (BACARS)


Given the nature of PSX, maybe I should add that if you have actual hardware in your sim, e.g movable switches - things might be less straight forward. There is of course no way that the master sim can make the fuel cutoff levers in the slave sim move... For me and QuadFan this is not an issue (as long as we agree on who is allowed to move the yoke and throttles

Just wanted to chime in and confirm that it is easier than it looks. We got this up and running in a small amount of time and I was really pleasantly surprised by how it all works together. A big thanks from me as well Hardy, you have written the only sim that has native networking figured out completely - and I have used some add-ons over the years

But I look forward very much to being able to test your new CPDLC client. Both me and (I think) Quadfan have written a bit of Python code, so hope we can be useful beta testers.

Happy to help beta test!

Ohh yes indeed - count me in - I have already booked vacation the whole week so I can dedicate my time to the full worldflight event this year.

Same here! I'm looking forward to it - now even more so, since we know shared flight is very well possible. It adds an extra dimension to it, since the workload is a bit much for a single person.

Macroflight and I have flown a full flight on VATSIM tonight. I haven't done much online flying, but preparing the flight together and being able to discuss about flows and actions is another level of flying. I've been on the radios for all of the flight and while it was a bit too short to get in the flow it proves that the concept is working well.

On my end I was running socat on Linux which relayed all the clients to Macroflight's public IP address, where the connections were NATted to his PSX server instance. This means that all my PSX clients (and my PSX instance) all connect to an IP address on my local network. On that machine I can change the destination IP address: I can tell it connect to Macroflight's public IP, or I can declare my laptop as the PSX master instance. The clients do need to reconnect after switching ofcourse, but that is no hassle.

It was very cool to see ATIS reports and load sheets coming out of my POS thermal printer while I knew Macroflight was getting his on his printer 

Loving this and PSX rocks!

QF out 

[JG]

Seb,
Very encouraging, and it seems Macro and yourself have already done most of the thinking I was talking of! I still have quite a lot of work to do on my sim bringing it to the same spec as most others, that is, Image generation with MSFS 2024 interfaced with PSX.NET.WASM and some of the other add on software that using Gary's platform affords for easier and proper online flight.
If you have time at some point it would be great if you could email me some more info about the socat relay. I totally understand what it does and why, I'm looking for an outline of operational setup and the best place to acquire the needed program or code. There seems very little info using a web search? I would like to keep it all under windows but have no problem with adding a machine to run it and this addition would be best added while I'm in "upgrade" rather than "flight" mode.
I too would join you in congratulating Hardy on creating PSX in a manner that so easily allows for networked and shared flight simulation. Since buying PSX it has been the gift that just keeps giving even after almost 2 years of use!
Cheers and thanks to you both for this additional and exciting possibility. J.G.

[Jeroen Hoppenbrouwers]

The currently available early beta is probably enough to prove whether it works in a mirror cockpit. If somebody could try it, and give feedback, that would help. It does not yet do much but all infrastructure is there so it is "just" a matter of adding more and more details from here on.

For example I don't know yet what would be the best prompt position. I don't want to replace ACARS itself (we have BACARS etc.) in all cases. This is why the thing now temporarily has a separate HACARS prompt. And to do just CPDLC needs a slightly different mechanism. But we'll get there.


Hoppie

[voipmeister]

@JG, as Macroflight stated we will look for the kinks in the works and document the setup. That should provide ample information on how to get things going. Our setup might contain stuff that others don't have or use (like a thermal printer) - you could just omit these components. We will be refining stuff in upcoming flights!

It's great stuff to dive into really and we both like to and will share our findings with anyone interested 

@Hoppie, will discuss with Macroflight!

[macroflight]

If you have time at some point it would be great if you could email me some more info about the socat relay.

Socat is a very simple TCP relay, originally from the Unix/Linux world. I used a Windows version I found on https://github.com/firejox/WinSocat. Install: "dotnet tool install -g winsocat" in a PowerShell window. Run: "winsocat TCP-LISTEN:10747,fork TCP:123.123.123.123:10747" in a PowerShell window (I think it needs to be started as administrator) on the computer that runs your main PSX instance. Replace 123.123.123.123 with the IP address of the remote "master sim" in the shared setup.

In theory, any TCP relay should work if you don't like winsocat for some reason. If you run your main PSX instance on macOS or Linux you should be able to use the regular socat.

What it does: for each new TCP connection made to port 10747 on the relay, it starts a new TCP connection to port 10747 on the remote sim and then forwards the data between the sims in a transparent way.

[Jeroen Hoppenbrouwers]

This old thing does the same but then for PSX with additional features. There are other brokers for PSX, they all share the basic idea: decoupling PSX-server from whatever nastiness may happen to your long-distance link.

https://www.hoppie.nl/psx/router/

including https://www.hoppie.nl/psx/router/conn.html

[voipmeister]

Hoppie, would you be open for brainstorming a bit about the idea of a revamped router, maybe on a text chat in Discord?

The socat solution is working, but effectively all connections are proxied to the other side. A router probably has added benefit and Macroflight and I would love to pick your brain a bit about it.

[voipmeister]

In theory, any TCP relay should work if you don't like winsocat for some reason. If you run your main PSX instance on macOS or Linux you should be able to use the regular socat.

Can confirm. Personally I use a Linux machine with socat for the current shared cockpit testing. If you want to use Linux too, remember to open up or disable the local firewall and in the case of a real distribution (any RHEL variant ), create SELinux policies or set it to permissive.

[Jeroen Hoppenbrouwers]

Hoppie, would you be open for brainstorming a bit about the idea of a revamped router, maybe on a text chat in Discord?

I believe Gary has a much better developed Broker by now. And the guys down under probably also have something. Let's first poll them for where they are, before we break open this stone age item (that was very useful when PSX was not released yet).


Hoppie

[voipmeister]

I believe Gary has a much better developed Broker by now. And the guys down under probably also have something. Let's first poll them for where they are, before we break open this stone age item (that was very useful when PSX was not released yet).

Wilco

[Gary Oliver]

I use SimStack switch at this time, but I understand that its only for people who have simstack hardware now.

It is on my roadmap to look at a router type program with different features but for now its at the bottom of the list.

[Kurt]

Socat is a very simple TCP relay, originally from the Unix/Linux world. I used a Windows version I found on https://github.com/firejox/WinSocat. Install: "dotnet tool install -g winsocat" in a PowerShell window. Run: "winsocat TCP-LISTEN:10747,fork TCP:123.123.123.123:10747" in a PowerShell window (I think it needs to be started as administrator) on the computer that runs your main PSX instance. Replace 123.123.123.123 with the IP address of the remote "master sim" in the shared setup.

In theory, any TCP relay should work if you don't like winsocat for some reason. If you run your main PSX instance on macOS or Linux you should be able to use the regular socat.

What it does: for each new TCP connection made to port 10747 on the relay, it starts a new TCP connection to port 10747 on the remote sim and then forwards the data between the sims in a transparent way.

This worked surprisingly well - Macro and I tested out this afternoon and after messing around getting winsocat to work locally on my main PSX sim PC it was "just" a matter of changing main PSX server to client and point it to localhost - BAM - just worked with all addons and all my PSX instances without any issues so far.

Thanks Macroflight for helping out - looking forward to try some shared cockpit sessions so we can have all wrinkles ironed out well before WF2025

Cheers

[Jeroen Hoppenbrouwers]

(just information in case it happens again)

If you connect a SIM router over the long and winding internet road, it is possible that the internet link freezes up due to a (temporary) line issue somewhere. Many TCP routers will start buffering the PSX output but eventually the outbound buffer will fill up and the router will stop accepting new input. This is good, as TCP is a reliable byte stream, you cannot just drop bytes out of the middle.

When the outbound TCP link blocks, the PSX server will have to stop right there -- for the same reason, that TCP cannot just start dropping bytes.

This is not a local PSX server or router problem, but obviously it is not desired. The only good option is to break the outbound link and allow PSX to keep pushing bytes out to the Router. Some PSX Routers may have this safety valve already.

So take care, the OUTBOUND link is as important to be smooth as the INBOUND link.


Hoppie