Jump to content

Recommended Posts

Posted (edited)

Bear with me...and I am SURE I am not seeing all options for BRAVO users, so this is just a discussion to get things going.

When I was at Air Venture, I spoke with the CEO of Honeycomb and tried their Bravo quadrant with the MU2.  I found it to be a bit confusing and this sentiment was echo'd by one of the Honeycomb sales staff, claiming the confusion stems from "lever movement below the detent" that does nothing.  So as you move the lever aft below the detent, a command is executed just aft of the detent, but you can continue to move the lever backwards but nothing happens...there is no axis values coming out of the hardware below the detent for us devs to do anything with.  Please read on before immediately responding :)

So for Bravo users,  as they move their levers aft TO the detent (in ALPHA region), the axis values goes to zero at the detent and if you map the detent command to "lift power levers", then the levers will immediately animate to the "3D lever 0 position" to match the raw axis value of zero, which is full aft/reverse in the Moo...and a bit of an odd jump of the levers from flight idle to full reverse.

Now lets say you do not have a Bravo with that "command detent"....and we'll use the TBM as an example.  In the Moo, you can elect to have the throttle 'stop at the detent' until you command it over, at which point it then animates to match the raw joystick value.  Now where this 'virtual detent' is on your own hardware is subjective.  Whose to say the 'virtual detent' in the TBM should be at 30% of your raw joystick movement...or 40%  or perhaps whatever the real thing is?  In the Moo, I think I hard-set it to 50% as per the real quadrant (and ignore the power detent ratio..which is for REAL detents only). This gives identical resolution in ALPHA and BETA range raw values and matches the Moo's 50/50 split.    

The point I'm getting to though...is that in this second example of a simpler joystick (no command switch aft of lever travel), there are still non-zero RAW joystick values below the 'virtual detent' in which to operate your joystick in the BETA region...so you don't get that funny jump to full reverse.  In the Bravo, this is not the case...UNLESS you're OK with never moving the joystick below the detent and adopting the "simple throttle lever" technique ....i.e. the Bravo detent position is analgous to a simpler joystick's "full aft position" where the raw values are zero.   This is what I found odd about the Bravo with regards to the MU2.  Your mind says "I want continuous BETA control below the detent", but there are no raw values to work with.....only the command trigger.  So when the command is executed at raw joystick values of 0...what should happen?

SO....after dreaming about this the following night.....if it were ME and I was a Bravo owner.....I asked myself...what might feel natural with the Bravo...even though the Bravo config does not mimic the MU2 quadrant well..and some compromise is required no matter what.....and this is what I'm currently thinking...its a bit of a combination of TBM-like behavior and IXEG behavior all rolled into one..and not sure yet what roadblocks I might find if I go down this road.

As you move your Bravo lever aft towards the detent position, the 3D levers move in the ALPHA region normally, from max throttle to flight idle.  I'd call this the lever ALPHA MAPPING.  If you continue to move your Bravo lever further aft though and trigger the command switch, then we could switch to BETA MAPPING and the "full foward position" of your Bravo now becomes the flight idle position....and full aft of your Bravo now becomes the full reverse position; however, being that your lever is full aft at the instant of command triggering from ALPHA to BETA... the beta mapping would not be effected until you moved your lever full foward to essentially "reset the mapping.  So, in essence, joystick movement is temporarily ignored when transiting between ALPHA/BETA modes until you move your levers to the opposite limit position and initiate the new mode.  This is where a ghost-throttle graphic would come into play in some fashion.   When in the BETA MAPPING mode though, the command switch would do nothing if you move your levers below the detent, because you can't, in reality, move the lever any further aft and there would be nothing to do. This might be awkward for some...but again, the Bravo doesn't map to the Moo quadrant well.

Another question though....How then, do you switch from BETA mapping back to ALPHA mapping when moving the lever towards the forward limit of travel.... because there is no command switch at the forward travel position of the Bravo.  You'd be using a hardware switch command to go from ALPHA to BETA, but not from BETA back to ALPHA.  That would have to be either a keystroke command or "smart ghost throttle code" in combination with a 'sniff command' to let the Moo know you want to switch modes (and not just stay against the stops).  

The reason this would be acceptable "for my mind" if I was a Bravo owner, is because the hardware lever would always moving in the correct direction when in ALPHA/BETA modes.....BUT...with the compromise of a quick lever movement to the opposite limit to effect the change..and this could be awkward also as it is an unnatural movement when nothing is happening.  So for example....during landing, you'd pull the Bravo levers to the detent  (flight idle)....then after landing and wanting to go into BETA....effect some command (hardware switch or keystroke) and immediately move your levers full foward to 'reset the mapping'...and then you could pull your levers AFT to effect reverse, same as in the Moo.  Even this has an annoying compromise if you're constantly going into ALPHA/BETA when taxiing as you'd be slapping your levers all over the place when switching modes.

