BLHeli OneShot, WiiEsc OneShot, SimonK OneShot - RC Groups
Thread Tools
Dec 16, 2014, 10:38 AM
RADIOACTIVE! RADIOACTIVE!
RS2K's Avatar
Discussion

BLHeli OneShot, WiiEsc OneShot, SimonK OneShot


This thread is for the discussion for adding OneShot125 to BLHeli, SimonK and WiiESC flashed ESCs.

Good explanation about what OneShot125 is here:
https://wiki.openpilot.org/display/W...125+or+PWMSync

BLHeli suite 13 now included OneShot125 support with auto detection. You can download it here:
http://www.helifreak.com/blog.php?b=2162

Tutorial by kajakmannen for flashing Atmel based ESC using BLHeli.
https://www.rcgroups.com/forums/show...3&d=1422550251

Quick instructions guide by akcom for SiLabs ESCs:
For those of you looking for the simplest way to flash SiLabs based ESCs to the newest BLHeli:
1. Buy an arduino nano for 11 bucks here
2. Open BLHeliSuite
3. Under ATMEL/SILAB select SiLab Serial Interface
4. Under the Interfaces for SiLabs tab, click "Make Arduino Nano Stick"
5. Connect your arduino nano to your ESC
5a. Show Pinout for Serial Interfaces (local pdf) has a description of how to connect it
6. Go back to the SiLabs BESC Setup tab and under port, select the port for your arduino
7. Click connect
8. Profit!


Test videos:

Maiden test flight on 6S. BLHeli and OneShot125 enabled.
First FPV flight of Tornado Spawner, Insanity Incarnate. (1 min 36 sec)


TESTING,TESTING,TESTING...BLHELI ONESHOT. (2 min 37 sec)


fpv - minion mini h quad - the jerk of the field (5 min 15 sec)


Blackout Super Mini H- Naze32- w/RS2K's Blheli OneShot125 ESC FW (4 min 0 sec)


Test goes like this.
1. Throttle to get arm level.
2. Jab roll stick left from center to stop 4 times.
3. Jab roll stick right from center to stop 4 times.
4. Tap arm sharply down 4 times.
5. Tap arm sharply up 4 times.

Naze32 was fully powered off and on after enabling and disabling OneShot125.

I can see the graph is smoother when oneshot is enabled. It also gets to where it needs to be faster with less oscillation. I look forward to trying this on a fast high and low NFET SiLabs ESC.

OneShot125 Disabled on BLHeli (0 min 43 sec)


OneShot125 Enabled on BLHeli (0 min 43 sec)


RCGroups BLHeli thread:
https://www.rcgroups.com/forums/show....php?t=2136895

BLHeli SiLabs compatible ESC PDF List:
https://github.com/bitdump/BLHeli/bl...s.pdf?raw=true

BLHeli Atmel compatible ESC PDF List:
https://github.com/bitdump/BLHeli/bl...s.pdf?raw=true

BLHeli GitHub:
https://github.com/bitdump/BLHeli

Here is an explination of the concept of oneshot PWM.
http://www.multiwii.com/forum/viewtopic.php?f=7&t=2729

Good explanation of what the flight controller does differently with OneShot125 enabled. Excerpt from from CleanFlight Issue #116.
Code:
Here is the code to allow oneshot125 in cleanflight.

It works by setting the timer speed to 8 Mhz (instead of 1 MHz), and also synchronises the ESC pulse to the main flight control loop.

It has been flight tested OK, and should also work for mixes where servos are used on motor outputs 1&2, and ESCs on 3, 4, 5 and 6 (eg tricopter mode, or gimbal control).

This is in relation to #116

This code will only work when the ESC timer is not used for anything else. It will need verification that this feature doesn't interfere with other functions that also use timers, as well as verification that this doesn't break functions on non-Naze hardware.

BLHeli:
The ESC firmware source code is published here: https://github.com/bitdump/BLHeli
The BLHeliSuite PC software can be found here: http://www.helifreak.com/blog.php?b=2162
or here: https://www.mediafire.com/folder/dx6...4l/BLHeliSuite

