Jump to content

electric_vehicle_lover

Full Members
  • Content count

    963
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by electric_vehicle_lover

  1. Firmware

    Happy that we achieved the same performance as the original firmware (pretty sure the Kunteng developers also implemented that very low resolution FOC) -- here the tests the other developer did -- I have some more ideas to try improve the results :-) The new controller arrived today. I've done some measurements on the test bench with the original firmware. The effiency is worse at higher mechanical loads in comparison to the 12 FET Lishui (FOC sensorless)... With your SVM_4 (8bit) algorithm we seem to do quite the same as the original firmware
  2. Firmware

    Yes, I started with a very slow EUC and just after moved to the MicroWorks board.
  3. Firmware

    What do you expect from me now?? Don't wast your time anymore talking to me, because I will ignore you.
  4. Firmware

    I wanted to say they are dangerous (without comparing to EBikes). Wasn't obvious, I had to build, learn and ride to understand the potential issues - and over the time I read the forum messages about the faceplants on every EUC brand, it scares me. But I still like them but I don't trust to ride fast and so I see them more like a toy. The bicycle, I feel safe riding my Brompton at 30km/h and my big other electric at 45km/h - do not want to ride EUCs at such velocities.
  5. Firmware

    IMO after I realized that EUCs are more dangerous than EBikes, I started and moved to this project: https://opensourceebikefirmware.bitbucket.io/ Also the MicroWorks stopped to sell the board and told that EUC market decreased, which other sources confirm. EBikes market is huge and will keep growing!! I found that the current motor controllers are dirty cheap starting at 14€ and they potentially can be controlled by UART, using for instance an Arduino -- that is my plan, a good EBike motor controller firmware + a firmware to make the controller generic in the hope it can be adopted on the Arduino world where there is no such option, users keep using DC motors :-( Also I think an DIY EUC can be made using EBike components: direct drive motor + motor controller + Arduino + batteries.
  6. Firmware

    @KingQueenWong just did it!! The EUC1 motor controller board does FOC!! And this board is cheap and available. It misses UART bluetooth connection:
  7. Firmware

    I would say you are dreaming. I never compromised myself as also you never discussed your hardware/prototypes -- you were working alone, in your project. I will say again my motivations: I want to work on projects that will be adopted by many as possible and for that I believe the hardware needs to be very cheap and widely available. For instance, (at least until now) VESC hardware is very expensive (135€) and seems some shops have it out of stock. The EBike motor controller I am developing firmware for costs only 14€ and can be bought from many online shops, they always have them in stock. VESC is very well known on a growing market that is eskate and still costs 135€ and EUC market seems to be decreasing... EBike market is big and will keep increasing that is why I got much more interest on the firmware for the EBike motor controller, including more 2 developers, one that is actively developing the firmware, already bought a few controllers (but went to find the cheaper ones!!) and even built a test bench:
  8. Firmware

    My opinion has evolved over the time, just like development projects does when we get more and more information over the time. I already explained the reasons why I am not motivated to work with custom board and instead focus on a widely available and cheap already existing motor controllers. You are repeating the same arguments when I already did explain my motivations -- you are misleading and being unfriendly and that is the reason that I feel the need to ignore you; due to your behavior, it is now more and more clear to me that I would not want to work with you in a project.
  9. Firmware

    I resolved some bugs on the firmware and finally I have my both very different motors running with the very low resolution FOC. The EUC motor runs very well, I would say with almost equal to the OpenSource firmware on the MicroWorks 30B4 board. Video of my EUC2 motor running at 60V (yes, the S06S EBike motor controller did run at 60V and there is a version of this controller that runs at 72V): But the Q85 EBike motor runs badly and I am pretty sure it is because is a high eRPM motor!! The EUC2 motor runs at 125 eRPM, needs to draw the SVM/Sinewave with steps of 64us/using 125 points. Q85 motor runs at 480 eRPM wich is only 32 points to draw the sinewave!! I am pretty sure the issue is this, lack of resolution -- I can go now and try optimize the firmware, I have some ideas... anyway, the original firmware don't seem to run very well this motor, maybe because of this limitation... But the MicroWorks 30B4 board may have the same issue, since the PWM frequency is the same!! I think EUC motors have lower eRPM than this geared EBike motor. As for comparison, here is the MicroWorks 30B4 board running the OpenSource firmware with FOC:
  10. Firmware

    Good that finally you could understand that there are low cost hardware that does FOC ignoring motor flux and resistance -- that is what I did, after following Shane Colton documentation and firmware, for the OpenSource firmware to the MicroWorks 30B4 board. And for this Kunteng STM8 8 bits 16MHz EBike motor controller, I had to go even simplifying even more but it is still FOC, at least IMO -- anyway, the original firmware for sure does that so we had to figure it out and do it!! What I got today: No FOC, see the amount of current motor asks for the power supply: Now with very low resolution FOC, see the decreased amount of current -- the motor speed also increased But there are still some issues reading IQ current and the control results also in bad results sometimes, as seen the yellow phase B current is not a good sinewave:
  11. Firmware

    Sorry but you have no reason on this point - because the document from OnSemi that I linked and I am following "Field Oriented Control of Permanent Magnet Synchronous Motors" implements FOC and don't do any calculation of the magnetic fields, don't rely on know motor inductance and resistance values to determine magnetic properties. I am saying that I documented the theory math of "very low resolution FOC" and implemented it, following the concepts math of that OnSemi document.
  12. Firmware

    Why are you misleading?? Again: I did quote what I was talking about:
  13. Firmware

    I did quote what I was talking about: And my answer was: That is what you say but others like OnSemi and TI employees consider that is also possible not making that calculation. Seems you are not reading before answering.
  14. Firmware

    Yes, because would not be possible to do that calculation on this so limited microcontroller. But I found a simplification to read ID and IQ currents, avoiding the need to have a second phase current sensor and do clark and park calculations. I documented the simplification math here: That is what you say but others like OnSemi and TI employees consider that is also possible not making that calculation.
  15. Firmware

    See this document from OnSemi, with the implementation of FOC with only hall sensors, with tittle "Field Oriented Control of Permanent Magnet Synchronous Motors" that uses only hall sensors. I will keep calling FOC but explaining that is a "very low resolution FOC" in the case of this EBike controller that uses a 8 bits STM8 microcontroller running at 16MHz only!!, and only measures 1 phase current.
  16. Firmware

    See here that Texas Instruments employees consider FOC using hall sensors (you can find many other examples on Texas Instruments forum): And I just found this 8 bits motor controller as low as $17!! Every online shop sells them and everyone is happy because they find their motors silent and efficient, when compared to the 6 steps old generation controllers.
  17. Firmware

    FIRST TIME EVER having "FOC" (very low resolution FOC) on the dirty cheap EBike controllers with a 8 bits microcontroller STM8: https://opensourceebikefirmware.bitbucket.io/ Very low resolution FOC seems to be working with my motor (EUC2 motor, low eRPM, at power supply 45V) but I had to do the interpolation every hall sensor signal and now the motor startup ok and do ok the interpolation. My EUC2 motor, low eRPM, at power supply 30V. Next image: without FOC, angle keeps constant. First part, motor at max eRPM speed of +100 and using about -500mA of IQ current. Second part, also using -500mA but I was blocking a bit the motor, so it could not get the max velocity: Now with FOC enable and and just changing the velocity/PWM duty_cycle. We can see that FOC try to keep IQ current near zero: Now as before, but on second part I tried to bloc with my hand and we can see angle going decreasing to very low values while the IQ current then goes to near zero value (it takes sometime to go to zero value, needs a PI controller):
  18. Firmware

    Nice to see the news about VESC :-)
  19. DIY One Wheel build with Unicycle components

    One day we will have our OpenSource firmware and then we will be able configure that functionalities :-) For now we are working to develop firmware for EBike motor controllers, that after will work as a generic brushless motor controllers, for instance, to be controlled with an Arduino using UART commands. If you are interested, you can follow current project here: https://endless-sphere.com/forums/viewtopic.php?f=30&t=87870&p=1317106#p1317106
  20. WTB 30B4 CONTROL BOARD

    I have 2 of them but I am keeping them as a recuerdo and also I played/hacked them so I don't have many confidence in them now :-) I hope I/we will be able to develop OpenSource firmware for EBike motor controllers and them be able to develop a DIY EUC version -- if you are interested you can follow our project here: https://endless-sphere.com/forums/viewtopic.php?f=30&t=87870&start=325 http://opensourceebikefirmware.bitbucket.io/
  21. Firmware

    Sharing the knowledge I developed: So I think I was able to figure out how to do FOC on the BMSBattery S06S/Kunteng STM8 motor controllers!! Due to the hardware limitations, I think FOC is only doable with losing much resolution but that should be enough for this application. But this way there is not need to do multiplications and calc sines and cosines, just read directly phase B current to have ID and IQ currents!! I write my notes, please see here: https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.09.02_-_How_to_do_FOC_on_the_BMSBattery_S06S-Kunteng_STM8_motor_controllers.html 2017.09.02 - How to do FOC on the BMSBattery S06S/Kunteng STM8 motor controllers On FOC hardware, typically at least 2 phase currents are measured while on the BMSBattery S06S/Kunteng STM8 motor controllers only 1 phase current is measured. Also FOC needs processing power and we see cheap hardware using like the STM32F103 32 bits that can do the math algorithm while the STM8 8 bits can't. I think BMSBattery S06S/Kunteng STM8 motor controllers do a kind of simplification of FOC. They can do FOC with much less resolution but that may be enough for this application where the target price of this motor controllers is ultra low. Next, I describe the way I think they achieve FOC. The following documentation considers that you are familiar with FOC documentation. The next image shows the 3 phase currents, phased out 120º of each other. On Kunteng STM8 motor controller, only 1 phase current is measured - let's say it is phase A (green line). Image 01 ia = green line ib = red line ic = dark blue line hall sensor signal = light blue line On FOC hardware, typically at least 2 phase currents are measured and since the sum of the 3 phase currents are zero (ia + ib + ic = 0), the third current is calculated. As we can see on the image 01, ib and ic have the same negative value while ia is positive with double amplitude, for instance: 10 + (-5) + (-5) = 0; 10 = -(-5 -5); 10 = 10. Although on Kunteng STM8 motor controller only 1 phase current is read, the other 2 should be similar but phased out 120º of each other. The next image shows the same current as vectors while teta is zero. Every current is placed 120º phased out of each other. Image 2 The sum of the current values can be represented on the quadrature axis Q and Q (gray color). At the specific moment when teta is zero, ia, ib, ic D axis components results in ID component which should be the max possible value for ID amps (100%). ia, ib, ic Q axis components: ia Q is zero as ia is placed on D axis; ib Q and iC Q have the same value but opposite directions and so they cancel out -- IQ is zero amps (0%). The next image shows the phase A current with teta 90º relative to motor rotor position - at FOC we want it to be at 90º where happens max efficiency of the motor. Image 3 hall sensor signal = light blue line As we can see, ID have the max value, the top of sinewave phase A current value. IQ is measured 90º compared to ID and the phase A current is 0. On FOC we want to keep/control IQ = 0 and that will mean a constant 90º of the phase current relative to motor rotor position, where happens max efficiency of the motor. ID is the value current value that we will also want to control and results of the motor torque. The next image shows the phase A current with teta 45º relative to motor rotor position. As we can see, IQ is not zero and ID is not the max value -- motor will vibrate, make noise and asking to much current: will be very inefficient. Image 4 The next image shows the phase A current with teta 0º relative to motor rotor position (I think motor would not even work/run on this situation). As we can see, IQ is max value and ID is zero value. With ID zero, we have zero torque meaning motor would not run, I think all the current/torque would be used to block the motor instead of making it rotating. Image 5 Conclusion I think we can do FOC on the BMSBattery S06S/Kunteng STM8 motor controllers by doing the following: • please refer to image 3. On this situation, if we read phase current B on Kunteng STM8 motor controller: ◇ point B: the read value is the IQ current ◇ point A: the read value is the ID current • to do FOC, we need: ◇ keep IQ current = 0 ▪ adjust the PWM sinewave phase angle that we generate, to keep IQ at zero amps value ◇ keep ID current at the value we desire, that will result the effective motor current/torque ▪ adjust PWM duty_cycle value to keep ID at the amps value we desire
  22. Firmware

    I got some more knowledge about driving the motors, and on EBikes, the cheaper, lighter and small motors are popular and they are geared like running at 13x faster than the direct drive motors. This faster motors have a much higher eRPM and they need faster PWM frequency -- which is not the case with the EUC motors that I know. But taking as example the MicroWorks 30km/h 500W motor, at 30km/h it is half the max eRPM (22.000 eRPM, max of eRPM for 16kHz PWM = 40.000)). Going with a bigger wheel size for speeds over 30km/h will help to avoid potential issues with faster eRPM. Ok I think I got the eRPM of your motor: I saw value of 40 of ui16_speed_inverse and that means 40 * 64us = 2.560ms per eRPM at 36V power supply -- I guess you want run motor at 36v. The firmware will draw the "sine wave" voltage using 40 points. My Q85 at 30V (and I think it is a 24v motor), have a 1.808ms eRPM as seen on the next picture -- so firmware will draw the "sine wave" voltage using 28 points... I think this is an issue!! (we can verify/count the 28 number of PWM pulses on the next image) At 30V, this motor have an eRPM of 15ms!! 6x lower than my Q85 motor!! So the firmware will draw the "sine wave" voltage using 234 points VS the only 28 on my Q85. I remember to try drive my Q85 with my MicroWorks 30B4 board (STM32F103), using FOC/sine wave/SVM and it worked well just up to medium speed and after that it was going craze!! I could see the value of position_correction_value start going backwards (crazy!!)... that firmware have the PWM running at 20MHz / 50us and with S06S it runs even lower at 16kHz / 64us... I am that afraid S06S can't run well this fast eRPM motors like Q85 and Q75, due to low PWM frequency / motor high eRPM. --- http://kellycontroller.com/faqs.php What's BLDC high speed model and ultra high speed model differ from standard model? 32-bit microprocessor, higher PWM frequency. Standard model: 16.6KHz, 40,000 eRPM. High speed model: 33KHz, 70,000 eRPM. Ultra high speed model: 100KHz, 100,000 eRPM. eRPM=Mechanical RPM*Pole pairs. It does generate more heat because of higher switching frequency.
  23. Firmware

    You are assuming wrong things about my talk. I am not hostile to open source hardware, nor even to your project - I am mostly ignoring your project for the reasons I already told I feel the need to start ignoring your messages because you are being unfriendly - as this is from long time ago.
  24. Firmware

    I just cooperate in what I believe that will have adoption. I simple don't believe in the adoption of your hardware when we already have on the market, cheap EBike controllers using similar hardware as MicroWorks boards -- boards capable of doing FOC and using STM32F103 (and yes, my main focus now are not EUCs but EBike controllers - that will also work for the EUC application as motor controllers): Sure I did for MicroWorks 30B4, see Zii message: http://forum.electricunicycle.org/topic/1109-firmware/?do=findComment&comment=105903 Current firmware works for my 2 different EUC motors + Zii motor, doing simplified FOC and max current and over current protection. If you read the synopsis of my talk, you will see that I will talk about the firmware of motor controllers.
  25. Firmware

    I will make a talk with title "Develop embedded soft/firmware for chinese motor controllers" in PixelsCamp, Lisbon, on 30 September. PixelsCamp is the most yearly relevant event, in Portugal, for the software, firmware and hardware developers -- 3 days of non-stop tech, talks, workshops and a 48 hour programming competition: https://pixels.camp/ The description of my talk - original link: https://github.com/PixelsCamp/talks/pull/161 Develop embedded soft/firmware for chinese motor controllers Description Since some years, I am being developing OpenSource firmware for the chinese electric motor controllers that are used on small electric vehicules: hoverboards, skates, unicycles and bicycles. This chinese controllers are dirty cheap, capable and with ok quality. Since they optimize their products for price, they have very limited resources - developing firmware for their controllers means learning how to make "the thing" in a unique and creative ways, optimizing all the processing power and memory used. Why I decided strategically to develop firmware for the cheap chinese controllers? Because the market is flooded with them: they work well and are easy to get. This OpenSource firmware is the first in the world and I hope it will be used by many users as possible, shapping the future like Arduino did. I would like to present my experience, from developing the firmware and up to try gather a community and contact with people all over the world (using a lot Google translator for german, chinese, etc).
×