NAV OBS tuning

[sunjunkiesi]

I had originally posted this in the root of support as it affects multiple aircraft - all of the De Havilland range, but I have received no response thus far so assume that area isn't monitored. This situation doesn't occur in the 407 or the 310 so it is beaver, otter and totter related.

When I use my nav panel to turn the OBS1 to the correct bearing it jumps to 359 and stays there, and doesn't move. The only way I can get it to turn to the correct bearing is to use the virtual cockpit. I am using a rotary encoder to send an FSUIPC offset to control the turning of the dial, and on the 310, 407, and all other aircraft I have (i do have SOME non-milviz planes, sorry) and all default aircraft, it works just fine. It is only these three aircraft that seem to not recognise the FSUIPC offset instruction to change the OBS1 card.

Is there something special going on behind the scenes with these functions that means FSUIPC can't control them?

Cheers - keep up the good work

[bpieke]

I had a related problem, in that my GTN750 could not adjust the OBS value..

If you read my post below on "Integrating the GTN750" you will see that you have to disable one line in the Events gauge.

[sunjunkiesi]

Can I politely bump this please? I do not have the GTN750 so I do not believe that the issue is related to this.

[Chuck Jodry]

On the DHC series aircraft the autopilot and HSI are operated by a custom set of variables . these not being standard offsets fsuipc isn't cognoscente of their values.

We can look at expanding the table of offsets , I believe there is one , perhaps Thomas can weigh in on its location.

Best CJ

[Taguilo]

Hi,

The OBS selector is using default VOR1_OBI_DEC and VOR1_OBI_INC events. It can be tested by using SHIFT-V and +/- from keyboard to rotate the OBI. If it doesn't work with this method then problem is not related to the OBS gauge.

IIRC the GTN750 takes control of OBI needle when active, unless the CDI option is selected (to alllow capturing a desired radial).

Tomas

[seb]

I have the same problem and it is related to the gauge in the beaver and turbo otter. Whenever I use lua to write to the correct offset (0x0C4E, which works a treat with every other plane out there) the value gets instantly reset by the plane to 0 thus rendering any rotary or set number assignment impossible.

The value is written to the offset, when turning the knob in the VC alright but whenever it is overwritten it is reset to 0.

Offset set: 0x0C4E type=DD format=DEC strlen=DEC val=270 < me setting the value via ipc.writeDD
Offset: DD 0x0C4E =0 < immediate response, also seen in cockpit with the OBS returning to 0

This the response from FSUIPC/ Linda. This is doubly bitter for me as I have two awesome bushplanes that prohibit me from flying with my built cockpit making me use the mouse for course changes.
VOR1_OBI_INC and DEC work, yes but they are so painfully slow that it is a real bother. I hope this thread still gets monitored and someone has a look at it. It really screws otherwise awesome planes.

[Taguilo]

Hi,

Fist let's make things clear: there is no problem with the OBS gauge. It is working as expected.
As it is custom coded, it won't react, or will do wrong, to direct address writing. Operating the OBI with custom/specific hardware must be done mapping VOR inc and dec events, which is for sure the standard FSIM method.
So far there are no plans to change it, sorry.

Tomas

[seb]

That's rather sad. As INC DEC take a long time to get a full 360. Plus if I use INC DEC on repeat when button held with FSUIPC for a somewhat reasonable turn time the gauge will eventually only jump in 10 degree increments, even if just one keypress is sent. Which is also not very usable and can only be remedied by reloading the sim. Plus this construct makes it that MultiCrewExperience will also not work with the gauge