TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

[buba]

Buba, one user told the throttle not working may be something about 0 cadence - this can make sense.

For debug, force motor PWM disable and override the throttle variable with a fixed value -- then do a debug to see where the code is forcing the motor output to zero when throttle > 0.

Will stand back as the same user said it actually does work on the beta 8. Luckily I did not have time to look for the bug so have not invested any time debugging. Waiting for another confirmation from the same user and if it is positive I think the stable 0.19.0 is a GO!

I wanted to implement that by myself, I mean, I was not asking for you to implement. But that is ok for sure, no problem. I just hope this goes to next version and not the stable version we are trying to release soon.

Yeah, this should preferably be released in the 0.20.0 so we can finally release the 0.19.0!

One important thing would be to make LCD3 startup even if there is no communications from the motor controller and show an error for that. That error would help the users that exchange by mistake the RX and TX wires as also the ones that keep brakes active without knowing it.
This is tricky in a way that the protection at startup for brake sensors active, for development protection, should be removed, I think. That is a risk we should take, I guess.

Also, do you think to add to LCD3, is there space for that??
I really like SW102 Bluetooth LCD, it seems to have enough memory to hold all this options on the LCD itself, not even counting with the mobile app.

Error codes are great and some issues happen frequently so it would be beneficial to have some code displayed so the user can look up what the problem is.

As I was finishing up the last betas I rewrote some parts on the KT-LCD3 so there is more space now. We can definitely add the enable/disable brake sensor code.

 

[buba]

Tried v0.18 today for the first time. I've noticed few things that are worse (out of the box) than on original firmware.

The 0.19.0 is soon to be released so as much as I appreciate feedback you should maybe try out that version when it is released.

1. LCD3 button clicks are really slow, you need to wait between each click otherwise it just ignores it.

This can maybe be improved slightly. There are a lot of functions in the KT-LCD3 that are not present in the original display. So one needs to be careful comparing the two displays for speed and simplicity.

2. Default Boost settings are too high. The first thing that was annoying me with the original software is that violent "jerking" on start, with default settings and OpenSource firmware it's even worse. Luckily, you can tune it down.

The only thing I can recommend for now is to change the default settings. We are in the process of making the calculation and feeling of the system much better. This will hopefully solve everything you mention and even work better than the original firmware. After making these changes it is very easy to adjust the default settings for more appropriate values.

3. When you stop pedaling motor continues to pull for a brief moment. This "delayed" time is present on both, OEM firmware and OSS, but it looks like it's a tiny bit longer on OSS.

As I said, this will hopefully be improved in the future versions. We are continually improving everything and hopefully this will be solved when we implement a better calculation for the human power. Our goal is to have it better than the original firmware.

4. I'm not sure if this is subjective or not, but I've noticed that with OSS, drop in power when cadence is rising comes sooner than with original firmware. Is this possible? In lower gear (3rd out of 8 on my Nexus) it's dropping fairly quickly to 300W on steep incline.

This depends on many parameters. But maybe one reason is due to the motor firmware implemented in the open source firmware. It is more advanced and operates in a different way. There is a chance that the top speed is slightly lower but this can be improved in the future with field weakening.

5. Tried cruise control a bit, and it looks like it's completely useless. It comes in, pulls you over the set speed than motor stops pulling. When it drops below the set speed it kicks in again with the boost and overshoots than stops. It's like a yoyo.

I presume you have the 36 V motor or some system voltage that was not used during development. It was recently brought to my attention that it does not operate optimal when not using the 48 V motor and a good 48 V battery. So this is something you need to try out more in the version 0.19.0 that will be released. In that version it is slightly adjusted and should work better with different setups and users. It is difficult to create one function that works for every situation. One of many things I have on my personal to-do is to optimize Cruise to be much better. But other things have more priority.

Hope this answered all of your concerns!

 

[bart594]

Hi

here is marcoq's take on emtb mode

...

To implement this we basically need 3 additional variables on LCD : min assist level, max assist level and max pedal cadence where motor riches max support
But for testing purposes for now all values could be hardcoded like 0.4-3 for min/max assist levels and pedal cadence = 95 and enable eMTB mode only if assist level factor is set up over factor 5
if(m_configuration_variables.ui8_assist_level_factor_x10 > 49) like in my original post

