Flashing Turnigy Plush(SiLabs) success, now with tutorial! - Page 4 - RC Groups
Thread Tools
Sep 30, 2012, 09:12 AM
Registered User
Thanks for the responses guys. Probably won't get to it until later in the week. Got my 23rd Anniversary today and then will be out of town on business this week. But I intend to reflash all the ESCs clean, set the beep stength to 128, low limit to 1000, high limit to 2000, and TX programming off. Sound like a plan?

Figured I start clean since I attempted to calibrate all the ESCs through the FC. If I still have issues I can easily set the PWM range of the FC smaller. Just thought I'd try for max resolution.....
Sign up now
to remove ads between posts
Sep 30, 2012, 02:25 PM
Registered User
Quote:
Originally Posted by jihlein
Thanks for the responses guys. Probably won't get to it until later in the week. Got my 23rd Anniversary today and then will be out of town on business this week. But I intend to reflash all the ESCs clean, set the beep stength to 128, low limit to 1000, high limit to 2000, and TX programming off. Sound like a plan?

Figured I start clean since I attempted to calibrate all the ESCs through the FC. If I still have issues I can easily set the PWM range of the FC smaller. Just thought I'd try for max resolution.....
Should be a good plan. I have tested throttle calibration with a signal that has max at 2100us and min at 900us. Works fine, result is set at 1000us to 2000us, which is the limit.
I have also gone into a deep code exploration and found a bug that may cause unpredictable behaviour. It is the "clear carry" curse of assembly, a place where carry was not cleared (when doing throttle calibration) before an add with carry operation. PM me your email address if you are interested in (and have time for) a test code
Sep 30, 2012, 07:26 PM
vimeo.com/bruno222
bruno222's Avatar
Hello sskaug!

Great work that you have done, thank you so much! My Tricopter videos at FPV are now much better!

The only thing that I can suggest is to allow “Low Voltage Limit” to 2.85V. I have Turnigy Plush 18A and the original firmware was allowed to have 2.85V limit voltage. On your firmware, the minimum Low Voltage Limit is 3.0V – Now I have 9 mins of flight time, against the original firmware that was giving me 10 mins.

Cheers my friend!
Sep 30, 2012, 08:03 PM
Emress
uhh ~3.0v is considered to be the bare minimum for good battery life... ~2.7 or so is the severe permanent damage area. get some more packs and dont go that low..
Sep 30, 2012, 11:47 PM
vimeo.com/bruno222
bruno222's Avatar
Well, I don't have OSD to check mAh, so I always try to have a flight limit arround 8 minutes to never get battery lower than 3.0v... But sometimes, in rare cases, when I forgot and go forward next to 10 mins of flight, I prefer save my Tricopter and landing save killing the battery life a bit....

With 3.0v voltage limit, I just fell down in the floor quickly, because it's always just one of tree ESC that detects this low voltage and only ONE motor slows down, it's bad. So for me, Voltage limit is bad because it is just a protection for the batery and not for all Tricopter parts.
Oct 01, 2012, 01:08 PM
Registered User
Quote:
Originally Posted by bruno222
Well, I don't have OSD to check mAh, so I always try to have a flight limit arround 8 minutes to never get battery lower than 3.0v... But sometimes, in rare cases, when I forgot and go forward next to 10 mins of flight, I prefer save my Tricopter and landing save killing the battery life a bit....

With 3.0v voltage limit, I just fell down in the floor quickly, because it's always just one of tree ESC that detects this low voltage and only ONE motor slows down, it's bad. So for me, Voltage limit is bad because it is just a protection for the batery and not for all Tricopter parts.
Basically I agree with Sirbow2, batteries should not be run that low, it will severely reduce their life. I do not fly multi (yet), but when I fly my helis, I set the timer so that batteries are at least 3.7V when done.

Glad you find the ESCs performing well
If you want to maximize flight time, you might be better off using low pwm frequency. Also, lower commutation timing is generally more efficient than high (just make sure you do not get into demag issues).

And if you do not want LVC, use the tail code Just choose direct startup and set idle speed to zero, and it should perform like multi without LVC.
Edit: And change pwm frequency from damped light to high frequency
Last edited by sskaug; Oct 02, 2012 at 03:26 PM.
Oct 06, 2012, 09:18 AM
Registered User

Plush 25A hexa with BLheli rev7.0


Attached video of Plush 25A BLheli rev 7.0 arducopter hexa.
Plenty of wind, but smooth flying.
Great work. Thanks.

APM 2.0, BLHeli Plush 25 rev 7.0 testing (3 min 46 sec)
Oct 06, 2012, 12:33 PM
Registered User
Quote:
Originally Posted by kaakku
Attached video of Plush 25A BLheli rev 7.0 arducopter hexa.
Plenty of wind, but smooth flying.
Great work.
Great video! And good music
Thanks!
-S
Oct 11, 2012, 10:35 PM
Registered User
Just flashed my Turnigy 25 AE using CRIUS MultiWII



