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

casainho said:
@EndlessCadence,

Yesterday I rode using V0.14.1 and I noted some issues:

1. Max power works but seems it is at wrong scale, I need to increase maybe 10x more to get a good value. Before this feature was working well so it was some change after.

2. EEPROM reset: for some reason, still fails. I don't know if it is the resetting process or the after process of writing the default values. Maybe one important thing was to have LCD3 show installed firmware version of motor and LCD so I could assure I have installed the correct versions.

3. Startup power fails a LOT when I enable boost. Again, It was not like that when I implemented this feature.

I will give a look at code to see if I can spot the reasons for this issues.


Same 1 and 3 problems for me with 0.14
if went back to 0.12 since i need the bike for commuting every day.
i am currently working on a complete rewrite off ebike_control_motor which should solve the lag issues and be more safe and better readable. (all throttle,cadence torque,brake,wheelspeed checks at the end before setting current to motor) so no more need to check this at any other place in the code (lags, safety problems...)

however only limited time at the moment for testing....
hope i have a tested an well running build at the weekend.

current version:
https://github.com/vscope/TSDZ2-Smart-EBike/blob/master/src/controller/ebike_app.c
 
casainho said:
I have an idea: on LCD3, set max pedal as being 1 or 0, maybe with zero it will work as if pedal cadence is at max value...

Cadence sensor is for sure equal/only one. What you can try is to take out the motor controller and verify if the connector of the sensor to the board is ok and mayne it is slightly removed.

Hi Casainho,
I tried your idea with the v14 setting (8,2) and set it to both 0 and then 1. No joy.

However, I took off the wheel magnet ;)
Now the controller doesn't know that I am moving, so it continues to help =)

So the combination of "Motor Assistance without pedal rotation" = Enabled, combined with NO speed sensor has worked around my broken cadence sensor.
Downsides: No speed reading, and if I push on the pedals while stationary the bike wants to go (need to be careful at traffic lights).

I will pull the motor apart in the following days to check for any lose wires.

Where is the cadence sensor? (EG: would I buy a replacement torque sensor or controller)
 
vscope said:
Same 1 and 3 problems for me with 0.14
if went back to 0.12 since i need the bike for commuting every day.
I think this is an incorrect conclusion.

To be honest I also do not agree with a lot of your changes like removing the compile switch for throttle/non-throttle versions. Yes, we want a separate version for non-throttle! I think I have to fork this project and continue on my own, I simply don't want to risk my and others' safety.

We should improve this firmware carefully and potentially slowly as well. Lots of testing involved. Quality over quantity :wink:
 
EndlessCadence said:
vscope said:
Same 1 and 3 problems for me with 0.14
if went back to 0.12 since i need the bike for commuting every day.
I think this is an incorrect conclusion.

To be honest I also do not agree with a lot of your changes like removing the compile switch for throttle/non-throttle versions. Yes, we want a separate version for non-throttle! I think I have to fork this project and continue on my own, I simply don't want to risk my and others' safety.
@vscope, you just arrived to the project. Since EndlessCadence arrived before you, did a great effort to organize the project and is actively maintaining/developing it, I think you should not make changes to the code and let EndlessCadence do it -- maybe the best way for you to participate is by using pull requests, that will force the code the be previous analyzed and accepted or not by EndlessCadence.
 
casainho said:
@EndlessCadence,

Yesterday I rode using V0.14.1 and I noted some issues:

1. Max power works but seems it is at wrong scale, I need to increase maybe 10x more to get a good value. Before this feature was working well so it was some change after.
The code seems ok for me and is not that complex. After I went to check using the debugger and I put the power variable at 100W and 500W and the various values were calculated correctly, up to the final step: ebike_app_set_target_adc_battery_max_current (ui8_adc_battery_target_current);

Hmmmm, what can be happen???
 
casainho said:
casainho said:
@EndlessCadence,

Yesterday I rode using V0.14.1 and I noted some issues:

1. Max power works but seems it is at wrong scale, I need to increase maybe 10x more to get a good value. Before this feature was working well so it was some change after.
The code seems ok for me and is not that complex. After I went to check using the debugger and I put the power variable at 100W and 500W and the various values were calculated correctly, up to the final step: ebike_app_set_target_adc_battery_max_current (ui8_adc_battery_target_current);