Have you tried the eMTB mode? And if so, I would like to hear what you think of it!

I have adapted it for our firmware on top of latest beta . I'm using LCD850 so i had to revert uart changes because they are not compatible with LCD850 code.
Support between 0.4-2.8 and max power on 105 rpm (i have 52v battery). I have changed a bit human power calculation too following your suggestions but i have no idea if they are now closer to real power level. Cruise mode mode constantly switches on and off so it's hard to see what power it applies as reference level for comparison
But eMTB mode feels really great and natural! If you pushing hard the motor give it back and if you just cruising you don't need to tone down assistance level. On more technical trails you probably not gonna need to juggle with assistance level that much too
I have cherry picked from marcoq soft start mode too but i haven't tested it extensively
I think eMTB mode with more resolution on the bottom end so you can apply power even more natural will make this motor really shine!

 

[buba]

Have you tried the eMTB mode? And if so, I would like to hear what you think of it!

I have adapted it for our firmware on top of latest beta . I'm using LCD850 so i had to revert uart changes because they are not compatible with LCD850 code.
Support between 0.4-2.8 and max power on 105 rpm (i have 52v battery). I have changed a bit human power calculation too following your suggestions but i have no idea if they are now closer to real power level. Cruise mode mode constantly switches on and off so it's hard to see what power it applies as reference level for comparison

Very nice work!

I understand it was, and is, rather difficult to set a constant speed and power on the fly. Meaning it is difficult to get meaningful data to confirm the human power. Especially if Cruise was not playing along. Cruise needs to better adjusted to cope with different bikes, voltages and setups. Maybe needs to be user settable for best performance.

Best way will be to force the duty cycle to some value that is somewhere near one of the ADC current threshold steps. And also have somewhat constant inclination so that the speed is constant. We will revisit this soon!

But eMTB mode feels really great and natural! If you pushing hard the motor give it back and if you just cruising you don't need to tone down assistance level. On more technical trails you probably not gonna need to juggle with assistance level that much too
I have cherry picked from marcoq soft start mode too but i haven't tested it extensively
I think eMTB mode with more resolution on the bottom end so you can apply power even more natural will make this motor really shine!

Very cool! I appreciate your comments and am looking forward to test it! It is funny you mention a higher resolution as this is exactly what I wish to improve. Will hopefully feel smoother and more responsive in all modes! The better we make the underlying control code the better eMTB and all other modes will be.

 

[jimmyfergus]

Flashed KT-LCD3 with the following commands on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -w KT-LCD3-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "KT-LCD3-v0.18.2.hex" is considered as INTEL HEX format!
32717 bytes at 0x8000... OK
Bytes written: 32717

Flashed TSDZ2 with LCD3 connected on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin
Determine OPT area
Due to its file extension (or lack thereof), "option_bytes_pwm_n_channels_enabled.bin" is considered as RAW BINARY format!
15 bytes at 0x4800... OK
Bytes written: 15

$ stm8flash -c stlinkv2 -p stm8s105?6 -w TSDZ2-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "TSDZ2-v0.18.2.hex" is considered as INTEL HEX format!
21233 bytes at 0x8000... OK
Bytes written: 21233

This is great info, thank you. I'm trying to take notes to contribute Linux flashing info to the wiki when I've finished. One thing though - it appears from the jbalatutube videos that partno (-p) field for the TSDZ should be stm8s105?4, not ?6 (?) - though by the sounds of it that didn't break anything for you.

Edit: I failed to notice on the wiki on flashing the TSDZ2 said to use the ?6 version, and it definitely works. So I'd trust that over the video.

 

[dameri]

I’m planning to install temperature sensor some day.

Is it enough to connect the cables from sensor to the controller. In 8 wire system temperature sensor is connected to green, orange and white wire and 6 wire system soldering direct to controller board.

There is no need to connect any wire to KT-LCD3?

 

[ashrambo]

I’m planning to install temperature sensor some day.

