Throttle Calibration Problem

[Badger]

After many years my Win 7 was getting buggy so I made the switch, finally, to win 10 pro.

My biggest worry was that I would have troubles getting the cougar to work but, it installed without trouble, following cub pilots guide.

However, every time i boot the machine the throttle, just the throttle, is out of calibration, so I have to run through the calibration routine with each start up.

I do have cup pilot’s hall sensor mod, and it is working fine.

What I’ve tried so far is the HOTAS cleanse, and the reflash firmware, with throttle disconnected, problem persists.

I also notice that the foxy joystick analyzer shows the stick pegged to the lower right hand corner of the screen.

Any thoughts / recommendations?

Thanks

[Red Dog]

Are you sure it loses the calibration?

I sometimes have this as well, but it actually does not lose calibration, it simply reverts to auto calibration
and that’s most noticeably visible because of the throttle detents not working correctly

To start with, just check the CCP when it happens, check the auto or manual calibration. and if it’s on auto calibration, just click manual calibration and Apply

it’s only half of the solution, but at least you Don’t have to recalibrate it each time

The question I haven’t really given more thought is why does it go back to mama and reset auto calibration.
To me it doesn’t happen at each reboot, but sometimes it does that and it drives me crazy as well as you realize it too late (once in the pit with a engine spooling down while your throttle is at idle detent …)

[Badger]

Actually, RD, I think you may be spot on. I will check that tonight.

In my case, when the throttle is at physical idle position, it reports at 80%, so away I go.

[Badger]

because of some other oddities, I did a complete reinstall of drivers and software.
All is good for now.

[white_fang]

Ha … Please Badger what exactly did you do ?

I have , at least it seems , that same problem with Cougar , X and Y and Throttle often change their min-max values so hence need re-calibration every now an then on win10.

Since then I figured that it happens mostly if I disconnect stick from usb port , I have it connected via powered usb3hub with switches for every port , so I turn off the ports I’m not using , but then this problem arise.

Mostly is just the throttle sometimes off from min and/or max , but sometimes X and Y come into play.

!!! funny enough - ANT RNG and MICROSTICK are NOT affected anytime, NEVER,… So just X,Y and (Z) Throttle. - and that only after the stick was disconnected for some time, was that from night till morning or a few days., doesn’t matters

Well , workaround is kinda a bitch…

1. manually create profile “test” with full ranges to axis 0-32767-65535 , then switch to it via “Cougar ctrl panel” and then with DIVIEW see min and max values at the moment,

2. then manually (npp++) edit and paste those min/max values into my original “user-profile” , save

3. apply my user-profile via Cougar control panel , and all is peachy

4… at least for some time… then after I don’t use stick for few days and plug it in / power usb-hub port , problem re-appears … shit

Please help - What did you do, maybe it will help me too …

Cheers

p.s. Another one Win10 peculiar bug with Cougar,… Seems RDDR and LBRK axis are swapped (buggy?) but only ‘visually’, internally they work as intended …
… have RDDR axis digitalised via S3 + ANT axis , use it for Zoom in BMS , … I have Logitech/Saitek pedals for real rudder

Rem TQS section
ANT /I LOCK(ANT,LASTVALUE) 2 49 LOCK(RDDR,100%) LOCK(RDDR,97%) LOCK(RDDR,94%) LOCK(RDDR,92%) LOCK(RDDR,90%) LOCK(RDDR,88%) LOCK(RDDR,86%) LOCK(RDDR,84%) LOCK(RDDR,82%) LOCK(RDDR,80%) LOCK(RDDR,78%) LOCK(RDDR,76%) LOCK(RDDR,74%) LOCK(RDDR,72%) LOCK(RDDR,70%) LOCK(RDDR,68%) LOCK(RDDR,66%) LOCK(RDDR,64%) LOCK(RDDR,62%) LOCK(RDDR,60%) LOCK(RDDR,58%) LOCK(RDDR,56%) LOCK(RDDR,54%) LOCK(RDDR,52%) LOCK(RDDR,50%) LOCK(RDDR,48%) LOCK (RDDR,46%) LOCK(RDDR,44%) LOCK(RDDR,42%) LOCK(RDDR,40%) LOCK(RDDR,38%) LOCK(RDDR,36%) LOCK(RDDR,34%) LOCK(RDDR,32%) LOCK(RDDR,30%) LOCK(RDDR,28%) LOCK(RDDR,26%) LOCK(RDDR,24%) LOCK(RDDR,22%) LOCK(RDDR,20%) LOCK(RDDR,18%) LOCK(RDDR,16%) LOCK(RDDR,14%) LOCK(RDDR,12%) LOCK(RDDR,10%) LOCK(RDDR,8%) LOCK(RDDR,6%) LOCK(RDDR,3%) LOCK(RDDR,0%)
    /O UNLOCK(ANT)

