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

Hi Buba,

Just installed the 0.20.0 alfa2 and it went smooth.

I noticed that start riding is even much better than before.
What is for me not so clear is if 2: "Power Assist" 3: "Torque Assist" 4: "Cadence Assist" can all be set together. I assume that only one can be set and that in combination with 5: "eMTB Assist" that is eg the 10th level.

I tried the 10:2 Weight on pedal and to have my correct weight , I needed to addapt 10:1 Pedal torque conversion factor from 67 to 150. When done that I realy needed to reduce seriously the Assist levels.
Just did 1 km but it felt very good. Tomorow I'll do some 40km's and keep you informed.

Very nice job :bigthumb:
 
Hi Buba,

0.20.0 Alpha 2. Installed on two bikes without issue. Both were on 0.19.0 release before and the reset worked perfectly.

I have tested the power assist and cadence assist so far and both work great. I can confirm if you enable power,torque or cadence assist the other two will become disabled. Which is great very quick and easy to switch between them.

On the Trike I tested cadence assist more and I had to increase the multiplyers significantly to get the full benefits. Lowest of 80 highest 200 seams to give a good spread of assist levels. This does indeed feel almost exactly like a bafang wheel motor now. Unlike a bafang middrive that generally is limited to a fixed cadence at each assist level.

Perfect!

Looking forward to my disabled rider testing this.

Also had a quick play with emtb mode which felt very interesting on a hilly track.

Will do some more testing this week., But so far big congratulations for an awesome Alpha!
 
MathiasP said:
buba said:
MathiasP said:
1. What is the difference between Alpha 1 and Alpha 2?
2. Is there any 850C software that works with 0.20.0?

1. One bug that has been with us for a long time has left us in Alpha 2. Completely redesigned EEPROM-controller. So when installing the Alpha 2 everything should load properly and without any problem. If there is a problem for any reason it is possible to do a simple "reset to defaults" and it will immediately do it. There is also some slight optimization on the new cadence sensor code.

I always recommend the latest Alpha!

Which I suspected. :)
Fantastic work you and casainho put into this project.

We appreciate it! :) Hope you will get to enjoy all the news, changes and improvements!
 
bwb said:
Hi Buba,

Just installed the 0.20.0 alfa2 and it went smooth.

Hi Bwb! Glad to hear! That is one of the things I like to get feedback from right now as it is very important to know how the user installed the 0.20.0 and if it installed properly! I hope that it powered up with the default settings from the very first start!



bwb said:
I noticed that start riding is even much better than before.

:bigthumb: Hopefully one of many things that are much better!



bwb said:
What is for me not so clear is if 2: "Power Assist" 3: "Torque Assist" 4: "Cadence Assist" can all be set together. I assume that only one can be set and that in combination with 5: "eMTB Assist" that is eg the 10th level.

Yes, you need to choose between Power, Torque or Cadence Assist. If you enable one all the others are disabled. But eMTB can be combined. You are totally correct!



bwb said:
I tried the 10:2 Weight on pedal and to have my correct weight , I needed to addapt 10:1 Pedal torque conversion factor from 67 to 150. When done that I realy needed to reduce seriously the Assist levels.
Just did 1 km but it felt very good. Tomorow I'll do some 40km's and keep you informed.

Very nice job :bigthumb:

Thank you, Bwb! Looking forward to hear more! :bigthumb:
 
perryscope said:
Hi Buba,

0.20.0 Alpha 2. Installed on two bikes without issue. Both were on 0.19.0 release before and the reset worked perfectly.

Hi Perryscope. I am very happy that the installation went well and that you are testing the Alpha 2! Please let me know if you had to manually reset or if there were any other problems! Otherwise, great!



perryscope said:
I have tested the power assist and cadence assist so far and both work great. I can confirm if you enable power, torque or cadence assist the other two will become disabled. Which is great very quick and easy to switch between them.