Hmmmm, what can be happen???
I noticed the same and am lost too :D What else can cause this issue?
 
casainho said:
casainho said:
@EndlessCadence,

Yesterday I rode using V0.14.1 and I noted some issues:

1. Max power works but seems it is at wrong scale, I need to increase maybe 10x more to get a good value. Before this feature was working well so it was some change after.
The code seems ok for me and is not that complex. After I went to check using the debugger and I put the power variable at 100W and 500W and the various values were calculated correctly, up to the final step: ebike_app_set_target_adc_battery_max_current (ui8_adc_battery_target_current);

Hmmmm, what can be happen???
I think the issue was about copy-paste :) -- on 2 different calculations, we store the different current values on the same variable: ui8_adc_max_battery_current :-(

Code:
  if (ui16_battery_voltage_filtered > 15)
  {
    // 1.6 = 1 / 0.625 (each adc step for current)
    // 25 * 1.6 = 40
    // 40 * 4 = 160
    if (configuration_variables.ui8_startup_motor_power_boost_div25 > 0)
    {
      ui32_adc_max_battery_current_boost_state_x4 = ...
    }

    if (configuration_variables.ui8_power_regular_state_div25 > 0)
    {
...
      ui8_adc_max_battery_current = ui32_adc_max_battery_current_regular_state_x4 >> 2;
    }

    if (configuration_variables.ui8_target_battery_max_power_div25 > 0) //TODO: add real feature toggle for max power feature
    {
...
      ui8_adc_max_battery_current = ui32_adc_max_battery_current_x4 >> 2;
    }
  }
 
Done, I went to test and it works as expected!! :)

EC, you were right that this error code were already on the other repo.

Here is the diff of the changes I did and tested:

Code:
diff --git a/src/controller/ebike_app.c b/src/controller/ebike_app.c
index f5b3a4a..3293608 100644
--- a/src/controller/ebike_app.c
+++ b/src/controller/ebike_app.c
@@ -143,6 +143,7 @@ static void ebike_control_motor (void)
   uint8_t ui8_tmp_pas_cadence_rpm;
   uint32_t ui32_adc_max_battery_current_x4;
   uint8_t ui8_adc_max_battery_current = 0;
+  uint8_t ui8_adc_max_battery_power_current = 0;
   uint8_t ui8_startup_enable;
   uint8_t ui8_boost_enabled_and_applied = 0;
   uint8_t ui8_tmp_max_speed;
@@ -174,7 +175,7 @@ static void ebike_control_motor (void)
     if (configuration_variables.ui8_target_battery_max_power_div25 > 0) //TODO: add real feature toggle for max power feature
     {
       ui32_adc_max_battery_current_x4 = (((uint32_t) configuration_variables.ui8_target_battery_max_power_div25) * 160) / ((uint32_t) ui16_battery_voltage_filtered);
-      ui8_adc_max_battery_current = ui32_adc_max_battery_current_x4 >> 2;
+      ui8_adc_max_battery_power_current = ui32_adc_max_battery_current_x4 >> 2;
     }
   }
 
@@ -246,7 +247,7 @@ static void ebike_control_motor (void)
         (!((ui8_boost_enabled_and_applied == 1) || (ui8_startup_boost_fade_enable == 1))))
     {
       // now let's limit the target battery current to battery max current (use min value of both)
-      ui8_adc_battery_target_current = ui8_min (ui8_adc_battery_target_current, ui8_adc_max_battery_current);
+      ui8_adc_battery_target_current = ui8_min (ui8_adc_battery_target_current, ui8_adc_max_battery_power_current);
     }
   }
 
casainho said:
Done, I went to test and it works as expected!! :)

EC, you were right that this error code were already on the other repo.

Here is the diff of the changes I did and tested:

Code:
diff --git a/src/controller/ebike_app.c b/src/controller/ebike_app.c
index f5b3a4a..3293608 100644
--- a/src/controller/ebike_app.c
+++ b/src/controller/ebike_app.c
@@ -143,6 +143,7 @@ static void ebike_control_motor (void)
   uint8_t ui8_tmp_pas_cadence_rpm;
   uint32_t ui32_adc_max_battery_current_x4;
   uint8_t ui8_adc_max_battery_current = 0;
