Thank you for taking the time for the detailed explanation.

 

To summarise. The behaviour is down to a combination of two things. The particular motor installed on my bike and the way in which the KT controller determines the speed cut off using the hall sensors. As the modified Lishui uses the motor speed sensor for cut off it nullifies this behaviour.

 

Real world experiment. I could modify the code so that the speed limit is activated by the hall sensors and the display information only comes from the speed sensor and then run for a couple of days and see what happens. Problem is that the code is designed to operate from either the speed sensor or the hall sensors. Start to combine the code and there is a good chance of introducing an error or two needing correcting.

 

So here's what I propose. I will switch the firmware over to run speed measurement from the hall sensors. I will also install an external cycle computer to accurately measure the wheel speed. The behaviour you have explained should occur on the uphill as no other components of the build have changed. Is this acceptable?

That's right. Your test should confirm if it's correct. Thanks for doing it. I still have the Speedict somewhere, but the software has long gone in an old phone. If I can find anything to download, I'll do some specific test with it. That old chart was to monitor what happened with the 2-speed drive.

Incidentally, I was just riding my folding bike with KT controller down a hill. It doesn't have a speed sensor, so it picks up the speed signal from the halls. Each time I pedalled, the speed indicated exactly 15 mph, and when I stopped pedalling, it went to zero. This is pretty obvious really.

I've had a cycle computer on for a few runs and had the controller speed measured by the hall sensors and I just can't replicate the behaviour. I'm not going to say Saneagle is wrong because it may be how the controller works.

 

When you hit the speed limit the display doesn't drop to zero, it freezes at 25km/h (which has given me another off tangent idea but maybe more on that later). Also when you stop pedaling it stops on the previous speed and slowly decelerates on the display. Pedalling again brings some accuracy to the speed.

 

It is of course possible that the controller is feathering power around cut off speed which would probably affect the behaviour. I don't think that I will be able to prove it conclusively one way or the other.

 

Using the hall sensors as speed measurement makes the ride awful. I suppose all the smoothing that I added is now redundant.

 

What have we learnt from this? Controllers that regulate cut off from the speed sensor are better (unless the speed sensor fails I suppose).

I've had a cycle computer on for a few runs and had the controller speed measured by the hall sensors and I just can't replicate the behaviour. I'm not going to say Saneagle is wrong because it may be how the controller works.

 

When you hit the speed limit the display doesn't drop to zero, it freezes at 25km/h (which has given me another off tangent idea but maybe more on that later). Also when you stop pedaling it stops on the previous speed and slowly decelerates on the display. Pedalling again brings some accuracy to the speed.

 

It is of course possible that the controller is feathering power around cut off speed which would probably affect the behaviour. I don't think that I will be able to prove it conclusively one way or the other.

 

Using the hall sensors as speed measurement makes the ride awful. I suppose all the smoothing that I added is now redundant.

 

What have we learnt from this? Controllers that regulate cut off from the speed sensor are better (unless the speed sensor fails I suppose).

Are you talking about your Lishui controller? When using the halls as the speed sensor on any bike, it's obvious that the motor will maintain 15 mph as long as you pedal when the bike speed is above that. When you stop pedalling, there is some friction that tries to keep the motor turning, which is why it takes a couple of seconds to slow down. All motors and control systems are the same in that respect. It's just that you don't see it when your speed display is based on a speed sensor. On the bike I'm presently testing, I can see that on the LCD, but you would otherwise never know.

If you get your speed from the Hall sensors, it can't show the correct speed beyond the set speed limit because the rotor won't spin faster than the set speed limit. When the bike travels faster than set speed limit, the clutch inside the motor disengaged, that explains why your lcd shows the speed limit.

To have the correct speed display, the LCD must get the signal from a separate speed sensor, which is most often installed inside the motor housing and its magnet glued to the motor cover. The same notor cable carries also the speed signal. That simplifies the wiring.

If you get your speed from the Hall sensors, it can't show the correct speed beyond the set speed limit because the rotor won't spin faster than the set speed limit. When the bike travels faster than set speed limit, the clutch inside the motor disengaged, that explains why your lcd shows the speed limit.

