DIY eBike BLDC Motor Controller

[Alan B]

I need to have my own documentation for halls and phases, so for now I made it a spreadsheet. Perhaps I'll make it a drawing later, but right now I don't have a convenient drawing tool to do it with, and there is a lot of spreadsheet style data that needs to be there anyway. I relabelled the phases to U,V,W again, I've gone back and forth a couple of times on that.

One thing I did is to divide the chart into 30 degree intervals to expose the sensorless transition event. So above is a first draft. The "Float High, Float Low terminology is with respect to the midpoint voltage, so you can see at 30, 90, 150, 210, 270, 330 there is a floating transition between high and low (in one direction or the other). These are the sensorless "zero" (really midpoint) crossings that start the timer for the next commutation event that occurs 30 degrees later.

I'm working on an algorithm that can watch both the hall events and the sensorless transition events and use whichever is the best quality with a preference toward sensorless events if both are good. In normal operation it would start from stopped with hall sensors and then smoothly transition to sensorless when the signal is good enough. So if the halls fail it would become pedal start (at least for direct drive motors). In some cases, perhaps under heavy throttle, load, vibration or sagging battery the sensorless data may become noisy and it would just seamlessly switch to use the hall sensors, and then transition back when the sensorless noise cleared up. We'll have some logging so we can see what is happening later. Perhaps an LED for Sensored mode? If that flashes while moving there's something noising up the sensorless data.

Note that for a gearmotor pedal first won't work, but I'm not going to try to fix that now, that can always be an exercise for the reader.

Another feature I'm thinking of incorporating from the start is a hall sequence check, I don't think the common controllers have this based on how they operate when the hall wiring is incorrect. The sequencer will essentially enforce the correct order of the hall states, and if they occur in the wrong order it will declare an error, shutdown the outputs and require a drop of the throttle to clear it. This lets you know that the halls are not wired properly, or there is noise or a loose connection or a failing hall sensor. This will also prevent getting the wrong hall sequence when setting up the wiring. Rather than the motor continue to run improperly, it will try and quit, and retry each time the throttle is lowered/raised again. So you'll know the halls are not right. We can always take it out if it is too annoying, but it seems to me that getting the system right and solid is better than having it appear to work when it is not quite right. If it quits when out riding then there is a problem. I will put some filtering so a single bad reading won't count but several in a row will trip it.

A similar timeout on the motor not turning, or going backwards would be good also. Try to catch those things that heat up the controller and motor and trip them quickly. With a simple throttle reset, not a power cycle.

The current sensing shunt is located between the capacitor bank and the FETs, instead of the usual location between the battery and bulk caps. The link caps are on the FETs as they should be, but putting the shunt after the bulk caps allows it to see the current peaks instead of just reading averages and being very delayed when there is a fault. There's a fast comparator and DAC in this CPU to set adjustable thresholds for quickly tripping off the FETs (in hardware, bypassing the CPU) if the current spikes. The goal here is to protect the controller from overcurrent faults. This CPU again shows its credentials for motor control.

It would be nice to automatically determine the hall wiring, but I'm not planning to start there. That can be an improvement for later on. That's a nice feature, but not really necessary. KISS principle.

edit - updated the spreadsheet with some color, expanded some features

 

[Alan B]

PWM Techniques

There were too many errors in the earlier posting here about PWM techniques, so I decided to delete it and start over.

The extremely flexible PWM generation capability of the ATmega32M1's Power Stage Controller allows us to generate many different forms of PWM. These variant PWMs have different properties for regen, braking, and sensorless back EMF detection. There are many choices - Two Quadrant, Four Quadrant, Unipolar, Bipolar as well as choices in the setup of the Power Stage Controller with Ramped or Centered waveform generation.

This "Which PWM Techique is Best" series of articles scratches the surface and gives some ideas. It doesn't cover all the characteristics we need to understand to make our choices. They do have some software simulations that might help to answer more questions, I haven't tried those.

https://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2012/03/19/so-which-pwm-technique-is-best-part-1

https://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2012/03/26/so-which-pwm-technique-is-best-part-2

https://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2012/03/29/so-which-pwm-technique-is-best-part-3

https://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2012/04/04/so-which-pwm-technique-is-best-part-4

https://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2012/04/09/so-which-pwm-technique-is-best-part-5

https://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2012/04/13/so-which-pwm-technique-is-best-part-6

