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

Rafe said:
casainho said:
850C display firmware can be installed without open it
Now that's more like it. No way was I going to break open a very expensive sealed display but this is an entirely different kettle of fish :)
It will all depends if there are developers available to help investigate and develop the software, otherwise this will not be a possibility.
 
casainho said:
850C display firmware can be installed without open it

Our firmware can be flashed on 850C by connecting a cable to the motor connector - this is for a new 850C from factory:



There are 2 tools needed for this: a specific Windows software from APT (the manufacturer) and "special box" also from the manufacturer.

For what I could understand:

1. The "special box" is just a USB<->UART 3.3V converter like the popular and very cheap ones used on Arduino. Also it powers the LCD but this can be done with the battery power.
but if the special case is only a usb to serial converter, with an old computer with a serial port might it not be necessary?
 
andrea_104kg said:
but if the special case is only a usb to serial converter, with an old computer with a serial port might it not be necessary?
Serial port of computers have different voltages I think. The converters I mention used on Arduino are pretty cheap just like the STLinkV2.
 
casainho said:
Rydon said:
casainho said:
Rydon said:
I tested v19 beta 3 on a coaster brake motor. There is no backward resistance but I also have no power. I did a reset and triple checked all the settings. There are good torque and PAS/cadence readings but always 0 watts. Any ideas?

The motor worked fine with v18.2 but had extreme backward resistance that made it unusable for coaster brake.
This code changed bit since beta 2, now ui8_pas_cadence_rpm will be 0 if we are not pedaling forward:

Can you please verify that you have cadence value only when pedaling forward??

This is the new piece of code to turn on/off the motor PWM. See that if there is not ui8_m_adc_battery_target_current because there is no cadence or torque.

Try also to enable BOOST.

Sorry, I missed this when you posted it. I have tested again and cadence is 0 when pedaling backward. There is no power when pedaling forward at any assist level. Watts is always 0. Cadence reads as expected when pedaling forward. Turning on boost has no effect. Can I try something else?
So, there is cadence and torque sensor signal. Please try startup start without pedaling.

Please tell if PWM duty-cycle value do increases when you pedal with torque... It should increase!!

Are you sure brake signal is not active??

I have waited for v19 release to follow up with this coaster brake effort. I loaded the v19 release on a coaster brake motor and there is no change over v19 beta 3. There is no throttle. There is no power. Watts is always 0. There are no brake sensors installed. Boost has no effect. V18.2 has power and works with throttle disabled but has resistance when pedaling backward so cannot be used for braking.

Here are the v19.0 values:
ADC Throttle = 0
Throttle = 120
ADC torque = 36 - 99
Torque = 0 - 165
Cadence reads normal pedaling forward. 0 when pedaling in reverse.
PWM is always 0

I have a number of disabled riders (quadriplegics) that need the benefits of the open-source firmware on a coaster brake motor. This is also the only mid-drive motor with a coaster brake option so there are a lot of bikes that can use this as well.
 
Rydon said:
casainho said:
Rydon said:
casainho said:
This code changed bit since beta 2, now ui8_pas_cadence_rpm will be 0 if we are not pedaling forward:

Can you please verify that you have cadence value only when pedaling forward??

This is the new piece of code to turn on/off the motor PWM. See that if there is not ui8_m_adc_battery_target_current because there is no cadence or torque.

Try also to enable BOOST.

Sorry, I missed this when you posted it. I have tested again and cadence is 0 when pedaling backward. There is no power when pedaling forward at any assist level. Watts is always 0. Cadence reads as expected when pedaling forward. Turning on boost has no effect. Can I try something else?
So, there is cadence and torque sensor signal. Please try startup start without pedaling.

Please tell if PWM duty-cycle value do increases when you pedal with torque... It should increase!!

Are you sure brake signal is not active??

I have waited for v19 release to follow up with this coaster brake effort. I loaded the v19 release on a coaster brake motor and there is no change over v19 beta 3. There is no throttle. There is no power. Watts is always 0. There are no brake sensors installed. Boost has no effect. V18.2 has power and works with throttle disabled but has resistance when pedaling backward so cannot be used for braking.