…so when I press S3 with ANT movement , I “LOCK” (S3in) RDDR axis via ANT , and when I ‘retrieve data’ from stick from Cougar control panel , the LBRK turns ‘Red’ (locked) instead RDDR …
I was banging my head ‘wtf?’ , … so I did little test and reconfigure LBRK instead (RDDR) , … and now… Guess what , … Now RDDR turns ‘Red’ (locked state) …

So it means they are swapped in software/windows , who knows… BUT! , other then that , axis works as they should NOT SWAPPED , RDDR is RDDR , LBRK is LBRK , just that ‘visually’, ‘Red’ locked state in Cougar control panel is buggy.(swapped) … maybe?!

[Badger]

I completely uninstall all cougar software, did a register clean up, unplugged cougar, rebooted, run registry cleaner again to be sure.
Followed word for word cub pilots instructions for installing on 64 bit system
No problems since then.

I have my cougar plugged directly into PC USB port not powered hub as recommended.
I never unplug it either, no need for me to do so.

[b_bong12]

How did u clean un the register? I uninstalled the drivers but after installation my CCP was as before.with the tmj and all the axes as before

[Badger]

I use ccleaner.
Also be sure delete any folders left behind. HOTAS for example

[b_bong12]

thanks

[buzzkill]

@Red:

Are you sure it loses the calibration?

I sometimes have this as well, but it actually does not lose calibration, it simply reverts to auto calibration
and that’s most noticeably visible because of the throttle detents not working correctly

To start with, just check the CCP when it happens, check the auto or manual calibration. and if it’s on auto calibration, just click manual calibration and Apply

it’s only half of the solution, but at least you Don’t have to recalibrate it each time

The question I haven’t really given more thought is why does it go back to mama and reset auto calibration.
To me it doesn’t happen at each reboot, but sometimes it does that and it drives me crazy as well as you realize it too late (once in the pit with a engine spooling down while your throttle is at idle detent …)

I have to apply Manual Calibration every boot. No big deal, gotta open CCP anyway to enable Btn/Axis Emulation.

[Red Dog]

You know you don’t have to do that, right:

Just enable the boot settings from the CCP and you can skip it

[buzzkill]

Here’s a screenshot of mine (shows in Manual now because I just flew a mission, but it boots up in Auto)

I think I have it set up right, it just doesn’t work. To be honest, I actually prefer the emulation being off until I’m ready to use it. Can cause problems if DGFT or something is unintentially engaged.

[Arty]

For me doesn’t work always.
So every time I open ccp and most of the times I have to reselect. For decades now.
I don’t recall though on my clean flight setup… I have to use it for years…

[white_fang]

@Red:

You know you don’t have to do that, right:

Just enable the boot settings from the CCP and you can skip it
http://www.ravico.com/ST/BMS_433/picture/Hypersnap00915.png

RedDog, I try to avoid that. NO WRITE to the stick eprom if not actually needed , chip as chip has finite number of writes (as a ssd) , … well it is a BIG number but whatever, Cougar eprom is an old standard built in WORM eepRom concept! ,
write-once-read-many , so hence , by using CCP in autostart you actually program stick by every restart, write to eprom , … while is good to refresh data , you actually decrease write counter by 1, technically every day by booting up pc.

so by using just that one line in profile , cougar should be good even for portable even between 2 pc’s , well as ‘Doc’ said in foxy … ‘In theory’ … I’ve never tried portability… , but stick programmed with that works without CCP autostart…, hence no need for ‘surplus’ writes to eprom

USE HWSTARTUP (EMULATION_ON, AXIS_MODE_USER, CALIBRATION_MANUAL)

@Badger
Ok,. THANKS Badger , so little housekeeping is on the way … ahhh, well., hope this will work.

I figured that it was strange that re-flashing did not correct situation of that suspicious ‘drift’, so first thought was something has gone wrong with controller or eprom , or by loosing power calibration data in eprom somehow gets corrupted … but that didn’t explain perfectly normal other 4 axis, ant,rng,microstick… so only 3 ‘basic’ axis sometimes do drift x,y,z.
That even could be something with software , even win10… hence, it is suspicious enough that software was written for Vista-x64 , so even compatibility is in question, moreover some bugs alone in win10… it is a big f*** field

I forgot to mention that completely same thing happens if stick is plugged in usb2 directly to motherboard, OH YES I’ve TRIED… , so NO difference between usb3hub and usb2 on MB…
YES… I know, the ‘golden’ rule is AVOID usb-hubs for the stick, and that was true for old tech unpowered hubs, or low quality ones, where they were problematic,…