https://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2012/04/18/so-which-pwm-technique-is-best-part-7

With the flexible hardware we have in this CPU, and the hall sensors for commutation we can set up software to try different PWM controls and see how it works out for our needs. Ultimately we may want to use more than one PWM style to meet all our goals. The micro code can change PWM techniques on the fly.

The more difficult question comes in when we want to do sensorless control and get a good clean back EMF signal, and when we want to do regen or plug braking.

Take a look at those articles and see what fun is in store here.

 

[Alan B]

Following is a simple outline of an initial program for motor control. It really doesn't take much code to do this given the hardware that the ATmegaxxM1 has for doing it. It will of course grow as features are added, but starting simple is a good way to get some experience and have some early success. This one has PWM throttle, hall commutation, ebrake and current limiting. It uses pin change interrupts to commutate the motor from hall inputs, measures throttle position and calculates new PWM values. The current and other ADC measurements are via a PWM synchronous trigger so it occurs at the proper time synchronized with the PWM cycle. The ADC sequence is not detailed yet, but will likely alternate between the current reading(s) and the other readings in a rotation, so the current is read every other cycle since it is most important, and the others are read in a rotation the other half the time. Thus the current would be read at an 8 khz rate, and the others at some fraction of 8 khz, probably about 2 khz for four other channels. This includes throttle, battery voltage, motor temperature, etc., which don't need as high a reading rate.

If there are any faults this version shuts down the PWM outputs, displays the fault info, and resets when the user throttles back to zero. Startup also requires a zero throttle before it will get going and after the ebrake is triggered the throttle must be rolled back to zero to regain power. This way if there is a throttle failure and the ebrake is triggered it will not go back to full power when the ebrake is released. There is also a check for throttle out of range for various broken throttle or wiring failure faults.

A Simple Hall Sensored Motor Control Software Outline

process fault macro
    set fault flag
    store fault info
    update PSC

initialize
    init startup fault (forces wait for zero throttle)
    setup pin change interrupts for ebrake and motor hall sensors
    setup psc 16 khz centered PWM, interrupt
    setup adc for mid PWM triggering, end of conversion interrupt
    setup overcurrent trip hardware
    setup watchdog timer reset
    setup output for serial display

main loop
    output fault info to display
    output readings to display
    delay()

pin change interrupt handler for ebrake and motor position sensors
    if ebrake changed
        if ebrake true then set ebrake fault and update PSC
    if hall sensors changed
        if not in rotation order then fault
        store new position
        update PSC

end of ADC conversion interrupt handler
    get raw reading
    setup for next reading

    switch(reading)        process raw reading

        case motor current: 
            filter current reading
            check current and update PWM clamps to control current
            if current way too high then fault

        case throttle: 
            filter throttle reading
            fault on raw throttle out of range
            if throttle value zero and ebrake false reset faults
            convert throttle to 0-1 value
            if fault then clamp throttle to 0
            calculate throttle request in PWM units
            apply overcurrent throttle clamp
            result is new updated throttle PWM value
            udpate PSC will schedule this into the hardware at the next PWM pulse

        case battery voltage: 
            filter battery voltage reading
            check for LVC and fault if too low

        case motor temperature: 
            filter motor temperature reading
            calculate new motor temperature, and dependent values
            if motor temperature too high then motor temp fault

update PSC function
    asynch items
    if fault shutdown PSC outputs
    if commutation terminate cycle
    synchronous items
    lock
    update registers per commutation position (per hall code)
    unlock

 

[Alan B]

Nice to see this forum updated with new software. Good job neptronix!

I've been doing some work on this BLDC Controller project. I've updated some of the postings within the thread, but most of the effort has been on starting to organize and write code and collect some hardware.

I've been researching the hardware datasheets and starting on the commutation code, which needs to be fast and efficient for good performance at higher RPM. I updated the code outline in the previous posting and started by writing a Python program to analyze the commutation sequencing from waveform tables. I like putting detail into tables that are easily checked and changed rather than in the code itself. The Python program converts this into code with details. This is faster, easier and more fun than writing in C (at least for me). I started writing C before the ANSI version existed and have worked with it a lot, it is a great tool for embedded processing, but Python is better for doing research.

The Python program generates the actual C code for the embedded compiler, which then makes machine language for the chip. This is a really nice way to handle all the preprocessing. It doesn't get around writing the C code, because we still have to write and embed C templates into the Python, but it allows us a very powerful abstraction layer on top of C's richness that far exceeds what we could do with C's built in preprocessor.

