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

mbrusa said:
HughF said:
...
EDIT: I say fully operational - the menu's are accessible and adjustable, but the bugs in menu navigation are still there, the navigation hangs every once in a while, requiring a display power cycle.
Nfer said:
...
My SW102 freeze every time I access the torque sensor menu. Rest of the menus work fine. It could be because the torque menu is too long? can you split it several submenus?
I have modified the configuration menu to fit SW102.
Can you try? New zip file in PM.
PM Received, will try this evening (or sooner if I give up on work for the day)
 
Here is a spreadsheet with charts to simulate Startup boost settings.
There are two parameters, the logic is simple.

Startup boost torque factor (%)
The value of this parameter is the percentage increase in torque applied to the pedals with cadence = 0.
This value gradually decreases as the cadence increases, depending on the next parameter.
Default value 250, maximum 500.

Startup boost cadence step
It is used to calculate the decrease in the boost torque as the cadence increases, until extinction.
Default value 25. Limits from 10 to 50, higher value = shorter effect.

All combinations can be tried.
My favorite, with 36V motor and 36V battery is 300-20.
I also tried the 500-10, starting from a standstill on a very steep climb without any problems.
You just have to be very careful to push on the pedals gradually.
If you have a habit of pushing hard on the pedals at the start, don't try!
The blue gear says thank you.
View attachment Startup_boost_spreadsheet.zip
 
Ciao Mbrusa!

I tested the version a bit and I can confirm it is a more responsive than v7 that I was using.
In order to have a correct comparison I tested in same conditions. No startup boost and not assist with no pedal rotation. The motor engages quick and I see not point of using those, probably that my torque sensor is hardware calibrated and have big range.
Everything feels so natural :).

As a contribution, I have created an updated wiki manual for LCD3, containing all your updates. It will be easier for users to understand how to use and configure it.
https://github.com/bbeschea/TSDZ2_wiki/wiki/KT-LCD3-TSDZ2-V20.1C
 
mbrusa said:
Lii said:
Hello everyone! I also installed this version on my bike. And now I'm trying to adjust a non-linear increase in power according to the torque sensor. I want the power to increase not linearly, without sudden jumps. But so far I have not succeeded. I have calibrated the torque sensor: I have set the offset (220) and the maximum value (280). But even after calibrating the sensor, the power rises too sharply and therefore the maximum assistance level has to be reduced. I have a VLCD6 display. Is there a way to make the torque sensor response non-linear? I want less assistance with less pedal pressure, more support with hard pedal pressure. How do I tune non-linearity?
What mode are you using?

I've tried different modes. But none of the modes can provide a smooth start when you press the pedal lightly and at the same time high power when you press the pedal firmly. To achieve a smooth start, you have to limit the overall level of support. As a result, the maximum power is limited. I'm trying to find parameters with which I can change the non-linearity curve. Yesterday I experimented a lot with this but there is no result. An excessive change in the calibration of the torque sensor resulted in an "E02" error. Apparently I will have to study the code. I have some experience with C ++ programming with Arduino. :)
 
mbrusa said:
Here is a spreadsheet with charts to simulate Startup boost settings.
There are two parameters, the logic is simple.

Startup boost torque factor (%)
The value of this parameter is the percentage increase in torque applied to the pedals with cadence = 0.
This value gradually decreases as the cadence increases, depending on the next parameter.
Default value 250, maximum 500.

Startup boost cadence step
It is used to calculate the decrease in the boost torque as the cadence increases, until extinction.
Default value 25. Limits from 10 to 50, higher value = shorter effect.

All combinations can be tried.
My favorite, with 36V motor and 36V battery is 300-20.
I also tried the 500-10, starting from a standstill on a very steep climb without any problems.
You just have to be very careful to push on the pedals gradually.
If you have a habit of pushing hard on the pedals at the start, don't try!
The blue gear says thank you.
Startup_boost_spreadsheet.zip

Hi @mbrusa, looks like you've been making some great improvements to the tsdz2 osf, i wasn't aware of this version of the firmware until very recently. I'm going to give your firmware a try to compare against v.1.11 of the original fw - as I'm very interested in things like the eMTB mode - and better startup boost and you're getting very good reviews so far :thumb:

