MobiFlight Community Support

Hello!
First of all, I've had success on configuring an encoder with MFS2020 to control the heading, and it is great! I first used FSUIPC Offset (and $+-182) but it was giving me trouble in 180º (i now found you need to set it to 4 byte) so I ended up using an EventID.

However, I am unable to find a way to control the push/pull functions of the knobs in the A320 (heading, speed, altitude...) to change between selected and managed mode.

Although this might be more a question for FSUIPC7 I'm wondering if there is any EventID or FSUIPCOffset to control this "pull or push" function of the encoders.

I'm sure it has to do something with the HEADING_BUG_SET offset in case of the heading but I cannot get it to work... Is there a way to to move the visible heading bug without instantly updating the autopilot's heading hold function?

Thanks a lot!

Hi

As i know this function is still not implement in FSUIPC ( maybe meanwhile it is.... i don´t know in case i not active use it)
Same problem with many other "new" systems of FS2020 cause FSUIPC7 at first only inlcude stuff that was possible in P3D also. Means new things are missed maybe already.

To solve Sebastian impelment in the new version a new typ of Input.... "FS2020 Simconnect"
These are "Events" that are directly from the sim ( No FSUIPC usage) . Maybe the needed is still included. If not you can incude it yourself by editing the WASM Module.

Check the Discord and Youtube Channel. Lots of other user still work with it. ( I can not help cause i not use FS2020)


*******************

Important Note:

You should understand what you do before you start up!

I first used FSUIPC Offset (and $+-182) but it was giving me trouble in 180º (i now found you need to set it to 4 byte) so I ended up using an EventID.

Thats fully wrong and against all rules !

YES its correct that the 180° Problem is solved if you change into 4 Bytes.... But this is just optical and temporary.... It will not Work at all !

In easy words.... If you learn and understand, WHY the setting to 4 Byte solve the Signed Bug..... then you also know why this is wrong and can not work finaly !

Hi! I will have a look at FS2020 Simconnect! Many thanks!

Hi
Important Note:
You should understand what you do before you start up!

I first used FSUIPC Offset (and $+-182) but it was giving me trouble in 180º (i now found you need to set it to 4 byte) so I ended up using an EventID.

Thats fully wrong and against all rules !
YES its correct that the 180° Problem is solved if you change into 4 Bytes.... But this is just optical and temporary.... It will not Work at all !
In easy words.... If you learn and understand, WHY the setting to 4 Byte solve the Signed Bug..... then you also know why this is wrong and can not work finaly !

You are totally right! I understand the sim translates the heading in 2 bytes (65535 numbers) but it can be unsigned or signed (-32768 to 32767) and 65535 is converted to degrees dividing in 360. So yeah, setting it to 4 byte doesn't make much sense really... was more of a desperate solution haha.
I'll check the documentation on how to put a transform funtion into "Set value"... like if the value is <0,$+65535 or something.

Thanks

OKay, I managed to get the heading to work using a FSUIPC by solving the "break issue" between 179 and 180 degrees due to the signed 2-byte.

If its of any use to anybody:

Left: if($=-32768,32767,$-182)
Right: if($=32586,-32767,$+182)

Checking the logbook of FSUIPC however, MFS2020 uses the Heading_Bug_Dec and Heading_Bug_Inc when you turn the heading with your mouse

Thanks anyway

I see you undertand.... Math and Informatics are no magic if you understand them !

So you also know now..... Range go from 0-65535 ..... And in case of Signed/Unsigned we got the "negative" Problem at 180°
If you "cheat" and use 4 Bytes..... Then it solve "temporary" the Problem cause Offset Value already goes from 0-65535 .....
Now the Signed/Unsigned Swap Point would be at 2.147.483.647 so far far away from our 65535 Max Value

BUT Lets look in the Offset List .

07CC 2 Autopilot heading value, as degrees*65536/360
07D0 4 Autopilot altitude lock

If you "cheat" and increase simply the Offset Size to 4 Byte then your Config will read 2 Bytes of 07CC and also behind the Bytes 07CE and 07CF
Funny Fact.... In this case it would work ! Cause these 2 Bytes are not used by a "coincidence" ... The next used Offset is 07D0.

But now look a little below.....

07E2 2 Autopilot airspeed value, in knots
07E4 4 Autopilot mach hold

Here the First Offset have 2 Byte.... And there is no "free Area behind" .... After the 2 BYte 07E4 start !
If you cheat here.... Then your Config will read 07E4 AND by fault it would also read the 1/0 Data of the first 2 Bytes of the Mach Hold Switch.


********************
Summary:
I must say apollogy.... Cause in case the offsets behind the AP Heading are Empty your fully right.... Swap to 4Byte INT solve the Unsigned Bug without any disadvantage !
But same time my comment was correct.... This can not be done at all time.... Only work in this example in case of pure luck !

Thanks, much appreciated

May I ask another question about managed /selected mode for the A320 in MSFS2020?

What I would like to achieve is using the button on the rotary encoder to toggle between Managed and Selected. That would imply that I would have to create a software switch in Mobiflight to be used as a toggle. Sofar I did not succeed but maybe some of you found a solution.

Thanks in advance for any suggestion.
Hans

PS In the meantime I found a kind of solution within this thread https://www.mobiflight.com/forum/message/20423.html

I assume that this still is the easiest solution. Is that correct?

Hi
This situation occure in case we got multiple problems here for now.

1. FS2020 is different and our former system we used for many years ( FSUIPC) is not working fine already..... So in the past those inputs are done within 20 seconds. Now thats no longer possible.
We still implement a new tool (WASM) so we no longer be depended to FSUIPC but also this is not working 100% in case FS2020 not allow the full range of connection till now.

2. The wrong way of Input.... Normaly this is a latching switch. In real aircrafts the Button is Pulled or Pushed. So we would not need a Toggle.... We would use a latching On Press or On Release input.
This was also tricky in the past for PMDG Boeings. They support a perfect System but only if you also use the correct Switches. Means Toggles for a Latching system was not possible and also backwards a latching switch for a toggle would not work.

****************

Solution:
For NOW the linked topic is a improvisional Sulution. And we must live with it a.t.m. ( NOTE: Check the Discord Channels or talk to FS2020 Pros. Maybe they still find a better way.... I not observe that in case i not use FS2020)

Hopefully soon we get a better interface to FS2020 ( more options in the WASM Module) . Additional Mobiflight will offert a new Placeholder System for Inputs.... So we can much more easy solve this within Mobiflight itsef, too.

In easy words.... Use the current (bad) options (like the linked topic) if you need it now..... Or wait a while until we offert a new System with next releases ( maybe summer 2021) that can handle all that stuff more easy and comfortable !

A method of achieving a push / pull arrangement for the FCU controls is shown here https://www.youtube.com/watch?v=1OmkiEdfpPI or search Rotary push-pull encoder for Airbus A320 FCU in YouTube

Not my work but quite simple and effective as the momentary switches provide the signal and force to return the control to the mid position.

Geoff