Just ziptied it to the two zipties i use to hold my compass… Works great, and i didn’t have to drill, glue, disasemble anything 
1 Like
Luis, I have an oscilloscope, don’t know how to test it. if you could guide me I would be glad to help.
I have three drones with Ardupilot: tarot hexa 680 , 480 immersionr quadc, one 270 racer - all with hobbyking escs. Blue series and Afro. All suffers from the very same problem: random arm - Oneshot and random twists ( oneshot125).
With oneshot ( not 125 ) , the random arm started with rc3. I’m pretty sure that the issue wasn’t present in RC1, (I can downgrade and test again). If so, and assuming that it could be an Blheli weirdness or component quality, why was it working before?
I’m travelling, but I will be back this weekend, so if anyone has any suggestion, just let me know than I’ll test and report back.
I’m using Oneshot125 with Pixracer and Speedix ESC’s with Blheli_S firmware and it’s working well. I just set the PWM min/max with BlHelisuite, no need for the typical calibration procedure.
Thanks Dkemxr. Mine isn’t blheli_s. Is there someone around with regular blheli having a working setup ?
Exactly the point. Some work great, some don’t…
Well, yes. I also have a Pixhawk quad (no distinction between Pixracer and Pixhawk I suppose) with older ZTW mini ESC’s running BlHeli and they work configured for Oneshot125. As Mr. Gonçalves states it seems to be ESC specific. Maybe Dshot should be developed as a standard.
Thank´s for the ideas guys 
Weird. Unfortunately no one from BLheli has shown any interest in looking at this issue and the code isn’t open.
Anyone reporting oneshot 125 issue? https://github.com/bitdump/BLHeli/issues?page=1&q=is%3Aissue+is%3Aopen
If someone can redact in correct english let me know to add +1
Great! I thought that i’ve read in rcforums that it was closed source. Will take a look to see if I find something. I will need to order a spare esc to test it.
I will, but now I’m travelling so I’m unable to post video, evidences etc. In this scenario I think that would be necessary because it only happens in a few escs
1 Like
I just want to mention, I am using “spider pro 20A” esc’s from RTFQ, and oneshot 125, and it is working fine, other than it takes a minute or two for all of them to arm.
Hello! Back home.
I made a video summarizing the issue : https://youtu.be/N833Bsi8Lds
I’ve read in git that disabling safety switch solves the random arming issue. Voila!
So, for that I think it is an ardupilot issue. @rmackay9 Could you please reopen the issue in git? Thanks,
The twitching with Oneshot125 is still present in 3.4.2 - I believe it has nothing to do with the random arming. I’ll start to dig on it in order to understand and will post a smaller video demonstrating the problem in blheli git issues page.
1 Like
Bit of an old thread, but I’ve got the same issue.
Arducopter arms some oneshot esc’s but not others.
Specifically for me, it won’t arm emax lightning_s 35A with blheli_s.
I suspect it’s because these esc’s auto-detect protocols and the Arducopter startup confuses them, but I could just be doing something wrong. Any tips appreciated.
Did the calibration routine went well on this esc? I’m willing to dig on git to find out which commit is the responsible for this behaviour.
I’d calibrated through blheli suite.
Got the esc’s working today (well, @tridge did). There was definitely something weird going on: the esc’s seemed to be stuck in cal mode. I’ll need to chat to him a bit more to work through what the problem was, and then I can post it.
Agree. Calibrating thru BLHeli suite is a good option.Until Ardu adds pass-through (being considered I understand) I just use a cheap Naze32 FC for a programmer. Between that and manually setting the MOT parameters in Mission Planner it works great.
I too have this issue with arducopter 3.4.4 and BLHeli 14.9 on RG20A. The ESC’s will eventually arm but you have to wait some time for it to happen and they happen at random times. Weirdly if I calibrate they are fine immediately afterwards, but if you remove power for some period and then try again the problem persists. Seems like this must be an arducopter issue otherwise all the other FC folk would be complaining.