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

jbalat said:

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.

Click to expand...

Hi jbalat,

Some time ago I mentioned it would be interesting to make a custom made PCB with a microcontroller and Bluetooth. So small package it could fit inside the TSDZ2 shell. Would be possible to connect a throttle and/or buttons. Was supposed to have USB so users could charge a phone as well. Under 50 USD.

Out of curiosity I created a very simple app for iOS that I played around with just to see how it would work. It had a live map showing where you were, assist level slider and all the other things you would expect. Possible to use touch ID or face ID to unlock the bike. Would be very easy to save the data with time stamps and thus create a logger.

So to answer your question, it is possible to do some sort of logging but I think the best way will be with the SW102 paired with a phone. I am focusing on the controller for know so can not say anything of value but the SW102 has the potential to be really great!

jbalat said:

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/

Click to expand...

That is really cool!

jimmyfergus said:

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.

Click to expand...

Great! It will only get better!

daenny said:

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.

Click to expand...

Will hopefully be fixed in the next version. Am working heavily on the controller code. Thanks for the feedback and I totally agree!

daenny said:

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.

Click to expand...

Have not thought about it that way and it certainly is logical. Several have commented on this so this will be changed! Thanks!

casainho said:

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.

Click to expand...

Update:

I will try to pull request within a couple of days. Have a couple of things I want to test more before submitting. A first 0.20.0 beta will be possible to make and maybe even a stable release with not as many changes as there was in 0.19.0 if we limit ourselves. So maybe focus on the menus in the SW102 and slightly wait with the communication between controller and display?

Will write separate changelogs but almost all changes to date are on the controller side. Only extremely minor changes on the display and the communication.

With the changes on 0.20.0 I want to make I think we have a great foundation for all future development. This is why I want to finish what I started.

I corrected the pedal human power calculation and I got this values for me, when pushing the pedals at a startup with motor disabled, only my human power (I did a few tests):

- ADC units for torque sensor: 35 (each unit = 0.77kgs)
- Pedal cadence: 35 RPMS
- ui16_pedal_torque_x100 = (uint16_t) ui8_torque_sensor * (uint16_t) ADC_STEP_PEDAL_TORQUE_X100;
- ui16_pedal_power_x10 = (uint16_t) (((uint32_t) ui16_pedal_torque_x100 * (uint32_t) ui8_pas_cadence_rpm) / (uint32_t) 96);

ui16_pedal_power_x10 = (35 * 120 * 35) / 96 = 1531 ---> 153 watts.

This seems a good value for me. If I would reduce considering the sinewave, that value would be: 153 * 0.637 = 97 watts.

Maybe it is more like 150 watts I hope. We need to validate this values.

I did push the code to master branch.



#define ADC_STEP_PEDAL_TORQUE_X100 120

/*---------------------------------------------------------
NOTE: regarding torque sensor

Torque (force) value found experimentaly.

Measured with a cheap digital hook scale, we found that
each ADC 8 bits step measures 0.77kgs.
Full ADC range of 10 bits, it can measure as low as 0.19 kgs.

Force (Nm) = 0.77 Kg * 9.18 * 0.17 (0.17 = arm cranks size)
Force per each ADC 8 bits step = 1.2 Nm
---------------------------------------------------------*/

@casainho had the idea to evaluate the torque sensor peak signal (measuring peak signal every pedal rotation) as being a sinewave and so the average would be:

> [Average value = 0.637 × maximum or peak value, Vpk](https://www.electronics-tutorials.ws/accircuits/average-voltage.html)

For a quick hack, we can just reduce actual value to 0.637.

casainho said:

I corrected the pedal human power calculation and I got this values for me, when pushing the pedals at a startup with motor disabled, only my human power (I did a few tests):

Click to expand...

One of many things I have worked on is the torque sensor. The human power calculation has become better just by improving the code that is related to the torque sensor. Give me a couple of days to finalize the changes I have made so we can create a beta for everyone to test. Think this will be solved once and for all this time!

But still submitted a pull request of my work so far. It is WIP but I do not want to solve more merge conflicts so thought it would be good to submit it. Even though nothing is finished it does work and solve many issues reported and improvements suggested already.

Have not even implemented my current control filter because I have put down so much time improving the controller code overall!

As I said, give me a couple of days and there will be a beta. This is basically the next generation controller firmware and ready for great new functions like eMTB. Together with the SW102 later on it will be really nice!

And please let me know if you plan to improve something on the controller the next couple of days so I can submit my latest changes beforehand. It will be easier as we do not need to solve merging conflicts and solve the same issues twice. I plan a couple of pull requests and then have a beta out for testing. Hopefully there will be a 0.20.0 that is stable before SW102. Then all focus can be on the display!

That looks very promising!
Thanks for the news.
Just refresh my memory.. is the SW102 display the one very difficult to open up to perform the initial programming?

buba said:

casainho said:

I corrected the pedal human power calculation and I got this values for me, when pushing the pedals at a startup with motor disabled, only my human power (I did a few tests):

Click to expand...

One of many things I have worked on is the torque sensor. The human power calculation has become better just by improving the code that is related to the torque sensor.

Click to expand...

I did that because I was spotted the wrong calculations, that were probably a mistake due to merges. The correction was straightforward. I think the hard part is to validate by comparing with other ways to measure the human power but the current values makes sense for me but the previous ones were like 2 or 3 times higher.

buba said:

And please let me know if you plan to improve something on the controller the next couple of days so I can submit my latest changes beforehand.

Click to expand...

I do not plan any more changes. Human power is the foundation for that other modes like emtb, so I think it should be done first.

thineight said:

That looks very promising!
Thanks for the news.
Just refresh my memory.. is the SW102 display the one very difficult to open up to perform the initial programming?

Click to expand...

See here all our information about the SW102 Bluetooth LCD:

https://github.com/OpenSource-EBike-firmware/Color_LCD/wiki/Bafang-LCD-SW102

Installed v0.19 today but didn't ride the bike yet.
Bravo for the menu navigating button logic change, previous one was pretty unusual.
It looks like browsing through menus is also faster than it was before.

It also appears as settings for previous 0.18 version were not overwritten during upgrade.

Quick update on the human power calculation!

Went through every single line on the controller code and put down some development time. The result is that the measured human power is a lot lower now and seems to be much more realistic. I have not calibrated anything.

Still using the same formula but without multiplying with 0.637 for average power (sine wave). It is more accurate to remove it for now as long as we are not measuring the maxima of the power in every crank revolution.

I need to improve the filtering on the display. Am getting around half the human power I would expect now. This will be a new filter implementation that has a lower steady state error. The new filter will greatly improve the accuracy and hopefully the precision as well. It is very adjustable, has no buffers, very minimal and low on execution time. No bias in any direction.

You can see the difference between the filters below. They are reacting to a step signal. Good for measuring the response. Notice the difference between the true power value and the filtered value between the two filters. The old filter converges to 66 % of the actual value in steady state. The new filter converges to the actual value.

NOTE: The new filter is matched to the same initial parameters the old filter uses. This is done for a more clear comparison. But will be adjusted and calibrated in the firmware for best performance.

-----------------------------------
Old filter reacts to 0 -> 100 watts applied from user. See the blue line for real power applied from user. The red line is the filtered value. Steady state around 66 watts.



-----------------------------------
New filter reacts to 0 -> 100 watts applied from user. See the blue line for real power applied from user. The green line is the filtered value. Steady state converges to the actual 100 watts.



-----------------------------------
Here are both filters in comparison.



Will soon make another pull request. Sorry if it seems slow but am working with many things at the same time. Need to test every change and validate. Many changes are dependent on other parts so they need to be developed in parallel.

buba said:

Will soon make another pull request. Sorry if it seems slow but am working with many things at the same time. Need to test every change and validate. Many changes are dependent on other parts so they need to be developed in parallel.

Click to expand...

Take your time. You are making good work.

Im a couple of years late into this, but I do have 2 TSDZ motors, one 36v and the other 48v. But none have throttles, is there a way to add throttling to it by upgrading to this firmware ?

Thanks for everything you guys do on this motor!

buba said:

Quick update on the human power calculation!

Went through every single line on the controller code and put down some development time. The result is that the measured human power is a lot lower now and seems to be much more realistic. I have not calibrated anything.

Still using the same formula but without multiplying with 0.637 for average power (sine wave). It is more accurate to remove it for now as long as we are not measuring the maxima of the power in every crank revolution.

Click to expand...

So I used the same formula and I also think the value is kind of low so, that * 0.637 seems to not make sense. But how to be secure of the calculated value?? I wish we could test and validate it.

buba said:

I need to improve the filtering on the display. Am getting around half the human power I would expect now. This will be a new filter implementation that has a lower steady state error. The new filter will greatly improve the accuracy and hopefully the precision as well. It is very adjustable, has no buffers, very minimal and low on execution time. No bias in any direction.

Click to expand...

Good that you found that error on the value calculated on the display and a good solution.
[/quote]

casainho said:

buba said:

Quick update on the human power calculation!

Went through every single line on the controller code and put down some development time. The result is that the measured human power is a lot lower now and seems to be much more realistic. I have not calibrated anything.

Still using the same formula but without multiplying with 0.637 for average power (sine wave). It is more accurate to remove it for now as long as we are not measuring the maxima of the power in every crank revolution.

Click to expand...

So I used the same formula and I also think the value is kind of low so, that * 0.637 seems to not make sense. But how to be secure of the calculated value?? I wish we could test and validate it.

Click to expand...

I think your idea will get us to somewhat realistic values initially: in short, you suggested to keep the motor at a constant duty cycle and constant power. Then test the human power and compare. This would be very good just too see we are on the right path.

To get more accuracy we could measure the watt hours consumed on a long stretch of road. Maybe a couple of kilometers. We try to maintain the same speed only with motor power so we have the same average speed in all tests. Maybe use Cruise and let it try to maintain the speed. Next test would be with the motor off and measuring human watt hours on the same stretch. I would develop a custom firmware for this where we could measure the human watt hours or the motor watt hours.

If the average speed is the same we can compare the results and see if the motor power consumption is equal to the human power. What is also important is to vary the cadence on a couple of tests. Low, medium and high preferably so we can validate that the torque measurements keep up with the crank rotational speed and that our approach is valid.

casainho said:

buba said:

I need to improve the filtering on the display. Am getting around half the human power I would expect now. This will be a new filter implementation that has a lower steady state error. The new filter will greatly improve the accuracy and hopefully the precision as well. It is very adjustable, has no buffers, very minimal and low on execution time. No bias in any direction.

Click to expand...

Good that you found that error on the value calculated on the display and a good solution.

Click to expand...

Thanks! Will keep on testing and validate everything the next few days!

buba said:

I think your idea will get us to somewhat realistic values: in short, you suggested to keep the motor at a constant duty cycle and constant power. Then test the human power and compare.

To get more accuracy we could measure the watt hours consumed on a long stretch of road. Maybe a couple of kilometers. We try to maintain the same speed only by motor power so we have the same average speed in all tests. Maybe use Cruise and let it try to maintain the speed. Next test would be with the motor off and measuring human watt hours on the same stretch. I would develop a custom firmware for this where we could measure the human watt hours or the motor watt hours.

If the average speed is the same we can compare the results and see if the motor power consumption is equal to the human power. What is also important is to test it with different cadence on a couple of tests. Low, medium and high preferably so we can validate that the torque measurements keep up with the crank rotational speed and that our approach is valid.

Click to expand...

I think the easiest ay would be to configure max limit the power to something like 100W on LCD3, then, with a throttle keep at max but the power would be a constant 100W.

What I guess will be difficult is to pedal at high human power values like 300W up to 800W. I can only go up to 150W, at least using this latest code/formula.

dameri said:

buba said:

Will soon make another pull request. Sorry if it seems slow but am working with many things at the same time. Need to test every change and validate. Many changes are dependent on other parts so they need to be developed in parallel.

Click to expand...

Take your time. You are making good work.

Click to expand...

Thanks, doing my best! Have already implemented a lot of ideas and am planning for even more the next couple of days!

casainho said:

buba said:

I think your idea will get us to somewhat realistic values: in short, you suggested to keep the motor at a constant duty cycle and constant power. Then test the human power and compare.

To get more accuracy we could measure the watt hours consumed on a long stretch of road. Maybe a couple of kilometers. We try to maintain the same speed only by motor power so we have the same average speed in all tests. Maybe use Cruise and let it try to maintain the speed. Next test would be with the motor off and measuring human watt hours on the same stretch. I would develop a custom firmware for this where we could measure the human watt hours or the motor watt hours.

If the average speed is the same we can compare the results and see if the motor power consumption is equal to the human power. What is also important is to test it with different cadence on a couple of tests. Low, medium and high preferably so we can validate that the torque measurements keep up with the crank rotational speed and that our approach is valid.

Click to expand...

I think the easiest ay would be to configure max limit the power to something like 100W on LCD3, then, with a throttle keep at max but the power would be a constant 100W.

What I guess will be difficult is to pedal at high human power values like 300W up to 800W. I can only go up to 150W, at least using this latest code/formula.

Click to expand...

Yes, we would have to limit the power, especially on the long tests. We would also need to make sure that the average speed is the same between the two tests. There are many possibilities and approaches. Would maybe be good to test a couple and see if we get the same result from different tests as well. Am now improving the calibration of the torque sensor so we always have that perfect. This will also improve the human power measurements even though it is minimal.

For the tests, I don't have a throttle as I use the temperature sensor.

Would be good to have a "virtual throttle", maybe something that increases throttle value using up and down buttons.

On SW102 we have 4 buttons instead of 3 as in LCD3 so we will get more button combinations that we can use for more options

casainho said:

For the tests, I don't have a throttle as I use the temperature sensor.

Would be good to have a "virtual throttle", maybe something that increases throttle value using up and down buttons.

On SW102 we have 4 buttons instead of 3 as in LCD3 so we will get more button combinations that we can use for more options

Click to expand...

I also have the temperature sensor. We will figure out something when it is time.

The three buttons on the KT-LCD3 are really not enough for the open source firmware. +1 for SW102!

Virtual throttle mode

Let's say there is a button combination to enter this mode and then up and down buttons do not change the assist level but instead increase/decrease throttle value in 5% steps (20 steps to get to max throttle value).

Throttle value would start at 0 and user could increase with a UP button press and keep button press to maintain the throttle value. A quick press would increase or decrease and maintain the up or down press would maintain the throttle value. As soon user release that buttons, the throttle value would decrease at a not so fast rate -- this gives some security against accidents and throttle being stuck and also avoid decrease when quick increasing or decreasing the value.

casainho said:

Virtual throttle mode

Let's say there is a button combination to enter this mode and then up and down buttons do not change the assist level but instead increase/decrease throttle value in 5% steps (20 steps to get to max throttle value).

Throttle value would start at 0 and user could increase with a UP button press and keep button press to maintain the throttle value. A quick press would increase or decrease and maintain the up or down press would maintain the throttle value. As soon user release that buttons, the throttle value would decrease at a not so fast rate -- this gives some security against accidents and throttle being stuck and also avoid decrease when quick increasing or decreasing the value.

Click to expand...

Wanted to do something similar for Cruise. To have it settable by user by the UP and DOWN buttons. Instead of assist level. This is why there is a "See the set target Cruise speed" in the odometer field.

But yeah:

apply_virtual_throttle()
{
if (ui8_virtual_throttle_enabled)
{
// ramp up or down appropriately

// map virtual throttle value to adc current

// set adc target current
}
}

I'm glad to see some work on the human torque reading. My TSDZ2 flatters me daily, my old bones push 200W so easily...

A decent check could be done with rollers. On zero assist pedal a while at a steady speed and get a good human watts reading. Then in the same gear use throttle only to reach the same speed and read the electrical watts.

Rollers eliminate confounding factors like wind resistance, head or tail wind, or changes in grade like you have on the road. If you run rollers the same speed they draw the same power.

Since the motor and gears are about 80% efficient, 0.8 * electrical watts should be very close to the true mechanical work at the spindle and can be used to calibrate human watts. The displayed zero assist human watts should correspond within 5% or so.

I would do this but I don't know anyone who has a set of rollers.

How would one install 3 wire(white red black) throttle to v19 kt lcd3 8 wire setup?

Do we connect to the Green White and Orange wires left from display install ( if so what order) or to connect directly to the display( if so where do we attach to?)
If this has already been addressed I’m sorry!



Sent from my iPhone using Tapatalk

I got 0.19 finally up and running 8)

by Rydon » 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/p11 ... ade.html#/

Click to expand...

If I was aware that this cable existed, it would have been much faster/easier than making a small interface cable.

Anyway, parameters settings quickly verified and made the first 500m testrun => congrats to the developpers.

@developpers: if test are needed, I can perhaps help. I have a 36V setup with trottle, brake sensors and I have Speedict Mercury logger between the battery and the rest of the bike. So I can do some logging/comparison. Voltage, current, power seem to match.



First thing now is ordering a new battery and learning the how to view the ebike parameter on the display.