thrust test

[adrianmiriuta]

@conuthead

for comparison : blheli32 Wraith32 50A f051bldc Wraith32 32A

your fw works well with 3S. with 4S it desynchs at (1770 PWM). Overall the efficiency N/W is better than blheli (on same motor prop configuration). f051bldc_ZMX-FINX23_HQPROP5x5x3v1s.zip WRAITH32-50A_ZMX-FINX23_HQPROP5x5x3v1s.zip

[AlkaMotors]

Awesome ! many changes are in the works. I have redid the dshot input to a single buffer and added adc reading for voltage , temp and current, i will add the changes to the git soon. The desync i cannot reproduce so i will have to wait until i get another motor similar to yours. I believe its probably a timing advance issue. That can be adjusted very easily but i would just be guessing without trying it. My timing advance is automatically adjusted to the commutation interval. I may make it a fixed degree at a certain rpm if i need to for high kv motors.

[AlkaMotors]

Were you using the latest version for the test the v1.2 bin? or did you compile your own?

[adrianmiriuta]

@conuthead I compiled it from your released source. If you have a new bin I can test it !

[AlkaMotors]

I will put a bin up tonight ( at work right now). With the new changes before I add to the source. There is quite a lot that has changed with the peripheral setup. The last bin i had added was the 1.2 bin, i think that's the same as the source. Do compiler optimizations make a difference? , i use optimize for speed flag.

[adrianmiriuta]

@conuthead I optimized for speed to. I don't know, anything is possible ! Put the bin on github as v1.3 , I will test it tomorrow.

[AlkaMotors]

OK i , uploaded the test bin, this also adds dshot600. i still don't think this will fix the desync though but it is a bit more efficient when it comes to decoding the signal.

The timing advance right now is done automatically by changing divider its really simple there is a line down in the while loop. "advancedivisor = map((commutation_interval), 100, 5000, 3, 20);"

One commutation interval is 60 degrees electrical, so if the advance divisor is 4 the timing advance is 60 / 4 = 15 degree timing advance. as you can see this gets pretty coarse as it will change from 15 degree to 20 degree timing advance.

Here are some old blheli numbers "Commutation timing can be adjusted in three steps. Low is about 0 degrees, mediumlow 8 degrees, medium 15 degrees, mediumhigh 23 degrees and high 30 degrees."

So you can just comment out that line and change the advancedivisor variable at the top to 3, 4, 5 or maybe 2 even and see what timing advance might be right for that motor.

[adrianmiriuta]

@conuthead where ? I cannot find it.

[AlkaMotors]

line 1272 in main.c

[adrianmiriuta]

@conuthead Oh ... I ment the new binary v3 file.

[AlkaMotors]

It's not there! Wtf GitHub. I will upload to the release folder. ok its there now..

On Fri, Apr 19, 2019, 6:25 AM adrianmiriuta notifications@github.com wrote:

@conuthead https://github.com/conuthead Oh ... I ment the new binary v3 file.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/conuthead/f051bldc/issues/6#issuecomment-484825198, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBMTQRO2R52TR5G3VX6J5TPRGFWXANCNFSM4HGT37WQ .

[AlkaMotors]

@adrianmiriuta , I also added a different version of 1.3 with a higher timing advance 30degree max at higher rpm , I am curious to see if it will make a difference. I think the right value is maybe between the two..

[adrianmiriuta]

@conuthead Sorry we have to delay this for a few days I smoked my motor, I have to rewind ...

[adrianmiriuta]

@conuthead tested with Lumenier RB2205C-12 2400KV still has desynchs above 1770
It is only on my thrust sand , with betaflight it does not show the same behavior. in betaflight there is one PWM pulse each 5ms the thrust stand has one PWM pulse each 20ms there must be something wrong with PWM input handling.

Have you changed anything ? can you push the source ?

[AlkaMotors]

@adrianmiriuta , Hmm, possibly something has changed. The input is completely changed from the version on the git. The buffer is now captured very differently with a timer to detect end of frame so that it captures each buffer. There is maybe a slight adjustment that needs to be made for servo with long pulse from a tester. The timer is 16 bit so will roll over at 15 ms right now with the servo input at 20ms so i can see that being an issue. I will make a simple check to verify the timer has had not just rolled over when the reading is taken otherwise i can be read as the wrong value. Thanks for finding it, should be simple to fix.

[AlkaMotors]

@adrianmiriuta, Are you sure about the refresh rate of the thrust stand? I have been using a servo input and don't have an issue at 50hz or 20ms refresh. Can you verify that the signal on the logic analyzer? 20ms should not be a problem.

