View source

From VaafWiki

You do not have permission to do that, for the following reason:
The action you have requested is limited to users in the group user.
You can view and copy the source of this page:
The way trim works in Black Shark is a great idea but seems to be not that well implemented for non-force feedback controls. Setting trim often results in a "bump" in the controls which can cause problems whilst flying. To get around this problem it is possible to program your CH controllers so that they can be trimmed internally without any "bumps".

To help you along I've included [http://users.bigpond.net.au/ro55/simpit/CHHardwareTrim.zip copies of the blank and final maps from this document]. The CMS code can be cut and pasted from the final map into your own but you'll have to perform the rest of the steps in this document to get it working with a different profile.


This document shows how to port the CMS code into an existing profile step by step.

== Obtaining Initial Hardware Information ==

To start with let's create an empty profile. If supported by the sim I always use separate devices rather than bundling them into one as that allows more axes and buttons. The hardware trim described in this document will work for bundled controls as well.

[[Image:CHTrim_BlankCH.png]]

* From the screenshot we can see that the Fightersick is the first device (JS1), the throttle the second (JS2), and the rudders the third (JS3). It is important to note this order as unfortunately CH do not have unique names for each hardware device in CMS scripting. 

* The FighterStick is the first device, JS1. This is because it is shown in the first tab after "Program Settings". It is also currently in DX mode and is DX device  "CM Device 1" with the yaw and pitch being mapped to the X and Y axes. CH labels the current hardware axis shown in the screenshot as JS1.A1. The Y axis is JS1.A2.

* The throttle is the second device, JS2. We don't need to worry about it as trim is not applied to the collective.

* The ProPedals are device JS3, and the rudder (or antitorque) are the Z axis and is axis A3.

From this information we can edit the following section of the CMS script and set them to our values

 // Change the next 3 entries to your physical devices
 // JS1 is the 1st TAB after "program settings" in the CH manager
 // The axis is the greyed out text above the "dx mode" check box
 // Write down the DX device that each control is assigned to and change it to "DX Device" none
 %DEFINE XIn JS1.A1  //Joystick X
 %DEFINE YIn JS1.A2  //Joystick Y
 %DEFINE RIn JS3.A3  //Rudder

We must also set the DX device of the joystick and rudder axes to "none" in the control manager software.

== Assigning CMS Controls ==
[[Image:CHTrim_CMSAssign.png]]

On the "CMS Controls" page assign A1, A2, and A3 to the DX devices/axes that the hardware was previously set to.
* A1 should be assigned to CM Device 1, X axis
* A2 should be assigned to CM Device 1, Y axis
* A3 should be assigned to CM Device 3, Z axis


== Trim and Shift Buttons ==
[[Image:CHTrim_CHButton.png]]

I'm going to use the lower "thumb hat" forward position as a trim button. As you can see from the screenshot it is button JS1.B13. I've changed it's DX Device to "none" to avoid any conflicts in the profile.

The script uses the shift and trim buttons pressed together for "trim reset". The "shift" button is the only button with the "shift" checkbox ticked. Again it should be assigned a DX Device of "none" to avoid conflicts. 

In this script I've decided to use button 2 on the throttle as my shift. It is JS2.B2

Now you'll need to edit the following section to your values.

 //Trim and shift buttons - Change to your physical devices
 //Also set the trim button to DX Device "none" so that pressing it doesn't do other things as well
 %DEFINE TrimBut JS1.B13
 %DEFINE ShiftBut JS2.B2

== Testing the trim ==
After saving and downloading your profile you need to test the trim function. The easiest way is to select "test/calibrate" in CH Manager and select the device ("Control Manager Device 1" for the Fighterstick). Move the joystick into the desired position and hold trim. Now release pressure on the stick and when it's centered release the trim button. The output on the screen should have stayed constant during this process and is now the new center of the stick. Retrimming should work exactly the same way without any jumping in values.

To reset the trim just press the "shift" and "trim" buttons simultaneously. The output should return to the center.