Here are the v19.0 values:
ADC Throttle = 0
Throttle = 120
ADC torque = 36 - 99
Torque = 0 - 165
Cadence reads normal pedaling forward. 0 when pedaling in reverse.
PWM is always 0

I have a number of disabled riders (quadriplegics) that need the benefits of the open-source firmware on a coaster brake motor. This is also the only mid-drive motor with a coaster brake option so there are a lot of bikes that can use this as well.

Ok, we tried something and got an interesting result that might be helpful. By applying backward torque on the pedals when first powering up the motor when it calibrates, we get power. The motor will turn continuously after pedaling to start until you apply backward pedal pressure to stop. Brakes also stop the motor. This is only with v19. With 18.2 it works normally and delivers power as expected but has the backward resistance problem.
 
casainho said:
Rafe said:
casainho said:
850C display firmware can be installed without open it
Now that's more like it. No way was I going to break open a very expensive sealed display but this is an entirely different kettle of fish :)
It will all depends if there are developers available to help investigate and develop the software, otherwise this will not be a possibility.

Don't worry, I should have this aspect handled. My priority first hand is get approved to distribute the bootloader software. The second priority is the cheapest easiest cable to flash new firnware to the 850c... I think everything is in place, just waiting for confirmation... I'm just so glad we finally got it worked out to flash these directly... Literally in under 5 minutes you can get a motor/display OSF installed and running!!! Nice and clean, no more breaking and entering ;)
 
eyebyesickle said:
casainho said:
Rafe said:
casainho said:
850C display firmware can be installed without open it
Now that's more like it. No way was I going to break open a very expensive sealed display but this is an entirely different kettle of fish :)
It will all depends if there are developers available to help investigate and develop the software, otherwise this will not be a possibility.

Don't worry, I should have this aspect handled. My priority first hand is get approved to distribute the bootloader software. The second priority is the cheapest easiest cable to flash new firnware to the 850c... I think everything is in place, just waiting for confirmation... I'm just so glad we finally got it worked out to flash these directly... Literally in under 5 minutes you can get a motor/display OSF installed and running!!! Nice and clean, no more breaking and entering ;)

Just flashed an 850C for a friend without breaking and entering (the 850C). Worked great. :) Thanks to Casainho and Eyebyesickle for figuring that part out. To be clear though, I have the proprietary flash kit. Hopefully, we will get one that can be distributed. Sounds like Eyebye is hinting at that.
 
Rydon said:
Ok, we tried something and got an interesting result that might be helpful. By applying backward torque on the pedals when first powering up the motor when it calibrates, we get power. The motor will turn continuously after pedaling to start until you apply backward pedal pressure to stop. Brakes also stop the motor. This is only with v19. With 18.2 it works normally and delivers power as expected but has the backward resistance problem.
I wish I could help more but that would only be possible with that specific motor on that type of bicycle that I don't own and I don't known anyone with one of that bicycles, they are mostly no existence here in Portugal, at least in my flat city near the ocean where people ride in a good number bicycles. I guess on this flat places would be good to have that bicycles.
 
Rydon said:
casainho said:
Rydon said:
casainho said:
This code changed bit since beta 2, now ui8_pas_cadence_rpm will be 0 if we are not pedaling forward:

Can you please verify that you have cadence value only when pedaling forward??

This is the new piece of code to turn on/off the motor PWM. See that if there is not ui8_m_adc_battery_target_current because there is no cadence or torque.

Try also to enable BOOST.

Sorry, I missed this when you posted it. I have tested again and cadence is 0 when pedaling backward. There is no power when pedaling forward at any assist level. Watts is always 0. Cadence reads as expected when pedaling forward. Turning on boost has no effect. Can I try something else?
So, there is cadence and torque sensor signal. Please try startup start without pedaling.

Please tell if PWM duty-cycle value do increases when you pedal with torque... It should increase!!

Are you sure brake signal is not active??

I have waited for v19 release to follow up with this coaster brake effort. I loaded the v19 release on a coaster brake motor and there is no change over v19 beta 3. There is no throttle. There is no power. Watts is always 0. There are no brake sensors installed. Boost has no effect. V18.2 has power and works with throttle disabled but has resistance when pedaling backward so cannot be used for braking.

