Tsdz2 firmware open source adapted to vlcd5, vlcd6 and xh18

[famichiki]

An ordinary cyclist doesn't even think about learning how a compiler works, nor does he start studying all the parameters.

Have you tried compiling for yourself? There is nothing required to learn, no parameters or settings, it's all automated and surprisingly simple. The scariest part is simply the word "compiler". However to try with Marcoq's you'll need to copy your generated config.h file as I mentioned in a previous post, since it's not designed to be used this way.

Just click a single file called compile_and_flash.bat and it's done.

Clicking the Compile and Program buttons in the configurator does the exact same thing but in a two-step process, separately calling compile.bat then flash.bat which are also part of the original OSF. Even the same command window progress is displayed.

As for editing the config file, it's just a list of options and you enter the value next to them the same as you enter into the configurator boxes. But as I mentioned, this could be improved further.

[Demion]

What can I say. Windows users like "user friendly" GUI apps with buttons and are scared off by batch files and text file manual edits.
Anyway it is not even in question to make or not configurator app, cause it is just few days of work. One day to code, one day to test.
I agree documentation is necessary. Although most options are from original open source firmware and are documented in wiki.
Also configurator should just edit config.h file and call compile_and_flash batch file so that both ways (manual and configurator) are possible and optional, as famichiki mentioned.

[obcd]

I doubt it's a wise idea to let people modify config parameters without knowing exactly what they do.
Some changes could easily fry your controller.
To avoid such, a configuration program that only allows to change the non harmfull things within their acceptable limits is a better solution.
Compiling the motor firmware is indeed easy. Compiling the firmware for the bafang displays is a bit more complicated. (Not relevant here I know.)
I also agree that the "error rate" increases with complexity. If things can be kept simple, they should be kept simple.

[Elinx]

It's always easy after someone thought about it and made it first. ,,,,,,,, With the gui of marcoq a cyclist with minimal effort programs the engine..... decide who the project is intended for, then everything is possible......

Think about it that marcoq also had a base to start with. Imho is there the fuzz about.
We as cyclists and user of his configurator are still grateful wat marcoq has done.
I really hope he will develop the Java configurator further.
But because this isn't complete clear it is not strange to think about alternatives.

I doubt it's a wise idea to let people modify config parameters without knowing exactly what they do.
Some changes could easily fry your controller. ..........

There is no difference if you write values into the java configurator or write direct into config.h.
Both have the same result, because the configurator made also a config.h file for compiling.
Ofcourse it is advisable to change default values that are already in the config.h as with the configurator too.
All is about the user friendliness presentation of config.h
You can use Notepad, html form, a script presenting the steps, java gui and mayby more is possible.
It is all about experience of the developer with these options.
Indeed important is simplicity for developer and user.

[stancecoke]

It's always easy after someone thought about it and made it first. For this reason it was not correct not to ask marcoq for anything.

Sorry, but marcoq didn't made the GUI first. He just took the GUI from the Kunteng project and edited some lines of the source code. All main functions are identical to the Kunteng GUI. Publishing his work without publishing the source code is a violation of the GNU license and the copyleft principle.



regards
stancecoke

[michih.]

Work the opensource Software for the new kt lcd4 Display? Maybe without cut the display like the sw102?

Mfg Michael

[Elinx]

Work the opensource Software for the new kt lcd4 Display? Maybe without cut the display .....

I doubt it.
This is only possible if the display have the same communication protocol with tsdz2 as the default diplays vlcd5-6, xh18.
For other OSF you have to flash the display too and that is only possible if the hardware of KT-lcd4 is exactly the same as KT-lcd3

[michih.]

Work the opensource Software for the new kt lcd4 Display? Maybe without cut the display .....

I doubt it.
This is only possible if the display have the same communication protocol with tsdz2 as the default diplays vlcd5-6, xh18.
For other OSF you have to flash the display too and that is only possible if the hardware of KT-lcd4 is exactly the same as KT-lcd3

Ok, at least kt lcd4 would be cheaper.


Mfg Michael

[Elinx]

.....at least kt lcd4 would be cheaper. ....

Not if you can't use it

[Demion]

Work the opensource Software for the new kt lcd4 Display? Maybe without cut the display like the sw102?

In limited way (assist level, battery level, speed, error code) can be ported to any display if protocol is known.
Maybe new lcd4 has same protocol as lcd3.
VLCD protocol - https://github.com/hurzhurz/tsdz2/blob/ ... ication.md
KT-LCD protocol - viewtopic.php?f=2&t=73471

[famichiki]

I have learnt that official Tong Sheng torque signal values are 50-105 when viewed using stock firmware on a VLCD5 display. I described how to access the service viewing menu in my previous post.

viewtopic.php?f=30&t=98281&start=600#p1518298

My readings with stock firmware are 98-190.

I do not know what these figures relate to, but they do not match any of Casainho's recommendations. His recommended torque sensor ADC range was 30-57, with a suggested resting value between 25-30.

But he has updated the wiki and it's no longer relevant for any v0.19 forks. You will need to refer to the previous version of the page here:

https://github.com/OpenSource-EBike-fir ... 4912a09f67

