You can connect LED to SCK line of ISP connector, this is my DbgLED In case it is on, was ZC recovery..

r75: btw, you can use movw temp1, temp3, instead of the two movs, when the registers are in order. Also, there is a redundant sei near the top of update_timing.

Tnx.

Trying r84, startup seems much better, but I'm not quite sure why. Is that just the MSB change?

Looks like, I found it experimenting with over-clocked Plush.

I can't start the HD on this BlueSeries 30A board because it keeps getting false timing and makes tones instead of turning,

For me it starts quite reliable on 16Khz PWM. If you interested, I can commit config. But still it is not clear for me, which is better: PWM synced comparator scan, but not filtered or filtered, but asynchronous.

Starting with 3 props on one motor doesn't work reliably and not at all unless I have at least 13V input voltage.

Even with higher PCT_PWR_STARTUP?

I'm surprised that you actually got it to work so well considering that there does not seem to be any alignment to PWM.

There are couple: - It is correcting on/off cycles, taking into account ISR overhead- It is performing last cycle without exiting from ISR

the spikes are still there. Is it possilbe that the filter is causing some "input lag"?

Yes, and looks like I can see it on the graph. But looks like it also limiting the current (was 42 now 36, and taking into account that now your battery in better condition, it is quite sugnificant). The question is: Is it worth it?Is it still screming?

EDIT: Looks like you changed time base.. So step response still the same ~500 msec?

Not necessarily, because the sample rate is really slow. I measured spikes up to 45A with r90.

The question is: Is it worth it?

Nope it's not, because we also lose the fast response at normal changes. And the case with a 70% throttle jump will almost never happen .

Is it still screming?

Yes, sometimes. But only for some seconds. I will make a short video tomorrow, because I also have some resets when idle throttle is to low.

funth1ngs wrote:I have timing problems (screams) on the first 3-4 fast throttle changes, but then they are gone until the ESC is restarted. Is it possible to make a special version which writes the working timing values into the eeprom, then we can read the eeprom an use them as start values in the normal version?

It this possible or am I completely wrong ?

EDIT: Looks like you changed time base.. So step response still the same ~500 msec?

Hm yeah, but as you can see on the older picture, the begin of the throttle and power jump happens nearly at the same time. On the newer pictures it is always delayed by around 50ms. I will verify that tomorrow.

I have timing problems (screams) on the first 3-4 fast throttle changes, but then they are gone until the ESC is restarted. Is it possible to make a special version which writes the working timing values into the eeprom, then we can read the eeprom an use them as start values in the normal version?

The timing is constantly updated on each commutation. I think, that most reasonable explanation is that battery is slightly discharged.

BTW: It also would be interesting if you can do the same with "working" motor. Maybe we can see the difference.

Hi all!First of all I want to thank you guys for this alternative ESC firmware. I saw some results and looks realy nice. I going to reflash my Mystery 20A with this firmware too but have some questions:

- What version should I use? Latest from svn ? O maybe hex file attached to topic? - For mystery 20A should I remove capacitors ? or this is not required? - And last one question, I know there are some function to protect ESC when motor stop imediately but in practice did you burn ESC when you have some accidents in a fly ?

Maybe this is not important but I'm going to use this ESC with KDA 20-22L (924kv).

- For mystery 20A should I remove capacitors ? or this is not required?

I have one ESC with them and one without them on my bench and don't notice any difference, so I wouldn't remove them. I only removed the the capacitor in PPM_IN, because it caused trouble with the 1-wire bootloader. But if you don't plan to use a bootloader, you don't need to remove it . Which ESC do you have exactly (Mystery, HobbyKing, all nFets...)?

Maybe this is not important but I'm going to use this ESC with KDA 20-22L (924kv).

Could you tell me more about one wire bootloader. I want to try different compilation with pwm_arduino_250.inc, pwm_fast_200.inc etc. to compare results and this is a little hard to disassemble everything to upload new firmware. I understand that you can change firmware using PPM_IN, but you compile wii-esc with different flags?

- Build this flash adapter. I think we don't need the pullup/pulldown stuff (R2) because we don't connect more than one ESC at a time. As I understand it, it also depends on the resistor which is connected to PPM_IN on the ESC. In my case it's a 220R, so I don't need a pullup/pulldown.

- Download this package. Now you need to decide if you would like to flash all ESCs with the same BL-ID (BootSign). Since we can connect the ESCs individually, it doesn't matter (the ARM-o-Kopter uses a UART bus). If you would like to change the IDs just let me know then I will explain it.