Is it enough to connect the cables from sensor to the controller. In 8 wire system temperature sensor is connected to green, orange and white wire and 6 wire system soldering direct to controller board.

There is no need to connect any wire to KT-LCD3?

Yes it is enough but you will lost the throttle option.

Enviado desde mi SM-G510 mediante Tapatalk

 

[dameri]

Ok, thanks. I don't need throttle, I use cruise if need in an emergency.

 

[perryscope]

I started working on the throttle issue reported from one of the betas in 0.19.0. I have already added wider range for the current acceleration, amps per second, as it was requested to be settable for values over 10 amps per second. And just implemented so that you can disable the brake sensor in the system. Will be included in the next pull request.

I can confirm that 0.19.0 beta 8 has now resolved the throttle issue I have had throughout 0.19.x! ( just for reference it was still there in 0.19.0 beta 7, so its something specific to beta 8 that resolved it.)

 

[buba]

I started working on the throttle issue reported from one of the betas in 0.19.0. I have already added wider range for the current acceleration, amps per second, as it was requested to be settable for values over 10 amps per second. And just implemented so that you can disable the brake sensor in the system. Will be included in the next pull request.

I can confirm that 0.19.0 beta 8 has now resolved the throttle issue I have had throughout 0.19.x! ( just for reference it was still there in 0.19.0 beta 7, so its something specific to beta 8 that resolved it.)

Thank you so much for clearing it out and for the comments! Great news!

We can now continue the development and there are exciting things to come! But first of all, lets release the stable 0.19.0!

Note, those of you who have installed the 0.19.0 beta 8 do not need to update to the stable release.

 

[buba]

0.19.0 is about to be released. Below is the entire changelog from version 0.18.X.

See the wiki for information regarding operation and configuration of the KT-LCD3 and the TSDZ2.

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X

Changelog
-----------------------
* Solved motor backwards resistance
* Rewritten button code for the entire system. Button logic for the user is still the same but faster and should be really solid. Much easier to adjust parameters and create new button events.
* Street Mode now with simpler logic of operation. Solved Offroad Mode settings have strange logic #90
* Possible to disable the throttle when in Street Mode.
* More space, less processing and better layout on the controller firmware.
* Overall changes in how the numbers are shown and so on. Better and more consistent experience throughout.
* Solved bug with the quick power config menu
* No blinking 1 error anymore. Same safety logic is still there and even safer! Also, the safety logic has actually even expanded to include all motor operations so it protects the motor controller, blue gear and motor in every possible use case/situation.
* New function has been created that replaces safe_tests(). The new function is called check_system.
* Firmware is also prepared for more error codes in the future as Casainho has given feedback about this.
* Slightly tuned the controller for the cruise function so it should work better for both motors.
* Solved unknown bug in the UART communication making it at at least two times faster.
* The UART communication has been cleaned up and is easier to change for future displays. Easier to add data for communication without changing a lot of parameters in several different places in the code.
* Overall clean up in the KT-LCD3 firmware and solved bugs.
* Corrected cadence value and human power
* Throttle now overrides torque sensor
* Improved BOOST code in the hope to solve a bug related to BOOST
* Added estimated range since power on depending on how much capacity is left
* Added option to set motor power limit in the configuration menu
* Added option to enable or disable motor power limit quick-set-menu
* Added two new main screen setup items
* More accurate watt-hour measurement
* More accurate time measurement
* Heavily optimized code size and speed
* Safer enable logic for Walk Assist and Cruise
* Added average wheel speed in temperature field
* More modular uart for future displays
* New button logic and completely new setup menu
* Solved unknown bug in UART communication making it at at least two times faster
* Tuned the controller for the cruise function so that is works okay for both motors
* New system safe test function
* Added a function that measures and calculates consumed watt-hours per traveled distance since power on
* Added a new sub field in the odometer field called Energy where user can see energy consumption and estimated range
* Merged previous configuration menu LCD Setup with configuration menu General Setup for better and faster setup
* Removed configuration menu LCD Setup
* Merged all battery setup menus to one
* Added option that enables user to enable or disable display of motor temperature in the odometer field
* Changed order in the Main Screen Setup menu in the configuration menu
* Changed order in the odometer field
* Improved pedal cadence calculation
* Updated README document
* Overall optimizations in regard to size and speed
* Cleaned up code and comments
* Created wiki that has been updated with all the changes
* And much more...

 