On the Trike I tested cadence assist more and I had to increase the multiplyers significantly to get the full benefits. Lowest of 80 highest 200 seams to give a good spread of assist levels. This does indeed feel almost exactly like a bafang wheel motor now. Unlike a bafang middrive that generally is limited to a fixed cadence at each assist level.

Perfect!

Looking forward to my disabled rider testing this.

Also had a quick play with emtb mode which felt very interesting on a hilly track.

That sounds wonderful! As time goes on I hope we get to have more discussions regarding the riding modes and how to improve them even more.



perryscope said:
Will do some more testing this week., But so far big congratulations for an awesome Alpha!

Means a lot! Really looking forward to hear your impressions. And of course the impressions of the disabled rider. I want to make this truly enjoyable for everyone.
 
buba said:
Hi Perryscope. First of all, I am very happy that the installation went well and that you are testing the Alpha 2! Please let me know if you had to manually reset or if you had any other problems!

No Manual reset required, just flashed the ihx file on the Motor and Display over the top of a fully setup 0.19.0 release , powered up and it appeared to have done a factory reset. my existing 0.19.0 settings were not there ( which was expected ) I manually ran through the settings under menu 0 and 1 and tested in Power assist mode first and all worked as expected, then enabled each assist mode one after another and quickly tested they worked.

All very straight forward and easy to navigate. I will hopefully get some riding in over the next few days to really test it and feed back.
 
perryscope said:
buba said:
Hi Perryscope. First of all, I am very happy that the installation went well and that you are testing the Alpha 2! Please let me know if you had to manually reset or if you had any other problems!

No Manual reset required, just flashed the ihx file on the Motor and Display over the top of a fully setup 0.19.0 release , powered up and it appeared to have done a factory reset. my existing 0.19.0 settings were not there ( which was expected ) I manually ran through the settings under menu 0 and 1 and tested in Power assist mode first and all worked as expected, then enabled each assist mode one after another and quickly tested they worked.

All very straight forward and easy to navigate. I will hopefully get some riding in over the next few days to really test it and feed back.

Thank you for confirming that it worked like one would expect and taking the time to explain it all! That gives me further confirmation that we have complete control over the EEPROM.

:bigthumb:
 
The video tutorial of the Cadence Sensor Automatic Calibration:

[youtube]m05rFrDUGHg[/youtube]

Did not want to give verbal instructions similar to my previous videos as it is better with text points so users can pause and follow the step by step instructions. Sorry for the poor video editing and quality. Better than nothing.

There is a possibility that I will improve this when the stable 0.20.0 is out but maybe it is enough with a well written text tutorial and some pictures? Will update the wiki and of course make a text tutorial when time allows.

Let me know if this looks too complicated and not worth it.

Some benefits are:

- Much faster motor engage and disengage
- More responsive system, reacts with less pedal rotation
- Better for Coaster Brake versions that need fast reaction times (Need to validate the Alpha 2 on the new coaster brake motor I have so will improve code until it is perfect)
- Faster shifts
- Safer

Can and will be tuned even more in the coming Alpha versions as it is only around 70 percent tuned now.

Even when we add the assistance without pedal rotation there is a way to use the benefits of the Cadence Sensor Advanced Mode (!!!) as it reacts faster than just using the torque sensor.

-----------------------------

Just want to say that I will continually improve everything I can with the 0.20.0 so this is not the final Alpha by any means. It will only get better.
 
Anyone know the pinout between a bafang 1-to-4 cable (3pin brake sensor) and the female 8 pin higo cable?

I'm trying to solder a female connector on the 1-to-4 cable so that I can connect it to the TSDZ2 without modifying the TSDZ2 cabling.

Also how should I wire up the KT-LCD3? I'm going to solder a female connector directly to the PCB of the display.

I'm looking at a picture of the bafang pinout, the only one I can't figure out is PL. Is that equal to Vin (red) TSDZ2 wire?
 
Cheers Buba. I've only done a quick test ride in Power, Torque, Cadence and eMTB modes to see what they are like The Bike now goes like a rocket so I'm going to have to dial everything down especially eMTB which would probably take me up Everest :wink:

Just a few questions

