Alternative ESC firmware (reflashing)

[Hamburger]

Uncortunately no. I know about timing advance.

[ziss_dm]

Hi Hamburger,

Can you try to reproduce it on the ground? Is it happenning on WOT or low throttle?

I can imagine only couple of possibilities to motor stop:
1) Sync lost, but we have quite good sync recovery.
2) The input pulses getting outside allowed range, and failsafe is triggered.
3) MCU brouwnout.

regards,
ziss_dm

[Hamburger]

Hi ziss_dm,
good to hear from you.
It happened at below WOT (difficult to be more precise, I also have throttle curve in TX active).
Ok, I will try and reproduce on the ground with servo tester and spare ESC. Unfortunately I have no spare motor atm, so it will be a wild setup.
I will report back soon (next week).
Thanks, Hamburger

[funth1ngs]

Hi ziss_dm,

today I made some tests without propeller. I can hear a slight cklicking noise at nearly full speed. It's arround 1895 - 1900 us (with pwm_fast_200.inc). I guess it's just before transition to 100% duty cycle.

Is this normal?

Cheers,
Heiko

[Hamburger]

Hi,
I did the test with the BlueSeries 20A ESC flashed to r195 stock and turnigy 2205 motor on 3S. I could not reproduce the motor cutoff.
This is the code I used for testing:

Code: Select all

/*
  ESC test. - based on arduino example code
 
 */

// These constants won't change.  They're used to give names
// to the pins used:
const int analogOutPin = 9; // Analog output pin that the ESC is attached to

// normal ESC
//#define MMIN 125
//#define MMAX 250

// special ESC extended range
#define MMIN 2
#define MMAX 252
#define INC 10

uint8_t outputValue = MMIN;        // value output to the PWM (analog out)

void setup() {
  Serial.begin(115200); 
    analogWrite(analogOutPin, outputValue);           
    delay(5000);
}

void loop() {

  // change the analog out value:
  analogWrite(analogOutPin, outputValue);           

  // print the results to the serial monitor:
 
  Serial.print("\t output = ");      
  Serial.println(outputValue);   


  delay(600);
  if (outputValue == MMAX ) delay(5000); 
  
 outputValue+= INC;
if (outputValue == MMAX + INC ) outputValue = MMIN; 
if (outputValue > MMAX ) outputValue = MMAX; 
}

for now I have flashed the large TRI's ESC to r195 stock and will again do some test flying.
Maybe I should change the test code somehow - another sequence of pwm values, maybe?

[quax]

I think, the slight cklicking noise comes indeed from the jump from the minimum PWM-off time to no PWM-off time.

There is a limited low pulse with because of software overhead. This may be a jump from 97% to 100% without steps between the power stages. A no load motor may have a little swing, if the power step occurs.

Might be the reason ....

regards

quax

[ziss_dm]

Hi quax,

I think, I have solved problem with jumps at the end of PWM range. The interrupt serving short off cycles without exiting the routine.

But if voltage is high enough, the RPM limiter can produce shakes. In my test 1100Kv motor hitting the limit around 16v.

regards,
ziss_dm

[Hamburger]

Hi zisss_dm,
will you release that new solution anytime soon? I might just wait for that (and hopefully avoid another crash from motor cutoff)

[Hamburger]

update on my latest crash issue:
after upgrading to r915 stock with those bigger motors (turnigy 2209) I could not reproduce motor cutoff on test stand with the sketch posted earlier and went through 3 battery packs at the field.
With the bigger motors I stand good chance to never reach 100% throttle - maybe that helps some.

[Hamburger]

now that a working silabs firmware exists, should we become interested? Any reason to go silabs?
https://github.com/bitdump/BLHeli/tree/ ... 736/SiLabs

They have an atmel branch as well, with governor (useless for multi rotors) but no wii specific extended range support.

[a432511]

