System is LCD3, T09s and AKM128.

It works very well but with this oddity:

When going down hill (over 20mph) I have to turn the assist off. If I don't then assist will not kick back in until speed gets down to below 12mph. This is not consistant which is very annoying, sometimes it'll be 5 or 6mph or not at all, so I have to turn the power off then on again. If I don't pedal (over 15mph) then, mostly, power will kick back in OK. Using brake switch between 15 and around 20mph will usually allow power to come back in if brake switch is released at around 15 or below.

As I live in a very hilly area this is pain in the butt that means I'm looking at the display and altering settings way more than I want to be.

 

I've tried various P and C settings (I'll list current set below) but haven't found a way to circumvent this oddity.

So my question is, is it likely to be the controller or the display that's causing the bug? I'm thinking of replacing because it's really awkward the way it is.

P1=168

P2=1

P3=1

P4=1

P5=13

C1=07

C2=0

C3=8

C4=1

C5=09

C6=3

C7=0

C8=0

C9=0

C10=n

C11=0

C12=4

C13=0

C14=3 going to reset to 2

 

So to sum up, I can't pedal over cut off speed with assist on or assist will not come back in a timely or consistant manner.

System is LCD3, T09s and AKM128.

It works very well but with this oddity:

When going down hill (over 20mph) I have to turn the assist off. If I don't then assist will not kick back in until speed gets down to below 12mph. This is not consistant which is very annoying, sometimes it'll be 5 or 6mph or not at all, so I have to turn the power off then on again. If I don't pedal (over 15mph) then, mostly, power will kick back in OK. Using brake switch between 15 and around 20mph will usually allow power to come back in if brake switch is released at around 15 or below.

As I live in a very hilly area this is pain in the butt that means I'm looking at the display and altering settings way more than I want to be.

 

I've tried various P and C settings (I'll list current set below) but haven't found a way to circumvent this oddity.

So my question is, is it likely to be the controller or the display that's causing the bug? I'm thinking of replacing because it's really awkward the way it is.

P1=168

P2=1

P3=1

P4=1

P5=13

C1=07

C2=0

C3=8

C4=1

C5=09

C6=3

C7=0

C8=0

C9=0

C10=n

C11=0

C12=4

C13=0

C14=3 going to reset to 2

 

So to sum up, I can't pedal over cut off speed with assist on or assist will not come back in a timely or consistant manner.

I explained it all before. It's sort of not the controller, it's the motor. When you understand what's going on, you can figure out how to deal with it.

 

The KT controller always uses the motor speed for the cut-off, not the bike speed. It gets the motor speed from the hall sensors. That means that when you're pedalling downhill, the motor speed will be maintained at an RPM equivalent to the cut-off speed. The wheel will be turning at some speed above that. The problem is that the clutch won't engage in that scenario until you do something to make the motor slow down to a suitable engagement speed.

 

There are two ways to solve that. Firstly, you can pause pedalling for long enough to let the motor slow down to engagement speed, whatever that is. Probably about 2 seconds is enough as you reduce speed past the cut-off speed, then you can start pedalling again. You have to let the motor reduce its speed to below the bike's speed.

 

The second way, if you don't want to pause pedalling is to use a power cut method. You can do it by pulling the brake lever enough to actuate the cut-off but not the brake while you're pedalling above the speed limit, otherwise a horn button wired in parallel with a brake switch. Like with pausing pedalling, you only need to cut-off the motor for a couple of seconds while you transition past the cut-off speed in the slowing down direction, just long enough to let the motor slow down enough for clutch engagement.

 

In summary, except when the brake cut-off is in operation, all the time you're pedalling, the motor will be trying to maintain an rpm equivalent to the cut off speed. The clutch will only engage when the motor speed is less than the bike speed. The clutch engagement is the same on any geared motor, but the KT controller is different to the others by keeping the motor spinning whenever you're pedalling, while as other controllers use the bike speed for the cut-off. so won't spin the motor when over the cut-off speed unless you don't have a separate speed sensor.

Before one does any more, with the P1 value try 224.

Edited September 30, 2025Sep 30 by Nealh

