New "TSDZ2 Torque Sensor Central Motor"

[casainho]

I agree most people would want to keep the wheel sensor, but I doubt I'd be the only person who'd want to remove it. I've seen lots of other people who want to minimize wires and clutter -- some going so far as to hide the display in the motor.

Casainho, if I decide I want this, I wouldn't ask you to implement it, I'd do it.

I see.

Even if you implement that, the issue me is that I think will be hard for users understand some part of the system that will behave very different when we would disable the wheel speed sensor. I think it would bring complexity to the system to have both options and the system would have very different behavior in some parts and would be hard for users to understand/debug -- probably would bring frustration.

 

[Ron Paul's Blimp]

I think I can address those valid concerns. I just found the other thread that's specifically about the open source firmware. I'll chat with you more about it over there if I decide to do this..

 

[andyme]

I think I can address those valid concerns. I just found the other thread that's specifically about the open source firmware. I'll chat with you more about it over there if I decide to do this..

Ok, so just for my understanding: "if i decide to do this" .... are you talking about something that you are doing for yourself or (why) would this have implications on everyone here?

 

[Ron Paul's Blimp]

Ok, so just for my understanding: "if i decide to do this" .... are you talking about something that you are doing for yourself or (why) would this have implications on everyone here?

I'm not sure if I follow the question. I'd do it because I want to use the feature myself, but I'd also expect that some other people might like it too. And I'd want to implement it in a way that addresses Casainho's concerns, because I'd want them to be willing to merge my changes (because I'd like to be able to enjoy both my own feature and also future updates that happen to Casainho's tree, without needing to backport them to my own fork).

 

[casainho]

Ok, so just for my understanding: "if i decide to do this" .... are you talking about something that you are doing for yourself or (why) would this have implications on everyone here?

I'm not sure if I follow the question. I'd do it because I want to use the feature myself, but I'd also expect that some other people might like it too. And I'd want to implement it in a way that addresses Casainho's concerns, because I'd want them to be willing to merge my changes (because I'd like to be able to enjoy both my own feature and also future updates that happen to Casainho's tree, without needing to backport them to my own fork).

I understand why you value to have your changes merge/added to the main firmware.

A quick and easy decision would be no, not taking your changes, but if you do it well and are available to maintain it, I think they should be merged.

I am reluctant because: one big feature missing on firmware is the walk assist :-( -- but we need a good walk assist and not the regular 6km/h walk assist mode of the original firmware that follows the max walk assist law value and not the users real needs. We need much lower speed for walk assist like 3km/h wen walking on step mountains (and a way to quick change that value on LCD3), as 6km/h is to fast and would be dangerous on that situation. Also different users like kids or someone that can't walk fast due to physical limitations, can't walk at 6km/h but maybe at 3 or 4 km/h. We need a kind of complex assist level implementation because wheel sensor measurement limitations/timing delays, but wheel sensor is a must for that. And bringing that complex code is my priority, I really need walk assist at 3km/h for myself and family when we are on hills -- this is also the need for much users, we had being discussing this on the other thread.

 

[andyme]

Ok, so just for my understanding: "if i decide to do this" .... are you talking about something that you are doing for yourself or (why) would this have implications on everyone here?

I'm not sure if I follow the question. I'd do it because I want to use the feature myself, but I'd also expect that some other people might like it too. And I'd want to implement it in a way that addresses Casainho's concerns, because I'd want them to be willing to merge my changes (because I'd like to be able to enjoy both my own feature and also future updates that happen to Casainho's tree, without needing to backport them to my own fork).

I understand why you value to have your changes merge/added to the main firmware.

A quick and easy decision would be no, not taking your changes, but if you do it well and are available to maintain it, I think they should be merged.


We need a kind of complex assist level implementation because wheel sensor measurement limitations/timing delays, but wheel sensor is a must for that. And bringing that complex code is my priority, I really need walk assist at 3km/h for myself and family when we are on hills -- this is also the need for much users, we had being discussing this on the other thread.

You mean: if it was not for walk assist, you would be willing to abandon speed info? can't be, no?

I think that if the firmware could be working in general without speed sensor, why not. but under no circumstances that should lead to give up the speed info altogether and leave people without the option to know at what speed they are riding...

 

[shaddi]

Motor without a display would be nice. The current problem is that the configuration is not split up in a persistent and a runtime-part. I opened a ticket for that on github and trying to implement it by myself. But i have not much spare time and the code is complex -> https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/30

 

[Ron Paul's Blimp]

You mean: if it was not for walk assist, you would be willing to abandon speed info? can't be, no?

I think that if the firmware could be working in general without speed sensor, why not. but under no circumstances that should lead to give up the speed info altogether and leave people without the option to know at what speed they are riding...

Yeah we're definitely not gonna do that. If I do it (I still haven't decided), it'll be an option. By default if someone doesn't have a sensor, I'd like them to get an error (as I assume they do now), because I wouldn't want someone having a faulty sensor resulting in them unknowingly enabling this new sensorless mode. Running without a sensor would require someone to explicitly choose it, probably at flashing time.

 

[b_vital]

You mean: if it was not for walk assist, you would be willing to abandon speed info? can't be, no?

I think that if the firmware could be working in general without speed sensor, why not. but under no circumstances that should lead to give up the speed info altogether and leave people without the option to know at what speed they are riding...

Yeah we're definitely not gonna do that. If I do it (I still haven't decided), it'll be an option. By default if someone doesn't have a sensor, I'd like them to get an error (as I assume they do now), because I wouldn't want someone having a faulty sensor resulting in them unknowingly enabling this new sensorless mode. Running without a sensor would require someone to explicitly choose it, probably at flashing time.

I need sensorless mode too. But I am against selecting mode at flashing time. A sensor may fail during ride.

 

[andyme]

quiz: where are my batteries and do i live in a warm or in a cold area...

Since I am tall i was able to fiddle 9 batteries into the seatpost tube and the other 17 batteries of my 13s2p pack are in the other fat tube....

normally that is enough for regular downtown rides. i added a flat 1p battery to the rear carrier, so it makes 3p and is altogether not really noticeable under normal circumstances.
and what you see here in the rear is a 3p pack, so that i can get up to 6p in total when needed.

 

[crun]

Motor without a display would be nice. The current problem is that the configuration is not split up in a persistent and a runtime-part. I opened a ticket for that on github and trying to implement it by myself. But i have not much spare time and the code is complex -> https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/30

I think that working with the stock XH18 would be very beneficial*, which has very much the same requirement: you can config the motor eeprom using LCD3/Phone/PC/STLink+default-eeprom-hex-files, then it will run with stock XH18 (or in your case no display), and only needs to get the assist level from the display.

* It opens up the project to wider use as no custom hardware modifications are needed. (e.g. I would be happy to help re-flash motors, but I'm really not going to get into modifying a bunch of displays for people. )
* It saves a reasonable amount of money: a display,cable, and dhl cost me ~ 1/3 the cost of the motor+xh18 , even purchased together.
* The limited function (only change assist level) is better for most members of my family

 

[andyme]

Motor without a display would be nice. The current problem is that the configuration is not split up in a persistent and a runtime-part. I opened a ticket for that on github and trying to implement it by myself. But i have not much spare time and the code is complex -> https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/30

I think that working with the stock XH18 should be a high priority, which has very much the same requirement: you can config the motor eeprom using LCD3/Phone/PC/STLink+default-eeprom-hex-files, then it will run with stock XH18 (or in your case no display), and only needs to get the assist level from the display.

working with XH18 is not even a low prioritiy. casainho has already clearly pointed out that he is not going to go for that and he is currently working on porting from LCD3 to 850C.

I think we as "users" must put ourselves more into his shoes in order to see how comments like this one may influece his future acting: He had the concept for the open source firmware and he invited others to follow him on this path and to contribute.
But we must not forget one thing: He is the captain of this ship and the main direction comes from him. I am sure that he feels a certain responsibility towards the members of the group as they embark on this project, void their warranties, invest time and material. But this will only work as long the main line is being maintained. I think, if someone wants XH18 to be the display, this can become his project and he should open a new thread. there are too many new ideas lately and i am afraid casainho will lose interest in sharing his project with others and at the end of the day we are all going to loose out.

So I want to suggest that we accept and see the main direction of the project and that our contributions are not in opposition to this direction. If not we are endangering the project alltogether.

My analysis of the situation: everyone is free to suggest what he perceives as useful features and improvements and if casainho finds them interesting for himself he will think of incorporating them. And if he is not interested, but they do not harm the overall progress of the project, he will not mind someone writing the code and integrate it.

I think that is what should be kept in mind in order to keep this alive, constructive and productive.

 

[gaber]

working with XH18 is not even a low prioritiy. casainho has already clearly pointed out that he is not going to go for that and he is currently working on porting from LCD3 to 850C.

I think we as "users" must put ourselves more into his shoes in order to see how comments like this one may influece his future acting: He had the concept for the open source firmware and he invited others to follow him on this path and to contribute.
But we must not forget one thing: He is the captain of this ship and the main direction comes from him. I am sure that he feels a certain responsibility towards the members of the group as they embark on this project, void their warranties, invest time and material. But this will only work as long the main line is being maintained. I think, if someone wants XH18 to be the display, this can become his project and he should open a new thread. there are too many new ideas lately and i am afraid casainho will lose interest in sharing his project with others and at the end of the day we are all going to loose out.

So I want to suggest that we accept and see the main direction of the project and that our contributions are not in opposition to this direction. If not we are endangering the project alltogether.

My analysis of the situation: everyone is free to suggest what he perceives as useful features and improvements and if casainho finds them interesting for himself he will think of incorporating them. And if he is not interested, but they do not harm the overall progress of the project, he will not mind someone writing the code and integrate it.

I think that is what should be kept in mind in order to keep this alive, constructive and productive.

Hear hear!

 

[Rydon]

DIY EX1 to adjust chainline

I've been using a Sunrace 11-42 10 speed cassette with the standard 42t chainring supplied with the TSDZ2. Chainline in first gear is not great but it works. However, the gearing is still too high for serious MTB use or towing a trailer offroad (I do a lot of wild camping).

So I decided to install a hope 34t front chainring. This move the chainline out by about 7 mm and I was concerned about snapping the chain under load. I made an 8 speed cassette with 10 speed gear spacing using three cassettes I had in my workshop. The sprockets are :-

42, 36, 32 - from my sunrace 10 speed cassete.
28, 22 from a sunrace 8 speed wide range cassette
17, 13, 11 from a shimano slx 10 speed cassette

To move the whole cassett outboard I added spacers between the cassette and the rear of the freehub and used 1 x 10 spacer plus a sprocket carrier from another. This has moved the cassette outboard by approx 10.5 mm.

Gear shifter is a 10 speed XT, rear derailer is a 10 speed XT with Goatlink. I've had to file the arm where the cable connects to the derailure as the chain rubbed this when changing down from 1st to 2nd.

Shifting is great apart from a delay in shifting from the 17t to 13t. I can get it working better by adjusting the B-tension, but then the derailure hits the 42t when going into 1st. I'm presuming it's because I'm using a derailure designed for 36t max, so I'll order an 11 speed derailure which can handle up to 46t (these do work with 10s speed) or a 10-speed one which can handle 42 teeth.

Thought I'd share this as an option for resolving chain line issues.

Great post. Thanks Bartman! I see you are using a goatlink with the XT Shadow+ derailleur. You should be able to make this work up to 42T. Why are you mixing 8 speed and 10 speed sprockets? The spacing is different. Can't you just take a few cogs out of the Sunrace 11-42 10 speed cassette? Also, have you thought about spacing out the derailleur from the derailleur hangar and maxing out the hi limit so the XT derailleur travels to the max sprocket diameter with 2 less cogs? Chainline is a huge issue. Interested to hear how this turns out!

 

[angusinalberta]

crun said:

I think that working with the stock XH18 would be very beneficial*, which has very much the same requirement: you can config the motor eeprom using LCD3/Phone/PC/STLink+default-eeprom-hex-files, then it will run with stock XH18 (or in your case no display), and only needs to get the assist level from the display

I'm with Shaddy and Crun on this. In a word - "just set and forget".

We'd have the benefits of two worlds, the elegance and transparency of the stock UI combined with Casainho's improvements to efficiency and smoothness of the motor itself. Everything else on the display is just clutter.

I'm not pushing Casainho for this. There's been too much pressure already on him from those who demand silly baubles or fixes to non-existent problems. The resulting code reflects the complexity of trying to reconcile it all.

Hopefully some of the coders out there will take up the challenge.

 

[Bartman]

DIY EX1 to adjust chainline

I've been using a Sunrace 11-42 10 speed cassette with the standard 42t chainring supplied with the TSDZ2. Chainline in first gear is not great but it works. However, the gearing is still too high for serious MTB use or towing a trailer offroad (I do a lot of wild camping).

So I decided to install a hope 34t front chainring. This move the chainline out by about 7 mm and I was concerned about snapping the chain under load. I made an 8 speed cassette with 10 speed gear spacing using three cassettes I had in my workshop. The sprockets are :-

42, 36, 32 - from my sunrace 10 speed cassete.
28, 22 from a sunrace 8 speed wide range cassette
17, 13, 11 from a shimano slx 10 speed cassette

To move the whole cassett outboard I added spacers between the cassette and the rear of the freehub and used 1 x 10 spacer plus a sprocket carrier from another. This has moved the cassette outboard by approx 10.5 mm.

Gear shifter is a 10 speed XT, rear derailer is a 10 speed XT with Goatlink. I've had to file the arm where the cable connects to the derailure as the chain rubbed this when changing down from 1st to 2nd.

Shifting is great apart from a delay in shifting from the 17t to 13t. I can get it working better by adjusting the B-tension, but then the derailure hits the 42t when going into 1st. I'm presuming it's because I'm using a derailure designed for 36t max, so I'll order an 11 speed derailure which can handle up to 46t (these do work with 10s speed) or a 10-speed one which can handle 42 teeth.

Thought I'd share this as an option for resolving chain line issues.

Great post. Thanks Bartman! I see you are using a goatlink with the XT Shadow+ derailleur. You should be able to make this work up to 42T. Why are you mixing 8 speed and 10 speed sprockets? The spacing is different. Can't you just take a few cogs out of the Sunrace 11-42 10 speed cassette? Also, have you thought about spacing out the derailleur from the derailleur hangar and maxing out the hi limit so the XT derailleur travels to the max sprocket diameter with 2 less cogs? Chainline is a huge issue. Interested to hear how this turns out!

I’m using 8 speed sprockets because that’s what I had and the ratios work. The spacers between sprockets are all 10 speed so no problem there. The sunrace cassetes has the sprockets on spiders and you can’t separate them, unfortunately. I have thought about moving the derailure out, but there’s a risk of stripping the threads using the existing Allen screw. Will be searching for a longer one. 11 speed desrikure has arrived, but no time to fit it yet.

 

[casainho]

Jbalat did a very good video on how to install the TSDZ2 motor temperature sensor. The video is clear and slow enough to see and learn details. Also, you will see Jbalat testing the motor and find that is easy to get motor over temperature when using the max power:

[youtube]Wb8Omk6e7GI[/youtube]

 

[casainho]

Current status on the Bafang 850C LCD, first test for the configuration menu:

[youtube]B5v-6loQ0t0[/youtube]

 

[andyme]

Current status on the Bafang 850C LCD, first test for the configuration menu:

Really cool...I have ordered mine a week ago from DHGate, they still were not able to verify my credit card.. No reaction to emails...better find a different source....

 

[Daught]

I read this thread a while ago and somewhere I saw mention that the KT-LCD3 will get damaged with the TSDZ2 52V using 14s. I cam't find those details again. What the solution?

 

[casainho]

I read this thread a while ago and somewhere I saw mention that the KT-LCD3 will get damaged with the TSDZ2 52V using 14s. I cam't find those details again. What the solution?

I have 2 ebikes with 14S/52V battery working perfectly with TSDZ2 and KT-LDC3.

By the way, Bafang 850C color LCD also works well on the same 14S/52V battery.

 

[mossboss]

I am setting up my TSDZ2 with a VLCD6, I was going for something inconspicuous and bare bones. I've had success specifying circumference and speed limit, but there is one last setting that confuses me: "Press the +assist, power, and -assist to enter the power select mode..."

First, what is the purpose of this function? Second, I can press two buttons at once, but three is challenging finger dexterity wise. Has anyone had success getting into this function?

 

[Daught]

I read this thread a while ago and somewhere I saw mention that the KT-LCD3 will get damaged with the TSDZ2 52V using 14s. I cam't find those details again. What the solution?

I have 2 ebikes with 14S/52V battery working perfectly with TSDZ2 and KT-LDC3.

By the way, Bafang 850C color LCD also works well on the same 14S/52V battery.

Which LCD3 did you order? Was it specifically for 60V or it's the regular 48V?

 

[casainho]

I read this thread a while ago and somewhere I saw mention that the KT-LCD3 will get damaged with the TSDZ2 52V using 14s. I cam't find those details again. What the solution?

I have 2 ebikes with 14S/52V battery working perfectly with TSDZ2 and KT-LDC3.

By the way, Bafang 850C color LCD also works well on the same 14S/52V battery.

Which LCD3 did you order? Was it specifically for 60V or it's the regular 48V?

It is the one for 24/36/48V. The same for Bafang 850C. Seems this LCDs also work well for up to at least 14S/52V batteries.

 

[watkinspd]

I'm in progress of switching my build over to the open source firmware and the KT-LCD3 display.
I'm searching for the pinout map for the 8 pin connector to the motor controller on the TSDZ2.
I've searched and found maps of wire colors against controller functions but the only way to use that is to cut the cable to expose the wires or disassemble my installed motor to map the wires to the pins using ohm meter. I'm trying to avoid that.
Has anyone got a mapping of the pins to wire colors or functions?