tkyler

Its VR...look down

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

ghost_options.mp4

In modern equipment, I believe this is the case. The GLASS version should do that. ...but to my knowledge, the OBS on the old RD-550 HSI is a manual setting and is not slaved to anything. There is a specific option in Planemaker to automatically slew the OBS to the desired track of the OBS...but I have not selected that option for the OEM / GNS variants because of this old unit. (The RSG G500 requires it however). As such, it can be adjusted at any time. If the OBS on this old unit can be servo/clutch driven, then I am unawares of such functionality on it. Also, when the 530 is in GPS mode AND OBS is selected on the 530....then the HSI knob can be used to input an intercept bearing to a waypoint. As far as the HSI OBS not adjusting in GPS mode as Daniel mentioned origninally, that has been fixed for the next update. -TK

That looks more normal "as far as rotate movement"..which is what I keyed on in my previous response. Understood on the "no sound and no lift animation" will look into that. TK

step in the right direction

@Bulva somthing is funny. See below screenshot. On the left is my mapped hardware axis value is 0.08, exactly as shown in your response curve screenshot above and validated by dataref editor output.. For this prop1 hardware axis value of 0.08 (8% of overall prop RPM range), then the resulting prop rotation speed should be between 114-115 rad/sec....and the 3D lever is animated based on the RPM setting (not hardware position) and should just align with the TAXI mark at this (0.08/114.7) value pairing. The 2nd screenshot at the right, shows a non-adjusted response curve, 0-1...and an axis value of 0 (lever fully aft)...and the 3D lever is now below the line as expected in this case..its lowest possible position with a hardware axis. The only way for me to confirm your full setup is for you to send a similar screenshot. In the end, we're matching numbers to animation so without the numbers, I can't tell whats going on. This is straight up linear interpolation and its working perfectly fine on every axis I try this with. Your 2nd video suggest no response curve mapped to 0.08 on the low end.

post reponse curves for the prop axis please Bulva.

Updated docs (bug tracker) to reflect work done towards 2.0.2 update. Should roll through remainder very quickly, within day or two at most. -TomK http://togasim.com/mu2docs/supplements/bug_tracker_201.html

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

I'm going to attempt to describe your hardware behavior @Bulva Let me know if I'm on the right track understanding it. As you retard your hardware levers from the ALPHA region towards the BETA region...you approach the Flight Idle position, i.e the "transition zone" (0.47-0.53) in your script. Because of the checkbox "Auto-stop at detent"...if you move your levers further aft of your tolerance zone, then no harm no foul...we're all good, the levers won't follow. BUT...you have to be in your tolerance zone to lift the lever so when you do lift if, you don't get any crazy lever moves. THEN....as you continue to move your levers further aft towards hardware position zero (just above your detent button), you are now controlling the BETA prop pitch directly....BUT...because of your response curve, Bravo hardware position 0 is NOT mapped to 3D lever position 0 (full reverse pitch)...i.e, there is JUST a little bit of negative pitch "still in reserve" So now, with your joystick at hardware zero and JUST AT the command detent....you can pull your hardware levers aft over that detent and the REV commands will command the 3D levers JUST a bit more aft for full reverse? And you can tweak your response curve (left side) and the REV command substractions (currently 0.002) to tailor the transition to reverse to your liking?....and I assume the 'flat spot' in your response curve is simply to give you a bit of wiggle room around the tolerance zone? Is that an accurate description of your operation and preference? -TK

I still can't figure out what it does 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

The original intention of "lift both power levers" was for users with single paddle hardware, which use a completely different array index value for THROTTLE. It really wasn't intended to be used with dual lever setups. When you execute that command with the 'TBM style' method, then I look at the raw joystick value to see where the hardware is so I can move the virtual throttle to match its position below the detent. If you have a dual lever setup, then what I do currently is look at the "single lever" array index value (which is zero in your case because a single lever throttle isn't assigned in a dual config) and bam...the levers jump to zero because they think that's where the hardware is. That's why they jump to reverse. Of course that is still a relevant command, even with dual levers....so.. ....what may be needed here is simply a separate set of 'lift' commands, one for single lever and another for dual. That is, by far, the easiest solution, rather than me trying to write a bunch of "guestimate' code on lever assignments.

ah yeah, Ok, I'm seeing what you're seeing now. tk

Default commands now drive the alt preselector Added 3 commands for this switch Those default commands do drive the barometer knob/values for me. Default commands drive the DH knob/display now.

Implemented for 2.0.2

And just got some hard numbers from a Moo owner. FI torque is approx 15% on the ground and leans closer to 20% on descent, but may vary based on engine 'personalities'. also, I met with both Philipp and Austin at Oshkosh AirVenture...and Philipp is going to put in both NTS lockout and overspeed governing for the TPE. Its a lot easier for them to do it in their code base than for me to "hack" around their current implementation -TK

agree, just need to record the right sound. Particularly the latch. Wasn't happy with what I orginally had, but definitely will get those sounds in. -TK

Understand your sentiment Marc and many times, these bugs do seem silly, even to me. I'll keep fixing though and we'll get through this phase soon enough. -TomK

The knob is animated off of the default x-plane dataref, nav1_obs_degm (because the knob is mechanically linked to the compass card). The knob should animate any time the HSI OBS rotates. The GPS/VLOC should have no bearing on the knob animation of course.... Those commands animate the HSI knobs for me no matter what mode (VLOC/GPS) I'm in, so I can't confirm what you're seeing.

All good Jerry, thx for clarifications! -Tom

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

Back from Oshkosh Air Venture airshow. Thx for patience...I'm off and running again. http://togasim.com/mu2docs/release_log.html Slightly revised the bug tracker links at left side of page to be a bit more clear with regareds to versions. Also added new bug tracker page towards the V2.02 release for folks to follow along. -TomK

I'll take a look at each of these in this current update pass -TomK