Thanks for cadence calibration video very useful indeed. Cadence mode mode for me feels strange certainly different to my BBSHD pedal away in low gearing up a slope and not much assist then change up a few gears and the assist really ramps up high which seems counter intuitive. What is the thinking or logic behind that? I need to play around wiith this one though as I'm only getting assist in the upper levels anyway.

What percentage of motor acceleration would you recommend for a 52v battery 48 v motor? Obviously the 50% I have set is far too much.

Throttle still behaves as an on off switch but suspect you know that.

'Weight on the pedal' Left and right are different is it best just to set it so they are as equal as possible above and below the true weight?


As I say it was just a very quick test by me and I'm really looking forward to fine tuning everything in the coming day(s)

Absolutely no problems programming the display and motor or going through the menus, great work indeed, thank you.
 
buba said:
The last 24 hours I have worked like a mad man to take care of the EEPROM bug and get the Alpha 2 out. I tested, changed and modified well over 1000 lines of code to get it to work perfectly. Works great for me and I can only hope it will work great for the community.

Hi Buba,
as for the eeprom bug, I looked at the eeprom.c code and the problem is that the write operation is not performed correctly.
For this device, the FLASH_ProgramByte call, does not wait the end of write operation, but return the control to the program immediately. For this reason, the program must check that the previous operation is ended before to start a new write operation.
This is done checking a EOP flag into an hardware register.
Below a correct example:

for (i=0;i<NUM;) ) {
FLASH_ProgramByte(addr+i, buffer[i++]);
while (FLASH_GetFlagStatus(FLASH_IAPSR_EOP) == RESET) {}
}

The write operation, according to the technical data sheet of the device, requires about 6ms and, if you write a lot of data, the operation could take a long time and this could be a problem if done e.g. in the main loop of the controller.
It is possible to reduce the programming time by a factor of 4 using Word programming (32 bits) instead of Byte programming as in the firmware code.
Below another example:

uint32_t ui32_tmp;
for(i=0;i<NUM;) {
ui32_tmp= (uint32_t)buffer[i++] | ((uint32_t)buffer[i++] <<8) | ((uint32_t)buffer[i++] <<16) | ((uint32_t)buffer[i++] <<24);
FLASH_ProgramWord(addr+i-4, ui32_tmp);
while (FLASH_GetFlagStatus(FLASH_IAPSR_EOP) == RESET) {}
}

Hope this will help.
 
Rafe said:
Cheers Buba. I've only done a quick test ride in Power, Torque, Cadence and eMTB modes to see what they are like The Bike now goes like a rocket so I'm going to have to dial everything down especially eMTB which would probably take me up Everest :wink:

Thanks for cadence calibration video very useful indeed.

Rafe, haha! I guess it is better to have to dial it down than wishing for more :wink:

No problem at all just hope the video is clear enough!



Rafe said:
Cadence mode mode for me feels strange certainly different to my BBSHD pedal away in low gearing up a slope and not much assist then change up a few gears and the assist really ramps up high which seems counter intuitive. What is the thinking or logic behind that? I need to play around wiith this one though as I'm only getting assist in the upper levels anyway.

Hmm, yes I think the default values need some adjusting. But it is difficult as it all depends on motor type and battery voltage really. But they could definitely be better configured from start. Try adjusting the assist levels and see if you come closer to the BBSHD experience.

Later on, if you would like to share your particular values we can compare those to the values of other users and find a correlation.



Rafe said:
What percentage of motor acceleration would you recommend for a 52v battery 48 v motor? Obviously the 50% I have set is far too much.

Try setting a value between 20 - 28 %. If that feels nice I will put that recommendation in the wiki and could then make recommendations for all other setups.



Rafe said:
Throttle still behaves as an on off switch but suspect you know that.

Did not know that! Same thing on the 0.19.0? Have seen conflicting reports stating that it does work and others that it is like a switch. I have the temperature sensor so have never even tested the throttle on the open source firmware.

