Jump to content
The simFlight Network Forums

Primary flight controls via FSUIPC and their sensitivity..


Recommended Posts

Hi Pete! :)

Been a while, but I've been building my own flight controls and setup.. My setup uses the IOCards hardware from opencockpits.com - basically, the potentiometers are connected to the hardware board, and with the software, I send the values directly to FSUIPC addresses. This is not a joystick from windows' perspective. Stuff gets written to FSUIPC directly. Like, aileron and elevator potentiometer values is mapped to BB6 and BB8 etc.

But turns out I have a problem now: The controlling works right. But it is a lot like when you set "sensitivity" to very low in FS in the joystick options. I can see from the iocards monitoring software that both fsuipc variables seem to move the full range (-16383 to 16383) - but the control surfaces in FS do not move much. Thus control sensitivity is very low.

I'd change the sensitivity - but there is no way to do it as far as I know. Also I cannot use fsuipc's axis curves etc, since this is not a joystick.

Do you know any solution to this? It seems like the axis'es do not move the controls to full deflection, but rather default to some "low sensitivity" mode?

I might need to use a usb joystick interface for the primary flight controls, and do the throttles etc via iocards, since those do not have this problem. But it would be interesting to know what causes this problem, and have others faced the same thing? When one writes 16383 to the offset, shouldnt the flight control surface get a full deflection or not, or am I missing something here?

Best,

//Tuomas

Link to comment
Share on other sites

I send the values directly to FSUIPC addresses. This is not a joystick from windows' perspective. Stuff gets written to FSUIPC directly. Like, aileron and elevator potentiometer values is mapped to BB6 and BB8 etc.

BB6 and BB2, you mean I hope?

But turns out I have a problem now: The controlling works right. But it is a lot like when you set "sensitivity" to very low in FS in the joystick options. I can see from the iocards monitoring software that both fsuipc variables seem to move the full range (-16383 to 16383) - but the control surfaces in FS do not move much. Thus control sensitivity is very low.

I assume this is with FS2004?

I cannot see how that is possible, as, since FS2002, the only way FSUIPC has of effecting those controls is by sending the values directly as parameters to KEY events such as KEY_AILERON_SET, whch are the same as would result from a normal joystick input, after FS's calibrations sensitivities and null zones.

When one writes 16383 to the offset, shouldnt the flight control surface get a full deflection or not, or am I missing something here?

I get a full deflection here, fine. I don't know what you are doing wrong, but have you checked with FSInterrogate, or even used logging in FSUIPC to see? Check in any case with a default aircraft -- some of the more sophisticated ones do intercept some of these controls for "fly-by-wire".

The Axis logging in FSUIPC won't log these by default, since the method used to send the controls by-passes it, but if you get the latest Beta (see top of Forum) you can force FSUIPC to log your axis changes too by changing the FSUIPC.INI file as follows:

Add to the [General] section

Debug=Please

Then, after loading FS, go to FSUIPC's logging page and set Axis event logging on, and "Extras" to the value 16.

Always compare what you are doing with what can be done simply in FSInterrogate, and also just using the keyboard Num keys to raise/lower elevators and so on.

Regards,

Pete

Link to comment
Share on other sites

Hi again Tuomas,

One thing I should warn you about since you are wirting direct to the control offsets. Aircraft panels with their own A/P and A/T such as PMDG and PSS, and external autopilots such as the Project Magenta one, will not work too well with such a system unless you take steps in your code.

For throttles, in the Beta FSUIPC I provide a facility for an alternative set of offsets:

There are now throttle controls at 089A, 0932, 09CA and 0A62 (for Engines 1-4). These are the same as the originals (at 088C, 0924, 09BC and 0A54) except that they are switchable via offset 310A/310B like joystick inputs, and have their values readable (even when disconnected) at 3330-3336, like the separate axis controls do.

You'd be best off using these for throttle control so that the AutoThrottle action can still override as needed.

For the main control surfaces when the A/P is engaged you may need to simply not move your controls (and trust they are stable) -- in a real airliner I believe sufficient control movement disconnects the A/P in any case, so perhaps that's what you'd need to do too.

