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

nassal said:
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.

This error message appeared in past, when firmware version 0.58 and above was running on the motor, but the display had an older version on it (due to the changed communication frequency). Have you tried to downgrade? Was the firmware flashing on the motor successfull (message "program code successfully verified")? And is it working when you flash the latest Alpha version on both the motor and display?
 
dameri said:
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.

Unfortunately they say it needs to be opened :(
Everything I read was very ambiguous about it, I was suspious when the Bt id was topin xxxx ......
I had hoped as it came installed with non standard firmware, that it would just flash via bt and not need opening.
 
Martin555 said:
nassal said:
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.

This error message appeared in past, when firmware version 0.58 and above was running on the motor, but the display had an older version on it (due to the changed communication frequency). Have you tried to downgrade? Was the firmware flashing on the motor successfull (message "program code successfully verified")? And is it working when you flash the latest Alpha version on both the motor and display?

I swapped the RX and TX wire,Communication is established now but no Pedal assist 😬. Use to have 850 which is not working any more. Got a 860 now and flashed it with first 860 display firmware was available and program code successfully verified. I thought it will be more stable one. Any idea why no pedal assist? Thanks
 

Attachments

  • EA127AAA-0833-40B9-B146-F817D8525A06.jpeg
    EA127AAA-0833-40B9-B146-F817D8525A06.jpeg
    15.1 KB · Views: 640
  • D8173133-F1F7-4A5A-B3CF-8394DBFB1762.jpeg
    D8173133-F1F7-4A5A-B3CF-8394DBFB1762.jpeg
    15.7 KB · Views: 640
  • 97E29B4C-3E00-4873-BD25-F8329D30C693.jpeg
    97E29B4C-3E00-4873-BD25-F8329D30C693.jpeg
    15.5 KB · Views: 640
nassal said:
Any idea why no pedal assist? Thanks
Now with the firmware on 850C/860C display, you have all the tools needed to understand why your motor is not working.

You can go to Technical configurations and see if there is cadence and troque sensor signals.

Also try the virtual throttle to see if motor runs.
 
casainho said:
nassal said:
Any idea why no pedal assist? Thanks
Now with the firmware on 850C/860C display, you have all the tools needed to understand why your motor is not working.

You can go to Technical configurations and see if there is cadence and troque sensor signals.

Also try the virtual throttle to see if motor runs.

Thank, I will do that. I used the throttle wire for heat sensor, so no throttle. I damaged my 850c during the programming. Forget to disconnect the battery and by mistake used the 8pin connecter instead of speed sensor connector to programme and had a short circuit, after that I flash the stock firmware on the motor and used the original display. Had the same problem, no pedal assist but throttle was working fine. Is it possible I have damaged the controller?? Thanks
 
nassal said:
Is it possible I have damaged the controller?? Thanks
You need to better understand each variable on Technical. For instance, if PWM ducy-cycle increases, the motor should run. You can see this value also from main screen.
 
Martin555 said:
nassal said:
Any idea why no pedal assist? Thanks

Maybe the pre-set battery cut-off voltage is above the current battery voltage? Is the walk mode working?

Yes walk mode works!!. Will check the configuration. Thanks
 
casainho said:
nassal said:
Is it possible I have damaged the controller?? Thanks
You need to better understand each variable on Technical. For instance, if PWM ducy-cycle increases, the motor should run. You can see this value also from main screen.

When it comes to technical and programming!, I am dumb, I have no idea what you just said, but I will look into it and will learn. Thanks
 
More test ride with the 1.0.0.alpha4 with SW102. Fantastic!
This is my list of observations:

  • Odometer in Imperil Units: it seems that I have to put initial value in km to get miles. Not a big deal
  • Motor Max Power: I accidentally activate this option and the default value is 1400watts!!!! wow! A lower value seems more reasonable
  • Start up boost: I played with it increasing the value of the assist level and I didn't feel any boost. I have to wait a couple of second to the motor to kick in and ramp up to get full speed. It doesn't take too long but when you are fighting with cars in a traffic environment, a quick start before the cars could be a lifesaving. In my case riding with my daughter in child seat with traffic lights in a hilly neighbor this feature is a must. Of all the different firmware I have installed, the start up boost only worked with the marcoq version. Any improvement will be highly appreciated
  • The motor works at a much higher amps than v0.19. I can see values of 13amps for the motor current uphill, and 10amps constant for 5 minutes. Of course,it goes much faster but the motor runs hotter than with v0.19. I am not capable of installing the thermal sensor to avoid any damage running with high amps. So do you think 16amps maximum is safe? I remember that the wiki recommend 10 or 12 amps maximum before. Same question for the 8 amps/s ramp. I am not going to win race carrying my daughter, so a "conservative" recommendation will be highly appreciated

Thanks!
 
nassal said:
Martin555 said:
nassal said:
Any idea why no pedal assist? Thanks

Maybe the pre-set battery cut-off voltage is above the current battery voltage? Is the walk mode working?


Yes walk mode works!!. Will check the configuration. Thanks

I have checked the configuration according ti instruction. The only thing works is walk mode. Have flash the latest version alpha.4, it didn’t make different, virtual throttle doesn’t work. Tried stock firmware, no pedal assist again but throttle works. I can’t use throttle with OSF as I used the wire for heat sensor. Any clue?
 

Attachments

  • 94723181-E965-40D8-BDA7-07925A21090E.jpeg
    94723181-E965-40D8-BDA7-07925A21090E.jpeg
    17.6 KB · Views: 591
  • 9AE55417-1FEA-43B1-9CF3-85EABBE42ADD.jpeg
    9AE55417-1FEA-43B1-9CF3-85EABBE42ADD.jpeg
    17 KB · Views: 591
nassal said:
I have checked the configuration according ti instruction. The only thing works is walk mode. Have flash the latest version alpha.4, it didn’t make different, virtual throttle doesn’t work. Tried stock firmware, no pedal assist again but throttle works. I can’t use throttle with OSF as I used the wire for heat sensor. Any clue?
If walk assist work then the motor is ok.

Note that you must put assist level > 0 for virtual throttle to work. And it must work. Also reset the configurations to default values and check again. Virtual throttle does not depend on torque sensor nor on cadence sensor, so, it must work unless some incorrect configuration is done.
 
Nfer said:
More test ride with the 1.0.0.alpha4 with SW102. Fantastic!
This is my list of observations:

  • Start up boost: I played with it increasing the value of the assist level and I didn't feel any boost. I have to wait a couple of second to the motor to kick in and ramp up to get full speed. It doesn't take too long but when you are fighting with cars in a traffic environment, a quick start before the cars could be a lifesaving. In my case riding with my daughter in child seat with traffic lights in a hilly neighbor this feature is a must. Of all the different firmware I have installed, the start up boost only worked with the marcoq version. Any improvement will be highly appreciated
Thanks!
If you want instant performance from a standstill you need to use the torque only version of this firmware, imho... The cadence sensor does not resolve cadence below a certain RPM, and this firmware uses pedal power (speed * torque) to calculate motor current, so you will never get assistance until the cadence increases above the minimum that can be resolved.

Try the r0mko fork (it is based on 0.57 so works nicely with SW102) and let us know if that gives you the performance you want. It certainly did for me.

It is as close as you will get to the marcoq code whilst having all the benefits of the work Casainho has done on the firmware recently.
 
James Broadhurst 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.
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.

The display which I have is AKSM2.0
I tried to figure out exact conditions on which motor kicks in, but it semes quite random.

I tried:
ADC min value from 0 to 5
Lights ofsett from 1 to 4 with various ADC min values
But no difference for issue.

Also I have tried to pedal with different cadence, torque. No exact values. Some times motos kicks in at 150W of human power, some times remains off at 500W.

What I figured out that with higher probability (but not neceserely) motor kicks in after2-3 seconds perdaling with torque above 10kg (I have calibrated torque sensor and checked it at Technical meniu)
 
zillap said:
I tried:
ADC min value from 0 to 5
Lights ofsett from 1 to 4 with various ADC min values
But no difference for issue.

Also I have tried to pedal with different cadence, torque. No exact values. Some times motos kicks in at 150W of human power, some times remains off at 500W.

What I figured out that with higher probability (but not neceserely) motor kicks in after2-3 seconds perdaling with torque above 10kg (I have calibrated torque sensor and checked it at Technical meniu)
Thanks for the feedback. I need to understand what is the issue... I hope to do it in next weeks.
 
Finally I was able to make SW102 firmware to send data over Bluetooth as being a serial port - this help me a lot to debug and can be great if anyone want to develop the mobile app.

So, I was logging the:
1. ADC torque sensor
2. pedal position (from 1 to 40, where 1 is like 0 degrees and 4 360 degrees)
3. cadence
4. pedal weight

So, that was in my bicycle. Each point is measure at every 50ms. Observations:
1. pedal position ideally would always be at 10 and 30, when cranks are horizontal with the ground. As we can see, the measurements are take all over the place, including on moments the value should be 0 (cranks at vertical).

2. since pedal position is very wrong, I would expect ADC torque sensor signal also very wrong although it is not I am guess that is because the hardware has the low pass filter. Still, I think the signal could be improved if reading at position 10 and 30, mainly after mid to high cadence.

3. the calculated pedal weight seems to have a big delay or be wrong, if we compare the torque sensor ADC values to the calculated pedal weigh

4. the cadence is going to 0 value!! My bicycle is full suspension one, so, I need to check again all this after disabling the feature of Cadence fast stop. Due to all the delays on the system, I could not yet understand that cadence was failing!!



 
Nfer said:
HughF said:
It is as close as you will get to the marcoq code whilst having all the benefits of the work Casainho has done on the firmware recently.

Is this the latest version https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.13?
Is it compatible with the display firmware 1.0.0 or do I have go back to the 0.8?
Please stop discussing on this thread other firmware forks.
 
casainho said:
can be great if anyone want to develop the mobile app.

You can use app named "Arduino Centrale Free" it is universal serial plotter.
It can show up to 10 values on one graph in different colors.
It can also log received data as CSV.

You have to send over bluetooth data as ASCII separated by commas - thats all

screen-0.jpg
 
Nfer said:
HughF said:
It is as close as you will get to the marcoq code whilst having all the benefits of the work Casainho has done on the firmware recently.

Is this the latest version https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.13?
Is it compatible with the display firmware 1.0.0 or do I have go back to the 0.8?
Nfer, please move this question over to the other thread where it is the correct place to discuss the details of the other fork...
 
Are you sure that the cadence is not the 4th graph and the weight the 3rd one?

casainho said:
Finally I was able to make SW102 firmware to send data over Bluetooth as being a serial port - this help me a lot to debug and can be great if anyone want to develop the mobile app.

So, I was logging the:
1. ADC torque sensor
2. pedal position (from 1 to 40, where 1 is like 0 degrees and 4 360 degrees)
3. cadence
4. pedal weight

So, that was in my bicycle. Each point is measure at every 50ms. Observations:
1. pedal position ideally would always be at 10 and 30, when cranks are horizontal with the ground. As we can see, the measurements are take all over the place, including on moments the value should be 0 (cranks at vertical).

2. since pedal position is very wrong, I would expect ADC torque sensor signal also very wrong although it is not I am guess that is because the hardware has the low pass filter. Still, I think the signal could be improved if reading at position 10 and 30, mainly after mid to high cadence.

3. the calculated pedal weight seems to have a big delay or be wrong, if we compare the torque sensor ADC values to the calculated pedal weigh

4. the cadence is going to 0 value!! My bicycle is full suspension one, so, I need to check again all this after disabling the feature of Cadence fast stop. Due to all the delays on the system, I could not yet understand that cadence was failing!!



 
agphil said:
Are you sure that the cadence is not the 4th graph and the weight the 3rd one?
You are right!!! thanks.
 
@casainho: here is my branch with the uart tx interrupt activated:
https://github.com/benno90/TSDZ-Smart-EBike
This worked well with my VLCD display. This as port from my branch and is not tested.

Regarding the adc reading:
If my interpretation of the description in the manual is correct, then it is wrong to read
the buffered register as it is currently done. Something like this would be correct:
Code:
#define UI16_ADC ((ADC1->DRH << 2) | ADC1->DRL)
ui16_g_adc_battery_current = UI16_ADC;
This way you get the value you converted during the single conversion mode.
It seems to me that the current implementation just reads the value of the last scan conversion -> i.e.
not the one you explicitly trigger in the interrupt.


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.
Thanks for the clarifications. The original Firmware turns the controller off after some time. However, i could not yet work out the mechanism. Any hint is welcome.

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.
Do you think polling the pin in the pwm interrupt or the 4ms loop would be an option?
If it is on high state, just set the duty cycle to zero and raise the over current error.
 
benno said:
@casainho: here is my branch with the uart tx interrupt activated:
https://github.com/benno90/TSDZ-Smart-EBike
This worked well with my VLCD display. This as port from my branch and is not tested.

It is also better to add the following call at the end of the uart_init() function in order to run the TX interrupt with lower priority than the other interrupts.
ITC_SetSoftwarePriority(UART2_TX_IRQHANDLER, 0x02);
 
Back
Top