Would you mind looking at the Technical Data, 11:1?
1. Does it scale appropriately?
2. Are you seeing around 127 when giving half throttle?
3. Is it really sensitive and goes 0 to 255 with basically minimal input?
4. What is the maximum value on 11:0 when giving full throttle?
6. What is the resting value on 11:0, no throttle applied?
7. What is the resting value on 11:1, no throttle applied?

I could rewrite the throttle code. Expanding the range of operation and enable users to have finer throttle control if that is something desirable.



Rafe said:
'Weight on the pedal' Left and right are different is it best just to set it so they are as equal as possible above and below the true weight?

That is only important for the Power Assist riding mode and for the human power calculation. I would advice to select an average between the two as it will average out when riding the bike. That would at least be how I would solve the discrepancy between left and right pedal.

(Maybe adjust it so you get slightly less assistance on the dominant, stronger, leg so you have to push slightly more on the other leg. This very small difference can over time equalize your both legs. :D But this is more of a fun thing I thought of while replying and there is a possibility that the difference will be negligible when all things considered.)



Rafe said:
As I say it was just a very quick test by me and I'm really looking forward to fine tuning everything in the coming day(s)

Absolutely no problems programming the display and motor or going through the menus, great work indeed, thank you.

Thank you for posting and sharing! Appreciate it very much and look forward to hearing more impressions!

Cheers!
 
mspider65 said:
Hi Buba,
as for the eeprom bug, I looked at the eeprom.c code and the problem is that the write operation is not performed correctly.
For this device, the FLASH_ProgramByte call, does not wait the end of write operation, but return the control to the program immediately. For this reason, the program must check that the previous operation is ended before to start a new write operation.
This is done checking a EOP flag into an hardware register.
Below a correct example:

for (i=0;i<NUM;) ) {
FLASH_ProgramByte(addr+i, buffer[i++]);
while (FLASH_GetFlagStatus(FLASH_IAPSR_EOP) == RESET) {}
}

The write operation, according to the technical data sheet of the device, requires about 6ms and, if you write a lot of data, the operation could take a long time and this could be a problem if done e.g. in the main loop of the controller.
It is possible to reduce the programming time by a factor of 4 using Word programming (32 bits) instead of Byte programming as in the firmware code.
Below another example:

uint32_t ui32_tmp;
for(i=0;i<NUM;) {
ui32_tmp= (uint32_t)buffer[i++] | ((uint32_t)buffer[i++] <<8) | ((uint32_t)buffer[i++] <<16) | ((uint32_t)buffer[i++] <<24);
FLASH_ProgramWord(addr+i-4, ui32_tmp);
while (FLASH_GetFlagStatus(FLASH_IAPSR_EOP) == RESET) {}
}

Hope this will help.

Hello mspider65 ,

I want to start off by thanking you for going through the effort of checking the code, investigating and writing a post to help me. This is one of the many reasons I enjoy this community and have great respect for everyone here! Thank you!

I just want to mention for future reference that the EOP flag is not something you need to poll on our type of microcontrollers (low density, ST). The write operation is stalling the CPU so it can not do anything else until the operation is completed.

We had another problem that was a bit tricky to define. But it is actually solved and implemented in the 0.20.0 Alpha 2. Please take a look at my branch if you wish to see how I have implemented an EEPROM controller (valid/key data byte last in write). And please give feedback if you see any room for improvement!

It is only implemented on the display side as there is no reason, for now, to have it working on the motor controller.

https://github.com/leon927/TSDZ2-Smart-EBike/blob/testing-pwm-acc/src/display/KT-LCD3/eeprom.c
 
buba said:
I just want to mention for future reference that the EOP flag is not something you need to poll on our type of microcontrollers (low density, ST). The write operation is stalling the CPU so it can not do anything else until the operation is completed.

Hello Buba,
I don't want to sound insistent, and maybe I'm wrong or i'm missing something, but according to the ST documentation the STM8S105XX is a medium density device and has RWW capability. (Write is not blocking).
RWW.jpg
 
