Timing Adjustment Tool

[Burtie]

Edit: I will use the beginning of this thread to publish the most up to date reference info on the Timing Adjuster, so it is easy to find.

Introduction:
The Timing Adjuster (TA) is a microcontroller based gadget that can be used with any sensored controller.
It sits between the hall sensors in the motor, and the sensor inputs to the controller, and allows the motor timing to be adjusted electronically.

An interface program running on a PC is used to configure the many settings of the TA, and can also display data about the motor as it is running.

In addition to static timing adjustments, motor timing can be modified dynamicaly in response to RPM, Throttle position and Phase Current.
The aim of continually adjusting the timing is to help keep the motor operating at its maximum efficiency, or maximum performance











Lots more words in this TA2Userguide . I will try to keep this userguide updated as it progresses.
View attachment TA2-Userguide.doc


Installer for PC interface program v2.02 (this works with current TA2, updated March 2012)
View attachment 1


Installer for PC interface program v1.02 (this works with the original TA prototypes)
View attachment TimingAdjuster v1.02.zip


Driver for HL-340 usb serial adapter
View attachment 4
View attachment HL-340 win7 x64.zip

Burtie

 

[Burtie]

With one of these modules attached, you can vary the timing depending on the phase current drawn by the motor


Link to the sale thread :
http://endless-sphere.com/forums/viewtopic.php?f=31&t=26068

 

[markobetti]

go burtie ,go !

 

[John in CR]

I'm having some difficulty understanding how a variable timing helps with an electric motor. With an electric motor things happen at electronic speed so there would seem to be only one optimum "timing", because there is only 1 exact position where the coil polarity should change from attracting the approaching magnet to pushing it away as it's leaving. Varying the duration of the ON status of a winding for that segment of the commutation would seem to make more sense. If the "ON period" is variable then I can see the timing of it coming into play as something beneficial to vary, but moving the start of the ON status without varying its duration doesn't make sense to me.

 

[rolf_w]

I'm having some difficulty understanding how a variable timing helps with an electric motor...

same with me - it would be nice to get some lessons in BLDC basics (or get some links... )

I give it a try with something I remember from brushed dc motors:
For brushed dc motors advancing or retarding the brushes allows to avoid brush sparking. The brushes commutate (reverse) the current through the windings which should be done when the back emf is exactly zero thus at an exact position of the rotor (windings) related to the stator (magnets). This 'zero back emf' position, however, is also dependent of the current through the winding, since they produce also part of the emf inducing magnetic field. Brushes would thus have to be moved according to the load.
This might be translated to BLDC too?

Am I right that a timing adjustment tool would need to allow for a) advancing / retarding the commutation pattern b) correcting the mechanical positioning errors and c) switching Y/D motor connection ?

 

[Burtie]

John in CR wrote:
I'm having some difficulty understanding how a variable timing helps with an electric motor

Hi John,
My (perhaps overly simplistic ) understanding is that: When the controller applies a voltage to a stator winding, due to the inductance of the stator, the current takes a finite time to build. So we need to energise the winding some time before the point where we want the maximum current to be flowing.

When the motor is spinning, the time can be translated into degrees of rotation, the time for the current to build remains constant, but as the motor speed increases, this translates to a larger number of degrees of advance. Therefore RPM dependent phase advance is desireable.

rolf_w wrote:
Am I right that a timing adjustment tool would need to allow for a) advancing / retarding the commutation pattern b) correcting the mechanical positioning errors and c) switching Y/D motor connection ?

Hi rolf
Yes to all points ( more specific for point (c), will allow required timing correction for Y/D config change)


Burtie

 

[John in CR]

Thanks Burtie,
That makes sense, but I'm surprised that the controllers don't already consider the fixed coil delay, though I guess the delay due to inductance varies by motor due to different windings. I wonder if the lower delay of my motors with very low turn counts is a factor in all controllers running hot with them, and not just the current limiting.

 

[dozentrio]

Yes, go Burtie go! I want this finished before my bike is, because now that I'm aware of the issue, it just doesn't seem right to have a motor controller which DOESN'T do this

 

[liveforphysics]

John, you ask a great question. Why isn't zero advance or retard always ideal?

To answer it, I think looking to the experience gained from RC car motors with adjustable sensors, or even brushed motors with adjustable brush ring positions. You can use advanced timing to compensate for coil field rise time at higher RPMs, which prevents premature torque decreases as rpms increase. This can make a 50kv motor into a 60+kv motor when you need it (going for max power).

Or, even more useful, it can be retarded to lower kv, and greatly decrease no-load waste currents on a motor for the times you just want to cruise along with minimal controller heating, motor heating, and trying to maximize range.

 

[liveforphysics]

And with a neat little device like this, its got throttle input, then the same little box can give you max economy retarded settings when you're just cruising along at mid throttle, then give you peak power when you need it by advancing timing when you need a burst of speed to jet around a car or whatever.

 

