bert.laverman

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...

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 delta to 1, which is overdone, but showed me the throttles are now very smooth, until the last bit. Using the Calibration dialog to check values, I see the "In" value going from smoothly from -16383 to 11172, 11200, and then jump to 16384. The corresponding "Out" values were 13779, 13793, and 16384. Bit short on time today, next time I'll see if the Min/Max settings have impact on the "jump", and hunt to see if I can't uncover that calibration data in the registry. Cheers, Bert

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.

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.

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 range. (as shown, -16383 is still there, but the next value is 0) So if those are all DirectInput provided values, then removing the reverser zone (the negative values) has told DirectInput to remap the positive values across the full range of that control. You haven't responded to my question on using Raw? Is that the new standard. (LM's remark on DirectInput being deprecated) Bert

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 input should be used in case of trouble. What do you prefer? Bert PS The definite killer feature of FSUIPC IMHO is the profile mechanism. Would it be possible to introduce e.g. a RegExp matcher rather than explicit titles? That way I can have a profile for "All PMDG 747 QOTSII" or "All Carenado C90"...

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, see them and can process their input. The Honeycomb software also works fine, apart from some things I am in discussion with them about how to program the buttons and LEDs. With respect to the values observed in the FSUIPC UI vs the values returned by the devices: The Windows Controller Calibration has a "Show raw data" option, which reports the values as being 0 to 1023, for all 6 axes. The -16383 to 16384 value ranges only come up in Prepar3D and FSUIPC. I have made a few screen captures of the FSUIPC UI: Image "0-1" shows the initial state, in this case for programming the PMDG 747's 4 engines. I have disabled the reverser zone, because the reversers will be controlled using buttons: Idle reverse by the lever, full reverse by additionally pushing the throttle lever down into the detent setting. Note that all four throttles have min set to -16383, and max to 16384, and the current state is at -16383. Because of the lack of reverser (I assume) the "Out" value shows 0. Image "0-2" shows the state when I move throttle 1 up until the values change. The "In" value has jumped to 0, and "Out" made a jump to 8191. Image "0-3" shows the next step up, with "In" appearing to take steps of about 256, and "Out" now a bit less. Moving further up goes smoothly, although the maximal value appears to be reached slightly before the end of the range. Now from earlier experiments, I know that setting the "Min" value to zero causes quite different behavior: I move the throttle back until "In" shows "0" and click "Set", as shown in image "1-1". Now if I go down to the lowest possible value, "In" again shows -16383 and "Out" again 0. (Image 1-2) Now if I go a smallest possible change up, "In" goes to 0, but "Out" does not change. (image "1-3") Going further up, I now see "In" and "Out" showing the same value, up to and including 16384, again reached slightly before the end of the actual range. Throttle 2 strangely behaves completely different, even without changing the "Min", it takes much smaller steps on "Out" side. I have also included my FSUIPC6.ini and the profile-specific file for the 747. Sincerely, Bert Laverman FSUIPC6.ini PMDG 747.ini

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.

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. The PropPitch and Mixture axes behave similarly, but reversed; the jump is on the upper end of the range, from max to about 75%, then it moves smoothly until the handle on the Bravo is about halfway, at which point the handle in the cockpit is fully down. Now what eventually solved this, but I could not find in the manual, is that I should have set the throttle minimums to 0. Because I cannot enter direct values in the dialog box, I keep moving axes and looking at the values, but the input value behavior actually changes when I set those minimum and maximum values, which is thoroughly confusing as they are "input". This is the Carenado C90 BTW. If you have any hint how I could get the range between Idle and Reverse used, I would be much obliged. I have the reversers now working using the throttle "detent" switches, so full down is Idle and "push through detent" gives me reversers, but even if I use the processed reversers, it skips part of the range. Cheers, Bert

[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. And yes, all my flightsimulator stuff gets installed under "C:\FS". I try to move stuff there that some folks install under "Documents", because executables and DLLs are not documents, and I don't want them ending up in OneDrive of Google Drive. Bert PS Unrelated but out of curiosity: Would you know why there are two "add-ons.cfg" files? One in "ProgramData" and one in "AppData".

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!

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, set both axes to straight to Prepar3D, and used the control configuration there, and that worked without a hitch? Any idea what the cause is for this behavior? I can fly, but not with FSUIPC it seems. I know version 6 is out, but thought that was only needed for Prepar3D v5. Is there something else I missed? Bert Laverman

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 FSUIPC did not see it. After landing I tried some more things and noticed that the calibration tab was working and showed values for the yoke! Could it be that the game-controller status in only the assignment scanner is the culprit? Cheers, Bert Laverman