If anyone has a Honeycomb Bravo throttle quadrant can you tell me if the trim wheel currently works and works well? Can you look at the actual trim wheel in one of the single engine small Cessnas and see how the real trim wheel in the pedestal moves when you move the Bravo’s wheel and describe that? I’ve 3D printed a scale trim wheel from a 172, connected to an encoder, connected to an Arduino, connected to the sim as keyboard input. (I was using it as joystick input before the last update, but something changed there). I’m using this until the Bravo starts shipping in quantity.
It’s working kind of ok - but not like a real plane’s trim wheel exactly but way better than using the keyboard or trim switches on the Alpha. Was just wondering if a professionally made trim wheel works before I spend an eternity trying to reverse engineer how Asobo is expecting trim information.
The trim wheel on the Bravo is just an encoder. Nice to have, works well enough, very little friction. If you’re really trying, you can (barely) hear and feel the encoder ticks. If your Arduino code is just firing one command on/off in one direction and another command in the other per tick, then it’s functionally the same as far as I can tell.
Thanks! Does the real trim wheel in the pedestal move smoothly? With my Arduino interface I can see the trim tab on the elevator move but the trim wheel on the pedestal sort of hesitates back and forth. When looking at the exterior of the plane the trim metric moves, but it takes a lot of physical trim wheel movement to get that to move and it does not seem linear. One of the biggest problems with the Arduino interface is figuring out the timing for the key down and key up - or the joystick down and up. I have experimented with all kinds of values.
So looking at the Bravo interface - it says the trim wheel is using joystick commands? In that case, I’ll go back to the joystick code and use that instead. And figure out that timing.
Why isn’t the Honeycomb Bravo using the “Trim Axis” instead of “Trim Up” and “Trim Down” buttons? This sounds like a disappointing limitation unless I’m not understanding something here.
I’ve used an optical encoder and a Netduino to setup wheel controls in other applications. You can get the absolute position of the wheel with a lot of precision and it spins smoothly and quickly. I’d try to bind that to “Trim Axis” in Flight Simulator if I were making my own controls.
Right now I have the throttle wheel on my joystick bound to “Trim Axis”, and it works really well. I was looking at getting the Bravo too, but if it’s going to be a step down from what I’m already doing with my 20 year old joystick, I’m going to have second thoughts.
@PapaKilo224 Feels relatively smooth and linear enough to me, although I haven’t really cranked it fast to see if it skips steps or anything. It at least doesn’t seem to have the nonlinear characteristic of the Alpha yoke where if you hold down trim buttons the value starts changing faster and faster the longer you hold it down. Haven’t noticed the pedestal wheel twitching – admittedly I haven’t been looking for it. I do remember having this twitchy value issue with an Arduino throttle quadrant I had built before the Bravo came in, and I vaguely recall I had added some smoothing logic to take care of the worst of it.
The following might be vaguely helpful or just heading down the wrong path… I put together a quick & dirty Max patch to check the encoder events. With a [hi] object poll time of 1ms using the [timer] object the trim wheel reports 24ms to 32ms between ticks when spinning the wheel freely (~1 second per full rotation).
@SkipTalbot Not sure what to say there. It definitely doesn’t send an axis when spun, and (to me) it behaves like a typical incremental encoder, not an absolute one. So if there’s any positional feedback I won’t claim to know enough to tap into it. Seems unlikely, though.
Would be nice if there’s additional logic to tune behaviors after Honeycomb and Asobo get the annunciator and landing gear lights working, but given the positioning of the Bravo as “driverless” (…once driver logic comes in a future update…), that’s merely wishful thinking. Maybe could hack something together with vJoy and Freepie type tools, however anything is but a workaround at that point.
Thanks for the info. I guess as long as it’s smooth and responsive, maybe it doesn’t matter if it moves in steps vs on an axis. I just shudder at thinking of having to constantly nudge the wheel up and down because you can’t just dial in the trim perfectly, like pressing buttons on a joystick it seems like you’re always chasing the trim.
Off topic, but wasn’t there a link to preorder directly from Honeycomb, shipping directly from the factory? I can’t find it now and remember seeing it just a couple weeks ago. Is that gone already?
If you were referring to the Bravo pre-order on their website back in early September: Yeah, that’s way, way past gone I’ll wager that whole ‘event’ has been discussed to death in other forum topics. Not how I’d suggest spending your time.
Thanks a million for the heads up on the cycle times for the joystick pushes - that will save me a lot of time. I was just throwing darts guessing at the timing - and as you can imagine the test cycle time, plugging and unplugging (i do the development on a 2nd computer) is time consuming. Are you saying that the time the button needs to be pressed is only 1ms?
No, I was just polling for HID events every 1ms. According to the MaxMSP [timer] object which I set up to measure time between events, I saw times of 24ms and 32ms between the encoder creating joystick button events when spinning the wheel.
Edit to add: Which means I think the time between each event’s ON and OFF would be either 24ms or 32ms; probably 32ms to be safe?
BINGO! You hit the nail on the head with that one! Using 32ms for the amount of time the button stays pressed and 32ms between presses seems to work really good! That took just about all of the “twitch” out of the sim’s trim wheel in the pedestal - the view of the sim’s trim wheel is the least of my concerns, I was just trying to use the sim’s trim wheel as some sort of way to measure what was happening while on the ground. When using the external view of the plane - the trim gauge moves pretty good in step with what the physical wheel is doing. It’s still no where near how a real trim wheel works - but it’s 1000x better than using the keyboard or the trim buttons on the Alpha. With a cycle time of 64ms that means only ~15 clicks per second. With that limitation there is no way that is going to approximate what a real Cessna does. And it seems like that zoomy weirdness when you hold the Alpha’s trim button for more than ~1 second creeps into this equation as well. I imagine with time Asobo will get this worked out. This is, and rightly so, probably about 9 billion on their list of things to work on.
*if you want to see something hilarious - go to the external view and make sure the trim setting is set to no trim. then go to the inside view of the plane, and give the trim wheel just one turn - just grab it with the mouse and pull it all the way down. then go back to the outside view and see how far that moved the trim gauge. I feel sorry for pilots with no time in an actual plane if they twist the sim’s trim wheel by hand.
I can’t thank you enough for putting the scope on there and giving me a heads up on the timing - that really helped!!
I’ve built my own arduino based trim control using a 10-turn potentiometer and the Trim Axis setting in MSFS. Super smooth and works well…until you change the trim in some other way (e.g. autopilot), then the next time you touch the trim wheel (or if you don’t code it right and there’s some jitter in the pot) then the trim will jump to the current trim wheel setting and not the small adjustment you though you were making.
So, using an up/down control approach is probably the better decision. Having a motorized pot as the trim wheel would be technically possible, but overly complex.
Yeah, that’s true, and I saw your post about that build. Looks super cool. I of course have the same “jump” issue with using the Joystick throttle axis as the trim. The wheel has an indent that makes centering the trim a snap though, so that jump is just a minor inconvenience, like I’ve bumped the yoke. It’s also nice for checklists where I can reflexively set the trim for take-off just by feel. I imagine with a step up/down wheel you have to actually look at where the trim wheel is set in the rendered cockpit? Not that that’s a big deal either.
The encoder method works pretty good since it has an infinite range of spin. It too needed to be debounced in code. The real trick was getting the timing down. Glitchmunk providing the timing data was really helpful. My implementation is no where near what a real trim wheel is like, but it’s good enough to trim the planes with. And until the sim matures a bit more - pretty sure we are just guessing for now - the last update changed the number of key presses to move the trim wheel the same amount. Previously it was 17 key presses, now it’s somewhere around 23. This is the encoder I used.
For what it’s worth I’m also running the FlightTracker plugin for Stream Deck. One gauge readout is the trim value. Again, nothing like the real thing but it serves as a visual cue for trim state.
It seems there are still two issues that make elevator trim somewhat unrealistic - but it’s still better than a poke in the eye with a sharp stick. First it seems like an external device can not send data fast enough to make the trim tab move far enough to cause a representative change in the plane’s attitude - and it seems that some button presses are even being ignored. With a 32ms button down time and a 32ms wait time before the next press can be sent - at best only 15 presses can be sent in the period of 1 second. And this doesn’t count any of the tragic overhead the Arduino joystick library adds. I just looked at the source code for how that library works, and that’s an unnecessary cycle eater for this application. No idea yet how much the HID library is adding on top of that. The next problem is the latency in which elevator trim effects the flight model. In a real 172 or any Cessna single engine piston plane with the throttle at least at 60% the effect of the elevator trim tab is nearly instantaneous. The sim seems to take about 3-4 seconds for trim to take effect and this induces an evil amount of porpoising when trying to correct it. Cant’ do anything about that one Asobo has to modify that reaction.
An interesting experiment might be to time the encoder’s pulses and if they are close together, just keep the button pressed, sort of like what the trim switch on the Alpha does when you keep it pressed - but then that odd delay before the trim starts moving is invoked. No idea why they did that. I have a real T210N with an electric trim switch on the yoke and there is not any delay in the plane’s attitude change when that button is pressed.
Somebody asked previously, but I didn’t see you guys respond…
Is there a reason you used an encoder instead of a potentiometer and assigned the pot to the trim axis instead of hitting buttons? Seems to me using the axis would be more satisfying and accurate?
Wondering…
I realized I could use the throttle axis of my Logi Extrm3D, just set it up, see how it works. Although, I imagine a pot with a large wheel might work better with a longer throw so more accurate placement. This throttle axis on the joystick might be too sensitive?
Edit: Nevermind,… because it doesn’t work, haha
Edit 2: Wait! It does work!, Just have to choose the right elevator trim axis choice the -100% - +100% Works great! Now let’s see what it’s like to fly with. This could be a game changer, I hated using buttons to go up and down.
A minor problem with using a potentiometer is the software is not aware of the physical position of the wheel and there is no synchronization between the potentiometer and the sim’s concept of where the trim wheel is. If the autopilot kicks in it’s going to move the trim tab and you may not have enough travel left in the potentiometer to get reasonable control back. It will be interesting to see what happens with a fight between a pot and the autopilot - when the pot is moved off center and the autopilot tries to move the trim tab. The encoder / Arduino just sends pulses one way or the other and never runs out of control. If the pot on the Logitech Extreme 3D is too sensitive consider yourself lucky. Using ether the numeric keypad 7 and 1 or joystick buttons is way way under sensitive. Like my post above states, there are an additional 2 issues to solve - one is the way under sensitivity of elevator trim tab control and the second problem is the excessive latency that occurs when changing the elevator tab.
So, in this case, what I’m suggesting is a 360 or less pot, of similar quality to a joystick pot so there’s no appreciable hysteresis. In fact, I think this rotating pot is only a 45 or 60 degree pot. (I’m assuming it’s an analog pot, I don’t actually know, but it feels like one).
The throttle (rotating) “slider” of the Logitech Extreme3D Pro works great as an elevator trim using it as an axis. I’m glad I happened upon this thread, I never would have thought of doing this without it. It makes flying sooooo much easier than using the buttons to adjust trim. It feels pretty much exactly like I’m flying for real (except, of course, you can’t feel the forces, so it’s easy to overdo it, but, super easy to get the hang of).
It was always super hard with the buttons to get the right trim setting, the change was too much around the sweet spot. Here, I can move it till it’s just right. And latency is non-existent. I’m pretty sure with the buttons, the first press doesn’t do anything, and it’s only subsequent presses the value changes. At least that’s the way it always seemed to work to me.
But you’re right, it’ll be interesting to see how MSFS was written to overcome the axis with the autopilot. My hope is, they just turn the axis reading off, then give it back when the AP is turned off. As an axis, it knows where zero is at all times, and 100/-100 are at the limits. I rarely fly with the autopilot, (and there is none in the planes I fly), so, it’s not a huge deal to me if they did it wrong, but, this is great!
I’ll wager that whole ‘event’ has been discussed to death in other forum topics. Not how I’d suggest spending your time.