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

zillap said:
1.0.0 alpha4 Light testing

First of all hudge thanks to all you guys for incredible work that is made on this software.
Here I decided to report on my test regarding Light issue, also I am able to do further tests and report if needed.

Motor 36V, Battery 36V. Firmware version 1.0.0 alpha4.
Light - 1pcs LED 6V 2,5W
ADC value with Light on fluctuates from 0 to 1
Light ON
With ADC offset 0 - no motor power
With ADC offset from 1 to 4 the same issue (also check on video):
After start of pedaling - no motor power.
After some time of pedaling motor kicks in suddenly.
I was unable to determine any relation on pedaling duration or power before motor starts working.

Hope it helps.

[youtube]lvhxy4NHH0A[/youtube]
Thanks for reporting.

So, there is a difference of using 0 or more ADC offset value? As I understand, with 0 there is no motor power all but what happens in detail when that value is > 0? For me is not clear in the video.
 
ilu said:
navasjm said:
Personally I prefer the 2nd option BUT I’d have to cut both the adapter/extension cable and the 1to3 cable since they’re too long, and I really don’t know if this is recommended.

What I don’t like about the first option is that one connector will remain unused/disconnected I don’t know if this could present any problem.

Thanks in advance for your help.

I would buy the 1to4 cable and just cut the throttle and seal it with a bit of heat shrink tube and glue. Unused connector won't be a problem but if you know you are not going to use it, cutting it off gives a slightly cleaner look.

That is what I did. I cut throttle and brake cables.
 
casainho said:
So, there is a difference of using 0 or more ADC offset value? As I understand, with 0 there is no motor power all but what happens in detail when that value is > 0? For me is not clear in the video.
I can confirm that 2 displays which include the reference AKSM2.0 in their serial number permit correct operation with the lights switched on irrespective of which version from 0.7 to 1.0 is used. The display with XF2.0 in its serial number does not. All these displays were manufactured from September 2019.
 
I uploaded the version for sw102 1.0.0 alpha 4. Earlier I had 0.8.0 and 0.57.3.
Casainho, did you change the engine stop time for bicycles with full suspension? I noticed that sometimes a few ms is missing and the support is temporarily interrupted, but it happens very rarely.
I also had the torque sensor calibration function active immediately after uploading. Compared with 0.8.0 the engine got power: D But I noticed that after entering the previous ADC values in the calibration of the torque sensor, while driving I have a spiral effect when pedaling. At 0.8.0 I could maintain the same pace and dose of power, now I have the impression on 0.1.0.0 that as if I was driving with the torque sensor option turned off (uncalibrated), but with a slightly weaker increase.
 
hetm4n said:
I uploaded the version for sw102 1.0.0 alpha 4. Earlier I had 0.8.0 and 0.57.3.
Casainho, did you change the engine stop time for bicycles with full suspension? I noticed that sometimes a few ms is missing and the support is temporarily interrupted, but it happens very rarely.
I also had the torque sensor calibration function active immediately after uploading. Compared with 0.8.0 the engine got power: D But I noticed that after entering the previous ADC values in the calibration of the torque sensor, while driving I have a spiral effect when pedaling. At 0.8.0 I could maintain the same pace and dose of power, now I have the impression on 0.1.0.0 that as if I was driving with the torque sensor option turned off (uncalibrated), but with a slightly weaker increase.
Thanks for the feedback.

For full suspension bicycles, on various configurations menu: added configuration for cadence fast stop mode, which is enabled by default. Enable for regular bicycles and disable for some full suspension bicycles.

The spiral effect, I think it is because of the change I did, after the idea of the user vshitikov: "ebike control loop now runs at twice the frequency in the hope to make system a bit more responsive (tested by vshitikov).
So, the motor has now 2x faster response AND the torque sensor is measured 2x faster. The torque sensor measures different values over different pedal positions and should be like a sinewave.... now being faster, probably the sinewave is now more noted on the motor assistance.