- Use AVRootloader.exe to flash the wii-esc firmware: Unpower the ESC, connect the flash adapter, hit connect in the flash tool and then power up the ESC. If everything works, you should now be able to flash it (Sign=ESCBL1) .

ENOUGH_GOODIES - number of successful electrical rotations before checking RPM. RPM_START_MIN_RPM - minimal RPM for transition to runRPM_STEP_INITIAL, RPM_STEP_MAX - initially when there no back EMF, it starts commutation with RPM_STEP_INITIAL speed and accelerates up to RPM_STEP_MAX. For a good start you need to provide enough power to rotate motor (with load) at least at RPM_STEP_INITIAL and motor should be able to produce detectable back EMF somewhere inside this range.

RPM_RUN_MIN_RPM - below this RPM it exits from run mode. Currently we have 2 cases: - if current power is lower than PCT_PWR_MAX_STARTUP it goes to startup - if higher - reset

funth1ngs wrote:- Build this flash adapter. I think we don't need the pullup/pulldown stuff (R2) because we don't connect more than one ESC at a time. As I understand it, it also depends on the resistor which is connected to PPM_IN on the ESC. In my case it's a 220R, so I don't need a pullup/pulldown.

So if I want to program only one ESC in the same time I need to only put resistor R1 between TTL-RX and TX? And there is no information about resistor values for Mystery 20A but this should be something about 4,7k-10k ?

So if I want to program only one ESC in the same time I need to only put resistor R1 between TTL-RX and TX? And there is no information about resistor values for Mystery 20A but this should be something about 4,7k-10k ?

R1 (2k2) has something to do with the 1-wire stuff, you need this one in any case. R2 is either used as pullup or pulldown and the value depends on the ESC (there are different resistors connected to PD0/PD2) and the number of ESCs. In my case (HobbyKing Blueseries 20A all nFET) the series resistor on the ESC has 220R, and I don't need R2 at all.

For example, here is a schematic, R24 is 220R in my case and C8 needs to be removed.

Yes I calculated fusebits again and need to confirm that value 0xCA is better than 0xD8 But back to 1-wire bootloader. Yesterday I've prepare testing ESC, solder ISP holder and burn Mystery 20A + pm_arduino_250. I can startup engine so I think it is ok. But also tried to use method described above with bootloader but without success - can't connect from PC program. But I don't remove any capacitor because can find correct. Could you make describe with one did you remove ?

But also tried to use method described above with bootloader but without success - can't connect from PC program. But I don't remove any capacitor because can find correct. Could you make describe with one did you remove ?

It will not work with the capacitor, try to remove the one in the red rectangle.

ENOUGH_GOODIES - number of successful electrical rotations before checking RPM. RPM_START_MIN_RPM - minimal RPM for transition to runRPM_STEP_INITIAL, RPM_STEP_MAX - initially when there no back EMF, it starts commutation with RPM_STEP_INITIAL speed and accelerates up to RPM_STEP_MAX. For a good start you need to provide enough power to rotate motor (with load) at least at RPM_STEP_INITIAL and motor should be able to produce detectable back EMF somewhere inside this range.

RPM_RUN_MIN_RPM - below this RPM it exits from run mode. Currently we have 2 cases: - if current power is lower than PCT_PWR_MAX_STARTUP it goes to startup - if higher - reset

Oh, and i almost forgot to post some oscilloscope measurements of the MT3506 from Simon:

Simon wrote:Here are some from when I tried to do a differential measurement at theACO AVR pins by doing math on my two-channel scope:

...

I'm not sure how accurate the timing/spike behaviour is on both channels,though, so a real differential probe would probably be better. However,you can clearly see the commutation steps (every 1ms in the not fullspeed case), and the noise it has to deal with, even on this AfroESCboard with filtering capacitors. That is modified code that had no delayafter zero cross, so it goes immediately to the next commutation stepafter detecting the crossing. The zero crossing is when the purple linecrosses its zero point. (The noise on the purple line only cancels outevery 1 of 3 commutation steps, so ignore the rest.)

I didn't realize you saw problems even with slow throttle increases. Does this also happen with my tree? I thought it was only a fast response change problem. This is with a 14" APC prop?

It's possible that the motor is just saturating due to too much current. It's rated for 14.5A and 200W according to http://www.rctigermotor.com/show.php?contentid=142 , and you are seeing the problem start at around 16A @ 16V (256W). I wish there was some simple way to collect a full high speed log of the whole drive and zero-crossing detection, like a 4-channel oscilloscope with long buffer. Hmm, perhaps it would work to trigger the scope from one of the unused pins when commutation loss is detected? At least then we could look at what is happening right around when it failed, on a digital scope.