Oct 12, 2012, 01:56 PM
Emress
hah good use of your FC: go MWC! why does it say rev 4.1? and you should use 7.0 as it lets you change the throttle range.
Oct 12, 2012, 11:04 PM
Registered User
Quote:
Originally Posted by sirbow2
hah good use of your FC: go MWC! why does it say rev 4.1? and you should use 7.0 as it lets you change the throttle range.
Thanks for pointing it out. I see no MULTI if I use 7.0. Is there a difference between MULTI, MAIN and Tail?
Oct 12, 2012, 11:19 PM
Emress
main is for main heli blades, tail for heli tail motor and MULTI for multi rotors (use this one )

you can download the latest from github, or maybe you have a old blehitool version.
Oct 13, 2012, 01:35 AM
OlliW
the BLHeli hex file for rev 7.0 multi is included in the latest version of the owsilprog zip file (http://www.olliw.eu/2012/owsilprog-tutorials/), and you would only have to select "Rev 7.0" in the "Revision" field on the flash tab

you should use rev 7.0 not only becasue of the adjustable thro range but also becasue of many internal improvements which make it much better for multicopters
Oct 13, 2012, 03:23 AM
Registered User
Quote:
Originally Posted by OlliW
the BLHeli hex file for rev 7.0 multi is included in the latest version of the owsilprog zip file (http://www.olliw.eu/2012/owsilprog-tutorials/), and you would only have to select "Rev 7.0" in the "Revision" field on the flash tab

you should use rev 7.0 not only becasue of the adjustable thro range but also becasue of many internal improvements which make it much better for multicopters
Thank you Olliw for all your time and effort in developing these products. :thumbup:

Over the stock Plush firmware, Revision 7 has transformed my twitchy micro-quad into a very stable and enjoyable night flier.

With the programmable throttle ranges and numerous other improvements, revision 7 is a must have for any pilot serious about stabilizing their quad.

Well done! :beer:
Oct 15, 2012, 12:28 PM
Registered User
BLHeli Rev8.0 has now been posted on github: https://github.com/bitdump/BLHeli/tree/master/SiLabs

The changes are focused towards multirotor performance:
- Added a 2 second delay after power up, to wait for receiver initialization
- Added a programming option for disabling low voltage limit, and made it default for MULTI
- Added programable demag compensation, using the concept of SimonK
- Improved robustness against noisy input signal
- Refined direct startup
- Removed voltage compensation
- Miscellaneous other changes

And a lot of escs have been added:
- RCTimer 6A ESC / RCX 6A
- Turnigy AE45 ESC
- Turnigy Plush 40/60/80A
- Origin/Oversky/HK ESCs
- Hobbywing Skywalker 40A sbec

Of particular interest to multirotors, is the demag compensation. I have tested it with a DT750 motor running 4S. Without demag compensation at medium timing it stutters even at fairly low throttle. With high timing it is close to acceptable, but with demag compensation, it just runs smooth even for the most abrupt throttle increase.

Cheers,
Steffen
Oct 17, 2012, 05:16 AM
OlliW

owSilProg BLHeliTool BLHeliBox release v20121017


Hey Folks,

new release of the owSilProg project
download v20121017 here: http://www.olliw.eu/2012/owsilprog/#firmware

main changes:
- support of BLHeli Rev8.0
- menu in BLHeliTool separated into Setup Main and Setup Advanced for better handling
- window height of in BLHeliTool restricted to be suitable for ebooks
- AvrBurnTool adapted to handle Arduino Mega 2560 boards accroding to copperclad @ helifreak (link)

all tutorials are available now (building owSilProg programmer, using BLHeliTool, building BLHeliBox, + sources of supply)
see here: http://www.olliw.eu/2012/owsilprog-tutorials/

Have fun, Olli
Oct 17, 2012, 05:10 PM
MavLab coordinator

I2C compatible?


Hello world,

I was wondering if the SiLabs esc's can be modified from pwm to I2C Input?
Can the BLheli firmeware cope with I2C input.

Thanks in advance,

Microuav
Oct 17, 2012, 06:14 PM
we dont NEED roads!
AcroFPV's Avatar
Quote:
Originally Posted by OlliW
Hey Folks,

new release of the owSilProg project
download v20121017 here: http://www.olliw.eu/2012/owsilprog/#firmware

main changes:
- support of BLHeli Rev8.0
- menu in BLHeliTool separated into Setup Main and Setup Advanced for better handling
- window height of in BLHeliTool restricted to be suitable for ebooks
- AvrBurnTool adapted to handle Arduino Mega 2560 boards accroding to copperclad @ helifreak (link)

all tutorials are available now (building owSilProg programmer, using BLHeliTool, building BLHeliBox, + sources of supply)
see here: http://www.olliw.eu/2012/owsilprog-tutorials/

Have fun, Olli
Is it possible to do this flash with a USBAVR Programmer? The type I use to Flash my KK2 board?
Oct 18, 2012, 12:59 AM
OlliW
Quote:
Is it possible to do this flash with a USBAVR Programmer? The type I use to Flash my KK2 board?
no...
but you can use your kk board for flashing the esc...
Oct 18, 2012, 01:51 AM
Registered User
Quote:
Originally Posted by bartremes
Hello world,

I was wondering if the SiLabs esc's can be modified from pwm to I2C Input?
Can the BLheli firmeware cope with I2C input.

Thanks in advance,

Microuav
BLHeli currently does not support I2C input. Are there any advantages to I2C over pwm?
Oct 18, 2012, 02:10 AM
Registered User
Quote:
Originally Posted by OlliW
no...
but you can use your kk board for flashing the esc...
That's interesting... makes sense tho... could a spare KK2 be used as a preassembled programming box?
Oct 18, 2012, 02:23 AM
OlliW
Quote:
Are there any advantages to I2C over pwm?
faster... technically...

... but who really (really!) needs update rates faster than 1ms? The intrinsic time constant of copters is typically on the order of 0.1s, a golden rule of controller theory says about 20 times faster than the intrinsic time, so 1ms should be a quite sufficient number for the large majority of applications...
Quote:
could a spare KK2 be used as a preassembled programming box?
yes... with the right firmware...
(I suggested to HK to produce a similar item without the DOF stuff, which would make it a cute little versatile programming box... but they haven't answered... at least yet... )
Oct 18, 2012, 04:36 AM
MavLab coordinator
Quote:
Originally Posted by sskaug
BLHeli currently does not support I2C input. Are there any advantages to I2C over pwm?
The reason I ask:
I m making a small autonomous quad based on this paparazzi autopilot.
http://paparazzi.enac.fr/wiki/NavGo_v3

The esc's can only be controlled by I2C.
I orderd the atmega8 esc 6 amp
http://www.hobbyking.com/hobbyking/s...dProduct=21246
And flashed them with Simonk. The problem is there are not enough ADC Ports available.

So I orderd the SiLabs variant
http://www.hobbyking.com/hobbyking/s...ontroller.html
But I have no idea if they can be modified to I2C.

So the basic question is: are there small esc 's (6 to 10 amp) who have I2C input instead of pwm so I do not have to use This havvy ( vor small quads) board.
http://abusemark.com/store/index.php...&products_id=3

Thanks microuav
Oct 19, 2012, 09:54 AM
IAD
IAD
UAV Driver
IAD's Avatar
Quote:
Originally Posted by bartremes
The reason I ask:
I m making a small autonomous quad based on this paparazzi autopilot.
http://paparazzi.enac.fr/wiki/NavGo_v3
...
I'm basically in the same boat. I'm going to try the I2C-->PWM converter for now, but my understanding is that it does introduce some latency.

-Luke
Oct 19, 2012, 09:54 AM
Registered User
Hi i have Arrowind 25A with Silabs, any body now the making of them and if there are som hexfile to flash for a quad
Anders
Oct 19, 2012, 12:29 PM
Registered User
Quote:
Originally Posted by vilhelmsson
Hi i have Arrowind 25A with Silabs, any body now the making of them and if there are som hexfile to flash for a quad
Anders
Just looked at the Arrowind website. And the ESCs look very much like the XP series ESCs. You could look at the PCB and compare it with these: https://github.com/bitdump/BLHeli/bl...abs%20ESCs.pdf
I'd be surprised if it is not identical to the XP 25A (ie just sold under another name).
Oct 19, 2012, 02:56 PM
Registered User
Hello,

I recently bought HobbyWing SkyWalker Quattro (20Ax4) and found out that they are C8051F330 based all N-FET ESCs. Each of four ESCs is powered from the single onboard BEC, but you may consider each ESC as independend one. I believe you will find flash pads designations pretty familiar. Please refer to photos here: http://drug123.org.ua/skywalker_quattro/

I've tried to flash ESC with BLHeliTool (c) OlliW @ www.olliw.eu from 16. October 2012 v0.07 with BLHeliHexFiles\SKYWALKER_20A_MULTI_REV8_0.HEX firmware. I have got the following output in the tool:
Flash hex file... Please wait!
delay... OK
v... OlliW SilProg v0.08 PB3PB4
r... rok
d... dok0A -> Device ID 0A F33x
i... iok
e... Device erase FAILED!

When I hit Verify button, the following error is reported:
Verify... Please wait!
delay... OK
v... OlliW SilProg v0.08 PB3PB4
r... rok
d... dok0A -> Device ID 0A F33x
i... iok
.Block read FAILED!

I'm not experienced with 8085 programming but believe there is some lock bit is set. Could you please advise if this could be worked around somehow. I asked Steffen first, but he advised go here to ask...

Thanks.

PS: I consider a chip replacement if nothing will help.
PPS: I have used Arduino Decimilia with owsilprog_v008_m168_16mhz_pb3pb4.hex firmware as flasher.
Last edited by drug123; Oct 19, 2012 at 03:07 PM.
Oct 19, 2012, 03:26 PM
OlliW
Hey Drug,

I actually got last week (for the first time since I started this project several months ago) a similar error behavior after I had flashed my BESC with a F330x chip with a firmware for a F31x chip. Didn't yet had time to figure out what exactly did happen (and somehow thought/hoped it to be a fluke). Although you obviously didn't made this mistake, my proceduer to resolve this might nevertheless work for you too.
(at first, however, you might wish to try hitting Flash a couple of times)

It's somewhat strange, but I did the following. I started the terminal program BrayTerminal.exe (it's included in the owsilprog zip package, and you also can call it from BLHeliTool if you go to the tools menu). You have to set 38400 bps, 8 data bits, no parity, 1 stop bit, no handshaking (should be the default setting), and of course you have to select the correct com port. You then hit the Connect button. At the bottom there is a white input textline, where you can enter commands and can send them by either hitting the send button or the return key. Now do the following. Press the reset button on the Arduino. Then type in "v" and send (type just the v without quotation marks). You should see the message "OlliW SilProg v0.08 PB3PB4" appearing in the recieve window. Now enter "r" and send, you should see "rok", now enter "d" and send, you should see "dok0A", enter "i" and send, you should see "iok", enter "e" and send, you should see "eok". At some point probably an error occurs. If so press the reset button on the Arduino. and enter "r" "i" "e", maybe send some cmd twice or three or four or five times in some arbitrarywild way, but always in the sequence r i e, and if an error occurs reset and start with r again. In my case sudddenly by some reasons I got "eok" and since then everything was working again perfectly (and is still working).

It's kind of strange that this error suddenly occures to you and me... I never had it before, and I have not changed anything in this part of the code since v0.04...

Anyhow, we will solve this, I am sure you don't have to replace the mcus.
Oct 19, 2012, 04:35 PM
Registered User
Quote:
Originally Posted by OlliW
(at first, however, you might wish to try hitting Flash a couple of times)
Hello OlliW, thanks for your fast reply! Actually I hit Flash button MANY times before deciding to bother you ;o) Unfortunately result always the same.

Quote:
Originally Posted by OlliW
It's somewhat strange, but I did the following. I started the terminal program BrayTerminal.exe
{skip}
enter "e" and send, you should see "eok". At some point probably an error occurs. If so press the reset button on the Arduino. and enter "r" "i" "e", maybe send some cmd twice or three or four or five times in some arbitrarywild way, but always in the sequence r i e, and if an error occurs reset and start with r again. In my case sudddenly by some reasons I got "eok" and since then everything was working again perfectly (and is still working).
Actually I tried this as well. Unfortunately after sending "e" command Arduino hangs until next reset happened. In terminal it looks like
Code:
OlliW SilProg v0.08 PB3PB4>rok>iok>e
(In response to 'vrie')
This happens constantly. I didn't get any other reaction from the board. BTW to exclude possible defects in my Arduino, I tried to use my ATMega328P based MultiWii board with owsilprog_v008_m328p_16mhz_pb3pb4.hex and got the same result.

Quote:
Originally Posted by OlliW
It's kind of strange that this error suddenly occures to you and me... I never had it before, and I have not changed anything in this part of the code since v0.04...

Anyhow, we will solve this, I am sure you don't have to replace the mcus.
Any other your guesses what to try next are welcome, because I'm not sure I could do any better by myself.
Oct 19, 2012, 05:22 PM
Registered User
BTW, if it could help a bit, here is my setup: https://picasaweb.google.com/lh/phot...eat=directlink
Oct 19, 2012, 07:10 PM
Registered User
Thnx sskaug, spot on :-)
Oct 19, 2012, 10:28 PM
OlliW
Hey Drug,