[jimmyfergus]

I climbed aboard the FOSS Firmware train yesterday (v19beta8) once I confirmed my system worked with factory firmware, and I'm very pleased. It gives me the bionic legs I was after, and should make my hot summer commutes much less sweaty.

I'm using it for urban transportation on my commuter bike with 3-speed hub; I changed cogs to raise my leg-power gearing +25%, and now I'm cadence-limited at ~25mph/40kph and with higher gearing could definitely cruise faster on the flat.

Q: Is there a project Patreon or equivalent for contributions? I would like to support the developers.

Flashing the motor with direct pin connection, as mctubster demonstrated is very easy. Getting that programming connection seemed a daunting step, but is actually very easy that way.

I may have misunderstood the LCD3 wiring instructions where it suggested buying a spare controller for connections. That hasn't helped me and I don't see how it would(?). As it is, I haven't needed any extras - just the LCD3 and TSDZ2. I have a spare controller now anyway, and I put the extra wheel magnet to use by installing two and halving my wheel circumference setting.

Initial observations:

I'm going to have to try the field weakening stuff, because it tails off much sooner than I would typically shift gears; I hadn't thought I was a particularly high-cadence rider...

With default settings, level 3 / 100% assist, I'm often pulling ~400W that feels quite intense. I can't help suspecting it over-estimates my power input. I'm likely to be adjusting the assist levels downwards. Initially I've been riding a lot at +100% for the novelty value, but it takes me through the gears and approaching the cadence limit in third very quickly with quite mild leg input.

The cadence metric seems over-smoothed, taking a very long time to catch up to reality. Perhaps that is a control input and deliberately done that way?

I have to add temperature and brake sensing soon. Keeping my feet off the pedals at the lights is a PITA, and I want to be confident I'm not overheating it.

 

[dameri]

I climbed aboard the FOSS Firmware train yesterday (v19beta8) once I confirmed my system worked with factory firmware, and I'm very pleased. It gives me the bionic legs I was after, and should make my hot summer commutes much less sweaty.

I'm using it for urban transportation on my commuter bike with 3-speed hub; I changed cogs to raise my leg-power gearing +25%, and now I'm cadence-limited at ~25mph/40kph and with higher gearing could definitely cruise faster on the flat.

Q: Is there a project Patreon or equivalent for contributions? I would like to support the developers.

Flashing the motor with direct pin connection, as mctubster demonstrated is very easy. Getting that programming connection seemed a daunting step, but is actually very easy that way.

I may have misunderstood the LCD3 wiring instructions where it suggested buying a spare controller for connections. That hasn't helped me and I don't see how it would(?). As it is, I haven't needed any extras - just the LCD3 and TSDZ2. I have a spare controller now anyway, and I put the extra wheel magnet to use by installing two and halving my wheel circumference setting.

Initial observations:

I'm going to have to try the field weakening stuff, because it tails off much sooner than I would typically shift gears; I hadn't thought I was a particularly high-cadence rider...

With default settings, level 3 / 100% assist, I'm often pulling ~400W that feels quite intense. I can't help suspecting it over-estimates my power input. I'm likely to be adjusting the assist levels downwards. Initially I've been riding a lot at +100% for the novelty value, but it takes me through the gears and approaching the cadence limit in third very quickly with quite mild leg input.

The cadence metric seems over-smoothed, taking a very long time to catch up to reality. Perhaps that is a control input and deliberately done that way?

I have to add temperature and brake sensing soon. Keeping my feet off the pedals at the lights is a PITA, and I want to be confident I'm not overheating it.

Look signature
https://endless-sphere.com/forums/memberlist.php?mode=viewprofile&u=18879https://endless-sphere.com/forums/memberlist.php?mode=viewprofile&u=18879

 

[buba]

I climbed aboard the FOSS Firmware train yesterday (v19beta8) once I confirmed my system worked with factory firmware, and I'm very pleased. It gives me the bionic legs I was after, and should make my hot summer commutes much less sweaty.

