Alternative ESC firmware (reflashing)

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

ziss_dm wrote:Hi,
Updated to "V 2.0.4 alpha":
ziss_dm


Hi, ziss_dm,

Thanks for your work. I just tested the latest sources, again with bs20_nFet/KDA20-28m and bs12a_nFet/kda20-50s. Again fine on the bench, first flight will be tomorrow if the weather is fine.
Question:
ziss_dm wrote:- Complementary PWM support for all-n-fet boards.ziss_dm

Can I activate this by

Code: Select all

//*************************
// System settings        *
//*************************
//#define    OSC_DEBUG
#define COMP_PWM
?

braking directly in the setup section of wii_esc_ng.cpp? :

Code: Select all

pwr_stage.braking_enabled = 1;


I modded the HAL for bs_nfet for reversed rotation, maybe helpful for someone else, maybe I just missed the "reverse-flag" somewhere else in the code :?

Code: Select all

#ifndef _BS_NFET_REV_H_
#define _BS_NFET_REV_H_

//*********************
// PORT B definitions *
//*********************
#define DbgLED          5
#define DbgStr          4
#define CnFET           0
#define PORTB_INIT      0
#define PORTB_DD        (1<<CnFET)+(1<<DbgLED)+(1<<DbgStr)
#define BRAKE_PB        (1<<CnFET)

inline void DebugLEDOn()     {PORTB |= _BV(DbgLED);}
inline void DebugLEDOff()    {PORTB &= ~_BV(DbgLED);}
inline void DebugLEDToggle() {PORTB ^= _BV(DbgLED);}

inline void DebugStrOn()     {PORTB |= _BV(DbgStr);}
inline void DebugStrOff()    {PORTB &= ~_BV(DbgStr);}
inline void DebugStrToggle() {PORTB ^= _BV(DbgStr);}

//*********************
// PORT C definitions *
//*********************
#define AnRef           1
#define CpFET           3
/* swap A/B
#define BnFET           4
#define BpFET           5
#define PORTC_INIT      (1<<AnRef)+(1<<CpFET)+(1<<BpFET)
#define PORTC_DD        (1<<AnRef)+(1<<CpFET)+(1<<BnFET)+(1<<BpFET)
#define BRAKE_PC        (1<<BnFET)
*/
#define AnFET           4                                 
#define ApFET           5                                 
#define PORTC_INIT      (1<<AnRef)+(1<<CpFET)+(1<<ApFET)         
#define PORTC_DD        (1<<AnRef)+(1<<CpFET)+(1<<AnFET)+(1<<ApFET)   
#define BRAKE_PC        (1<<AnFET)                           

//*********************
// PORT D definitions *
//*********************
#define rcp_in          2
#define c_comp          6

/* swap A/B
#define AnFET           5
#define ApFET           4
#define PORTD_INIT      (1<<ApFET)
#define PORTD_DD        (1<<ApFET)+(1<<AnFET)
#define BRAKE_PD        (1<<AnFET)
*/
#define BnFET           5                                 
#define BpFET           4                                 
#define PORTD_INIT      (1<<BpFET)                           
#define PORTD_DD        (1<<BpFET)+(1<<BnFET)                  
#define BRAKE_PD        (1<<BnFET)                           


/*inline void ApFETOn()  {PORTD &= ~_BV(ApFET);}
inline void ApFETOff() {PORTD |=  _BV(ApFET);}
inline void AnFETOn()  {PORTD |=  _BV(AnFET);}
inline void AnFETOff() {PORTD &= ~_BV(AnFET);}

inline void BpFETOn()  {PORTC &= ~_BV(BpFET);}
inline void BpFETOff() {PORTC |=  _BV(BpFET);}
inline void BnFETOn()  {PORTC |=  _BV(BnFET);}
inline void BnFETOff() {PORTC &= ~_BV(BnFET);}
*/
inline void ApFETOn()  {PORTC &= ~_BV(ApFET);}
inline void ApFETOff() {PORTC |=  _BV(ApFET);}
inline void AnFETOn()  {PORTC |=  _BV(AnFET);}
inline void AnFETOff() {PORTC &= ~_BV(AnFET);}

inline void BpFETOn()  {PORTD &= ~_BV(BpFET);}
inline void BpFETOff() {PORTD |=  _BV(BpFET);}
inline void BnFETOn()  {PORTD |=  _BV(BnFET);}
inline void BnFETOff() {PORTD &= ~_BV(BnFET);}

inline void CpFETOn()  {PORTC &= ~_BV(CpFET);}
inline void CpFETOff() {PORTC |=  _BV(CpFET);}
inline void CnFETOn()  {PORTB |=  _BV(CnFET);}
inline void CnFETOff() {PORTB &= ~_BV(CnFET);}

#define mux_c           0
//#define mux_a           6
//#define mux_b           7
#define mux_b           6
#define mux_a           7

inline void ACInit() {
  ACMultiplexed();
  ACSR |= _BV(ACIC);
}

inline void ACPhaseA() {
   ACChannel(mux_a);
}

