Possible motor 5/6 bug in new output.pde
Possible motor 5/6 bug in new output.pde
The output.pde sitting in shared... my branch is fully merged with shared + some enhancements in the Spektrum code, the serial code, and LCD code. Otherwise, I'm in exact synch with shared as of a few days ago. After that merger, I configured for a hex, loaded the code, and motor 5/6 were completely non-responsive. This is a Mini Pro, with Spektrum. Then, I copied the entire output.pde from 1.9+ production branch, and motor 5/6 worked fine. No other changes.
Did I miss something in shared? Anything I need to set in config.h? Has anyone flown a hex in shared since output.pde was re-written? I can see that output.pde was extensively re-written for Mini Pro and Hex, but I haven't gone through it in great detail (yet).
Did I miss something in shared? Anything I need to set in config.h? Has anyone flown a hex in shared since output.pde was re-written? I can see that output.pde was extensively re-written for Mini Pro and Hex, but I haven't gone through it in great detail (yet).
Re: Possible motor 5/6 bug in new output.pde
Hi Danal,
i did the last changes to output.pde to have it work with my promicro support.
did you download all files of r582?
i had to do some changes to not have dubble code for pro mini and micro.
but just some more defines in def.h for promini.
I've just tested hex (with pin 5 & 6 and also A0 & A1) on promini and as i can see it on my scope it seems to work well!
regards
felix
i did the last changes to output.pde to have it work with my promicro support.
did you download all files of r582?
i had to do some changes to not have dubble code for pro mini and micro.
but just some more defines in def.h for promini.
I've just tested hex (with pin 5 & 6 and also A0 & A1) on promini and as i can see it on my scope it seems to work well!
regards
felix
Re: Possible motor 5/6 bug in new output.pde
Yeah, I merged everything from every module. But, since I was merging, I could have missed something quite easily. Let me try a couple of things. Specifically, I'll load the shared branch exactly as it stands, and I'll recheck my merge.
Thanks for checking!
Thanks for checking!
Re: Possible motor 5/6 bug in new output.pde
OK, I've done the following:
1) Re-merged my branch with shared, because there's been some changes to shared since I last merged. Result: Motors 5/6 do not behave properly at Arduino boot. The 5&6 ESC will not init, instead they just fast beep. The ESCs on the particular bird I tried are Detrum, which are clones of Turnigy (the Turnigy programming card works with these). Of course, they won't arm or run, either.
Just for fun, I commented out Spektrum support and turned on SBUS. Same result. Therefore, it is not anything I'm doing with the new serial spektrum code.
2) Put the code straight from shared branch into the hex copter. Nothing from my branch. Defined spektrum 1024. Motors 5&6 fast beep only, just like above.
2) Went back to my branch, but copied the output.pde from V1.9. I had to add MOTOR_ORDER back into def.h, but no other changes. Now, motors 5 and 6 init ESC at boot, arm, and run just fine.
So, I think there is something wrong with motors 5/6 in Shared. I don't have time tonight to scope 5&6 when they are mis-behaving, but I will tomorrow night.
1) Re-merged my branch with shared, because there's been some changes to shared since I last merged. Result: Motors 5/6 do not behave properly at Arduino boot. The 5&6 ESC will not init, instead they just fast beep. The ESCs on the particular bird I tried are Detrum, which are clones of Turnigy (the Turnigy programming card works with these). Of course, they won't arm or run, either.
Just for fun, I commented out Spektrum support and turned on SBUS. Same result. Therefore, it is not anything I'm doing with the new serial spektrum code.
2) Put the code straight from shared branch into the hex copter. Nothing from my branch. Defined spektrum 1024. Motors 5&6 fast beep only, just like above.
2) Went back to my branch, but copied the output.pde from V1.9. I had to add MOTOR_ORDER back into def.h, but no other changes. Now, motors 5 and 6 init ESC at boot, arm, and run just fine.
So, I think there is something wrong with motors 5/6 in Shared. I don't have time tonight to scope 5&6 when they are mis-behaving, but I will tomorrow night.
Re: Possible motor 5/6 bug in new output.pde
Hi Danal,
there is one thing that changed since r484 this was the point alex added my different soft PWM code. it is good to have hexa with cam stab or octo on promini...
its disadvantage is that the min signal is something linke 1030 us (+-970us before)
[edit]
i checked it again and on HW PWM's min signal to arm is 999us and on SW PWM its 1027us ..
so if this is not the problem .. can you please do a test with r567?
[/edit]
maybe that is what your ESCs dont like? .. maybe fixable by relearning all ESCs with a little higher min throttle.
regards
Felix
there is one thing that changed since r484 this was the point alex added my different soft PWM code. it is good to have hexa with cam stab or octo on promini...
its disadvantage is that the min signal is something linke 1030 us (+-970us before)
[edit]
i checked it again and on HW PWM's min signal to arm is 999us and on SW PWM its 1027us ..
so if this is not the problem .. can you please do a test with r567?
[/edit]
maybe that is what your ESCs dont like? .. maybe fixable by relearning all ESCs with a little higher min throttle.
regards
Felix
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Possible motor 5/6 bug in new output.pde
Hi Felix,
I think it's better to lower the overal signal and reproduce the former situation.
It's easily possible to modulate the constant sum for one PIN (High state + Low state)
To reproduce the 970us, we just have to lower 255: 255*970/1030 = 240
this should be ok for your ESC Danal =>
We just have to care MAXMOTOR is not too high. default 1850 is still ok, and the new limit would be something like 1950.
I think it's better to lower the overal signal and reproduce the former situation.
It's easily possible to modulate the constant sum for one PIN (High state + Low state)
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+2;
atomicPWM_PIN6_lowState = 255-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+2;
atomicPWM_PIN5_lowState = 255-atomicPWM_PIN5_highState;
To reproduce the 970us, we just have to lower 255: 255*970/1030 = 240
this should be ok for your ESC Danal =>
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+2;
atomicPWM_PIN6_lowState = 240-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+2;
atomicPWM_PIN5_lowState = 240-atomicPWM_PIN5_highState;
We just have to care MAXMOTOR is not too high. default 1850 is still ok, and the new limit would be something like 1950.
Re: Possible motor 5/6 bug in new output.pde
Hi Alex,
you are right, but i made some tests and if we use 248-duty we have clean 1000us with 0+2
so i will change this also for 32u4's 16bit timer
regards
Felix
you are right, but i made some tests and if we use 248-duty we have clean 1000us with 0+2
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+2;
atomicPWM_PIN6_lowState = 248-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+2;
atomicPWM_PIN5_lowState = 248-atomicPWM_PIN5_highState;
so i will change this also for 32u4's 16bit timer

