TSDZ2 open source firmware only for KT-LCD3 (v0.19.0 / v.0.20.0beta1)

[andrea_104kg]

The original post on the Casainho firmware for tsdz2 is now dedicated to the 850x color display version. Please post discussions about the lcd03 version here, to avoid confusion. Thank you

On suggest of famichiki user, I modified the title of the tread and add to this first post whit additional information (thanks):
Download the firmware here:
v0.20.0 beta 1
v0.19.0 stable

There is a manual for v0.20.0 with KT-LCD3
but the original TSDZ2 wiki mostly references the 850C color display now.

To follow ongoing development visit Casainho's original OSF thread and the TSDZ2-Smart-EBike GitHub repository.

Those with stock displays (VLCD5, VLCD6 & XH18) should see the OSF for VLCD 5 thread.

For general discussion of the Tongsheng TSDZ2 torque sensing motor please use this thread.

 

[mctubster]

The original post on the Casainho firmware for tsdz2 is now dedicated to the 850x color display version. Please post discussions about the lcd03 version here, to avoid confusion. Thank you

Great!

Even though I have an 850c and the equipment to flash I remain on the lcd03 since the .20beta code is far more feature complete and very stable.

What about we bring together a list of final small bugs to squash and release .20 final? I am not a C programmer but can likely fix the first one below.

1 - Measured voltage is too high. Likely due to a change buba made to improve the voltage measured but appears there is a constant that is wrong

 

[zappan]

Good, place the link where to find the latest stable version for the display LCD3 V0.20.0-beta.1 of Buba-Casainho

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.20.0-beta.1

 

[Waynemarlow]

There's some pretty good stuff in V20 and kudos to Buba, but do we not think we are jumping the gun a little, has anyone made contact with Buba to see what his actual intentions are, he's done a grand job so far ?

 

[Rydon]

I think Buba just needs to know that his work is appreciated and there are a lot of us that would like to see it go forward. If you have not reached out to him by PM, please do.

 

[mctubster]

I think Buba just needs to know that his work is appreciated and there are a lot of us that would like to see it go forward. If you have not reached out to him by PM, please do.

I tried 4 weeks ago. No reply. Sounds like he gets very busy from time to time.

Would be great to get a quick confirmation from him re which branch / label is in sync with the released binary but we should be able to work it out.

 

[famichiki]

I documented my problems with v0.19 motor overrun in another thread. Since then I've converted v0.20 to work with the VLCD5 (sorry I know this is the LCD3 thread but it's relevant!) and have been testing that for a week or so.

https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818&p=1522007#p1522007

Initially I had thought v0.20 improved the operation in this regard, but unfortunately it does not. Torque mode seemed like an improvement, the overrun only happened if you give the pedal a "stab" of high torque. Overall it is good and if I wasn't looking for it I probably wouldn't notice. Maybe that is normal? I'm not sure. But Power mode is the same as v0.19 with bad overrun which is most apparent at higher cadence and assist levels. I haven't checked the other modes yet but I suspect Cadence mode will be the same.

So far this doesn't seem tied to any particular sensor and is something to do with the motor power not being reduced properly after pedal input. It's possible it could be Cadence sensor related but I will do more testing and report back here.

 

[thineight]

