FSUIPC 5.152 Axis trouble with Honeycomb Bravo

[bert.laverman]

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

[bert.laverman]

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!

Edited December 28, 2020 by bert.laverman

[Pete Dowson]

18 hours ago, bert.laverman said:

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!

Glad you worked it out, but do also please note that those facilities are described in the User Guide, along with lots of other helpful information.

Pete

 

[bert.laverman]

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

Edited December 30, 2020 by bert.laverman

[Pete Dowson]

1 hour ago, bert.laverman said:

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.

I always liked to keep everything in one folder and my installers always broke all the rules to do so.  But John is doing the right thing -- correctly abiding by Microsoft' & L-M  rules.  The program and its configuration stuff in your choice of Installation folder, the necessary activating Addon.xml in  P3D's Add-Ons folder, in your Documents, and the documentation in an appropriate folder also in your Documents.

I suppose there could be links placed to all these when they are installed, but many folks, including myself, don't like getting such a cluttered Start menu or, indeed, desktop. I tend to move or delete such additions.

It really shouldn't be so odd finding documentation in the Documents folder, surely?

BTW apart from the documents installed in the Documents folder, there is a document accompanying the Installer, in the ZIP you download, which provides helpful instructions and does tell you where things go.

Pete

 

[Pete Dowson]

1 hour ago, bert.laverman said:

PS Unrelated but out of curiosity: Would you know why there are two "add-ons.cfg" files? One in "ProgramData" and one in "AppData".

That is L-Ms doing, and I did read the explanation somewhere, but (sorry) I've forgotten the details. I think it's related to addons which will always be loaded ("ProgramData"), compared to those which only load when the appropriate user is logged on (AppData).

If you ask on the AVSIM P3D forum I expect someone will explain this more accurately.

Pete

 

[bert.laverman]

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

[Pete Dowson]

2 hours ago, bert.laverman said:

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

The INPUT value defined is definitely a direct copy of what is being received -- either directly from your Axis assignment when assigned "direct to calibration", or from the Sim otherwise. There is no way FSUIPC's calibration can change that unless it is affecting what does to the Sim and it is the Sim value you are using.

So without knowing anything about how you assigning nor to which controls I can't really advise.

As usual you do need to supply information -- maybe in this case your FSUIPC5.INI file.

But you refer to a particular add-on aircraft. Please always test your controls first on a default aircraft in case the add-on is doing its own odd things.

The other consideration if the whole range of your axis is not being used is a bad install of your control device. The entries in the Registry may be wrong.  It has happened quite frequently with Saitek devices (as an example) that the registry data for the device is limiting the range to only half that available, or even treating the analogue axis as a digital on/off input.

If the latter is a factor, first try calibrating in Windows. If the problem persists then a complete uninstall of the device via Windows device manager (including any drivers), followed by a re-boot so the device gets re-installed afresh, may work.

Pete

 

[bert.laverman]

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 Dowson]

On 1/9/2021 at 5:46 PM, Pete Dowson said:

So without knowing anything about how you assigning nor to which controls I can't really advise.

As usual you do need to supply information -- maybe in this case your FSUIPC5.INI file.

Did you miss the above in my previous reply?

On 1/9/2021 at 7:04 PM, bert.laverman said:

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.

If this is from an assignment in FSUIPC, and the axis is not assigned in the P3D, then this surely indicates a bad registry entry for that device. 

Please re-read my previous reply! You response gave no further usseful information at all.

Pete

 

[bert.laverman]

Pete,

I have been searching for how better to explain this.

Let me begin with these two points:

1. 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.
2. 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:

1. 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.
2. 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.
3. 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:

1. I move the throttle back until "In" shows "0" and click "Set", as shown in image "1-1".
2. Now if I go down to the lowest possible value, "In" again shows -16383 and "Out" again 0. (Image 1-2)
3. Now if I go a smallest possible change up, "In" goes to 0, but "Out" does not change. (image "1-3")
4. 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

[Pete Dowson]

18 minutes ago, bert.laverman said:

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.

Those are the normal maxima for a correctly registered and windows-calibrated joystick axis. They are related to entries in the registry.

The "IN" values shown in Calibration are the actual values received from the DirectInput driver in Windows. They are not interfered with in any way whatsoever by FSUIPC. You can also select, in the assignments tab, a "raw" mode, which causes those DirectInput functions to bypass any registry impose Windows calibration, so allowing the actual USB-received values to be seen in FSUIPC.

You have seen that your throttles are not all behaving in the same way. Does that not suggest to you that something is wrong?