inline void ACPhaseB() {
   ACChannel(mux_b);
}

inline void ACPhaseC() {
   ACChannel(mux_c);
};

//#define BEMF_FILTER_DELAY_US 22

void Board_Idle() {
};

inline void Board_Init() {
  TIMSK = 0;
  // Timer1
  TCCR1A = 0;
  TCCR1B = _BV(CS11);                 /* div 8 clock prescaler */
  PORTB = PORTB_INIT; DDRB = PORTB_DD;
  PORTC = PORTC_INIT; DDRC = PORTC_DD;
  PORTD = PORTD_INIT; DDRD = PORTD_DD;

  ACInit();
}

#endif // _BS_NFET_REV_H_


Regards,
gompf

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi gompf,

1) Yes, to activate complimentary PWM you need to define #define COMP_PWM
2) Currently yes, I'm thinking to put configuration block into EEPROM, that is why it is run-time option.
3) Currently there are no reverse, I'll think how to integrate it. ;)

regards,
ziss_dm

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

Sorry for cross-posting but maybe better suited here?!
viewtopic.php?f=8&t=2356&p=22072#p22072

Question is it possible that wii-esc (old) is more sensitive and can be culprit for those issues?

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

I would guess, that you are using soft PWM. EEPROM writes are disabling interrupts.

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

ziss_dm wrote:I would guess, that you are using soft PWM. EEPROM writes are disabling interrupts.

I'm only defining EXT_MOTOR_RANGE for QuadX on ProMini and Mega boards. AFAIK that does not enable softPWM?! :?:

I have noticed that you pushed EEPROM support into WII-ESC-NG! Any hints how to use it? What options are EEPROM programable (eg. COMP. PWM on or off??!).

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,

Not sure, in this case.. Can you reproduce it on the ground?

I have noticed that you pushed EEPROM support into WII-ESC-NG! Any hints how to use it? What options are EEPROM programable (eg. COMP. PWM on or off??!).

Currently: input pwm parameters and brake on/off. It is quite dangerous to put COMP_PWM there as enabling it on pFET boards will explode them. The Idea is to have pre-configured blocks (std, extended, UltraPWM, FreeFlight, etc..) and maybe even eeprom editor later. ;)

BTW: Looking at http://code.google.com/p/multiwii/sourc ... Output.ino, I have noticed that access to the 16 bit OCRnx is not atomic, thic can produce issues.

http://www.nongnu.org/avr-libc/user-man ... aq_16bitio

regards,
ziss_dm

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

ziss_dm wrote:Hi,

Not sure, in this case.. Can you reproduce it on the ground?

ziss_dm

I will try in couple of days.

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

ziss_dm wrote:Hi,

Currently: input pwm parameters and brake on/off. It is quite dangerous to put COMP_PWM there as enabling it on pFET boards will explode them.
ziss_dm


Is COMP_PWM on all nFET boards considered safe and air tested (at least to some extent)?
Regards
Andrej

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,

I'm flying it. ;) But you would need to re-adjust PIDs

regards,
ziss_dm

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

ziss_dm wrote:Hi,

I'm flying it. ;) But you would need to re-adjust PIDs

regards,
ziss_dm

Need to as in: "If you don't it will not fly!" or just "You can get more out of it if you do".
How much? I'm already using EXT_MOTOR_RANGE reflashed ESC and have roll and pitch PIDs around 8.5 0.029 30

Regards Andrej

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

Hi ziss_dm,
Thanks again for your work and answers, got airborn with V2 and everything is fine. I just couldn´t finish adjusting the PIDs, only hat 4 packs with me and needed 2 to feel the satisfaction of poshold after the rough setup ;-)
ziss_dm wrote:3) Currently there are no reverse, I'll think how to integrate it. ;)
ziss_dm

No problem, i just thought I might have missed this as I tend to find solutions for non existing problems from time to time :? Imho no action needed as defining a "reversed target" is quite simple and helps to keep the code clean and simple. You already did a great job!
crashlander wrote:Is COMP_PWM on all nFET boards considered safe and air tested (at least to some extent)?

I fly with COMP_PWM/nFet/ExtRange, works so far but can´t say much about the PIDs atm. still rising... Had 40min flightime with new FW, 20min dragstarts and rounds, 20min poshold. Motors/ESCs cool and no problems with combos bs20A/A20-28m and bs12a/a20-50s.

Regards,
gompf

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi gompf-2,

Tnx for your feedback.

I fly with COMP_PWM/nFet/ExtRange, works so far but can´t say much about the PIDs atm.


I would say, in my setup, I had to decrease D (as it was too slow with COMP_PWM) and increase P. Also noticeble difference: It is easier to control hight in wind gusts (less jumping).

regards,
ziss_dm

sim
Posts: 18
Joined: Tue Oct 18, 2011 11:40 pm

Re: Alternative ESC firmware (reflashing)

Post by sim »

Hi, ziss_dm!