that's really wiered, and I am running out of ideas.

Quote:
Actually I tried this as well. Unfortunately after sending "e" command Arduino hangs until next reset happened. In terminal it looks like
OlliW SilProg v0.08 PB3PB4>rok>iok>e
(In response to 'vrie')
have you also tried something like r i i i r r r r i i d d d r r r i i i i i i i e....

I scanned the web and the only thing I could find are comments like
Quote:
The F5xx is very sensitive to EMI. We had the same problems with the F580 and actual also the F554. Especially if you can program the controller only one time, the code is still running and you cannot reconnect:
In your source code you are setting the oscillator may be to 24MHz. EMI at VDD appears after the first RESET because the core now needs much more current. You need a very good scope to see the spikes. The next try to connect C2 fails.
...
If nothing helps, you may have shot the clamp diodes of the C2 terminals.

Capacitors close to the terminals
ceramicCapacitors between Vdd and gnd very close to the pins (<5mm) in parallel with tantalums.
To show the significance:
Not this chip, I have never used it, but with another the i... ehh.. person that laid out the board had about a 2cm trace to the Vdd decoupling cap, to make the board work reliably we had to solder another decoupling cap dirctly across the chip.
...
see if soldering a, say, 10nF ceramic across the chip Vdd to Gnd cures the problem. BTW if your chip is one of those with a built-in LDO then you need the direct cap both for Vin and Vout of the LDO.
...
if you do not have .1uF ceramic parallel with 10uF tantalum on Vcc all bets are off
not the same chip we have here but... who knows...

