Jump to content
The simFlight Network Forums

Joystick Calibration In/Out with Slopes to Limit Axes Effectiveness


Recommended Posts

I've calibrated my brakes to provide only 80% effort at full "press" to avoid wheel lockups. I did this by tweaking the INI file to include a larger MAX for the axes than what the joystick (Saitek Rudders) actually provides.

This works as expected with a linear slope (MIN=-16384 MAX=24576): -16384 IN provides -16384 OUT, 16384 IN provides about 9800 OUT.

If I change the slope, it obviously changes the OUT value at full press. So what I did was to empirically recalculate the MAX to still get an OUT value of 9800 or less.

With a slope of 4 and a MAX of 22528, 16384 IN provides about 8100 OUT. However, this OUT value locks up the brakes.

So the question is, what does OUT represent? Is OUT the axes "value" that is sent to FSX or something else? How can I determine what is being sent to FSX by FSUIPC?

If an OUT value of 9800 with a linear slope does not lock the brakes, shouldn't an OUT value of 9800 or less also not lock the brakes with a different slope?

I'd like to calculate exactly what MAX should be with a slope of 4, to get 80% effort sent o FSX when the axes is fully "pressed". When this was linear, it was easy.

With a slope, I assumed I could do it empirically, but the OUT value doesn't seem to represent what I thought it did, and since I'm not sure what the formula is for the slope, it's hard to calculate exactly the MAX value for 80% effort.

Can you shed some light on this?

Edited by pilotjohn
Link to comment
Share on other sites

If I change the slope, it obviously changes the OUT value at full press.

No, it certainly shouldn't have that effect. The slopes still calibrate between the minumum and maximum possibly FS values, but just distribute the intermediate values differently -- flatter centre, steeper sides, or vice versa. Obviously if you change the slope after editing the values you'll undo those edits.

So the question is, what does OUT represent? Is OUT the axes "value" that is sent to FSX or something else? How can I determine what is being sent to FSX by FSUIPC?

The OUT value is what is being sent to FS. You can see exactly what gets sent by using the AXIS logging, which logs the actual controls being sent.

If an OUT value of 9800 with a linear slope does not lock the brakes, shouldn't an OUT value of 9800 or less also not lock the brakes with a different slope?

I've no idea how FS decides to lock brakes, but for realism I would have thought it would be related to the ground speed and therefore how fast the value changes in any case. A sudden hard application is surely more likely to lock than a steadier one to the same level? A strong but steady increase should not lock them -- it's must relate to the speed decrease as well as the surface friction? So what you are probably seeing with a steeper end slope is a higher application at higher speeds.

To prevent brakes locking surely you press steadily, not suddenly, or "feather" them (press/release/press/release, gradually increasing the press time over the release time) -- as in car driving in wet weather. I don't think reducing the brake effectiveness is a realistic or desirable approach.

I'm not sure what the formula is for the slope,

There's no formula. The range from minimum to maximum is divided into 128 points, as plotted on the small graph you see on screen, and the actual values are linearly computed between them. It's too inefficient using complex algebra -- tables are used and the same tables plot the curve you see.

Try and relate your brake pressure to the ground speed and not a specific pressure value. I think it must be the faster (ie earlier) application which is confusing you. Also make sure you have the FS "stick sensitivity mode" set correctly -- see the advice on the in the FSUIPC user guide.

Regards

Pete

Link to comment
Share on other sites

No, it certainly shouldn't have that effect. The slopes still calibrate between the minumum and maximum possibly FS values, but just distribute the intermediate values differently -- flatter centre, steeper sides, or vice versa. Obviously if you change the slope after editing the values you'll undo those edits.

I can see how a joystick input of 16384 with FSUIPC MAX set at say 24576, the OUT value without a slope would be different than an OUT value with a slope, since now the IN value looks like an intermediate point and not MIN or MAX. So, this, I think is correct. For example with MAX set at 21502, an IN of 16384 outputs about 11700 without a slope, and 5100 with a slope of 15.

The OUT value is what is being sent to FS. You can see exactly what gets sent by using the AXIS logging, which logs the actual controls being sent.