regards
Felix
Re: Possible motor 5/6 bug in new output.pde
Aha! I typically run a MAXTHROTTLE of 1950. I will back this down a little, and try the above code/timer changes.
Thanks!
Danal
Thanks!
Danal
Re: Possible motor 5/6 bug in new output.pde
Hi,
I have a quite interresting issue which maybe related to this issue.
I have a quadrino board in mini hexa, A0_A1_PIN_hex and AUXPIN8 are defined. I'm using reflashed (latest by simonk) 6A TGY ESCs with auto throttle range setup (setup is made with 1850 high and 1000 low with multiwii).
Since r569, and with dev_20120219 now on, when the hexa is powered on and the transmitter is powered on too, the 5 and 6 motors (which are connected to the A0 and A1, sometimes makes a small thick during idle.
Just like motors would start for a microsecond. But they don't start fortunatelly. When flying, I can't see anything problem at all.
But when only hexa is powered on and transmitter is off, this doesn't happen, even for many minutes. I think this is a small BUG since the r569, with 20111220 there weren''t any issues like this.
BR
I have a quite interresting issue which maybe related to this issue.
I have a quadrino board in mini hexa, A0_A1_PIN_hex and AUXPIN8 are defined. I'm using reflashed (latest by simonk) 6A TGY ESCs with auto throttle range setup (setup is made with 1850 high and 1000 low with multiwii).
Since r569, and with dev_20120219 now on, when the hexa is powered on and the transmitter is powered on too, the 5 and 6 motors (which are connected to the A0 and A1, sometimes makes a small thick during idle.
Just like motors would start for a microsecond. But they don't start fortunatelly. When flying, I can't see anything problem at all.
But when only hexa is powered on and transmitter is off, this doesn't happen, even for many minutes. I think this is a small BUG since the r569, with 20111220 there weren''t any issues like this.
BR
Re: Possible motor 5/6 bug in new output.pde
nhadrian wrote:Hi,
I have a quite interresting issue which maybe related to this issue.
I have a quadrino board in mini hexa, A0_A1_PIN_hex and AUXPIN8 are defined. I'm using reflashed (latest by simonk) 6A TGY ESCs with auto throttle range setup (setup is made with 1850 high and 1000 low with multiwii).
Since r569, and with dev_20120219 now on, when the hexa is powered on and the transmitter is powered on too, the 5 and 6 motors (which are connected to the A0 and A1, sometimes makes a small thick during idle.
Just like motors would start for a microsecond. But they don't start fortunatelly. When flying, I can't see anything problem at all.
But when only hexa is powered on and transmitter is off, this doesn't happen, even for many minutes. I think this is a small BUG since the r569, with 20111220 there weren''t any issues like this.
BR
Hi nhadrian,
i saw this jitter you noticed on the scope .. to prevent this i added the "+2". it comes from the RX interrupts. that is why it is just there if the rx is on.
with my ESC's this +2 was enough to prevent it.
so you may want to test some different settings fo us?
1.
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+2;
atomicPWM_PIN6_lowState = 240-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+2;
atomicPWM_PIN5_lowState = 240-atomicPWM_PIN5_highState;
2.
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+2;
atomicPWM_PIN6_lowState = 248-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+2;
atomicPWM_PIN5_lowState = 248-atomicPWM_PIN5_highState;
3.
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+5;
atomicPWM_PIN6_lowState = 240-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+5;
atomicPWM_PIN5_lowState = 240-atomicPWM_PIN5_highState;
Thanks

Felix
Re: Possible motor 5/6 bug in new output.pde
i did a lot of tests now.
and this
works well with all ESCs i have (HKSS, YGE12S, turnergy plush 6a, diamond smart 10a, jamara xetronic 6a, unknowen hype 30A)
so its in shared now!
regards
Felix
and this
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+2;
atomicPWM_PIN6_lowState = 248-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+2;
atomicPWM_PIN5_lowState = 248-atomicPWM_PIN5_highState;
works well with all ESCs i have (HKSS, YGE12S, turnergy plush 6a, diamond smart 10a, jamara xetronic 6a, unknowen hype 30A)
so its in shared now!
regards
Felix
Re: Possible motor 5/6 bug in new output.pde
Hi Felix, I made the tests.
For me, this one works:
So with +5 at the end of highstate line, All thicks are gone.
BR
Adrian
PS.: It even works with 248 and 240 too...
For me, this one works:
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+5;
atomicPWM_PIN6_lowState = 255-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+5;
atomicPWM_PIN5_lowState = 255-atomicPWM_PIN5_highState;
So with +5 at the end of highstate line, All thicks are gone.
BR
Adrian
PS.: It even works with 248 and 240 too...
Re: Possible motor 5/6 bug in new output.pde
Thanks Adrian!
i changed it now in shared to:
so we have 1000us to arm and no ticks in standby
regards
Felix
i changed it now in shared to:
Code: Select all
atomicPWM_PIN6_highState = ((motor[4]-1000)>>2)+5;
atomicPWM_PIN6_lowState = 245-atomicPWM_PIN6_highState;
atomicPWM_PIN5_highState = ((motor[5]-1000)>>2)+5;
atomicPWM_PIN5_lowState = 245-atomicPWM_PIN5_highState;
so we have 1000us to arm and no ticks in standby
regards
Felix
Re: Possible motor 5/6 bug in new output.pde
OK, I'm now getting a start and arm. Flew a hex in the house and seemed very good. I will get to fly outdoors tomorrow.
Re: Possible motor 5/6 bug in new output.pde
Hi,
it seems that thay are some setups that have problems with the new soft PWM method ..
(viewtopic.php?f=8&t=1463&start=20#p12013)
so i changed it to have the old (with it all setups seem to work) method active if it is a hexa setup with no servos.
for hexa with servos or octo there is still the new method .. because it is not possible with the old one
changes in output.pde
http://code.google.com/p/multiwii/sourc ... de&old=668
i also cleaned up the A0_A1_PIN_HEX code so now it just changes the defines for SOFT_PWM_X_PIN_XXX in def.h this saves a few line code in output.pde
regards felix
it seems that thay are some setups that have problems with the new soft PWM method ..
(viewtopic.php?f=8&t=1463&start=20#p12013)
so i changed it to have the old (with it all setups seem to work) method active if it is a hexa setup with no servos.
for hexa with servos or octo there is still the new method .. because it is not possible with the old one
changes in output.pde
http://code.google.com/p/multiwii/sourc ... de&old=668
i also cleaned up the A0_A1_PIN_HEX code so now it just changes the defines for SOFT_PWM_X_PIN_XXX in def.h this saves a few line code in output.pde
regards felix