OC ADF for FO side with PMDG

[NobbyC_B738]

Just an idea: maybe your No. 9 problem is just another mismatch problem similar to your DU mismatch or my previous lights test and electrical state knobs mismatch. The Oi4FS software or SIOC reacts very sensitively to missing input signals.

2 of your statements led me to this assumption:
- I do not have these modules COM2, ADF1, ADF2, AUDIO2. (Borrowed known working COM1 for test purposes)
- Also i have the OC house built IDC Pedestal so I do not have to set configurations for the individual panels. I just configure in Oi4fs with Pedestal.

When I understand correctly you have a factory-built pedestal, but not a complete one what makes it to a custom one.

Did you disable all entries in the script that deal with COM2, ADF1, ADF2, AUDIO2? If not, script may expect a pedestal complete with all panels.

I solved all my el. stat and lights test problems incl. some knob mismatches by disabling all variables for switches that I didn’t connect on the OVH. Additionally I searched for loose contacts. I did this by operating every switch with simultaneous observation of the virtual cockpit and indeed I found 2 switches with loose contacts. After fixing this I never had any mismatch problem again.
Good luck

[biggstuff]

Interesting observation Mr. N
The ATC interference with the display is COM active is a mystery. I have checked all inputs in SIOC and see no issue. As you know, the active window does not have a direct input from anything. It just gets the value from the standby after pressing TFR. So there is no direct connection to the active window. The ATC number showing in the active window of the com has to be coming from some display card interference whenever the ATC encoder is used.

Also can you explain what you mean by loose contact? Are you saying that you actually had a physically loose connection of some wiring and that was creating a mismatch?
Thx for your suggestions.

[NobbyC_B738]

Yes, I mean “physically loose connection” (what is better translation for German “Wackelkontakt” than “loose contact”). The screw of a switch has loosened after some time or wasn’t tightened enough. For the software a loose connected switch is nearly the same as a non-connected switch .

I will tell you some details of my previous lights test problem so you can imagine what non-disabled functions can do with the software.

When I operated the lights test switch from “Off” to “Lights Test ON”, several things on virtual cockpit happened at the same time:
- Left knob on electric panel moved from “STBY PWR” to “TR3”
- Right knob on electric panel moved from “STBY PWR” to “TEST”
- B switch on FLT Control panel jumped from “B ON” to “OFF”
- Left knob on IRU panel moved from “NAV” to “OFF”
- Right knob on IRU panel moved from “NAV” to “ATT”
- Yaw damper switch jumped from “ON” to “OFF”
- I lost navigation on captain’s PFD instruments

Nearly same behavior, when I turned off battery

For a long time I went the same way as you do now and looked for logic explanations:

1) Hardware failure: no, hardware worked fine on SIOC Monitor and hardware worked fine on X-Plane 11
2) Card or wire interference: no, hardware worked fine on SIOC Monitor and hardware worked fine on X-Plane 11.
3) Script bugs: same behavior with scripts version 6.2, 6.4 and 6.5. Great improvement on electrical states and revised lights test logic since script version 7.0. No problems with electrical state changes any longer on my side and much better lights test behavior, but not completely solved.

Then I read documentation again and found the following and most important note:

Readme.jpg (138.18 KiB) Viewed 207 times

This was the game changer for me. Jumping switches, that was exactly what I saw on the VC. After disabling non-used functions and after fixing the loose wiring all problems were solved.

Until then I thought, a non-connected switch will be treated as a switch in “OFF”-position, like in other programming languages where the software queries the real switch positions 50 or 60 times a second.
But SIOC is different. It is event driven and asks for changes and will not notice a wrong value until you operate the corresponding switch again. I’m not sure, but I can imagine that SIOC or the driver software may re-organize assignments when functions are in the script but not implemented in the hardware.

When 2 missing switches plus 2 loose connected switches on my side can have such effects as described above, you can imagine, what effects missing switches, missing displays and missing encoders can have on your side.

My question again: did you disable all pedestal functions in the script that are not implemented in your hardware?

Would be interesting if Roar also recommends to disable pedestal functions in the script that are not implemented in your hardware. Maybe I’m wrong and the above Readme-note is not valid for semi-complete pedestals.

[biggstuff]

Mr. N
To answer your question, I haven't disabled the sections of the script that I do not have panels for yet.
I will do that in due time and see if it makes a difference here.
I will keep you updated.
Thanks