I've no idea how FS decides to lock brakes, but for realism I would have thought it would be related to the ground speed and therefore how fast the value changes in any case. A sudden hard application is surely more likely to lock than a steadier one to the same level? A strong but steady increase should not lock them -- it's must relate to the speed decrease as well as the surface friction? So what you are probably seeing with a steeper end slope is a higher application at higher speeds.

To prevent brakes locking surely you press steadily, not suddenly, or "feather" them (press/release/press/release, gradually increasing the press time over the release time) -- as in car driving in wet weather. I don't think reducing the brake effectiveness is a realistic or desirable approach.

Well, it seems FSX's brake locking (or at least brake locking animation) is rather crude. It has no relation to ground speed or rate of application. Whether I apply at just before Vr, or at a slow taxi speed, and whether I apply fast or slow, the brakes lock at the same time. So I am puzzled why the slope is not having an affect.

There's no formula. The range from minimum to maximum is divided into 128 points, as plotted on the small graph you see on screen, and the actual values are linearly computed between them. It's too inefficient using complex algebra -- tables are used and the same tables plot the curve you see.

Try and relate your brake pressure to the ground speed and not a specific pressure value. I think it must be the faster (ie earlier) application which is confusing you. Also make sure you have the FS "stick sensitivity mode" set correctly -- see the advice on the in the FSUIPC user guide.

Well this is interesting... it doesn't seem like the SLOPE has an affect on the OUT according to the logs. So I have the MAX set to 21502 which results in a linear OUT of about 11700 at full press, and locked brakes. Regardless of what I set the slope to I get locked brakes. At a SLOPE of 15, the full press OUT that is shown is around 5100 but I still experience locked brakes. I turned logging on, I press the brakes fully to lock, and the last thing I see in the log file are these two lines (slope of 15 while the UI shows out of 5100):

1065518 *** AXIS: Cntrl= 66387 (0x00010353), Param= 11631 (0x00002d6f) AXIS_LEFT_BRAKE_SET

1065518 *** AXIS: Cntrl= 66388 (0x00010354), Param= 11631 (0x00002d6f) AXIS_RIGHT_BRAKE_SET

When I release the brakes, I get:

719539 *** AXIS: Cntrl= 66388 (0x00010354), Param= -16384 (0xffffc000) AXIS_RIGHT_BRAKE_SET

719602 *** AXIS: Cntrl= 66387 (0x00010353), Param= -16384 (0xffffc000) AXIS_LEFT_BRAKE_SET

On a separate unrelated question, what does the "512" or other number represent below the center set value to the left of the slope button in other axes?

Link to comment
Share on other sites

I can see how a joystick input of 16384 with FSUIPC MAX set at say 24576, the OUT value without a slope would be different than an OUT value with a slope, since now the IN value looks like an intermediate point and not MIN or MAX.

Oh, yes, of course. Sorry.

Well, it seems FSX's brake locking (or at least brake locking animation) is rather crude. It has no relation to ground speed or rate of application. Whether I apply at just before Vr, or at a slow taxi speed, and whether I apply fast or slow, the brakes lock at the same time. So I am puzzled why the slope is not having an affect.

The only thing FS will see is the final "OUT" value, as you can see if you do the logging. But if you don't have the correct stick sensitivity mode set, I think it does something extra based on the timings of incoming values.

Well this is interesting... it doesn't seem like the SLOPE has an affect on the OUT according to the logs. So I have the MAX set to 21502 which results in a linear OUT of about 11700 at full press

Depends on the slope. You can see in the graph the changes it makes. But possibly in the part of the graph that "max input" point reaches it is approximating the linear point too?

On a separate unrelated question, what does the "512" or other number represent below the center set value to the left of the slope button in other axes?

Do you mean the pair of centre values, allowing a null central zone on axes like elevators, ailerons and rudders? They set the range over which 0 (centre) is sent. A centaral dead zone is used to prevent slight jitter or accidental movement affecting those controls.

On throttles it defines the idle area in the 4 throttles calibration when a reverse zone is calibrated.

