TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

[Rydon]

I think now that lag is better we can totally kick it in the butt and reduce motor noise by applying a constant load on the motor while wheel speed is greater than zero. My friend says his Bafang is using 20w even with no assist !!

Why would that reduce motor noise and why would you want to use battery power when you don't need it? As for your friend's comment, I have extensive experience with Bafang mid-drives and have never seen what he observes. You could program any assist level to provide 20w but you would have to be pedaling to get it.

 

[jbalat]

I just want to do a test, I notice a lot of the whining noises from the motor come when there is little load on the motor, I have a feeling by applying a little load the gears would always stay engaged with a little pressure to prevent chattering .

Also this means the lag will be eliminated, if you stop pedalling at 30km/hr then start again the motor is already at the same speed so it doesn't have to start from zero which takes some time to catch up again.

It's pretty good now with the quicker ramp factor but it's worth testing out this theory to see if it can be better.

What do you think ?

 

[casainho]

I just want to do a test, I notice a lot of the whining noises from the motor come when there is little load on the motor, I have a feeling by applying a little load the gears would always stay engaged with a little pressure to prevent chattering .

Also this means the lag will be eliminated, if you stop pedalling at 30km/hr then start again the motor is already at the same speed so it doesn't have to start from zero which takes some time to catch up again.

It's pretty good now with the quicker ramp factor but it's worth testing out this theory to see if it can be better.

What do you think ?

Stop talking and do it!! -- I think there is almost no risk to damage your motor controller or motor if you implement the min amount of current. Just do it, test and report

 

[maximusdm]

I made the changes of 2 ADC units for torque. Also added min cadence assist ONLY in case of non boost mode. The logic is complex and I did not want to impact it.
I was not able to make a branch or a pull request(I get error at push)
@casainho can you please give me rights to be able to push a branch/ make a merge request so you are able to review my changes?

The minimum human power should work so long as it only applies while wheel speed > 0.. Will have a look Thanks !! Yes please let me know or just post the code here and I can cut and paste.

I attached the changed source code. You can make a compare with master branch to see the exact changes from eclipse. Let me know if you have any questions. I do not have time to test it until the weekend.

PS: I have updated to code to fix some problems. So use latest version. Keep in mind it is not tested!
PSS: I removed the code and I will provide a fork.

 

[jbalat]

Thanks maximus, run out of daylight just changed over my chain and rear cassette on the Norco tsdz, after 6000kms chain had stretched around 10mm
Long weekend after I get home from work tomorrow so lots of time for testing.

 

[maximusdm]

Glad that I could help a bit. It is very valuable to have proactive users who test changes. Thanks!

 

[AleZMaD]

First time here! My name is Alex and, first of all, thanks casainho for all the imaginable working hours he devoted to this project and Jbalat for all the videos which smooth the way of installing it.

I have some programming experience and I am learning to understand the way this code works. I made the step up change as Jbalat to get a faster response from the motor, although I share the same opinion to correct the lag from the code to not force the mechanisms. Minimum current theory, if it can be called so, seems to be plausible and I like it.

Just let you know I am available to share the efforts to make this even better. Code is well commented but create engineering work flow documentation could attract more developers. I will try to start with that.

First question, the temperature sensor calibration was lost after the step up change I made. It shows 0C when temperature is around 20, and when engine is working, the temperature starts going up from 0C.

 

[gaber]

https://en.wikipedia.org/wiki/Analog-to-digital_converter
https://en.wikipedia.org/wiki/EEPROM
https://en.wikipedia.org/wiki/Pulse-width_modulation

ERPS: electric revoltuino per second: https://en.wikipedia.org/wiki/Revolutions_per_minute

Thanks casainho! I did some more reading on PWM and it jogged my memory from what I am (slowly) learning via arduino. Fun to start connecting the dots to practical scenarios!

re: ERPS - could you (or anyone else) give a little further explanation within the context of this setting? I enjoy building a deeper understanding of all of this, and would like to expand on it in the wiki . Cheers!

 

[maximusdm]

Stop talking and do it!! -- I think there is almost no risk to damage your motor controller or motor if you implement the min amount of current. Just do it, test and report

Can you please take a look at the modifications?

 

[casainho]

I made the changes of 2 ADC units for torque. Also added min cadence assist ONLY in case of non boost mode. The logic is complex and I did not want to impact it.
I was not able to make a branch or a pull request(I get error at push)
@casainho can you please give me rights to be able to push a branch/ make a merge request so you are able to review my changes?

The minimum human power should work so long as it only applies while wheel speed > 0.. Will have a look Thanks !! Yes please let me know or just post the code here and I can cut and paste.

I attached the changed source code. You can make a compare with master branch to see the exact changes from eclipse. Let me know if you have any questions. I do not have time to test it until the weekend.

PS: I have updated to code to fix some problems. So use latest version. Keep in mind it is not tested!