I was also looking at making an EEPROM block area for configuration (reverse, brake, timing, and maybe some other options). I wonder if we should try to make something standard / compatible? Also, are you shipping wii-esc with a boot loader that is in any way compatible with multiwii, and/or are there any plans to make it configurable through the flight board? This is possible with the boot loader I wrote, but it is using the Turnigy USB linker wire protocol, which is probably a bit strange compared to most others, albeit safe to send even to an armed ESC.

Meanwhile, I tried comp_pwm in my tree as well, and it definitely has an interesting effect. Have you noticed a decrease in fight time? I need to set up something to measure efficiency, throttle linearity, response time, etc.

Also, the idea I posted previously regarding sync loss avoidance has had some progress. My original idea of waiting for the demag regardless of length has the problem that the capacitors lag the _start_ of the visible demagnetization, so rather than just starting a 30° timer and giving up if the filtered comparator does not show demag has ended, I split it into two timers -- the first is the length of the original demag period (15°, or a bit less), and then after this we look for the demag for up to an absolute 30° since the commutation. If this times out, we turn off PWM (same as 0% duty), wait for the commutation delay, and commutate while turning back on PWM. Otherwise, ZC sense continues as normal for up to the zc timeout. This seems to work -- I can now accelerate the MT-3506 and hard drive motor at full throttle at 18V input. The only issue seems to be that the hard drive motor and some other motors tend to cause the loss avoidance/pwm disable even when they don't need to, because of the filtering capacitors. I think this can probably be tuned so that people do not need to remove the capacitors, but otherwise, it seems to work.

I also went to absolute timers instead of relative ones to reduce the skew at high speed, but it's looking really heavy at 24-bit and trying to compensate for byte-extended 16-bit timers everywhere, and register spills in update_timing. Maybe I really should go back to 16-bit tracking. ;) Meanwhile, I have also implemented DC bias removal in update_timing, and this seems to have made low speed a bit smoother and less confusing for the demag tracking. I need to sort out all of the mess and feed it into git.

Cheers,
Simon-

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

Hi,

sim wrote:Meanwhile, I tried comp_pwm in my tree as well, and it definitely has an interesting effect. Have you noticed a decrease in fight time? I need to set up something to measure efficiency, throttle linearity, response time, etc.


I just made a quick shoot without load. The current vs. ppm input looks quite nice for comp_PWM but I also see a dip around 1640µs in normal mode.
Firmware is r323, extended range on Mystery BS12A nFet with EMF caps and RC-input cap removed
Image
Sadly to late now to measure with prop and I also need to build a simple filter to get the rpms.

Regards,
gompf

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi Simon,

I was also looking at making an EEPROM block area for configuration (reverse, brake, timing, and maybe some other options). I wonder if we should try to make something standard / compatible?

Good idea! Currently I use really simple layout:

Code: Select all

struct eeprom_layout {
  uint8_t __ver_magic;
  struct config_data cfg;
};

struct config_data {
  uint16_t rcp_min_us;
  uint16_t rcp_max_us;
  uint16_t rcp_start_us;
  uint16_t rcp_full_us;
  uint16_t rcp_cal_us;
  uint8_t  rcp_deadband_us;
  uint8_t  braking;
};

__ver_magic - layout version.

The only "trick" is that all values in phisical units. If you have better idea, I'm ready to change it. ;)

Also, are you shipping wii-esc with a boot loader that is in any way compatible with multiwii, and/or are there any plans to make it configurable through the flight board? This is possible with the boot loader I wrote, but it is using the Turnigy USB linker wire protocol, which is probably a bit strange compared to most others, albeit safe to send even to an armed ESC.

Currently there is no bootloater bundled. I'm old-fasion man - I think, that ISP connector on the board is safest and fastest way to update firmware. I'm also researching possibility to use SPI as a digital communication channel, instead of PPM as a side-effect it should allow to re-flash without bootloader ;)

Meanwhile, I tried comp_pwm in my tree as well, and it definitely has an interesting effect. Have you noticed a decrease in fight time? I need to set up something to measure efficiency, throttle linearity, response time, etc.

You probably need to adjust dead-time. In C version dead-time inserted naturally by overhead of the case statement. In your case, you probably need to add some delay 0.5 - 0.7us, usually enough.

Also, the idea I posted previously regarding sync loss avoidance has had some progress. My original idea of waiting for the demag regardless of length has the problem that the capacitors lag the _start_ of the visible demagnetization, so rather than just starting a 30° timer and giving up if the filtered comparator does not show demag has ended, I split it into two timers -- the first is the length of the original demag period (15°, or a bit less), and then after this we look for the demag for up to an absolute 30° since the commutation. If this times out, we turn off PWM (same as 0% duty), wait for the commutation delay, and commutate while turning back on PWM. Otherwise, ZC sense continues as normal for up to the zc timeout. This seems to work -- I can now accelerate the MT-3506 and hard drive motor at full throttle at 18V input. The only issue seems to be that the hard drive motor and some other motors tend to cause the loss avoidance/pwm disable even when they don't need to, because of the filtering capacitors. I think this can probably be tuned so that people do not need to remove the capacitors, but otherwise, it seems to work.