It doesn't apply to brakes.

Pete

Link to comment
Share on other sites

Depends on the slope. You can see in the graph the changes it makes. But possibly in the part of the graph that "max input" point reaches it is approximating the linear point too?

No, it's not the coincident point.

So I have MIN at -16384, MAX at 21502, SLOPE at 15. At these settings, an IN value at 16384 (fully depressed brakes) provide an OUT value of about 5100 according to the GUI.

However, the logs show that it's sending a param value of around 11700, which would be the OUT value if the SLOPE were 0.

It seems like the GUI is showing the correct value (5100) but the incorrect value (no slope) is being sent to FS. Is there any other way to verify this?

1. I set MIN/MAX/SLOPE as above. I fully depress the brakes, and see an OUT of around 5100 in the GUI.

2. I return to FSX, fully depress the brakes, switch to the modules directory open FSUIPC.log and see the last two lines showing around 11700 as params being sent.

3. I return to FSUIPC, set brakes SLOPE to 0, full depress brakes, and see an OUT of around 11700.

So during condition 1/2, the GUI is showing 5100 OUT but the logs are showing 11700 being sent. I'm not sure if this is a bug, or if I'm missing something somewhere...

Do you mean the pair of centre values, allowing a null central zone on axes like elevators, ailerons and rudders? They set the range over which 0 (centre) is sent. A centaral dead zone is used to prevent slight jitter or accidental movement affecting those controls.

And on this separate note, is there a way to change this "null" central zone?

Link to comment
Share on other sites

It seems like the GUI is showing the correct value (5100) but the incorrect value (no slope) is being sent to FS. Is there any other way to verify this?

Hmm .Strange. I'll do some tests here -- but it'll be tomorrow.

First, though, can you tell me exactly which version of FSUIPC you are using (the version number). And check whether the one in the download Links subforum is later. If so, please update first and test again, just in case. I don't want to spend time testing it if it is something already fixed.

And on this separate note, is there a way to change this "null" central zone?

You can set it where you like along your axis. That's the point. Or am I misunderstanding you?

Pete

Link to comment
Share on other sites

Hmm .Strange. I'll do some tests here -- but it'll be tomorrow.

First, though, can you tell me exactly which version of FSUIPC you are using (the version number). And check whether the one in the download Links subforum is later. If so, please update first and test again, just in case. I don't want to spend time testing it if it is something already fixed.

You can set it where you like along your axis. That's the point. Or am I misunderstanding you?

Pete

It's 4.703. But, I just installed 4.708 and it has the same behavior.

I figured out the center settings... one other question, what are the /8 or /40 after the calibration settings?

Link to comment
Share on other sites

Hmm .Strange. I'll do some tests here -- but it'll be tomorrow.

Seems that slopes have NEVER been applied to the brakes axes. Same in FSUIPC3. Probably no one ever thought of using them on brakes.

Fixed in FSUIPC 3.997 and 4.709, now available in the Download Links subforum.

Pete

Link to comment
Share on other sites

Just tested... reads 4.709 in GUI, shows correct value in GUI (9744 OUT for 16384 IN with 20480 MAX and 4 SLOPE) but it's still sending the unsloped value according to the logs (param = 12136).

Not acording to my logs, nor monitoring the brake offset to see how much it is operating. This is with assignment to the FS brake axis control, and it is working perfectly correctly.

Maybe it is related also to how you are assigning the brakes? I don't think you ever told me that? Are you using FSX assignments, or FSUIPC to FS control (and which ones?) , or FSUIPC direct to FSUIPC calibration?

I won't have time to re-investigate for a few days now. but more information is obviously needed!

Regards

Pete

Link to comment
Share on other sites

Not acording to my logs, nor monitoring the brake offset to see how much it is operating. This is with assignment to the FS brake axis control, and it is working perfectly correctly.

Maybe it is related also to how you are assigning the brakes? I don't think you ever told me that? Are you using FSX assignments, or FSUIPC to FS control (and which ones?) , or FSUIPC direct to FSUIPC calibration?