[adrianmiriuta]

@conuthead Yes , it is a compounded problem , it depends also on motor RPM. on 3S it works fine betaflight and RcBench on 4S it works fine on betaflight , and desynchs on RcBench

do you use the same Timer or DMA for input and motor PWM ?

attached scopes and RcBench results.

betaflight

RcBench

test1_v1_2019-04-23_1814.zip

[AlkaMotors]

@adrianmiriuta, Interesting thanks. When you say desync, what type of behavior are you seeing? I have not been able to reproduce yet testing up to 35k rpm on a 14 pole motor.

[adrianmiriuta]

@conuthead the motor does not follow the input speed setting any more, slows down , wobbles up down RPM , and if you do not plug out the battery quick enough ... it smokes , and burns out.

It happens at much lower RPM 15387 as you can see from the TestBench CSV. This is a Lumenier RB2205C-12 2400KV 14 pole motor.

[AlkaMotors]

Ok, did you try the newest bin in the release folder 1_4servo_testing? Doesn't sound like a desync you are experiencing. With a desync the ESC will keep commutation at a fixed rate. A loud high pitch squeal will accompany the desync and your motor will pretty much smoke instantly. Sound like you have signal corruption. If that other bin makes a difference we will know.

[adrianmiriuta]

@conuthead i used wraith32v1_3HIGHAdvance.bin I will try the new bin tomorrow

[AlkaMotors]

It might make a difference with the other bin. Are you sharing a ground between the ESC and the servo tester? I really hope we can get it working. It's been tested on about 20 different motors now and only your have given us any issues. You are the only high kv tester so far.

[adrianmiriuta]

@conuthead I use a dedicated signal ground. the new 1_4 binary takes very long time to arm (15 seconds and longer) and it shows the same breakups on 4S. (it draws more than 45A 675W)

[AlkaMotors]

Oops the arming timeout was set way to long. Still works with Betaflight? This is getting frustrating.. is it possible to do a little video of the setup? Do you still have the st-link plugged in at the same time? Do you have a ground on that too? How long is your USB cable from the test stand? There must be something different in the setup between your betaflight tests and the benchmark stand as I cannot recreate this issue with any receiver or FC I have. I hope the test stand can at least do a digital output so that we can see if it's a signal corruption issue. Make sure you don't have multiple ground paths to the ESC as ground loops can cause major issues.. especially if you have the st-link plugged in and grounded to the esc too. The last test code was back to normal timing but with more error checking on the servo input. The timers nor dma are not shared..input capture is straight to dma and is the only thing using the dma.

[adrianmiriuta]

@conuthead

1. yes it works with betaflight
2. USB cable 1m
3. no RCbenchmark does only PWM
4. I tested with and without dedicated signal GND (it is the same)
5. ST-LINK is not plugged in !
6. I attached the scoped signal lines in my previous post ,they are clean .
7. Pictures of the setup attached

[adrianmiriuta]

@conuthead

It isn't a setup , or signal degradation issue ! The exact same hardware setup with blheli32 works.

[adrianmiriuta]

@conuthead here a video the Current (45A)and Power(675W) limits are on so it does not wobble around and smoke !

20190424_164718.zip

[AlkaMotors]

Just trying to rule out the possible causes. You have to understand that if the issue cannot be repeated with other setups that I have to ask about the hardware. From the pics I still have doubts, it looks like you have a very long signal cable from the device to the esc.. The signal outputs always look clean on a scope! Its what the esc see's thats important. I will try something else tonight and try a different way of doing the input capture and get another test code out to you. The other people to use this firmware are not using the wraith32. They are using their own hardware. I will see if we can get another wraith loaded with the firmware so we are on the same page. Even if it is a signal issue, I still need to work out a firmware solution so I will keep trying to reproduce the problem. I am going to make an intentionally noisy setup tonight an do some more testing. I will probably have to remove the caps from my hardware to make it like the wraith lol.

[adrianmiriuta]

@conuthead

1. I know it is frustrating, debugging always is !
2. can you push the new source to github ?
3. can you reproduce the signal timing from the RCbenchmark testing gear ? (how do you simulate it ?)
4. I don't think it is a noise issue, then it should not work with the PWM signal from betaflight either.

[AlkaMotors]

Wow, that video is interesting, the startup sounds very different from what I have experienced. Why does that RED led light up on the wraith?

[AlkaMotors]