I am working to log real data from the torque sensor so I can apply a filter to smooth the readings. The issue is that we want a fast response but that is incompatible with having a stable readings, because they are not naturally stable.
 
casainho said:
So, there is a difference of using 0 or more ADC offset value? As I understand, with 0 there is no motor power all but what happens in detail when that value is > 0? For me is not clear in the video.

Please look at a display data:
Upper Left - Cadence
Lower right - Motor power

Normaly (with Lights OFF) Motor power (assit) starts with the first pedal stroke so Cadence and Motor power allways >0 together

In this case with (with Lights ON) Cadence >0 but motor power is 0 (from video second 8 till second 12) after that motor kicks in with power.

I have tried several times, in one cases it takes fwe seconds in others even 10-20 seconds for motor to start.
 
zillap said:
casainho said:
So, there is a difference of using 0 or more ADC offset value? As I understand, with 0 there is no motor power all but what happens in detail when that value is > 0? For me is not clear in the video.

Please look at a display data:
Upper Left - Cadence
Lower right - Motor power

Normaly (with Lights OFF) Motor power (assit) starts with the first pedal stroke so Cadence and Motor power allways >0 together

In this case with (with Lights ON) Cadence >0 but motor power is 0 (from video second 8 till second 12) after that motor kicks in with power.

I have tried several times, in one cases it takes fwe seconds in others even 10-20 seconds for motor to start.
Please try to increase also the min motor ADC while pedaling, I need to know what will be the effect. It will increase or decrease that time? What if you put at 0 the ADC step for the lights but increase only the other, what happens?

Also, this delay only happens when motor assistance is 0 and increase pedal power or even when pedal power is 0 and cadence is > 0 and then increase the pedal power?

Please test and give that detailed feedback, that will help me to understand what may be happening.
 
casainho said:
Thanks for the feedback.

For full suspension bicycles, on various configurations menu: added configuration for cadence fast stop mode, which is enabled by default. Enable for regular bicycles and disable for some full suspension bicycles.

Yes . I turned off this option. I have the impression that a few ms are missing during the stop. Although it can also be due to this faster response to pedal pressure, as you wrote.
 
hetm4n said:
casainho said:
Thanks for the feedback.

For full suspension bicycles, on various configurations menu: added configuration for cadence fast stop mode, which is enabled by default. Enable for regular bicycles and disable for some full suspension bicycles.

Yes . I turned off this option. I have the impression that a few ms are missing during the stop. Although it can also be due to this faster response to pedal pressure, as you wrote.
And if you keep that option enable, it is very clear to you that disabling the feature has an improvement?

And I am working to figure out this new issue after increasing the system reaction 2x.
 
casainho said:
I am working to log real data from the torque sensor so I can apply a filter to smooth the readings. The issue is that we want a fast response but that is incompatible with having a stable readings, because they are not naturally stable.
@Casainho. That is a great idea on which you are working. A nice additional feature will be to have configuration parameter for the data weighting. This will give the user the option to adjust the motor response according his expectations and needs - (fast and unstable) or (slow and stable).
And finally it will fully solve my problem with the torque sensor.
 
Sorry to bother you guys but......................
I have an SW102 from the lovely people at Eco cycles - with the "standard?" firmware, and I am looking to change to this. I am confused as to whether I can directly flash via Bluetooth or if it needs opening?
Thanks.
 
Hi. I thought I'd share an small unfortunate experience, just in case anyone else makes the same mistake. I'm new to 'leccy bikes, and I bought the TSDZ2 so that I can manage the 14 mile cycle to work. Fitted the kit, then flashed the motor and 860C display with the open source firmware. Took it out for a test ride and it was fantastic. Got home and decided to get on with adding the brake sensor and shortening the loom a bit for a better fit to the bike. Disconnected the battery first and started soldering. Noticed I'd connected two of the wires wrong, unsoldered them and corrected. Reconnected battery only to get an RX error on the display.

So it turns out I've fried both the display and motor controller. Neither are responding to the PC any more.

I had disconnected the battery but not disconnected the loom from the motor. Maybe there's a capacitor in there which damaged the devices when connected wrong.