Ciao Andrea and guys.
I think this thread should be named "for LCD3" without mention the release 19 or 20beta, because to date we have the .20 as latest stable release (anyone still on v19? Don't think so), but tomorrow it may be v.21.
The only true reason we are here on this thread is that we do not want to buy and install a replacement for the good old LCD3, that can show all the necessary information during a trip.
I am pretty sure that the new version from casainho is good and improves many things from v.19 (as v.20 does), but he moved forward to the new display and we have to respect that.

Welcome to all the active developers that still want to keep the lcd3 and fix some bugs or improve something within the memory limits.

I wrote a mail to Buba few days ago.. no answer so far, I believe he's very busy.

 

[famichiki]

Ciao Andrea and guys.
I think this thread should be named "for LCD3" without mention the release 19 or 20beta, because to date we have the .20 as latest stable release (anyone still on v19? Don't think so), but tomorrow it may be v.21.

It was previously but I suggested to include the version numbers because with all the current confusion people might be specifically looking for the version numbers right now. It can always be updated in the future.

Although v0.20 seems "stable" the name says it's beta and officially on Github it's tagged as a "pre-release" version.

 

[jbalat]

Subscribed...
Unfortunately I have no motivation to go for an 850c when the ktlcd3 is working fine.

if I ever buy another tsdz motor For a new bike I would certainly buy the 850c but at this stage I don’t think it’s worth it.

Where do we go from here ?
My suggestion is let’s document what we think needs fixing in version 20.. at this stage it’s working perfectly for me!

I am not concerned about the overrun as it seems my Bosch CX is just as bad in fact in some cases it has the opposite problem in that it will not give me any power for a few revolutions.

 

[famichiki]

I tested out eMTB mode and basic Cadence mode this afternoon.

eMTB seemed good for its purpose, but for general riding I preferred Torque mode. eMTB pulls hard from a standing start but then is more effort to maintain speed because the assist varies quickly with minor differences in pedal input.

Cadence mode was odd, I'm not sure if that was something to do with my conversion or not. It was very lacking in power and hard to get the bike moving even with full assist, plus it had massive overrun.. I presume that's to be expected for cadence-only systems. What are other people's experiences with this mode?

 

[devboy-greg]

I also have the LCD3 on two bikes, one running v0.19 & the other v0.20, it is great that there is still potential development for this screen. Thanks to all those making this happen.

I would like to draw attention to the motor runaway issue mentioned here and in a few other posts:

https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818&start=4325#p1522064

...has the problem been isolated, can it be patched?

I know Casainho says that it is fixed in his version v0.51, could this fix be brought to the LCD3? Casainho implemented a new protocol to handle communication between the display and the motor in his latest software and maybe this is how the fix has been implemented.

I personally have never experienced the issue, but I ride enduro bikes and if it happened it could lead to a serious injury, especially as the brake cut-offs won’t even kill the motor.

 

[mctubster]

I also have the LCD3 on two bikes, one running v0.19 & the other v0.20, it is great that there is still potential development for this screen. Thanks to all those making this happen.

I would like to draw attention to the motor runaway issue mentioned here and in a few other posts:

https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818&start=4325#p1522064

...has the problem been isolated, can it be patched?

I know Casainho says that it is fixed in his version v0.51, could this fix be brought to the LCD3? Casainho implemented a new protocol to handle communication between the display and the motor in his latest software and maybe this is how the fix has been implemented.

I personally have never experienced the issue, but I ride enduro bikes and if it happened it could lead to a serious injury, especially as the brake cut-offs won’t even kill the motor.

Have never had this issue running .20, in fact never had it running .19 either with lcd3 display. Looks more like a new bug with the new displays?

 

[famichiki]

I would like to draw attention to the motor runaway issue mentioned here and in a few other posts:

A few people including myself mentioned that in the VLCD5 thread, here is one post.. I haven't had it happen in a while now.
https://endless-sphere.com/forums/viewtopic.php?f=30&t=98281&start=400#p1500159

 

[Waynemarlow]

Personally I’ve only ever run V20 with the LCD3 and factory default with the VLCD5 early on. On neither have I had any experience of over run. Watching the various threads on the motor, the over run issue seems to be mainly on those using the Marcoq version of using V19 on the VCLD5 screen.

For the moment I want to continue with the LCD3 for one main reason, it’s sunlight readable. From previous experience of using an Iphone for navigation, the colour screens are not great in sunlight.

About the only gripe I have with the V20 version is moving between the display fields, I really struggle to time the short click long click to move between fields.

 

[famichiki]

Following on from a few posts back, has anyone done the cadence sensor calibration and tried running advanced cadence mode?

 

[mctubster]

Following on from a few posts back, has anyone done the cadence sensor calibration and tried running advanced cadence mode?

I have but no idea what it actually did. Maybe faster to respond to stop/start?

 

[thineight]

Following on from a few posts back, has anyone done the cadence sensor calibration and tried running advanced cadence mode?

I have but no idea what it actually did. Maybe faster to respond to stop/start?

Yes the intention behind that calibration was to instruct the motor to recognize also the "valleys" in the cadence magnetic field variation rather than the "peaks" only. In such way Buba said it was possible to double the resolution and therefore making the motor startup and stop quicker than the standard setup.

 

[jbalat]

Did you see that Ackmaniac did something to take into account the cadence for less overrun
Maybe have a look at that and see if its also worth incorporating

 

[famichiki]

Did you see that Ackmaniac did something to take into account the cadence for less overrun
Maybe have a look at that and see if its also worth incorporating

I similarly modified his fork and was running that as my go-to version for a while and it helped a lot.

However, I think I've diagnosed the overrun in v0.20 and am working on a solution.

 

[thineight]

Did you see that Ackmaniac did something to take into account the cadence for less overrun
Maybe have a look at that and see if its also worth incorporating

I similarly modified his fork and was running that as my go-to version for a while and it helped a lot.

However, I think I've diagnosed the overrun in v0.20 and am working on a solution.

Good stuff. Are you in touch with mbrusa? He's doing the same porting and I hope you can speak to each other to get the maximum benefit with a single source code.

 

[Rydon]

Did you see that Ackmaniac did something to take into account the cadence for less overrun
Maybe have a look at that and see if its also worth incorporating

I similarly modified his fork and was running that as my go-to version for a while and it helped a lot.

However, I think I've diagnosed the overrun in v0.20 and am working on a solution.

Good stuff. Are you in touch with mbrusa? He's doing the same porting and I hope you can speak to each other to get the maximum benefit with a single source code.

Awesome news to see the V20 code brought forward on stock displays. At one time I heard that the javascript config app also let you pick KT-LCD3 as the display. Is this still the case?

 

[mctubster]

Did you see that Ackmaniac did something to take into account the cadence for less overrun
Maybe have a look at that and see if its also worth incorporating

I similarly modified his fork and was running that as my go-to version for a while and it helped a lot.

However, I think I've diagnosed the overrun in v0.20 and am working on a solution.

Good stuff. Are you in touch with mbrusa? He's doing the same porting and I hope you can speak to each other to get the maximum benefit with a single source code.

Awesome news to see the V20 code brought forward on stock displays. At one time I heard that the javascript config app also let you pick KT-LCD3 as the display. Is this still the case?

I'm not that familiar with github, please correct if wrong ... can we have a single identified fork to work off or should a new repo be created? I've moved back home after a year OS, plan to get my dev environment up again Monday and will try a build of .20beta to check the binaries are identical before looking at the over voltage reading. I have a coulomb meter inline now with the battery - also checking out the state of charge code (seems to over read consumption under higher load) also with the aim to drive the battery meter from SOC rather than just the battery voltage which is not very useful.

 

[jbalat]

Anyone seen the latest changes on the 850c version. Looks like a change from using battery current to motor current could be a good thing ? Is it worth doing a source compare and copying out the code for this ?

Btw has anyone used 15s with the lcd3 ? Is it reliable ?

 

[mctubster]

Anyone seen the latest changes on the 850c version. Looks like a change from using battery current to motor current could be a good thing ? Is it worth doing a source compare and copying out the code for this ?

Btw has anyone used 15s with the lcd3 ? Is it reliable ?

Hard to know, some empirical testing could go a long way. I have an 850c, just have to solder up the board to flash. Potentially a different (faster?) feedback loop. The 850c code is still missing the polish of the LCD3, lots of missing bits, odo, soc, light flashing and so on.