#$%@$#@ <--- (insert favorite swearword here), IT WORKS !!!!

[damcard]

I always wanted a half twist throttle that lets you not only twist back for acceleration, but forward for reverse/ variable regen. Just thought it would be cool. -Damcard.

[Alan B]

Nice progress.

My plan for a throttle/regen control is a full twist for throttle with a thumb variable regen both on the right hand side. The regen and rear brake are easily controlled simultaneously by the one hand that is no longer busy with the throttle. The other hand has a full job already handling the front brake.

[MitchJi]

Hi,

I always wanted a half twist throttle that lets you not only twist back for acceleration, but forward for reverse/variable regen. Just thought it would be cool. -Damcard.

Like the Vectrix?

[Lebowski]

Nieles just pointed me to a thread from Jeremy

http://endless-sphere.com/forums/viewto ... =2&t=23350

Reading through the datasheet of the NCP5181, I think I'll use this IC as the FET driver for
the controller for my own personal bike. Thanks Jeremy and Nieles for mentioning this driver IC

At the moment I use an optically isolated output stage but all the extra supplies this needs
are giving me a headache

[bigmoose]

If your future intent is high power, you might like to consider driver chips that have a separate source return pin (commonly labelel LO) that can be +- 5 relative to true ground.

Great results!

[Arlo1]

This is my first time using express shc but this is what I made for a powerstage with the IR2113 fet driver dave recomended. I should have it working soon.

[bigmoose]

edit: I missed a part in my original comment. Removed comment as it is not accurate. Sorry Arlo!

But I think I caught something new. Mind the data sheet, particularly page 3 and figure 12B and 13B. If you feed Vdd with 15 volts you will move the input logic levels up above the 5V range. You want to power Vdd with 5V and Vcc with 15.

[Alan B]

Why is the IR2113 "recommended"? Just like to understand the differences between the drivers better.

Thanks in advance,

[bigmoose]

Every designer has the products he is familiar with, and likes. A lot like the Ford/Chevy preferences of the old days. There are a couple of features I "like" about the IR2113, one is the shutdown pin. The second and more important is the separate LO return for driving the lower FET. This "extra" pin allows the LO to be within +-5 volts of GND or Vss pin of the driver without it going weird. This "extra" pin often saves a headache in layout, or gives you more wiggle room there when the bottom FET "ground bounces" and such.

Again, just my opinion. Others will see it differently, and will have successful designs. There are many "right" designs.

[Arlo1]

edit: I missed a part in my original comment. Removed comment as it is not accurate. Sorry Arlo!

But I think I caught something new. Mind the data sheet, particularly page 3 and figure 12B and 13B. If you feed Vdd with 15 volts you will move the input logic levels up above the 5V range. You want to power Vdd with 5V and Vcc with 15.

Thanks thats proly why it don't run yeat lol.

[MitchJi]

Hi,

How difficult would it be and how beneficial would it be to add the capability of accepting input from sin/cos sensors, in addition to hall sensors? Seems like a good match for this project because the sin/cos sensors work better at low speed:
http://endless-sphere.com/forums/viewtopic.php?f=28&t=34628&p=503866

Two nice things about the sin/cos sensor:

• It get the position sensing element out of the stator heat flux
• It allows precise timing advance with the right controller just like a timing map in an IC ECM

Yes sir it does. We did it mainly for the heat reason you mentioned, as hall melting failure was our demise at the last race event, as well as a previous race.

The second reason you mentioned wasn't really something we were needing for this application, but WOW! It just make it silky smooth, no more chug-chug-chug at low RPM's as each hall sensor latches and tells the fets to switch the next coil on, it's just silky now, you can make the motor spin so slowly you can barely see it moving at all, and it's just perfectly smooth with no torque ripple noticed at all now. Really feels like electric power should feel at all RPM's rather than little bumps of torque pulses when you're at low speeds.

It's fun having this much torque too, I just nosed the front wheel up to a staircase outside a strip mall, and in a very slow controlled calm way, just torqued up the 10 stairs or so and rode along the sidewalk path at the top. It felt even easier than walking up stairs, though the seat does kinda smash into your ass as the rear tire goes over each step. I don't know that it would have been possible to do it so effortlessly on hall sensors.

[Lebowski]

Hi,

How difficult would it be and how beneficial would it be to add the capability of accepting input from sin/cos sensors, in addition to hall sensors? Seems like a good match for this project because the sin/cos sensors work better at low speed:
http://endless-sphere.com/forums/viewtopic.php?f=28&t=34628&p=503866

I don't see any benefit in using sin/cos sensors.

