Fenix A320 vs PFC Avionics Help Needed

[PSantos]

1 hour ago, Fragtality said:

Now I'm confused too, although you've showed it too me during our call 😅

So is it:
1) The Plane should turn on when you press a Button on the PFC?
 

Hi Daniel

No sir...... on the FBW for exemple when I turn the Batt ON and the Ext Power on all the Avionics on the plane Turn ON.
I had to bind a button (on the PFC Avionics Stack) to turn the Stack ON.
Every other plane all I have to do is tell FSUIPC to turn the Avionics ON (PFC and Plane) by binding a button/stitch to the AVIONICS_ON/SET.

 

1 hour ago, Fragtality said:

So is it:
2) The PFC should turn on when the Plane is turned on?

99.9% of the time YES.... except the Fenix A320.

[PSantos]

3 hours ago, John Dowson said:

Could you list the available lvars for the Fenix please: Add-ons->WASM->List Lvars and paste/attach here from the FSUIPC7.log or FSUIPC7 main window. Please wait for a minute or two after the aircraft is loaded before doing this.

I´m not sure if this is what you looking for.

 

lvars.txt

events.txt

[Fragtality]

Nope. Still don't ^^

Is is that?
- PFC Display and Plane are OFF
- Press Button on PFC to turn Plane ON
- When Plane turns on, PFC Displays become alive?

[PSantos]

6 minutes ago, Fragtality said:

Is is that?
- PFC Display and Plane are OFF
 

NO... but on the FBW Plane is on and then I turn the PFC ON

 

6 minutes ago, Fragtality said:

 

- Press Button on PFC to turn Plane ON

NO

6 minutes ago, Fragtality said:

- When Plane turns on, PFC Displays become alive?

YES

 

 

[Fragtality]

These where not meant as either / or options, they belonged together as one flow^^
But okay ... we will go with ""When Plane turns on, PFC Displays become alive => YES. And ignore everything else you said (else I can't follow what your Goal is)

Did you find out what exactly PFC is monitoring / expecting to get it's turn-on-signal?
It can't be "AVIONICS_MASTER" - these Offsets / SimVars are already set to ON/1 by the Fenix (even without having Bat/Pwr turned on).

From what I understand, something like this lua Script should do the Trick:

local turnedOn = false
function FNX_SYNC_AVIONICS()
	if not turnedOn and ipc.readLvar("S_OH_ELEC_BAT1") == 1 and ipc.readLvar("S_OH_ELEC_BAT2") == 1 then
		ipc.control(66701) -- Or whatever else is needed for PFC to recognize the Avionics being on ...
		turnedOn = true
	end
end

event.timer(500, "FNX_SYNC_AVIONICS")

(Bind it to some Key / Button to test if this helps. Can be run as [Auto] Script to start it automatically - consult the FSUIPC Documentation.)

[John Dowson]

The more posts here, the more confused I am...

Quote

So is it:
1) The Plane should turn on when you press a Button on the PFC?
2) The PFC should turn on when the Plane is turned on?

I thought that 1 was applicable: you say the button is working, but stanfard controls (Avionics On, Avionics Set, etc) do not work. And so I thought that you are looking for an assignment that when you press a button on yout PFC Radio Stack this turns the aircraft avionics on. But it seems that 2 is correct, as you say:

57 minutes ago, PSantos said:

1 hour ago, Fragtality said:

- When Plane turns on, PFC Displays become alive?

YES

So, if this is the case, what is turning the PFC displays on for other aircraft? Is this looking at an offset value, and if so, which one?
If you can explain how this is configured for other aircraft, then maybe we can help... If its looking at an offset to do this, and that offset isn't being populated for the Fenix A320, then there are solutions available, assuming there is an lvar or something that holds this state (e.g. you can spoof the offset to an lvar value, if you can't change the offset that the PFC hardware is looking at for this).

BUT, I still find this confusing, as you say:

1 hour ago, PSantos said:

on the FBW Plane is on and then I turn the PFC ON

So you manually turn the PFC on for the FBW when the avionics are on. But then:

1 hour ago, PSantos said:

1 hour ago, Fragtality said:

- When Plane turns on, PFC Displays become alive?

YES

which sounds like you want the PFC display to turn on automatically when the avionics are turned on in the plane...

I think we are going around in circles here and neither @Fragtality nor I have a clear understanding of the actual issue...or maybe its just me... 

Normal behavior would be that you press a button on your hardware, this triggers the control, avionics turn on in the aircraft and your hardware displays light up. Is it that this is the case in other aircraft, but in the Fenix the aircraft avionics turn on, but your displays stay dark? If that is the case, then you need to know what is driving the displays to be turned on - is this an offset value, and if so, which?

[PSantos]

John

Both of these are true....

When flying the FBW, I turn on the Airplane and nothing happens on the PFC.

3 hours ago, PSantos said:

on the FBW for exemple when I turn the Batt ON and the Ext Power on all the Avionics on the plane Turn ON.
I have to bind a button (on the PFC Avionics Stack) to turn the Stack ON.
Every other plane, all I have to do is tell FSUIPC to turn the Avionics ON (PFC and Plane) by binding a button/stitch to the AVIONICS_ON/SET.

2 hours ago, John Dowson said:

So you manually turn the PFC on for the FBW when the avionics are on.     YES.......

 
Repeating myself, 
On EVERY other plane, I have Battery and Avionics bind to Buttons and Switches and as soon as I turn the Battery and Avionics switches ON, EVRYTHING lights up, the plane and the AVIONICS STACK. Together and sometimes separately. 

I´m sorry if this is getting out of control, but I can´t find a better way to explain it.

Paul

 

[Fragtality]

The thing is, you somehow contradict yourself 😅

So your initial Problem is with the Fenix - because on every other Plane it works. Then you give an Example (and requote and emphasize it) that is understood in such a way that it does not work with the FBW too.  So is it every other Plane except Fenix and FBW? Or what is it you try to explain with the FBW when the Problem is "only" the Fenix? Because what you are describing with the FBW also does not match up with the Things you said no/yes to ^^

You know better Explanations don't have to be long, sometimes shorter is better 😉
Can you describe your goal in 2-3 short and general Steps (similiar to my try)? So we have a chance to get the basic Idea? Details and specifics don't matter if nobody understands the basic Idea ^^

 

[PSantos]

36 minutes ago, Fragtality said:

The thing is, you somehow contradict yourself 😅

So your initial Problem is with the Fenix - because on every other Plane it works. Then you give an Example (and requote and emphasize it) that is understood in such a way that it does not work with the FBW too.  So is it every other Plane except Fenix and FBW?