+  uint8_t ui8_adc_max_battery_power_current = 0;
   uint8_t ui8_startup_enable;
   uint8_t ui8_boost_enabled_and_applied = 0;
   uint8_t ui8_tmp_max_speed;
@@ -174,7 +175,7 @@ static void ebike_control_motor (void)
     if (configuration_variables.ui8_target_battery_max_power_div25 > 0) //TODO: add real feature toggle for max power feature
     {
       ui32_adc_max_battery_current_x4 = (((uint32_t) configuration_variables.ui8_target_battery_max_power_div25) * 160) / ((uint32_t) ui16_battery_voltage_filtered);
-      ui8_adc_max_battery_current = ui32_adc_max_battery_current_x4 >> 2;
+      ui8_adc_max_battery_power_current = ui32_adc_max_battery_current_x4 >> 2;
     }
   }
 
@@ -246,7 +247,7 @@ static void ebike_control_motor (void)
         (!((ui8_boost_enabled_and_applied == 1) || (ui8_startup_boost_fade_enable == 1))))
     {
       // now let's limit the target battery current to battery max current (use min value of both)
-      ui8_adc_battery_target_current = ui8_min (ui8_adc_battery_target_current, ui8_adc_max_battery_current);
+      ui8_adc_battery_target_current = ui8_min (ui8_adc_battery_target_current, ui8_adc_max_battery_power_current);
     }
   }
Fantastic! :D Will you create a pull request or do you want me to do it?
This is the Github issue: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/13

Let's get this into the master branch and I'll release a new version.
 
Fantastic! :D Will you create a pull request or do you want me to do it?
This is the Github issue: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/13

Let's get this into the master branch and I'll release a new version.
[/quote]
I am a bit lost to where commit. To development branch? or a new branch for V0.14.2??

Well, for now. Do it you.
 
casainho said:
EndlessCadence said:
vscope said:
Same 1 and 3 problems for me with 0.14
if went back to 0.12 since i need the bike for commuting every day.
I think this is an incorrect conclusion.

To be honest I also do not agree with a lot of your changes like removing the compile switch for throttle/non-throttle versions. Yes, we want a separate version for non-throttle! I think I have to fork this project and continue on my own, I simply don't want to risk my and others' safety.
@vscope, you just arrived to the project. Since EndlessCadence arrived before you, did a great effort to organize the project and is actively maintaining/developing it, I think you should not make changes to the code and let EndlessCadence do it -- maybe the best way for you to participate is by using pull requests, that will force the code the be previous analyzed and accepted or not by EndlessCadence.

No problem for me. @EndlessCadence just copy from my fork if you think something in the changes is worth it. ( i am not angry if you dont and do all the work by your own) If you need some help. Just send me a message.
One thing i want to clarify. My changes are for safety reasons not the opposite since the current state of the software is not very safe.
one = instead of an == and the bike will go crazy...
with the ebike_motor_run as an fundamental safety instance before setting motor current its much more safe.

cheers
 
casainho said:
EndlessCadence said:
Fantastic! :D Will you create a pull request or do you want me to do it?
This is the Github issue: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/13

Let's get this into the master branch and I'll release a new version.
I am a bit lost to where commit. To development branch? or a new branch for V0.14.2??

Well, for now. Do it you.
I create a branch for every bugfix or feature and the create a pull request to master (for bugs) or development (for large features or refactoring of code).
 
vscope said:
No problem for me. @EndlessCadence just copy from my fork if you think something in the changes is worth it. ( i am not angry if you dont and do all the work by your own) If you need some help. Just send me a message.
One thing i want to clarify. My changes are for safety reasons not the opposite...
I think pull requests also makes the things more manageable, because there are a lot of things going on but there is 1 human that must check the code first. That human needs time, the pull requests will force discussion and also give time for that human other way to many changes from different sources...........
 
vscope said:
casainho said:
EndlessCadence said:
vscope said:
Same 1 and 3 problems for me with 0.14
if went back to 0.12 since i need the bike for commuting every day.
I think this is an incorrect conclusion.

To be honest I also do not agree with a lot of your changes like removing the compile switch for throttle/non-throttle versions. Yes, we want a separate version for non-throttle! I think I have to fork this project and continue on my own, I simply don't want to risk my and others' safety.
@vscope, you just arrived to the project. Since EndlessCadence arrived before you, did a great effort to organize the project and is actively maintaining/developing it, I think you should not make changes to the code and let EndlessCadence do it -- maybe the best way for you to participate is by using pull requests, that will force the code the be previous analyzed and accepted or not by EndlessCadence.