I won't have time to re-investigate for a few days now. but more information is obviously needed!

Regards

Pete

Brakes axes are assigned in FS, not direct control by FSUIPC... Here are the settings:

LeftBrake=-16193,20480/8

RightBrake=-16193,20480/8

SlopeLeftBrake=4

SlopeRightBrake=4

When the brakes on my Saitek rudder are fully depressed, the GUI shows the attached screenshots, and the log shows:

********* FSUIPC4, Version 4.709 by Pete Dowson *********

User Name=...

User Addr=...

FSUIPC4 Key is provided

WIDEFS7 not user registered, or expired

[Continuation log requested by user]

Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07)

Module base=61000000

Wind smoothing fix is fully installed

318383 System time = 21/06/2011 14:28:41, Simulator time = 08:30:45 (15:30Z)

318383 LogOptions changed, now 10000000 00000001

320629 *** AXIS: Cntrl= 66388 (0x00010354), Param= -12637 (0xffffcea3) AXIS_RIGHT_BRAKE_SET

320629 *** TOE BRAKE AXIS, Right set = 10

320660 *** AXIS: Cntrl= 66388 (0x00010354), Param= -14745 (0xffffc667) AXIS_RIGHT_BRAKE_SET

320660 *** AXIS: Cntrl= 66387 (0x00010353), Param= -14923 (0xffffc5b5) AXIS_LEFT_BRAKE_SET

320660 *** TOE BRAKE AXIS, Left set = 4

320660 *** TOE BRAKE AXIS, Right set = 23

320692 *** TOE BRAKE AXIS, Left set = 20

320692 *** TOE BRAKE AXIS, Right set = 45

320723 *** AXIS: Cntrl= 66387 (0x00010353), Param= -13107 (0xffffcccd) AXIS_LEFT_BRAKE_SET

320723 *** AXIS: Cntrl= 66388 (0x00010354), Param= -9011 (0xffffdccd) AXIS_RIGHT_BRAKE_SET

320723 *** TOE BRAKE AXIS, Left set = 48

320723 *** TOE BRAKE AXIS, Right set = 81

320754 *** TOE BRAKE AXIS, Left set = 86

320754 *** TOE BRAKE AXIS, Right set = 155

320785 *** AXIS: Cntrl= 66387 (0x00010353), Param= -2294 (0xfffff70a) AXIS_LEFT_BRAKE_SET

320785 *** AXIS: Cntrl= 66388 (0x00010354), Param= 9010 (0x00002332) AXIS_RIGHT_BRAKE_SET

320801 *** TOE BRAKE AXIS, Left set = 155

320801 *** Both toe brakes over threshold: FS BRAKES control sent

320801 *** TOE BRAKE AXIS, Right set = 176

320832 *** TOE BRAKE AXIS, Left set = 176

320863 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET

320863 *** AXIS: Cntrl= 66388 (0x00010354), Param= 12451 (0x000030a3) AXIS_RIGHT_BRAKE_SET

post-21350-0-39939200-1308681180_thumb.j

Link to comment
Share on other sites

Brakes axes are assigned in FS, not direct control by FSUIPC... Here are the settings:

You are using Filtering? That takes several sequential readings and uses a computed smoothed value. It will be counteracting any changes is slope to a certain extent, and it will certainly make it impossible to compare "OUT" vlaues displayed in the calibration tab (which obviously cannot be smoothed) with real resulting values sent to FS.

Filtering is generally a bad idea -- it was originally added for a gentleman in Malaysia who's PC's power supply was so bad that filtering was the only answer to any sort of control. Generally, it isn't needed for any recent devices unless you are is a very variable environment (temperature and humidity-wise) or have very worn or dirty controls.

[LATER]

Just doing some experiments, I get the same sort of results as you, even without filtering, but ONLY when the maximum calibration point has been "fiddled" (to 20480) as you have. Evidently there's something in the real-time computations which is assuming that, for slope computation purposes, the max cannot be more than 16383.