It's a lesson learnt for me, might be worth mentioning on the wiki though to ensure others fully disconnect the loom before working on it.
 
dameri said:
Mr.Flibble said:
Sorry to bother you guys but......................
I have an SW102 from the lovely people at Eco cycles - with the "standard?" firmware, and I am looking to change to this. I am confused as to whether I can directly flash via Bluetooth or if it needs opening?
Thanks.

First time to flash it you have to open it.

https://github.com/OpenSource-EBike...he-bootloader-and-firmware-on-SW102-using-SWD

Even if it has had the TSDZ2 firmware put on it instead of Bafang?
 
rcx194 said:
Hi. I thought I'd share an small unfortunate experience, just in case anyone else makes the same mistake. I'm new to 'leccy bikes, and I bought the TSDZ2 so that I can manage the 14 mile cycle to work. Fitted the kit, then flashed the motor and 860C display with the open source firmware. Took it out for a test ride and it was fantastic. Got home and decided to get on with adding the brake sensor and shortening the loom a bit for a better fit to the bike. Disconnected the battery first and started soldering. Noticed I'd connected two of the wires wrong, unsoldered them and corrected. Reconnected battery only to get an RX error on the display.

So it turns out I've fried both the display and motor controller. Neither are responding to the PC any more.

I had disconnected the battery but not disconnected the loom from the motor. Maybe there's a capacitor in there which damaged the devices when connected wrong.

It's a lesson learnt for me, might be worth mentioning on the wiki though to ensure others fully disconnect the loom before working on it.

There are capacitors on the controller, but the rx and tx are reserved from what you would expect and what the pin out diagrams would lead you to expect, when going from Tongsheng to Bafang.
Try reversing the data wires, it worked for me when I made a cable and it didn't work .
 
Mr.Flibble said:
dameri said:
Mr.Flibble said:
Sorry to bother you guys but......................
I have an SW102 from the lovely people at Eco cycles - with the "standard?" firmware, and I am looking to change to this. I am confused as to whether I can directly flash via Bluetooth or if it needs opening?
Thanks.

First time to flash it you have to open it.

https://github.com/OpenSource-EBike...he-bootloader-and-firmware-on-SW102-using-SWD

Even if it has had the TSDZ2 firmware put on it instead of Bafang?

Sorry, I read the question carelessly. Maybe it’s better to ask Eco cycles. Or maybe someone here knows. Do you see any signs that the display has opened. If it has OS firmware then it have to be opened.
 
Hello

I write in response to my posts of mid April (P 205).
I have a branch ready which utilizes the uart tx interrupt. This should
free up quite some processing time.
@ casainho: if you add me to the contributors i will push my branch and you can check if you want to
merge it in or not.

Regarding the adc current measurement:
The STM8 Reference Manual states on P432 that in single conversion mode, the converted data are stored in the ADC_DR
register and not the buffered registers. It seems to me that you are reading the buffered register in the pwm interrupt
and therefore just get the last value from the continuous conversion.
If thats the case, the triggering and reading of the adc sensor in each pwm interrupt could be omitted.

In my experimental branch i sample the current every 10th interrupt resulting in 6 to 7 samples between two executions
of the 4ms control loop. In the control loop i then use the average of these samples to compute the duty cycle and the foc angle.


In the meantime i have two more questions:

(1) According to the wiki https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/TSZD2-Hardware-Information
the controller can turn itself off by setting PD4 to one. This seems to be a typo, since PD4 is the light pin. Does anyone know the correct pin number for turning off the controller?

(2) In the file pins.h there is a comment about the PD0 pin:
The microcontroller should read the turned on transistor signal on PD0, to detect the battery_over_current of 22 amps
Did you experiment with that? Since its already there, i think it would make sense to make use of it.
Apparently the PD0 is configured to be TIM1_BKIN in the original firmware (also from a comment in the pins.h file).
So far i did not have the time to investigate this.

Thanks already for your support
 