When you first switch on using OSF (original or Marcoq's) 16 samples are taken to determine a baseline minimum value. Then 6 is added to allow for any sensor instability.

So your starting reading should not matter as this becomes your zero point.

What is important is that you have enough resolution or range between your minimum and maximum torque readings.

However this maximum is not read from your sensor, but is hardcoded to be your minimum + 32 (Ackmaniac's fork uses a flat 255).

The minimum-maximum range is then normalised to fit a range of 0-255.

If your sensor has a smaller or larger range than 32, then you may experience problems.

For example:

Your torque range is 50-150, but your maximum will be actually be 82 (50 baseline + 32 hardcoded maximum) and any reading above is limited to 82.

You'd be missing all torque in the range of 83-150.

So you will have a sensitive torque sensor with very narrow range of torque of 50-82 (normalised to 0-255) where full power is achieved quickly so your motor appears to be overpowered.

Conversely:

If your torque range was 50-70, your maximum will still be 82 (50 baseline + 32 hardcoded maximum) even though you are unable to produce that much torque.

Your motor will appear to be underpowered as you can never reach the torque values above 70 (maximum achievable is 159 on the normalised 0-255 range).

[michih.]

Do not understand the problem with the torque sensor. When it starts up, it recalibrates. The factor can be easily set in the opensource. It doesn't matter whether it starts at 50 or 100 or 150?

Mfg Michael

[Elinx]

....When it starts up, it recalibrates. ...It doesn't matter whether it starts at 50 or 100 or 150....

Yes it recalibrates the "zero" without your foot on the pedal. But the range stays untouched.
With OSF you can change the torque support, but this isn't ideal if the zero and range is far from the expected values.

[michih.]

....When it starts up, it recalibrates. ...It doesn't matter whether it starts at 50 or 100 or 150....

Yes it recalibrates the "zero" without your foot on the pedal. But the range stays untouched.
With OSF you can change the torque support, but this isn't ideal if the zero and range is far from the expected values.

Ok thx, work this for kt LCD3 with the 0.20.0 Software?
Find nothing about it.

Mfg Michael

[marcoq]

Hello guys.
I have attached the source code of the TSDZ2 Configurator ver. 0.3.7.
Happy new year!

Regards.
marcoq

[cejean]

Thank you for sharing youre source code MarcoQ.

Enjoy youre holliday`s and hopefully you will contineu youre great work.

[famichiki]

I have attached the source code of the TSDZ2 Configurator ver. 0.3.7.
Happy new year!

Bravo Marcoq

[stancecoke]

I have attached the source code of the TSDZ2 Configurator ver. 0.3.7.

Thank you!

regards
stancecoke

[Elinx]

...........
I have attached the source code of the TSDZ2 Configurator ver. 0.3.7...............
marcoq

...................Thank you!.......
stancecoke

Glad that it is solved now.
My thanks to everybody who is contributing on the development of OSF for all TSDZ2 engines
Happy 2020

[famichiki]

Do not understand the problem with the torque sensor. When it starts up, it recalibrates. The factor can be easily set in the opensource. It doesn't matter whether it starts at 50 or 100 or 150?

Mfg Michael

I have a better understanding now and edited my previous post to explain the issues that can occur.

viewtopic.php?f=30&t=98281&p=1519375#p1519375

[Elinx]

.....
I have a better understanding now and edited my previous post to explain the issues that can occur...

What do you think. Is it possible that a hardware sensor calibration could help?
imho you can get a lower zero point, but the range you can't change.

[famichiki]

.....
I have a better understanding now and edited my previous post to explain the issues that can occur...

What do you think. Is it possible that a hardware sensor calibration could help?
imho you can get a lower zero point, but the range you can't change.

It's possible the range could change after physical calibration. The other thing you could try is measuring your maximum torque using Demion's firmware with VLCD5 or maybe Mbrusa's with other displays and then hardcode that value as your maximum.

[marcoq]

I have attached the source code of the TSDZ2 Configurator ver. 0.3.7.

Thank you!

regards
stancecoke

[chri27.5]

.....
I have a better understanding now and edited my previous post to explain the issues that can occur...

What do you think. Is it possible that a hardware sensor calibration could help?
imho you can get a lower zero point, but the range you can't change.

Hi Elinx,
I just made the calibration of the hardware sensor, thanks to Mbrusa I was able to read the ADC values, when empty it read 49.2 and 62.1 with the maximum force applied on the crank in a horizontal position, this calibration I did because having a reading field very narrow the engine had a bad performance, it could only be used in sport / turbo.
After calibration the no-load values ​​are 25.0 and 65.0 with maximum applied force.
I highly recommend you to calibrate it because after calibration the engine works perfectly, now I can use all 4 assistance levels without any problem

[chri27.5]

.....
I have a better understanding now and edited my previous post to explain the issues that can occur...

What do you think. Is it possible that a hardware sensor calibration could help?
imho you can get a lower zero point, but the range you can't change.

Hi Elinx,
I just made the calibration of the hardware sensor, thanks to Mbrusa I was able to read the ADC values, when empty it read 49.2 and 62.1 with the maximum force applied on the crank in a horizontal position, this calibration I did because having a reading field very narrow the engine had a bad performance, it could only be used in sport / turbo.
After calibration the no-load values ​​are 25.0 and 65.0 with maximum applied force.
I highly recommend you to calibrate it because after calibration the engine works perfectly, now I can use all 4 assistance levels without any problem