TSDZ2 OSF for all displays, VLCD5-VLCD6-XH18, LCD3, 860C-850C-SW102.

Blacklite said:
michih. said:
Mr.Flibble said:
I am using 20.1C2 and like others have said, I am getting an occasionally feedback through the pedals like a tooth is missing in the main gear (no noise or apparent effect on the motor).
It only happens in higher cadences, with lower pressure on the pedals. There can be anywhere between 5 and 20 minutes between occurrences, and it happens in eMTB mode.

Is this the copy and paste issue, or something different?

Thanks again.

No ist still there. At first I thought it came from the blue gear. then swapped the entire engine. but the problem is the same. V7 flashed, the twitch is gone.

MFG Michael

I have been unable to get rid of this in the version I forked before mbrusa's released the .2 using the V12 base... I first thought it was an issue with code execution speed, so I've tried a whole lot of things to speed up the code outside the motor control. But still doesn't eliminate it completely. Unfortunately I don't have enough tools and knowledge to properly work out the problem.
...
It is possible to have some more information on how to replicate this problem?
Is it only in eMTB mode?
 
mbrusa said:
Blacklite said:
michih. said:
Mr.Flibble said:
I am using 20.1C2 and like others have said, I am getting an occasionally feedback through the pedals like a tooth is missing in the main gear (no noise or apparent effect on the motor).
It only happens in higher cadences, with lower pressure on the pedals. There can be anywhere between 5 and 20 minutes between occurrences, and it happens in eMTB mode.

Is this the copy and paste issue, or something different?

Thanks again.

No ist still there. At first I thought it came from the blue gear. then swapped the entire engine. but the problem is the same. V7 flashed, the twitch is gone.

MFG Michael

I have been unable to get rid of this in the version I forked before mbrusa's released the .2 using the V12 base... I first thought it was an issue with code execution speed, so I've tried a whole lot of things to speed up the code outside the motor control. But still doesn't eliminate it completely. Unfortunately I don't have enough tools and knowledge to properly work out the problem.
...
It is possible to have some more information on how to replicate this problem?
Is it only in eMTB mode?

is also in hybrid mode. have only tested emtb and hybrid. I especially notice it when I'm doing wheelies. think the strongly changing load triggers it.

MFG Michael
 
I noticed the problem quite a while ago too.
First I thought it's because the large motor freewheel bearing is going to have known problems. I changed and problem remained. I also tried swapping the complete back wheel.

Michih pointed me yesterday to the point that it might be the V12 version. I could add my ESP32 display changes to the former version and tried it with V7 again. The problem was gone!

I will change the assembler code and will do a test ride tomorrow again.
 
Just made the change and gave it a short trial.
I'm not sure that the problem (at least the one I noticed) is gone. At a 1km ride I again had one "clack".
 
Beli said:
I noticed the problem quite a while ago too.
First I thought it's because the large motor freewheel bearing is going to have known problems. I changed and problem remained. I also tried swapping the complete back wheel.

Michih pointed me yesterday to the point that it might be the V12 version. I could add my ESP32 display changes to the former version and tried it with V7 again. The problem was gone!

I will change the assembler code and will do a test ride tomorrow again.
Did you test with native mspider65 v12 version or the ported one to the 20.1.CV2? As you mentioned ESP32 and your display code, I assume it’s the first.
If this is the case, I am confident that mspider65 will very soon come with a working solution that can be easily ported to 20.1.CV2.
 
I use mspider65 V12 with an ESP32 (plus display directly connected to the ESP32 and additions for that).
 
mbrusa said:
Blacklite said:
michih. said:
Mr.Flibble said:
I am using 20.1C2 and like others have said, I am getting an occasionally feedback through the pedals like a tooth is missing in the main gear (no noise or apparent effect on the motor).
It only happens in higher cadences, with lower pressure on the pedals. There can be anywhere between 5 and 20 minutes between occurrences, and it happens in eMTB mode.

Is this the copy and paste issue, or something different?

Thanks again.

No ist still there. At first I thought it came from the blue gear. then swapped the entire engine. but the problem is the same. V7 flashed, the twitch is gone.

MFG Michael

I have been unable to get rid of this in the version I forked before mbrusa's released the .2 using the V12 base... I first thought it was an issue with code execution speed, so I've tried a whole lot of things to speed up the code outside the motor control. But still doesn't eliminate it completely. Unfortunately I don't have enough tools and knowledge to properly work out the problem.
...
It is possible to have some more information on how to replicate this problem?
Is it only in eMTB mode?