So, you switching power_off only for 15deg? I tried to re-produce this algorithm, but without success: I can see, that it is powering off and automatically commutating when driving HDD motor, but with "normal" motor it never detecting ZC on next state ;( Are you sure, that improvemet is not side-effect of anything else? ;)


Meanwhile, I have also implemented DC bias removal in update_timing, and this seems to have made low speed a bit smoother and less confusing for the demag tracking.

This is interesting. ;) Can you explain little bit more? I understand, that we can vitrually shift zc instant depending on timing difference, but we have only 15deg window for compensation and not clear how to take into account real acceleration.

@gompf-2
I have found reason for this jump and dip. ;( In latest version it should be corrected, but in expence a litle bit higher noise at low power.
Could you also describe your testing procedure?
BTW: You can get RPM data from MISO pin, if you enable debugging.


regards,
ziss_dm

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

Hi,

ziss_dm wrote:I have found reason for this jump and dip. ;( In latest version it should be corrected, but in expence a litle bit higher noise at low power.
Could you also describe your testing procedure?
BTW: You can get RPM data from MISO pin, if you enable debugging.


I just did some load tests with BS12A, KDA20-50s and EPP8045 carbon @7,5V (my PSUs limit for 3,5A), ext range normal and comp PWM, this is current over driving frequency:
Image
I used the same r323 hex files I also flashed last night, but with load I couldn´t reproduce the dip in normal PWM mode?

You shoud see this as a rough result as my testing curcuite is a bit ugly:
Image

I fed the esc with analog.Write 0-254 in steps of 10 by an arduino with serial connection, then I monitored current, driving frequency via a rc-filter from one of the motor lines, PPM and Vin to the esc. Vin dropped from 7,50 to 7,33 at full load/esc input (DMM/cables/connectors R), the graphs are not voltage normalized as I cant find my origin and don´t want to bother with calculations in OO.

With the Tektronix I coud also monitor response but haven´t done this as I can´t find an USB stick small enough to be compatible with the storage function, iirc was 2gb limit or something.
Thrust is not so interesting I think as we use well known propellers (and my wife doesn´t tell me were to find the kitchen scale) ;)

edit: I just rechecked because it looked strange: The picture of the graph is with cubic splines, even if I remove every smoothing the comp_PWM curve looks as smooth as above

Regards,
gompf

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,

I used the same r323 hex files I also flashed last night, but with load I couldn´t reproduce the dip in normal PWM mode?

I think this is due larger scale of I axis. If you "zoom" or use smaller load, you will find it is still there. ;)

regards,
ziss_dm

User avatar
NikTheGreek
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece
Contact:

Re: Alternative ESC firmware (reflashing)

Post by NikTheGreek »

Hi.
I ve flashed succesfully my Turnigy Mag8 Towerpro 18a ESC with simonk firmware tp_nfet.hex :D
This is the best firmware for them ? or there is something better ?

Thank you in advance for your time and effort .

FRONT
Image
BACK
Image

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,

Updated to "V 2.0.6 alpha":

What is new:
- The PPM configuration now stored in EEPROM. The distribution archive also contains pre-defined blocks for different variants/boards (default, extended, ultra-pwm, etc)
- Fixed small power bump at the beginning and end of the range.

@NikTheGreek: The tp_nfet.hex target exists, but it was not tested. You can be first. ;)

regards,
ziss_dm

User avatar
NikTheGreek
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece
Contact:

Re: Alternative ESC firmware (reflashing)

Post by NikTheGreek »

ziss_dm wrote:@NikTheGreek: The tp_nfet.hex target exists, but it was not tested. You can be first. ;)


Tested in my bench and....WORKING FINE :D

3 more left to go...... ;)

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi gompf-2,

Can I ask you to repeat test on: 2.0.6? ;)

regards,
ziss_dm

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

Hi ziss_dm,

I will, but unfortunately it´s monday... :o I´ll find some time in the next 2-3 days.

Regards,
gompf

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

Hello,
question: Are those (marked with yellow on picture) caps BEMF on F-30A (and F-20A) HK ESC? And should they be removed when used with v2 firmware (it worked O.K. with them not removed on v1 of firmware)?!

Regards Andrej.
Attachments
UP1.jpg

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Yes, they are.
V1 was more tolerant, but still better to remove them. If you after "perfection", you can replace them with 40pf ones.

Regards,
Ziss_dm

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,

To simplify firmware flashing and adjusting configuration, now it is possible to use this tool:

http://wii-esc.googlecode.com/files/wii ... _win32.exe

This is simple avrdude shell. It is designed to support users that have never flashed firmware to a micro-controller. Idt supposed to be fully portable and self-contained (with reasonable download size)

Features:
1) Existing firmware backup (flash, eeprom, fuses)
2) Download fresh files
3) Edit Parameters
4) Portable

regards,
ziss_dm
Attachments
wii_esc_flash_main.png
wii_esc_flash_conf_editor.png