[Burtie]

From the 'Adding hall sensors to outrunners' thread:

dozentrio wrote:
I wonder if it's possible to adjust the timing of EACH hall signal individually, though. At very small intervals too? Say, tenths of a degree? That way, even if you haven't mounted them exactly perfectly, the software could adjust the signal so that it runs perfectly smooth. I could potentially contribute on the code for that.

I was thinking that once the motor is running fast enough, we have a fairly predictable hall signal sequence. We would only need to use the timing reference from one sensor to allow us to generate the signals for all three sensors. This way we would ensure that the signals were generated exactly 120 E degrees from each other.

The accuracy of placement and relative spacing of the 3 hall sensors would only really be important when the motor was starting.

 

[rolf_w]

A short video showing the effect of adjusting the brush ring whilst driving on a brushed motor in a http://www.quantya.com
[youtube]LYHZtl3Jq9g[/youtube]

 

[dozentrio]

We would only need to use the timing reference from one sensor to allow us to generate the signals for all three sensors. This way we would ensure that the signals were generated exactly 120 E degrees from each other.

The accuracy of placement and relative spacing of the 3 hall sensors would only really be important when the motor was starting.

True! I'm still working on learning exactly how it all works. I don't really understand why 3 hall sensors are needed even for starting. Anywhere I can figure this stuff out in detail?

 

[deVries]

I was reading in another thread about this...

I've played with it extensively...

The purpose in the eyes of eBike designers is quite simple... Although some hub motors are really torquey, most just arent... to that end, you need the most torque when launching from a dead stop and so...

An engineer decides what wattage and determines the motor's torque output based on 1355 / No Load KV * Amps... Then depending on the requirements, for instance a max load weight of 300 lbs the engineer needs to find a way to get that mass (the 300lbs of you bike batteries and motor) moving along quickly... though accelleration takes more power, it only needs that power for a short time... hence Block time is supposed to be the delay in seconds before the limiting kicks in and brings you back to the programmed primary current.

Another bit you may or may not have realized is the purpose of Phase Current and why it is different than Primary or Battery Current...

At lower speeds the controller can multiply the current at the cost of voltage which is only needed (the higher voltage) once the motor is trying to gain speed.... That's why people with 9C usually recommend 2.5 X the Primary Current for this setting and it's the current your phase windings are slammed with on startup... the block time allows for a momentary surge of Primary Current to enable the output which is current amplified (the FETs do this) which in a 26" DD 9x7 Rear (Loaded kV of 10.10 @ 48v - load rating 100KG / 220lbs) - these motors don't have enough torque at 45A to get you moving and thus reduce duty cycle and power handling of the FETs, phases and every other component... then when you approach speed... you will see your current taper down because "An object in motion stays in motion unless acted upon by an outside force".

By comparison - I have found that using Phase Current of lower multipliers of Primary Current like 1.5 X will result in higher top end speeds because the voltage sag is less in the current amplification process.

If your using geared hubs... these are the most fun, here I begin at 1:1 with block time at about 5 (I do run 69A limit on a 9FET shunt soldered and reprogrammed infineon with stock fets and caps) - I can't keep the nose down and my top speed reaches 30+ mph where as when I had the Phase Current at 2.5 the max speed was 27mph... Next I increased the multiplier until my top speed on a flat without wind dropped measurably... This gives me the absolute best combo of slamming accelleration, higher top speeds and better efficiency since the motor spends less time at low inefficient speeds.

And, I see all the work you brilliant ES contributors are doing to install hall sensors with RC motors and adjust the timing to affect torque/speed and efficiencies, etc.

And, since I know nothing about the technical aspects about all this, I wonder why some type of ESC can't be programmed too? There are ESC for hot-rod wheel driven models and boats (besides the aero/heli flight) that might have some programmable features to at least help with stop to start-up conditions???

I obviously don't know, since I'm new to building eBikes and know nothing about the RC world. I did read on some thread that one can overcome some of these issues with start-up from stops if you get a 150amp+ ESC... I guess to handle the power and not burn-up ?... but why not have the ESC programmed to do something like Mike refers to at the top in this post?

This may be a stupid question for those in the know, but I'm sure newbies with little electrical knowledge just starting out might wonder about this too.

TIA for any help and explanations...

 

[amberwolf]

There's no *technical* reason the ESC couldn't be reprogrammed to do this work by itself, as part of normal operation as a controller. But it is highly unlikely that you'd be able to get the source code for the ESC from the manufacturer so you could rewrite it to do so. That would require writing totally new ESC code from scratch, debugging it (probably blowing up a lot of controllers in the process), and then verifying that it works the same way the original code did (or better) plus the modifications.