Hello all. I am trying to get the wii-esc firmware to work with my HobbyWing 40A ESCs. They are different than the 30A version so the Plush30A hardware config file does not work. I made a new config file for the 40A version based on the differences that I saw between SimonK's tgy and tp_nfet firmware configs. The tgy firmware is synonymous with Plush30A and the tp_nfet is synonymous with the new config that I am trying to create. Just to be clear, SimonK's tp_nfet firmware is the firmware that works with the 40A version of the HobbyWing ESCs.

After making the changes to the Plush30A config, I was able to get my ESCs to power up with the 3 beep sequence, but I am not able to get the motor to start spinning up. I really have no idea what I am doing as far as the code is concerned. I just used winmerge on SimonK's two different configs to see what I needed to change in the wii-esc configs. I think I am 99% there, but the motors just wont spin up. I am attaching the files that I modified/created.

[vpb]

Hi, has anybody used custom simonk fw, and run 400khz mode with multiwii? we just need to reflash esc and enable #define I2C_SPEED 400000L in the sketch?

[chris ables]

That define is not for esc ! The esc refresh rate is in the output.ino and it is fixed at 490hz if im not mistaken !

[vpb]

So as you said, I need not to modify anything?

[vpb]

I replace 3 turnigy plush 30A with 3 F-30A reflashed with simonk fw. No need to change anything in the config file. It flies great, very stable

[chris ables]

That define is not for esc ! The esc refresh rate is in the output.ino and it is fixed at 490hz if im not mistaken !

The firmware is set at 490hz esc refresh rate and is fixed (not adjustable) ! The only way it can be changed is for a codewriter to rewrite output.ino file ! Hope this helps understanding !

[ziss_dm]

Hi,

Just a quick update. The version 2.0 alpha is available for brave ones This time this is complete re-write from scratch.

What's new:
1) Sigma-delta modulator is used instead of PWM. http://en.wikipedia.org/wiki/Delta-sigma_modulation
- Low noise
- High resolution (current builds have 1600 steps of resolution)
- It has quite big ON and OFF time, which reduces switching losses. On my bench HK SS 18A is working comparatively cool. With 1.1 and RapidESC it is getting extremely hot.
2) ZC detector is refactored again
- Synchronized with SDM
- 2:1 sampling factor
3) Start-up is refactored again
4) Due different filtering method, the dynamic response of the system is significantly increased.
5) Target names now "compatible" with RapidESC, just to make life easier.
6) Pre-compiled .hex available here: http://code.google.com/p/wii-esc/downloads/list

regards,
ziss_dm

[ziss_dm]

Hi a432511,
Is it arming? You should have 4th beep..

regards,
ziss_dm

[crashlander]

Hi,

Just a quick update. The version 2.0 alpha is available for brave ones This time this is complete re-write from scratch.

What's new:
1) Sigma-delta modulator is used instead of PWM. http://en.wikipedia.org/wiki/Delta-sigma_modulation
- Low noise
- High resolution (current builds have 1600 steps of resolution)
- It has quite big ON and OFF time, which reduces switching losses. On my bench HK SS 18A is working comparatively cool. With 1.1 and RapidESC it is getting extremely hot.
2) ZC detector is refactored again
- Synchronized with SDM
- 2:1 sampling factor
3) Start-up is refactored again
4) Due different filtering method, the dynamic response of the system is significantly increased.
5) Target names now "compatible" with RapidESC, just to make life easier.
6) Pre-compiled .hex available here: http://code.google.com/p/wii-esc/downloads/list

regards,
ziss_dm

Any instructions for us with EXT_MOTOR_RANGE wishes?
I have noticed that new version seems to be in C/C++ (not in ASM), what compiler/compiler flags are recommended what are tunable parameters?
Also I'm using TY-P1 ESC that uses bs.hex (by SimonK) and Mystery20A.inc (from pre 2 wii-esc) which HW (hal) option to use now?

Regards Andrej

[ziss_dm]

Hi Andrej,

1) Not yet. But you can adjust receiver settings in config.h
2) I'm using WinAVR-20100110. You can take a look options in "makefile.avr". Also there Code::Blocks IDE project file with all targets/options/etc.
3) Currently I do not have any normal BS board to test. But I have created target, so be careful.

regards,
ziss_dm