I've only been using Emtb mode, and it took a good 40 minutes to notice it happen.
I suspect that was due to my outbound trip being average uphill (more pressure on pedals), and my homebound average downhill (less pressure, higher cadence).

I first noticed it after a steep climb, shortly into the flat easy bit at the top.
 
The TSDZ2 motor controller V2 is a way more capable hardware to implement FOC (ARM 32bits 64MHz VS STM8 8bits 16 MHz, and with added 3 motor phase current sensors), which will mean more efficiency motor control and less noise. Also the microcontroller manufacturer provides a ready code for FOC witth an application note documenting, so should be very fast to get it working!!

With TSDZ2 motor controller V2, there will be no need to do hall sensors calibrations and we can have sure to get the best efficiency possible and lowest noise.

The cost of the motor controller V2 is the same 35€ as old motor controller. The only thing that changes is the programmer to flash the firmware, that is the J-Link but is also very cheap as it costs 4€ on Ebay.

This is a call for help, because, if more developers help, I am pretty sure we can have the very first working version of the firmware in 1 month or less!

I just started the very initially firmware, here the repository: https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2
We also have all the information about the hardware, like all datasheets and application notes of the new microcontrollers as also all other chips.

And building the very initial code:
Screenshot-from-2021-04-27-08-52-49.png
 
My first impression with adding
pop cc
remained: the problem still exists.

Once I really noticed that the motor turned on again and produced kind of a stroke on the crankshaft. Problem can't be reproduced with a certain action. But it seem to happen with higher cadence (~80) and moderate pedal force.

If I knew an event or value that would help to observe this occurrence (with the ESP32) I could add it to be shown on my display.
 
Beli said:
My first impression with adding
pop cc
remained: the problem still exists.

Once I really noticed that the motor turned on again and produced kind of a stroke on the crankshaft. Problem can't be reproduced with a certain action. But it seem to happen with higher cadence (~80) and moderate pedal force.

If I knew an event or value that would help to observe this occurrence (with the ESP32) I could add it to be shown on my display.

Should be moving the “pop cc”, not adding an extra one.

Haven’t done too much testing but so far this fix seems to work for me.
 
Blacklite said:
Beli said:
My first impression with adding
pop cc
remained: the problem still exists.

Once I really noticed that the motor turned on again and produced kind of a stroke on the crankshaft. Problem can't be reproduced with a certain action. But it seem to happen with higher cadence (~80) and moderate pedal force.

If I knew an event or value that would help to observe this occurrence (with the ESP32) I could add it to be shown on my display.

Should be moving the “pop cc”, not adding an extra one.

Haven’t done too much testing but so far this fix seems to work for me.

Yes, not add but just move at the end!
The correct code should be the following
Code:
        __asm
            push cc             // save current Interrupt Mask (I1,I0 bits of CC register)
            sim                 // disable interrupts  (set I0,I1 bits of CC register to 1,1)
                                // Hall GPIO interrupt is buffered during this interval
            mov _ui8_temp+0, _ui8_hall_state_irq+0
            mov _ui16_b+0, _ui8_hall_60_ref_irq+0
            mov _ui16_b+1, _ui8_hall_60_ref_irq+1
            mov _ui16_a+0, 0x5328 // TIM3->CNTRH
            mov _ui16_a+1, 0x5329 // TIM3->CNTRL
            pop cc              // enable interrupts (restores previous value of Interrupt mask)
                                // Hall GPIO buffered interrupt could fire now
        __endasm;
 
mspider65 said:
Blacklite said:
Beli said:
My first impression with adding
pop cc
remained: the problem still exists.

Once I really noticed that the motor turned on again and produced kind of a stroke on the crankshaft. Problem can't be reproduced with a certain action. But it seem to happen with higher cadence (~80) and moderate pedal force.

If I knew an event or value that would help to observe this occurrence (with the ESP32) I could add it to be shown on my display.

Should be moving the “pop cc”, not adding an extra one.

Haven’t done too much testing but so far this fix seems to work for me.

Yes, not add but just move at the end!
The correct code should be the following
Code:
        __asm
            push cc             // save current Interrupt Mask (I1,I0 bits of CC register)
            sim                 // disable interrupts  (set I0,I1 bits of CC register to 1,1)
                                // Hall GPIO interrupt is buffered during this interval
            mov _ui8_temp+0, _ui8_hall_state_irq+0
            mov _ui16_b+0, _ui8_hall_60_ref_irq+0
            mov _ui16_b+1, _ui8_hall_60_ref_irq+1
            mov _ui16_a+0, 0x5328 // TIM3->CNTRH
            mov _ui16_a+1, 0x5329 // TIM3->CNTRL
            pop cc              // enable interrupts (restores previous value of Interrupt mask)
                                // Hall GPIO buffered interrupt could fire now
        __endasm;