LazyZero
Posts: 2
Joined: Mon Jun 25, 2012 6:57 am

Re: Alternative ESC firmware (reflashing)

Post by LazyZero »

Funny ;) , because I released today a new version of the kkflashtool also able to flash wii-esc directly from svn.

The only thing I am still working on is the eeprom editing, I will add it to next beta when it is ready.
So there is a alternative for Mac and Linux users, Windows users are also welcome.

Best Christian

vpb
Posts: 231
Joined: Mon Jul 23, 2012 4:09 pm

Re: Alternative ESC firmware (reflashing)

Post by vpb »

Hi LazyZero, I use your kkflashtool all the time, very comfortable! :D

I have small thing about Turnigy F30 reflashed with Simonk fw, I dont know that's feature or problem. Whenever one of my propeller touch hard-to-cut-through thing, like a (very) small tree branch, tough glass body, leaf, it stops immediately that motor and ofcourse my tricopter fall. But later then, about 1s, it spins again Luckily that's almost at low height when I try to cut the glass :D. Anybody meets that behaviour?

LazyZero
Posts: 2
Joined: Mon Jun 25, 2012 6:57 am

Re: Alternative ESC firmware (reflashing)

Post by LazyZero »

vpb wrote:Hi LazyZero, I use your kkflashtool all the time, very comfortable! :D

I have small thing about Turnigy F30 reflashed with Simonk fw, I dont know that's feature or problem. Whenever one of my propeller touch hard-to-cut-through thing, like a (very) small tree branch, tough glass body, leaf, it stops immediately that motor and ofcourse my tricopter fall. But later then, about 1s, it spins again Luckily that's almost at low height when I try to cut the glass :D. Anybody meets that behaviour?


I think that is normal behavior of simonk firmware, I had to make the same experiences.

Best Christian

vpb
Posts: 231
Joined: Mon Jul 23, 2012 4:09 pm

Re: Alternative ESC firmware (reflashing)

Post by vpb »

thank you, nice to hear that!

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

Hi ziss_dm,