- whatever position sensor system you use, it will always be as accurate as the person whole placed it.
- under load timing will always be wrong as timing depends on many things, only (hall-) sensorless can have perfect timing.
- I make the transition to sensorless around 60 to 120 e-rpm anyway.

And, not unimportant, I already used all the analog inputs (all 9 of 'm) I'm assuming its an analog-out sensor ?

[MitchJi]

Hi Lebowski,

How difficult would it be and how beneficial would it be to add the capability of accepting input from sin/cos sensors, in addition to hall sensors? Seems like a good match for this project because the sin/cos sensors work better at low speed:
http://endless-sphere.com/forums/viewtopic.php?f=28&t=34628&p=503866

I don't see any benefit in using sin/cos sensors.
- whatever position sensor system you use, it will always be as accurate as the person whole placed it.
- under load timing will always be wrong as timing depends on many things, only (hall-) sensorless can have perfect timing.
- I make the transition to sensorless around 60 to 120 e-rpm anyway.

I wasn't thinking of better accuracy. I was thinking of better low speed performance:

The second reason you mentioned wasn't really something we were needing for this application, but WOW! It just make it silky smooth, no more chug-chug-chug at low RPM's as each hall sensor latches and tells the fets to switch the next coil on, it's just silky now, you can make the motor spin so slowly you can barely see it moving at all, and it's just perfectly smooth with no torque ripple noticed at all now. Really feels like electric power should feel at all RPM's rather than little bumps of torque pulses when you're at low speeds.

It would be nice to have completely a perfectly smooth motor starting up, when its "spin[ing] so slowly you can barely see it moving at all" all the way up to perfect timing at WOT. I assume when Luke says "WOW!" about low speed performance it must be pretty nice, since its not an issue he is normally concerned with. So it seems like its potentially an excellent combination, great low speed and great high speed performance.

And, not unimportant, I already used all the analog inputs (all 9 of 'm) I'm assuming its an analog-out sensor?

It depends on which one you use. They are available with digital outputs (both of Todd's links have options with digital outputs):

I am pretty certain they grabbed an off the shelf rotary encoder for reading position. a quick google brings up several that could be employed with a little creativity:
http://www.quantumdev.com/products/optical_encoders/sc12.html
http://ab.rockwellautomation.com/Motion-Control/Sine-Cosine-Absolute-Encoder

Output Circuits
(A) Sine/Cosine, Index & RS422 UVW (TTL Compatible)
(B) Sine/Cosine, Index & UVW Open Collector

But I suspect I'm overlooking a potential problem, or that it will be more work to implement than its worth because if it was a good idea, and the benefits outweighed the work involved someone else would probably have jumped in to support the idea.

Thanks!

[Alan B]

The sin/cos encoder has the precision advantage (significantly more resolution than halls), and they escape the heat of the motor which will destroy the halls before other damage to the motor. They can be calibrated against the back EMF for best accuracy.

[Lebowski]

I looked at the links of the sensors, the difficulties I see are

- the sensor needs to be matched to the number of poles in the motor. One of them is available in 4,6 or 8 poles, I have
14 poles.
- how would you (mechanically) connect something like that in a hub motor ?
- since I switch to sensorless at a low rpm it would only offer a (questionable) advantage at startup

Maybe an interface for such a sensor would be a good idea when they come standard in the hubmotors 80% of us use but even
then, I feel for high power and difficult motors (any motor) sensorless is the only way...

[Alan B]

I'm trying to think of any of our high performance industrial BLDC motors that use sensorless (at work). I can't think of any. I think of all the folks who have tried sensorless on ES, and they always seem to have problems. Low RPM, high load, high RPM, high power, coasting, accelerating hard, decelerating quickly, regen, operating in field weakening mode or back EMF greater than supply voltage - they always have regions of difficulty where the sensorless becomes unsynchronized or produces less performance than hall sensors did. So for rock reliable never out of synch operation under the full range of conditions sensorless seems to fail.

On the other hand, we have exactly one example that I'm aware of on ES of sin/cos encoder operation - it is not compatible with a hubmotor (though Amber's wheelchair motor has it and it is sort of a hubmotor?), and as you point out finding an encoder to match the pole count is not always easy, though opticals can be set up for any pole count.

I suppose the Variable Frequency Drives could be said to be "sensorless", and they seem to work fine. I believe they look at current rather than voltage, so perhaps vector control works better than back EMF sensorless. They also model the motor and have the data for inductance and resistance and motor temperature so they can compensate more accurately for dynamics.

So thinking about this I agree with you - sin/cos encoders are probably not worthwhile to worry about at this point - but I also suspect that getting sensorless operation to be perfect seems to be more difficult than expected and I don't think we've seen any controllers yet that have succeeded. I wonder if Justin of ebikes.ca's sensorless operation is without problems... Burtie's timing advance unit seems to have difficulties as well, but he is working through them. Perhaps it only takes a couple of years of tweaking to get it right.

So what do you think - is your sensorless control algorithm having or going to have regions of difficulty?

[Lebowski]

So thinking about this I agree with you - sin/cos encoders are probably not worthwhile to worry about at this point - but I also suspect that getting sensorless operation to be perfect seems to be more difficult than expected and I don't think we've seen any controllers yet that have succeeded. I wonder if Justin of ebikes.ca's sensorless operation is without problems... Burtie's timing advance unit seems to have difficulties as well, but he is working through them. Perhaps it only takes a couple of years of tweaking to get it right.

So what do you think - is your sensorless control algorithm having or going to have regions of difficulty?

Interesting question where would my algorithm have difficulties. I'll keep thinking about this question
but at the moment there's only one significant (though unlikely) one I can think of. There may be trouble with
a high impedance motor (who wants that ?) running at a low speed where it produces very little back-emf

Another thing (also highly unlikely) is that the control loops (who's parameters are accessible and can be set over RS232
by the user, so lots of playing around room) lose it. If you manage to slow down / speed up the motor significantly
in a matter of milliseconds then the loops might lose lock, though... If the phase loop cannot keep up with accelleration
the timing will be off by such an extent that the motor cannot accelerate, an equilibrium will be found I imagine.

[markobetti]

[markobetti]

[markobetti]

It took me a while , sorry. iS THIS WHAT YOU WANTED FOR 306 BOARDS ? if you want pdf files , send me your mail adress
Sweet work , keep on man ..

[MitchJi]

Hi,

I looked at the links of the sensors, the difficulties I see are...

I feel for high power and difficult motors (any motor) sensorless is the only way...

Just to be clear I suggested the sensors to replace the Halls, not the sensorless.

So thinking about this I agree with you - sin/cos encoders are probably not worthwhile to worry about at this point - but I also suspect that getting sensorless operation to be perfect seems to be more difficult than expected and I don't think we've seen any controllers yet that have succeeded.

#1 If you are talking about a sensorless controller, good luck. MANY people have tried and it would be tough to improve on the Castle Creations controllers we are using for sensorless RC stuff. It is not impossible, but would cost a lot to do. Sensored is another thing altogether.

For motor control the Castle controllers work very well except for high power/low speed, particularly startup and the resulting amp surges. The reason they are so fragile in general is they are not designed or intended (not heavy duty enought) for ebike use. If Lebowski's unit works comparably well as the Castle for higher speeds, and is used in conjunction with sensors to solve the startup issues and is combined with heavier duty parts to address the Castle's fragility it would be an almost perfect solution.

I say almost because it would clearly be even a little better with sine/cosine sensors instead of halls . I'm sorry Lebowski, I couldn't resist.

[whatever]

what are the reasons for changing from halled to sensorless once the motor is running?

[parabellum]

what are the reasons for changing from halled to sensorless once the motor is running?

In this case hall sensors are the worst option for higher rpm. Lebowski is feeding the coils with kind of alternating current (AC) which makes smooth and efficient run and is timed by analog BEMF. Hals (we usually use) are kind of digital switches good for on/off position.

[Lebowski]

what are the reasons for changing from halled to sensorless once the motor is running?

What Parabellum said is part of the answer. It is virtually impossible to place hall sensors in the
correct location and to get the timing spot on. Plus there is much more than just the rotor position
determining the correct timing. You also need to take into account rotor speed, amount of power
being delivered, hell, the only thing timing does not depend on is the position of the sun and the moon

Sensorless is the only way to get the timing correct. I treat sensored operation as something you do
to get torque at 0 standstill and at very low rpm to dial in the sensorless control loop, once that's done
sensorless takes over.

Another thing about sensored... My 30F controller real-time outputs all kinds of loop parameters during motor
operation. I was shocked to see how un-even my motor was built, from the data I could exactly see which
magnets and coils were out of position. I expect the same to be true for commercial motors, maybe to
a lesser extent but still.. How are you going to place your hall sensors correctly when the magnets in
the motor are un-evenly spaced ?

[fechter]

I think even commercial motors (at least typical ebike motors) have significant position error in the hall sensors. I'm not sure how much this affects efficiency, but it can't be good.

It would be interesting to see how much improvement there is between a typical chinese controller and Lebowski's design under actual operation conditions.

By getting the timing exactly right, there could be a significant reduction in motor heating as it won't be fighting itself so much.