Please make a pull request!! Look at goggle how to make it.

Please also describe your changes/the concept about the changes and only do 1 change/feature for each pull request!!

 

[EndlessCadence]

Stop talking and do it!! -- I think there is almost no risk to damage your motor controller or motor if you implement the min amount of current. Just do it, test and report

Can you please take a look at the modifications?

Hi maximuscdn, thanks for helping us! Your effort is appreciated. Please take a look at this guide for information about forking repositories, creating branches and pull requests. https://guides.github.com/activities/forking/

Basically you should first create your own fork, create a branch, commit your changes, thoroughly test and then create a pull request with a clear description of your modifications. Please keep in mind that the smaller the changes the easier it is to accept them. Always fix only one bug or add one feature per pull request.

Don't worry if this is too steep of a learning curve, I can always create a branch for you and add your code to it but then it won't be easy for you to improve any further.

Btw, I may have time soon to look at and test your code too :wink:

 

[Bartman]

unfortunately lag is still present in 14.3...
i hard to analyse since its so random...
most of the time it reacts fast, sometimes i needs 2 seconds before motor kicks in again.

From what I know 14.3 only has only high cadence enhancement for 36v on experimental mode. No lag fixes are there.

I think now that lag is better we can totally kick it in the butt and reduce motor noise by applying a constant load on the motor while wheel speed is greater than zero. My friend says his Bafang is using 20w even with no assist !!

I think we can have that if we have a miniman "human power" in the code. I did not have time to test it.
Now the cadence goes from 0-max_cadence. I plan to have a range of 25-max_cadence. This way you keep the motor permanently under small load and the assist at low cadence will be better.
@Jblat If you want to try the changes I can try to push my branch on git(if I have the right).

Yep there is no fix for lag just that setting you will need to change yourself from 75 to 25... see earlier posts.

Also just to make it clear, the bike will not be as efficient at a high cadence however if you find yourself in a situation where you need to peddle fast before you go up a big hill and don’t want to change down gears then this mod let’s you peddle as fast as you can.

The minimum human power should work so long as it only applies while wheel speed > 0.. Will have a look Thanks !! Yes please let me know or just post the code here and I can cut and paste.

I've had a look for the post to reduce the lag but can't seem to find it. Can you document the workaround in the wiki ?

 

[maximusdm]

Hi EC,
Thanks for your support. I have good experience with git and GitLab(paid version).
However Github is different. I tryed to make a branch on existing project and push it, but it does not work.
If fork is the way to go. I will make a fork and pull req from it.

Btw I really like the way you organized the dev process. Way better than just commiting in master.

 

[maximusdm]

Thanks maximus, run out of daylight just changed over my chain and rear cassette on the Norco tsdz, after 6000kms chain had stretched around 10mm
Long weekend after I get home from work tomorrow so lots of time for testing.

Pull request is here: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/pull/31
I still need to document it and after that I will ask for a code review.

 

[casainho]

Thanks maximus, run out of daylight just changed over my chain and rear cassette on the Norco tsdz, after 6000kms chain had stretched around 10mm
Long weekend after I get home from work tomorrow so lots of time for testing.

Pull request is here: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/pull/31
I still need to document it and after that I will ask for a code review.

That way is way simpler, I can use look at code changes on my phone, etc.

I already commented your changes, I think with a line of code should be enough -- I would implement in a different way you did.

 

[casainho]

re: ERPS - could you (or anyone else) give a little further explanation within the context of this setting? I enjoy building a deeper understanding of all of this, and would like to expand on it in the wiki . Cheers!

ERPS

Motor rotor has 16 magnets. Each pair makes 1 ERPS, so the rotor rotates at 8 ERPS if it rotates 1 RPS.

Hall sensor detects 1 ERPS, because each magnet pair has both north and south magnetic field (360 degrees).

 

[gaber]

re: ERPS - could you (or anyone else) give a little further explanation within the context of this setting? I enjoy building a deeper understanding of all of this, and would like to expand on it in the wiki . Cheers!

ERPS

Motor rotor has 16 magnets. Each pair makes 1 ERPS, so the rotor rotates at 8 ERPS if it rotates 1 RPS.

Hall sensor detects 1 ERPS, because each magnet pair has both north and south magnetic field (360 degrees).

I get it! Man, I am super grateful for the time and knowledge you (and the other contributors) are pouring into this. It’s allowing me to learn and get into this at a much deeper level. Thanks!

 

[maximusdm]

That way is way simpler, I can use look at code changes on my phone, etc.
I already commented your changes, I think with a line of code should be enough -- I would implement in a different way you did.

My idea was to achieve the "min adc units" proposal. I took it a bit further and also added min cadence units. If there is a minimal value then I could make the mapping function more abrupt resulting in a better motor response. I am using the map function to map a smaller interval to 0-255 basically obtaining a leverage effect.

