Closed ProDrone closed 9 years ago
D'oh! I had actually already added basically free auto-detection of this, but never ended up committing it because it broke the calibration. However, rather than adding a bunch of shifts, it defines a configurable input alias shift factor and shifts the scalers when pulses are received in the scaling range, accepting a change only during arming. I figure this is safer than always allowing either input. For the end user, it's still transparent, as switching modes will just cause a timeout disarm and re-arm.
BTW, I don't think it's a good idea to enable COMP_PWM by default for bs_nfet, since some people won't want it. I agree, though, that some method of making it more obvious of an available feature needs to be available, since it sounds like most users haven't tried it. I've been experimenting with various forms of regeneration protection to make it safe-ish to enable even if the battery falls off in flight or on bench supplies, but this is a bit tricky with slow ADCs and no logic level signals that would go high right above maximum input voltage on most boards.
I think the bunch of shifts is the fastest way to execute this and calibration still works fine. I also thought about safety with respect to accepting both ranges. Considering in flight and on the bench scenario. When is it not safe? If only a few pulses are wrong it will be hardly noticeable. If many pulses are wrong, there must be something totally wrong. On the bench one should either remove all props or limit the supplied current to prevent a take off. What happens when there is a timeout disarm and rearm in mid air? Will the copter continue normally?
I agree that COMP_PWM should not be enabled by default, but i think using oneshot125 without it is kind of useless. I am not sure if protection against the regenerated voltage can be accomplished, would be a nice feature to have. Its interesting to see what happens when you have 4 motors randomly regenerating & consuming power when the battery just fell off... On the bench i am using a supply that has Over Voltage Protection, so i feel safe...not sure if i am.
With an always-active input alias, there is a greater chance that a bad connection or noise (like RF input if the cable falls off or is pulled or is held by the finger while removed) will power the motor. The rest of the input flow determines which input to use and disables the rest, and I think the operation at a pulse length alias should be implemented as another input type that persists as long as the ESC is armed.
Shifting is certainly not the fastest way since there's already a 16x16 multiplier that follows to scale it to POWER_RANGE. The way I did it the other day was to just recalculate the scaling factor during arming and then the armed phase has nothing more needed other than an additional pulse length limit check for safety. I saved some cycles for this elsewhere, so the whole change is mostly free.
I'll post it shortly.
Good to see you going to great length for safety. I'm looking forward to your solution. Another related thing which is already mentioned as issue #43 is still there to solve. The problem is with popular motors for mini H race quads. These are the same quads that have the most benefit from oneshot125.
I would like to test this out on HK F30a 30amp ESC's with cleanflight and oneshot, where can I find the BS_NFET.HEX file? I am not a software guy, I don't compile. TIA
@Ozzy33 you can download it from my Dropbox here: https://www.dropbox.com/s/wn44hukquwb7jbp/bs_nfet_6dbc056a71.hex?dl=0. It has been successfully tested on Sunnysky 2204 2300Kv motors and Blue Series 12A ESC's.
Is comp_pwm enabled on this .HEX file?
Thanks Lauszus, SK, prodrone and everybody else!
@Ozzy33 no it is not.
When ONESHOT125 is defined in the *.inc file (only useful when combined with COMP_PWM defined) the rc puls length is automatically detected and adjusted for oneshot125 and/or normal range PWM input (1000-2000uSec).