I will review your source in more detail - but if you don't mind me asking in advance - are you using casainho's protocol pretty much unchanged? Do you see any major problems with using your motor firmware against the wireless controller/remote we've developed on the other thread? I won't just try it without reviewing the code and protocol/packet definitions - and I realise I'll probably need to hardcode some settings that aren't yet exposed in the android app but am interested in your thoughts :)
 
Lii said:
I've tried different modes. But none of the modes can provide a smooth start when you press the pedal lightly and at the same time high power when you press the pedal firmly. To achieve a smooth start, you have to limit the overall level of support. As a result, the maximum power is limited. I'm trying to find parameters with which I can change the non-linearity curve. Yesterday I experimented a lot with this but there is no result. An excessive change in the calibration of the torque sensor resulted in an "E02" error. Apparently I will have to study the code. I have some experience with C ++ programming with Arduino. :)
Sounds like you should be using power mode without boost and lower the current ramp. Otherwise you will have to patch the code. Could you explain a scenario when you need this behaviour? Can you confirm the range of your torque sensor?
 
elfnino said:
mbrusa said:
elfnino said:
I've been desperatly waiting for the fusion of the best from all FW forks and it is here 20.1C ! :thumb:

I could catch only few minor issues in 850C release:
- Clock field settings is not persistent after restart, when I set Battery Voltage after restart the Time field is preset
- Seems that my temperature senzor shows aproximatly 10 degrees more than the real value is.
I'm glad you like the new version.
850C doesn't have an rtc and I haven't changed anything about it.
I did not understand what the problem is, you can explain better.
The next motor I will install will be with a temperature sensor, I will consider whether to add a calibration.

Let me explain better the issue, in cofig menu "Display/Clock field" I chose to set "batt volts" instead of "clock" but after display restart it reverts the setting back to default value which is again the "clock"

My temperature sensor on v1.0.0 was giving correct values, wonder if anyone else is having this offset +11 C on v20.1C or could be there is only something wrong with my senzor, maybe some moisture has got inside the case or so..

Hi - Really enjoying v20.1C on 860C. Started with hybrid mode and so far not finding any reason to switch. Strong starts on Seattle hills, super smooth acceleration, nice power at the top end. Very appreciative and grateful for all the time and effort!

I too found temp is displaying high, about 10F above ambient at start of ride. I think it's more than just a simple offset as the temperature change rate was higher than previously experienced under similar conditions. Also, the temp minimum and maximum did not inhibit the motor in any way even though the display indicated the limits were exceeded.

Interested if others have similar experience with temp display?
 
seattlesockey said:
...
I too found temp is displaying high, about 10F above ambient at start of ride. I think it's more than just a simple offset as the temperature change rate was higher than previously experienced under similar conditions. Also, the temp minimum and maximum did not inhibit the motor in any way even though the display indicated the limits were exceeded.

Interested if others have similar experience with temp display?
At this point it is clear that there is a problem with the temperature measurement.
Let me check.
 
beemac said:
...
I will review your source in more detail - but if you don't mind me asking in advance - are you using casainho's protocol pretty much unchanged? Do you see any major problems with using your motor firmware against the wireless controller/remote we've developed on the other thread? I won't just try it without reviewing the code and protocol/packet definitions - and I realise I'll probably need to hardcode some settings that aren't yet exposed in the android app but am interested in your thoughts :)
My aim was to improve the osf version for stock displays, after doing that I thought I'd also adapt it to LCD3 and 860C.
I have not followed the wireless project but I think it can be adapted to this version, v20.1C-860C uses the same protocol as v1.1.0 but it is not compatible, in the tx and rx buffers some common variables have remained unchanged, others have been added and others eliminated,
If you need clarification, feel free to ask.
 
mbrusa said:
Thanks maximusdm, great job.
Added to the release page.
I will fix any wiki issues if they are reported.
We thank you for putting the community above your direct needs!
 