So when you run the Python program it generates the C file(s), along with anything else you want like error-checking the sequence tables. The resulting C files are then compiled by the embedded tools and loaded into the processor. When we are ready for that. Or you can just look at the C code and decide if that is what you want, and change the Python file until you get C you like.

For example, in this example I was studying the code for commutation. By writing in Python and generating C I was able to try different C control structures easily. I started using a switch case statement, but after some research was reminded that switch case is not advisable in an interrupt service handler (which commutation is) due to various issues like stack space consumption. So I tried other structures and settled on a table of function pointers. Due to the symmetry of commutation, we only have to write one template and it gets generated for all six of the commutation steps, driven by the same waveform tables that were used for the switch case example.

Whether that is convincing to others or not, I have done this type of "writing a program to write the final program" many times in the past. At first people often don't understand why I'm doing it, later after the project is running they are happy we did it this way. Building a tool to make the job easier takes a bit more time up front, but the payoff is big later on, if the right tool is built. In any case, that's what I'm experimenting with now. Not all the tools are useful, sometimes it takes a few tries to build the right one.

There is another approach taken by a project here on ES that is worth a look. They chose some available inexpensive hardware and are re-programming it with their own code. They are using STM8 based ebike controllers and working on new firmware written directly in C. So they avoid the "construct hardware" step. So they can quickly try their software on hardware (and blow it up).

https://endless-sphere.com/forums/viewtopic.php?f=30&t=87870

I have looked around for available hardware that has the ATmegaXXM1, but I did not find anything that was suitable. So when I get in the mood to do some PC board design I'll have to make some boards. I've done a lot of that in the past, and will get back to it at some point.

But for now I'll work on the software. When I have something that looks like it needs to be tested then I'll get more serious about building some hardware.

 

[Alan B]

Most ebike controller throttles are implemented wrong. There are a few that work properly, and we'll get to those later in this article. But the vast majority are done incorrectly.

They do a very simple thing, and map the throttle directly to the PWM duty cycle. Zero throttle is no duty cycle, easy enough, and full throttle is full duty cycle. This seemingly simple idea doesn't work and leads to a number of problems and wastes most of the throttle's adjustment range. It makes our wrists sore and our bikes jerky and hard to control. It causes us to want three speed switches and cruise controls, which are not really needed if things are done better.

So what does "duty cycle" mean, really? Boiled down to simplicity, it means "effective motor voltage". Now, the way the controller FETs work, the voltage applied to the motor alternates between zero and full battery voltage, because the FETs are used as switches that are either on or off. However the inductance of the motor filters this into a nearly smooth motor current, so the effective motor voltage is the voltage that would produce this same average current, the same torque, and the same heating in the motor. It is equal to the battery voltage times the duty cycle. So when you twist the throttle you are effectively applying a variable voltage, from zero to full battery, to the motor. This sounds good, however it is a poor idea for ebikes.

So let's look at how this works. Assume we're moving at half of full speed. So the motor's back EMF is half the battery voltage. In this case, over the throttle's first half of it's range, the effective motor voltage is less than the motor's back EMF. So in this range nothing happens at all when we move the throttle there. The voltage from the controller doesn't overcome the back EMF so no current flow results. so 50% of the throttle's motion is wasted throttle movement doing nothing useful.

Above the halfway point the throttle begins to do something, and the motor current increases. After less than a quarter of a turn or so the maximum power is being produced in the motor and beyond that point the movement of the throttle has no further effect. So the variation is compressed into a small region of the throttle, making it sensitive to small motions.

So, over the range of the throttle, only about 1/5 (or evens less) does anything in terms of changing the motor current. The rest is wasted. The higher powered the ebike is, the smaller this useful adjustment range becomes. We can do better.

What would we like to see? The control variation should be spread across the entire throttle's rotation. How can we do this? Change to a Torque throttle. Zero is zero, of course, but from there to the maximum we should vary motor torque over its full range. Torque is proportional to motor current, so we vary the motor current over the range. Sounds simple enough. We want a throttle that varies motor current from zero to maximum as it rotates over its full range of motion.

How can we do this? I know of two ways. One is feedback loops. This is the way Field Oriented Controllers do it. They read the motor current (also called phase current), and they adjust the duty cycle to get the desired current. The key thing here is they measure motor current, making it easy to control it. But most ebike controllers don't even measure motor current..