mspider65 said:
buba said:
I just want to mention for future reference that the EOP flag is not something you need to poll on our type of microcontrollers (low density, ST). The write operation is stalling the CPU so it can not do anything else until the operation is completed.

Hello Buba,
I don't want to sound insistent, and maybe I'm wrong or i'm missing something, but according to the ST documentation the STM8S105XX is a medium density device and has RWW capability. (Write is not blocking).
RWW.jpg

Hi Mspider65,

You are not insistent and I do not want you to feel that way. It is my fault for not looking at the classifications with greater care. You are correct! It seems they class it as a medium density device and not a low density one.

The write is blocking when executed in the main program memory. But we are writing to the data memory where it is possible to read it while writing, of course. But the thing is we are constantly checking and not going forward until it is correct:

1. Write
2. Read if Write is correct
3. If Write not correct, rewrite

But as we are to continue writing to data memory we should use the EOP as it can not hurt to wait first.

Will change this thanks to you! Nice job!

I also think you hinted at maybe using word programming and while I was rewriting the EEPROM code I should have maybe gone all the way and done that. But wanted to get the Alpha 2 out as quickly as possible and did not want to add possible bugs when I was working with solving a very strange bug.

But word programming would be possible to implement on the controller as we are starting from scratch. Do you have any further thoughts? Please give feedback where improvements can be made and thank you again for helping me!
 
I'm not sure if this is a bug, but I installed 0.19.0 and I have no power going to the motor.

Looking at menu 9, I can see that both PAS and torque is changing with pressure/pedal movement, but human power stays at 0.

I'm guessing it won't supply any power to the motor as long as human power = 0, as any multiplier is still 0.

Is this a bug, or did I just configure something wrong?
 
cnrd said:
I'm not sure if this is a bug, but I installed 0.19.0 and I have no power going to the motor.

Looking at menu 9, I can see that both PAS and torque is changing with pressure/pedal movement, but human power stays at 0.

I'm guessing it won't supply any power to the motor as long as human power = 0, as any multiplier is still 0.

Is this a bug, or did I just configure something wrong?

Could you reset everything and see if that helps?

------------------------

Step 1: Go to the Configuration Menu

Step 2: Go to the "Reset to factory defaults" under General Setup

Step 3: Increment the number until the screen is blank/turns off

Step 4: When the screen is blank/off, hold the ONOFF button for a couple of seconds. This is important!

Step 5: Release the ONOFF button

Step 6: Power on the system and it will hopefully be set to default settings

------------------------

If this does not help we will try other things but as you freshly installed it it is good to reset to default settings. I think it will help!

EDIT: After a reset it is of course necessary to follow the advice from Thineight:

thineight said:
Hello, I suggest you to scroll all the configuration parameters to make sure everything is set as intended.
That is a good habit when you change the "major" version of the software.
The thing you describe looks a typical "0" on some power setting.
Cheers
 
cnrd said:
I'm not sure if this is a bug, but I installed 0.19.0 and I have no power going to the motor.

Looking at menu 9, I can see that both PAS and torque is changing with pressure/pedal movement, but human power stays at 0.

I'm guessing it won't supply any power to the motor as long as human power = 0, as any multiplier is still 0.

Is this a bug, or did I just configure something wrong?

Hello, I suggest you to scroll all the configuration parameters to make sure everything is set as intended.
That is a good habit when you change the "major" version of the software.
The thing you describe looks a typical "0" on some power setting.
Cheers
 
buba said:
But this would be possible to implement on the controller as we are starting from scratch. Do you have any further thoughts? Please give feedback where improvements can be made and thank you again for helping me!

Hi Buba,
glad to be helpful.
And Yes, I have another thoughts :)
Would it be possible to store all the configuration data on the controller side instead of on the LCD side?
This could open up to new scenarios like running the bike without LCD.
And also will simplify my project ... :)
I'm working on an small Arduino module to put between Controller and LCD. This will offer the possibility of running the Open Source firmware also with different LCDs like the OEM VLCD5 or other (the Arduino module can perform all the translations between the LCD protocol and the Open Source Protocol) and use an app on a smartphone to setup the controller parameters via a Bluetooth connection to the Arduino module.
The app will also have a dashboard with all the "real time" controller data (Power, Torque, etc.). In the future the app may also be able to update the controller firmware via the Arduino module using the built-in STM8 booltloader or a custom bootloader.
 
