#Trouble reading SF50 Autothrottle status for VKB GNX-SEM LED indicator

1 messages · Page 1 of 1 (latest)

devout sedge
#

Hello, I am trying to drive one of the LEDs on my VKB GNX-SEM to display the status of the autopilot for the Vision Jet in MSFS2024.

I want the LED to be:

  • Off if the Autothrottle is disabled
  • Green if the Autothrottle is enabled and in FMS mode
  • Yellow if the autothrottle is enabled and in Manual mode

  1. Mobiflight recognizes my GNX-SEM and I’ve confirmed that it basically works. I’ve successfully configured buttons on it to control things in the Vision Jet and using the test feature in Mobiflight I can change the color of the LED to all the states it supports (off, red, yellow, green). So, this means the definition files included with Mobiflight include support for my GNX-SEM and I should be able to use it. Right?

  2. In the output config display tab, the alternatives offered for the GNX-SEM A2 LED are “SEM A2 - Green” and “SEM A2 - Red”. With those being the only alternatives for the A2 LED, the only way I can configure it to display two colors (in my case green and yellow) is is to use two output configs defined for that LED. There’s no way to display two colors with just one output config on that LED. Right?

  3. I can’t get even one output config to work correctly on that LED. I created an output config which turns the LED off if the autothrottle is disabled and green if it is enabled. I specified “SEM A2 - Green” in the display tab and can control the LED using the test feature. So, that seems to be working fine. However, I can’t seem to get the Sim Variable tab configured correctly to read the autothrottle status variable. I’ve attached a PDF with a couple of screen shots of the details for the Vision Jet autothrottle from the behavior tool. It seems looks to me like the SF50_AUTOTHROTTLE_STATUS variable is the one to use, but “(L:SF50_AUTOTHROTTLE_STATUS)” doesn’t work. I’ve tried a few different variations using that variable and also “SF50_AUTOPILOT_AUTOPILOT_ARM” and “SF50_AUTOPILOT_ARM_POSITION”, but nothing has worked. Any ideas?

IMG_1058.jpg IMG_8480.jpg
cedar kayak
#

Yeah, right now yellow is made by turning on green and red at the same time, and the most straightforward way to do so is with two configs. Sadly not too familiar with how the SF50 autothrottle LVARs work.

tepid wadi
devout sedge
devout sedge
# tepid wadi Did you try these presets? https://hubhop.mobiflight.com/presets/?aircraft=Visio...

Thanks for the link. Yes and no.

First the no part. I looked in HubHop, and noticed presets for the MSFS2020 SF50, but somehow I didn’t see that there were autothrottle ones in there. The MSFS2024 Vision Jet is based on the FlightFX version from MSFS2020, but there are a lot of changes including Sim Variable implementation. Still, if I’d seen those presets in HubHop, I would have tried them.

Now the yes part. Turns out, the HubHop preset you pointed me to which is most aligned with what I’m trying to do at the moment is almost identical to what I’ve tried. It specifies “(L:SF50_Autothrottle_Status)”. I was aware of that variable because the behavior tool in MSFS2024 surfaced it as “SF50_AUTOTHROTTLE_STATUS” (as seen in the pictures I attached). So I’ve tried “(L:SF50_AUTOTHROTTLE_STATUS)” and it didn’t work. I’ll try “(L:SF50_Autothrottle_Status)” though that would be surprising wouldn’t it? Since the Behavior tool said it is in all caps? I’ll report back ASAP.

vernal minnow
#

in 24 it has changed to one of the new scoped lvars (L:1:SF50_AUTOTHROTTLE_STATUS)

devout sedge
vernal minnow
#

do not trust an LLM with this stuff. it will send you way down the wrong path

devout sedge
#

Understood. That was really intended as a lame joke. I have used it successfully to help me understand the bigger picture, and to know where I need to dig deeper, but it’s answers are typically flawed.

vernal minnow
#

no worries you can find the scoped lvars under variables > local in the dev mode behaviours dialog

tepid wadi
#

BTW, The Lvar names are case insensitive.

tepid wadi
vernal minnow
#

correct L:1 variable are new to msfs 2024

tepid wadi
#

I mean, you can specify that in msfs2020 too, but it means the same as without the :1

devout sedge
#

“(L:1:SF50_AUTOTHROTTLE_STATUS)” worked! Thanks!

devout sedge
#

There’s one additional improvement I’d like to add. Right now the LED is dark if the autothrottle is disabled and if it’s enabled then the LED is either green or yellow depending on whether the autothrottle is FMS or Manual.

When the autothrottle is disabled, and the mode changes, I’d like for the LED to flash green or yellow briefly to indicate which mode was just set.

I’m thinking that I need two more output configs to make that happen (it can’t be integrated into the output configs I have).

I guess I will need to use “blink” modifier to make it flash once, maybe by setting 500ms for the on time and some very large number for the off time. I haven’t seen any specification for maximum value for those fields. Is there a better way to keep it from repeating the blink timing continuously?

devout sedge
#

In case anyone follows this topic, I got this working, but it’s surprising how much effort it took. If there are better mechanisms than the ones I ended up using, please let me know. The two causes of the complexity were:

  1. Preconditons can only be based on configs and Mobivars. I needed to implement preconditions based on the state of two SimVars. So, I had to create two output configs for the sole purpose of having a config I could reference in preconditions. I don’t know what complexities supporting SimVars as a precondition source might have, but it would be nice to have that available.
  2. Due to a combination of the way VKB controller LEDs and output configs are implemented, you have to separate logic for each color you want to use for an LED into separate output configs. If you don’t, the output configs will end up fighting with each other over whether the LED should be a color or dark. My use case has four different colors/behaviors for a single LED (Solid Green, Solid Yellow, Blinking Green, and Blinking Yellow) and so I had to implement four output configs.
