February 9, 20197 yr Xplane 11.32 for windows I am having two issues that I haven't been able to solve. First, if I change transponder code in the RXP GTN750, it doesn't update the default transponder that is on the plane. More importantly, if I select the option "Connect CDI Mode to NAV/GPS switch" and then I have GPS on the autopilot, the HSI CDI needle starts going back and forth between the GPS course and the NAV1 course. If I don't select the option, the autopilot NAV mode doesn't follow the GPS navigation when I select GPS on the 750. Help would be greatly appreciated!
February 10, 20197 yr Hi, this could be related to XP11.32 itself, or the aircraft, or the configuration, so I'd suggest you try out our just released v2.5.12 update. In effect this update has many changes in the 'autopilot' department.
February 10, 20197 yr 7 hours ago, RXP said: Hi, this could be related to XP11.32 itself, or the aircraft, or the configuration, so I'd suggest you try out our just released v2.5.12 update. In effect this update has many changes in the 'autopilot' department. How to upgrade to v 2.5.12?
February 10, 20197 yr @afcad very easy: it is explained in the first sentence of the dedicated discussion:
February 13, 20197 yr Author I updated, but the problems are not solved. I will try to post on the justflight forum, to see whether there is a viable solution...
February 14, 20197 yr Hi, we're preparing a point fix update to correct a few bugs which passed through unfortunately. Hold on tight for this one.
May 9, 20197 yr Having the same issue. The transponder reverts back to 1200 after entering any code. Makes it impossible to fly on PE other than VFR. Any resolution to this yet?
May 11, 20197 yr @Piper5299X Hi, is this reverting back to 1200 right away, or during takeoff roll for example?
May 26, 20197 yr On 5/11/2019 at 9:34 AM, RXP said: @Piper5299X Hi, is this reverting back to 1200 right away, or during takeoff roll for example? It reverts back immediately. When you enter in the GTN 750, the aircraft transponder overrides it, and it reverts back to whatever the aircraft transponder is set to. I hope that makes sense.
May 26, 20197 yr @Piper5299X Hi, If you have some specific plugins installed and active, maybe you could try to disable them and see if the transponder works as expected? I'm not sure what might cause the problem on your end but I just tried the Arrow III and Turbo Arrow IV with the GTN and the XPD works correctly in both planes. It's possible to change the squawk code with the GTN or the Bendix/King transponder. I'm using XP 11.34, RXP GTN 2.5.16, and probably the latest JF Arrow versions (not sure).
May 27, 20197 yr 20 hours ago, Bourrinopathe said: @Piper5299X Hi, If you have some specific plugins installed and active, maybe you could try to disable them and see if the transponder works as expected? I'm not sure what might cause the problem on your end but I just tried the Arrow III and Turbo Arrow IV with the GTN and the XPD works correctly in both planes. It's possible to change the squawk code with the GTN or the Bendix/King transponder. I'm using XP 11.34, RXP GTN 2.5.16, and probably the latest JF Arrow versions (not sure). Thank you for checking, but it is the Archer that the issue is with. The Warrior, and Arrow are working fine.
May 27, 20197 yr @Piper5299X Then maybe on the Archer they have coded their transponder to 'enforce' whatever value it is set to, like most developers do. Again, there are 2 approaches: - Enforcing (value based): the gauge maintains its own internal variables/state values and whenever the simulator variable disagree they write back their own variable values. - Synchronizing (event based): the gauge maintains its own internal variables/state and whenever the simulator variables change, they change their own. Conversely, whenever their variables change they write the simulator variables back. The former is how most developers do, because well, their code is supposed to be the sole running. The latter is how some developers do, because they consider they don't own the state, rather they consume the simulator-owned state, and as such it can change behind their back legitimately (say you reload a saved situation, you have a fancy hardware input triggering a command, the simulator implements a new automatic feature which turns the XPDR off on ground after landing etc...)
May 27, 20197 yr 4 hours ago, RXP said: - Enforcing (value based): the gauge maintains its own internal variables/state values and whenever the simulator variable disagree they write back their own variable values. - Synchronizing (event based): the gauge maintains its own internal variables/state and whenever the simulator variables change, they change their own. Conversely, whenever their variables change they write the simulator variables back. So, I'm assuming there is no solution??
May 27, 20197 yr You may assume anything! The GTN and the GNS V2 are developed (cleverly?) to synchronize their state fully back and forth (except the CDI mode with enforces the underlying HSI nav source switch). Any other 3rd party aircraft departing from the 'I own the sim' mentality and implementing sane event-based synchronisation will certainly work fine then. The ball in this case is in the 3rd party developper hands. I'm just saying these two approaches determine whether any such add-on could interface with another one.
Archived
This topic is now archived and is closed to further replies.