Buba, I was wondering the difference between the 0.20 Power and Torque mode..
In my mind the Power mode uses mainly the torque and cadence sensors with a proper force_vs_torque_units calibration to allow correct human power calculation and, in turn, the motor power in accordance with the set multipliers.
The Torque mode provides, i presume, the motor power in accordance with the multipliers without the need a proper calibration.

Conceptually both the modes use the same "logic" behind, am I correct?
Do you keep them as separate setup to keep a clean display output, i.e. power mode --> human watts are displayed, torque mode --> human watts are not displayed?

I will try to understand the automatic calibration mode because I do not understand how it deals with the non linearity of the force_vs_torque_units related to the rest value / "knee" / full weight.
Did I miss the explanation from previous posts?

Thanks
 
mspider65 said:
Hi Buba,
glad to be helpful.

You have been very kind and helpful, mspider65! :)



mspider65 said:
buba said:
But this would be possible to implement on the controller as we are starting from scratch. Do you have any further thoughts? Please give feedback where improvements can be made and thank you again for helping me!

Yes, I have another thoughts :)
Would it be possible to store all the configuration data on the controller side instead of on the LCD side?
This could open up to new scenarios like running the bike without LCD.
And also will simplify my project ... :)
I'm working on an Arduino module to put between Controller and LCD. This will offer the possibility of running the Open Source firmware also with different LCDs like the OEM VLCD5 or other (the Arduino module can perform all the translations between the LCD protocol and the Open Source Protocol) and use an app on a smartphone to perform the configuration via a Bluetooth connection to the Arduino module.

It is very much possible to store all configuration data on the controller and have it work standalone:

buba said:
Will later update the EEPROM code on the motor controller so it works as well. That will make it possible to use the TSDZ2 without display. Actually, it would also be possible to configure the settings with the display connected and then just remove it when satisfied with the settings.

But I think you should constantly send data to the motor controller from your module. This is similar to a dead man's switch in a way as we are constantly confirming the actions you wish the controller should do. If for any reason communication is lost the TSDZ2 will stop assisting. This is how it currently works in the 0.20.0.

If we do not have a display then communication is not a problem but it is good to be close to the battery power switch if for any reason we need to switch off the power immediately.



mspider65 said:
The app will also have a dashboard with all the "real time" controller data (Power, Torque, etc.). In the future the app may also be able to update the controller firmware via the Arduino module using the built-in STM8 booltloader or a custom bootloader.

Very cool and something I really wanted to do. Users could use the TSDZ2 without any display. If they wanted some data they could simply connect the best display they have: their smartphone display. All via Bluetooth. I actually implemented an iOS app just to see how it would work and it had maps, GPS etcetera. :)
 
buba said:
But word programming would be possible to implement on the controller as we are starting from scratch.
Please do not implement on the motor controller the saving of configurations because:

- as we saw on KT-LCD3, that has the same memory size as the motor controller and is very small, after adding many features the KT-LCD3 memory is full and no more features can be added and/or will need to be removed, as it happens right now

- there is absolutely no need to store the configurations on the motor controller, instead, the LCDs as 850C has 16x times more memory (512 kbytes VS 32 kbytes) and so they can store it without any worry

- we need to increase the configurations, probably is more important to implement a specific package that is transferred at startup and there is a confirmation to LCD about this. And the configurations can be a structure, that can be placed on an array as happens now and after do a memcpy() of the array to a structure as I implemented recently on 850C firmware
 
buba said:
Could you reset everything and see if that helps?

------------------------

Step 1: Go to the Configuration Menu

Step 2: Go to the "Reset to factory defaults" under General Setup

Step 3: Increment the number until the screen is blank/turns off

Step 4: When the screen is blank/off, hold the ONOFF button for a couple of seconds. This is important!