Here are the v19.0 values:
ADC Throttle = 0
Throttle = 120
ADC torque = 36 - 99
Torque = 0 - 165
Cadence reads normal pedaling forward. 0 when pedaling in reverse.
PWM is always 0

I have a number of disabled riders (quadriplegics) that need the benefits of the open-source firmware on a coaster brake motor. This is also the only mid-drive motor with a coaster brake option so there are a lot of bikes that can use this as well.

I actually bought the coaster brake motor when ordering the last time just for this reason. I also created the double cadence resolution on that motor just so it stops as fast as possible. It is especially easy to setup on that motor. I do not think that any commercial product in the world is using all transitions from the cadence sensor so it is possible to have double the response time.

But I can not stress enough that I have improved the original cadence code as well so no user is forced to setup the "double cadence".

Since a couple of weeks I installed a normal clutch on the motor in question but can switch to the coaster brake when needed. Have switched between different setups and gears all the time to test all aspects of the system.

With user suggestions and myself experiencing a strong pull (power-off-lag) I thought it is not acceptable to have a slow response on the system, especially on the coaster brake version. It will always be some lag but there is a great difference between some small lag and lag so have tried to improve this as much as possible.

Not completely sure but have a feeling and know where to start testing in the firmware for the no-power-issue if it is not solved in the 0.20.0. Which I think it is as I could use that version with the coaster brake without problem.
 
Quick update on the 0.20.0 beta!

I will submit one last commit to my branch today and it will be something that is beta-worthy for all users! I know I promised the beta out this week and this really pushed me to finalize everything. Will develop the entire day today and give a better update tonight on where we stand. Just wanted to update the status so the community knows that we are very close to start testing at large scale!
 
buba said:
Quick update on the 0.20.0 beta!

I will submit one last commit to my branch today and it will be something that is beta-worthy for all users! I know I promised the beta out this week and this really pushed me to finalize everything. Will develop the entire day today and give a better update tonight on where we stand. Just wanted to update the status so the community knows that we are very close to start testing at large scale!
Buba, I was thinking that probably will be better if I fork 0.20.0 motor controller for the 850C LCD, because seems there will be more features that will not be on KT-LCD3 anyway due to the memory limitations and I think would be a bad idea to stress the development and stability of the version of KT-LCD3.

And maybe the SW102 will have the same features of 850C and they can share the same motor controller version.

A feature I want is the torque sensor calibration and it needs the setup of more 11 differents values on LCD (21 bytes), maybe this is impossible on KT-LCD3.
 
A warning/my view of very near future of KT-LCD3:

- I think the shops selling TSDZ2 will probably stop selling the KT-LCD3 because they are being asking for long for the 850C and SW102 LCDs (I guess this is because they know their clients will prefer them)

- Also will be much easier for this shops to flash the firmware without opening the LCD, also this guarantees the water resistant level from the LCD manufacturer

- I think users will prefer the LCDs that can be flashed without open them (for the same reasons of shops) and they will be 850C and probably SW102.

About the SW102: there are active 2 developers that seems more experienced than me, they are working fast and maybe a working version will be achieved in 2 weeks.

Also seems there is hope it will be possible to flash firmware on SW102 by Bluetooth, without open it.
 
casainho said:
buba said:
Quick update on the 0.20.0 beta!

I will submit one last commit to my branch today and it will be something that is beta-worthy for all users! I know I promised the beta out this week and this really pushed me to finalize everything. Will develop the entire day today and give a better update tonight on where we stand. Just wanted to update the status so the community knows that we are very close to start testing at large scale!
Buba, I was thinking that probably will be better if I fork 0.20.0 motor controller for the 850C LCD, because seems there will be more features that will not be on KT-LCD3 anyway due to the memory limitations and I think would be a bad idea to stress the development and stability of the version of KT-LCD3.

And maybe the SW102 will have the same features of 850C and they can share the same motor controller version.

A feature I want is the torque sensor calibration and it needs the setup of more 11 differents values on LCD (21 bytes), maybe this is impossible on KT-LCD3.