Thanks Saneagle, I will further try with the brake and no pedal. However I found these to both be unreliable so far. They both seem to work so long as mph doesn't go above approximately 20. To be clear, this is using brake switch when rolling above cut off and not letting go until 15mph or below OR not pedalling until below cutoff. As stated this works so long as speed doesn't go above around 20mph which doesn't make any sense to me. However I'll try to be more exacting.

Turning assist off completely works every time.

Problem is I'm spending too much time looking at the display and fiddling with buttons when I need to be watching traffic and road conditions.

Another question then, where does the system derive mph registration from ? I had thought this was a function of the hall sensors, or is there a 2nd set for this?

Thanks Neal, why 224?

Thanks Saneagle, I will further try with the brake and no pedal. However I found these to both be unreliable so far. They both seem to work so long as mph doesn't go above approximately 20. To be clear, this is using brake switch when rolling above cut off and not letting go until 15mph or below OR not pedalling until below cutoff. As stated this works so long as speed doesn't go above around 20mph which doesn't make any sense to me. However I'll try to be more exacting.

Turning assist off completely works every time.

Problem is I'm spending too much time looking at the display and fiddling with buttons when I need to be watching traffic and road conditions.

Another question then, where does the system derive mph registration from ? I had thought this was a function of the hall sensors, or is there a 2nd set for this?

Thanks Neal, why 224?

Let's say that you're going to pedal down and up a U-shaped valley. You can pedal all the time as hard as you want all the time. when you get to the bottom of the hill, your speed will still be above the cut-off, but as you start to go up the other side, it'll start slowing down. That's probably the best time to start fethering the brake, while you continue to pedal. As soon as the speed goes below the cut-off (say 15 mph), you can let go of the brake and the motor will engage and help you up the hill immediately. After you've done it a few times, you'll recognise what 15 mph is like, so you won't need to look at anything. There are no buttons to press. just pull the brake lever enough to operate the switch.

 

One thing to watch out for is that if you adjust P1, it changes the cut-off speed, so always confirm with a phone that your LCD is showing the right speed, and confirm that the cut-off speed is 15.5 mph or whatever you want. You can adjust the cut-off speed to match the LCD with P1.

I never thought to switch off the controller to see what happens. Good experiment. I don't think you will find a way around it that doesn't involve faffing around during a ride other than removing the speed limit.

 

I solved it by changing to a different type of controller but my particular solution isn't for everyone.

I never thought to switch off the controller to see what happens. Good experiment. I don't think you will find a way around it that doesn't involve faffing around during a ride other than removing the speed limit.

 

I solved it by changing to a different type of controller but my particular solution isn't for everyone.

Many forum members, including myself, have done tens of thousands of miles with KT controllers and never experienced that issue. There must be something different in the way we pedal.

So turning the motor off above assistance speed limit seems to solve the problem.

 

A question: is there any difference in behaviour using an external speed sensor Vs the motor's internal speed sensor?

 

A possible workaround:

 

Use an external speed sensor to measure speed and an additional brake cutout switch to automate the turning off of the motor. A very simple Arduino or similar controller doing the clever bit.

So turning the motor off above assistance speed limit seems to solve the problem.

 

A question: is there any difference in behaviour using an external speed sensor Vs the motor's internal speed sensor?

 

A possible workaround:

 

Use an external speed sensor to measure speed and an additional brake cutout switch to automate the turning off of the motor. A very simple Arduino or similar controller doing the clever bit.

When you don't have any speed sensor, external or internal, the controller will default to using the hall sensors to display the speed. Nothing will change in the way it handles the cut-off. The only difference is that the motor speed is displayed on the LCD, calculated from the hall sensor pulses, P1 setting and wheel size. If you stop pedalling, you'll see it reduce to zero, regardless of bike speed.

 

As you can see, none of this would be an issue with a direct drive motor. It's simply that the clutch won't engage easily on some motors when the motor speed is maintained at a high speed by powering it. It must be a centrifugal effect. I have the same motor and controller as Benjamin, but I never experienced that problem. Maybe I ride differently or maybe it's different grease in my motor.

I've never seen a Brazilian tree frog. It doesn't mean they don't exist.

If you remember I did attempt an experiment with a different controller to prove your theory. Unfortunately I was unable to recreate the behaviour. I'm willing to concede that the time I spent on it wasn't enough to draw any conclusions.