maybe you could try shorter wires between Uno and BESC (admittedly a desperate suggestion)

sorry for having no better response, I guess I was a bit too optimistic
Oct 20, 2012, 03:01 PM
Registered User
Quote:
Originally Posted by OlliW
Hey Drug,

that's really wiered, and I am running out of ideas.
Hello again,

Today I bought 4 brand new C8051F330 (luckily local parts distributor have them in stock for around US$2/pcs) and replaced IC in the ESC. All chips started to respond and I flashed all of them successfully. Problem is, it seems that one of the chips weren't soldered well, motor didn't start, just beeped. I was fool enough to put more throttle and one of MOSFETs blown up. So I have now more work to do thanks to my stupidity. This issue is not related to FW because two other motors were OK, and fourth did not respond at all.

But here we could make a conclusion that there is something in firmware what prevents chip re-flashing. I already heard that some newly purchased ESC from hobbyking have same issue. Not sure which one of them exactly but this is what I heard from friends. I suppose we need to find solution for this issue somehow. If you want, I could send you the chip for investigation. I could propose same for Steffen, if he reads this thread - I have 4 chips desoldered from PCB.
Oct 20, 2012, 05:42 PM
Registered User
Quote:
Originally Posted by drug123
Hello again,

Today I bought 4 brand new C8051F330 (luckily local parts distributor have them in stock for around US$2/pcs) and replaced IC in the ESC. All chips started to respond and I flashed all of them successfully. Problem is, it seems that one of the chips weren't soldered well, motor didn't start, just beeped. I was fool enough to put more throttle and one of MOSFETs blown up. So I have now more work to do thanks to my stupidity. This issue is not related to FW because two other motors were OK, and fourth did not respond at all.