I couldn't say that after a bit of use with the Bravo, I would not just opt for the "TBM like" behavior and ignore the detent command altogether.  There seem to be no ultimate solution that satisfies all.

So...I'm ears to hear your suggestions, thoughts and recommendations, but in the end, the Bravo lever tech does not map well to the Moo IMO...so I am curious as to what the most preferred method may be that most will accept (because it will never be all)

-TomK

Edited by tkyler
Posted


Please take a look at my current solution with Bravo:

I have been using this configuration for a week and I am very happy with this solution.
I would not like the new version of MU2 to prevent me from using this solution. ;-)

 

 

 

Posted (edited)

Of course, it would be great if the commands I had to "create" in the lua script could be accessed directly from within XP / MU2.
In my solution it works like this:
 - Alpha range - it is about 50% of the range of lever movements (upper range) of Bravo
 - when you withdraw the lever below the Alpha point - the MU2 throttle remains at the lowest Alpha setting (no matter how far you withdraw the Bravo lever - this prevents you from accidentally entering the Beta range during the flight)
- when you press the button (MU2_LIFT_BOOTH - I'm assigned to the button "Go Around"), then the throttle MU2 lever rises(pulled) and moves to the maximum BETA setting (THR_R and THR_L = 50) 
(but only when the Bravo lever is in the near position of the Beta range - "if (THR_L <0.53) and (THR_L> 0.47) then ....")
- when you continue to move the Bravo lever down, you smoothly move from Beta to REVERSE.
For my own use (because I prefer it  ;)) ) I made that the Bravo axis you can use a small reverse string value (THR_L and THR_R = 10), which allows a safe range power during a taxi.
- I get the full Reverse by moving the Bravo levers completely back, where the button to which I assigned the commands: MU2_REV_L and MU2_REV_R is used

This solution also allows any individual descent from Alpha to Beta (and REV) for each engine separately. (which may be needed, for example, when one engine fires ;-)).

Moreover, as I wrote earlier,
it also improves the behavior that after starting the engines (from the C&D state) the "LOCKS PROP" locks remain blocked (although after starting the ENG Torque 1 and 2 indicators show RPM -  this is not correct). To release the Prop Lock, the Throttle levers must be moved to the Reverse range.
 

Edited by Bulva
Posted (edited)
  Quote

Bulva's solution works perfectly well for me

Expand  

I still can't figure out what it does :P   Mostly because the FlyWithLua API  is strange compared to the X-Plane SDK start/hold/end callback paradigm...so I can't tell if there's any "hold" or "one shot" things going on.  I really need either a video of both the hardware and 3D quadrant at the same time, or a really really good step by step description of moving the lever from full power to full reverse and whats going on along the way....when buttson are pressed, what happens when the buttons are pressed...are they being held down?  or the levers moving WHILE buttons are being held down?  etc, etc.

-TK

Edited by tkyler
Posted (edited)

So one by one (as long as it allows me to translate the google translator well;) ).

I will describe it for one of the throttle Bravo axes (the other one behaves identically):

1) upper range: from 100% to 50% of throttle range - axis Bravo works normally for throttle Alpha range.
2) going down - to a value of about 50% (here my lua script checks if Bravo axes are between 47-53% of the power range by checking the parameter - "xscenery / mu2b60 / manips / L_power_lever_rotate" (lines 16 and 24 in lua script)
3) when I move the Bravo throttles down (without pressing the button) nothing happens -> the power remains at 50% - which prevents accidental entering the Beta range during the flight
4) when you are between 47-53% power ("xscenery / mu2b60 / manips / L_power_lever_rotate") and you press the "MU2_LIFT_BOOTH" button then:
4a) if you are outside the range of 47-53% - pressing and releasing the button and "MU2_LIFT_BOOTH" does not change anything
4b) when you are between 47 and 53% of power and press and release the "MU2_LIFT_BOOTH" button, then the lever is raised (dataref ("PULL_L", "xscenery / mu2b60 / manips / L_power_lever_pull", "writable") -> PULL_L = 0.013 - line 18 of lua script) and it will move to the Beta range (THR_L = 0.50 -- lines 19 and 27 in lua script).
5a) If you move the Bravo lever back up, you will return to the Alpha range again
5b) if you move the Bravo levers down, you will decrease the power in the Beta range.
6) in the Bravo profile (THROLTTLE 3 (4) AXIS RESPONSE CURVE)) there is a horizontal line between 40 and 50 set to a value of 49 to provide a margin of "inertia" when you move the Bravo lever. In other words, you have "more space" to effectively use the "MU2_LIFT_BOOTH" button.
7) on the left, extreme side of the THROLTTLE 3 (4) AXIS RESPONSE CURVE profile, I have set the minimum value to 10, it prevents entering the maximum reverse range. The value "10" is my individual setting, in which you smoothly (being in the Beta range) control the low power of the reverse, which is convenient during a taxi.
8) At the very bottom position of the Bravo lever there is a hidden switch (no. 9 and 10) that activates when you slide the Bravo levers all the way down.
I assigned the command "MU2_REV_L" (and similarly MU2_REV_R) to this switch.
When the Bravo throttle is still down (the button is still pressed), then the reverse thrust power increases continuously (if (THR_L> 0.0) then THR_L = THR_L - 0.002 ----> lines 47 and 58 in lua script), until the maximum reverse thrust is reached.
9) When you flip the Bravo levers back up (the button is released) and the power is controlled again the Bravo axis in the Beta range