When you don't have any speed sensor, external or internal, the controller will default to using the hall sensors to display the speed. Nothing will change in the way it handles the cut-off. The only difference is that the motor speed is displayed on the LCD, calculated from the hall sensor pulses, P1 setting and wheel size. If you stop pedalling, you'll see it reduce to zero, regardless of bike speed.

 

As you can see, none of this would be an issue with a direct drive motor. It's simply that the clutch won't engage easily on some motors when the motor speed is maintained at a high speed by powering it. It must be a centrifugal effect. I have the same motor and controller as Benjamin, but I never experienced that problem. Maybe I ride differently or maybe it's different grease in my motor.

One strange thing I came across lately. It was a xf07 geared motor that needed a bearing replacement but worked ok. When I had the motor opened, I checked the clutch and the three nylon planetary gears and they looked ok. However, when I spun the shaft I noticed that the gears were sticking and the motor was turning with the gear assembly.

With these, the motor normally turns in the opposite direction and 4.4 times faster . When freewheeling (without power), the motor I would imagine normally stops and the planetary gears spin somewhat slower than the hub. However, with this hub, the whole planetary assembly along with the motor pinion was spinning, so with this hub, when freewheeling (without power), the motor would be spinning slowly in the forward direction, which is the actual reverse of what it normally is spinning.

Anyhow, a clean up of the gears with a tooth pic fixed the problem, which was caused by little bits of nylon debris embedded between some of the teeth of the gears.

 

The reason I bring up this issue is that the controller must have some way of dealing with this possibility, i.e. The motor may be spinning slightly in the opposite direction to what it normally does after freewheeling if say there is any friction/drag on the gears, so it may have to do a sort of resync or restart to get going again.

Use an external speed sensor to measure speed and an additional brake cutout switch to automate the turning off of the motor.

I did buy an external sensor with the motor, I tried to use it but couldn't get the magnet and sensor head close enough together to give a signal. Don't think I got any further than that.

 

When I first fitted this kit I was using a 48v 328rpm AKM 128 but running it at 36v to give the rpm I needed. This gave me all sorts of problems (overheating, P1 setting difficulties etc.)so I ended up buying the current motor. The problem I'm having now did turn up at the time though, amongst all the other stuff, it didn't get mentioned. I am wondering if the various thermal cutouts and general mis-match of the previous motor have caused some damage in the controller.

 

Got to pick my van up from the garage later so may get another chance to try methodologies mentioned above.

One strange thing I came across lately. It was a xf07 geared motor that needed a bearing replacement but worked ok. When I had the motor opened, I checked the clutch and the three nylon planetary gears and they looked ok. However, when I spun the shaft I noticed that the gears were sticking and the motor was turning with the gear assembly.

With these, the motor normally turns in the opposite direction and 4.4 times faster . When freewheeling (without power), the motor I would imagine normally stops and the planetary gears spin somewhat slower than the hub. However, with this hub, the whole planetary assembly along with the motor pinion was spinning, so with this hub, when freewheeling (without power), the motor would be spinning slowly in the forward direction, which is the actual reverse of what it normally is spinning.

Anyhow, a clean up of the gears with a tooth pic fixed the problem, which was caused by little bits of nylon debris embedded between some of the teeth of the gears.

 

The reason I bring up this issue is that the controller must have some way of dealing with this possibility, i.e. The motor may be spinning slightly in the opposite direction to what it normally does after freewheeling if say there is any friction/drag on the gears, so it may have to do a sort of resync or restart to get going again.

AKM motors have the clutch between the hub and the gears. It's different to a typical Bafang or MXUS motor, which have the clutch between the motor and gears. Basically AKMs disengage everything from the hub so that there's no drag at all from the motor or gears. The behaviour that Benjamins experiencing would only come from an AKM motor.

So the clutch is running at a much lower rpm in an AKM. Is the clutch mechanism the same as other motor types?

 

Does the engagement rely entirely on centrifugal force, or is there any spring loading involved?

 

Do the clutch 'bits' stay in contact with the driven surface when disengaged if the motor is still running, and perhaps not if it is stopped?