But here we could make a conclusion that there is something in firmware what prevents chip re-flashing. I already heard that some newly purchased ESC from hobbyking have same issue. Not sure which one of them exactly but this is what I heard from friends. I suppose we need to find solution for this issue somehow. If you want, I could send you the chip for investigation. I could propose same for Steffen, if he reads this thread - I have 4 chips desoldered from PCB.
Wow, I'm impressed! Getting new chips and replacing them just like that. I've never heard of SiLabs chips being locked, in fact I have not seen any info at all on that in the datasheet. Atmel chips can be locked though. But I remember Liftbag reported some problems similar to yours some time ago in the "BLHeli for SiLabs" thread. The chips were not locked, but I do not remember what it came down to then. I'll have to check.
Not sure I can do much checking on the chips, first of all I do not have the equipment to solder them onto a board . And secondly I do not control the interface to the chip. Olli or 4712 would probably be the most capable.
Oct 20, 2012, 06:22 PM
Registered User
Quote:
Originally Posted by sskaug
Wow, I'm impressed! Getting new chips and replacing them just like that. I've never heard of SiLabs chips being locked, in fact I have not seen any info at all on that in the datasheet. Atmel chips can be locked though. But I remember Liftbag reported some problems similar to yours some time ago in the "BLHeli for SiLabs" thread. The chips were not locked, but I do not remember what it came down to then. I'll have to check.
Not sure I can do much checking on the chips, first of all I do not have the equipment to solder them onto a board . And secondly I do not control the interface to the chip. Olli or 4712 would probably be the most capable.
Steffen, thanks for your reply. Believe me, chip replacement is much simplier work comparing to producing decent piece of code I know that as former software developer, so I know what i'm saing

OK, let's wait for Olli and 4712 - if anybody will be interested, I gladly provide the chip.
Oct 21, 2012, 05:28 AM
OlliW
wau, I am impressed too...

I am actually puzzled by your finding. The data sheet is VERY clear that you should always be able to do a complete chip erase (if the communication works properly). The only thing I found on the Inet is the sort of problems I cited in the above, that an improper hardware environment can make the chip flashable only once.

Have you tried to reflash your newly installed chips?

In general however I have really no clue what's going on. I only can speculate. Sometimes chip manufactures provide their customers preprogrammed chips, which then can't be read/erased by the standard methods. Also, maybe HobbyWing wanted going cheap and used b-grade chips. Sometimes you find F334 chips which somehow have been hacked to work as F330 chips, but who knows what other side effects this hacking might have. As I said, just wild speculations...