I'm using it for urban transportation on my commuter bike with 3-speed hub; I changed cogs to raise my leg-power gearing +25%, and now I'm cadence-limited at ~25mph/40kph and with higher gearing could definitely cruise faster on the flat.

Welcome aboard! Hope you like the 0.19.0 beta 8! It is by far the best version with many functions and features. But there is much more to come! :wink:

Q: Is there a project Patreon or equivalent for contributions? I would like to support the developers.

First of all, that is very nice of you!



Casainho
Endless Sphere and GitHub user Casainho created this amazing community and project. He is currently working on adding support for more displays.

GitHub account:
https://github.com/casainho

Casainhos paypal: casainho AT gmail.com

Developer of the Flexible OpenSource firmware for EBike motor controllers (TSDZ2 and KT) and LCDs (KT-LCD3 and Bafang 850C color LCD).

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.



Endless Cadence
User Endless Cadence, on Endless Sphere and GitHub, is another developer that helped out a lot in the beginning I think.

GitHub account:
https://github.com/endlesscadence



buba
My name is Leon, buba here at Endless Sphere and leon927 on GitHub. I have been an active developer since we wanted to improve the version 0.16.0. Started with some minor things and never stopped. If you have any bugs to report you are free to let me know.

GitHub account:
https://github.com/leon927

I have done this Pro Bono since I started. This is because I love the community and love to improve something hopefully many enjoy using. IF you feel something I have done has added significant value to your life and like the things I am planning to do I am very humbled that you want to contribute in some way. Thanks!

Will consider adding my PayPal account in the signature.



Others
All the contributors are found on the project page on GitHub at this link:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/graphs/contributors

 

[buba]

Initial observations:

I'm going to have to try the field weakening stuff, because it tails off much sooner than I would typically shift gears; I hadn't thought I was a particularly high-cadence rider...

Try the experimental modes in the Configuration Menu under 7. Motor Controller Setup and choose the appropriate experimental mode for the type of motor you have: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X#7_Motor_Controller_Setup

This might help a bit for now. But field weakening in the future will definitely increase the top speed.

With default settings, level 3 / 100% assist, I'm often pulling ~400W that feels quite intense. I can't help suspecting it over-estimates my power input. I'm likely to be adjusting the assist levels downwards. Initially I've been riding a lot at +100% for the novelty value, but it takes me through the gears and approaching the cadence limit in third very quickly with quite mild leg input.

The human power calculation is something that many users have reported being too optimistic and as you say over-estimating the true power. This is actually something actively worked on and will be improved in the next version. My development version I am using is already much better. Will write more about this when it is time.

The cadence metric seems over-smoothed, taking a very long time to catch up to reality. Perhaps that is a control input and deliberately done that way?

Same thing has been reported not long ago so it is clearly something that needs to be improved. Will be fixed for the next version!


-----------------------------------------


The overall goal is to make the system even smoother and more responsive together with some cool new functions. When we start discussing possible improvements for the next version you are free to give as much feedback as possible!

Reported issues and possible enhancements are listed on the project GitHub page. This will be updated soon, with many of the suggestions users have submitted the last couple of weeks. We are just waiting to release the stable version 0.19.0 and then switch focus on the next version.

Here is the project page and the issue list on GitHub:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues

 

[jimmyfergus]

Re: support, I sent Casainho a contribution. Hopefully it all evens out in the end. I don't know if the Gihub Sponsors feature could be useful. Having somewhere project-related to send money could be good, but then it does give you guys an adminstration / distribution headache to deal with.

Try the experimental modes in the Configuration Menu under 7. Motor Controller Setup

I definitely will try this today

The overall goal is to make the system even smoother and more responsive together with some cool new functions. When we start discussing possible improvements for the next version you are free to give as much feedback as possible!

Yeah, the primary function of natural-feeling torque multiplication is obviously key, and really all I care about. That's why I picked the TSDZ2 and the FOSS firmware. In an ideal world TongSheng would find a way to partner up with you guys. An off-the-shelf TSDZ2 with its weaker components upgraded a little, and the FOSS firmware, would be fantastic.

