FSUIPC Fails to see CH rudder toebrakes at initial startup

[Adamski]

FSUIPC 4.60a. I have a Saitek X52 throttle/stick plus CH rudders with toe brakes. All axes are UNassigned in FSX. Everything calibrates and works fine via FSUIPC- all my additional axes (rudder, toe brakes, reverser, prop, mixture) are mapped to various rotaries or sliders ...

However - I seem to need to open up FSUIPC and just use one additional axis and closing the window (without making any changes whatsoever) before FSX "sees" my toe brakes. When I'm in this pre-open FSUIPC window "limbo", all my axes operate fine - except the toe brakes.

It's not a huge problem - I make a point of opening and closing FSUIPC for each new FSX session, but I'm wondering whether this can be avoided. It feels like FSUIPC isn't quite initiliasing properly on startup.

My first post here, so be gentle with me! *Great* program, BTW Pete!

EDIT: Just installed 4.616. Same issue. Correction to the above: simply opening and closing the FSUIPC window kicks things off.

[Pete Dowson]

However - I seem to need to open up FSUIPC and just use one additional axis and closing the window (without making any changes whatsoever) before FSX "sees" my toe brakes. When I'm in this pre-open FSUIPC window "limbo", all my axes operate fine - except the toe brakes.

Strange, because FSUIPC doesn't treat any axis differently than any other. Have you made sure that Windows USB power management is switched off? That's the usual reason for unseen axes -- the USB driver doesn't pick them up initially because of power cut of to the chips.

It feels like FSUIPC isn't quite initiliasing properly on startup.

FSUIPC doesn't do anything differently initially as compared to when you go into the options. It's the same routine.

Are the toe brakes properly calibrated? Or maybe they are operating digitally? If they are only providing two values -- off or full on -- you would need to operate them a few times before FSUIPC will start to use the values. This applies to all axes, it needs to see 6-12 changes before accepting a "good" value. This is to make sure it doesn't use spurious values generated by some joystick drivers whilst initialising, which otherwise cause some havoc.

You could also try updating to 4.616, available here in the Updates announcement. Although there's nothing specifically changed in this area, a lot of other things have.

Regards

Pete

[peterhayes]

PeteD

Sorry to interrupt but didn't Bob Church explain this behaviour in viewtopic.php?f=54&t=70574&p=438683#p438683 and I think viewtopic.php?f=54&t=71912&p=445130&hilit=bob+church#p445130 as well.

Bob said: "When FS first starts, it's apparently defaulting everything to zero or whatever. FS has no data until an axis or button on the controller changes value/state and it sends a report. It should only take movement by one control on each controller, and in a lot of cases one of the values will be bobbling (127, 128, 127, 128, .....) anyway and that's enough. You're feet are on the pedals and your hands are on the yoke, it would be very unlikely that they wouldn't move by at least a count. OTOH, with the Quad, if the levers are in the detents they're dead stable because they're in deadzone, and it's likely that the endpoints are stable too so no data goes to FS and you're running on the default value until something moves. The pedals will do that too about half the time if your feet aren't on them."

Apologies if this is a different problem

PeterH

[Adamski]

Are the toe brakes properly calibrated? Or maybe they are operating digitally? If they are only providing two values -- off or full on -- you would need to operate them a few times before FSUIPC will start to use the values. This applies to all axes, it needs to see 6-12 changes before accepting a "good" value. This is to make sure it doesn't use spurious values generated by some joystick drivers whilst initialising, which otherwise cause some havoc.

Thanks Pete D and Pete H (!!). I must say I'm still a bit perplexed by this. I agree that the toe brakes shouldn't be behaving differently. I updated to 4.616.

1) I disabled power management for all USB devices (then rebooted).

2) Started up FSX without touching any controllers. Same problem. All axes work except the toe brakes.

3) Restarted FSX, but kept moving the toe brakes as the flight loaded. This time, the axes were recognised, but didn't appear to be calibrated properly. Opening up the FSUIPC window gets things back to normal again.

How can I check if they're operating "digitally"? As far as I can make out, they apply gradually - more pressure gives greater braking effect. I suspect that my TB calibration is somehow not quite as it should be. I've scoured various posts as to how to do it but can't see where I may be going wrong.

Adam.

[Adamski]

Well - I'm embarrassed :oops: to say I think I've solved it! The advice here got me thinkingthat nothing was being sent by the TBso I re-did my calibration and set my DELTA to a much smaller value. I'd set it unnaturally high as I was getting a fair few spurious spikes that were jamming the brakes on when taxiing. I found a sweet spot that didn't trigger the brakes, yet was enough for FSUIPC to "see" the axes.

I've tested it about four times now - each time from a fresh FSX startup - and all is OKyay!!! Thanks to both Petes here for pointing me in the right directionI'm a happy camper :D

[Pete Dowson]

... and set my DELTA to a much smaller value. I'd set it unnaturally high as I was getting a fair few spurious spikes that were jamming the brakes on when taxiing. I found a sweet spot that didn't trigger the brakes, yet was enough for FSUIPC to "see" the axes.

The Delta tells FSUIPC to ignore any changes less that that so you can eliminate jitter, but it shouldn't never be used in place of a null zone for any axis!

Instead of finding a "sweet spot" for the Delta, put it back to default and simply re-calibrate with the "brakes off" (minimum) point set with both brakes pressed in a little way. Similarly set the max with the brakes not quite fully pushed down. That way (the way actually documented in the step-by-step calibration section of the user guide) you still get excellent sensitivity over the range, and can always reach max braking (or whatever), without risk of accidentally engaging them.

This is the very reason FSUIPC doesn't do "automatic calibration" like many drivers -- setting endpoints WITHIN the range and not at the extremes helps get the best from your equipment!

Regards

Pete

[Adamski]

The Delta tells FSUIPC to ignore any changes less that that so you can eliminate jitter, but it shouldn't never be used in place of a null zone for any axis!

This should be printed in red and bold in the manual! :wink:

Instead of finding a "sweet spot" for the Delta, put it back to default and simply re-calibrate with the "brakes off" (minimum) point set with both brakes pressed in a little way. Similarly set the max with the brakes not quite fully pushed down. That way (the way actually documented in the step-by-step calibration section of the user guide) you still get excellent sensitivity over the range, and can always reach max braking (or whatever), without risk of accidentally engaging them.

I followed those instructions (which are pretty good, I have to say) but I think my pots may be past it. I don't just get small spikes - I get really huge values at the very beginning, then a smooth bit and a final huge value when the pedal is all the way down. I did calibrate just short of this last spike - or I couldn't have got them to work at all! It's that huge spike at the beginning that causes the brakes to jam on - just when you're taxiing past the control tower :lol:

On the subject of spiky pots - it's great to see Bob Church around in this forum. I'm a long time Falcon/Thrustmaster customer of his! I have every hope that FSUIPC can do in software what his digital chips did in hardware for my venerable TM gear 8)

I'll have another go at calibrating - but it's already 100x better than it was - much appreciated!

EDIT/UPDATE: Last calibration seems to have totally tamed the beast :D