[gompf-2]

I would test a HK BS20A at the weekend. On my test ESC I removed the c´s in the back-emv circuite. What would you recommend at the moment: remove or leave them? (full n-FET board, works fine with wii-esc and SimonK´s FW).

[ziss_dm]

Hi,

It is better to remove them. If you want "perfect" results it is good idea to replace them with 30-40pf (instead stock 5n). This reduces jitter with small motors. Works also well with 1.0 and RapidESC.

regards,
ziss_dm

[crashlander]

Hello,
what is the proper range for EXT_MOTOR_RANGE in v2 config.h?
What is the difference (meaning of) RCP_MAX and RCP_FULL?

Code: Select all

#define    RCP_MIN             900
#define    RCP_MAX             2200
#define    RCP_START           1060
#define    RCP_FULL            1860
#define    RCP_DEADBAND        5

Should we leave

Code: Select all

#define    OSC_DEBUG

enabled in final version or is it there only for your (devel) purposes.

[ziss_dm]

Hi,

Should be something like this:

Code: Select all

//*************************
// RC Input               *
//*************************
#define    RCP_MIN             14
#define    RCP_MAX             2200
#define    RCP_START           18
#define    RCP_FULL            2016
#define    RCP_DEADBAND        2

MIN/MAX - valid range, everything outsude is rejected
START - where to start (with min. power)
FULL - where to have full power
DEADBAND - deadband for startup

It is better to disable OSC_DEBUG.

regards,
ziss_dm

[crashlander]

@ziss_dm: thank you for quick answer.
I have noticed that bs.h and bs_nfet.h have same header that is probably NOT O.K.!?

Code: Select all

#ifndef _BS_NFET_H_
#define _BS_NFET_H_

[ziss_dm]

Hi,
I'll fix it, but it should not affect anything as only one header included per target.

Regards,
Ziss_dm

[gompf-2]

Hi,
Feels fine on the bench with 09-18 bs_nfet: BS12A/KDA20-50S, BS20A/KDA20-26M
btw, its still august

[ziss_dm]

Oops..

Updated to "V 2.0.3 alpha":

Safety:
- PPM stream timeout (power off on a signal loss)
- Arming require at least one valid PPM frame

Experimental:
- Automatic oscillator calibration for boards without external oscillator. It uses PPM as a reference and searches best OSCCAL value.

regards,
ziss_dm

[Rob]

@ Ziss

I have the qynx controller tested, with a small engine one of the controllers hold while flying. I think the settings were not correct for this engine.
I must further test.

if RC input below RCP_MIN (by powerup) the controller won't arm.


Furthermore, with these settings I hear and see a small dip with ca.1770us to the input.

//*************************
// RC Input *
//*************************
#define RCP_MIN 900
#define RCP_MAX 2100
#define RCP_START 1100
#define RCP_FULL 1900
#define RCP_DEADBAND 5

(tested with a Hitec HFP-10)

Further change what I made for the Qynx controller:

in M8.h :

Code: Select all

#if (BOARD == _QYNX_)
#warning "INT1 for Qynx target"
ISR(INT1_vect) {
  uint16_t time = TCNT1;
  uint8_t state = (PIND & _BV(3));
  rx_ppm_callback(time, state);
}

inline void AttachPPM() {
  PORTD  |= _BV(3); // activeer pullup
  MCUCR = (MCUCR & ~((1 << ISC10) | (1 << ISC11))) | (1 << ISC10);
  GICR |= (1 << INT1);
}
#else
ISR(INT0_vect) {
  uint16_t time = TCNT1;
  uint8_t state = (PIND & _BV(2));
  rx_ppm_callback(time, state);
}

inline void AttachPPM() {
  PORTD  |= _BV(2);
  MCUCR = (MCUCR & ~((1 << ISC00) | (1 << ISC01))) | (1 << ISC00);
  GICR |= (1 << INT0);
}
#endif

in core.h :

Code: Select all

#if (BOARD == _QYNX_)
  #include "hal/m8.h"
  #include "hal/qynx.h"
#endif

and the qynx.h :