I can't afford to spend a lot more time on this this week. could you possibly explain why you need any slope manipulation on the brakes axes? I'm pretty sure they weren't even added to such axes originally (and when they were, they obviously had no effect as I found out and fixed earlier today). As the only user of slopes on brakes, it would be useful to understand the reason for it.

If I can fix it easily I will do it sooner though.

{LATER STILL ... ]

Okay, I see what happened. I inserted the slope application call in the wrong place -- it is using uncalibrated, not calibrated values. Hence it was ignoring your artificial 20480 max value.

I can fix it pretty easily, but I can't build and upload a new version till tomorrow. It will be 3.997a or 4.609a, dated 22nd June 2011.

Regards

Pete

Link to comment
Share on other sites

Okay. Versions 3.997a and 4.709a work here with your data.

Regards

Pete

Thanks I'll test... so the reason for the artificial maximum is because the pressure required to press the brakes on Saitek is very low and linear and thus braking always goes to the stops. It's hard to not go to the stops and stay coordinated with both brakes (there's no feel of pressure). Going to the stops always locks brakes in FSX. Going to stops and locked brakes are completely unrealistic, and seem to provide unrealistic stopping distances (I'm an RW pilot as well a sim hobbyist). I noticed that going to 80% max provides no locked wheels and a more realistic feel. The reason for the slope is that because the "throw" of the Saitek brake is so short, I wanted finer control over individual brakes in the beginning of the movement, which also is more natural (the initial movement provides a lot less stopping power, then the final "to the stops" effort; while the level of effort required to push is not simulated by Saitek, the slope adjusts the result of the axes movement.)

Link to comment
Share on other sites

I noticed that going to 80% max provides no locked wheels and a more realistic feel. The reason for the slope is that because the "throw" of the Saitek brake is so short, I wanted finer control over individual brakes in the beginning of the movement

Okay, all reasonable. I just wonder why no one discovered that the slopes facility was inoperable on the brake axes before now? Must have been like that for many years! ;-)

Regards

Pete

Link to comment
Share on other sites

Okay, all reasonable. I just wonder why no one discovered that the slopes facility was inoperable on the brake axes before now? Must have been like that for many years! ;-)

Regards

Pete

I think most just don't care enough... but don't feel bad. It's like this for me with everything: if I touch it, I'll inevitably find something that's been broken/missing/wrong that no one noticed before. :)

Thanks for the great support BTW!

Link to comment
Share on other sites

Hmm... I'm still getting the same behavior with 4.709a.

