Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About bert.laverman

  • Rank

Profile Information

  • Gender
  • Location
    Almere, Netherlands

Recent Profile Visitors

266 profile views
  1. Eventually I contacted Honeycomb, which sent me through to Aerosoft (I live in the Netherlands and Aerosoft does support in Europe), which authorized an RMA... and confirmed my findings. I have a new one now that has the whole range working. Please note there appears to be a "Konami code" like recalibration mode in the Alpha, but it was never added to the Bravo. Ah well...
  2. Ok, disconnecting, rebooting, and reconnecting did not help. However, calibrating in the Control panel widget did restore some sanity. At least all axes are now again showing their full range of values. The raw data shown in the Windows calibration indicates that the Honeycomb Bravo is indeed using a 1024 value range. What is kind of annoying is that the "Let go of your controller so it returns to the center" will naturally not work for a Throttle Quadrant, but the impact of not having it exact in the center may be what has been causing the weird ranges. As an experiment I also set the de
  3. Ok, but FSUIPC can do Raw as well. My point is that LM is stating that DirectInput is deprecated, so not further developed by Microsoft. That could indicate that the alternative, Raw input, is the safer path towards the future.
  4. John, the manual itself states that this may not be as satisfactory as it should be. Name matching on "Yes" will match starts, while "substring" searches for a part, but e.g. the PMDG aircraft would require a combination of that due to their naming standard.
  5. Nope, I did. I don't see why you said I didn't bother to do calibration. My screenshots are all about that and how that didn't work out due to the strange data coming through. Min and Max can only be set by moving the controls to the values you want to set, and my major issue has been the strange way the "In" value progresses through values. Next time I do tests I will have tried the registry reset and see what that does. You say the "In" values (from -16383 to 16384) are the values returned by DirectInput, but selecting "No reverser zone" removes all but a single step from the negative r
  6. Yesterday evening I flew a sessions using a different profile, and found that, even when the axis was set to "Send to FS as normal axis", the "Rev" processing in the FSUIPC Calibration tab was still active. I'll try the registry reset by rebooting without having the controls connected. Is there a standard path in the registry where the interfering values may be found? Does the "Remove Calibration" button in Prepar3D have anything to do with this, or is that only about the XML files it makes? The Prepar3D site actually states that DirectInput is (supposed to be) deprecated, and Raw in
  7. Pete, I have been searching for how better to explain this. Let me begin with these two points: Yes, I read all your replies. If I appear to not respond how you expect, then most likely one of us misunderstood the other. I am an experienced software developer, but will readily admit to have limited experience with Windows device drivers and their behavior. I do have experience interfacing with SimConnect using C++, but little to no Lua. I cannot find "bad registry entries" for both my Honeycomb devices. They work perfectly and Prepar3D, X-Plane 11, as well as MSFS 2020, s
  8. The values in the "In" field for when the handle is in max and min are 16384 and -16383, but one "step" up from -16383 is 0; the whole negative range in the "In" value is gone. For the Mixture and PropPitch there are values between 0 and -16383. If I re-enable reverser, there are values in between, but at the same time the step-size (minimal change in value for a given amount of movement) in "In" values actually changes depending on where I set the mid-point or "Idle" point.
  9. Pete, I was thoroughly confused by this behavior, that messed up my axes: I disabled the reverser area, used "Set" to enable processing, and enabled "Rev" because the Bravo Throttle sends reversed axes. For both throttles I used the "Set" buttons so Max is 16384 and Min is -16383. I know I could add a bit of "dead zone" at the ends, but this just ensures I get the whole range. If I slowly move a throttle from max down to min, in the cockpit I see it move very slowly down to about halfway between max and Idle, then on the last few millimeters on the Bravo it jumps to Idle
  10. [EDITED] Yes, I know an RTFM feels appropriate, but in my defense, the documentation was uninstalled when the installer removed FSUIPC5, and I don't see it in the FSUIPC6 installation directory. I Googled, but could not find online versions of the manual. I checked the installation in "C:\FS\FSUIPC" and the (dummy) in "<profile>\Documents\Prepar3D v4 Add-ons\FSUIPC6", but then found an extra directory in "<profile>\Documents\FSUIPC6". Please don't create so many folders in separate locations, or at the least create an entry in the Start menu with a link to the documentation.
  11. Ok, I think I see what is happening here. Important point: The Bravo Throttle Quadrant has its axes reversed, so you have to do processing on it. In Prepar3D this is just adding the "Reverse" checkmark, but in FSUIPC it means you must use the calibration tab and click "Set" and "Rev". However, this also enables processing that divides the range into "Normal", "Idle", and "Reverse", which is not what you want if you use the Bravo. In the top-left of this tab there is a check-box for "No reverse zone". That fixes it!
  12. Having received my new Bravo Throttles, I started testing it with the axes registered in FSUIPC. Prepar3D 4.5 BTW. I noticed The values registered were kind of "chunked" and not consistent. If I define the throttles for a King Air C90, using the same procedure as for the Saitek Throttle Quadrants, I noticed in Prepar3D the throttles moved only for a part of the range, no matter how I set the three values in the Calibration page. For the PMDG 737 NGXu things were even stranger, where the Throttles wouldn't have any effect at all, other than moving the reversers? Next I removed the assignment, s
  13. Yesterday I lost control of my yoke. I'll admit the basic problem here is the yoke, but what happened after that is relevant. I unplugged and then re-plugged the yoke, which is my only known fix until I buy a new yoke (I guess), but although FSX accepted this treatment, FSUIPC didn't. I have the axes configured through FSUIPC and that didn't return to normal. Then I entered the "Axis assignment" tab and saw the same: FSUIPC did not respond to the yoke anymore. I also lost the button assignments. Luckily I managed to re-configure FSX to pick up the yoke, so I could finish the flight, but FS
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.