GN750 and justflight Archer/Arrow

[andreaventura 0]

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!

 

[RXP 2,338]

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.

[afcad 0]

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?

[RXP 2,338]

@afcad very easy: it is explained in the first sentence of the dedicated discussion:

 

[andreaventura 0]

Thanks. Will try the update,

[andreaventura 0]

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...

[RXP 2,338]

Hi, we're preparing a point fix update to correct a few bugs which passed through unfortunately. Hold on tight for this one.

[Piper5299X 10]

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?

[RXP 2,338]

@Piper5299X Hi, is this reverting back to 1200 right away, or during takeoff roll for example?

[Piper5299X 10]

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.

[Bourrinopathe 138]

@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).

 

[Piper5299X 10]

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.

[RXP 2,338]

@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...)

[Piper5299X 10]

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??

[RXP 2,338]

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.