Those scope pictures I posted were not from full load, but if you look at a shorter timescale, the noise patterns change as the motor current increases. The kick-back takes longer to demagnetize and so this affects the noise at the comparator -- the swing back to high stays high longer until the current stops and the undriven phase sees just backEMF. It's almost like a current sense by pulse length. The high part stays high longer based on current, while the lower part is just the length of the PWM ON cycle (and this is proportional to drive voltage). This scope screenshot is just one phase, not at the comparator which has the neutral subtracted, but if you imagine noise each time the signal changes, you can see how picking up a valid zero-crossing can be difficult: http://0x.ca/sim/tmp/motor_phase_zoom.png

If the motor saturates, I would expect the current to start spiking excessively at the end of the PWM ON cycle. I'm not quite sure what would happen next, however.

I was just thinking: Maybe we are looking in wrong direction? Maybe something wrong with this "virtual" charge pump on this boards? As I remember you mentined that Plush is working just fine for you?Can I also ask you to check voltage on charge pump capacitor with your scope? regards,ziss_dm

sim wrote:I didn't realize you saw problems even with slow throttle increases. Does this also happen with my tree? I thought it was only a fast response change problem. This is with a 14" APC prop?

Yes, I didn't notice that before, it only occurs on a fully charged 4S. With your current tree, I can't reach full throttle at all. The prop was a EPP 13x4.5".

sim wrote:It's possible that the motor is just saturating due to too much current.

I switched to a Graupner 11x5" E-Prop today, and it's way better. I still can't reach full throttle with your tree, but with ziss_dm's version it works quite well. There is still some noise, but it's only a very short click. So you are right, the 13" prop is causing too much load on a 4S.

ziss_dm wrote:I was just thinking: Maybe we are looking in wrong direction? Maybe something wrong with this "virtual" charge pump on this boards?

