Hi ,
I'm brand new to PSX and I have to say that it greatly exceeded my expectations and the price I can only say is fair for the complexity of the simulation.
Now I´m trying to setup CPDLC using the Hoopie network, and I assume that the it can directly integrate ( by this I mean to replace the default CPDLC implementation) but I have been unable to make it happen.
When I followed the online tutorial here https://www.hoppie.nl/acars/prg/air/, but in the end it reports Something wrong with your PS1.3 PAth setting.
So the question is , can Hoopie CPDLC replace the one by PSX or how do you guys fly online using CPDLC and PSX ?
Thanks !
Hi,
This is a project a few of us were looking to pick up but no one did.
It's currently not possible to use PSX CPDLC with Hoppie/VATSIM.
Maybe a project for a cold winters weekend.
Cheers
Gary
Thanks Gary , I will try using MSFS + WidePSX + The all-in-one package.
Thanks :D
My ACARS network is still fine but the old PS1.3 software definitely has not been adjusted for PSX.
To fly online you first need to get something else to work, just connecting ACARS isn't sufficient as no controller would see you. You need to get one of the many scenery generators to link up with PSX and then the usual software for this scenery generator will provide the ATC link.
I've never thought about inserting the old CPDLC client for PS1.3 into PSX however it may be time to do so. CPDLC has seen a tremendous explosion in interest over the last two years. Probably because it finally got rolled out in the real world as well.
No promises ... but ...
Hoppie
(with one "o")
Yes please Hoppie!
Oh yeah, please do it
Please Hoppie :) I'm one of the 'didn't get to it' ones... I couldn't work out a good integration as PSX always took control of some things (e.g. accepting logon).
Still a couple of weeks to go to WorldFlight. lol!
I don't think I can "take over" the PSX CPDLC, it would become a new add-on with a new prompt. Unless I overlook an option that exists for this case?
Just checking: would it be sufficient if there was a PSX add-on that literally puts an interface to most functions of Hoppie's ACARS on the MCDUs, using whatever prompt (<HOPPIE would be an extremely silly example) and only talks to the ACARS server, no connection elsewhere? I suppose it then requires a scenery generator with VATSIM/IVAO network login on the side, else no controller would see you?
Hoppie
That'd work well... I was trying to hijack the ATC pages so it was seamlessly integrated with all CDUs...
HACARS?
:)
The FANS-1 stuff in PSX is accessible by add-ons via Qs and Qi variables:
Qs466="FansDn"; Mode=DELTA; Min=0; Max=500;
Qs467="FansUp"; Mode=DELTA; Min=0; Max=500;
Qs468="FansDnResp"; Mode=DELTA; Min=0; Max=500;
Qs469="FansUpResp"; Mode=DELTA; Min=0; Max=500;
Qs470="FansLastLog"; Mode=START; Min=0; Max=500;
Qs471="FansBasics"; Mode=ECON; Min=50; Max=500;
Qi221="FansAtcMsgId"; Mode=ECON; Min=0; Max=9999;
Qi222="FansCont"; Mode=ECON; Min=0; Max=3;
Documentation on request in the Networkers subforum.
|-|ardy
Thanks Hardy!
The difficulty I had was the LOGON process was automated so PSX always logs on to the CPDLC station, I couldn't control the logged in state and just use the UI and logic...
What do you mean by "PSX always logs on to the CPDLC station"?
- On a CDU select 'ATC' and the ATC/LOGON STATUS page appears.
- Line select any 4 letters into LSK1 ('LOGON TO'); lets use JOHN for example :)
- Press LSK1R ('LOGON -> SEND') to initiate connection.
PSX will now always logon to the ICAO station (which makes perfect sense with the integrated CPDLC in the instructor station).
For external integration we'd need to take over the success or failure to ensure people only get a successful login for stations that are online on Hoppie's network.
Unless I'm missing something - it's been a looong time since I looked at it - it's possible there were some other challenges as well that I'm not recalling right now... need more coffee on this wet Sydney Sunday.
Side note:
Although not CPDLC, Hoppies network also provides ACARS serices and variables I had in my notes are;
Qs462="AcarsTelexDn"; Mode=ECON; Min=0; Max=125;
Qs463="AcarsTelexUp"; Mode=ECON; Min=0; Max=125;
Qs405="AcarsScrPads"; Mode=ECON; Min=7; Max=500;
Qs485="AcarsAtis"; Mode=XDELTA; Min=4; Max=500;
Qi149="AcarsMsg"; Mode=ECON; Min=0; Max=1;
Qs464="MetarsUp"; Mode=ECON; Min=0; Max=3000;
For a special inhibit function, I could add another Qi variable with the values 1 and 0, and when an add-on sets this to 1, the internal PSX ATC robot will never establish the logon but the add-on will then have the full logon control.
Alternatively, you could try this:
The Qs "FansBasics" includes several variables separated by semicolons. The first three are:
logonTimer (integer)
logonTo (string)
actCtr (string)
When logged on, PSX will send the Qs starting with something like "12;YSSY;YSSY;" etc.
When the pilot has logged off, PSX will send the Qs starting with "0;;;" etc.
In other words, if your add-on receives this Qs with the first three variables not empty, you know it has logged on. And if you don't want to allow this logon, you may try to resend the Qs with the first three variables empty. This should make it log off immediately. But maybe the pilot's controls will flash and dingdong for a second anyway, and that's not elegant. So a special inhibit function might help ...
|-|ardy
I think the innhibition of the ATC Robot is the solution we need for the reason you stated.
Unfortunately the second officers have me busy today so can't redo my testing - not sure if Hoppie or Gary can verify that the logon issue is the only one before comitting to the change!
Integrating with PSX native ATC is a beautiful solution for obvious reasons, and from an addon developer perspective requires less coding :)
How long does it take until your add-on can tell whether a logon can be established?
I just realized there's a delay of circa 10 seconds until the PSX robot establishes the logon. If you cancel that before the delay is passed, there'll be no undesired momentary logon effects, I think.
Could be a couple of minutes. The interaction with Hoppie by clients is at an interval specified by the client - 1 minute recommended - so a delay before the ATC client even gets the request.
Then add a buffer for ATC to accept the logon etc - could be minutes to get a response.
Quote from: Hardy Heinlin on Sat, 22 Oct 2022 23:22How long does it take until your add-on can tell whether a logon can be established?
To reach out to the network, a second.
Then the controller needs to see the request and answer, either positive or negative. I do see quite a few negatives as people try to log on to a station that is outside their current airspace.
Typical real-world performance requirement for CPDLC is RCP240 -- 240 seconds round trip, including human response time. That is officially for ATC to airplane, but let's do the opposite, too. This is for oceanic CPDLC. I think domestic CPDLC uses RCP130.
Interestingly there are also combined stations to allow pilots to log on to the station they are under, without knowing it. KUSA is the best example. Internally the handovers are still done but all automated. However this is a ground function; the airplane only processes handovers.
Hoppie
OK, I'll add an inhibit control to the next PSX update.
I thought when a human ATC is available for a certain area, the VATSIM/IVAO data system would indicate this availability automatically and promptly while that human ATC might be drinking a cup of tea and holding a pizza in the other hand.
Is there anything else I could add to the FANS model?
|-|ardy
Just to not cause an after-you/after-you problem: I am currently NOT working on CPDLC for PSX, as I understand that there is a likely better option, which is to fork PSX native CPDLC to the Hoppie's ACARS backend. And I have not been looking at this option yet while John and friends have.
Let me know what you recommend, although I cannot promise any work in a definite time frame. At work I am deeply into the rabbit hole of Iridium ACARS improvements which absorbs most brain capacity and I am terrible at parallel projects.
Hoppie
I hope to have some time to review this at WorldFlight next week... to at least check the logic will work without any additional changes from Hardy...
By the way, I have a new plan (after World Flight). Instead of adding an extra inhibit Qi, I'll just extend this existing selector on the Instructor's CPDLC console:
(o) Manual control
(o) Random control - very restrictive
(o) Random control - less restrictive
(o) Random control - no restrictions
(o) External control
This allows the user to reset the control mode in case the add-on exits without an autoreset. I.e. the inhibit mode will be visible to the user instead of being hidden in the network background. Just like the "Externally controlled" switch on the Traffic page.
|-|
Good thinking!
You guys said it takes several minutes until the logon is established. In which phase exactly is this delay?
Phase 1: "SENDING" is displayed ... how long?
Phase 2: "sent" is displayed ... how long?
|-|ardy
Given that my real-world system does CPDLC all day long...
To send anything while over deep water using satellites takes at least 5 and usually about 15 seconds. So the "sending" phase is about that long.
Then the message arrives at the ATC center and somebody or something needs to react. If the logon is automated, this is usually a matter of a second. If a controller needs to take action, it can be up to 30 seconds.
Then the ack needs to come back to the aircraft, which again takes between 5 and 15 seconds.
This all assumes that there is no other ACARS traffic in the way. Add 30 seconds if there is another message in the way.
ACARS over SATCOM isn't the speed monster people assume it is...
Hoppie
So the afore-mentioned delay of several MINUTES in VATSIM occurs after "SENT", not before "SENT".
Is the "sent" event the confirmation of the ACK event?
Quote from: John Golin on Sun, 23 Oct 2022 01:27Could be a couple of minutes. The interaction with Hoppie by clients is at an interval specified by the client - 1 minute recommended - so a delay before the ATC client even gets the request.
Actually you have a bit more freedom there.
If you are sitting idle and poll for new unsollicited messages, I recommend a poll interval around that one minute. But if you just sent a downlink and you expect an answer, you can poll after 10 or 15 seconds without any problem. Just be reasonable and everything will be fine.
It won't speed up the ATC client receiving your message of course but it won't also delay your own client much. No worst case of two minutes or more.
That said, such a delay is not uncommon in the real world.
The benchmark for oceanic CPDLC is RCP240. A full four minutes between the ground sending a new clearance and the pilots answering. This is including all technical latency and the pilot's reaction time. 99.9% of all CPDLC transactions (ground to air and back) need to be completed within these 240 seconds for an airplane/fleet/type to be allowed to file flight plans indicating CPDLC capable.
Domestic CPDLC uses RCP130 -- 130 seconds to get 99.9% of all clearances answered. "This is a challenge."
Hoppie
Quote from: Hardy Heinlin on Sat, 19 Nov 2022 10:19Is the "sent" event the confirmation of the ACK event?
90% sure it is. There is a tech ack at the ACARS level that indicates the ground received the request. There may also be a CPDLC ack coming later that is an indication from the end system (ATC) that they received the logon request, but that does not contain the actual accept/reject yet.
I will dig into some realworld CPDLC logs from a 747-400 I have at work what exactly happens there, just for information.
Hoppie
External CPDLC control is now available in PSX update 10.158:
https://aerowinx.com/board/index.php/topic,4191.0.html
|-|ardy
Documentation upon request.
Requesting documentation pls...
Steff
Quote from: Captain_Crow on Sun, 20 Nov 2022 19:40Requesting documentation pls...
Steff
We have ourselves a volunteer!!
So, as far as I understand, there is an external software in work ?
Steff
Documentation:
https://aerowinx.com/board/index.php/topic,6944.0.html
|-|ardy