I'll be keeping track and poking around for ways I can contribute, even if it's only tending to the wiki a little.

Thanks for your efforts!

 

[casainho]

New stable version v0.19.0: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0

Thanks to everyone involved included the community!!

---

Buba, I plan a first working version of SW102 Bluetooth LCD in 4 weeks. I think is a good idea to try avoid change motor controller interface with the LCD and also write separately change logs.

On SW102, I did agree with Nick that I will implement the configurations menu and later the only thing missing will be to implement the main screen. I hope I can do this in next 4 weeks. I really thing everyone will like a lot the results that a matrix display gives, due to the flexibility over LCD3 fixed symbols. Also, there is more memory and that means we will be able to improve even more current interface with the users.

 

[buba]

Buba, I plan a first working version of SW102 Bluetooth LCD in 4 weeks. I think is a good idea to try avoid change motor controller interface with the LCD and also write separately change logs.

Cool! Going to freeze development on the UART to simplify your development. But have made it really modular so it should be easy to develop for the different displays!

Think I have solved human power, will validate and update as I have more information. Working on the torque sensor ADC and current resolution among other things.

Looks really nice and heavily optimized. Will soon Pull Request. Have made the foundation so it will be easy to implement eMTB Mode, Cadence-Only Mode, Workout Mode and so on...

On SW102, I did agree with Nick that I will implement the configurations menu and later the only thing missing will be to implement the main screen. I hope I can do this in next 4 weeks. I really thing everyone will like a lot the results that a matrix display gives, due to the flexibility over LCD3 fixed symbols. Also, there is more memory and that means we will be able to improve even more current interface with the users.

The new displays are the way forward. Will be a much better experience!

 

[dameri]

New stable version v0.19.0: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0

Thanks to everyone involved included the community!!

---

Buba, I plan a first working version of SW102 Bluetooth LCD in 4 weeks. I think is a good idea to try avoid change motor controller interface with the LCD and also write separately change logs.

On SW102, I did agree with Nick that I will implement the configurations menu and later the only thing missing will be to implement the main screen. I hope I can do this in next 4 weeks. I really thing everyone will like a lot the results that a matrix display gives, due to the flexibility over LCD3 fixed symbols. Also, there is more memory and that means we will be able to improve even more current interface with the users.

Is this: http://www.pswpower.com/ven.php?cargo.2018-cu-aacd SW102 Bluetooth LCD?

 

[casainho]

New stable version v0.19.0: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0

Thanks to everyone involved included the community!!

---

Buba, I plan a first working version of SW102 Bluetooth LCD in 4 weeks. I think is a good idea to try avoid change motor controller interface with the LCD and also write separately change logs.

On SW102, I did agree with Nick that I will implement the configurations menu and later the only thing missing will be to implement the main screen. I hope I can do this in next 4 weeks. I really thing everyone will like a lot the results that a matrix display gives, due to the flexibility over LCD3 fixed symbols. Also, there is more memory and that means we will be able to improve even more current interface with the users.

Is this: http://www.pswpower.com/ven.php?cargo.2018-cu-aacd SW102 Bluetooth LCD?

Yes it is. It is very easy to find on eBay, AliExpress, PSWPower, etc.

 

[jbalat]

Hi Buba, just wondering whether its possible to do any logging.

I know its been mentioned before but Im sure it can be done easily just not sure about the best interface.

The ulitmate would be logging to your phone via bluetooth.. eg. Cadence, human power, motor power, speed, etc If it were on your phone it would be easy to get a timestamp.

I know casino will prefer the bafang displays but I think one of the users already has an android app and bluetooth dongle on his motor, so just need to follow up on that.

My interest is purely for making mountain biking videos. Ive just come across a program called Dashware which lets you overlay telemetry on your video. I was able to get my gps data, speed, distance and heart rate onto the video off my fitbit watch !!!

http://www.dashware.net/

 

[jimmyfergus]

The experimental high cadence setting (48V motor) works just as well as I'd hoped, and I no longer have it die under me just before I want to change gear.

While I was exploring all the config options I enabled Boost, with default params, and I like it. I'd vote for having that enabled by default; it makes the whole thing feel more responsive. Overall the default assist and boost levels seem well chosen to me.

