Dear developer team,

 

as I was writing for 1,5 months to rsrandazzo and got no reply after 3 mails, I have to try it this way as we could not wait any longer for any reply of your company.

 

This was the original request and we would like to see your answer regarding this topic:

 

Dear PMDG development team,

as the PM of the VATSIM pilot client project I would like to contact you and give you some information about the situation we have and would like to ask you, if you are interested in.
As we are developing the new client, we suggested some further plugin / interface system for 3rd party software developer as there have been requests by FSL and Aersoft regarding a CPDLC datalink system.
We are setting up a complete custom VATSIM CPDLC system connected with the client deamon and as well we would like to offer it to 3rd party software developer to establish a connection for a CPDLC of their aircraft via the client to use it on VATSIM.
Therefore we have created the plugin system - which was created in C++ QT5.1 DBUS system. As well more then only the CPDLC could be connected to the client via the DBUS.
So we would like to ask you, if you are interested in any contact points for maybe a CPDLC system for your payware products in the future or ARCARS - whatever you are interested to add.
Please contact me here or via : [email protected] to let me know about your thoughts.
We have an example ready up for the DBUS system, as you would like to have a closer view how its build up and working.

Kind regards,
Sascha Steingrobe PM VATSIM pilot client project

sorry, the topic have been opened twice as there was an unexpected error from the forum.

[email protected] 

 

 

[email protected] 

...

 

 

Dear developer team,
 
as I was writing for 1,5 months to rsrandazzo and got no reply after 3 mails, I have to try it this way as we could not wait any longer for any reply of your company.

Thanks mate. Did not get that Email Adress from somewhere:)

Sounds interesting, and a step forward in realism. Good luck with the project.

Had no idea there was a new client in the works. Does anyone have a thread I can read about it?

As the VATSIM forum crashed several weeks ago, I am about to summarized the facts, the steps and pics we have posted so far for a new one. I will post a link later on.

New Vatsim Client will be very welcome.

andy a realistic ACARS and CPDLC system would be awsom. Keep up the good work, hopefully to be released soon

I cant wait to start flying on vatsim network full time. Cant stand running SB on my laptop through simconnect.

New Vatsim Client will be very welcome.

andy a realistic ACARS and CPDLC system would be awsom. Keep up the good work, hopefully to be released soon

As a complete ACARS and CPDLC system is one subproject which will be integrated into the VATSIM network, we would like to connect this feature to 3rd party developer like PMDG, Aerosoft and FSL. CPDLC system will start with the release of the new VATSIM pilot client and as well the ATC client will be updated to be fully integrated into the new service....but on the other side, it will be very quite on the COM frequency at events like Cross the Pond

How would you model ACARS isn't that a company specific item? Also I was told in the past the reason that CPDLC never took off on VATSIM was not so much the pilots but the controllers. They had made comments that CPDLC increased the work load and made it more difficult to control. What things are going to be done to push it out? Will it be mandatory use for A/C that are equiped with the system? Not trying to cast doubt on ACARS/CPDLC I really want to see it done properly and believe it could take the hobby to the next level but I hear alot of push back every time it is brought up on VATSIM and in these forums. It seems there is never a clear path on how to roll it out to the masses and make it compatable with other clients and software.

 

 

How would you model ACARS isn't that a company specific item?

 

No.  Procedures on its use would be company specific (what gets sent, company-specific acronyms, times messages are sent and so on), but the system itself is a standardized protocol.  This is why it has such widespread use: it's standardized, which makes it easily scalable.  Otherwise, it would be pretty hard (and crazy expensive) for the airlines to equip their version of ACARS into the aircraft.  The proprietary software would need to somehow be integrated into the FMS, which would take a ton of time and money.

 

 

 

Also I was told in the past the reason that CPDLC never took off on VATSIM was not so much the pilots but the controllers. They had made comments that CPDLC increased the work load and made it more difficult to control. What things are going to be done to push it out? Will it be mandatory use for A/C that are equiped with the system?

 

Not so much.  More of the issue is that the client isn't integrated into any of our software.  That means I'd have to go download Hoppie's system to interact with anyone using that system (which, in my opinion, too few do to justify my effort.)  Alternatively, one could utilize the text chat as a proxy, but the guys using Hoppie will want to use that instead, much like someone else would want to use whatever other system they have.

 

The problem isn't the workload, it's the lack of standardization.  All of the different CPDLC and ACARS messaging is its own proprietary, unique thing.  It would be like asking controllers to download every VA software to communicate with each pilot via the respective VA program.  I'll just avoid it because I'd prefer not to be switching programs all day.

 

Additionally, controllers are required to support those who require text as their means of communication (for those who have "low hearing" or whatever the PC term is this week).  As such, we're forced to deal with text anyway.  CPDLC wouldn't be any more of an issue, especially if the controller has the appropriate text alias files.

No. Procedures on its use would be company specific (what gets sent, company-specific acronyms, times messages are sent and so on), but the system itself is a standardized protocol. This is why it has such widespread use: it's standardized, which makes it easily scalable. Otherwise, it would be pretty hard (and crazy expensive) for the airlines to equip their version of ACARS into the aircraft. The proprietary software would need to somehow be integrated into the FMS, which would take a ton of time and money.

 

 

Not so much. More of the issue is that the client isn't integrated into any of our software. That means I'd have to go download Hoppie's system to interact with anyone using that system (which, in my opinion, too few do to justify my effort.) Alternatively, one could utilize the text chat as a proxy, but the guys using Hoppie will want to use that instead, much like someone else would want to use whatever other system they have.

 

The problem isn't the workload, it's the lack of standardization. All of the different CPDLC and ACARS messaging is its own proprietary, unique thing. It would be like asking controllers to download every VA software to communicate with each pilot via the respective VA program. I'll just avoid it because I'd prefer not to be switching programs all day.

 

Additionally, controllers are required to support those who require text as their means of communication (for those who have "low hearing" or whatever the PC term is this week). As such, we're forced to deal with text anyway. CPDLC wouldn't be any more of an issue, especially if the controller has the appropriate text alias files.

Thanks for the reply!

Thanks for the reply!

 

Welcome!

Strange, How could it mean more work? If it was more work why would it be in use in real life. So many times on big events i have sat for an age on the ramp trying to get my call in for clearance. Only to have other pilots jump in or be ignored by the over stressed ATC. A pre filled text message is sent in a instant. the controller gets an ordered list of requests he can browse at his own speed and reply. Messages are pre formatted. thats the whole point.