Code: Select all

#ifndef _QYNX_H_
#define _QYNX_H_

//*********************
// PORT B definitions *
//*********************
#define    CpFET           1
#define    BpFET           2
#define    ApFET           3

#define    PORTB_INIT      (1<<ApFET) + (1<<BpFET) + (1<<CpFET)
#define    PORTB_DD        (1<<ApFET) + (1<<BpFET) + (1<<CpFET)
#define    BRAKE_PB        0

//*********************
// PORT C definitions *
//*********************
#define    AnFET           0
#define    BnFET           1
#define    CnFET           2

#define    PORTC_INIT      0
#define    PORTC_DD        (1<<AnFET) + (1<<BnFET) + (1<<CnFET)
#define    BRAKE_PC        (1<<AnFET) + (1<<BnFET) + (1<<CnFET)

//*********************
// PORT D definitions *
//*********************
#define    DbgLED          2
#define    rcp_in          3
#define    DbgStr          4
#define    c_comp          6

#define    PORTD_INIT      (1<<DbgLED) + (0<<rcp_in) + (1<<DbgStr) + (0<<c_comp)
#define    PORTD_DD        (1<<DbgLED) + (1<<DbgStr)
#define    BRAKE_PD        0


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

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

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

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

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

//*********************
// ADC definitions    *
//*********************
#define    mux_a           3
#define    mux_b           4
#define    mux_c           5

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 // _QYNX_H_

And I have set the necessary settings in codeblocks

Very clean and readable code


Rob

[Schachti]

Hello,

I mean here not even a 1/4.
I have the Tiger MT 3506 and they want to fly with the 12 or 20A HK blue.
So I need a bs n-fet with less timing.
This can create a file of for me?

Greetings from Berlin
Schachti

http://translate.google.de/

[funth1ngs]

Hi Schachti,

just use this (release\normal\bs_nfet.hex) package. You don't need to change anything.

Cheers,
Heiko

[Schachti]

and then also runs with the MT3506 650kv ?

[funth1ngs]

Yes, I have the same motors...

Cheers,
Heiko

[bartwaw]

Hi,
is there noticeable difference with this new firmware ?
(compared to simonk 400Hz)

Bartek

[Schachti]

Heiko,

you fly the MT3506 with 4S or 3S?

[dollop]

Hi!
Can somebody help me with the problem. I know that the flight controller is different, but I use the ESC firmware that is discussed here
I experience the problem only with 3S battery . My Xcopter flies perfect with 2S. So my setup is
HK Multi-Rotor Control Board V2.1
HK SS series 15A (flashed by wii-esc. I also tried RapidESC - the same results)
hexTronik 24gram Brushless Outrunner 1300kv
prop 8x4.3
As you can see in the video the copter is uncontrollable on 3S battery. It only can flip after I slide my throttle to make the props spinning...
http://www.youtube.com/watch?v=4Cj_Ye42eBc&feature=plcp

So may be there are some parameters in firmware that I can change to fix the problem?

Thank you

[bosondehiggs]