Whatever you think is best and simplifies development for you. But do you wish to have the exciting repo, TSDZ2+KT-LCD3, and make another repo for TSDZ2+850C and TSDZ2+SW102? Then it would all still be under your official GitHub? Or do you want me to carry the TSDZ2+KT-LCD3 in my fork and you just take the motor controller firmware for future development of 850C?

I know that I can put more in the KT-LCD3 and would be able to add you torque sensor calibration with some time but I understand you no longer wish to have the KT-LCD3 "supported".

Just want to add that I think it is best to have separate repos for different displays. As this greatly simplifies the code in the TSDZ2. If this is what you are hinting at I agree.

EDIT: Either way, this is what I would recommend: the community should get a stable version 0.20.0. This will be a version with many great changes and improvements. It will be a thank you for all users that ordered the KT-LCD3, gave feedback, made the overall experience much better and helped create this community to what it is today. After 0.20.0 you can do whatever you feel like from the 0.20.0 and the best thing would be a new repo for the new displays. So the TSDZ2+KT-LCD3 is in a separate repo.

Please give some input to what you think of my recommendation. Because I think it is very flexible. As soon as 0.20.0 is released how I envisioned it you can implement all the other things you wish to do on a separate repo for the other displays. But before we add more complexity let us focus on the 0.20.0.
 
buba said:
Please give some input to what you think of my recommendation. Because I think it is very flexible. As soon as 0.20.0 is released how I envisioned it you can implement all the other things you wish to do on a separate repo for the other displays. But before we add more complexity let us focus on the 0.20.0.
I think you can keep current repo as it is and I will later create a new one specific to hold the code for motor controller and 850C, and it will be a fork of 0.20.0.
 
casainho said:
buba said:
Please give some input to what you think of my recommendation. Because I think it is very flexible. As soon as 0.20.0 is released how I envisioned it you can implement all the other things you wish to do on a separate repo for the other displays. But before we add more complexity let us focus on the 0.20.0.
I think you can keep current repo as it is and I will later create a new one specific to hold the code for motor controller and 850C, and it will be a fork of 0.20.0.

Perfect!
 
buba said:
I will submit one last commit to my branch today and it will be something that is beta-worthy for all users!

I just took a look at your latest commits. Very well commented and easy to understand!
I still don't understand, why you don't use a PI-control for the battery current and fiddle around with the ramp steps and why not using interrupts for the PAS and speed sensors. Is the PAS signal not symmetrical (duty cycle = 0.5)?

The e mtb mode is not working yet?

regards
stancecoke
 
stancecoke said:
buba said:
I will submit one last commit to my branch today and it will be something that is beta-worthy for all users!

I just took a look at your latest commits. Very well commented and easy to understand!

Thank you, appreciate it! Hoping to add more comments in the next couple of commits!



stancecoke said:
I still don't understand, why you don't use a PI-control for the battery current and fiddle around with the ramp steps...

Really should be a PI-controller (!) and I would love to implement that. But due to many reasons its kept simple for now...



stancecoke said:
... and why not using interrupts for the PAS and speed sensors.

You are right, should be interrupts. But works for now and can be improved more in the future. No difference to user but would be much nicer code!



stancecoke said:
Is the PAS signal not symmetrical (duty cycle = 0.5)?

Sadly no, thought it would be in the beginning but it differs ever so slightly. Around 0.56 duty cycle HIGH and 0.44 LOW for the bike I am testing. Depends on bike and magnets. Planned to explain this long ago but have postponed. Will try to explain soon!



stancecoke said:
The e mtb mode is not working yet?

Just noticed I have not added it on my pushed branch! Should be on my next commit! Sorry! Tuning the last parameters and need to finish the display side development and merge everything.
 
casainho said:
A feature I want is the torque sensor calibration and it needs the setup of more 11 differents values

The torque sensor output can be described with two linear equations,if you ignore the slight difference between left and right pedal you mentioned in this post. I guess the temperature drift of the system will be greater than the difference between left and right.

So you just need 4 constants to calculate the torque from the adc reading with sufficient accuracy. Excel will tell you the linear approximation coefficients. You can scale them to an eigth bit value if you want to avoid hibyte and lowbyte transmission. :)

torquesensor calibration.PNG

I just took your right pedal example and converted the Kilogramm into Newtonmeter for a 170mm crank length.