I'm astonished to find that when I thought I was using high assist in town stop/start with 20-25mph cruising speed, mostly on level 3, i got 15 miles (24km) on 0.9Wh, which means my little 52V 6Ah cube battery should be good for up to 45 miles / 70km. That's great! I'd hoped for 30 miles. To be fair my area is overall fairly flat with only short modest hills. I'm glad I went with the small 3lb battery, which is perfect for urban transportation, though I may yet want another to allow longer trips.

 

[daenny]

After having biked now more than 300km with the 0.19.0beta8 I am still very pleased with is . Some minor issues I have:
- Very occasionally I have a 2-3seconds lag in support. I cannot really pin down when it happens, seems mostly at very low force on the pedals
- The same as other users reported, at very low force, the motor still goes on-off. On 12s LiPo, it seems that it is around 50W support. As a temporary quick-fix I would like to be able to add a "minimal support", e.g. round up to the lowest possible value to keep the motor engaged, until higher resolution support is possible.

And coming back to the intuition of the new button logic (see below for a quick reminder of the discussion). I finally realized why I think a single press for after selecting a value is more intuitive. I agree that the different actions to have a clear logic, but it depends on how you think of the actions:
I would interpret the actions like:
short-press: confirm/select
long-press: cancel/go-higher

So when selecting a value, my intuition says 'short-press' to confirm the value (and automatically go back), and long-press would go back and not change the value, i.e. keep the previous value. If you see the actions like this, a short press to confirm a new value seems very logical to me. My ISDT charger also implements exactly this logic.

#new button logic - to exit the submenu once the value is set the long press of on/off button is required however I think just a short press would be enough.
Now by exiting submenu with the long press I have ended occasionally two levels higher than initially wanted as well it takes more time to configure parameters.

Good note! I have decreased the time needed to hold the button. Much faster now but still not a click. I strongly believe it is best to have two different button events/actions for different menu actions so as to have a clear logic. I truly recommend this and would love that you test the new faster logic in the next beta as it should be better!

So after the feedback from elfnino, the button hold time was drastically reduced for the beta 8, daenny. But I understand you still feel it is slow. If you do not mind I will take a look at it and try to improve it for future versions. This is so that we can release a new stable version for all users and finally finish the development on the 0.19.0.

 

[bwb]

Hi, I am newby on this forum and I follow this topic silently for a very long time.
I installed a first TSDZ2 + XH18 on my daughters bike (still standard fw). I loved it directly and bought a second set to rebuild my bike from to hub motor with pas sensor to TSDZ2 + P850C display and brake sensors (still standard).
Now that my battery is fading, I want to give the FOS a try, it's however a big step. I already managed to reprogramme the LCD3. I intend to make an interface cable between original LCD3 connector and the TSDZ harness display connector.

Based on this picture (I added pin nrs)

I was wondering if somebody can confirm if underneath pin-to-pin interface cable is correct?

Thanks in advance for feedback and a big thanks to all the people contributing to very nice project.

 

[Rydon]

I was wondering if somebody can confirm if underneath pin-to-pin interface cable is correct?

Thanks in advance for feedback and a big thanks to all the people contributing to very nice project.

The pin mapping for the KT-LCD3 to plug into the 1to4 harness that came with your TSDZ2/850C is as follows:

KT-LCD3 / 850C
Blue / Orange
Green / Green
Yellow / White
Black / Black
Red / brown

This is the same as Bafang display wiring. Your motor probably has a female 8 pin connector and your daughter's has an 8 pin male or a 6 pin female. If your daughters motor has an 8 pin male you can convert her motor to be compatible with this same wiring using a special 1to4 cable I had manufactured that converts a standard TSDZ2 8 pin controller to use Bafang style wiring so you can use all of the Bafang throttles and brake sensors. Also, very soon, thanks to the talented engineers working on this project, you will also be able to flash the 850C and the new BlueTooth SW102 displays and they are compatible with this cable as well. You can find it here: https://www.electrifybike.com/store/p116/1_to_4__Female_Cable_for_TSDZ2_FOS_Firmware_Upgrade.html#/