To have the correct speed display, the LCD must get the signal from a separate speed sensor, which is most often installed inside the motor housing and its magnet glued to the motor cover. The same notor cable carries also the speed signal. That simplifies the wiring.

That's how KT controllers work, but like many others, they will get the speed from a hall sensor if you don't have a motor with internal speed sensor or an external speed sensor.

 

That's made me think! What does a Lishui controller do regarding the 15 mph cut-off if it loses the speed signal? It's quite common for a motor's internal speed sensor magnet to fall off. I seem to remember from the days before motors had internal speed sensors, people twisting the wheel magnet away from the sensor to bi-pass the 15 mph limit. Does a Lishui controller still allow power when the display is always showing zero speed? I think it does, so that would be a way of getting past any software locks, except that the power will shutdown after the sleep timer trips, so you'd have to keep switching on every 10 minutes.

That's made me think! What does a Lishui controller do regarding the 15 mph cut-off if it loses the speed signal?

Lishui controllers use external speed signal.

Lishui controllers use external speed signal.

The one in the Yose kits doesn't. It only has 4 connectors: motor, battery, 1 to 5 and PAS. 1 to 5 has LCD, throttle, light, L brake and R brake.

The one in the Yose kits doesn't. It only has 4 connectors: motor, battery, 1 to 5 and PAS. 1 to 5 has LCD, throttle, light, L brake and R brake.

The 9pin motor cable has speed signal on the white wire, it goes to a data pin on the processor.

The speed is then encoded and sent to the LCD.

Currently with the modified Lishui if the speed signal is lost it happily outputs maximum power until reaches the motors maximum speed. There is of course no indication on the display.

 

As the display freezes at around 25km/h when measured from the hall sensors I have now incorporated that into the stealth mode settings. Not only does the LCD3 display only show up to 250W it now doesn't show the speed above 25kmph. Very useful for the wheel off the floor test.

 

Now most of the code is there if I can think of suitable triggers I will incorporate an emergency back up speed limit from the halls should the speed sensor fail.

Currently with the modified Lishui if the speed signal is lost it happily outputs maximum power until reaches the motors maximum speed. There is of course no indication on the display.

 

As the display freezes at around 25km/h when measured from the hall sensors I have now incorporated that into the stealth mode settings. Not only does the LCD3 display only show up to 250W it now doesn't show the speed above 25kmph. Very useful for the wheel off the floor test.

 

Now most of the code is there if I can think of suitable triggers I will incorporate an emergency back up speed limit from the halls should the speed sensor fail.

You're going to be a very popular guy, but not with everyone.

The 9pin motor cable has speed signal on the white wire, it goes to a data pin on the processor.

The speed is then encoded and sent to the LCD.

Internal speed sensor then, not external. External is wheel-magnet type or GPS.

Internal speed sensor then, not external. External is wheel-magnet type or GPS.

It's a bit of a terminology thing. The firmware classes an internal speed sensor as the halls and an external sensor as any other. Even though the speed sensor might be the 'white wire' type sensor fitted in the motor this is classed as external as well, even though it is physically internal.

 

Clear? Thought not. Clear as mud. Took me a bit to get my head around it and caused a few mishaps when programming.

It's a bit of a terminology thing.

Should have said separate speed sensor.

Haven't posted on here in a while and thought I'd do a bit of an update.

Everything running that well that I can't remember the last time I altered the software, probably over six months ago. Very pleased with it. Used as a daily commute.

I completed several bits of tinkering to make a smoother ride but never got around to updating it on GitHub. The code on there is probably 4 or 5 versions behind. I will try to remember to upload the latest version if for no other reason that it will give me a remote backup.

Can you pleaseput a link here to your project on github?

39 minutes ago, Woosh said:

Can you pleaseput a link here to your project on github?

I thought it was on here somewhere but just in case it isn't:

https://github.com/SparksandBangs/SparksandBangs_EBiCS_Firmware

Edited Thursday at 11:492 days by Sparksandbangs
Make link clickable.

Thank you