If I double the available gain range, you'd just have to adjust your transmitter gain end point to 37% to get the same gain you have now - but it would make more gain available for faster servos. In the past, I've found that the faster the servo, the higher you can set the gain before oscillation sets in - though of course there are lots of other factors like rotor (and tail rotor) rpm, tail rotor blade length, and so on...
I've done the first stage and test flown the 450 in the garden, without a canopy fitted (and with its existing Spartan Quark gyro and Futaba S9650 tail servo). It all went well until the battery fell out! Luckily, it was in a very low stable hover when it happened so no harm done - the heli just landed. Good job it didn't happen earlier when I was doing gentle lazy 8s or hovering higher up to check the blade tracking (which was out - but it can stay out for now as I've already removed the blades for the next stage of testing).
No more test flying of that helicopter until I've sorted out the gyro program - the whole point of repairing it was to use it as a test-bed. I've got plenty of other helis I can fly for fun - but because they're either the mini ones with integrated gyros, flybarless ones where the tail gyro is part of the flight controller, or bigger noisier glow powered ones, they're not as suitable for gyro testing in the garden, or perhaps even indoors.
Other things I'm thinking of adding:
- Configurable output pulse rate to suit faster digital servos. At the moment, the output pulse rate is the same as the input pulse rate from the receiver - so probably 50Hz-ish for most receivers. At the moment, my program initializes the gyro to provide only 50 updates per second, so there's no point in driving the servo at a faster frame rate - even if it's capable. But the MPU6050 can be configured to provide much faster updates - and I think the ATtiny could cope with faster frame rates and servo modulation schemes such as the ones that run at 560Hz with a 760 microsecond centre-pulse width.
. - Compensating for any slight clock-drift in the ATtiny85 by using the received pulse rate from the receiver as a reference. The ATtiny85 is running on its internal clock which might drift by 0.5% or so - due mainly to temperature changes.
Assuming the received frame rate is constant (because the receiver and transmitter probably have crystal controlled microprocessors) then the ATtiny could measure the frame time during the gyro calibration period - say it's 2000 microseconds. If, later the ATtiny thinks the frame rate has changed to 2010 microseconds, it's more likely that the ATtiny's clock has sped up by half a percent - so it could compensate for that by making the same half-percent change to its measured (and output) pulse widths.
I suppose if someone is flying with a vintage non-microprocessor transmitter and receiver then that would probably drift by more than the ATtiny's clock, so there would be the option to switch clock drift compensation off in the config file.