SimonK flasher:
RapidFlash Chrome App: https://chrome.google.com/webstore/d.../related?hl=en
Last edited by RS2K; Apr 04, 2015 at 07:42 PM.
Sign up now
to remove ads between posts
Dec 16, 2014, 10:41 AM
RADIOACTIVE! RADIOACTIVE!
RS2K's Avatar
Copy and pastes from of posts relating to BLHeli with OneShot125 from the ZMR 250 thread to go here.


I know I'm missing some. It's a busy day at work.


Quote:
Originally Posted by RS2K
I just looked up the oneshot code in CleanFlight. It's incredibly simple.

Code:
Here is the code to allow oneshot125 in cleanflight.

It works by setting the timer speed to 8 Mhz (instead of 1 MHz), and also synchronises the ESC pulse to the main flight control loop.

It has been flight tested OK, and should also work for mixes where servos are used on motor outputs 1&2, and ESCs on 3, 4, 5 and 6 (eg tricopter mode, or gimbal control).

This is in relation to #116

This code will only work when the ESC timer is not used for anything else. It will need verification that this feature doesn't interfere with other functions that also use timers, as well as verification that this doesn't break functions on non-Naze hardware.
I don't think it's going to be too difficult to make an ESC work with it. I can see the software side of it is really simple. I don't know anything about the hardware side of it though.


There's no magic involved. All it does is speed up the timer and sync the ESCs to the loop by sending the PWM code to the ESCs at the end of the loop. All an ESC needs to do is look for the faster timer and do a few things to handle it correctly like keep the last known pulse in mind until the next one comes or shut down if the next one doesn't come after XX time. I'm looking at the BLHeli code now. I'm going to try to "hack" in a OneShot code of my own with a spare BLHeli ESC I have. I think that any fast enough ESC will be capable of running OneShot125 effectively.

The FC is what does the timing. The ESC just needs to run as quickly as possible while a function keeps its eye open for the next command.
Quote:
Originally Posted by nebbian
Yep you're right, there's no magic in getting oneshot into the FC code. I had proof of concept working in a couple of hours. The hardest part were technical issues to do with the CC3D port - that board uses the same timer for motor outputs as it uses for PPM inputs. So when you alter the timebase for the outputs, you also stuff up the system that reads PPM inputs.

Things to bear in mind:
Oneshot125 protocol is exactly 8 times faster than normal pwm, so you should be able to just alter the prescaler to get proper readings
Ensure that the timer that's connected to the input is different to the timer that handles outputs, otherwise you'll have a heck of a job trying to reconcile the two
It would be awesome if your code could autodetect oneshot instead of having to set it manually

From my (and others) experiments, I half suspect that enabling the oneshot jumper on a KISS might do more towards improving performance than just the protocol change. I don't have solid evidence of this, however.

Good luck with this, I'm really interested to hear of your progress.
Quote:
Originally Posted by RS2K
Is the FC starts sending PWM signals of less than 500 ÁS (125 ÁS instead of 1000 ÁS for disarmed) it should be pretty easy to autodetect that. Anything over 600 ÁS can be thrown out to prevent accidental full throttle if the ESC thinks it should be in OneShot125 mode instead of PWM1000 mode.

I wonder what would happen if the only thing I did was alter the prescaler. I'm not sure why "freezing" the last known value is important yet. Maybe it already does that.
Quote:
Originally Posted by waltr
In the ESC, the command pulse (PWM or OneShot) is used to set the next motor speed. The ESC can not act until it has measured the pulse width (time). The advantage to OneShot, being is takes 1/8 the time as a PWM pulse, is that the FC's command happens in the ESC sooner.

The other advantage is the ESC is acting on the new motor speed command before it starts the next control loop (read sensors, read RC input, cal new outputs). With PWM the pulse can be as long as the control loop therefore the control loop is working on a new motor speed before the ESC has acted on the last speed command. This was demonstrated by Final Glide's recent video and just adding OneShot was not a large performance boost, actually it is a bit subtle.

Even though the KISS OneShot spec is receive a pulse and it does not need another pulse for X period of time, this is not the real benefit of OneShot.

In the BLHeli code, after it times the input command pulse, how soon does it change the motor speed.