With your exact parameters (but no filtering) and all three ways of assigning tested, I get matching OUT and logged FS values, every time, within 40-80 units (that's the granularity of the braking values, which runs 0-200). I've checked it with slopes as divergent as 15 and -15. I really can't do any more. I don't understand why it appears not to work for you, but logically, now, there is absolutely no way around the slope processing.

I changed the logging in 4.709a so you could see for yourself. If you have Axis event logging you should see the same as I. Here I have that set, and also I am monitoring the FSUIPC offset sohing the actual brake application in FSX (which is measured from 0 to 16384, not -16k to +16k, which explains the difference).

I'm logging, in each case, the last few "notches" to full application (IN = +16383 in this case). the max in the INI is edited to 20480 as in yours. The Log shows IN and OUT values, exactly as would be shown in the Calibration dialogue, and you can see that the OUT value corresponds with what is sent to FS. The actual application in FS is rather different because of the different range (0-16k instead of -16k to 16k).

So, where are you logs showing the opposite of this, something you are saying isn't working?

Left brake assigned in FSUIPC to FS control "Axis Left Brake Set"
=================================================================

Slope = 4:

  1581953 *** TOE BRAKE AXIS, Left set = 169 (IN=15360, OUT=11304)
  1581953 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 11304 (0x00002c28) AXIS_LEFT_BRAKE_SET
  1581984 Monitor IPC:0BC4 (S16) = 11609
  1581984 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.7085272059
  1583578 *** TOE BRAKE AXIS, Left set = 163 (IN=14848, OUT=10320)
  1583578 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 10321 (0x00002851) AXIS_LEFT_BRAKE_SET
  1583609 Monitor IPC:0BC4 (S16) = 10685
  1583609 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.652183173508
  1584015 *** TOE BRAKE AXIS, Left set = 158 (IN=14336, OUT=9502)
  1584015 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 9502 (0x0000251e) AXIS_LEFT_BRAKE_SET
  1584047 Monitor IPC:0BC4 (S16) = 9915
  1584047 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.605134604695
  1584765 *** TOE BRAKE AXIS, Left set = 177 (IN=16383, OUT=12614)
  1584765 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12614 (0x00003146) AXIS_LEFT_BRAKE_SET
  1584797 Monitor IPC:0BC4 (S16) = 12840
  1584797 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.783690093614
  1603250 Sim stopped: average frame rate for last 21 secs = 38.1 fps


Left brake assigned in FSUIPC direct to FSUIPC calibration "Left Brake"
=======================================================

Slope = 4

  1806547 *** TOE BRAKE AXIS, Left set = 169 (IN=15360, OUT=11304)
  1806578 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 11304 (0x00002c28) AXIS_LEFT_BRAKE_SET
  1806609 Monitor IPC:0BC4 (S16) = 11609
  1806609 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.7085272059
  1806844 *** TOE BRAKE AXIS, Left set = 174 (IN=15872, OUT=12124)
  1806890 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12123 (0x00002f5b) AXIS_LEFT_BRAKE_SET
  1806922 Monitor IPC:0BC4 (S16) = 12379
  1806922 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.755575774714
  1808031 *** TOE BRAKE AXIS, Left set = 177 (IN=16383, OUT=12614)
  1808094 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12614 (0x00003146) AXIS_LEFT_BRAKE_SET
  1808125 Monitor IPC:0BC4 (S16) = 12840
  1808125 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.783690093614

Left brake assigned in FSX to Left Brake
========================================

Slope = 4

  2089797 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450)
  2089828 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET
  2089859 Monitor IPC:0BC4 (S16) = 12688
  2089859 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.774395106871
  2089890 *** TOE BRAKE AXIS, Left set = 172 (IN=15684, OUT=11796)
  2089953 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 11795 (0x00002e13) AXIS_LEFT_BRAKE_SET
  2089984 Monitor IPC:0BC4 (S16) = 12071
  2089984 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.736756442556
  2090875 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450)
  2090906 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET
  2090937 Monitor IPC:0BC4 (S16) = 12688
  2090937 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.774395106871

I really don't see there's anything else I can do for you. Everything I've checked shows it works as intended. If you are using a slope like +4 or +15 then the top end is going to be pretty similar. You can see the real changes the Slope effects near the brakes-off level -- the area you are intending to affect in any case! Your "20480" artificial limit provides are real limit of about 12-13k, which is correct. (16384/20480) x 16384. If you want to limit it to 9k you'd need the upper limit set to (16384/9000) x 16384 = 29826.

If you still think it is wrong all I can suggest to you is that you write your own algorithm in Lua, as a lua plug-in assigned to your brakes.

Regards

Pete

Link to comment
Share on other sites