Step 5: Release the ONOFF button

Step 6: Power on...

Hey thanks

Unfortunately nothing seems to help, I did also try flashing the alpha2, nothing.

The motor works fine with marcoq 0.3.5 and the stock display, so the motor does work.

I think that I may have messed up the wiring, I cut the male connector off a bafang 1-to-4 cable and soldered on a female connector, using the following mapping:

Bafang - TSDZ2
Brown - Blue
Orange - Red
Green - Brown
White - Green
Yellow - Yellow
Red - White
Blue - Orange
Black - Black

Used this picture for bafang pinout: https://electricbike.com/forum/filedata/fetch?id=77817&d=1541800588

I also put a female connector on the KT-LCD3 with the following mapping:
Wire color - Solder pad
Yellow - Red
Blue - Blue
Red - Black
Black - Green
Green - Yellow

I had to do this as the stock bafang display pinout does not match the KT-LCD3.

Are these correct? Or is there a guide somewhere that I missed on how to create the cable?
 
thineight said:
Buba, I was wondering the difference between the 0.20 Power and Torque mode..
In my mind the Power mode uses mainly the torque and cadence sensors with a proper force_vs_torque_units calibration to allow correct human power calculation and, in turn, the motor power in accordance with the set multipliers.
The Torque mode provides, i presume, the motor power in accordance with the multipliers without the need a proper calibration.

Conceptually both the modes use the same "logic" behind, am I correct?

Will gladly explain the difference but let me know if something is not clear :)


Power Assist:

1. Measure the torque sensor value and convert it to torque.
2. Measure the cadence.
3. Calculate human power, it is defined as torque * cadence.
4. The target motor power is calculated by human power * assist level multiplier. So if we measure a value of 200 watts human power and multiply it with an assist level multiplier of 2.0 we will be asking the motor to assist us with 400 watts motor power.

Result: the more you sweat the more assistance you will get.


Torque Assist:

1. Measure the torque sensor value.
2. The target motor torque is calculated by torque * assist level multiplier

Result: the more you push on the pedals the more assistance you will get.



thineight said:
Do you keep them as separate setup to keep a clean display output, i.e. power mode --> human watts are displayed, torque mode --> human watts are not displayed?

I have not removed the human power value displayed on the display when users are using Torque Assist. It is still sent to the display regardless of riding mode. I considered to remove it when using Torque Assist but I know Casainho has some nice graphs showing different parameters when riding. And some users maybe wish to see the human power even if they are using Torque Assist. So it is still sent regardless of mode.



thineight said:
I will try to understand the automatic calibration mode because I do not understand how it deals with the non linearity of the force_vs_torque_units related to the rest value / "knee" / full weight.
Did I miss the explanation from previous posts?

Thanks

It has actually nothing to do with the torque sensor. It is only for the cadence sensor. I saw a way of making it react faster to users start or stop pedaling.

The torque sensor is slow to react to fast changes. So when you stop pushing on the pedals it will have a time delay and still show that you are pushing on the pedals and continuing to assist you. It is the cadence sensor that usually first signals the system that the user has stopped rotating the pedals and requires no assistance. If it reacts faster we can have a motor that follows your intentions better.
 
casainho said:
buba said:
But word programming would be possible to implement on the controller as we are starting from scratch.
Please do not implement on the motor controller the saving of configurations because:

- as we saw on KT-LCD3, that has the same memory size as the motor controller and is very small, after adding many features the KT-LCD3 memory is full and no more features can be added and/or will need to be removed, as it happens right now

- there is absolutely no need to store the configurations on the motor controller, instead, the LCDs as 850C has 16x times more memory (512 kbytes VS 32 kbytes) and so they can store it without any worry

- we need to increase the configurations, probably is more important to implement a specific package that is transferred at startup and there is a confirmation to LCD about this. And the configurations can be a structure, that can be placed on an array as happens now and after do a memcpy() of the array to a structure as I implemented recently on 850C firmware

Of course! Was just thinking out loud.
 
Back
Top