== CMS Script Listing ==
For anyone who might like to look at the text from the script without using the CH Control Manager (perhaps for the purpose of porting it to a different brand of joysticks?), here's the code from it.


 // CMS Script File
 //
 // Game Title: Black Shark
 // Script (only) Written By: ScatterGun Virtual Australian Airforce, Black Shark Squadron http://www.vaaf.net
 // Date: 24/12/08
 // Warning: As with any script this will not just plug into any profile directly
 // It has to be customised to fit in with a particular profile
 // It works with a trim button that when shifted resets trim
 // The trim button cannot have any other "shifted" usage as it will conflict with it
 
 // To trim the helo, get your controls into the desired position, press and hold the trim button
 // while centering the controls, then release the trim button.
 // To reset trim to neutral hold the shift and trim buttons simultaneously
 
 script
 
 
 // Change the next 3 entries to your physical devices
 // JS1 is the 1st TAB after "program settings" in the CH manager
 // The axis is the greyed out text above the "dx mode" check box
 // Write down the DX device that each control is assigned to and change it to "DX Device" none
 
 %DEFINE XIn JS1.A1  //Joystick X
 %DEFINE YIn JS1.A2  //Joystick Y
 %DEFINE RIn JS4.A3  //Rudder
 
 //Don't change the next few lines
 //Instead, go to the CMS tab and assign CMS.A1, CMS.A2, and CMS.A3 to the DX devices that 
 //your physical controls (from the previous block) were previously mapped to
 
 %DEFINE XOut CMS.A1
 %DEFINE YOut CMS.A2
 %DEFINE ROut CMS.A3
 
 //Trim and shift buttons - Change to your physical devices
 //Also set the trim button to DX Device "none" so that pressing it doesn't do other things as well 
 
 %DEFINE TrimBut JS1.B13
 %DEFINE ShiftBut JS2.B2 
 
 //Internal variables, no need to change these unless you use them in your own scripting
 %DEFINE Trimming B1
 %DEFINE XTrim A1
 %DEFINE YTrim A2
 %DEFINE RTrim A3
 
 //Purely hardware trimming
  IF( NOT Trimming ) THEN     // If not trimming then
    XOut = XIn + XTrim;   //   add the X offset to the stick X value
    YOut = YIn + YTrim;   //   and add the Y offset to the stick Y value
    ROut = RIn + RTrim;
  ENDIF
 
  IF (TrimBut AND ShiftBut) THEN //RESET HARDWARE TRIM
    XTrim=0;
    YTrim=0;
    RTrim=0;
  ENDIF
 
  SEQUENCE
    Trimming = FALSE;
    WAIT( TrimBut AND NOT ShiftBut);         // Wait until Button 13 pressed
    Trimming = TRUE;
    XTrim = Xout - 128;      // Calculate the X offset and save it in A1
    YTrim = Yout - 128;      // Calculate the Y offset and save it in A2
    RTrim = Rout - 128;
    WAIT( NOT TrimBut );
 // You can uncomment the next line if you want the script to check that you've 
 // centred the controls before finishing the trim operation
 //    WHILE( [Xin < 130] AND [Xin > 124] AND  [Yin < 130] AND [Yin > 124] AND  [Rin < 130] AND [Rin > 124] ); 
    Trimming = FALSE; // Apply trim
  ENDSEQUENCE
 
 
 
 endScript

== Scaled Trim (improved version) ==
After I released the script and wrote this page, I was informed that one problem with the simple offset type trimming system employed in the script is a loss of range on the opposite side to the trimmed point ie: if you trim 10 forward and pull the stick fully back it will only go to 245 rather than the full scale of 255. To get around this issue I've written a new set of segmented trimming equations which apply a different multiplier to the upper and lower halves of each scale. [http://users.bigpond.net.au/ro55/simpit/CHHardwareScaledTrim.zip Here] is the new version.

The equations look a bit mysterious but end users don't have to worry about those implementation details. It's just a bit of algebra and scaling.

== Native Trim Profile For Black Shark ==
Thrustmaster Cougar owners have a macro that they use to improve the use of native trim in Black Shark. It holds the joystick postion while the user recenters their controls. As a comparison to the native trim system above, I've done a similar thing for my CH gear. I'm not sure which is really better so I've put it here for people to try both and see which they prefer. [http://users.bigpond.net.au/ro55/simpit/CHBlackSharkNativeTrim.zip Here] is the (improved) native trimming version.


You should note that in this profile the trim button should not be "de-assigned". It should be mapped to the trim key "t" as per a "normal" profile.

Even with the hold (and no bumps in the CH manager test screen) you still see a bump in the Black Shark Controls when it applies trim. It looks as if Black Shark is applying a 2nd order filter to the user inputs which causes some overshoot.


== Improvements needed for CH scripting ==

I'm not sure how many people do scripting with their CH gear (this was pretty much my first go at it). When writing these scripts and helping people to port them to their own profiles I realised that it'd be nice to have some changes in the CH Control Manager.

* Deadzone should be able to be applied to physical device axes, not just DX output axes. This is a huge issue as controller backlash needs to be handled at the source. An added benefit is that it could make scripts shorter as the writer doesn't have to write extra code to create the effect of deadzones. '''Note: According to the docs you should be able to do this in the script - unfortunately the SCALE function doesn't seem to work for devices like JS1.A1 when they are not directly mapped to an output.'''

* Each CH device needs it's own unique name for scripting. At the moment the JS1, JS2, etc. order is based upon the order you click on them when making a profile. Having unique names (just as you do for buttons within a device) would aid script portability.

* It'd be nice to be able to access DX devices and emit macros without having to go through intermediate CMS controls. In other words it'd be nice for the scripting system to be a total solution rather than something tacked on to the back end of a map.

* Since CMS uses only integer values, nonlinear functions like "ABS", "SIGN", "FLOOR, "CEIL" and "MOD" etc. are really necessary. Getting around their absence makes code longer and unwieldy.

== Scatter's Black Shark Profile ==

I know what you're all thinking at this point. Hey, this Scatter's a cool dude and I want to be just like him. Well that may not be possible but you can fly Black Shark with the same profile. Here is the page with [[Black Shark CH Profile Scatter|Scatter's Black Shark CH Profile]]. If you use this as a starting point you don't have to worry about all of the steps listed above.

By the way, if you want to meet me and have a good laugh at my flying skills in the Black Shark you can always [http://www.vaaf.net/forum/index.php sign up for the Virtual Australian Airforce]. It's free and we're always happy to have new members. Once you see me in action you'll realise that lack of skill is no impediment to joining in.
Return to CH HOTAS hardware trim.
Retrieved from "http://vaaf.net/wiki2/index.php5?title=CH_HOTAS_hardware_trim"
View source

From VaafWiki

Views

Personal tools

Wiki

VAAF

Search

Toolbox