No problem for me. @EndlessCadence just copy from my fork if you think something in the changes is worth it. ( i am not angry if you dont and do all the work by your own) If you need some help. Just send me a message.
One thing i want to clarify. My changes are for safety reasons not the opposite...

cheers
Hi vscope, as I've said before (and by PM :wink: ) I appreciate your effort but we should do this step by step. Not so easy to explain for me but I definitely want collaboration but without the frustation of constantly breaking functionality and potential safety issues!

I have the following suggestion:
- Try to fix this issue first: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/9 Without any restructuring of the code.
- Maybe help fixing the issue with boost.
- Do your restructuring, carefully test!
- Create a pull request (PR) to a specific branch (not master, I will create a new branch for this)
- We will discuss the code in the PR.
- Complete the PR and get the changes in the specific branch.
- We will arrange a beta test version for other users (and ourselves).
- When users are (still) happy and this is a real improvement, we'll merge to master and release a new final version! :D

Rule of thumb: never mix bugfixes with lots of other changes (refactoring/restructuring or features). Keep your changes as specific and small as possible this makes it way easier to understand and accept them! Feel free to ask any questions.

Just my two cents :wink:

So please don't stop here, we'll make this a success!

casainho said:
I think pull requests also makes the things more manageable, because there are a lot of things going on but there is 1 human that must check the code first. That human needs time, the pull requests will force discussion and also give time for that human other way to many changes from different sources...........
Exactly!
 
i started fixing https://github.com/OpenSource-EBike-fir ... e/issues/9 after 0.14 came out but then i realized that the main problem is not this piece of code but the whole ebike_control_motor is a mess. checking brake values in the middle of ebike_control_motor or setting torque values to 0 in the middle of other functions .... this is not clever and potentially risky. thats why i wanted to create a clean version with fundamental safety checks at the end before setting current. this fundamental safety features wont need to be changed with new features added which makes adding features more safe and easier to test. one thing led to another and at the end a lot of things got changed :) its hard to stop in the middle of such a task... at the end the code is much better in my eyes and would be a good restart. i understand that this would be a big change but fixing bugs cause the code is really bad (caused by adding lots of features in the development phase without restructuring) doesnt make sense to me. global values where not needed ... different naming of vars...

i would make a big cut. clean up the mess have a nice stable release with good safety and then add features...
at the moment adding features is only adding possible bugs in different places...
 
It is very difficult for me that I do not speak English to understand where this software is going. too many changes, bugs, versions, etc.
Is it possible to make an excel sheet where in the various columns are indicated the characteristics with the indication if the feature is working, not working, in process?
 
andrea_104kg said:
It is very difficult for me that I do not speak English to understand where this software is going. too many changes, bugs, versions, etc.
Is it possible to make an excel sheet where in the various columns are indicated the characteristics with the indication if the feature is working, not working, in process?
Just use the Github project page I would say. You can find everything there: the wiki with a description of the features and configuration, known issues, open bugs, wish list and the latest releases including their release notes. Please see my signature below.

And:
  • When programming always use the latest version (unless it's a beta)
  • When you have no issues or must have features there is no reason to upgrade
  • When a new version is released, most of the time you can find an in-depth discussion in this forum but on Github you can find the issue with description and the pull request with the actual changes
 
EndlessCadence said:
:!:

@everyone, v0.14.2 has been released which includes a fix for the max power issue. This fix was made and tested by casainho : )

Looking forward to getting this functionality back guys. Also it would be great to get the multipliers back, setting 5000w to get some descent assist is really crazy

Can I ask you include a “High cadence” option in the next release
 
jbalat said:
EndlessCadence said:
:!:

@everyone, v0.14.2 has been released which includes a fix for the max power issue. This fix was made and tested by casainho : )

Looking forward to getting this functionality back guys. Also it would be great to get the multipliers back, setting 5000w to get some descent assist is really crazy
Have fun :D Regarding the assistance multiplier issue, this remains to be discussed. I also prefer this but I don't want to bypass casainho in this regard because I highly value his ideas.