As regards sending me some chips, I feel a bit like Steffen. I mean, I do not have any diagnostic methods/capabilities beyond those you obvioulsy have yourself. One thing to do would be to connect your chips to a programmer and see if they work or not, but that's something you obviously can do yourself. I am also not sure if the issue is just with the chips and not partly also with the hardware environment provided on the BESC. I don't have a testbed, so far the only thing I did myself is to flash a XP-3A... so, your suggestion makes sense but unfortunately I wouldn't know what I could/should do to tackle the problem...

Anyhow, it's good that you could solve the issue for your case... and may be getting airborne soon...
Oct 21, 2012, 10:56 AM
Registered User
Quote:
Originally Posted by OlliW
wau, I am impressed too...
Guys, you really make me shy ;o))

Quote:
Originally Posted by OlliW
I am actually puzzled by your finding. The data sheet is VERY clear that you should always be able to do a complete chip erase (if the communication works properly). The only thing I found on the Inet is the sort of problems I cited in the above, that an improper hardware environment can make the chip flashable only once.

Have you tried to reflash your newly installed chips?
Yes, I tried and succeeded. Not sure if it's the same - I had written settings to the chip as well.

Quote:
Originally Posted by OlliW
In general however I have really no clue what's going on. I only can speculate. Sometimes chip manufactures provide their customers preprogrammed chips, which then can't be read/erased by the standard methods. Also, maybe HobbyWing wanted going cheap and used b-grade chips. Sometimes you find F334 chips which somehow have been hacked to work as F330 chips, but who knows what other side effects this hacking might have. As I said, just wild speculations...
I got your point. It could be anything. But for me most strange thing is that chip normally responds when I'm requesting chip ID. It seems it correctly responds with F330 ID meaning that C2 actually is working.

Quote:
Originally Posted by OlliW
As regards sending me some chips, I feel a bit like Steffen. I mean, I do not have any diagnostic methods/capabilities beyond those you obvioulsy have yourself. One thing to do would be to connect your chips to a programmer and see if they work or not, but that's something you obviously can do yourself. I am also not sure if the issue is just with the chips and not partly also with the hardware environment provided on the BESC. I don't have a testbed, so far the only thing I did myself is to flash a XP-3A... so, your suggestion makes sense but unfortunately I wouldn't know what I could/should do to tackle the problem...
My point was you have more understanding of the protocol, because I have no experience with C2 at all. The only thing I really suppose to try is just make some testbed PCB, just to see whether C2 started working. If not, I really doubt that I will overcome you in protocol exploration.

Quote:
Originally Posted by OlliW
Anyhow, it's good that you could solve the issue for your case... and may be getting airborne soon...
Actually I successfully replaced two MOSFETs and motors are starting normally now. So my birdie definitelly will fly in a week upon my returning from business trip )
Oct 21, 2012, 03:35 PM
Registered User
Quote:
Originally Posted by fnodado
Just flashed my Turnigy 25 AE using CRIUS MultiWII



hi fnodado
I have a turnigy plush 30a. "CRIUS se" How will the connections. Pin

thanks
Last edited by seco3332003; Oct 23, 2012 at 08:05 AM.
Oct 21, 2012, 07:14 PM
Registered User
Hope this is the correct place for this question about start-up parameters. I need help with how to adjust start-up parameters for my Turnigy 30A plush escs flashed with V8.0 running NTM 2830 motors. After some tuning I have them flying great with one exception. If I raise the throttle quickly from an off position the motors do not start but just stutter. If I raise the throttle slowly at first the motors start up fine. Which settings would help with this initial start-up behavior?

Thanks
Oct 22, 2012, 01:41 AM
Registered User
Quote:
Originally Posted by BounceOnce
Hope this is the correct place for this question about start-up parameters. I need help with how to adjust start-up parameters for my Turnigy 30A plush escs flashed with V8.0 running NTM 2830 motors. After some tuning I have them flying great with one exception. If I raise the throttle quickly from an off position the motors do not start but just stutter. If I raise the throttle slowly at first the motors start up fine. Which settings would help with this initial start-up behavior?

Thanks
Hmm.. starting any and every motor perfectly is challenging. I have four motors 750kV to 2200kV that are tested on 2S to 4S and they start well.
The only parameter that affects direct startup, is startup power, that during direct start sets the maximum allowed power. Reducing it might help in your case.
Oct 22, 2012, 01:53 AM
Registered User
+1 with troubles at startup with some motors. Especially HXT 10g 2000KV outrunner. It has quite high locking effect of magnets, and tend to stutter instead of turning.
I have reflashed Supermicro 3.5 for this reason, using arduino nano and owsilprog, everythng works like a charm at the first attempt. Version 8 Multi but I have tried even Main with no advance.
..Any values I did try for startup, did not result in clean start. Direct mode do not move at all, Stepped mode is much better but really stepping over sharp steps initialy.
Yes I understand that it may be special kind of outrunner.. but using atmega version ESC e.g. Plush10 (even with original firmware) starts it up perfectly.. Reflashed it can perfectly go even forward/backward without troubles using car mode firmware (by the way, does CAR mode exist for Silabs ESC? I found nothing..)
Perhaps Supermicro 3.5 is way too weak? But, for 10g motor, I expected that it should suffice.