Regards,

Pete

Link to comment
Share on other sites

BB6 and BB2, you mean I hope?

Ah yes. My typo.

I assume this is with FS2004?

I cannot see how that is possible, as, since FS2002, the only way FSUIPC has of effecting those controls is by sending the values directly as parameters to KEY events such as KEY_AILERON_SET, whch are the same as would result from a normal joystick input, after FS's calibrations sensitivities and null zones.

Yes. FS2004.

I get a full deflection here, fine. I don't know what you are doing wrong, but have you checked with FSInterrogate, or even used logging in FSUIPC to see? Check in any case with a default aircraft -- some of the more sophisticated ones do intercept some of these controls for "fly-by-wire".

I think I know. I *dont have any joysticks* so there are no FS's calibrations, sensitivities or null zones defined at all. So there's nothing happening *before* setting the value. I'd probably need to have a dummy joystick in place to get those? But since my control stick is not a joystick at all, as far as windows is concerned, I cannot set the null zones to it.

I wonder if the only possibility is to look into fs9.cfg to see if that has some default sensitivity settings, and if not, then just swap my controls so that the primary controls go via the joystick card, and the throttles go via the iocards master card. It's easy to do and not a hassle, but this case was pretty interesting.

I wonder how many add-on planes break if you remove joysticks btw?

The Axis logging in FSUIPC won't log these by default, since the method used to send the controls by-passes it, but if you get the latest Beta (see top of Forum) you can force FSUIPC to log your axis changes too by changing the FSUIPC.INI file as follows:

Add to the [General] section

Debug=Please

Then, after loading FS, go to FSUIPC's logging page and set Axis event logging on, and "Extras" to the value 16.

Always compare what you are doing with what can be done simply in FSInterrogate, and also just using the keyboard Num keys to raise/lower elevators and so on.

Keyboard controlling works okay though, which is strange. I'll try logging tomorrow. How does the PFC flight console work btw, does it also put all data through something else than the joystick interface, even the yoke? Would it have the same problem if you remove your real joysticks?

Hi again Tuomas,

One thing I should warn you about since you are wirting direct to the control offsets. Aircraft panels with their own A/P and A/T such as PMDG and PSS, and external autopilots such as the Project Magenta one, will not work too well with such a system unless you take steps in your code.

No worries, no such nintendos my cockpit ;)

There are now throttle controls at 089A, 0932, 09CA and 0A62 (for Engines 1-4). These are the same as the originals (at 088C, 0924, 09BC and 0A54) except that they are switchable via offset 310A/310B like joystick inputs, and have their values readable (even when disconnected) at 3330-3336, like the separate axis controls do.

You'd be best off using these for throttle control so that the AutoThrottle action can still override as needed.

Interesting. This should be useful for my friends who are building an autothrottle also at some point for their setup.

For the main control surfaces when the A/P is engaged you may need to simply not move your controls (and trust they are stable) -- in a real airliner I believe sufficient control movement disconnects the A/P in any case, so perhaps that's what you'd need to do too.