But, every other device plugged in my hub works perfectly. PS3camera, usb-disks, saitek pedals, … .even power for ir diodes for opentrack … I can’t see any problem there.
Once I get rid of the drift by workaround explained before, everything in combination works without problem… Really… beats me.

Anyways, have some dusting to do…
Cheerio

p.s. this is the 7 port hub, but it has a DC adapter not shown on that pic
https://www.ebay.com/itm/Binful-Usb-3-Hub-3-0-4-7-Ports-With-Power-Charging-And-Switch-Multiple-Usb-Sp-/273347078053

[Red Dog]

RedDog, I try to avoid that. NO WRITE to the stick eprom if not actually needed , chip as chip has finite number of writes (as a ssd) , … well it is a BIG number but whatever, Cougar eprom is an old standard built in WORM eepRom concept! ,
write-once-read-many , so hence , by using CCP in autostart you actually program stick by every restart, write to eprom , … while is good to refresh data , you actually decrease write counter by 1, technically every day by booting up pc

Are you sure about that?
I doubt that waking up the last bit loaded is actually a write on the eeprom
Back in the old days, we had ppl donwloading the files each day from Foxy before flying. That was Indeed not advised for the Reason you state
But I doubt a wakeup with manual calibration and emulation On write anything on the eeprom.
if that was the case, then clicking manually the red button for it to become green would be a write as well
and in that case, my method wouldn’t be worse than clicking everyday on that emulation button before flying

So sorry mate, I am not convinced

[white_fang]

Of course I’m sure, … Pleas ‘Dog’ , I know it is hard to believe to everydays mubojumbo, but trust me on this one. Let me find a quote from foxy help, I’ll point you there , I KNOW , I’ve read it from there.

But , even so, logic must prevail also … When you PROGRAM stick then, alas, you WRITE to the same chip , it even writes to the chip when you calibrate via internal mechanism for min/max/center values .

I’ve read all that from technical manual and stuff, and its… perfectly logical

–edit: Read this … as I’ve said it is a BIG number of write/erase cycles so probably you will not exceed it, but to avoid unnecessary every-day program , why not? !!!Especially IF it writes to the SAME address location on the chip over and over, IF not using ‘address cycling’ of data meaning data is stored in similar fashion on the disks , everytime on another sector/location , so the same sector is not used 2 or more times in the row even on overwrite of the same data

https://www.edn.com/design/systems-design/4359278/Overcoming-erase-write-endurance-limitations-in-EEPROMs

…but feckin I can’t find that quote from foxy’s help, other then this, on contraire … but I know ‘Nutty’ referred to chip flashing/programming at some point, was that in help file or here in forum like 7-8 years ago or more… can’t recall/
…but essentially.
'Don’t worry, nothing’s gonna break, we flashed/programmed it zillion times and they still work…"

If you’ve ever flashed the BIOS on your motherboard, then you’ll also probably remember the first time you did this and how petrified you were. Well I certainly remember that fear. This was because I’d read nightmare accounts on the net from people who after flashing their BIOS couldn’t get their computers to start, booted up with blank screens, had to use jumpers to clear their CMOS settings …. etc. etc. I’ve noticed that this trepidation has trickled down to users when advised to flash their Cougars. What if it all goes horribly wrong?

So I want to set you straight on this. It won’t go horribly wrong. It is likely to become such a non event for you you’ll wonder what all the fuss was about. If for any reason the flash doesn’t take, a reboot and reflash will always fix it. You can completely erase the firmware inside the Cougar so it’s gone, and it’s no big deal. The stick will quite happily sit there still connected, ready to be flashed again, and your computer will still work fine. So hopefully you can lay your fears to rest on this. During development, when we were testing statements and bug hunting, we’d always reflash before every test to ensure we were at the same common state, and that might mean we’d be flashing our controllers 30+ times a day. So it’s no big deal, and it’s a great way of resetting your controllers to a perfect state should you have any problem with them.

Convinced?

[white_fang]

@BADGER

You are the MAN… something that stupid like re-install can fix something that tricky complicated like axis play/drift … unbelievable, and true… f*** me if I know what was wrong.
All stuff was installed the same before in the first place. (ugh, with 4 windows major upgrades after initial install, from win7x64 over win8 /win8.1…. till win10 1809… maybe something got stuck:) )
Same 2007HCO driver … same foxy sofware, but foxy wasn’t the problem for sure.
Same HUBPILOT pdf instructions , with copy that STT…203.dll in SYS64 dir…
Working out of the box, but now WITHOUT drift and some play in center. And NO CCP autostart need at all.
Anyway case closed.

Here, I gave you THANKS as many posts you’ve had in this thread

Now I just wait for my hal sensors and magnets.

Cheers :drink:

[Badger]

Glad to hear it worked out for you

I was puzzled as well. So many years without a hiccup

had to do two reinstalls. Thank goodness that the second one took.