I really strongly suggest that you try uninstalling the device completely, drivers included, via the Windows Device Manager. Unplug it first. Then re-boot the PC and plug it back it and re-check. That should clean up the registry -- unless there are multiple entries, which we would have to tackle separately (that involves some serious logging to identify the entries involved).

Incidentally, the 256 increment change is the "Delta" value set in the assignments tab. You can change it if you which, but, really, 256 is the minimum P3D is likely to ever see as a real change and lowering it just reduces performance as it gets many more inputs than it can deal with and any slight natural jitter in the values can make that worse.

BTW, for PMDG Boeing aircraft most folks have found that FSUIPC calibration is not good. it seems it can cause conflicts, as PMDG code seems to scan devices itself in some cases. Mostly just assigning to the Axis Throttle ... FS controls and not calibrating seems to work best for most folks.

Pete

 

 

[bert.laverman]

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 Dowson]

1 hour ago, bert.laverman said:

even when the axis was set to "Send to FS as normal axis", the "Rev" processing in the FSUIPC Calibration tab was still active.

You evidently still haven't bothered to read the user guide section on Calibration! 

Of course the "Rev" setting takes effect if you have set calibration. Your iNI showed that you have enabled calibration (pressed the left-hand main Set button, but not bothered to actually do the calibration (other than setting "Rev" it seems).  To disable calibration just go to the tab and press the Reset button!

1 hour ago, bert.laverman said:

Is there a standard path in the registry where the interfering values may be found?

It is complex and different for each device. Best not to try editing the Registry unless there's no alternative. We can go through that later if it looks necvessary.

Pete

 

[John Dowson]

4 hours ago, bert.laverman said:

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

But you can do this already with the 'substring' match facility. I guess I could match on regex expressions, but I don't see any benefit in doing this as you can already match on multiple substrings. I think adding regex expression matching would probably be more confusing for most folk.

[bert.laverman]

3 hours ago, Pete Dowson said:

You evidently still haven't bothered to read the user guide section on Calibration! 

Of course the "Rev" setting takes effect if you have set calibration. Your iNI showed that you have enabled calibration (pressed the left-hand main Set button, but not bothered to actually do the calibration (other than setting "Rev" it seems).

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

[John Dowson]

5 hours ago, bert.laverman said:

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?

FSUIPC uses DirecInput. The P3D option for this is used when assigning in P3D, not FSUIPC.

[bert.laverman]

1 hour ago, John Dowson said:

But you can do this already with the 'substring' match facility. I guess I could match on regex expressions, but I don't see any benefit in doing this as you can already match on multiple substrings. I think adding regex expression matching would probably be more confusing for most folk.

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.

[bert.laverman]

6 minutes ago, John Dowson said:

FSUIPC uses DirecInput. The P3D option for this is used when assigning in P3D, not FSUIPC.

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.

[Pete Dowson]

32 minutes ago, bert.laverman said:

I don't see why you said I didn't bother to do calibration.

Because the calibration values are all default. All axes behave a little differently so the values are almost never the same as default values.

34 minutes ago, bert.laverman said:

You say the "In" values (from -16383 to 16384) are the values returned by DirectInput

Only if calibrated in Windows Game Contollers.  They are the values recognised by P3D for minimum and maximum.  The true values DirectInput gets from your device are only seen in Raw mode (selectable in FSUIPC if you really want to).

37 minutes ago, bert.laverman said:

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.

This only applies to throttles, obviously, and DirectInput doesn't change anything, it's the calibration. -16384 or whatever your real minimum value is, is calibrated to 0, and then complete range -16384 to +16383 is calibrated to the forward thrust range of 0-16383. It's part of calibration (please read about it).

27 minutes ago, bert.laverman said:

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.

LM are not Microsoft. If L-M prefer Raw mode that is the way they are programming their assignment system.  RAW mode is a DirectInput option, it is part of the Windows HID device interface system.

In FSUIPC RAW mode is advocated for use when an axis is being used to directly set a value, like a heading to be set using a POV axis.  The Delta is then set to 1 so that every value is used.  Please read the section in the User Guide which explains in some detail the pros and cons and uses.  In my FSUIPC6 user guide this text starts part way down page 36, but easily found by searching for "Raw".

Pete

 

[John Dowson]

52 minutes ago, bert.laverman said:

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.

You may have to add a couple of substrings rather than one regex expression, but I think that is far easier than using regex expressions for the standard user.
If you don't think that is sufficient, please provide me with an example where substring matches won't work for you.

[bert.laverman]

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

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

[John Dowson]

33 minutes ago, bert.laverman said:

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.

Ok. Thanks for the update.