Throttle Calibration Problem
-
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. -
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
-
I use ccleaner.
Also be sure delete any folders left behind. HOTAS for example -
thanks
-
@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 correctlyTo 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.
-
You know you don’t have to do that, right:
Just enable the boot settings from the CCP and you can skip it
-
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.
-
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… -
@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.pngRedDog, 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*** fieldI 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…
Cheeriop.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 -
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 pcAre 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 flyingSo sorry mate, I am not convinced
-
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
…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?
-
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:
-
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.