problem seems to be resolved. have just ridden a lot of wheelies. normally it always twitched. not even now.

mfg michael
 
I really was too fast and overlooked that there was already the pop cc earlier :oops:
Just changed and will try again...
 
I am after longer tests 20.1c, 20.1c2. as for me, it is not suitable for driving, on the revised version 20.1c2 with FW turned off, I heated up to 75 ° after driving 3km on a flat road with an average speed of 30kmh. I came back home, I switched the displays from sw102 to ktlcd3 from 0.20 beta. 10x better. same route, same speed, temperature max 40 °. no wild reaction to the slight rotation of the crank. on 20.1C2 without brake sensors it is impossible to drive. returning home and connecting the sw102 back, I played 0.8 and it stays like that.
For me the best osf is:
. 1 - 0.20beta,
2- 0.8 ,.
3- 0.6.
 
After applying pop cc at the right place and 10km it seems to be okay :thumb:
 
hetm4n said:
I am after longer tests 20.1c, 20.1c2. as for me, it is not suitable for driving, on the revised version 20.1c2 with FW turned off, I heated up to 75 ° after driving 3km on a flat road with an average speed of 30kmh. I came back home, I switched the displays from sw102 to ktlcd3 from 0.20 beta. 10x better. same route, same speed, temperature max 40 °. no wild reaction to the slight rotation of the crank. on 20.1C2 without brake sensors it is impossible to drive. returning home and connecting the sw102 back, I played 0.8 and it stays like that.
For me the best osf is:
. 1 - 0.20beta,
2- 0.8 ,.
3- 0.6.

Thanks for letting know I'm not alone with this. I reported my tests with same heating issues earlier in the thread, I tried to keep all the variables same when testing. I also flashed back and use to this day - 0.20beta because of noticeably lower temperatures when riding MTB.
Regarding fw off, on, in 20.1c2 doesn't make a difference. And all firmwares after 0.8.0 are heating like that.
I still hope someone will come with a solution to this :) If anyone needs my help I can test again.
 
It seems there is a good progress and all the issues of the latest version based on v12 were addresses in v13. If someone implements the changes on 20.1.CV2, please kindly share the new motor firmware for testing.
mspider65 said:
New version released.
Everything must be updated, Android App, ESP32 and Controller.

The files are always on Github: https://github.com/TSDZ2-ESP32/TSDZ2-ESP32-Wiki/tree/master/bin
- Android: TSDZ2_ESP32v2.1.9.apk
- ESP32: TSDZ2-ESP32-Mainv1.1.7.zip
- STM8: TSDZ2-v13.zip

This version contains mainly some fix to the Motor Controller.
In particular:
- the annoyng problem of the "power glitch" which rarely occurred is solved.
- removed potential overrun error in ADC conversions
- PWM frequency reduced to 18KHz
- PWM "Dead Time" increased from 1us to 1.5us

Regarding the "Dead Time" increase, i found the OEM Firmware uses a vales of 3,1us but the original OSF firmware used a value of only 1us. Dead time is a very delicate parameter and its incorrect setting can cause higher consumption and in the worst case serious overheating of the controller.
I only did a test ride of a couple of hours and my impression is that this intervention has further reduced the power consumption. I await your feedback for confirmation.
 
v20.1C with Imperial units: the wh/mile calculation shown on a 850C display are much too low and the graph of wh/mile is painted red indicating excess values. The calculation of wh consumed in Battery SOC looks to be correct. SI units are all correct.

I know its technically correct to display imperial temperature in Fahrenheit but Centigrade is so much easier and the KT-LCD3 always reads Centigrade?