But what about our DIY controller? It can measure motor current, so a feedback loop is possible. But feedback loops add delay and can be hard to tune. There's another way...

We can calculate it. Find the duty cycle range and map the throttle to that. It requires a few calculations, and it changes with speed. So it has to be done on the fly. It also requires knowing things about the motor like the resistance and the back EMF voltage.
The basic formula is quite simple (remember ohm's law?):

I = E / R

In this case the motor voltage is reduced by the motor's back EMF as well as the duty cycle:

motor current = (effective motor voltage - back EMF) / resistance

That doesn't seem hard. Motor voltage is:

effective motor voltage = battery voltage * duty cycle

We can calculate the motor's back EMF:

back EMF = motor RPM * motor KV

Where motor KV is in units of Volts per RPM

So motor KV is a constant for a particular motor. Resistance is for the system, but mostly the motor determines this. It changes with motor temperature, but if we ignore that the current just goes down a bit when the motor gets hot. We could compensate for it, that might be a good future upgrade.

We do have to decide on the maximum motor current we want. This is a good thing because it drives motor heating:

motor heat = motor current ^2 * resistance

And motor current generates torque:

torque = motor current * torque constant

But we don't have to get into torque calculations, just decide what maximum motor current we want to use. If we allow a larger value it will produce more heat, or we could choose a more conservative value and get a bit less torque but also a cooler motor. On my Sabvoton Cromotored bike I selected the max current to be just less than required to lift the front wheel. So it does not wheelie, which makes the bike very easy to ride, despite having a lot of power.

If we know a few things about the system like KV and resistance we can calculate the duty cycle to get the range of motor current and map the throttle to this range. It needs to change as speed changes, so it takes a little work, but it results in a throttle that has essentially no lag, and responds without excessive current. There is a minor delay from the motor inductance, which we could compensate for at less than full speeds, but it is already so much faster than regular throttles we probably don't want to. In fact we may have to add some throttle delay because this will be so fast.

Note that we don't have to measure motor current to do this. We do need to measure motor speed (RPM) and battery voltage. We could assume a fixed battery voltage, and it would just taper off the current a bit as the battery sagged. But we measure battery voltage already.

Measuring the motor speed is critical as it affects the motor current a great deal. We need it to subtract out the dead throttle range. If we don't read it accurately it may cause the throttle to waver.

This is a feature I want to test out in my DIY controller. It would make this controller throttle work the way a throttle should work. The way modern hybrid and EV throttles work. I have experienced this on electric cars and motorcycles, hybrid cars and some of my ebikes already. Even new computer controlled internal combustion engine (ICE) vehicles use this technology. With smooth control the need for three speed switches and cruise controls goes way down. Good control, the way it should be.

So what ebike controllers do this already? Most Field Oriented Controllers do, as well as a few others. The Grin PhaseRunner (a collaboration with ASI) does, and the Sabvoton for example. ASI's other products do. Some others do also. The BBSHD has something similar. Zero motorcycles do, so the Sevcon must have this capability. I hear some Kelly controllers do. FOC is not required to do this.

One side effect of torque throttle is the behavior with the wheels off the ground. If you put your torque throttle bike on a stand and twist the throttle slightly, calling for a certain torque with no load, the wheel speed goes quickly to max (it is trying to get to that requested torque, and with no load accelerates till it reaches the torque or runs out of speed range). Some torque throttles implement a "torque plus speed" throttle that limits to torque or speed to avoid this. It is not too hard to do, but it is not needed when there is a load on the motor. Another future improvement, perhaps. It is not a problem when the bike is being ridden, just on the stand.

There are still uses for three speed switches and cruise control, but they are much less needed. Build a torque throttle first, then see what is really required. Keep it simple, but do it right.

 

[Buk___]

I'm a little reluctant to post my ramblings in this thread and in response to your technically inciteful post,
so if what I've posted below is just too simplistic for you to even consider, fell free to ignore it completely.

The first thought that popped into my mind when I read your stuff about the limited effective range of throttles was: logarithmic potentiometers. I won't pursue that further as it seems so obvious an answer that it must be wrong otherwise everyone would be using them.

The other thought I've been having, though not directly in response to your post, is the idea that as electric motors run less efficiently when running at low speed, but seem to happily run on a range of input voltages, a three position switching between 24V, 36V and 48V naively would allow the rider to select a range appropriate to the type of riding they are doing and perhaps keep the motor in a happier place when running at low speeds around town or on shared usage paths etc. (Perhaps this is what you are referring to when you said: "It causes us to want three speed switches"?)

Whether this would be best achieved by taping different points in a series of battery packs (which would unbalance the packs?),
or perhaps by arranging three or more set points on a DC-DC converter capable of both buck and boost mode I'm unsure.

Anyway, if you have the time & motivation to set me straight, I'd be grateful to learn.

 

[Alan B]

I'm a little reluctant to post my ramblings in this thread and in response to your technically inciteful post,
so if what I've posted below is just too simplistic for you to even consider, fell free to ignore it completely.

The first thought that popped into my mind when I read your stuff about the limited effective range of throttles was: logarithmic potentiometers. I won't pursue that further as it seems so obvious an answer that it must be wrong otherwise everyone would be using them.

The other thought I've been having, though not directly in response to your post, is the idea that as electric motors run less efficiently when running at low speed, but seem to happily run on a range of input voltages, a three position switching between 24V, 36V and 48V naively would allow the rider to select a range appropriate to the type of riding they are doing and perhaps keep the motor in a happier place when running at low speeds around town or on shared usage paths etc. (Perhaps this is what you are referring to when you said: "It causes us to want three speed switches"?)

Whether this would be best achieved by taping different points in a series of battery packs (which would unbalance the packs?),
or perhaps by arranging three or more set points on a DC-DC converter capable of both buck and boost mode I'm unsure.

Anyway, if you have the time & motivation to set me straight, I'd be grateful to learn.

Logarithmic potentiometers are just one way to map throttle position to PWM. No fixed mapping works here. It must change with speed. The useful range of PWM is perhaps 10 or 20 percent of the total, and the range slides from zero to 100% depending on the current speed. The throttle must map to that range to have useful change distributed over it's positional range. The rest of the PWM range produces either zero or full current, and must be mapped out or it will waste throttle motion. Those portions need to be "above" or "below" the throttle's range of rotation.

The way a motor controller works is essentially identical to a buck DC-DC converter already. It takes in voltage and steps it down using PWM and inductance of the motor. It takes in current and correspondingly steps it up, so the power input and the power output are essentially the same, aside from minor losses.

Changing the PWM duty cycle is nearly exactly the same as reducing the supply voltage. There's simply no reason to tackle the complexity of rearranging the battery.

For a given system, load and speed the efficiency is fixed. You need a certain torque to make that speed. That fixes the motor current. The motor has a certain resistance, so that fixes the heat loss. The load and speed fixes the useful work output. So the work and the loss is fixed and the efficiency is also fixed. There's nothing to change. Voltage wise, you either have enough, or not. So the battery and/or controller cannot really improve efficiency here.

The only way to keep the motor in a happier place is to reduce the standing torque requirement, the part that produces no work. Gearing can do this. Going a little faster can help, but the losses go up fast as well. A motor with more copper or lower resistance conductors can reduce resistance and loss.

 

[Buk___]

Thanks for your detailed reply.

 

[Buk___]

Changing the PWM duty cycle is nearly exactly the same as reducing the supply voltage. ... For a given system, load and speed the efficiency is fixed. You need a certain torque to make that speed. That fixes the motor current. The motor has a certain resistance, so that fixes the heat loss. The load and speed fixes the useful work output. So the work and the loss is fixed and the efficiency is also fixed.

Here I go again. Dumb I know, but you tolerated me once

Once a motor has achieved a given speed, the efficiency remains the same regardless of lower-V & higher-A or higher-V & lower-A; but doesn't the problem arise in getting there?

Ie. When doing stop-start riding through sets of lights, each time you pull away, you open the throttle wide to get up to speed ASAP, before rolling it back to maintain whatever speed is right.

During the acceleration the controller is effectively calling for either a given 'higher then now' speed, or full-torque, depending on the type of throttle/controller. To start, the motor is currently moving slower than the asked for speed, or too slow to produce the asked for torque, but the controller is pouring the full voltage in and the motor will draw full amperage.

Since the motor is turning too slowly for all that wattage to be converted to work, a large proportion of it is turned to heat. Hence why hill climbing with 'fast wound' motors that don't have sufficient power to accelerate on a hill will overheat.

If you started off acceleration with 24V and only stepped up once road speed had reached the limits of 24V, full throttle would be putting less wattage into the motor, so less would be shed as heat.

 

[Alan B]

Changing the PWM duty cycle is nearly exactly the same as reducing the supply voltage. ... For a given system, load and speed the efficiency is fixed. You need a certain torque to make that speed. That fixes the motor current. The motor has a certain resistance, so that fixes the heat loss. The load and speed fixes the useful work output. So the work and the loss is fixed and the efficiency is also fixed.

Here I go again. Dumb I know, but you tolerated me once

Once a motor has achieved a given speed, the efficiency remains the same regardless of lower-V & higher-A or higher-V & lower-A; but doesn't the problem arise in getting there?

Ie. When doing stop-start riding through sets of lights, each time you pull away, you open the throttle wide to get up to speed ASAP, before rolling it back to maintain whatever speed is right.

During the acceleration the controller is effectively calling for either a given 'higher then now' speed, or full-torque, depending on the type of throttle/controller. To start, the motor is currently moving slower than the asked for speed, or too slow to produce the asked for torque, but the controller is pouring the full voltage in and the motor will draw full amperage.

Since the motor is turning too slowly for all that wattage to be converted to work, a large proportion of it is turned to heat. Hence why hill climbing with 'fast wound' motors that don't have sufficient power to accelerate on a hill will overheat.

If you started off acceleration with 24V and only stepped up once road speed had reached the limits of 24V, full throttle would be putting less wattage into the motor, so less would be shed as heat.

Try to keep a simple, quantitative mathematical view of what is happening. Visualize the math in steps. The base formulas are simple.

Adjusting the throttle you can make whatever effective voltage you want (up to battery voltage). The Back EMF (from motor RPM) determines how much of this applied voltage is left over to drive the motor, and the resistance determines the current. The current determines the torque and the current squared determines the heat. If you put too much current into the motor it gets much less efficient. Best to stay below the first saturation knee, that really wastes power as the torque growth per amp is lower beyond the first knee of the curve. Nothing magic is going on here. Just simple relationships interacting.

By twisting the throttle you control the heat generated and the torque. Whatever torque is not needed for maintaining the current speed goes into acceleration. Torque is not wasted. Torque does not go into heat. Current makes heat in resistance, and it makes magnetic field which makes torque. If you built a superconducting motor, it would generate only torque, not heat.

The motor is capable of dissipating some amount of heat. How much? Depends on the size, the temperature it can tolerate, the heat path and the airflow. If you dissipate this amount of heat or less you can do so indefinitely. Given this amount of heat, and the I squared R, and the motor's R value you can calculate the max continuous current rating for the motor. From that and the torque constant for the motor you can calculate the max continuous torque. This you can use full-time and not overheat the motor.

It becomes a problem when this torque level is insufficient to get the job done. The hill is too steep, the wheel is too large, etc. Then we raise the voltage, which increases the current and we ask the motor to generate more torque than the continuous level it can handle. It will make more torque, and it will make more heat (remember I squared for heat and just I for torque, so the heat rises much faster than the torque). The increased torque will help climb the hill, but the heat will start warming the thermal mass of the motor above the safe temperature. This is where we have a problem that depends on the amount of thermal mass, and the distance, speed and time duration of the climb vs the overheating of the motor. By the way, the current here can be way above the full rated current for the motor and far more than the battery current. By using a large voltage we can force the current. This is why raising the voltage causes such a performance improvement and why it can lead to melting the motor.

The motor will produce the asked for torque immediately (as soon as the current increases). It has no choice. Torque is motor current times torque constant for the motor. The heat production is motor current squared times resistance. The resistance will rise with temperature, increasing heat production even more. It cannot generate (significant) heat any other way.

But either way, if you control the voltage with the throttle or the current with the throttle, is equivalent in the motor. One is just much easier for the wrist muscles than the other due to the gain or sensitivity of the control. The path you follow to the stable conditions does make a difference in the efficiency of getting there. Efficiency has always been about moderate throttle usage, it is no different here because using more torque than needed develops I squared R heat losses much more than it develops increased torque.

For a vehicle and a fixed set of conditions there is an optimal speed for best efficiency. Either slower or faster reduces the efficiency. Go too slow and the duration gets too long, and the fixed losses dominate. Go too fast and increasing losses from pushing air aside dominate, and best efficiency is in between and is probably a low speed. The same is true on a gradient, but the climbing losses are much higher due to the gradient, so the optimal velocity rises, otherwise too much time on the hill takes too much energy. But opening the throttle fully will not be the best plan in either case.

Hope this helps.

 

[Buk___]

The base formulas are simple.

That's very true for the steady state case, but for the for the dynamic case -- accelerating from different starting speeds, against differing loads; wind, slope etc. -- is substantially harder and less intuitive. Even the best dynamic simulations are approximations interpolating between a fixed number empirically determined data points.

(I think) I get the steady-state case; but I've been trying to wrap my brain around the reason why those who have extensive real-world experience small motors, advise 'slow' winds over 'fast' winds for hill climbing on small motors. Eg. '201' wound Q128 in preference to '328' wound.

Whilst others say that the wind makes no difference to torque.

Now maybe, there is no conflict between those two positions, and the only conflict is with my (very apparently lacking) intuition on the subject; but it certainly feels like there is still something missing from my intuition that isn't directly soluble using the simple static equations or static simulations like the ebike.ca one.

May be the solution is entirely in the hands of the rider and fine throttle control -- if my damn motor ever gets shipped I may be in a position to get a real-world feel for the thing and the conflict in my head will go away -- but right now I'm limited to a vicarious experience and it feels like the controler could do more to aid the rider in that control. Which, getting back to your threads subject, I'm whiling away the waiting time by trying to plan a Raspberry Pi Zero based throttle control for a dual motor rim drive (that I may never get around to building).

I kind of like the idea of a different kind of throttle mechanism that I can only describe as a "rocker throttle". The basic idea is of a 3 position switch with the central position being the detente position and up & down being momentary contacts. The intent is to activate the rocker switch using a (half) twist grip; twitch down to increase speed, twitch up to decrease and do nothing to maintain current speed. When in the central (no effort) position, the controller seeks to maintain the current (road) speed. If the up position is pressed momentarily, it seeks to increase the current road speed by some small increment; and down momentarily decreases it by the same amount. If the up is pressed and held, the speed is increased at some steady rate, and if down is held for more than (say) 1/4 second, then the motors disengage.

A separate lever is used to mechanically reengage the motors and the controller waits until they motors are turning at the same speed as the wheel before engaging enough power drive the motors to match and maintain the current speed. applying the brakes also disengages the motors.

Hope this helps.

It really does. If only to make me realise how wrong my intuition is and therefore how much I have to learn.

 

[Alan B]

The simulations are amazingly accurate, but people misinterpret them most of the time. Justin has recently made upgrades that should help this, however I have not spent much time with the new sims. The two biggest problems with interpretations are understanding the full throttle test condition results and the actual meaning of the efficiency curves. The ability to handle two motors at once for dual drives is also major, previously doing this led to many errors. I look forward to using the improvements to help tune the dual PhaseRunners on the Bonanza.

Keeping in mind that the windings just make magnetic fields (and heat), and the fields and physical dimensions make torque might help the thinking about equivalency. In my case I went through this learning curve with the Bonanza, linked below, and tried the speed and torque winds in the same bike. I ended up with the torque wind which requires higher voltage and lower current which turns out to be perfect for the PhaseRunner's six FET current capacity. Earlier I ran a 12 FET controller on it which could handle the higher current required by the speed winding motor I started with. Both motor setups were marginal for California gradients. The bottom line is that bike had marginal torque with either wind of 9C motor in the rear wheel when tackling steep gradients (like my commute and the fire road in Marin). The solution is more torque production capacity, which I accomplished in several different ways. One was to build a bike with a double width motor, the Cromotor in the Borg. The other was to add a second front (geared) motor to the Bonanza. In both cases this produced twice the torque and believe me, both solutions make a huge improvement (from hot to not). The third solution I tested was to use a mid-drive with the Ridge Runner using a BBSHD. Each of the three approaches produced significantly improved results and very different machines with varied riding experiences, and all are documented here on ES from the links in my sig. All three handle the job at lower heat production levels.

Good luck on your journeys, both learning and riding. My ebikes have been some of the most educational projects in my life experience. One does not have to understand them to enjoy them, but there is a huge opportunity there for learning electronics and physics. I originally skipped motors and three phase power in my Engineering education (favoring electronics, computing and controls), but between precision motion requirements in my career and ebikes I filled that void in later, and am still learning.