It's also unlikely the ESC manufacturers would even consider putting anything like this directly into their code unless someone first proves it is a very useful feature that the majority of their customer base will want, or that they can at least use as a marketing point to sell more controllers to justify the expense of rewriting and debugging. If you can prove the idea useful and saleable, I'm sure they'd be more than happy to steal the idea and any code created, then adapt it for their MCUs in the ESCs, and market away.

 

[deVries]

There's no *technical* reason the ESC couldn't be reprogrammed to do this work by itself, as part of normal operation as a controller.

Thanks for your explanation noting the major limitation of obtaining the source code to do it.

Some RC ESC do come with some limited user programmable feature sets, so I'm wondering if there is one of these that might help with ramp-up speed or acceleration from stop to start-up conditions?

 

[rhitee05]

I don't really understand why 3 hall sensors are needed even for starting.

There are 6 possible commutation states for the controller. Consider the hall signals as binary bits, you need 3 bits to uniquely identify each of the 6 states.

 

[Burtie]

The weather has been kind to us in Southern England lately, so I have been out biking around and not working on this project too hard

It is prooving a tougher job than I expected, but I have made some progress. Still a long way to go, but at least the concept seems feasable.
Here is a short nerdy video for those of us who enjoy that sort of thing.


http://www.youtube.com/watch?v=RZDLpqs5Sc0
[youtube]RZDLpqs5Sc0[/youtube]


BTW, NO -I didnt choose those flowery curtains :|

burtie.

 

[gwhy!]

The weather has been kind to us in Southern England lately, so I have been out biking around and not working on this project too hard

It is prooving a tougher job than I expected, but I have made some progress. Still a long way to go, but at least the concept seems feasable.
Here is a short nerdy video for those of us who enjoy that sort of thing.


http://www.youtube.com/watch?v=RZDLpqs5Sc0


BTW I didnt choose those flowery curtains :|

burtie.

Hi Burtie,
Its looking good . The starting issue with the motor can be resolved by programming the 6 fet with 12 or 18 fet settings and adjust shunt to compensate for current, Im sure you are aware of this but just thought will mention it as it may help testing your set up a bit easier ( consistent ).

 

[Burtie]

gwhy,

Thanks, but I welcome the over-current transient protection at the moment, because of the horrible conditions I am subjecting this un-modified controller to during this testing

burtie

 

[dozentrio]

need any help? I am eagerly awaiting developments because i want to use this to optimize my own hall sensor positioning...

 

[markobetti]

gwhy,

Thanks, but I welcome the over-current transient protection at the moment, because of the horrible conditions I am subjecting this un-modified controller to during this testing

burtie

Dear Burtie , when we were testing Colossus mr. Chubichevic made a similiar device but with less adjustable settings... .. i will ask him to join discussion if he finds time

 

[liveforphysics]

The weather has been kind to us in Southern England lately, so I have been out biking around and not working on this project too hard

It is prooving a tougher job than I expected, but I have made some progress. Still a long way to go, but at least the concept seems feasable.
Here is a short nerdy video for those of us who enjoy that sort of thing.


http://www.youtube.com/watch?v=RZDLpqs5Sc0
[youtube]RZDLpqs5Sc0[/youtube]


BTW, NO -I didnt choose those flowery curtains :|

burtie.

Burtie! This is awesome! Great work! It's amazing how sensitive the motors are to a little tiny bit of timing change isn't it? I thought I was going crazy when I was first setting mine up, and moving it a quarter of a mm would cause a few amps +- of no-load current. lol

 

[Tiberius]

Hi Burtie,

What's your algorithm for adjusting the phase?
At one stage in the video it looked like the shift was different on the rising and falling edges.

Nick

 

[Burtie]

need any help? I am eagerly awaiting developments because i want to use this to optimize my own hall sensor positioning...

Thanks for the offer, I will give you a shout when I get stuck. I should have more time to work on it if/when it starts raining!

Dear Burtie , when we were testing Colossus mr. Chubichevic made a similiar device but with less adjustable settings... .. i will ask him to join discussion if he finds time

Thanks markobetti, that would be great!
Are there any details on the forum about mr. Chubichevics device already??

LFP wrote:
Burtie! This is awesome! Great work! It's amazing how sensitive the motors are to a little tiny bit of timing change isn't it? I thought I was going crazy when I was first setting mine up, and moving it a quarter of a mm would cause a few amps +- of no-load current. lol

LFP,
Thanks for the encouragement :wink:
Yup, these high pole count motors sure are damn fussy about any small error in the sensor positioning.

Hi Burtie,

What's your algorithm for adjusting the phase?
At one stage in the video it looked like the shift was different on the rising and falling edges.

Nick

Well spotted Nick. Yes the algorithm is still a slightly flawed one.
Plenty of work to do / fun to be had to get it right :?


I am beginning to think I will have to cut down the original feature set because the processing capacity of the PIC18 is too limited.
May start looking at the larger/faster families of PIC processors as a better platform for this project.

Burtie