#

The Output configs I implemented:

  1. Output config for use as precondition in other configs returns bool corresponding to the Vision Jet auto throttle enable/disable status
  2. Output config for use as precondition in other configs returns bool corresponding to the Vision Jet auto throttle FMS/Manual mode
  3. Output config with preconditions ensuring that it is only active when the auto throttle is disabled and in manual mode. Drives the LED to blinking yellow.
  4. Output config with preconditions ensuring that it is only active when the auto throttle is enabled and in manual mode. Drives the LED to solid yellow.
  5. Output config with preconditions ensuring that it is only active when the auto throttle is disabled and in FMS mode. Drives the LED to blinking green.
  6. Output config with preconditions ensuring that it is only active when the auto throttle is enabled and in FMS mode. Drives the LED to solid green.

I learned a lot in doing this and it does what I wanted it to do. So, good, I guess. 😉

tepid wadi
#

I think the way you did it is just fine. Just as an idea, an alternate way that could reduce the number of output configs necessary could be to transfer the Simvar logic to the simulator by building more complex RPN calls.
This would only make sense if you are comfortable with RPN and handling Simvars directly.

devout sedge
# tepid wadi I think the way you did it is just fine. Just as an idea, an alternate way that ...

I’d be interested in trying that and I should be able to handle the RPN and Simvars necessary, if i understand the idea behind the improvement. I had two ideas which I thought might yield a better result. . One was a variation on the implementation I ended up building. The other was a different approach entirely.

Possible improvement on existing implementation: Eliminate two output configs by combining #3 with #4 and #5 with #6. If the blinking state could be made conditional based on the auto throttle enable/disabled state, then I could just have one output config for green behavior (solid & blinking) and one output config for yellow behavior (solid and blinking). I wasn’t sure how to make the blinking state conditional.

Different approach: The reliance on preconditions comes from the fact that the green LED is required to produce both yellow and green (setting up the conditions for two output configs to conflict over the state of a common LED.). Theoretically I could revise the logic so that one output config drives the red LED and a second one drives the green LED. The logic would be much more complex, but preconditions would not be necessary since the output configs don’t control the same color LED.

devout sedge
#

FYI, I’m pretty much convinced that the way I described doing it above with 6 output configs is actually the only way to do it. Every other alternative I tried has a fatal limitation.

I was not able to combine any of output configs #3 through #6. I can’t combine #3 & #4 (and #5 & #6) because there is no way to make the blink modifier conditional within a single output config. I can’t combine #3 and #5 (and #4 & #6) because there is no way for a single output config to output more than one color (given the way VKB controller LEDs are controlled).

Trying to reconstitute the solution by controlling the red and green LEDs in separate output configs still required preconditions to keep the blinking and solid states form conflicting with each other. so the same number of output configs was required and ultimately it failed because the blinking green and blinking red states couldn’t be synchronized.

The solution above works. So, that’s fine, but as an intellectual exercise, I was curious whether there was a different/better implementation. At this point I don’t think so (at least not within Mobiflight itself).

Still interested to explore the “transfer the simvar logic to the simulator by building more complex RPN calls” suggestion offered above, but I don’t understand the concept behind it. Is the implication literally that additonal logic could be added to the simulator to provide the needed state variables in a form more easily translated into the desired behavior in Mobiflight? Intriguing, but not something I have any knowledge of. Please let me know if such a capability exists (short of building a special-purpose plug-in, which would be overkill).

tepid wadi
#

With the current solution, you read variables into Mobiflight, Mobiflight then uses these values to make decisions about when the leds should turn on and when they should blink.
In the other case, the simulator is quite capable of doing the same logic via one or more RPN code blocks registered through MF output configs and return already processed values back to Mobiflight. Even blinking of leds can be done. I use to do blinking with the SIMULATION TIME variable long before Mobiflight had a Blink modifier.
I haven't actually attempted to code a solution for you, but should not be too hard, I think.

tepid wadi
#

I guess at minimum you would need four output configs to be able to control 2 leds x 2 colors

devout sedge
#

I think I understand your suggestion now. The “RPN Code Blocks” you refer to are just the RPN code you provide to an output config in the variables tab? I didn’t realize that code was actually processed in the sim (though that makes perfect sense now that I understand what you meant).

Implementing blinking via code in variables tab would be useful since the blinking of multiple output configs could be synchronized (since they would all be derived from SIMULATION TIME). Unsynchronized blinking when using the blink modifier was a problem I ran into when I tried implementing it with output configs driving the green and red LEDs independently. Likewise, it might allow me to stop relying on preconditions. I’ll have to try it to know.

Thanks!

tepid wadi
#

That is, instead of using one blink modifier in each blinking output config.

#

In RPN, blinking can be done with this RPN statement (E:SIMULATION TIME, second) 2 % (>L:myLvar)

#

It creates a user defined myLvar that alternates between 0 and 1 every 2 sec.

devout sedge
tepid wadi
#

You could also extend this logic in a Mobiflight output to consolidate blink and no-blink conditions.

#

Say # is the blink output value and & is the blink-on status.
Then, a transform

if(&=1,$*#,$)
#

So if # is equal to 1, led blinks. All else the led remains solid.

#

But only when $=1, all else the led is off.