I'm sorry I can't describe it better.
There are a few people who have tried my solution and are happy with it, so perhaps someone with a good command of English can do a better description of these steps.

 


At this link there is a short video for download,  that shows how the throttles MU2 behave with my solution:
 

https://mega.nz/file/Q7pCwZIR#CDOniuNOnzDj7V0EHWF1yq756G0FAmWpWalIaI0APKg

 

 

Edited by Bulva
  • Like 1
Posted

In another post, I gave my own interpretation, I suspect you'll come across it if you haven't already.  Your explanation above seems to be very close to my interpretation also so I think I have a good understanding of your operation.  My biggest concern is making sure I accomodate your preferences while not messing up other settings I have for other hardware configs.  I have most all of the 2.0.2 update items done (docs do not reflect this yet) and I'm quickly getting to this last item, which is accomodating the bravo (with its "button at the detent") which is a bit unique.  So hopefully tomorrow I can get this work put it and get the update out asap.

Worst case, its not quite there, we work through it and I get another update out :)  

-TomK

 

 

Posted
  On 8/6/2022 at 8:55 PM, tkyler said:

... I'm quickly getting to this last item, which is accomodating the bravo (with its "button at the detent") which is a bit unique.  

Expand  


It is not such a unique solution. If I remember correctly, the popular Saitek Pro Flight Throttle also has a button in the bottom position:


  1.jpg.e8978694de0b10b3ee3078c069d5db21.jpg

  • Upvote 1
Posted (edited)

movie is standard MP4.  Don't know what else to do...possibly a Windows incompatibility?  It was encoded on a mac.  I'll see if I can re-encode it.    Its simply a video of the ghost throttle with 4 options for viewing:  NEVER, ALWAYS,  Flight idle and below,  when misaligned"

The wrong CODEC was selected when I exported.  See YouTube link below.

-tk

Edited by tkyler
Posted

It looks promising (although the throttles visualization for VR users does not contribute anything).
I just hope that it will be possible (using one button) to go down to the BETA range for each axis separately (not with the mouse, but with the Bravo axis).

Posted

Looking real good and useful Tom. One thing I think it's still missing (using Bulva's script as an example) is to make the "Lift throttles command" ONLY valid when hardware throttles are within that Alpha/Beta transition zone in order to avoid sudden jumps when HW levers are already way down the Beta zone but the Software levers are locked in lowest Alpha then Lift Levers command is pressed and that's where the "catch up" jump occurs. 

In other words, only allow the Lift levers command if HW levers are in that zone, not before nor after; to avoid any unsync between HW and SW levers.

 

Just my 2c.

Posted

@gercast : that's actually the function of the ghost throttle visualization. Then, we will be able to know precisely where the SW throttle levers are before activating the lift throttle command...

Posted
  On 8/8/2022 at 4:11 PM, danhenri said:

@gercast : that's actually the function of the ghost throttle visualization. Then, we will be able to know precisely where the SW throttle levers are before activating the lift throttle command...

Expand  

If you are in VR it doesn't do anything ;)

Posted
  On 8/8/2022 at 3:56 PM, gercarst said:

Looking real good and useful Tom. One thing I think it's still missing (using Bulva's script as an example) is to make the "Lift throttles command" ONLY valid when hardware throttles are within that Alpha/Beta transition zone in order to avoid sudden jumps when HW levers are already way down the Beta zone but the Software levers are locked in lowest Alpha then Lift Levers command is pressed and that's where the "catch up" jump occurs. 

Expand  


I don't know if I understood You correctly, but in my solution the place where you press the button is checked and it should work as you describe ...

Posted
  On 8/8/2022 at 4:51 PM, Bulva said:


I don't know if I understood You correctly, but in my solution the place where you press the button is checked and it should work as you describe ...

Expand  

Yes, I was mentioning your solution as a suggestion to Tom to integrate something similar to the throttle behavior so that no extra LUA script would be necessary.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...