Never I said it does not work with the FBW, I said that I needed to bind a SWITCH(BUTTON to make it work, but it works.
And yes, I maintain... the only plane that is not recognizing the bind to turn on the FPC Avionics is the FENIX.
 

[John Dowson]

12 hours ago, PSantos said:

I said it does not work with the FBW, I said that I needed to bind a SWITCH(BUTTON to make it work, but it works.

What is this binding/assignment?

Do you have anything assigned in the Fenix to turn the batteries on? If not, assuming the lvars are writeable, you can create a preset (in a file called myevents.txt file) to set the battery lvars, e.g.
     Fenix_A320_Batteries#$Param (>S_OH_ELEC_BAT1) $Param (>S_OH_ELEC_BAT2)
Then assign to Prefix:Fenix A320 Batteries with a parameter of 1 for on and 0 for off. Alternatively, you can create separate presets for each battery, and separate presets for on/off if you prefer.

18 hours ago, PSantos said:

I´m not sure if this is what you looking for.

The lvars.txt is one of the files I was after - I don't need to see your events.txt file (I have that) - I want to see your FSUIPC7.log file, generated with logging for events activated (in FSUIPC) and you turning on the avionics in the cockpit UI (as I asked for...). This would show any events/controls used by the avionics. It may also be useful to list the lvars before doing this, and again directly after. Comparing the two lists would then show if/what lvars have changed values.

It may be obvious to you what your issue is, but it really is confusing to understand reading these comments..
I assume that you need to bind something (a switch or button) on your PFC stack to turn on the avionics in the aircraft, so lets try and sort that out first. 

And, from what I understand, you issue is nothing to do with PFC, it is the Fenix that is missing a function to turn the avionics on. The binding/assignment that does this for you in the FBW may help us understand...

There also seem to be many presets already available for the Fenix (41 for the avionics alone, and 344 for the electrical systems) - have you looked through the preset list to see if anything is applicable (https://hubhop.mobiflight.com/presets/)? 

Edited June 19, 2022 by John Dowson
Further info added

[PSantos]

5 hours ago, John Dowson said:

It may be obvious to you what your issue is, but it really is confusing to understand reading these comments..
I assume that you need to bind something (a switch or button) on your PFC stack to turn on the avionics in the aircraft, so lets try and sort that out first. 

I´ve mentioned this a few times, but don´t know what I´m saying that is confusing.
I need a BUTTON/SWTICH that can turn that PFC AVIONICS RADIO STACK "ON"...... not "in" the aircraft. 

 

 

5 hours ago, John Dowson said:

What is this binding/assignment?

Do you have anything assigned in the Fenix to turn the batteries on? If not, assuming the lvars are writeable, you can create a preset (in a file called myevents.txt file) to set the battery lvars, e.g.
     Fenix_A320_Batteries#$Param (>S_OH_ELEC_BAT1) $Param (>S_OH_ELEC_BAT2)
Then assign to Prefix:Fenix A320 Batteries with a parameter of 1 for on and 0 for off. Alternatively, you can create separate presets for each battery, and separate presets for on/off if you prefer.

 Yes I do.... I´ve mentioned that to. On my Ignition setup I have 2 switches that turn on the Airplane batteries ON.

and. this is the log 

FSUIPC7.log



thank you guys

FSUIPC7.log

[John Dowson]

42 minutes ago, PSantos said:

I need a BUTTON/SWTICH that can turn that PFC AVIONICS RADIO STACK "ON"...... not "in" the aircraft. 

But this is what is confusing - there is no such button/switch. Control are only EVER sent to the FS, not to controllers.
And the only thing to turn your stack on would be a power button on the stack itself. If pressing buttons on the stack are recognisd by FSUIPC, it must be ON..
But, I am now assuming that the problem is that the displays are not active for some reason...

So, the PFC device must be monitoring an offset to determine when to light up the displays, and maybe this offset is not being populated by the Fenix? Have you tried monitoring the avionics master switch offset (0x2E80 or 0x3103) to see if those change value when the avionics are on in the aircraft? Or maybe the master battery offset (0x281C)?
Maybe the PFC is waiting for one of those offsets to change to 1 before activating the displays (or 'turning on'). If that is the case, you could try either configuring your PFC hardware/driver to use a different offset, if that is possible, or maybe by spoofing the offset using lua, although  I am not 100% sure the spoofing facility works if not being read from an external program, but you can try (see offset 0x0024).

It would really help if you could respond to all of my questions - you seem to ignore most of them for some reason. Can you PLEASE explain what your binding is for the FBW that you use to get this to work - this would help enormously as, as far as I can tell, you have the same issue in the FBW without this binding. If I know what that is doing, it could shed some light on the issue with the Fenix (i.e. what is being used to trigger the displays).

 

 

[Fragtality]

43 minutes ago, PSantos said:

I´ve mentioned this a few times, but don´t know what I´m saying that is confusing.
I need a BUTTON/SWTICH that can turn that PFC AVIONICS RADIO STACK "ON"...... not "in" the aircraft. 

Exactly this type of explanation it is 😅 😉
You answered "yes" that the Stack should turn on automatically. Here you write you want to bind a button/switch to turn the Stack on (to which you said no to). Whatever on top means "not in the Aircraft" - the Solution can only come from inside the Plane when the PFC should react to the Plane oO

To be honest, I give up at this Point. I've just stumbled across the Topic trying to help/volunteer because I just did something roughly similiar.
But I just can help when I don't understand yet alone the basic Problem, sorry 😞

The last Thing I could share is: if both Lvars for HDG/VS and TRK/FPA Modes are 0/Off, the FCU is off. As soon as it turns on, one of them is 1/On. So this could be another reliable Check (besides Checking the Battery Switches/Korrys) that could be used to test if the Fenix is alive/on.
But we still don't know what we can do with that - you / PFC are the only ones which could tell us what we need to send/set in this Situation 😕  (IF we understand the Situation at all correctly)

 

3 minutes ago, John Dowson said:

So, the PFC device must be monitoring an offset to determine when to light up the displays, and maybe this offset is not being populated by the Fenix? Have you tried monitoring the avionics master switch offset (0x2E80 or 0x3103) to see if those change value when the avionics are on in the aircraft? Or maybe the master battery offset (0x281C)?

That was my Guess too, I've tested it. The Avionics Master Offsets are directly 1/ON when the Fenix is loaded. So either PFC never checks the actual Value and is just waiting for Value-Changed-Event (which will just never happen) or they are listening/checking on something else. My Guess in the Lua I shared is, that it is maybe the Master Avionics Control/Event.
And just did a test with the Master Battery Offset: same Story, it is directly 1/ON.

For the FBW that is behaving differently: the Avionics Master Offsets are 0/OFF when being loaded and Master Battery is 1/ON. But the Values do not change there too when Power is applied.
So it should not work with the FBW too when PFC is monitoring these Offsets ... but I still don't even know if the FBW counts to Fenix (not working) or every other Plane (working) 😕 

[John Dowson]

Thanks @Fragtality - I agree completely - the PFC driver must be monitoring either an offset or a control to know when to activate the displays (or turn the PFC on...). And I think this is the salient point:

1 hour ago, Fragtality said:

So it should not work with the FBW too when PFC is monitoring these Offsets

as the OP said it doesn't work like this as for all other planes, BUT the OP bound a button to activate this. So, if the OP could share what that assignment/binging is, then this may shed more light on the issue...

Useful to know that he Fenix IS updating those offsets, so it can't be those. If its an event, which it seems likely, then it may be that the Fenix is just ignoring that event. You can send the event, but if its not handled, it won't be received (or logged) by FSUIPC - or the PFC driver. Logging would show this - i.e. if the OP tries the script you kindly provided and checks if the event sent is logged.

Pete wrote the PFC driver, many years ago, in agreement with PFC. I have access to the source via github, but I really don't want to support this - it should be PFC that do this. I can maybe move the driver source across to my account and make it public if needed (and possible - I would need to talk to PFC).... I may take a quick look to see if there is anything obvious, but windows hardware drivers are an area about which I know next to nothing, and don't have the time (or inclination!) to do so.

John

[John Dowson]

Can one of you check if the ready-to-fly flag is being set for the Fenix in offset 0x3364? This is the offset/flag that activates the driver when set to 0 (non-zero indicates still loading).

 

[John Dowson]

I'm pretty sure that offset must be set, as I've just checked the log @PSantos posted and can see this line:

Quote

   581047 -------------------- Starting everything now ----------------------

That flag should be set then...but please check.

You also posted a continuation log - please only post full log files when requested (zip them if too big). Your log shows several errors - these are from trying to use presets before everything is ready (you need to be more patient):

Quote

   455875 Executing preset 'C_172_AVIONICS_BUS_1_OFF' [731]
   455875  [ERROR]: Error setting Client Data Calculator Code: '(A:CIRCUIT SWITCH ON:24, Bool) if{ 24 (>K:ELECTRICAL_CIRCUIT_TOGGLE) } (A:CIRCUIT SWITCH ON:24, Bool) 1 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:4, Bool) != if{ 4 1 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) }'
   455875 Button changed: bRef=0, Joy=5 (G), Btn=21, Pressed
   455875 [Buttons] 11=PG,21,CPC_172_AVIONICS_BUS_2_OFF,0
   455875 Executing preset 'C_172_AVIONICS_BUS_2_OFF' [733]
   455875  [ERROR]: Error setting Client Data Calculator Code: '(A:CIRCUIT SWITCH ON:25, Bool) if{ 25 (>K:ELECTRICAL_CIRCUIT_TOGGLE) } (A:CIRCUIT SWITCH ON:25, Bool) 2 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:5, Bool) != if{ 5 2 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) }'
   455875 Button changed: bRef=0, Joy=5 (G), Btn=5, Pressed
...
   581891 Button changed: bRef=0, Joy=18, Btn=1, Pressed
   581891 [Buttons.FenixA320_SATCSTKO] 18=P18,1,CPFNX320_Transponder_Operation_Knob_AUTO,0
   581891 Executing preset 'FNX320_Transponder_Operation_Knob_AUTO' [2018]
   581891  [ERROR]: Error setting Client Data Calculator Code: '1 (>L:S_XPDR_OPERATION)'
 

You can use presets (or lvars/hvars) until you see this line logged (nearly 3.5 minutes later than when you executed the first preset):

Quote

   659000 Lvars/Hvars received - checking aircraft autos....

This one is interesting:

Quote

   576813 Attempt to set external joystick assigns refused

but looking at the code I think this is normal when using the PFCcom64.DLL to prevent the axes getting registered with FSUIPC.

Please attach a full log next time, and don't attempt to do anything until the plane is fully loaded and FSUIPC has received the config data to be able to communicate with the WASM.

Also, can you please check the bits in offset 0x3300, and also that the com/nav frequencies are being populated in the following offsets:

Quote

    {    0x034e, 2 }, // 4  COM freq
    {    0x0350, 2 }, // 5  NAV1 freq
    {    0x0352, 2 }, // 7  NAV2 freq
    {    0x3118, 2 }, // 37  COM2 freq
    {    0x311a, 2 }, // 38  COM1 standby freq // N.B. These 4 not refreshed except on change
    {    0x311c, 2 }, // 39  COM2 standby freq
    {    0x311e, 2 }, // 40  NAV1 standby freq
    {    0x3120, 2 }, // 41  NAV2 standby freq
 

And it is offset 0x3103 that is used for the avionics switch status (not 0x2E80) - so please double-check that one.
The PFC driver doesn't listen for events, it only reads offsets, so there must be an offset that is not being set correctly with the Fenix...

John

[John Dowson]

@PSantos To summarise my previous posts, please do the following which should help us get to the bottom of this:

1. Start MSFS and FSUIPC7.
2. Open the FSUIPC7 main window
3. Remove/uncheck all logging
4. Open the offset logging window and log the following offsets:
        0x3103 U8
        0x3364 U16
        0x3300 U16 hex
        0x034E U16 hex
    Click Ok when done to close the offset logging window.
5. Load the Fenix A320, and press the ready-to-fly button.
7. Wait a minute or two to make sure everything is loaded - you can open the logging console if you like, and wait until you see this message:
        Lvars/Hvars received - checking aircraft autos....
    Once that message is received and any luas/macros are started, everything is ready.
8. Power up the aircraft and the aircraft avionics and wait a few seconds.
9. Exit FSUIPC7.
10. Start FSUIPC7 again. Wait a minute or two (i.e. as step 7).
11. Exit FSUIPC7 again.

Then show me both your FSUIPC7.log and FSUIPC7_prev.log files as well as your FSUIPC7.ini file.

You can also repeat but log the following offsets instead:
    0x281C U32
    0x0350 U16 hex
    0x0352 U16 hex
    0x311A U16 hex

John

Edited October 17, 2022 by John Dowson
Corrected offset monitoring type/size

[Fragtality]

Hello @John Dowson

I digged a little bit further in this Issue for @PSantos:

From what I understood from him: He is used to, that Binding a Joystick Button to the SimEvent “AVIONICS_MASTER_1_ON” via FSUIPC turns on his PFC Box. Works for him on other Planes (e.g. FBW A32NX, Default Neo) but not on the Fenix A320.
I’ve analyzed that a bit, tried to compare these three Planes in terms of that SimEvent:
- I did monitor the FSUIPC Offsets (SimVars) for Master Avionics Switch (0x2E80) and Avionics (0x3103): The FBW and Default NEO start with 0/OFF. The Fenix directly starts with 1/ON.
- When sending the mentioned SimEvent, these Offsets will change to 1/ON for the FBW and Default NEO.
- Trying to write a 0/OFF to these Offsets on the Fenix reveals that it is instantly changed back to 1/ON.

So my current theory on why it does not work with the Fenix: The PFC Box respectively the DLL/Plugin is polling these Offsets/SimVars and is waiting for a Change from 0 to 1 as the Signal to turn on. Although, with a Script which sets both Offsets to 0/OFF so that there is Change with the Fenix did not really work - but that could maybe related to which interval is used for Polling?!

I tried again to get any Information out of PFC, but they are still on the Standpoint only you and Pete can know:

Quote

Previously Pete Dowson made a .DLL for our serial device and also made the PFChid.dll for our USB Devices. He or John Dawson are therefore more suited to be able to answer your questions. With this in mind we do not know what event, simvar or FSUIPC offsets will trigger the avionics to come on because we did not write the DLL.

 

I hope Paul picks up the Discussion again and generates the Logs - but maybe you can make some Use of my Information and can verify if that Theory is correct?

 

Greetings,
Daniel

[John Dowson]

Hi Daniel,

17 hours ago, Fragtality said:

but maybe you can make some Use of my Information and can verify if that Theory is correct?

As I previously indicated, the PFC driver is waiting for the ready-to-fly offset flag to change before the avionics are activated. The driver does not react to sim events, only offset changes.

17 hours ago, Fragtality said:

So my current theory on why it does not work with the Fenix: The PFC Box respectively the DLL/Plugin is polling these Offsets/SimVars and is waiting for a Change from 0 to 1 as the Signal to turn on. Although, with a Script which sets both Offsets to 0/OFF so that there is Change with the Fenix did not really work - but that could maybe related to which interval is used for Polling?!

I don't think the polling frequency is an issue, it is the offset values themselves. This is why I need to see those offsets logged. If those offsets (or simvars associated to those offsets) are not being used by the Fenix, it is just a matter of determining what is being used (simvar or lvar) and then adding that to a spare/free FSUPC offset and then spoofing the value of the original offset (which is monitored by the PFC driver) to the value of the new offset.

But I really don't think it is worth looking at this further if the OP is not prepared to supply the information required to resolve this for him.

Thanks for your input, regards,

John

[Fragtality]

7 hours ago, John Dowson said:

As I previously indicated, the PFC driver is waiting for the ready-to-fly offset flag to change before the avionics are activated. The driver does not react to sim events, only offset changes.

And my theory is about a specific Offset Change?

 

7 hours ago, John Dowson said:

I don't think the polling frequency is an issue, it is the offset values themselves. This is why I need to see those offsets logged. If those offsets (or simvars associated to those offsets) are not being used by the Fenix, it is just a matter of determining what is being used (simvar or lvar) and then adding that to a spare/free FSUPC offset and then spoofing the value of the original offset (which is monitored by the PFC driver) to the value of the new offset.

So you confirm that the PFC Driver is indeed looking for Offset changes?

One of the Offsets you have asked for, 0x3103, is constantly overwritten with 1 by the Fenix. So there is no Change (or the Change is too short). The Other Planes don't do that, which is completely normal: an Airbus just does not have the Concept of Master Avionics Switches.
Given that the mentioned SimEvent changes these Offsets 0x2E80 and 0x3103 on other Planes but not on the Fenix could have been a lead.

To explain my Theory another way: It is not the SimEvent and not the Plane reacting to a SimEvent. The mentioned SimEvent just changes the SimVars which is picked up by the PFC Driver. The Reason the other Planes are working is that they just don't care about these two Offsets and the Change can happen. Fenix on the other Hand (for Reasons unknown) is overwriting that Offset and a Change is not happening.

Sure, it could also be that the Fenix is just not updating a complete different Offset(s). But somebody must be able to tell what exactly is monitored to send the turn-on Signal to the PFC Box? The PFC Support is always pointing to you and Pete and that you should know.
I want to find out what is missing on the Fenix so that either a Workaround can be found or at least with the Knowledge of the Root-Cause a Feature Request to Fenix can be formulated.

 

8 hours ago, John Dowson said:

But I really don't think it is worth looking at this further if the OP is not prepared to supply the information required to resolve this for him.

I have offered him to pick up the Discussion for him after he started another Discussion about the Issue on the Fenix Discord. Paul is not really able to conduct a technical Discussion about that - as much as he likes that Hardware, as much he does not understand how and why it is working.
So please help me for the Moment with the PFC Driver and what the Driver is expecting.

Also, I have very clearly told him, that he stopped the Discussion here and also that he should give you the requested Information. He needs to help you helping him.
I would give him some days for that.

[Fragtality]

8 hours ago, John Dowson said:

is waiting for the ready-to-fly offset flag

What would be of personal Interest to me, for StreamDeck Plugin and the Fenix Integration: what would that Offset be? And is that a reliable working way to test that the Ready-to-Fly Button was pressed by the User?

[John Dowson]

16 hours ago, Fragtality said:

And my theory is about a specific Offset Change?
...So you confirm that the PFC Driver is indeed looking for Offset changes?

Yes, but the ready-to-fly offset at 0x3364 is the one that activates the PFC driver as far as I remember. It has been a while (3 months) since I last looked at this, so I really need to review the whole thread and the PFC driver code again if you want to resurrect this....

16 hours ago, Fragtality said:

One of the Offsets you have asked for, 0x3103, is constantly overwritten with 1 by the Fenix. So there is no Change (or the Change is too short). The Other Planes don't do that, which is completely normal: an Airbus just does not have the Concept of Master Avionics Switches.

But if its always 1, then it is always on, so I don't think this is an issue. However, I could check the PGC driver code to see if it is waiting for this to change from 0 to 1 (but I don't think so).

16 hours ago, Fragtality said:

Sure, it could also be that the Fenix is just not updating a complete different Offset(s). But somebody must be able to tell what exactly is monitored to send the turn-on Signal to the PFC Box? The PFC Support is always pointing to you and Pete and that you should know.

Yes, I do - and I have asked for a log with these offsets being monitored with the Fenix. I see no point in looking at this again until this is provided. Please see my last comment from 3 months ago, If you can provide those logs with the suggested logging/monitoring, then I will look at this again. Otherwise, I do not think it worth me spending the time to go through this again...

And the Fenix will be updating simvars and lvars, not offsets. It is FSUIPC that picks up these changes and maintains the offset data. If the Fenix is not using the standard simvars for this. then we need to determine what it is using instead, add this to an offset and then spoof the original offsets for these values to the new offsets, so anything reading the original offsets will automatically get the spoofed value from the new offsets.

16 hours ago, Fragtality said:

On 10/15/2022 at 1:29 PM, John Dowson said:

is waiting for the ready-to-fly offset flag

What would be of personal Interest to me, for StreamDeck Plugin and the Fenix Integration: what would that Offset be? And is that a reliable working way to test that the Ready-to-Fly Button was pressed by the User?

The ready-to-fly offset is at 0x3364, but this is not related to the Ready-To-Fly button being pressed. There is no event generated for this. You could try offset 0x026D - CAMERA STATE. This offset was added in 7.3.11 and will be < 11 (and non-zero) when ready, but not necessarily after the Fly Now button has been pressed. FSUIPC now also uses this to determine when to start threads for aircraft control.

John

Edited October 16, 2022 by John Dowson
Added info on offset 0x026D

[Fragtality]

54 minutes ago, John Dowson said:

Yes, but the ready-to-fly offset at 0x3364 is the one that activates the PFC driver as far as I remember. It has been a while (3 months) since I last looked at this, so I really need to review the whole thread and the PFC driver code again if you want to resurrect this....

Somehow it leaves Paul no rest 😉
But maybe sometimes a "fresh start" is better?

For my Part I go with his latest Description of the Problem over at the Fenix Discord.
On the FBW (and other Planes) this achieves what he wants:

Using that Switch (1) bound to (2) turns on the PFC Box respectively the Displays of it (3).
And the Switch is bound to:

 

1 hour ago, John Dowson said:

But if its always 1, then it is always on, so I don't think this is an issue. However, I could check the PGC driver code to see if it is waiting for this to change from 0 to 1 (but I don't think so).

Was only a theory of mine based on a Difference between these Planes given the latest Problem Description - but you're the only one who could say that is false/not related to the issue or if is true or at least a clue 😉

 

1 hour ago, John Dowson said:

Yes, I do - and I have asked for a log with these offsets being monitored with the Fenix. I see no point in looking at this again until this is provided. Please see my last comment from 3 months ago, If you can provide those logs with the suggested logging/monitoring, then I will look at this again. Otherwise, I do not think it worth me spending the time to go through this again...

Yes, I understand - but he is on it! The Description is a bit unclear for him what is meant with "UW", because he can't find it in the Dropdown. I guess you meant U16, right?

 

1 hour ago, John Dowson said:

And the Fenix will be updating simvars and lvars, not offsets. It is FSUIPC that picks up these changes and maintains the offset data. If the Fenix is not using the standard simvars for this. then we need to determine what it is using instead, add this to an offset and then spoof the original offsets for these values to the new offsets, so anything reading the original offsets will automatically get the spoofed value from the new offsets.

Sure the Offsets are a "copy" of the SimVars monitored by FSUIPC - but I'm not sure what you want to express with that? If the SimVar is changed (either by a SimEvent or the Plane itself) the Offset changes also? So anything writing to a SimVar is indirectly writing/changing to the Offset also.
So to correct myself - Fenix is constantly updating the SimVars I've mentioned. Which can be seen by monitoring the Offsets which FSUIPC maintains. 

Sure, if you find it more promising/effective to follow the Approach to look what SimVars (or Lvars) the Fenix is using. But then still, in the End, we need to know what exactly has to be spoofed for the PFC Driver? And that is my core Question - What does the Driver expect to turn on the PFC Box/Displays?
My approach was/is to find that out first. Then it can be analyzed what the Fenix A320 is not doing (or doing) differently there. And based on that either create a Workaround or at least have clear Base for a Feature Request to Fenix.

 

1 hour ago, John Dowson said:

The ready-to-fly offset is at 0x3364, but this is not related to the Ready-To-Fly button being pressed. There is no event generated for this. You could try offset 0x026D - CAMERA STATE. This offset was added in 7.3.11 and will be < 11 (and non-zero) when ready, but not necessarily after the Fly Now button has been pressed. FSUIPC now also uses this to determine when to start threads for aircraft control.

Kewl, thanks! 🙂
I'll look into this, maybe that's a workaround for the Design-Problem Asobo created there.^^

[PSantos]

John,
So sorry for thanking so long, a bunch of "little" things got in the way.
As you requested I´ve been trying to follow the steps you´ve asked to add those offsets, but it turns out that I either can´t or don´t know what I´m doing.
I found this, please advise.
What do I do??

Thank you so much for keeping the "hope" alive
Paul

  

[John Dowson]

22 hours ago, Fragtality said:

Yes, I understand - but he is on it! The Description is a bit unclear for him what is meant with "UW", because he can't find it in the Dropdown. I guess you meant U16, right?

Yes, sorry about that.

22 hours ago, Fragtality said:

Sure the Offsets are a "copy" of the SimVars monitored by FSUIPC - but I'm not sure what you want to express with that? If the SimVar is changed (either by a SimEvent or the Plane itself) the Offset changes also? So anything writing to a SimVar is indirectly writing/changing to the Offset also.
So to correct myself - Fenix is constantly updating the SimVars I've mentioned. Which can be seen by monitoring the Offsets which FSUIPC maintains. 

Yes, that is all correct - I was just clarifying that the aircraft/FS updates the simvars, not offsets, and it is FSUIPC that maintains the offsets based on these simvar changes.

22 hours ago, Fragtality said:

And that is my core Question - What does the Driver expect to turn on the PFC Box/Displays?

I believe it is just the ready-to-fly flag, but I will check this again.

22 hours ago, Fragtality said:

My approach was/is to find that out first. Then it can be analyzed what the Fenix A320 is not doing (or doing) differently there. And based on that either create a Workaround or at least have clear Base for a Feature Request to Fenix.

This is also my approach, which is why I have requested monitoring of those offsets.

@PSantosSorry, UB should be U8, UW should be U16. I will correct my post.

John