So the clutch is running at a much lower rpm in an AKM. Is the clutch mechanism the same as other motor types?

 

Does the engagement rely entirely on centrifugal force, or is there any spring loading involved?

 

Do the clutch 'bits' stay in contact with the driven surface when disengaged if the motor is still running, and perhaps not if it is stopped?

The clutch inner is attached to the hub and runs at hub speed. The clutch outer is attached to the final ring gear, which spins at the same speed as the hub would if it were engaged.

 

Putting that in numbers, for a legal bike that goes between zero and 30 mph with a 26" wheel, the clutch inner would spin at between zero and 201 rpm, and the clutch outer would spin at between zero and 201 rpm. It would disengage at 201 rpm when the bike is above 15 mph, and it would continue to spin at 201 rpm all the time the rider is pedalling at 15 mph or above.

 

The problem is that when the rider is decelerating from above 201 rpm with the clutch disengaged and the clutch inner is rotating at 201 rpm, it doesn't re-engage when the clutch outer is spinning at less than 201 rpm.

 

I posted a picture of the clutch at the bottom of post #1 here See if you can figure out why it won't engage. My brain has just got stewed trying to picture it:

https://endless-sphere.com/sphere/threads/q100-and-q100c-internals.61966/

When the clutch is straight after the motor, it is going many times faster, 201 x reduction ratio. The centrifugal forces will be correspondingly higher. That might make a difference.

 

The clutch bits in your ES pics are full of grease. That, and the low relative speed when hoping for reengagement at 201 rpm might make a difference.

 

Does the behaviour change if an experiment is carried out with no grease in those cutouts where the rollers live?

 

The rollers might be sliding and rotating instead of gripping because the speeds and forces are not in their expected range. If they start to do so, like an aquaplaning tyre, a substantial power reduction is needed to re-establish grip.

 

Are there standard design parameters for this style of clutch?

Further to previous post, I am interpreting the three tapered slots and the rollers therein as being the 'grippy' elements of the clutch. Say if I've got that wrong.

 

If so, there are only three points of drive, unlike a true sprag clutch that has many of them all round the circumference.

 

In which case this is an engineering compromise of a clutch, and given the unique behaviour of the KT controller in keeping the motor spinning, between them they create the conditions for the observed behaviour.

And how to solve the problem:

 

I'd build the Arduino circuit I mentioned earlier, to prevent the KT controller keeping the motor running.

 

Other ideas:

 

1. Change the amount and type of grease in the clutch. Minimum amount. Lowest viscosity. Might work, worth a try.

2. Impractical, but might solve the problem mechanically: remachine the clutch ramps to a smaller wedge angle. Should grip more strongly.

3. Dump the KT controller.

4. Dump the AKM motor.

Likewise I have never suffered the same issues with my KT S09S or AKM128cst.

I suggested using 224 as a higher P1 value as it will/ should alter the cut off top speed of the motor, one then can try it to see if the pick up speed lag still occurs.

Though TBK list the IG of the 201rpm as 10:5 it may be incorrect, so up the P1 and test to see if once above 20mph if the motor will pick up better once one slows.

Streuth ! Thanks guys, must admit I'm totally lost here.

Never having had one of these motors in pieces, and not being familiar with geared hubs and their construction/operation, I can't really follow. What seems to be being said is that the motor is doing what it's meant to.

If that's the case then this system isn't going to work for me 'cos being caught at the bottom of a vee valley with no power and facing a 1:8 (or greater) climb is no fun. If I get the procedure wrong then I can find myself stuck on the begginings of the climb, stopped, in the wrong gear having to turn the power of then on again. So coming down the hill in top gear, very quickly losing momentum at the bottom, not able to pedal to change gear above 15mph or turn the power on until 15mph or below. A lot happening in a very short time.

Neal, I did try higher P1 settings during the set up period, I think 224 may have been one of them. Problem with it is that speed display is then out of whack with gps and the whole point of doing this kit was to get a legal cut of speed in case of officer pullage.

Matthew, what's an arduino and what the hell would one do with it? The motor gives me good torque for the hills I have to climb, so I'd be more inclined to swap the controller if I could get a simply working system that allowed me to just ride the bike.

 

