Firmware

[lizardmech]

13 hours ago, electric_vehicle_lover said:

About motor possible (not) using sensorless on EUC application

Also, as we can see on chinese firmware for EUC: https://eggelectricunicycle.bitbucket.io/FOC--Chinese_controllers_code.html (see first line of FOC_Model()) they seem to use only hall sensor (no sensorless) and just the same way I do, estimate angle between each hall sensor pulse, that's why they integrate the electric angle.

To resume: I would say that firmware of EUC don't need sensorless to work (as like the original firmware). Maybe sometimes we are to picky with our selfs - chinese seems to simply and do it in a cheap way.

 

You can see the clark transforms and SVM in that code it's not similar. I don't see anything to suggest chinese EUC manufacturers are taking this approach, the majority of them have 2 in phase current sense which makes it obvious they are running FOC. Just having a sinewave output based on hall sensors does not mean it's FOC, if phase lag due to resistance and induction isn't compensated for the controller will have low efficiency among many other issues.

[electric_vehicle_lover]

5 hours ago, lizardmech said:

You can see the clark transforms and SVM in that code it's not similar. I don't see anything to suggest chinese EUC manufacturers are taking this approach, the majority of them have 2 in phase current sense which makes it obvious they are running FOC. Just having a sinewave output based on hall sensors does not mean it's FOC, if phase lag due to resistance and induction isn't compensated for the controller will have low efficiency among many other issues.

Seems you didn't understand my point. Maybe you could read it again.

[lizardmech]

8 minutes ago, electric_vehicle_lover said:

Seems you didn't understand my point. Maybe you could read it again.

Aside from maybe some of the older first gen clones all the chinese EUC use FOC based control using clarke and park transforms to estimate electrical angle. I don't understand how anyone could look at the existing chinese controllers and claim a hall based sinewave speed controller is widely used.

[electric_vehicle_lover]

9 minutes ago, lizardmech said:

Aside from maybe some of the older first gen clones all the chinese EUC use FOC based control using clarke and park transforms to estimate electrical angle. I don't understand how anyone could look at the existing chinese controllers and claim a hall based sinewave speed controller is widely used.

I just said that the original firmware don't do sensorless but instead always use hall sensors signal.
You said: (...) use FOC based control using clarke and park transforms to estimate electrical angle. <--- clark and park have nothing to do with estimate electric angle / sensorless.

[lizardmech]

You have to perform these calculations, you're missing the basic concept of FOC, the flux values must be calculated and known D & Q axis cannot be calculated from physical position sensors alone. Stator inductance and resistance dictate how far the stator electrical angle deviates from the physical position. You can feed data from physical sensors into the algorithm as a reference but it can't operate on hall input alone.

[electric_vehicle_lover]

38 minutes ago, lizardmech said:

You have to perform these calculations, you're missing the basic concept of FOC, the flux values must be calculated and known D & Q axis cannot be calculated from physical position sensors alone. Stator inductance and resistance dictate how far the stator electrical angle deviates from the physical position. You can feed data from physical sensors into the algorithm as a reference but it can't operate on hall input alone.

Well, I found some different answers online - for instance this one from a TI employee on TI forum - see bellow.
Looking at the code from chinese firmware, seems they are doing the same interpolation of hall sensor signals to get the rotor angle, like I am doing on my firmware.

---
https://e2e.ti.com/support/microcontrollers/c2000/f/902/t/542888

As Chris mentioned, the interpolation logic is need to get enough angle resolution for FOC control with hall sensor. The most simple interpolation logic is as following.

theta = theta_old + W*Tsample

theta: angle (rad)

theta_old: one cycle behind angle (rad)

W: angular speed (rad/sec)

Tsample: sampling time (sec)

This logic need a speed information and you can also use eCAP module for speed measurement. This algorithm has some disadvantages like a poor angle resolution at low speed and angular seam at each hall transition. Nevertheless, this kind of method has been used in many applications because of simple implementation.

You can also use more advance method for hall interpolation like observer and PLL. But this kind of method need some parameters tuning and need more CPU resource.

[lizardmech]

That's just reading the hall sensor. Basically at 0 rpm you can use the hall sensor to detect the electrical angle, but as erpm increases the stator does not instantly magnetize and demagnetize so depending on variable your magnetic field will appear further behind the Q axis as RPM and other values shift. In theory you could probably calculate the possible lag at different speeds and store them in a table but it's better to calculate these variables in real time. As a bonus many of the values doing this produces can be used to run a sensorless observer. 

[RolluS]

On 14/05/2017 at 6:06 AM, electric_vehicle_lover said:

Do you have contact with ReinTech? MicroWorks disappeared and maybe we can buy boards from ReinTech?

Sorry for late reply.

I have a friend who has step family in China. I had the chance to have him buy me a RT board on taobao. The seller only sells to shop, so I borrow a company name (with owner approval).