Nevertheless i can also make a pull request with minimal current value since it is a one liner.

My proposal is that at least a few of us to test my idea. If my plan does not reflect in user's positive feedback, I can either make it better or just drop it. But for that I need your feedback and EC's on the design since I have no experience with electrical motors.

 

[casainho]

That way is way simpler, I can use look at code changes on my phone, etc.
I already commented your changes, I think with a line of code should be enough -- I would implement in a different way you did.

(...) If there is a minimal value then I could make the mapping function more abrupt resulting in a better motor response. I am using the map function to map a smaller interval to 0-255 basically obtaining a leverage effect.

Better motor response? We already know how to do it, I implemented to be like this:

// Choose PWM ramp up/down step (higher value will make the motor acceleration slower)
//
// For a 24V battery, 25 for ramp up seems ok. For an higher voltage battery, this values should be higher
#define PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP 75

And we can increase that value to have a lower response and save the gears, or do exactly the contrary.

Also about min cadence value, seems you don understand start power boost. Startup power boost was implemented so we get a fast/quick torque impulse at startup, but the amount of value depends on the pedal torque/force value the user does (it ignores cadence/constant cadence value). So, I think you are trying to duplicate already existing functionality. Maybe you should take time to understand how this feature work and configure fr your needs.

Nevertheless i can also make a pull request with minimal current value since it is a one liner.

Yes, please don mix different things.

 

[jbalat]

Happy to try both ideas guys

Casainho if we get the min current set up then that may also solve the lag issue leaving us to modify the inverse ramp as a simple way of startup boost ???

 

[AZUR]

Happy to try both ideas guys

Casainho if we get the min current set up then that may also solve the lag issue leaving us to modify the inverse ramp as a simple way of startup boost ???

Jbalat do you have the lag issue in the v0.3?

 

[casainho]

Happy to try both ideas guys

Casainho if we get the min current set up then that may also solve the lag issue leaving us to modify the inverse ramp as a simple way of startup boost ???

The inverse ramp should be used to save gears and have have, or not, a very fast response of the motor. I think the idea of keeping motor rotating at a min current current value will be better for gears than reducing the ramp steps. I think the first option is better for gears. For the feedback of users, the lag does not happen when startup, only when wheel is already rotating, so no need to reduce ramp steps.

 

[maximusdm]

Better motor response? We already know how to do it, I implemented to be like this:

// Choose PWM ramp up/down step (higher value will make the motor acceleration slower)
//
// For a 24V battery, 25 for ramp up seems ok. For an higher voltage battery, this values should be higher
#define PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP 75

And we can increase that value to have a lower response and save the gears, or do exactly the contrary.

Also about min cadence value, seems you don understand start power boost. Startup power boost was implemented so we get a fast/quick torque impulse at startup, but the amount of value depends on the pedal torque/force value the user does (it ignores cadence/constant cadence value). So, I think you are trying to duplicate already existing functionality. Maybe you should take time to understand how this feature work and configure fr your needs.

I do not know how PWM_DUTY_CYCLE_RAMP_UP works or does . Any explanation is welcome.

In my opinion BOOST != MIN_ASSIST.
Boost helps startup stationary or on the move.
What I done should help the user reach easier the assist power. It is a permanent assistance with a minimal value. It should be a bit easier to reach target assisted power.
I did not check the boost code yet, so I cant say I understand it or not. Of course an explanation of the logic would be helpful.

Regarding min_current vs min_assist I think there is no VS. I already did that and I think they should work better together. The current changes will be added to my proposal as well.

 

[casainho]

It is a permanent assistance with a minimal value. It should be a bit easier to reach target assisted power.

I did boost at first using a fixed amount of power but in the end it was awkward, because it was a fixed value, user had no control when start pedaling. Now boost depends on pedal force, boost is ignoring cadence at startup (because it is zero and is a problem) and having a specific configuration for pedal force ratio assistance + time duration of the boost phase (that also includes fade out/transition from boost power to regular power).

 

[jbalat]

For the feedback of users, the lag does not happen when startup, only when wheel is already rotating, so no need to reduce ramp steps.

Well that's what I mean, for startup there will be no lag despite the value of inverse ramp. If we use a big figure then it will take some extra time for the bike to reach speed and therefore the power will not overshoot (and better for the gears). If we use a small figure then there will be more acceleration to get to speed quicker but more power overshoot. I'm just saying that you can just replace the entire power boost logic/code by adjusting the inverse ramp and not have to worry about timing, complex logic, and what the user is doing.

Jbalat do you have the lag issue in the v0.3?

Yes it is there but it has not really bothered me since I just knew to expect it. Now that we understand it we can fix it. In fact the inverse ramp reduces it down so its negligible but I would rather use it for power ramp as mentioned above and use minimum current to fix the lag.