With your exact parameters (but no filtering) and all three ways of assigning tested, I get matching OUT and logged FS values, every time, within 40-80 units (that's the granularity of the braking values, which runs 0-200). I've checked it with slopes as divergent as 15 and -15. I really can't do any more. I don't understand why it appears not to work for you, but logically, now, there is absolutely no way around the slope processing.

I changed the logging in 4.709a so you could see for yourself. If you have Axis event logging you should see the same as I. Here I have that set, and also I am monitoring the FSUIPC offset sohing the actual brake application in FSX (which is measured from 0 to 16384, not -16k to +16k, which explains the difference).

I'm logging, in each case, the last few "notches" to full application (IN = +16383 in this case). the max in the INI is edited to 20480 as in yours. The Log shows IN and OUT values, exactly as would be shown in the Calibration dialogue, and you can see that the OUT value corresponds with what is sent to FS. The actual application in FS is rather different because of the different range (0-16k instead of -16k to 16k).

So, where are you logs showing the opposite of this, something you are saying isn't working?

Left brake assigned in FSUIPC to FS control "Axis Left Brake Set"
=================================================================

Slope = 4:

  1581953 *** TOE BRAKE AXIS, Left set = 169 (IN=15360, OUT=11304)
  1581953 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 11304 (0x00002c28) AXIS_LEFT_BRAKE_SET
  1581984 Monitor IPC:0BC4 (S16) = 11609
  1581984 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.7085272059
  1583578 *** TOE BRAKE AXIS, Left set = 163 (IN=14848, OUT=10320)
  1583578 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 10321 (0x00002851) AXIS_LEFT_BRAKE_SET
  1583609 Monitor IPC:0BC4 (S16) = 10685
  1583609 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.652183173508
  1584015 *** TOE BRAKE AXIS, Left set = 158 (IN=14336, OUT=9502)
  1584015 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 9502 (0x0000251e) AXIS_LEFT_BRAKE_SET
  1584047 Monitor IPC:0BC4 (S16) = 9915
  1584047 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.605134604695
  1584765 *** TOE BRAKE AXIS, Left set = 177 (IN=16383, OUT=12614)
  1584765 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12614 (0x00003146) AXIS_LEFT_BRAKE_SET
  1584797 Monitor IPC:0BC4 (S16) = 12840
  1584797 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.783690093614
  1603250 Sim stopped: average frame rate for last 21 secs = 38.1 fps


Left brake assigned in FSUIPC direct to FSUIPC calibration "Left Brake"
=======================================================

Slope = 4

  1806547 *** TOE BRAKE AXIS, Left set = 169 (IN=15360, OUT=11304)
  1806578 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 11304 (0x00002c28) AXIS_LEFT_BRAKE_SET
  1806609 Monitor IPC:0BC4 (S16) = 11609
  1806609 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.7085272059
  1806844 *** TOE BRAKE AXIS, Left set = 174 (IN=15872, OUT=12124)
  1806890 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12123 (0x00002f5b) AXIS_LEFT_BRAKE_SET
  1806922 Monitor IPC:0BC4 (S16) = 12379
  1806922 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.755575774714
  1808031 *** TOE BRAKE AXIS, Left set = 177 (IN=16383, OUT=12614)
  1808094 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12614 (0x00003146) AXIS_LEFT_BRAKE_SET
  1808125 Monitor IPC:0BC4 (S16) = 12840
  1808125 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.783690093614

Left brake assigned in FSX to Left Brake
========================================

Slope = 4

  2089797 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450)
  2089828 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET
  2089859 Monitor IPC:0BC4 (S16) = 12688
  2089859 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.774395106871
  2089890 *** TOE BRAKE AXIS, Left set = 172 (IN=15684, OUT=11796)
  2089953 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 11795 (0x00002e13) AXIS_LEFT_BRAKE_SET
  2089984 Monitor IPC:0BC4 (S16) = 12071
  2089984 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.736756442556
  2090875 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450)
  2090906 ***  AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET
  2090937 Monitor IPC:0BC4 (S16) = 12688
  2090937 SimRead: 0BC4="BRAKE LEFT POSITION"
        	FLT64: 0.774395106871

I really don't see there's anything else I can do for you. Everything I've checked shows it works as intended. If you are using a slope like +4 or +15 then the top end is going to be pretty similar. You can see the real changes the Slope effects near the brakes-off level -- the area you are intending to affect in any case! Your "20480" artificial limit provides are real limit of about 12-13k, which is correct. (16384/20480) x 16384. If you want to limit it to 9k you'd need the upper limit set to (16384/9000) x 16384 = 29826.

If you still think it is wrong all I can suggest to you is that you write your own algorithm in Lua, as a lua plug-in assigned to your brakes.

Regards

Pete

I've also disabled filtering, just to be sure.

So with a slope of 4 you are getting an OUT of 12450? I think that is the OUT value that should occur without a SLOPE.... If I remove the SLOPE I see that value (~12700) in OUT in the GUI and in the logs. But if I add in a SLOPE of 4, the GUI shows an OUT of ~9700 but the logs still show an out value of ~12700. So shouldn't the GUI and logs agree +/- a few hundred? Without a SLOPE they agree. With a SLOPE the GUI shows 9700+/- while the logs show 12700+/-.