regards
stancecoke
 
buba said:
I actually bought the coaster brake motor when ordering the last time just for this reason. I also created the double cadence resolution on that motor just so it stops as fast as possible. It is especially easy to setup on that motor. I do not think that any commercial product in the world is using all transitions from the cadence sensor so it is possible to have double the response time.

But I can not stress enough that I have improved the original cadence code as well so no user is forced to setup the "double cadence".

Since a couple of weeks I installed a normal clutch on the motor in question but can switch to the coaster brake when needed. Have switched between different setups and gears all the time to test all aspects of the system.

With user suggestions and myself experiencing a strong pull (power-off-lag) I thought it is not acceptable to have a slow response on the system, especially on the coaster brake version. It will always be some lag but there is a great difference between some small lag and lag so have tried to improve this as much as possible.

Not completely sure but have a feeling and know where to start testing in the firmware for the no-power-issue if it is not solved in the 0.20.0. Which I think it is as I could use that version with the coaster brake without problem.

Wow! I didn't expect that! That is awesome news. I know a few riders that will be doing cartwheels (figuratively speaking). :)
 
Rydon said:
buba said:
I actually bought the coaster brake motor when ordering the last time…
Wow! I didn't expect that! That is awesome news. I know a few riders that will be doing cartwheels (figuratively speaking). :)
Hi "coaster brake" caught my eye, never heard the term used except the ancient mechanical sense.

How does its use here fit in with TSDZ2?

Are we talking regen?

Does it block the use of additional regen hubs?

My need is extremely strong drag braking for very long descents, heavy tandem/cargo bike in hill country.

Not every brake system needs to be for Stop-Now safety, at least one will be switch on, 15min later switch off.

Is what was just mentioned above someting I should look at?

Links or anything else to help just dispel ignorance would also be appreciated.

Heat dissipation being an issue, especially once the battery's back to full :cool:

looking at 1000+W resistors mounted away from other bits.



 
john61ct said:
Rydon said:
buba said:
I actually bought the coaster brake motor when ordering the last time…
Wow! I didn't expect that! That is awesome news. I know a few riders that will be doing cartwheels (figuratively speaking). :)
Hi "coaster brake" caught my eye, never heard the term used except the ancient mechanical sense.

How does its use here fit in with TSDZ2?

Are we talking regen?

Does it block the use of additional regen hubs?

My need is extremely strong drag braking for very long descents, heavy tandem/cargo bike in hill country.

Not every brake system needs to be for Stop-Now safety, at least one will be switch on, 15min later switch off.

Is what was just mentioned above someting I should look at?

Links or anything else to help just dispel ignorance would also be appreciated.

Heat dissipation being an issue, especially once the battery's back to full :cool:

looking at 1000+W resistors mounted away from other bits.

No, we are talking about a version of the TSDZ2 that works on bikes with coaster brakes. These are hub brakes that are applied when you apply backward force on the cranks. The motor does this by not freewheeling at the cranks like all other mid-drive motors. It is only possible with torque sensing. Many of us had bikes with this kind of brake when we were kids. They are still popular today on cruisers and comfort bikes. They also allow quadriplegics with some use of their arms for a handcycle but no use of their hands to be able to brake while also pedaling and steering.
 
Oh wow, never imagined that, yes I know what coaster brakes are

never imagined the actual physical implementation would be part of eBike tech

assumed some sort of digital emulation

Roseanne Roseannadanna voice: "Never Mind!"
 
stancecoke said:
casainho said:
A feature I want is the torque sensor calibration and it needs the setup of more 11 differents values

The torque sensor output can be described with two linear equations,if you ignore the slight difference between left and right pedal you mentioned in this post. I guess the temperature drift of the system will be greater than the difference between left and right.

So you just need 4 constants to calculate the torque from the adc reading with sufficient accuracy. Excel will tell you the linear approximation coefficients. You can scale them to an eigth bit value if you want to avoid hibyte and lowbyte transmission. :)

I just took your right pedal example and converted the Kilogramm into Newtonmeter for a 170mm crank length.
Hmm, I got a different of 30kgs between left and right pedal: 100 kgs on right and 70 kgs on left so I think it should not be ignored.