By the way, is there a copy of original firmware of silabs esc's somewhere? It was not possible to read and I am considering drawback to original. If You would be so kind to point me to download.
Last edited by coro; Oct 22, 2012 at 01:58 AM.
Oct 22, 2012, 02:08 PM
Registered User
Quote:
Originally Posted by coro
+1 with troubles at startup with some motors. Especially HXT 10g 2000KV outrunner. It has quite high locking effect of magnets, and tend to stutter instead of turning.
I have reflashed Supermicro 3.5 for this reason, using arduino nano and owsilprog, everythng works like a charm at the first attempt. Version 8 Multi but I have tried even Main with no advance.
..Any values I did try for startup, did not result in clean start. Direct mode do not move at all, Stepped mode is much better but really stepping over sharp steps initialy.
Yes I understand that it may be special kind of outrunner.. but using atmega version ESC e.g. Plush10 (even with original firmware) starts it up perfectly.. Reflashed it can perfectly go even forward/backward without troubles using car mode firmware (by the way, does CAR mode exist for Silabs ESC? I found nothing..)
Perhaps Supermicro 3.5 is way too weak? But, for 10g motor, I expected that it should suffice.

By the way, is there a copy of original firmware of silabs esc's somewhere? It was not possible to read and I am considering drawback to original. If You would be so kind to point me to download.
To my knowledge there does not exist any original code for any SiLabs ESCs
I have now tested my Hacker A10 2200kV that has high cogging ("locking effect") on an XP 3A (similar to the supermicro) on 1S. And as you say, it does not start properly. Earlier it was tested on 2S without problems.
Also I have looked for code improvements . And by doing some simple changes, like extending the "keep out" zone for the comparator around the pwm switching, it now starts well. Looks promising .
Oct 23, 2012, 05:53 AM
Registered User
Flashed my Plush 25As that are running with SunnySky X2216 880kvs. Getting "cogging" if I full throttle when motors are still and also grinding in low throttle. It's a lot smoother in the air but also less control, like the stick scaling has been set down. Also my motors sound different now. They sound "grainy" like there's sand or something in there. But it should be OK if they don't get hot or smell, right?

Keep up the good work sskaug and OlliW
Oct 23, 2012, 10:00 AM
Registered User
Quote:
Originally Posted by ElectroDie
Flashed my Plush 25As that are running with SunnySky X2216 880kvs. Getting "cogging" if I full throttle when motors are still and also grinding in low throttle. It's a lot smoother in the air but also less control, like the stick scaling has been set down. Also my motors sound different now. They sound "grainy" like there's sand or something in there. But it should be OK if they don't get hot or smell, right?

Keep up the good work sskaug and OlliW
Thanks! I will work on the stutter for a full throttle start. Should be possible to improve.
I have also heard the "grainy" sound on some motors particularly when running at low throttle. I believe this is because of the interrupt timing of the MCU. Sometimes interrupt execution causes a longer time between pwm on and pwm off, leaving the motor current on for a slightly longer time. This slightly longer pwm on time at random intervals causes the sound. More on some motors than on others. It should have no practical impact on motor or ESC life. It's just the nuisance of the sound if you listen for it
I do not know why you have the stick "scaled down". Maybe this has to do with throttle range/calibration?
Oct 23, 2012, 06:47 PM
Registered User
Quote:
Originally Posted by drug123
Steffen, thanks for your reply. Believe me, chip replacement is much simplier work comparing to producing decent piece of code I know that as former software developer, so I know what i'm saing

OK, let's wait for Olli and 4712 - if anybody will be interested, I gladly provide the chip.
Yes, chip replacement isn't sooo difficult. But I wouldn't call it "fun" and the chips are too expensive here...

Would be nice to have the chip..
But, I think most people have problems with the solder connections or the cable length, which is really critical with the Toolstick. Interfacing with a rebuild ATMega C2 Interface is much more robust with the long line length. I tried it with more the a half meter - no problems. That is very astonishing. But one should keep in mind, that the toolstick can do a lot more, which is not needed for simply flashing a firmware.
A theme which fit in here perfectly is, that you cannot read the lockbyte with the rebuild C2, but you can read it with the toolstick, even if tockbyte is set to 0, which locks the chip completely. The miracle here is, that the manual says, that one cannot read the lock byte over the C2 interface, if any part of the memory is locked - But the Tollstick can and the debug adapter (Oversky /RC-Hawk) as well. So I'm wondering what else is possible with the Toolstick.... or what undocumented functions are hidden in the C2 interface.