The power consumption with a correctly calibrated motor appears to be either normal at 6.5wh/km (v1.1 measured over '000s of kms) or better. What is certain is a) individual but theoretically identical TSDZ2 motors show markedly different performance and b) with invalid torque parameters eg using those downloaded the performance is rocket like and the motor does warm up; you just sit back and pretend to be pedaling. But this is to the credit of the software; the previous versions could never be distinguished in this way or so I think.
 
James Broadhurst said:
I know its technically correct to display imperial temperature in Fahrenheit but Centigrade is so much easier and the KT-LCD3 always reads Centigrade?

:thumb: Would defiantly be nice to be able to choose the temperature in Centigrade when setting all other settings to 'imperial'
 
I have made today 35 km with OSF 1.0.1
I have used most of the time 8-12 level of assistance.
a lit bit of enduro ride, flat with single track

Distance: 35 km
Outside temp : 19 C
Motor temp start - 21C
Motor temp - end- 41C
peak- 54C
FW- On
Battery: 830 Wh
battery start-100 %- 54.6 V
Battery on the end of the ride: 65%, 49.1 V

Im very happy of that results.
 
martin.shane said:
I have made today 35 km with OSF 1.0.1
I have used most of the time 8-12 level of assistance.
a lit bit of enduro ride, flat with single track

Distance: 35 km
Outside temp : 19 C
Motor temp start - 21C
Motor temp - end- 41C
peak- 54C
FW- On
Battery: 830 Wh
battery start-100 %- 54.6 V
Battery on the end of the ride: 65%, 49.1 V

Im very happy of that results.
This are similar results I have on my EBike. My motor only goes to 85 degrees temperature if I put high assist level and I ride on the street at 45 km/h and motor using like peaks of 900W, the motor will get to 85 degrees after maybe 5 or more minutes.

Battery 830 Wh should be big and heavy!! I have 500Wh and 300Wh batteries and I already think the 500Wh battery is to big, but I can do with it easily 60kms on flats, MTB tires, and I weight 105 kgs.
 
casainho said:
This are similar results I have on my EBike. My motor only goes to 85 degrees temperature if I put high assist level and I ride on the street at 45 km/h and motor using like peaks of 900W, the motor will get to 85 degrees after maybe 5 or more minutes.

Battery 830 Wh should be big and heavy!! I have 500Wh and 300Wh batteries and I already think the 500Wh battery is to big, but I can do with it easily 60kms on flats, MTB tires, and I weight 105 kgs.

Battery weight is 3.3 kg for 17,5 AH . Samsung E35 , 3.7 v ,
I use it for longer distances and for ... MTB. As We all know efficiency and power is going down if the V is dropping. Having bigger battery let me go with power for around 50 % of capacity. Then it drops and I can feel it. ( I have some problem to set up resistance as it is changing. Power loss- sometimes small like 2-7 , sometimes big like 17-20. I do not know why...)
My weight is 79 kg.

But the most important is that because FW I started riding with higher cadency and lower ratio- around middle of my 10 gear cassette. Before that I used to ride almost all the time the higher ratio .
I have notice that this change is ( besides is a good thing for U knees) much more efficient and put much less stress on the motor, drive components and blue gear. It is kind of thinking like "modern bikes " where we have front sprocket max 36, most of the time 24-32 and bigger wheels.
Also important is that i use ( for now) 26 + tires ( 26 x 2.6) that gives me around 27' diameter. Higher cadence and lower gear ratio is the way to go ... Im using front 42 and rear 11-34 , and i know that U have around 50 in the front. ( I done the same some time ago ..) In my set up I can easy go like 43 km/h
For my next bike what I building now ( 29+ bike ) I have design special front sprocket ...38! With proper offset of 9 mm. Bigger wheels, higher cadence ...It works for me well. All because OSF! I can design whole bicycle around that firmware. THANK U for such a great work.
CHainring38.jpg

Here Is a lit bit of calculation. Speed for cadence. Cadence 90
38 chainring in 29+ size tires
42 chainring in 26+ size tires
cassete 11-34

Printed prototype.

IMG_20210501_093014.jpgIMG_20210501_093025.jpgIMG_20210501_093051.jpg
 

Attachments

  • 42_speed_cadence.jpg
    42_speed_cadence.jpg
    21.6 KB · Views: 776
  • 38_gearing_speedCadence.jpg
    38_gearing_speedCadence.jpg
    21.3 KB · Views: 776
martin.shane said:
For my next bike what I building now ( 29+ bike ) I have design special front sprocket ...38! With proper offset of 9 mm. Bigger wheels, higher cadence ...It works for me well. All because OSF! I can design whole bicycle around that firmware. THANK U for such a great work.
CHainring38.jpg
That looks Great!
Would you be willing to share your 3D model?
 
I will have few of them after CNC process. Cheap. Only Cost of the material for members of this forum. I design it for my custom bike frame and it will be like an option for my customers if they choose TSDZ2. But it will work with other frames as well.
For now the most important thing is chainline. It looks like it will be better then OEM but worst then 42 from some aftermarket makers. If U look at the engine case , there is a small groove in the bottom. It affects how deep chainring can go until chain will start rubbing the case. I will use it in a boost frame and 73 BB . We will see. If the chainline will be very much worst then it not worth doing it. In 3 weeks It will be ready and we will see...:)
 
Back
Top