Can I ask you include a “High cadence” option in the next release
Yes, no problem!
 
EndlessCadence said:
jbalat said:
EndlessCadence said:
:!:

@everyone, v0.14.2 has been released which includes a fix for the max power issue. This fix was made and tested by casainho : )

Looking forward to getting this functionality back guys. Also it would be great to get the multipliers back, setting 5000w to get some descent assist is really crazy
Have fun :D Regarding the assistance multiplier issue, this remains to be discussed. I also prefer this but I don't want to bypass casainho in this regard because I highly value his ideas.
I think we should instead invest to make the multiplier to be of pedal human power.

Maybe I should do it while EC takes care of the walk assist mode ;)
 
And an Issue wich can kill your controller -

-and all whats needed is to forget to switch off. (Wich I did, and it cooked mine because of a failing switch on my old battery).

And so it happened: I leaned the bike against a tree, pressed the switch on the battery and left for two hours. After I came back, bike was dead.

And now what really happend: The battery switch did no 'click' and the bike was still on. The torque sensor can be fooled by leaning the bike against a tree. Or having some Weight of your bike lock on it. As I tested today, Display showed 90 Watt pumping into the blocked motor. For two hours (not in the test, of course). Probably all the time with the same mosfet. Wich than burned. Wich than short circuit the Battery. Wich than set bike and tree on fire.
Just kidding. The BMS saved battery, bike and the wood.

Only weeks ago, I had no torque sensor and I was not used to this. And maybe I just should have done a better configuring of the auto switch off. How does it work: Depending on measuring speed at 0 for some minutes? Or can a torque value above some zero or changing torque values prevent auto switch off?

If so, we really need some safety measures here: Faster auto switch off with no motor turns, despite of Watt usage above... 20 Watt or something like that for instance? Or could have a configured switch off save me from that?
 
Eremit said:
And an Issue wich can kill your controller -

-and all whats needed is to forget to switch off. (Wich I did, and it cooked mine because of a failing switch on my old battery).

And so it happened: I leaned the bike against a tree, pressed the switch on the battery and left for two hours. After I came back, bike was dead.

And now what really happend: The battery switch did no 'click' and the bike was still on. The torque sensor can be fooled by leaning the bike against a tree. Or having some Weight of your bike lock on it. As I tested today, Display showed 90 Watt pumping into the blocked motor. For two hours (not in the test, of course). Probably all the time with the same mosfet. Wich than burned. Wich than short circuit the Battery. Wich than set bike and tree on fire.
Just kidding. The BMS saved battery, bike and the wood.

Only weeks ago, I had no torque sensor and I was not used to this. And maybe I just should have done a better configuring of the auto switch off. How does it work: Depending on measuring speed at 0 for some minutes? Or can a torque value above some zero or changing torque values prevent auto switch off?

If so, we really need some safety measures here: Faster auto switch off with no motor turns, despite of Watt usage above... 20 Watt or something like that for instance? Or could have a configured switch off save me from that?
Sorry for the dead controller (but you've written it in a funny way), but if you'd used the default setting for "Motor assistance startup without pedal rotation" (configuration menu 8.1) you, the bike, battery and tree would be fine and without rotating pedals there should be no watts pumping at all :p

Wiki: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Usage-and-configuration-of-firmware-version-0.14.x
 
Eremit said:
If so, we really need some safety measures here: Faster auto switch off with no motor turns, despite of Watt usage above... 20 Watt or something like that for instance? Or could have a configured switch off save me from that?
Sorry for what happened.

That's true, there is no such protection. On KT motor controllers firmware I did implement that, like if after 3 seconds of having duty-cycle/energy to the motor, if the bicycle wheel speed < min speed value, then the motor energy is turned off until torque sensor AND throttle are zero.

I didn't bring that code/protection from the other firmware to simplify when I started the project and then, guess what :)
 
[/quote]
Sorry for the dead controller (but you've written it in a funny way), but if you'd used the default setting for "Motor assistance startup without pedal rotation" (configuration menu 8.1) you, the bike, battery and tree would be fine and without rotating pedals there should be no watts pumping at all :p

Wiki: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Usage-and-configuration-of-firmware-version-0.14.x
[/quote]

I like the fast start and so 8.1 must be on. I'll care a little more for the switch off next time and...
 
Back
Top