casainho said:
And if you keep that option enable, it is very clear to you that disabling the feature has an improvement?

And I am working to figure out this new issue after increasing the system reaction 2x.

When I turn on the quick stop option, it is such a difference that practically driving the forest path all the time the engine stops supporting on potholes. If I turn off this option, this problem is gone but sometimes it stops for a while. At 0.8.0 and 0.57.3 this effect was already gone.
 
Hello casainho, thank you for your great work. I drive 2000km with your version 0.19. No Problems! Yesterday i do update to 860C und Version 1.0.0 alpha4 - I'm now also Test-Driver vor this Version! ;). One little mistake i get in the setup screen! If i go first in Menu "Various" and next in Menu "Display" then i get a freeze with black screen with text: 0x2 0x8010c64. For your Information!
__________________________________________
Canyon AL 6.0 2014 TSDZ2 10s5p / 860C
 
hetm4n said:
casainho said:
And if you keep that option enable, it is very clear to you that disabling the feature has an improvement?

And I am working to figure out this new issue after increasing the system reaction 2x.

When I turn on the quick stop option, it is such a difference that practically driving the forest path all the time the engine stops supporting on potholes. If I turn off this option, this problem is gone but sometimes it stops for a while. At 0.8.0 and 0.57.3 this effect was already gone.
Ok, good to know. Let me first try to improve the torque sensor readings and then we will see if this issue still happens.
 
rcx194 said:
Hi. I thought I'd share an small unfortunate experience, just in case anyone else makes the same mistake. I'm new to 'leccy bikes, and I bought the TSDZ2 so that I can manage the 14 mile cycle to work. Fitted the kit, then flashed the motor and 860C display with the open source firmware. Took it out for a test ride and it was fantastic. Got home and decided to get on with adding the brake sensor and shortening the loom a bit for a better fit to the bike. Disconnected the battery first and started soldering. Noticed I'd connected two of the wires wrong, unsoldered them and corrected. Reconnected battery only to get an RX error on the display.

So it turns out I've fried both the display and motor controller. Neither are responding to the PC any more.

I had disconnected the battery but not disconnected the loom from the motor. Maybe there's a capacitor in there which damaged the devices when connected wrong.

It's a lesson learnt for me, might be worth mentioning on the wiki though to ensure others fully disconnect the loom before working on it.
I would try to make sure both are fried before bought the 2 and install them. I think the 850C/860C much more sensitive to shot circuits them the motor controller.

Please go ahead and put a warning on the wiki, maybe on the firmware installation page.
 
benno said:
I write in response to my posts of mid April (P 205).
I have a branch ready which utilizes the uart tx interrupt. This should
free up quite some processing time.
@ casainho: if you add me to the contributors i will push my branch and you can check if you want to
merge it in or not.
I would prefer a pull request. Or before the pull request, maybe you can share here a link for your github so I can see if first?? - if that works as your said, then it will be a welcome contribution.

benno said:
Regarding the adc current measurement:
The STM8 Reference Manual states on P432 that in single conversion mode, the converted data are stored in the ADC_DR
register and not the buffered registers. It seems to me that you are reading the buffered register in the pwm interrupt
and therefore just get the last value from the continuous conversion.
If thats the case, the triggering and reading of the adc sensor in each pwm interrupt could be omitted.
I am doing both, single conversion and scan conversion, buffered, as seen on the comments:

First, to get the battery current in single conversion mode, specifically read on to the middle of the PWM duty_cycle:

Code:
  /****************************************************************************/
  // read battery current ADC value | should happen at middle of the PWM duty_cycle
  // disable scan mode
  ADC1->CR2 &= (uint8_t)(~ADC1_CR2_SCAN);
  
  // clear EOC flag first (selected also channel 5)
  ADC1->CSR = 0x05;
  
  // start ADC1 conversion
  ADC1->CR1 |= ADC1_CR1_ADON;
  while (!(ADC1->CSR & ADC1_FLAG_EOC)) ;
  ui16_g_adc_battery_current = UI16_ADC_10_BIT_BATTERY_CURRENT;