I did some tests with r381 today, setup again BS12A nFet and KDA20-50s,epp8x4,5.
I was to lazy to export all the graphs so I uploaded the ods-file.
http://www.dateiupload.com/files/lHx71RLdLU.ods
I tried to normalize to U=7,5V as my PSU isn´t stable. The comp_PWM firmware feels fine, normal PWM has problems in my setup with startup transist lower than pwm step 2-20 (e.g. starts with jump 2 - 10 but needs 3-4s to get rotor on ordered rotation/get feedback. Even when the motor seems to run smooth I can observe several sync losses (oszi on Miso-pin shows unstaple PPM) while analoge.Write < ~45.
But as I wrote, comp_PWM feels fine.

PS: Is it possible to disable ee2 support via config? I ask because I use armokopter bootloader (http://www.armokopter.at/wiki/doku.php?id=aok:elektronik:regler_neu:bootloader), works fine but for flash only. I managed to set eg input method by hand but braking seems to be enabled by default in comp-mode when I build it "by hand" and flash the .hex only.

Regards,
gompf

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

The comp_PWM firmware feels fine, normal PWM has problems in my setup with startup transist lower than pwm step 2-20 (e.g. starts with jump 2 - 10 but needs 3-4s to get rotor on ordered rotation/get feedback. Even when the motor seems to run smooth I can observe several sync losses (oszi on Miso-pin shows unstaple PPM) while analoge.Write < ~45.
But as I wrote, comp_PWM feels fine.

You can try to increase RPM_START_MIN_RPM up to 7000-8000 rpm.


PS: Is it possible to disable ee2 support via config? I ask because I use armokopter bootloader (http://www.armokopter.at/wiki/doku.php? ... bootloader), works fine but for flash only. I managed to set eg input method by hand but braking seems to be enabled by default in comp-mode when I build it "by hand" and flash the .hex only.


Added:

Code: Select all

#define    READ_EXTERNAL_CONFIG


regards,
ziss_dm

sim
Posts: 18
Joined: Tue Oct 18, 2011 11:40 pm

Re: Alternative ESC firmware (reflashing)

Post by sim »

Hello! Oops, sorry, I forgot to check here for a while.

ziss_dm wrote:Hi Simon,

I was also looking at making an EEPROM block area for configuration (reverse, brake, timing, and maybe some other options). I wonder if we should try to make something standard / compatible?

Good idea! Currently I use really simple layout:

Code: Select all

struct eeprom_layout {
  uint8_t __ver_magic;
  struct config_data cfg;
};

struct config_data {
  uint16_t rcp_min_us;
  uint16_t rcp_max_us;
  uint16_t rcp_start_us;
  uint16_t rcp_full_us;
  uint16_t rcp_cal_us;
  uint8_t  rcp_deadband_us;
  uint8_t  braking;
};

__ver_magic - layout version.

The only "trick" is that all values in phisical units. If you have better idea, I'm ready to change it. ;)


Gah.. it's fine except for this. :) Actually, I was testing with a very tiny high KV motor the other day, and noticed my new variable timing code is slow enough that it was lagging the timing at very high speed, so I went and ripped everything back out down to 16-bit again. It's fairly easy to do (and the new 16-bit rc pulse code works either way), but I just couldn't find a way to make the input pulse scaling not ugly and slow. I think I prefer optimizing 24-bit and having the extra bits than making the interrupt slower or putting a shift left 3 during input and calibration, just so that scaling from it to PWM range can still happen without much overhead and meet shorter ranges (@8MHz and/or with RC car mode). So I shelved that again and optimized and JITitized the 24-bit stuff, meaning everything still calibrates to 1/16µs steps. I guess you don't want to store everything left-shifted 4 bits. :)

ziss_dm wrote:Currently there is no bootloater bundled. I'm old-fasion man - I think, that ISP connector on the board is safest and fastest way to update firmware. I'm also researching possibility to use SPI as a digital communication channel, instead of PPM as a side-effect it should allow to re-flash without bootloader ;)


Hehe.. :) I also have some contrib code to enable SPI for debugging during operation. It should be pretty simple to use it for commands as well. We will still need a connection to reset for reflashing, though.

ziss_dm wrote:You probably need to adjust dead-time. In C version dead-time inserted naturally by overhead of the case statement. In your case, you probably need to add some delay 0.5 - 0.7us, usually enough.


Yeah, I was experimenting with this. The F-30A boards seem to have pretty good response time except for high FET on time is quite slow. I also notice the effect that starting is easier and even back-EMF seems less noisy with complementary PWM. I'd like to make it an option for larger boards with FET drivers, but they often have the same pin config as tiny boards with P/N. Your P/N test ended quickly, eh? I was thinking about how difficult it might be to measure for both FET on/off times and for the presence of BEMF capacitors, and shift the timing if found. We could drive AIN0 on any board. Maybe it would be possible to measure delay from AIN0 to any mux pin, or from one mux pin to another. Measuring FET timing (to calculate a deadtime) may be difficult when capacitors are present.

ziss_dm wrote:So, you switching power_off only for 15deg? I tried to re-produce this algorithm, but without success: I can see, that it is powering off and automatically commutating when driving HDD motor, but with "normal" motor it never detecting ZC on next state ;( Are you sure, that improvemet is not side-effect of anything else? ;)


Hmm, no, I'm not. I changed too many things at the same time. :/ The intent is, in absolute degrees (0 being the commutation point), 15°: start looking for demag, 30°: give up, stop PWMing, continue as if ZC happened, 60-advance°: go to next step and re-enable PWM. If I skip the looking for demag loop and just go straight to looking for ZC with abs 120° timeout, the hard drive motor driving is really bad. What "normal" motor are you trying?

ziss_dm wrote:
Meanwhile, I have also implemented DC bias removal in update_timing, and this seems to have made low speed a bit smoother and less confusing for the demag tracking.

This is interesting. ;) Can you explain little bit more? I understand, that we can virtually shift zc instant depending on timing difference, but we have only 15deg window for compensation and not clear how to take into account real acceleration.


Motors driven very slowly always bad on the F-30A: the commutation steps are very uneven, and I thought this was maybe leading to problems, but since it mostly disappears at higher speeds, I'm not so sure this really helps anything. It does seem to make things more symmetric on the hard drive motor. It just uses the interval of the last two ZCings as 120° and adds half of the difference between the last two intervals to the previous ZC time to "fix" the next ZC time...if that makes any sense. I uploaded some scope pictures here with channel 1 showing phase A, channel 2 showing the start of update_timing until the end of the commutation wait. You can see that it is trying to keep the falling edge evenly spaced.

http://0x.ca/sim/esc/timing_loss_fix/hd ... as_fix.png
http://0x.ca/sim/esc/timing_loss_fix/hd ... as_fix.png

