Honeycomb Sierra TPM

[michael.woodward 0]

Hi.

 

The gear leds on the Sierra TPM dont work.

Tried the bravo fixes but that didnt work.  

Any update regarding a fix yet?

 

Thanks

[SimWare 834]

What is the simulator and the plane/addon used ?

[michael.woodward 0]

MSFS 2024 (tried SU3 & SU4)

 

Ive tried various planes: 

Textron Beechcraft Bonanza G36

Carenado C182 RGII

Aero Vodochody L-39 Albatros

Airbus A3** Inibuilds

Boeing 737 etc

 

Apparently a fix is on the way.

 

Please login to display this image.

 

 

[SimWare 834]

Yes indeed.

I just had confirmation a light driver is currently worked on.

I will keep you informed and it will then be available from our download section.

[michael.woodward 0]

That's great thanks

[SimWare 834]

Welcome.

[michael.woodward 0]

I see the gear leds are now working!!!!!

 

SIERRA TPM MODULE – Honeycomb Aeronautical Europe

 

 

[SimWare 834]

Indeed.
 

Led driver MSFS2024 : 
https://snakebyte.canto.global/b/H1L7U

 

Led Driver MSFS2020 : 
https://snakebyte.canto.global/b/R3PJB

[SimWare 834]

For info, the Honeycomb Sierra TPM drivers are now available from the product page on our website : 
https://www.aerosoft.com/en/shop/flight/hardware/instruments/4662/honeycomb-sierra-tpm-module

Please login to display this image.

 

[SimWare 834]

And now also from the download section of this forum. (Thanks Tom)

 

[hankybanister 0]

Has anyone addressed the trim wheel not being an axis lever yet..? The product information on honeycomb software website says "high resolution" trim wheel. In fact, it fires button press events at a very inconsistent rate making it very hard to use it in planes with a ... trim wheel. I'm just guessing, but I would say the hardware trim wheel is simply "pinged" by an optical device or a hall sensor. I experience the trim wheel to fire just very few events when turning the wheel very slow and also when turning it very fast. That tells me, that the sampling speed of the wheels rotation is way too slow. Why not building it as an axis with limits? Would've been so easy. Even the mapping from a continuous movement on the axis to an electronic trim system like an a P28 would be feasible imho. I don't get why producing the Sierra TPM with a "high resolution" trim wheel and then make it fire button events... Don't get me wrong. The Sierra TPM is fantastic product, but ouch.... that wheel disappointed me...

 

What're your thoughts? 

[MarkHurst 174]

On 12/6/2025 at 9:50 AM, hankybanister said:

Has anyone addressed the trim wheel not being an axis lever yet..? The product information on honeycomb software website says "high resolution" trim wheel. In fact, it fires button press events at a very inconsistent rate making it very hard to use it in planes with a ... trim wheel. I'm just guessing, but I would say the hardware trim wheel is simply "pinged" by an optical device or a hall sensor. I experience the trim wheel to fire just very few events when turning the wheel very slow and also when turning it very fast. That tells me, that the sampling speed of the wheels rotation is way too slow. Why not building it as an axis with limits? Would've been so easy. Even the mapping from a continuous movement on the axis to an electronic trim system like an a P28 would be feasible imho. I don't get why producing the Sierra TPM with a "high resolution" trim wheel and then make it fire button events... Don't get me wrong. The Sierra TPM is fantastic product, but ouch.... that wheel disappointed me...

 

What're your thoughts? 

 

I don't have this product, so I can only comment in the general case. A major benefit to using a digital encoder for trim is that it is compatible with an autopilot. The autopilot takes over the trim, and if you use an analogue (absolute-positioning) control then obviously it cannot change this unless it is motorised. This means when you switch off the autopilot the aircraft trim will not match the setting of your analogue control. You won't notice this until you touch the trim (although this may be sim-dependent), at which point you may get a violent excursion if the trim is set far from where it was when you engaged the a/p. (This will also be impacted by which vertical autopilot modes you have used in the meantime.)

 

If the Honeycomb device has a driver, it may be that the driver is controlling the pulse rate. If so, I would expect it will also have an acceleration feature, so if you spin it fast you should get faster pulses. You could probably circumvent that by not using the driver, although that may remove other functions (the gear lights being the only obvious one). It ought to just send pulses as button-clicks for two independent buttons, which you could program some other way. In the simplest case you could just multiply up the number of trim events you send from each pulse.

[hankybanister 0]

I'm pretty sure, it doesn't have an acceleration feature. You said I could multiply up the number of events. How?

 

Rotary encoders are fine, I don't have a problem with them as I worked with many of them as an engineer. You could easily map an axis to the encoder and set limits. And the autopilot just does its thing without having to set the hardware. But I admit that this doesn't work when absolute positions on the hardware side are important. Then motors or servos come into play.

 

It gets even worse. When using it in VR, the number of events is even smaller. And a lot smaller If I turn up the resolution in VR. Then the trim wheel in the 172 is barely moving... I'm assuming that the UI and graphics are processed in one thread (or task?). I'm sersiously thinking about building my own trim wheel...

[SimWare 834]

You could emulate a faster trim with some programming.
Measuring the time between two pulses and if the the time is shorter than a certain threshold, increase the trim position by 5 instead of 1 for instance.
This could be maybe achieved with Axis&Ohs addressing the trim Lvar.
But overall, the decision by Honeycomb to make the trim an encoder instead of an axis with limits was for compatibility and ease of use. 

[MarkHurst 174]

4 hours ago, hankybanister said:

You said I could multiply up the number of events. How?

 

To multiply the number of events you'd need to be using a third-party programming tool like SPAD.neXt, or anything that lets you map multiple events or actions to a button click. Then you'd just map two or more 'trim up' or 'trim down' events for each pulse. From memory, I think I have typically programmed five at a time. If you do build your own, have a look at MobiFlight, which is for programming Arduino devices. It is free, almost trivially easy to set up, and it has acceleration features built in for encoders.

[hankybanister 0]

I came across SimTrim. It helps a lot and makes things work a little bit better. It lets you add a multiplier. But it's not smooth like a "continuous" axis.

 

@SimWare, I'm totally fine with an encoder solution. I'm up to building my own trim wheel with a hall type encoder. But the way the Sierra TPM wheel  (barely) works, is just disappointing. Or maybe my TPM is simply not working correctly...  So, without SimTrim, if I turn the wheel up or down the whole range of motion one time at normal speed, it produces between 0 and maybe 2 button events, way too less. Do you experience it differently? So confusing...