mbrusa said:
seattlesockey said:
...
I too found temp is displaying high, about 10F above ambient at start of ride. I think it's more than just a simple offset as the temperature change rate was higher than previously experienced under similar conditions. Also, the temp minimum and maximum did not inhibit the motor in any way even though the display indicated the limits were exceeded.

Interested if others have similar experience with temp display?
At this point it is clear that there is a problem with the temperature measurement.
Let me check.
Bug found, it should now work.
Can you give me confirmation?
Thank you.

Only the hex file of the motor has changed.
https://github.com/emmebrusa/TSDZ2-Smart-EBike-860C/releases/tag/v20.1C-860C
 
Mine was reading a little higher than normal but I just put it down to the fact that I’m probably using more power than before. Thanks for fixing this. Will install it tomorrow
 
mbrusa said:
mbrusa said:
seattlesockey said:
...
I too found temp is displaying high, about 10F above ambient at start of ride. I think it's more than just a simple offset as the temperature change rate was higher than previously experienced under similar conditions. Also, the temp minimum and maximum did not inhibit the motor in any way even though the display indicated the limits were exceeded.

Interested if others have similar experience with temp display?
At this point it is clear that there is a problem with the temperature measurement.
Let me check.
Bug found, it should now work.
Can you give me confirmation?
Thank you.

Only the hex file of the motor has changed.
https://github.com/emmebrusa/TSDZ2-Smart-EBike-860C/releases/tag/v20.1C-860C

First opportunity to flash it is later tonight. Will definitely report back.

Thanks for looking into it so quickly!
 
Hello, very nice software. Is it possible to use it without the speed sensor? Unfortunately, I get error 08. which was not the case with the other versions and the originals.
 
The absence of the speed sensor is considered a fault, signaled by an error code, the same for all sensors.
The presence of an error disables assistance in all modes.
In case of necessity. it is however possible to force assistance even with an error if this is caused by a sensor problem, of torque, cadence or speed, enabling "Assist with error".
This feature is available in all versions.
You will have to choose the assistance mode that does not involve the use of the faulty sensor.
"Cadence assist" can be used if the torque sensor is faulty.
"Torque assist" can be used if the cadence sensor is faulty.
With failure of the speed sensor, all modes with a limitation can be used, the acceleration and deceleration ramps which are calculated as a function of the speed, assume a fixed value.

Regarding the speed sensor, the distance between the sensor and the magnet is now no longer a problem, it works well even if they are very close.

A curiosity, why don't you want to use the speed sensor?
 
w
mbrusa said:
beemac said:
G...
I will review your source in more detail - but if you don't mind me asking in advance - are you using casainho's protocol pretty much unchanged? Do you see any major problems with using your motor firmware against the wireless controller/remote we've developed on the other thread? I won't just try it without reviewing the code and protocol/packet definitions - and I realise I'll probably need to hardcode some settings that aren't yet exposed in the android app but am interested in your thoughts :)
My aim was to improve the osf version for stock displays, after doing that I thought I'd also adapt it to LCD3 and 860C.
I have not followed the wireless project but I think it can be adapted to this version, v20.1C-860C uses the same protocol as v1.1.0 but it is not compatible, in the tx and rx buffers some common variables have remained unchanged, others have been added and others eliminated,
If you need clarification, feel free to ask.

Ok great thanks very much - my motivation with the wireless project was less about wireless and more about getting rid of the display completely. I run my bike 'headless' with just a button keypad on the handlebars wired directly to the wireless controller.

I'm really interested in seeing how your fw compares - especially for startup boost and also if you integrate the changes mspider65 is proposing for motor control.... building a new fsr this weekend - so might be the time to try it out :)
 
mbrusa said:
The absence of the speed sensor is considered a fault, signaled by an error code, the same for all sensors.
The presence of an error disables assistance in all modes.
In case of necessity. it is however possible to force assistance even with an error if this is caused by a sensor problem, of torque, cadence or speed, enabling "Assist with error".
This feature is available in all versions.
You will have to choose the assistance mode that does not involve the use of the faulty sensor.
"Cadence assist" can be used if the torque sensor is faulty.
"Torque assist" can be used if the cadence sensor is faulty.
With failure of the speed sensor, all modes with a limitation can be used, the acceleration and deceleration ramps which are calculated as a function of the speed, assume a fixed value.

