Doe's the B02N (EKD01) display male cable connector have all 6 pins showing as I like to use brake sensors, so I normally shave back the outer sheath and pick out the purple and black wires and graft in a pair of cables with connectors for plugging in brake sensors.
TSDZ2 OSF for all displays, VLCD5-VLCD6-XH18, LCD3, 860C-850C-SW102.
- Thread starter mbrusa
- Start date
Just a quick data point….
I have TSDZ2B on my Trek Dual Sport for three years and 3000 miles. I’m running early version of OSF that has bug with trip distance resetting once in a while and motor temp graph showing twice value. I have added motor temp sensor and I modified motor cover to allow air flow for cooling. I ride only in dry weather. I make many rides at +30 miles range. I love this motor, OSF software, and 860C color display. Very natural and smooth power addition…
I have TSDZ2B on my Trek Dual Sport for three years and 3000 miles. I’m running early version of OSF that has bug with trip distance resetting once in a while and motor temp graph showing twice value. I have added motor temp sensor and I modified motor cover to allow air flow for cooling. I ride only in dry weather. I make many rides at +30 miles range. I love this motor, OSF software, and 860C color display. Very natural and smooth power addition…
Attachments
Great.
The temperature graph bug is already fixed in the current version, while the random trip reset will be fixed in the next version.
It's ready, but I need to update the manual before releasing it.
I am running the TSDZ2 OSF on the bike in the photo with a muck shield in front of the drive and have not had any problems with overheating, perhaps it may be because I am 75% of the time on the flat and 25% hill climbing, this is a 36v combo but it also applies to my 48v combo on my other bike. I do like the alternative idea for cooling which makes one think is there another way, I am into to high power computer so water cooling come to mind.
Attachments
The problem of losing pedal assist has already been reported by other users. It is not frequent, it only happens under certain conditions.
It happened to me twice last year and once this summer.
I think I have identified the cause and solved the problem.
It will be in the next update.
Great! Thank you. I’ll make sure I’m ready to flash when you have the update ready. Let me know if you need a beta tester.
Now wondering why I never experienced this in 2,000 miles until recently, like the last couple months. Maybe I changed a setting that makes it more likely to run into… ah, middle-aged memory.
In the mean time, is there a particular exacerbating corner case that I should try to avoid?
Last edited:
Hi Mbrusa
Some really cool software here , thankyou .
I have several tsdz2/b motors attached to Marin mountain bike frames
the configurability of OSF is very good but I wondered if you could add an " overrun" feature .
Already using minimum deceleration 2% ( sort of works a bit )
Some really cool software here , thankyou .
I have several tsdz2/b motors attached to Marin mountain bike frames
the configurability of OSF is very good but I wondered if you could add an " overrun" feature .
Already using minimum deceleration 2% ( sort of works a bit )
Last edited:
If my guess is correct, there is a way to avoid this problem.
When you stop pedaling, wait until the motor is at zero rpm before you start pedaling again.
How many times has this happened to you in the last two months?
I'm glad to hear that there is someone, besides me, who appreciates a long deceleration. I have it set to 0%.
I don't know if anyone has noticed, but I have already increased the deceleration time.
Do you think it should be even longer?
I have KT LCD3 TSDZ2 V20.1C.4-2 OSF . Just searched my manual for "deceleration" but it was not found. Is it called something else or is it a feature not available in my version?
If overrun mean that motor keep running after stop pedaling. It happens to me on every day when I'm bicycling. It usually do not start immediately. Maybe TSDZ2B get warm and then it will begin. It also includes a banging sound. It seems to me that the reason is the big gear. I think TSDZ2 had better big gear than TSDZ2B. TSDZ2B big gear is too complex and fault-prone.
is it easy to make the deceleration ( overrun ) a bit longer ? . Really useful when using the tsdz2 on mountain trails
It is true that a long deceleration time (overrun) improves the use on mountain trails, but it also has some contraindications and above all it requires greater attention when changing gear.
To increase overrun, in addition to setting "Motor deceleration" to zero, the value of PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_DEFAULT must be increased. I will try to do so.
I will also have to try to decrease the minimum overrun, there are also requests in the opposite direction.
A clarification, the deceleration time, with the same setting of "Motor deceleration", is not constant, but depends on the pwm duty cycle, the cadence and the motor rpm.
I checked, the manual has not been updated.
The item 10.9 is not "Min current ADC step" but:
10.9 - "Motor deceleration adjustment".
If set to zero, the maximum deceleration ramp is active, if set to 100%, the minimum deceleration ramp is active (quicker stop).
Thanks for checking. Now I will have to go play with 10.9- "motor deceleration adjustment" to see what it does in actual riding.
so, just to get i right, flashing to the motor can be done on linux using the java configurator just like on windows?
i just made my way through the manual and wiki and got quite confused by the improvements IArchi made: Compile and flash automatically from Linux and Mac OS by IArchi · Pull Request #44 · emmebrusa/TSDZ2-Smart-EBike-1
Yes exactly, in Linux the Java configurator can be used as in Windows.
I tried with Ubuntu, it is necessary to install xterm (sudo apt install xterm).
I adopted the IArchie proposal even if it did not work automatically for me.
There was also another proposal for MacOS systems
Configurator UI and error handling improvements by ec-bikes · Pull Request #92 · emmebrusa/TSDZ2-Smart-EBike-1
I did not adopt it because it did not work in Linux and it was not possible to investigate further.
However, I understood that to work automatically in Linux a terminal emulator was needed to show the compilation output, hence the choice to use xterm.
i apologize for asking dumb questions but how do i get the VLCD12 to fully work with the my tsdz2B? as of now, the VLCD12 refuses to display correct battery %.
i was able to hook the STLink cable to my motor. which Display Type should i select? i dont see VLCD12 as an option.
i believe this Java tool is only for the motor controller's firmware, correct?
do i also need to hack the VLCD12's fw? if so, what program do i need and where would i find the fw for that?
Thanks everyone.
i was able to hook the STLink cable to my motor. which Display Type should i select? i dont see VLCD12 as an option.
i believe this Java tool is only for the motor controller's firmware, correct?
do i also need to hack the VLCD12's fw? if so, what program do i need and where would i find the fw for that?
Thanks everyone.
This tool was made for the 3 older Tsdz2 display's, later on there a lot more display types. Mostly they all work, because they communicate with the controller, but some small things aren't. 850C is later added.
If it is only a battery bar problem, you can solve this partly, with "advanced settings" by changing the Voltage value for each bar.
Choose vlcd5 (6 bars) if you have 5 bars.
You only need to flash the controller.
rivers
1 W
There's a new SW-M58 display with versions for both Bafang and TSDZ2B motors. Has anybody tried one and will it work with the embrusa OSF.
Because the Tsdz2b version of the SWM58 does work with stock Tongsheng FW, imho this will be a reason it does too with OSF Java version. Maybe some minor things aren't.
Last edited:
Just an update. I decided to try flashing both my motor (TSDZ2) and display (860C) to V20.1C.5 in the github repo. While the motor flashed fine, the display did not.
After the display finished flashing it will not turn on. I tried all the variants of the display bin files, including older versions... no luck. It will happily take a flash, but just won't turn on either with the APT flash tool attached or re-connected to the motor. Strange that just the display doesn't turn on, but it will accept a flash upload.
Now, possibly this is my own doing. Initially I had plugged my APT flash tool into the second connector on the display while the first connector was still connected to the motor (with bike battery disconnected). Secondarily, once I figured out I had the wrong connector in my wiring harness (argh!), I got the flash utility working and successfully flashed, but chose the 850C file instead of the 860C file, thinking I didn't want the bootloader but the core firmware. Apparently that was an incorrect assumption?
Subsequently flashing any of the 860C bin files do not result in a working display either. Possible I fried something with either of these initial mistakes, or just a coincidence?
Unless it's something simple, I'm thinking the display has fried itself, perhaps having nothing to do with my flashing efforts. It's had a lot of Arizona sun resulting in a delaminating glass screen (and it has a broken USB port), so it's not exactly a prime candidate for extraordinary measures.
That said, I'm sad to have gone from an intermittent eBike to a non-eBike in a flash (hah).