I'm mapping a range of 32768 (-16k to 16k) to a range of 36864 (-16k to 20k). So at an input of +16k (fully pressed brakes) the OUT should be about 12743 (or (32768 / 36864 * 32768) - 16384) without a SLOPE map, which appears correct. But depending o the SLOPE setting, since the IN of 16384 is not the MAX value, the OUT should be less and less with higher an higher slopes. Am I correct? This appears to happen in the GUI, but not the logs.

I'll verify one more time to be sure, and I'll try to reproduce with another axes where the SLOPE appears to work correctly.

Link to comment
Share on other sites

I'm mapping a range of 32768 (-16k to 16k) to a range of 36864 (-16k to 20k). So at an input of +16k (fully pressed brakes) the OUT should be about 12743 (or (32768 / 36864 * 32768) - 16384) without a SLOPE map, which appears correct. But depending o the SLOPE setting, since the IN of 16384 is not the MAX value, the OUT should be less and less with higher an higher slopes. Am I correct? This appears to happen in the GUI, but not the logs.

Hmm. there's something strange going on here. I've tried with the release-built version and I also get the same discrepancy, yet the debug-built version, the one from which i showed the logs, shows the same in the GUI as in the log.

I'm not understanding this at present. That's one problem with delving through n-year old code, especially at my age! Sorry! I'll take a longer look. Back in a few days, hopefully!...

Pete

Link to comment
Share on other sites

Hmm. there's something strange going on here. I've tried with the release-built version and I also get the same discrepancy, yet the debug-built version, the one from which i showed the logs, shows the same in the GUI as in the log.

I'm not understanding this at present. That's one problem with delving through n-year old code, especially at my age! Sorry! I'll take a longer look. Back in a few days, hopefully!...

Pete

I know how it is...

I tested with the aileron axis, and that works correctly:

Ailerons (SLOPE 4) ---> 1.jpg

475662 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 10649 (0x00002999) AXIS_AILERONS_SET

Ailerons (SLOPE 0) ---> 2.jpg

837163 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 12953 (0x00003299) AXIS_AILERONS_SET

Brakes (Left SLOPE 0, Right SLOPE 4) ---> 3.jpg

685874 *** TOE BRAKE AXIS, Right set = 176 (IN=16192, OUT=12450)

685874 *** Both toe brakes over threshold: FS BRAKES control sent

685905 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450)

685936 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET

685936 *** AXIS: Cntrl= 66388 (0x00010354), Param= 12451 (0x000030a3) AXIS_RIGHT_BRAKE_SET

Notice how the ailerons output the same thing as the GUI, however the two brakes (one at SLOPE 0, the other at 4) log the same thing despite the GUI showing two different things.

post-21350-0-96545200-1308781187_thumb.j

post-21350-0-54847900-1308781194_thumb.j

post-21350-0-20283100-1308781203_thumb.j

Link to comment
Share on other sites

I tested with the aileron axis, and that works correctly:

the brakes treatment is very different, and not only because it is centreless. The original code handles brakes for FS98 via the 0x0C01 and 0x0C00 single byte offsets, which have the values 0-200. These are incremented by pressing the brakes button (.), and build up faster the quicker it is pressed (or if held), and die down over time. The brake axis treatment added by FSUIPC back then had to retain the pressure the axis was providing, so it became quite convoluted. For compatibility across versions since then all that original method is still retained and applied back to FSX's true axis support.

The brake axes are unique in this regard, and the route the values take is quite different from all the others. I'm working my way through it now.

Regards

Pete

Link to comment
Share on other sites

I'm working my way through it now.

Right. I've made some drastic changes (up till the wee hours), and even simplified things a bit in the process. Both UI and run-time action for the brake axes should now follow the same path through the code and therefore give the same results, which themselves seem okay now according to my testing.

Of course I could be wrong, I have been twice before already, so please try 4.709b and let me know.

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.