ziss_dm wrote:I have found reason for this jump and dip. ;( In latest version it should be corrected, but in expence a litle bit higher noise at low power.

This is what I was seeing when I was testing with your tree. It seems fixed now.

vpb wrote:I have small thing about Turnigy F30 reflashed with Simonk fw, I dont know that's feature or problem. Whenever one of my propeller touch hard-to-cut-through thing, like a (very) small tree branch, tough glass body, leaf, it stops immediately that motor and ofcourse my tricopter fall. But later then, about 1s, it spins again


Maybe I didn't quite understand when you reported this before. It should immediately reduce duty to maximum 25%, but not stop unless physically blocked, and always keep trying to run again. There should be no 1s delay. Do you think instead that it should stop and only start again if re-armed, like if freshly-rebooted?

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

@ziss_dm: I can see you released 2.0.7 beta and also avrootloader! Can you please summarize changes/improvements.

I'm currently using 2.0.6 with comp_pwm and EXT_MOTOR_RANGE on a Y6 and it works perfectly. The only thing I have noticed when I moved from 3S to (much heavier) 4S configuration was the necessity to set #define MPU6050_LPF_42HZ or I could not remove oscillations, that was defiantly not so obvious with 3S!??

Regards Andrej

My config:
Y6, 1.6kg fly weight
- Crius AIO Pro
- mix of F-30A and F-20A,
- Turnigy D2830-11 1000kv (Aerodrive),
- 4S 5800mAh
- GWS 10x4.7 prop.

zarkon
Posts: 68
Joined: Sat Oct 15, 2011 8:25 am

Re: Alternative ESC firmware (reflashing)

Post by zarkon »

NikTheGreek wrote:Hi.
I ve flashed succesfully my Turnigy Mag8 Towerpro 18a ESC with simonk firmware tp_nfet.hex :D
This is the best firmware for them ? or there is something better ?

Thank you in advance for your time and effort .

FRONT
Image
BACK
Image


hey I have the same ESC mind sharing where is the programming pad for it? can't seem to figure it out

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Alternative ESC firmware (reflashing)

Post by LenzGr »

zarkon wrote:hey I have the same ESC mind sharing where is the programming pad for it? can't seem to figure it out

There does not seem to be one - you will have to connect to the solder pads of the CPU directly. Check the info and links from this spreadsheet for more info.

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Alternative ESC firmware (reflashing)

Post by frogstarb »

I have one of these in transit, and if it works as it should I'll be flashing my 6 hobbykink blue series 12A escs without even pulling out the soldering iron :)

User avatar
NikTheGreek
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece
Contact:

Re: Alternative ESC firmware (reflashing)

Post by NikTheGreek »

LenzGr wrote:There does not seem to be one - you will have to connect to the solder pads of the CPU directly. Check the info and links from this spreadsheet for more info.


You are right...somehow you have to connect the ISP to the microcontroler directly ;)

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,


@ziss_dm: I can see you released 2.0.7 beta and also avrootloader! Can you please summarize changes/improvements.


Yes, 2.0.7 was released, but list of changes is not really big. ;)
1) The status was changed to the beta, as was no big problems was reported. ;)
2) The timing advance is configurable in EEPROM now (15, 17, 19, 21 deg)
3) Compiller directive to disable EEPROM reading ;)

The flash tool v 0.4:
1) Timing advance in EEPROM editor
2) AVRootLoader added as a target, so it is possible to flash it. Boot sign: "ESCBL1"
3) AVRootLoader added as a programmer. I have created command-line wrapper for the AVRootLoader.dll. It supports writing Flash and EEPROM. The boot sign currently hardcoded to the "ESCBL1". ;) Also there are small addition: It before programming it sets DTR, so DTR can be used to apply power to the ESC, which makes process fully automatic. If there are interest, I can post schematic. ;)

The only thing I have noticed when I moved from 3S to (much heavier) 4S configuration was the necessity to set #define MPU6050_LPF_42HZ or I could not remove oscillations, that was defiantly not so obvious with 3S!??

This is interesting. Usually is enough to reduce P and D by 20-30% (which is quite explainable). So, was no way to remove oscillations by PID adjustments? Was it fast or slow oscillations or erratic? ;)

regards,
ziss_dm

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi Simon,

I have tryed last "fetkiller" release on my micro, and found some anomailies in recovery algorithm.
This is the video:
http://youtu.be/CPsDLV1Xvf4

regards,
ziss_dm

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

ziss_dm wrote:Hi,
This is interesting. Usually is enough to reduce P and D by 20-30% (which is quite explainable). So, was no way to remove oscillations by PID adjustments? Was it fast or slow oscillations or erratic? ;)
ziss_dm

On further testing: it is possible that only bearings get worser and thus produce more vibrations, because oscillations were (and are now getting back) like random kicks around X and Y axes. I really have to test again with 3S....

Regards
Andrej

sim
Posts: 18
Joined: Tue Oct 18, 2011 11:40 pm

Re: Alternative ESC firmware (reflashing)

Post by sim »

ziss_dm wrote:I have tryed last "fetkiller" release on my micro, and found some anomailies in recovery algorithm.
This is the video:
http://youtu.be/CPsDLV1Xvf4


Hello! I think the problem is actually not with the recovery algorithm but with the ZC filter and/or DC bias cancellation stuff, where it keeps falling from running mode back to start mode because it hits what it thinks is a 120 degree timeout. Can you try the latest release at https://github.com/sim-/tgy/downloads and see how it compares? I have only the 2900KV version of that motor, and it seems to work fine (though it hits TIMING_MAX with no prop). Cheers!

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

ziss_dm wrote:3) AVRootLoader added as a programmer. I have created command-line wrapper for the AVRootLoader.dll. It supports writing Flash and EEPROM. The boot sign currently hardcoded to the "ESCBL1". ;) Also there are small addition: It before programming it sets DTR, so DTR can be used to apply power to the ESC, which makes process fully automatic. If there are interest, I can post schematic. ;)
ziss_dm

If you meant the schematics for programer than: Yes please!

Regards Andrej

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

Hi ziss_dm,