I have tested with an arduino using the servo library for 50 hz testing and also with the output from a flysky reciever @ 50hz . I don't want to push the new source because people are using the old firmware now and the input handling is quite different. Should i make another branch for testing?

[adrianmiriuta]

@conuthead

1. because you programmed it so ? (i used wraith32_1_41servo_input_test.bin)

   main.c  line 635
           while (TIM3->CNT  < waitTime){
               GPIOA->BSRR = GPIO_PIN_15;
   
           }
           GPIOA->BRR = GPIO_PIN_15;

2. yes a testing branch would be nice.

[AlkaMotors]

Hah, aweseome.., i don't have a wraith so i had no idea that gpioA 15 would got to that led. Its just used for debugging with the scope .. On my board its just a pin.

[adrianmiriuta]

@conuthead can you push the new changes to the testing branch ?

[AlkaMotors]

@adrianmiriuta Hey , sorry i got busy with work for a few days. I am still testing some things and will get back at it on the weekend. There are a few ideas I have that i want to try to keep the servo signal reading cleaner.. There is basically no filtering or noise rejection really on the old implementation. The problem with a low refresh rate and servo signal is that if it gets a bad number then it has a much bigger effect. The effect from a 50hz bad capture would last 10 times longer than the bad capture at 500hz. This can make the motor have wild changes in power levels and desync. I do not have any maximum rates of change imposed on the motors so in one servo pwm period the motor can fluctuate by a huge amount. When the signal is completely clean it will not happen.. If the refresh rate is higher the change in rpm from a bad capture is much smaller.. So I am going to keep playing with the hardware input capture filter and software filtering on the pwm input. Also imposing a max rate of change to the motor is probably good. Its a tricky balance between keeping as much performance as possible and avoiding situations where a desync can happen. When I get a chance I will clean up the test code and get it up..

[adrianmiriuta]

@conuthead no problem, take your time ... (this is for fun). br.

[adrianmiriuta]

@conuthead still playing with this ... https://github.com/3x8/nostromo/releases/tag/v1.2.2

done some improvements in timing, deadtime, motor commutation interval, overcurrent protection ...

got it working acceptable ... on a Wraith32V2 with EMAX RS-II motors tested on a warp230 frame with a CLRACINGF7.

have you made any improvements ?

[AlkaMotors]

that's cool. I am not sure where what i have done lately. I am always tinkering away with things.. I have made a few new firmwares for other mcu's but not worked on this one much. I have added current reading, temperature and bus voltage to dma but not done anything with it yet. Working on serial currently for telemetry out and programming /flashing esc via the 4 way betaflight passthrough. What improvements did you do? Be careful with dead time , it is chosen for a reason depending on hardware , it should be large enough to avoid shoot though in all scenarios.

[adrianmiriuta]

@conuthead

1. more targets (DYS35ARIA FURLING45MINI TYPHOON32V2 WRAITH32 WRAITH32MINI WRAITH32V2)
2. Better output linearity
3. Inproved proshot DMA reading (dropped all other protocols)
4. overcurrent disarm (with kalman filtering) voltage and temperature not used yet ...
5. FD6288 has builtin 200ns deadtime (no need for software deadtime)
6. mcu PWM deadtime is counted with in 22ns granularity (yours is much too high) !
7. lots of syntax improvements... (and cleanups)
8. lots of thrust tests with different motors.
9. some quadcopter flight tests.

[AlkaMotors]

Awesome, i am going to give people links to your firmware in the future when working on hardware.

The deadtime was very high on mine, i am glad you brought down for the wraith! I was working on an esc that used 3 mosfets in parallel per leg and it needed a massive deadtime. I only used the fd6288 on this one design so far, i had no idea it even had 200ns dead time built in haha.

I am going to link your firmware to the diy esc project so other people can test too. I wil put a link on the first post. https://www.rcgroups.com/forums/showthread.php?3322857-A-cheap-32-bit-diy-ESC-and-firmware.

I have been flying with the latest version for a few weeks in quad it has been working great! ( the one in experimental folder).

Thanks for continuing on with this. I think your firmware version is probably the most functional right now. I am back to making hardware and don't have much time for coding.

[adrianmiriuta]

@conuthead no problem I only wanted to stay in touch.

1. only WRAITH32V2 is optimized
2. on DYS35ARIA I am struggling to understand the voltage current measurement (i tried to contact DYS for schematics, but they do not seem interested)
3. on the FURLING45MINI i downgraded the mcu (they use a stm clone GD32F303 i cannot program).