For the users, I think will be easier to input pairs of: weight in kgs, ADC value. User will need a cheap digital fish scale or some know weights of 5 or 10 kgs, maybe up to max of 40kgs or 50kgs total. Maybe will help the user to calculate the ADC steps in each interval so he can understand which points to choose and simple calculator will work. But sure, excel will also work for the ones used to it.

For now it is working like this and took me some time to make it working. Maybe in future it can be improved and/or simplified but first we need to get more feedback. Myself, I will test this on the other bicycles I have.

And by the way, here is my 1000 watts peak of human power :)

I was testing the pedal human power reading and at startup, when I put my weight on the pedals, I got max value of 1050 watts!! As you can see on the graph (it averages the values on 3.5 seconds window so it does not show that peak of 1050 but shows a little less). The values more constant on the graph were about 100 up to 150 watts while I was riding, only on startups If I put a lot of force I could go to this high values of 1000 watts:

image.png


Validation:
- I verified before start this tests that the torque sensor was correctly measuring my weight of 102 kgs
- the formula is:
pedal_torque_x100 = torque_sensor_weight * (uint16_t) TORQUE_SENSOR_WEIGHT_TO_FORCE_X100;
pedal_torque_x100 = 102 kgs * 167
pedal_torque_x100 = 17034

pedal_power_x10 = pedal_torque_x100 * pas_cadence_rpm) / 96
pedal_power_x10 = (17034 * 60) / 96
pedal_power_x10 = 10646
pedal_power = 1064 watts!!

Hmmm, but there is one important note here!! the 1050 watts are instantaneous values and not the average of my human power... as we know, we should get a kind of sinewave shape on the pedal torque...

Force (Nm) = weight Kg * 9.81 * 0.17 (0.17 = arm cranks size)
---------------------------------------------------------*/
#define TORQUE_SENSOR_WEIGHT_TO_FORCE_X100 167

// (2 * pi) / (60 * 10) = 0.010466667
// 1 / 0.010466667 = 96
 
Rydon said:
buba said:
I actually bought the coaster brake motor when ordering the last time just for this reason. I also created the double cadence resolution on that motor just so it stops as fast as possible. It is especially easy to setup on that motor. I do not think that any commercial product in the world is using all transitions from the cadence sensor so it is possible to have double the response time.

But I can not stress enough that I have improved the original cadence code as well so no user is forced to setup the "double cadence".

Since a couple of weeks I installed a normal clutch on the motor in question but can switch to the coaster brake when needed. Have switched between different setups and gears all the time to test all aspects of the system.

With user suggestions and myself experiencing a strong pull (power-off-lag) I thought it is not acceptable to have a slow response on the system, especially on the coaster brake version. It will always be some lag but there is a great difference between some small lag and lag so have tried to improve this as much as possible.

Not completely sure but have a feeling and know where to start testing in the firmware for the no-power-issue if it is not solved in the 0.20.0. Which I think it is as I could use that version with the coaster brake without problem.

Wow! I didn't expect that! That is awesome news. I know a few riders that will be doing cartwheels (figuratively speaking). :)

Great! :bigthumb:

Will try to re-install the coaster brake clutch before the beta is released and test how it all works! It is now a couple of weeks since I last tested it so need to validate the latest changes.

My goal is that the motor should stop assisting as quickly as possible, no matter what TSDZ2 version you have. This means no different settings for the different TSDZ2 versions and no hassle. Will update more in the coming days!
 
stancecoke said:
buba said:
I will submit one last commit to my branch today and it will be something that is beta-worthy for all users!

I just took a look at your latest commits. Very well commented and easy to understand!

...

The e mtb mode is not working yet?

regards
stancecoke

Please let me know if I need to comment or explain something more! Just merged my local eMTB branch so if you want to take a look at it you are free to go to my development branch on GitHub:

https://github.com/leon927/TSDZ2-Smart-EBike/tree/testing-pwm-acc

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

It is now possible to release a beta for all users. But would like to make the cadence sensor calibration automatic for those users that wish to have a really fast response. Will explain more about the "double resolution cadence" in a coming post. Will update within one hour.
 
Back
Top