ziss_dm wrote:3) AVRootLoader added as a programmer. I have created command-line wrapper for the AVRootLoader.dll. It supports writing Flash and EEPROM. The boot sign currently hardcoded to the "ESCBL1". ;) Also there are small addition: It before programming it sets DTR, so DTR can be used to apply power to the ESC, which makes process fully automatic. If there are interest, I can post schematic. ;)


Again, thank you very much for this comfortable and easy solution! :ugeek:

crashlander wrote:If you meant the schematics for programer than: Yes please!


The "programer" is a rs232 to 1-wire interface consisting of 2 resistors, see the small schematic under the "Hardware" section (sry, page is in german): http://www.armokopter.at/wiki/doku.php?id=aok:elektronik:regler_neu:bootloader
I tested this setup with HK BS12 nFet and 10k pullDOWN (list sais pullup) and it works fine with external power source.
With wii_esc_flash_v04_win32 DTR goes from high to low when entering programming so I assume ziss_dm intended to power the ESC via a pnp driver, general types like BC557 should be fine.

Edit: I tested this with success:
Image
Powering the ESC via the 3pin connector doesn´t work for HK BS12 as the BEC connected there is seperated from the MCUs +5V

Regards,
gompf

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,

The "programer" is a rs232 to 1-wire interface consisting of 2 resistors, see the small schematic under the "Hardware" section (sry, page is in german)


With FTDI and "Blue Series" style boards it is even simplier: 1 resistor. ;)

With wii_esc_flash_v04_win32 DTR goes from high to low when entering programming so I assume ziss_dm intended to power the ESC via a pnp driver, general types like BC557 should be fine.


Yes, that was intended. This is my "schematic":
servo_prog_imp_small.jpg
servo_prog_proj.jpg


Code: Select all

 R1 - 1.6k
 R2 - 4.7k


This works for all "bs" family. For others I'm just replacing resistor on the board (or put jumper, if I'm leazy)

Powering the ESC via the 3pin connector doesn´t work for HK BS12 as the BEC connected there is seperated from the MCUs +5V

True, but it is possible to put diode, like this:

IMG_20120927_173049.jpg


regards,
ziss_dm

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Alternative ESC firmware (reflashing)

Post by crashlander »

@ziss_dm & gompf-2: Thank you for schematic.

Another question regarding EXT_MOTOR_RANGE and atmega328, since Alexinparis introduced LadyBird option (brushed direct FET control) the ESC does not arm (even with MINTHROTTLE 1008), so I must add each time +2 in output.ino to get old behavior back.
eg. new default:

Code: Select all

OCR1B = ((motor[1]>>2) - 250);

old working:

Code: Select all

OCR1B = ((motor[1]>>2) - 250)+2;

Is there any known workaround to fix this (without changing output.ino each time).
Regards Andrej

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Alternative ESC firmware (reflashing)

Post by frogstarb »

Hey all,

Just received my socket tool for programming my ESCs. These are 12A hobby-king blue series (which HK implies are mystery rebranded), but before I go about building and flashing I thought I'd ask; are these know to work/not work with the alternative firmwares? Is there one I should try first?

Pointers greatly appreciated :)

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Alternative ESC firmware (reflashing)

Post by gompf-2 »

Hi frogstarb,

yes, they work. You just have to find out if you have the older version with p- and n-fets in the powerstage or the newer one with nfets only. If you remove the shrink tubing for programming check if you have 6 identical fets under the heatsink (->nfets only) or 3 each of 2 different types (p- and nfets).
With p/n fets you have to choose Blue Series as target, with nfets only Blue Series V2 or Blue Series V2 with complimentary PWM.

I use BS12 V2 with KDA20-50s and for me it feels better with complimentary PWM. Also I like the bootloader option with the BS-ESCs as rx from the mega8 is connected to the ppm input -> no rework needed.
PS: It woudn´t have been tooo dificult to find this info here... ;)


Regards,
gompf

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Alternative ESC firmware (reflashing)

Post by frogstarb »

Hey gompf,

Thanks for the info. I'm not the patient type so I went ahead and reflashed them with bs_nfet.hex from simonk, I didn't know I should have checked the fets... oops. Now, they all work and while I had to play with reversing rotation, everything else was simple and straightforward, I will check the fets tomorrow before I recalibrate the escs. I was confident about using nfet because the RapidEsc DB only mentioned one kind of BS 12A.

I know information isn't hard to find here, but there's so much of it and I have no way of knowing what to trust so I thought I'd ask on a thread dedicated to the alt firmwares. I learned a lot today, thank you!

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Alternative ESC firmware (reflashing)

Post by ziss_dm »

Hi,

Also I like the bootloader option with the BS-ESCs as rx from the mega8 is connected to the ppm input -> no rework needed.


BTW: The bootloader in flash tool uses PD2(INT0) pin directly, so it does not require this connection any more. ;)

regards,
ziss_dm

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Alternative ESC firmware (reflashing)

Post by Hamburger »

Is there any known workaround to fix this (without changing output.ino each time).
Regards Andrej

Try set MINCOMMAND 1008. I think that is used for initializing?

Post Reply