Hello i have 4 hk-ss30A flashed with tp.hex. (http://www.rcgroups.com/forums/showthread.php?t=1513678)
Can they works with multiwii 2.1 or i need to reflash with wiiesc hex?
What are the options to configure?

thanks

[chris ables]

Hello i have 4 hk-ss30A flashed with tp.hex. (http://www.rcgroups.com/forums/showthread.php?t=1513678)
Can they works with multiwii 2.1 or i need to reflash with wiiesc hex?
What are the options to configure?

thanks

Just uncomment the simonk esc near the top of config.h in 2.1 version firmware !

[ziss_dm]

Hi,

@Rob: I have commited support for qynx target. Could you please check that everything is correct. Also could you please describe your problem in more detail? Is it clicking sound on high RPM? Is it without load? Currently there are no "soft" RPM limiter, like it was before. The motor will accelerate until it would start loosing sync after that sync recovery reduces power.

@dollop: Looks like you need to adjust throttle endpoints in firmware.

@chris ables: True, but this will give you only 125 steps of resolution on ProMini. With extended range you can get 250 steps, which makes a difference.

regards,
ziss_dm

[funth1ngs]

Hi,

you fly the MT3506 with 4S or 3S?

I have tested V2 with 3S/4S and 12x4.5 on my bench... Sync recovery works perfect!

Cheers,
Heiko

[Schachti]

super, danke

[Rob]

Hi,

@Rob: I have commited support for qynx target. Could you please check that everything is correct. Also could you please describe your problem in more detail? Is it clicking sound on high RPM? Is it without load? Currently there are no "soft" RPM limiter, like it was before. The motor will accelerate until it would start loosing sync after that sync recovery reduces power.
regards,
ziss_dm

qynx implementation work properly !

The problem I had is that with a heavy payload 1 of the engines stopped by quickly raising the trottle.
Today I have tested again with another quad (same engine type same payload). No problems, I think that the settings were not correct.

Next week I have the problem quad rebuilt and will test again, I do not think it is a software problem.

Rob

[ziss_dm]

Hi,

Updated to "V 2.0.4 alpha":

- Complementary PWM support for all-n-fet boards.

regards,
ziss_dm

[sim]

Hi, ziss_dm! (and Heiko and others )

I just tried 2.0.4 (and SVN head) on an F-30A board. Starting seems much improved, pretty cool!

I did notice on an MT3506 and a Turnigy/Keda 2213 1050KV motor that the throttle seems to have some bumps, with either normal or complementary PWM. It seems like a significant rounding error or perhaps some sort of busy wait or interrupt interaction. There's a big bump near the bottom where a tiny bit higher input speeds up the motor significantly, and at least one more near the top of the range where the motor slows down while raising the input. How did you manage 4000 PWM steps if still using div8 for the timer? Btw, I noticed GCC 4.7.1 added a uint24_t type, which might be useful. In my asm tree I had to switch most things to 24bit once I dropped the timer divisor, while 32 bits would incur significant overhead.

I actually had tried a "spread spectrum" PWM mode in my tree where on each PWM update, the on and off times were multiplied integer-fractionally by a pseudo-random number between 1 and 2, resulting in a frequency spread of, for example, 4-8kHz. This actually worked fairly well. However, I was doing it to try to make the HK-SS25A board sound better than at 8kHz, and I didn't really feel that it was any better (no single pitch whine, but overall louder), so I ended up stashing that code. Starting a purposely stalled motor makes a similar waterfall sound in your Delta-Sigma implementation as in my old code...I suspect you are only updating on commutation steps when starting, as I did.

Complementary PWM support seems to work better than I was expecting. When I was looking at active freewheeling/synchronous rectification support, I was concerned with trying to sense the best FET timing to avoid deceleration, but I suppose just doing it for the full cycle (or measuring on time and adjusting to try to avoid overlap but otherwise keep it on for the full PWM-OFF time) and keeping the deceleration effect may actually be beneficial. I was thinking about measuring pull-up and pull-down times during the starting beeps, etc.

Out of interest, did you ever try doing demagnetization tracking instead of sync recovery? I am still trying to get this to work in my tree..

Simon-

[ziss_dm]

Hi Simon,
How is your vacations?

Actually there are no divisions and even timer interrupts. There are only one interrupt source enabled, which is INT0.
So, i would guess you have BEMF filter caps still in place. It does not like them any more

How did you manage 4000 PWM steps if still using div8 for the timer?

Generally concept is simple: http://en.wikipedia.org/wiki/Pulse-density_modulation. So, there are 1 bit first order SDM. Due the fact that it has integrator, it is not necessary to sample it precisely. It even benefitial to add some noise to the sampling. So SDM generation scheduled as Idle task using prothothreads, without any timer or interrupt. This also allows to naturally sync SDM generation and Analogue comparator sampling. Qantizer value can be any as soon as the integrator not overflowing. So currently all measured range passed directly to the SDM without any transformation, which is ~4000 points with extended range, 1600 with standard one.

Btw, I noticed GCC 4.7.1 added a uint24_t type, which might be useful. In my asm tree I had to switch most things to 24bit once I dropped the timer divisor, while 32 bits would incur significant overhead.

Hm.. I always wanted to ask why you did this? For measuring input pulses it is not beneficial (without ICP) as you have other interrupts and lot of places where interrupts are disabled, so jitter is significant. For timing purposes it is also seems to be overkill, as a jitter in ZC detector is 2-3us in best case scenario and scalar control is not reliing on precise timing.

Out of interest, did you ever try doing demagnetization tracking instead of sync recovery? I am still trying to get this to work in my tree..

Yes, I have tried to measure kickback length and limit power if it close to threshold. It even worked. The problem was the treshold value. For some motors it should be quite early, for others it reduces dynamic response significantly. ;(
I also belive that kickback is not biggest problem here. By the nature, scalar control has limited dynamic response during acceleration and we are hitting this limit. If you connect stroboscope controlled by commutation cycles and look to the rotor during acceleration, you actually can "see" it.

regards,
ziss_dm

[sim]

Hi Simon,
How is your vacations?

Actually there are no divisions and even timer interrupts. There are only one interrupt source enabled, which is INT0.
So, i would guess you have BEMF filter caps still in place. It does not like them any more

Our vacation was awesome, thanks! I didn't miss flying until we got to some awesome open field areas in Slovakia.

I will try with the caps removed again. I see you now have a table with a few holes for a successful ZC filter result, and the filter length does not seem to be based on timing anymore. I'm not quite seeing what you are doing other than making a filter that can swing either way by about 5 bits worth. Is this right? Is this better than a limited value in a byte?

Generally concept is simple: http://en.wikipedia.org/wiki/Pulse-density_modulation. So, there are 1 bit first order SDM. Due the fact that it has integrator, it is not necessary to sample it precisely. It even benefitial to add some noise to the sampling. So SDM generation scheduled as Idle task using prothothreads, without any timer or interrupt. This also allows to naturally sync SDM generation and Analogue comparator sampling. Qantizer value can be any as soon as the integrator not overflowing. So currently all measured range passed directly to the SDM without any transformation, which is ~4000 points with extended range, 1600 with standard one.

So, in theory, the jitter from the RC signal not matching the clock ticks will average out, and the result will be "dithered". Wouldn't the same thing happen with a fixed PWM frequency was fixed and tied directly (with no scaling aliasing) to the RCP input? I understand that varying frequencies will hide some of the edge-bump issues.

Hm.. I always wanted to ask why you did this? For measuring input pulses it is not beneficial (without ICP) as you have other interrupts and lot of places where interrupts are disabled, so jitter is significant. For timing purposes it is also seems to be overkill, as a jitter in ZC detector is 2-3us in best case scenario and scalar control is not reliing on precise timing.

The change came primarily from wanting more precision on the RC pulse input. Since there's only the one 16-bit timer, tracking timing in 24-bits came as a side-effect. I agree that it's not needed for motor timing based on the precision of the ZC filtering and everything else. So, with throttle calibration, I just scale the 24-bit RC pulse length to a 16-bit PWM duty cycle with a 16.16 multiplier that is usually around 4096 (16 ticks per µs * 4096 >> 16). It feels wrong to work only with µs or half µs input and then try to scale it, but since most ESCs only have 100ish steps anyway, it's probably fine. I really should set up a test rig for this.

Yes, I have tried to measure kickback length and limit power if it close to threshold. It even worked. The problem was the treshold value. For some motors it should be quite early, for others it reduces dynamic response significantly. ;(
I also belive that kickback is not biggest problem here. By the nature, scalar control has limited dynamic response during acceleration and we are hitting this limit. If you connect stroboscope controlled by commutation cycles and look to the rotor during acceleration, you actually can "see" it.

I first experimented with longer blanking windows, and saw the limited dynamic response very easily. I suspect even a fixed 15° blanking window is limiting the acceleration of some motors and actually causing sync problems (especially with the timing being updated in quarter-averages), but that happens so quickly that it would be difficult to see. It seems that you have set the blanking to 7.5° and there is no averaging. Is that right? When I test with a hard drive motor that exhibits the demagnetization/sync loss problem, I can feel the sync recovery as bumpy thrust instead of it being perfectly smooth. It's not bad, but still makes me want to try to get it to cut the power early or something instead of trying to correct the timing after the fact.

[ziss_dm]

Hi,

Our vacation was awesome, thanks! I didn't miss flying until we got to some awesome open field areas in Slovakia.

Lucky you!

I see you now have a table with a few holes for a successful ZC filter result, and the filter length does not seem to be based on timing anymore. I'm not quite seeing what you are doing other than making a filter that can swing either way by about 5 bits worth. Is this right? Is this better than a limited value in a byte?

This is just table implementation of the "majority" filter. It says "true" when first 3 bits has more "1"s than last 3 bit has "0"s. I need different type of filter as I cannot sample ACO as fast as before. It has fixed delay ~3 sample cycles. The old "penality" filter is still used on startup.

So, in theory, the jitter from the RC signal not matching the clock ticks will average out, and the result will be "dithered". Wouldn't the same thing happen with a fixed PWM frequency was fixed and tied directly (with no scaling aliasing) to the RCP input? I understand that varying frequencies will hide some of the edge-bump issues.

Not exactly.

* In your scheme there are no integrator to "remember" previous errors.
* 1 bit SDM automaticaly varying base frequency to fit resolution and minimum on/off time. As a result:

* Lower switching losses as FET's have enough time to properly open/close (currently min on/off ~4us)
* More linear power curve by the same reason.
* Lower noise in working range. Yes, the base frequency drops to 1khz at 99.99% but it is not really critical as commutation noises are much higher there.
* I also try to prevent RC input jitter
* Only one interrupt is enabled
* Interrupts are disabled only to read TCNT1, which is 4 cycles
* With 1/8 prescaler jitter is not measurable, there are still 1 bit Quantization noise, but no jitter. Pretty much same as with ICP

I just scale the 24-bit RC pulse length to a 16-bit PWM duty cycle with a 16.16 multiplier that is usually around 4096 (16 ticks per µs * 4096 >> 16)

Not sure, I think, same rusult would be if you just shift left value with 1/8 pre-sacaler. But maybe I'm wrong.
Anyway, currently I do not need to scale as SDM scaling automativcally, so 1/8 pre-scaler seems to be good option.

I suspect even a fixed 15° blanking window is limiting the acceleration of some motors and actually

I think, even more: all intervals based on previous timing information...

It seems that you have set the blanking to 7.5° and there is no averaging. Is that right?

Yes I have 7.5° blanking time and 2 taps FIR instead of IIR for timing. 2 taps FIR still needed because ZC detection in LH and HL transitions is not symmetrical.

I can feel the sync recovery as bumpy thrust instead of it being perfectly smooth. It's not bad, but still makes me want to try to get it to cut the power early or something instead of trying to correct the timing after the fact.

I'm starting to belive that we just do not have enough information. ;(

Another way could be:
- implement bus voltage measurement
- implement motor Kv measurement (test run without props and store result in EEPROM)
- implement power limiter based on current RPM and bus voltage.

BTW: I have LTSpice simulation of ZC detector, it is quite interesting. Want to take a look?

regards,
ziss_dm

[sim]

* In your scheme there are no integrator to "remember" previous errors.
* 1 bit SDM automaticaly varying base frequency to fit resolution and minimum on/off time. As a result:

* Lower switching losses as FET's have enough time to properly open/close (currently min on/off ~4us)
* More linear power curve by the same reason.
* Lower noise in working range. Yes, the base frequency drops to 1khz at 99.99% but it is not really critical as commutation noises are much higher there.
* I also try to prevent RC input jitter
* Only one interrupt is enabled
* Interrupts are disabled only to read TCNT1, which is 4 cycles
* With 1/8 prescaler jitter is not measurable, there are still 1 bit Quantization noise, but no jitter. Pretty much same as with ICP

sdm_ref and thus sdm_err seem to take input only from rx.raw, so I still don't understand how any other error can be incorporated other than its own error for the purposes of modulating. The exact pulse timing is still up to the sender, so we still have to hope that it spreads smoothly and often around the div8 ticks to hide the quantization. You're probably right in that this matters little in practice, and the fact that it takes care of scaling at the same time is really nice.

It seems that to check for timer expiry, it is much faster to have a slower interrupt once than to constantly lock/read/compare to check for expiry. Of course, you can only have two timers this way. Too bad that with the AVR, even "ret" causes 4-cycle interrupt jitter. :/

Yes I have 7.5° blanking time and 2 taps FIR instead of IIR for timing. 2 taps FIR still needed because ZC detection in LH and HL transitions is not symmetrical.

Yes, I see this asymmetry on the F-30A in particular, especially at lower speeds. I'm not seeing 2-tap FIR, only "est_comm_time = (last_comm_time + comm_time)" in update_timing(), which seems to be IIR?

I'm starting to belive that we just do not have enough information. ;(

Another way could be:
- implement bus voltage measurement
- implement motor Kv measurement (test run without props and store result in EEPROM)
- implement power limiter based on current RPM and bus voltage.

ESC32 is doing it this way (a full calibration process). There are a bunch of factors that get calibrated (with prop) and then math which guarantees that current will always stay within desired limits. Though this is probably the ideal solution, I'd still be happier with something that just works, for the most part, without a calibration process.

BTW: I have LTSpice simulation of ZC detector, it is quite interesting. Want to take a look?

Sure, I would love to see the LTSpice simulation!

[ziss_dm]

sdm_ref and thus sdm_err seem to take input only from rx.raw, so I still don't understand how any other error can be incorporated other than its own error for the purposes of modulating. The exact pulse timing is still up to the sender, so we still have to hope that it spreads smoothly and often around the div8 ticks to hide the quantization. You're probably right in that this matters little in practice, and the fact that it takes care of scaling at the same time is really nice.

Initially I had dt there but could not see any benefit.

It seems that to check for timer expiry, it is much faster to have a slower interrupt once than to constantly lock/read/compare to check for expiry. Of course, you can only have two timers this way. Too bad that with the AVR, even "ret" causes 4-cycle interrupt jitter. :/

You even can do something like this:

Code: Select all

static inline void __hw_alarm_a_set(uint16_t ticks) {
  uint8_t __sreg = SREG;
  cli();
  OCR1A = ticks;
  SREG = __sreg;
  TIFR = _BV(OCF1A);
}

static inline uint8_t __hw_alarm_a_expired() {
  return TIFR & _BV(OCF1A);
}

But.. that means relative time intervals, which is not flexible.

I'm not seeing 2-tap FIR, only "est_comm_time = (last_comm_time + comm_time)" in update_timing(), which seems to be IIR?

It does not have feedback, so it is FIR.

Simulation:
http://wii-esc.googlecode.com/files/mot ... ls_pwm.zip

[sim]

Simulation:
http://wii-esc.googlecode.com/files/mot ... ls_pwm.zip

That simulation is awesome! Maybe I don't need a 4-channel scope after all. If you set the PWM duty higher, such as 0.95, you can even see the demagnetization start to cause the early comparator swing. Lower phase resistance and higher inductance makes it even worse, as expected. Starting with (or I guess keeping in this case ) a lower back-EMF such as 10V (like with a motor that was running at 50% duty) brings the demagnetization in further than 30°, making it impossible to see the zero crossing. This is what causes the sync loss.

What difference per motor were you seeing when tracking the demagnetization? I was hoping that the time that the current is still flowing could just be measured and then used to turn off the next step's power by that many ticks. However, since this is reactive, the first step where the PWM increase occurred may already be too late. Perhaps it would be enough to start a 30° timer at the beginning, waiting for the (filtered) comparator to be the opposite of the edge we are looking for. If we don't see it by the time that timer expires, we turn off power (or halve it or something), wait another 30°, and turn back on power at the next commutation step. This should result in there being no demag and no sync loss, just a power cut for 30°. Do you think this would work?