Another thing to consider.
The performance and stability is greatly improved by just using the KISS ESCs WITHOUT OneShot. Therefore I do not expect any real performance improvement by just adding OneShot to ESCs running BLHeli. To get this performance/stability improvement you really need need a New ESC hardware design. This is really the strength of the KISS ESCs.

Go back to the KISS ESC thread and read the fist few posts that describe the Hardware design.

Quote:
Originally Posted by RS2K
I don't know how much of a difference the hardware makes. That's something I plan on testing. I think the active braking might make the biggest difference of all. I've seen some comparison videos of KISS vs Brand X where Brand X obviously has no active braking.

I think my 250 on 4S and 2204 2300 kv motors will make a great testbed for comparing the two. My hypothesis is that the better hardware will only really allow for higher eRPMs, not higher PIDs. I believe its OneShot125 that allows for the higher PIDs. Assuming both ESCs are capable of running the same motor / battery / prop combination I would expect similar performance from a OneShot125 enabled KISS and a OneShot125 enabled BLHeli ESC. I would imagine the KISS ESCs would be able to run a higher KV motor at a higher voltage though. There's no question the KISS has better performing hardware, what I want to test out is what does that better hardware do?

The BLHeli code's timer2 appears to act independently of the RC Pulse interrupt. I believe that's why it stores the last known RC Pulse for up to 32 ms. If all I do is increase the PWM it's looking for from 1000-2000ÁS to 125-250ÁS that should give me something that pretty much is OneShot125. If it does, I can start testing it. If the tests prove good then it'll be worth adding OneShot125 code to BLHeli properly.

I'm pretty sure this is how the KISS ESCs work. I don't think it's possible to update the motor speed during a motor update cycle. It needs to finish what its doing before acting on the new data. That speed should rely on the PWM rate.
Quote:
Originally Posted by sskaug
Hey guys

I think implementing OneShot in the code (at least for experimental purposes) should be very easy. Just don't divide 1000-2000us down to 0-255 in the input signal, probably just after the "pca_int_fall:" label.

However - on Atmel (non-Afro) ESCs, running may become annoyingly noisy, since the input signal is measured by FW (not strobed by HW). Still should run OK though, BUT more noise.

Also, most small Atmel ESCs have a FET high side driver that is slow to turn on (about 10us). Which limits the braking effect. And IMHO good braking is more important than OneShot.

On a SiLabs ESC with fast drivers, maybe OneShot has a noticeable effect (without artifacts).

Cheers,
Steffen
Last edited by RS2K; Dec 16, 2014 at 11:41 AM.
Dec 16, 2014, 10:54 AM
Registered User
bulesz's Avatar
sbscrbd...
Dec 16, 2014, 11:05 AM
Team AlienWarpSquad
sbscrbd... me too.
Dec 16, 2014, 11:21 AM
Firmware Fiend
The Quasar's Avatar
Wish he we didn't have to move this discussion out of the ZMR250 clubhouse, since there's not much new stuff happening to ZMRs other than different component configurations, but I do enjoy any discussions that deal with electronics since that's my major and what I currently do for work. Let me know how I can contribute. Kudos for taking the initiative to try something that has the potential of advancing the technology within our hobby.
Dec 16, 2014, 12:02 PM
RADIOACTIVE! RADIOACTIVE!
RS2K's Avatar
Quote:
Originally Posted by sskaug
Hey guys

I think implementing OneShot in the code (at least for experimental purposes) should be very easy. Just don't divide 1000-2000us down to 0-255 in the input signal, probably just after the "pca_int_fall:" label.

However - on Atmel (non-Afro) ESCs, running may become annoyingly noisy, since the input signal is measured by FW (not strobed by HW). Still should run OK though, BUT more noise.

Also, most small Atmel ESCs have a FET high side driver that is slow to turn on (about 10us). Which limits the braking effect. And IMHO good braking is more important than OneShot.

On a SiLabs ESC with fast drivers, maybe OneShot has a noticeable effect (without artifacts).

Cheers,
Steffen

Thanks! I think you're right about that. If active braking isn't quick then I doubt OneShot125 will make much of a difference. I'll plan on trying it out.