Then scan conversion for others:

Code:
  /****************************************************************************/
  // trigger ADC conversion of all channels (scan conversion, buffered)
  ADC1->CR2 |= ADC1_CR2_SCAN; // enable scan mode
  ADC1->CSR = 0x07; // clear EOC flag first (selected also channel 7)
  ADC1->CR1 |= ADC1_CR1_ADON; // start ADC1 conversion

benno said:
In the meantime i have two more questions:

(1) According to the wiki https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/TSZD2-Hardware-Information
the controller can turn itself off by setting PD4 to one. This seems to be a typo, since PD4 is the light pin. Does anyone know the correct pin number for turning off the controller?

(2) In the file pins.h there is a comment about the PD0 pin:
The microcontroller should read the turned on transistor signal on PD0, to detect the battery_over_current of 22 amps
Did you experiment with that? Since its already there, i think it would make sense to make use of it.
Apparently the PD0 is configured to be TIM1_BKIN in the original firmware (also from a comment in the pins.h file).
So far i did not have the time to investigate this.
1. I did the schematic/hardware analysts and I don´t remember that TSDZ2 has this feature. Also, maybe I did a copy paste from the KT controllers???... -- hmm, maybe the motor controller could turn it self off in the case of timeout of missing communications with the display, this would be a nice safety feature. BUT we are the providers of both display and motor controller firmware so we have this safety feature on the display side. I think this safety feature is needed because the TSDZ2 motor controller can work with displays with firmware developed by third parties, which is not our case.
2. I think I remember to do the calculations on the resistors to find and write that "battery_over_current of 22 amps". I don't see any advantage to use that like how our firmware is implemented. I know that TIM1_BKIN can be a signal to "chop" the PWM signal but that would be only ok for square wave voltage signals and we are using SVM which are very different. Anyway, I don't feel the need to use it and since our firmware is working very well, I don't see a reason to bother with that.
If we think that TIM1_BKIN is like a fast reaction to the event of OVER current, that must have priority, we already read that signal every PWM cycle with the highest priority on the system, that is why I prefer to keep reading the currents on the PWM cycle.
 
casainho said:
Ok, good to know. Let me first try to improve the torque sensor readings and then we will see if this issue still happens.

In order to have accurate values from Torque sensor, you should decrease the ADC clock. Actually you have configured 8MHz but the STM8 datasheet states a maximum ADC clock frequency of 6MHz. You are now about 33% above the Max Freq. This is particularly important for a signal with weak current drive capabilities and small value escursion like the torque sensor signal.
 
Please help. just flash the v0.7.0 to 860 display but doesn’t communicate with TSDZ2, it shows errors brakes. Flash the TSDZ2 with v0.56.0. Breaks connect to green and black wire. Any idea what is wrong.
 

Attachments

  • F91B5B90-7F6E-4EEE-B533-1E03D380D4FA.jpeg
    F91B5B90-7F6E-4EEE-B533-1E03D380D4FA.jpeg
    48.3 KB · Views: 625
rcx194 said:
Hi. I thought I'd share an small unfortunate experience, just in case anyone else makes the same mistake. I'm new to 'leccy bikes, and I bought the TSDZ2 so that I can manage the 14 mile cycle to work. Fitted the kit, then flashed the motor and 860C display with the open source firmware. Took it out for a test ride and it was fantastic. Got home and decided to get on with adding the brake sensor and shortening the loom a bit for a better fit to the bike. Disconnected the battery first and started soldering. Noticed I'd connected two of the wires wrong, unsoldered them and corrected. Reconnected battery only to get an RX error on the display.

So it turns out I've fried both the display and motor controller. Neither are responding to the PC any more.

I had disconnected the battery but not disconnected the loom from the motor. Maybe there's a capacitor in there which damaged the devices when connected wrong.

It's a lesson learnt for me, might be worth mentioning on the wiki though to ensure others fully disconnect the loom before working on it.

Thanks for sharing that's a good thing for people to know.
 
Back
Top