I have considered swapping to speed control (which I'm used to from my Ezee days) to see if this helps at all.

Streuth ! Thanks guys, must admit I'm totally lost here.

Never having had one of these motors in pieces, and not being familiar with geared hubs and their construction/operation, I can't really follow. What seems to be being said is that the motor is doing what it's meant to.

If that's the case then this system isn't going to work for me 'cos being caught at the bottom of a vee valley with no power and facing a 1:8 (or greater) climb is no fun. If I get the procedure wrong then I can find myself stuck on the begginings of the climb, stopped, in the wrong gear having to turn the power of then on again. So coming down the hill in top gear, very quickly losing momentum at the bottom, not able to pedal to change gear above 15mph or turn the power on until 15mph or below. A lot happening in a very short time.

Neal, I did try higher P1 settings during the set up period, I think 224 may have been one of them. Problem with it is that speed display is then out of whack with gps and the whole point of doing this kit was to get a legal cut of speed in case of officer pullage.

Matthew, what's an arduino and what the hell would one do with it? The motor gives me good torque for the hills I have to climb, so I'd be more inclined to swap the controller if I could get a simply working system that allowed me to just ride the bike.

 

I have considered swapping to speed control (which I'm used to from my Ezee days) to see if this helps at all.

Speed control won't help, neither will any settings. To silve it, you have to do what i said, which is pretty easy and doesn't affect your pedalling or anything like that.

An Arduino is a tiny microcontroller chip mounted on a PCB with lots of accessible hardware pins, and straightforward programming language support. A more up to date equivalent is the Raspberry Pi Pico.

 

No use unless you have someone who can make one do what is needed, but for such a person, can easily do clever control and/or data gathering tasks. Kids of the right age and interest are a useful resource! And the kit is very cheap.

 

Two uses for this approach here: 1. To see exactly what the clutch is doing. 2. To modify the behaviour of the KT controller.

 

My theory, which is not proven so may be wrong, is that the clutch is not engaging straight away when your speed comes back down from quite fast to cut-in speed. I think the clutch parts are skating on grease because the engagement force is too low to force them through it. They engage eventually at a much lower wheel speed because the increasing difference in speed between clutch inner and outer creates conditions that allow it.

 

To see what's happening needs the rpm of clutch inner and outer to be made visible, and their values over time to be plotted. The speed sensor output and any one of the motor hall sensor inputs give this information, and an Arduino or Pico can sense the pulses and with a little bit of programming, convert them into rpm numbers. The motor gearing and speed sensor pulses per rev need to be applied to the raw pulse data.

 

The plotting can be done by sending data to a phone or laptop and using suitable software there, or by accumulating data on a Pico for download after the test ride. Arduino boards don't have the memory for that bit.

 

My theory predicts that from the moment your speed exceeds cut-off speed until the moment of reengagement, the motor speed remains at full cut-off speed of about 201rpm, and the wheel speed rises to its maximum down the hill, and then falls back through cut-in speed and keeps on falling until engagement takes place. At that moment, there is a rapid reduction in motor speed as the clutch grips.

 

Something like this:

 

 

That's the diagnosis use of the clever kids toy. The only awkward bit is accessing the motor hall sensor signal. Bringing the wire out from a short extender lead is one way to solve that.

 

To override the KT 'motor always on' behaviour only needs one input, the wheel or motor speed sensor, and it needs to present an output that looks like an extra brake cut-out switch. The programming just monitors bike speed, and whenever that is above cut-off speed it activates the brake cut-out and turns the motor off. Dead simple.

 

This is what those microcontroller boards look like:

 

 

I was on my bike today that's basically the same as Benjamin's. I stopped pedalling occasionally while both above and below the cut-off. I could hear and feel that the power to the motor was cut-off instantly, and it took about 1 second for the motor to slow right down with the clutch disengaged. I reckon that all Benjamin needs to do, is just pause the pedals for about half a second as soon as the bike speed is below 15 mph and his problem will be completely resolved.

To clarify that, stopping pedalling stops PAS signal so motor stops, whereas continuing to pedal above cut-off speed with the KT controller keeps the motor running at full cut-off speed. With other controllers, motor cuts off at cut-off speed, irrespective of PAS.

 

That's the basis of my earlier posts, and works with your last. Is that right?