BTW: silabs-c2-interface-debugging-code
Oct 24, 2012, 06:12 AM
Registered User
Quote:
Originally Posted by sskaug
I do not know why you have the stick "scaled down". Maybe this has to do with throttle range/calibration?
Flew it today with less wind and seemed better, so I guess it was the high wind. I did also calibrate the ESCs again so maybe I had my radio setup different from last calibration. In any event it doesn't matter I can just change the stick scaling in KK 2.0.

Also forgot to mention that after I flashed all my motors rotation got reversed which is interesting.
Oct 24, 2012, 09:56 AM
Registered User
hi guys

I tried to do the installation with Cruise SE. but I got the same error, could you help me?

Turnıgy plush 30A ESC


Oct 24, 2012, 10:35 AM
Registered User
hello !

first thanks a lot for a tutorial !

I bought my Plush 60A in july 2011, are they supposed to be if they are Amtel or SiLabs ?
And once I cut the heatshrink, how can I tell for sure ?

Alain
Oct 24, 2012, 11:23 AM
OlliW
Hey Seco,

sh.... although I don't see what serious I could have changed while progressing from BLHeliTool v0.06 to v0.07 this sudden multiple occurence of this error makes me wondering if I have not actually made a stupid mistake somewhere which I am just to blind to realize...

Could you do me a favor? Could you download the previous firmware package owSilProg BLHeliTool BLHeliBox v20120921c.zip and try BLHeliTool v0.06? (download here and extract in a fresh folder)
You can't use then BLHeli Rev8.0, so please choose BLHeli Rev7.0, but the purpose of this test is to see if the older version doesn't have this issue.
This would be very helpful.

BTW: I am actually a bit puzzled by the screenshots. (1) In the first screen shot you loaded the oSilProg v0.08 hex file, while in the second screen shot it reports beeing a BLHeliBox... how does this come? (you are apparently not using a BlHeliBox...) (2) The flash has worked but not the verify? Or haven't you done a Flash before?

EDIT: ÄHM, Seco... I haven't looked at it before... your setup looks VERY dangerous... you are powering the ESC backwards through the FC board via the USB???? I think you definitely should have a lipo plugged to your ESC and remove the black-red-white servo cable from your FC unit! Try this first.

Hey Alain,
I am not familiar with the Plush 60A it is listed in TomSn0ws spreadsheet as beeing Silabs... however, if you cut it open you can tell for sure by looking at how the MCU chip looks like. If you are not sure just post photos.
Last edited by OlliW; Oct 24, 2012 at 12:18 PM.
Oct 24, 2012, 05:42 PM
Registered User
[QUOTE=OlliW;23087721]Hey Seco,

sh.... although I don't see what serious I could have changed while progressing from BLHeliTool v0.06 to v0.07 this sudden multiple occurence of this error makes me wondering if I have not actually made a stupid mistake somewhere which I am just to blind to realize...

Could you do me a favor? Could you download the previous firmware package owSilProg BLHeliTool BLHeliBox v20120921c.zip and try BLHeliTool v0.06? (download here and extract in a fresh folder)
You can't use then BLHeli Rev8.0, so please choose BLHeli Rev7.0, but the purpose of this test is to see if the older version doesn't have this issue.
This would be very helpful.

BTW: I am actually a bit puzzled by the screenshots. (1) In the first screen shot you loaded the oSilProg v0.08 hex file, while in the second screen shot it reports beeing a BLHeliBox... how does this come? (you are apparently not using a BlHeliBox...) (2) The flash has worked but not the verify? Or haven't you done a Flash before?

EDIT: ÄHM, Seco... I haven't looked at it before... your setup looks VERY dangerous... you are powering the ESC backwards through the FC board via the USB???? I think you definitely should have a lipo plugged to your ESC and remove the black-red-white servo cable from your FC unit! Try this first.



Thank you very much OlliW answer as soon as possible

1 - ESC took the red-black-and-white cables.

2 - lipo to the ESC plugged

3 - I pressed the flash directly to verify without

flash hex file... done!

Thanks again OlliW



Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Found forget the plush, i need 5x 30 amp esc that i can flash, no plush !!! crash8384 Aircraft - Electric - Multirotor (FS/W) 14 Jun 25, 2012 04:10 AM
Discussion is it possible to flash the Flycam Blackboard w/ 4.7kk X betito Multirotor Drone Talk 2 May 03, 2012 03:12 PM
Discussion Silabs 8051 ESC (Turnigy Subperbrain) Firmware nickax Multirotor Drone Talk 2 Jan 30, 2012 12:11 AM
Sold 2 Turnigy Plush 10 amp ESCs + 1 Turnigy 5A UBEC + 1 Turnigy Programming Card - $21 shawn595 Aircraft - Electric - Power Systems (FS/W) 2 Apr 02, 2011 01:30 PM
Discussion Is it possible to convert TURNIGY Plush 30A ESC's from PWM to TWI/I2C control benbois DIY Electronics 0 Dec 17, 2008 12:56 PM