I'm pretty sure I could organise a group buy.

 

Nice progress BTW, I like the e-bike controller with a separate balancing module. On my Gausswheel, that would allow two driving mode (throttle and balanced).

[electric_vehicle_lover]

1 hour ago, RolluS said:

I have a friend who has step family in China. I had the chance to have him buy me a RT board on taobao. The seller only sells to shop, so I borrow a company name (with owner approval).

I'm pretty sure I could organise a group buy.

Thanks. For now I am busy with EBike motor controller. I am also waiting to see new webshop from MicroWorks. Later I will think what path I will follow.

 

1 hour ago, RolluS said:

I like the e-bike controller with a separate balancing module. On my Gausswheel, that would allow two driving mode (throttle and balanced).

I would like to see a generic OpenSource brushless motor controller that could be controlled by UART, so people with Arduino or others could control this motors. I didn't find nothing like this for Arduino, everyone is using DC motors on Arduino world while brushless motors are much more widely available and probably cheap.

Just found that the cheap controller I am developing firmware for, is available for 72V, maximum operating current 60A, maximum power 4.3kW. The lowest version if for 24V 15A = 360W.

Edited May 30, 2017 by electric_vehicle_lover

[electric_vehicle_lover]

@RolluS, I am being afraid of using EUC at high speeds, due to any possible fail and have a face plant. Gauswheel seems great because if motor stops should not happen a face plant, maybe unless if the motor blocks. Gauswheel seems almost small than EUCs and maybe not much more weight.

Did you built it already as electric??

[RolluS]

@electric_vehicle_lover I've a "higher end" sinewave EBike controller. I haven't choose hat technology (ebike or EUC controller) I will put in my Gauswheel yet. I haven't even done a blank insall to check and think about component and positions.

From my experience, with EUC, motor stops next to user errors: to much weight put on acceleration or braking, etc.. I felt two times between 35 and 42 km/h, on a 800W 14" EUC! My fault.I've bought the Gauswheel exactly or that. I know a French shop has sent an EUC or eBke controller to Gauswheel romania, who were preparing an exhibition with an electrical gauswheel...

[KingQueenWong]

The Gotawy original controller board:

\

I draw a shematic just like below attach.

BMC-01A.PDF

[electric_vehicle_lover]

3 minutes ago, KingQueenWong said:

The Gotawy original controller board:

\

I draw a shematic just like below attach.

BMC-01A.PDF

Are you sure is from Gotway?? Because is the same as MicroWorks 30B4 board....

ACS712 should not handle all the current of each motor phase... Maybe like on 30B4, there is one resistor on PCB or a power resistor in parallel with ACS712... If so, please add to the schematic.

Would like to see the source files for the schematic on your GitHub and even better if on the KiCad that is OpenSource.

[KingQueenWong]

12 minutes ago, electric_vehicle_lover said:

Are you sure is from Gotway?? Because is the same as MicroWorks 30B4 board....

ACS712 should not handle all the current of each motor phase... Maybe like on 30B4, there is one resistor on PCB or a power resistor in parallel with ACS712... If so, please add to the schematic.

Would like to see the source files for the schematic on your GitHub and even better if on the KiCad that is OpenSource.

I pulled it out of my Gotway.At the top right corner,you can see the www.kebye.com logo link.Gotway comes from kebye company.I am not familiar with Kicad,but i can try to use it and i really wanna to post the harware to my github.

https://github.com/451506709/bmsbattery_s06s_controller_hardware

[electric_vehicle_lover]

2 hours ago, RolluS said:

@electric_vehicle_lover I've a "higher end" sinewave EBike controller. I haven't choose hat technology (ebike or EUC controller) I will put in my Gauswheel yet. I haven't even done a blank insall to check and think about component and positions.

From my experience, with EUC, motor stops next to user errors: to much weight put on acceleration or braking, etc.. I felt two times between 35 and 42 km/h, on a 800W 14" EUC! My fault.I've bought the Gauswheel exactly or that. I know a French shop has sent an EUC or eBke controller to Gauswheel romania, who were preparing an exhibition with an electrical gauswheel...

That's why I am afraid of EUCs, the fails/faceplants. Also I want/need to ride at faster speeds. That's why I am being cleaning and preparing my EBikes on my garage. Please share when you have more information about Gauswheel electric.

 

[electric_vehicle_lover]

26 minutes ago, KingQueenWong said:

I pulled it out of my Gotway.At the top right corner,you can see the www.kebye.com logo link.Gotway comes from kebye company.I am not familiar with Kicad,but i can try to use it and i really wanna to post the harware to my github.

https://github.com/451506709/bmsbattery_s06s_controller_hardware

Just added you to Github EGG and also OpenSource EBike. If you prefer you can put there.

 

[KingQueenWong]

12 minutes ago, electric_vehicle_lover said:

Just added you to Github EGG and also OpenSource EBike. If you prefer you can put there.

 