Yep. This is pretty interesting stuff (and one could do this easily with the SIOC programming language of iocards (it's pretty wacky language with number-named variables and other fun quirks, but it's pretty awesome tool for making logic like that on a home simulator.. :)

My setup is a light twin though, I havent decided whether I want an autopilot yet.

//Tuomas

Link to comment
Share on other sites

I think I know. I *dont have any joysticks* so there are no FS's calibrations, sensitivities or null zones defined at all. So there's nothing happening *before* setting the value. I'd probably need to have a dummy joystick in place to get those? But since my control stick is not a joystick at all, as far as windows is concerned, I cannot set the null zones to it.

The sensitivities and null zones are ONLY applicable to true joystick inputs. You most certainly do not need real joysticks or dummy ones. The controls are what happens AFTER all that stuffas I thought I explained?

Keyboard controlling works okay though, which is strange. I'll try logging tomorrow. How does the PFC flight console work btw, does it also put all data through something else than the joystick interface, even the yoke? Would it have the same problem if you remove your real joysticks?

It uses pretty much the same system you are using. There is certainly no problem on a system which has no joysticks -- in fact most all PFC installed systems have no Windows type joysticks and never have had any.

I repeat, there is no need to have any real joysticks, and never has been. You do not need them or dummy ones. Something else is going wrong, you need to check your system as I suggested. There are plenty of tools provided for you to check!

Pete

Link to comment
Share on other sites

I repeat, there is no need to have any real joysticks, and never has been. You do not need them or dummy ones. Something else is going wrong, you need to check your system as I suggested. There are plenty of tools provided for you to check!

Pete

Okay, this is good to know. The log shows stuff like:

(numbers, timestamp I guess) Elevator input=NNNN1 calibrated to NNNN2

And NNNN1 is roughly twice the calibrated value, so this is definitely my problem. But does this mean the calibration comes from FSUIPC (I have disabled the axis calibration stuff) or does it come from FS itself?

Update: Solved - So, I had a bunch of the joystick sections on my FS9.cfg - things like "aileron_something=127" (I have this on the other computer, so I dont remember it exactly) - but since I dont have joysticks right now, I just cut those out, saved the config without them and started FS again. And it appears to be solved. So some calibration was still haunting me from there, even though the corresponding joystick never was plugged in.. Go figure.

Anyway, it's good to know this kind of thing can cause problems. Thanks for the hints, Pete, and good night! :)

//Tuomas

Link to comment
Share on other sites

Okay, this is good to know. The log shows stuff like:

(numbers, timestamp I guess) Elevator input=NNNN1 calibrated to NNNN2

And NNNN1 is roughly twice the calibrated value, so this is definitely my problem. But does this mean the calibration comes from FSUIPC (I have disabled the axis calibration stuff) or does it come from FS itself?

Erthe log entries you *should* be getting with that option look like this:

   229125 ***  AXIS: Cntrl= 65762 (0x000100e2), Param= -16383 (0xffffc001) AXIS_ELEVATOR_SET
   234765 ***  AXIS: Cntrl= 65762 (0x000100e2), Param= 16383 (0x00003fff) AXIS_ELEVATOR_SET
   253812 ***  AXIS: Cntrl= 65763 (0x000100e3), Param= -16383 (0xffffc001) AXIS_AILERONS_SET
   298906 ***  AXIS: Cntrl= 65763 (0x000100e3), Param= -16383 (0xffffc001) AXIS_AILERONS_SET
   303656 ***  AXIS: Cntrl= 65763 (0x000100e3), Param= 16383 (0x00003fff) AXIS_AILERONS_SET

The calibration messages come from an entirely different option, originally put into FSUIPC for Aerosoft (Australia) for their GA-28R Piper Arrow III cockpit (of which I have one of the only five made, I think)! ;-)

Check your FSUIPC.INI file. There's a parameter "AxisCalibration=No" -- it sounds like you must have that set to "Yes"! The calibration is done when you have this as "Set". This enables automatic calibration to occur when FS is first loaded by moving all the controls to each extreme. This is how it is done for the GA-28R (I think some others do too). A section in the INI is generated called [AxisCalibration] and the values placed there.

I don't know how or why you have that parameter set, but if you don't want to use the facility (and it certainly sounds like you don't, delete the section and change the parameter back to "No".

Update: Solved - So, I had a bunch of the joystick sections on my FS9.cfg - things like "aileron_something=127" (I have this on the other computer, so I dont remember it exactly) - but since I dont have joysticks right now, I just cut those out, saved the config without them and started FS again. And it appears to be solved. So some calibration was still haunting me from there, even though the corresponding joystick never was plugged in.. Go figure.

HmmmI'm not sure about any of that. Those "something's" were probably "SCALE" and represent the sensitivity slider positions in FS -- but I can assure you, those do not affect stuff written directly. I have tested that conclusively by setting all sensitivities to zero and all null zones to max, which should well and truly clobber all the axis inputs, but it has no effect whatsoever on these direct inputs.

Regards,

Pete

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.