This made me to open another ESC. Unfortunately it looks like that is's also using a charge pump. I tried it anyway and figured out that it has the same pin assignment than the BlueSeries ESCs. To my surprise it works with the Mystery20A.inc without any changes . Compared to the HK BlueSeries all nFet ESC it's even a little bit better (the clicks are quieter and nearly gone) (11x5" E-Prop and 4S)). The 2 capacitors are 330uF/25V, on the my BlueSeries board are currently 2x220uF/35V. Do you think if I increase them to maybe 2x470uF/25V can help?

Cheers,Heiko.

Attachments

Turnigy TY-P1 25A

Last edited by funth1ngs on Sat Oct 29, 2011 9:28 am, edited 1 time in total.

Well, there are a couple of problems here. I saw your problem originally on Plush at 15.8V, with a 10x4.7 prop on the MT3506. I made some changes, and it was totally fixed for me, so I was happy, and posted, and you said it didn't fix it. So, I ordered a BlueSeries 20A and 30A. The stock firmware seemed to work with them and the MT3506 at 15.8V, but with slow throttle response, as expected. I was surprised to see that they went with 16kHz PWM for startup but defaulted to 8kHz for run mode. Anyway, when I tried my tree, I noticed that the backEMF sense either has differently-timed noise or is for some reason more noisy/less sensitive, since driving any of my motors with my tree is much worse than the Plush at slow speeds. Also, it missed like the Plush did when accelerating quickly to full throttle, even though that was fixed for me on the Plush. D'oh! Finally, it suffers from resets at high current even though this never happens on the Plush.

I haven't tried >15.8V on the Plush since the capacitor that they shipped with it is only 16V, even though they rate it for 16.8V. I need to swap it for a 25V cap and compare. Also, I haven't tried removing the BlueSeries backemf sense capacitors yet, but I just got an smd rework station today, so I can try that, but I'm really not expecting it to make much difference. I also don't have a high-ampere 16.8V source to compare with, just an 18V supply at about 5A, so I probably need to order a 4S lipo to see exactly what you are seeing.

Newer ESCs, in particular the TowerPro "type 3" boards, are switching to gate drivers (finally), with a charge pump for the gate drive. The nFETs are inverted on those boards, but it seems that Turnigy TY-P1 25A HexFET ESC is yet another variant without inverted drive. It's weird that they went with the original Mystery pin configuration, hmm. Using both sides of the comparator allows the ACME to be turned off and the ADC during that cycle, so they can sample voltage/temperature without having to stop sensing timing, but the original and all-nfet Mystery pin configuration requires ACME and ADMUX to always be on. Also, you can't do any simplifications with a single out to turn off all NFETs regardless of commutation stage, etc.

Anwyay, there is no charge pump on my BlueSeries 30A, but there is a small 7805 type regulator just for VCC, separate from the BEC, and even though it has a regulation output capacitor, I see voltage across that comparator drop below 2.7V when the AVR resets. I'll take a scope screenshot so you can see what I mean. I'm thinking the sense noise might be a lot more difficult when combined with the fact that there is also this pulse noise on A(VCC) as well.

With gate drivers, I would really be inclined to PWM switch on the high side instead of the low side. I did this even on the Plush and it worked surprisingly well, especially considering that it only had transistors for gate drive and it was actually switching the pFETs. I even tried a variant which switched high and low at the same time. In theory, if the fets turn on and off at the same time, the motor voltage average always stays in the middle and the comparator does not even need a neutral reference, it can just use half of the input voltage. I figured backEMF sampling noise would thus be lower, but alas the fets of course turn on and off at different times, so I didn't notice any improvement at the time. Also, I didn't do any load tests and I figure that without gate drivers, it would probably behave badly at higher currents. But with all nFET boards, maybe..

Hi again,So I tried this software with Mystery 20A (nFet + pFet) and KDA 20-22L but have some problems. I tested revision 44, 65, 79, 82, 106 and first version from this topic attached to this post:http://www.multiwii.com/forum/viewtopic.php?f=13&t=516&start=20#p3044All version was compiled with pwm_arduino_250.inc, and of course I've changed MWC code to use extend resolutions. All version have a huge problem with motor startup, motor shaking about 3-5s then start working normally - all version except this attached to post above. It works without any problems. So I think changes related with Mt motors is not good for other motors... But I can still use first version compiled int this topic .

I have some question for Mystery 20A users. I had some crashes when testing this software (because testing to high PID values, and landing in a grass, on the wall etc but luckily didn't burn any mosfet, so did you guys burn anyone when you stop propellers ?

today I played again with my MT3506 . I limited MAX_THROTTLE to 185 steps, and with the BEMF feedback capacitors removed the "screams" are completely gone, even with a 13x4.5 prop and a fully charged 4S battery. So I must retreat my previous statement that the behavior is the same with or without capacitors, it's a little bit better without them.

The only remaining problem are the resets which happen sometimes when idle throttle is increased too fast. So i recorded this short video. In the first half of the video the software is untouched, in the second half I flashed a modified version with resets disabled.

All version have a huge problem with motor startup, motor shaking about 3-5s then start working normally - all version except this attached to post above. It works without any problems. So I think changes related with Mt motors is not good for other motors...

@marbalon: Can you try the latest 0.11 tag? For my setups it is finally better or equal to the original one.

I have some question for Mystery 20A users. I had some crashes when testing this software (because testing to high PID values, and landing in a grass, on the wall etc but luckily didn't burn any mosfet, so did you guys burn anyone when you stop propellers ?

The latest versions should be quite safe. I'm doing stop tests from half throttle. The erly ones may or may not burn FET's, depends on luck.

@Heiko:

I limited MAX_THROTTLE to 185 steps

But you are "loosing" 45W of power (according to the graphs), so maybe smaller prop is better? I also noticed that you always start ramping from different RPM. Can you try to fix initial RPM to fixed value? Maybe we have some treshhold, after which it start resetting? Would be fun if it is 1200 RPM BTW: How you generating input? Manually?

I noticed with resets disabled that the motor nearly stops for a very short time, then immediatly accelerates to full speed.

This is quite explainable: it goes to startup, performs pre-align (motor stops), starts and than slowly ramping to full power.

Sadly enough, I've made same mistake. There are limits for lower RPM value, due the 17bit timer we using. ;(The limits are:~75 rpm for 8mhz boards and ~150 rpm for 16mhz boards. In case you setting lower than that, it is overflowing and rpm would be actually higher than intended.

ziss_dm wrote:@marbalon: Can you try the latest 0.11 tag? For my setups it is finally better or equal to the original one. The latest versions should be quite safe. I'm doing stop tests from half throttle. The erly ones may or may not burn FET's, depends on luck.

Will try on my backup motor and ESC. This will be a little hard in my quad because I need to disassemble it to get an access to ESC (I have ESC between centerplates - foto here). But I found that sometimes motor don't have a problem with startup without propeller but with propeller situations maybe be different. Will try to give you feedback soon.

funth1ngs wrote:Hi simon and ziss_dm,...This made me to open another ESC. Unfortunately it looks like that is's also using a charge pump. I tried it anyway and figured out that it has the same pin assignment than the BlueSeries ESCs. To my surprise it works with the Mystery20A.inc...Heiko.

Hello,can you please post a picture of how-to connect Tgy TY-P1 for flashing.Subquestion does this ESC originally works with MultiWii (with original firmware)?

But you are "loosing" 45W of power (according to the graphs), so maybe smaller prop is better?

Yes and no, it's all about efficiency at hover throttle . For example, with a 11x5" the max thrust is 800g and with a 13x4.5" it's 1100g. If the max thrust of the 13x4.5" needs to be limited to 800g, but the efficiency at hover throttle is better, I prefer to use the bigger prop.

I also noticed that you always start ramping from different RPM. Can you try to fix initial RPM to fixed value? Maybe we have some treshhold, after which it start resetting? Would be fun if it is 1200 RPM BTW: How you generating input? Manually?

I use an AVR development board with a poti and a self written software to generate a 400Hz PWM signal. Unfortunately, there is no constant treshold. The higher the voltage, the higher must be the RPM. And even at a fixed voltage the treshold fluctuates around 100-200 RPM:

But thats no problem, because I always use some idle throttle. It just needs to be high enough to prevent resets. As long it's below hover throttle, everything is fine . For the MT3508 the min idle throttle generates a thrust of 40g, what makes 240g on a hexa. Compared to the hexa weight of 1500g it's OK. I only thought it would be more fool proof if the resets could be prevented at all.

Another question: Is it possible to have the full POWER_RANGE between PCT_PWR_MIN and 100% (or even better PCT_PWR_MAX ) and start the motor always at MIN_RC_PULS?

Example (POWER_RANGE=200): At the moment with PCT_PWR_MIN=15 the "real" resolution would be 200-0,15*200 = 170 steps. The required pulse length to start the motor is 1100+(1900-1100)*0,15 = 1220us. It would be easier to understand, if the motor always starts at MIN_RC_PULS=1100, but with a start duty cycle of PCT_PWR_MIN=15. And the 200 steps POWER_RANGE are aligned to the remaining 75%.

But I think the resoultion of the timers is a problem, and maybe the math gets to complicated for the AVR.

ziss_dm wrote:Can you try the latest 0.11 tag? For my setups it is finally better or equal to the original one.

I've just made some tests on one motor and ESC - this is not good test because sometimes one pair in my quad (motor+ESC) works fine with one firmware but other pair (of course the same models) have a problem with startup. But back to test results. I've uploaded version r82 and have huge problem with startup. Then uploaded version from tag 0.11 and motor make few rotation with some problems (a little noisy) but then works fine. Then I've added modifications suggested by Heiko:

#define PCT_PWR_STARTUP 20#define PCT_PWR_MAX_STARTUP 25

And motor start with a short grind but much better then on original 0.11. But it is far away startup comparing this to original or Quax version (first working in this topic) - this firmwares start smoothly and without any any problems. I 'ca try to upload this firmware to all ESC but do your think you can try to tune startup procedure to work better?

What motors/props are you using? And have you removed back EMF feedback capacitors?And if you like experiments, you can try to adjust STRT_ZC_FILTER_DELAY in core\str_zc_filter.inc. I think, you can lower it little bit.

The idea is:- When you rotate pot, it can change fast but not immidiate, so motor can keep up and everythingis fine- When RPM is low, the limiter limiting power to 50% and this is good, but than motor reaches treshhold RPM it can generate "step" change in power

What motors/props are you using? And have you removed back EMF feedback capacitors?And if you like experiments, you can try to adjust STRT_ZC_FILTER_DELAY in core\str_zc_filter.inc. I think, you can lower it little bit.

regards,ziss_dm

Hi,My setup is KDA 20-22L + Mystery 20A (old version with p+nFet) + prop 10x4.5. And I like experiments so If you tell me what defines should I try to change I can make some test. I prepared one arm with motor + prop + ESC with soldered ISP so testing is easy now. Will try to tune STRT_ZC_FILTER_DELAY and will give you feedback when I get home.

marbalon wrote:Will try to tune STRT_ZC_FILTER_DELAY and will give you feedback when I get home.

If this will not fix your problems, try to remove the BEMF capacitors on one ESC as the next step. It's possible that your capacitators have a greater capacitance what affects BEMF meassurement in a negative way. And you can try to increase PCT_PWR_STARTUP and PCT_PWR_MAX_STARTUP even more.

@ziss_dm:

ziss_dm wrote:And to generate step, you just rotate pot fast?

Yes, in all my tests I used the poti to set the PWM, so it was never set "immediately".

ziss_dm wrote:And it depends on idle rpm?

Sorry, i don't get it. What do you mean ? I mean with idle throttle, that my motors are always spinning, even with the throttle stick in the lowermost position. I start/stop the motors with throttle off and yaw left/right (OP CopterControl).

The idea is:- When you rotate pot, it can change fast but not immidiate, so motor can keep up and everythingis fine- When RPM is low, the limiter limiting power to 50% and this is good, but than motor reaches treshhold RPM it can generate "step" change in power

I will try that, but as far as I understood you when you explained the settings, the RPM values are electrical RPM. Idle throttle on the MT3508 is arround 800-1000 "mechanical" RPM, and if I convert that to electrical RPM it's 5600-7000 RPM (electrical rpm = mechanical rpm * poles / 2). If this is right, PWR_CURVE_POINT 01 is never reached. But maybe I'm wrong ?

EDIT: OK, now I got it. That's exactly what you want me to test.

Cheers,Heiko.

Last edited by funth1ngs on Fri Nov 04, 2011 11:09 am, edited 2 times in total.

funth1ngs wrote:If this will not fix your problems, try to remove the BEMF capacitors on one ESC as the next step. It's possible that your capacitators have a greater capacitance what affects BEMF meassurement in a negative way. And you can try to increase PCT_PWR_STARTUP and PCT_PWR_MAX_STARTUP even more.

In Rev 115, I have added support for "Complimentary" PWM (for n-fet boards, and it is disabled by default). It would be interesting to hear, how it performs on your setup. And it would be interesting to see acceleration/deceleration profiles, as it actively breaking.

The idea is:- When you rotate pot, it can change fast but not immidiate, so motor can keep up and everythingis fine- When RPM is low, the limiter limiting power to 50% and this is good, but than motor reaches treshhold RPM it can generate "step" change in power

Tried it, but it had no affects on the resets.

In Rev 115, I have added support for "Complimentary" PWM (for n-fet boards, and it is disabled by default). It would be interesting to hear, how it performs on your setup.

OK, but I don't know what it should do . At first looking, I didn't see any difference with or without COMP_PWM.

Unfortunately, yes. I noticed that with HIGH_SIDE_PWM enabled the ESC resets on any throttle change from 1300us to 1900us, while it's working up to 95% with HIGH_SIDE_PWM disabled. So I meassured RPM at 1300us an got:

HIGH_SIDE_PWM enabled: 1680 RPMHIGH_SIDE_PWM disabled: 2050 RPM

Graphs are look cool: Looks like down slopes are shorter now and it is charging battery (which is strange).

What motors/props are you using? And have you removed back EMF feedback capacitors?And if you like experiments, you can try to adjust STRT_ZC_FILTER_DELAY in core\str_zc_filter.inc. I think, you can lower it little bit.

regards,ziss_dm

Hi,I tried to tune this valune but don't see the difference. So I only change this values:#define PCT_PWR_STARTUP 20#define PCT_PWR_MAX_STARTUP 25

And noe all my ESC and motors don't have a problem with startup. thanks for help.

Looks like I finally understand what is happening with zero crossing in case of low RPM and high voltage. Whe RPM is low, the BEMF voltage is really low and have really flat slope, as a result even small amount of ringing noise would cause comparator to switch especially around zero crossing. The usual way to prevent it from happenning is to create some positive feedback to the comparator, to create hysteresis. Unfortunately AVR comparator does not have this setting, and looks like it has 0 hysteresis. So I was thinking, if we can mirror comparator value to one of the free GPIO pins, it should be possible to feed it to the positive comparator input (in our case this is virtual common point) and this should create some hysteresis and reduce noise.

here is the picture with the ISP pins. I have only one TY-P1, so I never used it in a copter.

Cheers,Heiko

Hi!What input and hw files have you used? I have tried with Mystery20A and pwm_fast_125, with additional #define MINTHROTTLE 1220 and 1150 in MultiWii and the motor doesn't start properly (it only goes around slow and jerky).I'm using http://www.hobbyking.com/hobbyking/stor ... duct=14847.