https://github.com/EGG-electric-unicycle/gotway_controller_board_hardware Commit done!

[electric_vehicle_lover]

@lizardmech, maybe you can help here (even if is not an EUC controller):

I am trying to develop OpenSource firmware for Kuteng motor controllers with STM8S105 microcontroller. With 6 steps the motor runs ok (my OpenSource firmware). With original firmware that implements sinewave, the motor makes a bit more noise, asks a bit more current and increases a bit the power supply voltage. Then I tried to implement 4Q Bipolar PWM (the same used on MicroWorks 30B4) and after some days debugging, I am pretty sure the waves are correctly however, the motor asks to much current, (like 4 times more than original firmware), makes a lot of noise and increases a lot the power supply voltage (increases from 30V to 36V) -- the current and voltage increases when increasing the PWM duty-cycle.

The schematic is here and were done by @KingQueenWong: https://endless-sphere.com/forums/viewtopic.php?f=2&t=87870&start=25#p1293661
The original PWM signals are here: https://opensourceebikefirmware.bitbucket.io/Controllers--BMSBattery_S06x--S06S--PWM_signals--max_speed_-_sineware.html

I am blocked here.... and with all this I had to read about PWM schemes (https://opensourceebikefirmware.bitbucket.io/Motor_control--PWM_schemes--So,_Which_PWM_Technique_is_Best_(Part_1).html) and found that the one used on MicroWorks 30B4 and FOC is the one that let brake the motor/regen, the more simple ones like 6 steps can't technically do that.

[lizardmech]

4 quadrant control is a separate thing from FOC. I think you basically get it without any effort on newer MCUs with advanced PWM hardware, old 8 bit MCUs may be much more work. The ACS712 on that older gotway board is using the PCB as a resistor to boost the range.

I was talking to Ti engineers on their forum, they pointed out this new MCU http://www.ti.com/product/tms320f280049m High res PWM, 3 ADC + sigma-delta filters, hardware based clarke/park computations and it's only going to be $6. Pretty much going to be the best low cost motor control MCU around.

[electric_vehicle_lover]

Another experiment, I just put my old electric unicycle motor running with 4 quadrant bipolar PWM (just like PWM signal of MicroWorks 30B4 board) but with the EBike controller. This firmware is similar with the code I did for MicroWorks 30B4 board but don't do FOC. Power supply had 30V.

 

[electric_vehicle_lover]

Another experiment, the same firmware and controller as on the last video but this time with that Q85 Ebike motor, which is very small, light and less powerful (200W) when compared to the EUC motor. And this motor runs bad, with noise, asking a lot of current (motor heats)!!

And why so different this motor VS the EUC motor??
I think the main different is that this small and light motor have much less coils inductance and resistance:

http://www.diyelectriccar.com/forums/showthread.php/bldc-controllers-suitable-very-low-inductance-76770.html
There are many low inductance motors around these days. By low I mean 5μH and lower. These are coreless or compact outrunners.
The problem is that the inductance is so low, that it is unable to integrate the PWM and current ripple blows the controller or overheats a motor. Or significantly lowers motor's maximum useful current at least.

Seems that this low inductance motors are more hard/expensive to control... and seems that one way is to lower the voltage supply to minimum so the current peaks will be lower... but on EUC motor can be different and that is also one reason for them to have high voltage supply??
 

 

[lizardmech]

What PWM freq? Sinewave or BLDC type drive? It shouldn't be that low inductance like coreless motors or some of the extreme rc hobby motors. 

[electric_vehicle_lover]

16 hours ago, lizardmech said:

What PWM freq? Sinewave or BLDC type drive? It shouldn't be that low inductance like coreless motors or some of the extreme rc hobby motors. 

Same PWM freq as original firmware: 16kHz.
Problems on the sinewave. BLDC 6 steps seems good. Videos bellow for comparison -- can be seen on the power supply voltages, when this issue happens, the power supply voltage increases!!
2nd video shows on oscilloscope the wave of motor current where we can see that the current pulse have about half the time of PWM and increases very high after the power supply measures over 1.8A -- with 6 steps that is ok, the power supply measures 1.8A. Maybe I need to limit the current to 1.8A... something that is not needed on EUC motor for it to run as it should.

BLDC 6 steps:

Sinewave:

Sinewave EUC motor is ok:

 

Edited June 7, 2017 by electric_vehicle_lover

[lizardmech]

The current must not be aligned with the Q axis.

[electric_vehicle_lover]

2 minutes ago, lizardmech said:

The current must not be aligned with the Q axis.

It is as I went manually the find the best angle until I got the best running. Also it is very near the same value as on 6 steps, that works well.

And I tried this motor before with the FOC firmware for EUC and it worked well just up to medium speed and after starts to fail... angle_correction_value inverted on the direction after medium speeds... I am pretty sure it is the issue with the current, as angle_correction_value depends mainly on the measured currents.