Regarding the speed sensor, the distance between the sensor and the magnet is now no longer a problem, it works well even if they are very close.

A curiosity, why don't you want to use the speed sensor?
assist with error Unfortunately, I cannot select this in the configurator 3.0. I use the 06 display.
 
galaxissurfer said:
assist with error Unfortunately, I cannot select this in the configurator 3.0. I use the 06 display.
It is not in the configurator because it makes no sense, "Assist with error" is not a parameter to be enabled by default, it must only be enabled in the event of a sensor failure.
It is possible to enable it only from the display, even with VLCD6.
With VLCD6 it's a little inconvenient, you know the lights turn on or off with the UP button for 2 seconds.
In the configurator you have to set Lights configuration-> Mode 3 to 10.
Turn on the display and wait 5 seconds, go to level 4-TURBO, lights button 6 times.
In detail, lights on (E02), lights off, lights on (E03), lights off, lights on (E04), lights off, wait 5 seconds "Assist with error" is enabled.
Attention, if you want to keep the setting when restarted, you must save in eeprom, go to level 0-OFF, lights button 6 times as described above.
While using the bike, E08 will again be displayed cyclically to remind you of the fault.
Remember that the engine does not work as well as with the speed sensor installed, because the acceleration and deceleration ramps cannot be calculated, it was the same with the 20 beta 1 version.

EDIT: I think the light button is not UP but -
 
seattlesockey said:
mbrusa said:
mbrusa said:
seattlesockey said:
...
I too found temp is displaying high, about 10F above ambient at start of ride. I think it's more than just a simple offset as the temperature change rate was higher than previously experienced under similar conditions. Also, the temp minimum and maximum did not inhibit the motor in any way even though the display indicated the limits were exceeded.

Interested if others have similar experience with temp display?
At this point it is clear that there is a problem with the temperature measurement.
Let me check.
Bug found, it should now work.
Can you give me confirmation?
Thank you.

Only the hex file of the motor has changed.
https://github.com/emmebrusa/TSDZ2-Smart-EBike-860C/releases/tag/v20.1C-860C

First opportunity to flash it is later tonight. Will definitely report back.

Thanks for looking into it so quickly!

Just got back from testing temp bug fix and can report it is working as expected. Temp display is equal to ambient at startup, temp display increases similar to past experience, motor power is diminished at min. temp setting and motor power restricted at max temp setting. Very nice!

Also am appreciating the new stability in the speed sensor. Thanks!
 
Can someone confirm that I understand this correctly?

For the 860c I need to flash a bin file to the display and a hex one to the motor.
For a Tongsheng display I need to compile a hex from the configurator, and flash it to the motor only?

With the Tongsheng display the process is reversible, and just flashing the motor with the original hex will revert to factory?
 
Mr.Flibble said:
Can someone confirm that I understand this correctly?

For the 860c I need to flash a bin file to the display and a hex one to the motor.
For a Tongsheng display I need to compile a hex from the configurator, and flash it to the motor only?

With the Tongsheng display the process is reversible, and just flashing the motor with the original hex will revert to factory?

Yes this is correct, except that the configurator for stock displays also flashes the fw to the motor, so you don't need to do it manually.
 
Mr.Flibble said:
...
With the Tongsheng display the process is reversible, and just flashing the motor with the original hex will revert to factory?
Remember that the hex files to save the original firmware with ST-Visual-Programmer are 3, one for each Tab, PROGRAM MEMORY, DATA MEMORY and OPTION BYTE.
 
AZUR said:
This problem is especially important when riding mountain trails, where due to the difficulties of the paths, with many obstacles, we have to stop pedaling and press the pedal again to start pedaling a few tenths of a second later.

If the engine does not respond immediately, we can fall to the ground.



[/b]

yes, that is the main problem.
it's better with the new software. the re-turning is unfortunately still available.

mfg michael
 
Back
Top