I notice the SiLabs version of BLHeli uses the label "pca_int_fall" while the Atmel version uses "rcp_int_fall".

The only ESCs I have to test at the moment are:
1. RotorGeeks V4 12A ESCs (Pfets, not sure what chip it has)
2. Turnigy Plush 60A (SiLabs with Fast switching on both low and high)
3. HK BlueSeries 30A (Atmel with Fast switching low and slow switching High side)

I also have some BLHeli Slim 20A ESCs on the way which use Atmel chips and have slow high side switching.

I plan on using the RotorGeeks ESC to test with first. It uses PFETs so I can only really use it to test if the ESC will at least work with the OneShot125 signal. I doubt the OneShot125 will do any good without some form of active braking. I actually think it could make the PIDs difficult to tune if you use OneShot125 on an ESC without active braking.

I think I need to get some Turnigy Plush Nfet 18A ESCs. I think they'll end up being the best BLHeli ESCs to use on a 250 sized quad... though they are heavy.
Last edited by RS2K; Dec 16, 2014 at 12:12 PM.
Dec 16, 2014, 12:02 PM
Registered User
bulesz's Avatar
Same here, I can't understand that crying, because this could make our ZMR even more beast!
Dec 16, 2014, 01:18 PM
Registered User
has anyone tried the xrotor esc's from hobbywing ? they seem to be running a new kind of firmware on the silabs chips other than simonk and blheli.
Dec 16, 2014, 02:02 PM
Team AlienWarpSquad
Nice to put all of this in one thread.
It does look like you were able to gather up all the previous discussions.

will be interesting on how this experiment goes.
Dec 16, 2014, 02:07 PM
RADIOACTIVE! RADIOACTIVE!
RS2K's Avatar
OK. I think this will work.

Removing these three bits of code:

Code:
	mov	A, Temp2
	clr	C
	rrc	A
	mov	Temp2, A
	mov	A, Temp1					
	rrc	A
	mov	Temp1, A
after the label "pca_int_fall" should have the effect of multiplying the PPM signal by 8.


It looks like Temp 1 is Rcp_Prev_Edge_L and Temp 2 is Rcp_Prev_Edge_H and they get divided in half 3 times by the "rrc A" instruction.


It looks like the RC Pulse is calculated from timestamps set when the RC pulse is either high or low. There don't seem to be any sanity checks until after the pca_int_fall label which is why not dividing the signal should work.
Last edited by RS2K; Dec 16, 2014 at 02:18 PM.
Dec 16, 2014, 02:28 PM
RADIOACTIVE! RADIOACTIVE!
RS2K's Avatar
I'm not sure which hex file to use on the Rotorgeek V4 ESCs. I'm checking now. If I can't figure it out before too long I'll just flash the Turnigy Plush I have.


Edit:
Looks like Skywalker 40A is loaded on it now... which seems odd to me. It looks like a Skywalker 12A. / Turnigy Plush 12.
Last edited by RS2K; Dec 16, 2014 at 04:17 PM.
Dec 16, 2014, 04:15 PM
RADIOACTIVE! RADIOACTIVE!
RS2K's Avatar
I compiled the new hex files and will be testing the changes later tonight.
Dec 16, 2014, 04:20 PM
The Blacksite Dev
The_DoGMaN's Avatar
I will be interested to hear what you find.
Dec 16, 2014, 04:24 PM
Micro Quad Flyer
QuadBert's Avatar
Is braking worth turning on in BLHeli on something like the EMAX esc? I've never used it, but combined with oneshot think it would help? Or do you think the braking would be too slow, and do more harm than good?
Dec 16, 2014, 04:44 PM
Firmware Fiend
The Quasar's Avatar
Quote:
Originally Posted by RS2K
I'm not sure which hex file to use on the Rotorgeek V4 ESCs. I'm checking now. If I can't figure it out before too long I'll just flash the Turnigy Plush I have.


Edit:
Looks like Skywalker 40A is loaded on it now... which seems odd to me. It looks like a Skywalker 12A. / Turnigy Plush 12.
It's possible that dklein uses the 40A hex file since he uses upgraded FETs among his improvements to his hardware.