I see the occasional CPDLC exchange on the message log, but few people really provide CPDLC ATC services. We might need to attract the interest of oceanic services on VATSIM and/or IVAO. Maybe a better tutorial is helpful?
Edit: A reasonable tutorial is available in the form of the WorldFlight walkthrough. You can see most of the things going on, including Dispatch and CPDLC/ATC communications. http://www.hoppie.nl/acars/example.html
What still keeps me busy is whether Eurocontrol's variant of CPDLC has a different pilot side interface than the FANS/1 console on the MCDU? Anybody knows?
Jeroen
Some remarks
A great suggestion for a CPDLC Tutorial also since Aerowinx 747-400
Precision simulator is no loner availabe and the MCDU doesn,t function
well without the PS1 software, maybe someone will create an acars device
that will link with PMDG aircraft MCDU Panel using Vatsim or IVAO communication interface Server for receiving and sending Acars messages.
thank you
Robert
Mixing up issues
Hi Robert;
You mix up four things.
We do not need another ACARS device. We need PMDG to allow access to their MCDU. And there is no need at all to involve IVAO/VATSIM.
In an ideal world, there would be open standards for MCDU access and ACARS exchanges. But the way it is today, everybody insists on building everything from scratch in their own closed environment. Instead, I offer a fully open environment, and it has already proven to work. Other authors wrote programs that display on my MCDU, and other authors wrote programs that use my ACARS server.
If PMDG opens up their MCDU, I can consider adapting ACARS to it. Not rewrite -- just adapt. If PMDG would use my open MCDU protocol, ACARS would not even need adaptation.
If others would use my open ACARS protocol, everything could interface right away.
Jeroen
PMDG and ACARS
Hi Jeroen,
Long time, no talk!
As I am a PMDG 747-400X user now for some time, I would very much like to see your ACARS/CPDLC efforts used by PMDG aircraft.
Could you suggest a form of words that I could use to place on the PMDG forum to see if we can get a positive reaction?
Kind regards, Richard
Hi Richard, It is something
Hi Richard,
It is something like: "Would it be possible to offer a published interface to control the MCDU, so that independent modules can create a new MENU entry and use the MCDU in that mode for new applications? Much like this MCDU: ... (my web site)."
I think the major barrier at this moment for any acceptance is that it must be natively inside MSFS, or else nobody picks it up. And as we all know, MSFS is not the most developer (or user) friendly operating system out there. For me, it means I cannot develop anything if it requires developing for native MSFS. If PMDG offers an interface, it must be NOT a MSFS-based interface such as FSUIPC. It must be something simple, such as the TCP socket my MCDU uses.
Jeroen
MCDU
Hi Jeroen,
I have sent an e-mail to PMDG Technical Support with words as you suggested. I shall keep you up-to-date with any replies.
As you know, MSFS supports additional non-MS content by scanning for any DLLs in its modules directory (hence inclusion of FSUIPC). Presumably you would ask for a similar function within PMDG (assuming they would supply a published interface to control the MCDU).
Then a development of something akin to Markus Vitzetum's weather radar, and an interface to the PMDG Navigation Display and we would be well on the way to a real world experience!
Cheers, Richard
Thanks for the help
Richard,
Actually, I would prefer not to use any DLL-based interface. That is quite 1990-style. A network-based interface using TCP is the way to go for any modern system, if only because this means that the new modules do not need to be running on the same machine as the MSFS operating system. On top, DLL means Windows means platform-dependent, which is also 1990-style.
Something as the MCDU is eminently network-capable and it would be a pity if it had to be run as a native module inside MSFS.
Of course any API that can be implemented in a small DLL for MSFS dropin, which then opens a TCP socket for the real communication to an external program, is an acceptable workaround. I see this happening for the new PSx free-standing simulator. It will not include external scenery except for basic runway environments, but there will probably be a dropin MSFS DLL to quickly and easily connect MSFS as the windshield (using Sim Connect).
Jeroen
Post new comment