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

Info for the developers: marcoq version had a sort of major update that includes also the VLCD5 compatibility and the backwards resistance sorted.
He released it only on the Italian forum by now, for the first tests. He will share on GitHub after the testing.

In short the criteria for the backwards resistance is: bike is not moving (speed=0) and no forces on pedals.
Unfortunately I didn't test myself due to lack of time but a user reported that the resistance is now gone.

I guess it worth to give it a look, you can see the code here:http://www.jobike.it/Public/data/ma...M0.18.A_and_TSDZ2_Configurator_Beta_0.3.0.zip

Cheers
 
thineight said:
In short the criteria for the backwards resistance is: bike is not moving (speed=0) and no forces on pedals.
Unfortunately I didn't test myself due to lack of time but a user reported that the resistance is now gone.
Many thanks for the update!!!

I was looking at the code and it always disable PWM output and we want to disable motor current and vice-versa. It can be like when we press brakes, or any other situation like changing to assist level 0. I am a bit afraid afraid of this because there can be problems when enable PWM output if motor is already rotating... well, but maybe that case is unlike to happen due to the motor clutch... or let's say the motor is rotating at high speed and a quick hit the brakes and release them, I don't know if motor really stops before next start... or maybe simple the current controller takes care of motor current peaks on that situation. Anyway, it is important to have brave developers and testers and if we get good feedback on this approach, we should use it!!!

I guess this approach can be a problem with coast brake TSDZ2 motor...??
 
I found this new video on youtube channel of Buba, seems he is busy recently :)

[youtube]LVqvzC2e2sE[/youtube]
 
NIPSEN said:
The problem is that you divide torque by voltage to calculate the setpoint current. The consequence is that the current setpoint will be underestimated.
...I am very sorry for not sharing my point of view effectively.
Indeed. :wink:
The behaviour we want to have is

Code:
Pmotor = Assistfactor * Phuman

We ignore that the electrical power is not equal to the mechanical power in a BLDC. Especially at low speeds.
https://www.ebikes.ca/tools/simulator.html

You are right, that the speed can be eliminated in a system with a fixed ratio of pedal speed and motor speed, if you set
Code:
Phuman = speed pedal * torque pedal 
Pmotor = speed motor * torque motor
speed motor = constant* speed pedal
torque motor = Imotor * constant
Imotor = k * torque pedal
Imotor means the motor current that follows

Code:
motor current = battery current / duty cycle

We would have to control the motor current, not the battery current to follow your suggestion.

regards
stancecoke
 
thineight said:
marcoq version had a sort of major update that includes also the VLCD5 compatibility and the backwards resistance sorted.
He released it only on the Italian forum by now, for the first tests.

He followed the suggestion to disable the PWM :D

Code:
#if ENABLE_BACKWARDS_RESISTANCE_OFF
    // stop pwm motor:
    if((configuration_variables.ui8_assist_level_factor_x10 == 0)||
    	(ui8_walk_assist_flag == 1)||
    	((ui16_wheel_speed_x10 == 0)&&
			(ui8_torque_sensor_raw == 0)&&
			(ui8_pas_cadence_rpm == 0)&&
			(ui16_motor_speed_erps == 0)))
  	{
  		if(!ui8_pwm_stopped)
  		{
  			// stop pwm...
  			pwm_stop();  			
				ui8_pwm_stopped = 1;
  			ui8_pwm_started = 0;
  		}
  	}

regards
stancecoke
 
tbyt2000 said:
Any suggestions?
I’ve done both the 8 & 6 pin conversions and followed the wiring as per “the Wire KT LCD3 to TSDZ2” diagram successfully so I’m puzzled that you had to reverse the tx and rx wires. The brake and throttle wires will be loose; they should be disconnected?

I also thought something had gone wrong with the motor (36v 350w 8 pin with 48v battery) but I had the bike in a stand without the chain and was not applying enough torque to get it to assist. I worked round it by first trying the walk assist which worked then cruise which also worked.

Have you gone through the configuration settings eg battery min?
 
stancecoke said:
thineight said:
marcoq version had a sort of major update that includes also the VLCD5 compatibility and the backwards resistance sorted.
He released it only on the Italian forum by now, for the first tests.

He followed the suggestion to disable the PWM :D

Code:
#if ENABLE_BACKWARDS_RESISTANCE_OFF
    // stop pwm motor:
    if((configuration_variables.ui8_assist_level_factor_x10 == 0)||
    	(ui8_walk_assist_flag == 1)||
    	((ui16_wheel_speed_x10 == 0)&&
			(ui8_torque_sensor_raw == 0)&&
			(ui8_pas_cadence_rpm == 0)&&
			(ui16_motor_speed_erps == 0)))
  	{
  		if(!ui8_pwm_stopped)
  		{
  			// stop pwm...
  			pwm_stop();  			
				ui8_pwm_stopped = 1;
  			ui8_pwm_started = 0;
  		}
  	}

regards
stancecoke

Yes but not as you suggested to enable PWM, when erps = 0. For me seems dangerous but let's see...

stancecoke said:
zappan said:
I hope there is a solution for this as this is the only mid-drive motor that supports coaster brakes. This is crucial on hand-cycles for riders who do not have the use of their hands for braking. The Flexible Open Source Firmware is otherwise perfect for handcycles because the torque sensitivity can be adjusted according to the strength of the rider.

That's quite easy to implement in the ebike_app.c, just disable the PWM if erps = 0 and no power wanted:

Code:
if(erps == 0 && battery_target_current == 0)TIM1_CtrlPWMOutputs(DISABLE);

and enable PWM again, if power is wanted:

Code:
if(erps == 0 && battery_target_current != 0)TIM1_CtrlPWMOutputs(ENABLE);

regards
stancecoke
 
Rydon said:
casainho said:
Rydon, please test the new version: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta1
Ok, is there any documentation for the menus in version 19?
casainho said:
When pedaling backwards, motor power is cut off. Note that the motor resistance is still there.
If you know the motor resistance is still there, what am I testing?
casainho said:
Can you please tell if you expect that motor goes to 0 velocity before goes backwards when user brakes with coast brakes?? I am thinking on the next step...
By velocity do you mean rpms? Yes, the motor completely stops before pedaling backward.

That motor I sent you that got stuck in customs was a coaster brake motor. They returned it after about 6 months. Should I try sending it again?
No documentation yet.

Maybe you are right, I should add the PWM disable BUT I am afraid it can burn the controller. The code to disable the PWM is being applied to regular TSDZ2 version that should not rotate backwards..

Yes, I mean the erps value seen on LCD3 (menu 12).
So, to resume. The motor is direct drive with the pedals and the bicycle as a free wheel on the wheel, with the coast brake.

1. Motor mode (torque and positive cadence): previous of when user decides to brake, the user is pushing forward the pedals and we have pedal cadence and torque

2. Motor stop (torque = 0 and cadence = 0): user decides to brake, the user quickly decide to stop pedaling and immediately next will push them backwards. Even if motor keeps pushing the pedals forwards, the user stop to do torque and cadence. Here I think motor assistant will stop and the motor may take a fraction of a second to stop: erps = 0

3. Motor stop but coast braking (torque positive or 0 and cadence negative or 0 - running backwards): user is pushing pedal backwards:
-- since it is pushing, there is torque signal and it is positive (??) -- can you please validate again?? check the rest value of torque sensor ADC and see if it increases or decreases when pushing backwards.
-- since the movement is small, the cadence value will be either 0 or we will have the indication of pedaling backwards. We can't trust on later, maybe we need to signal that it was backwards and consider that state until it runs again forwards.
I think may be tricky to detect when coast braking, because it is very small backward movement.

-- does the motor runs backwards when user is pushing pedals backwards?? does the motor stops for a fraction of time that we can measure it or it is so fast the transition from forward <-> backwards that we can not detect it?? because we can disable PWM at anytime but we should enable only when motor erps = 0.

Rydon, can you help on this questions??

About sending a motor for coast brake, I do not have any bicycle for development nor even with a coast brake. Maybe we should try to make the development for now like this.
 
casainho said:
tbyt2000 said:
I'm not sure this is the correct thread but I have a problem with my TDZS2 and I'm hoping someone can give me some pointers.
I have the 36v 8-pin version with VLCD5 which worked fine.
I decided to hook-up a KT-LCD3 and load the open-source firmware.
I bought a new 8-pin cable and soldered it directly onto the KT-LCD motherboard using the pinout in https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Wire-KT-LCD3-to-TSDZ2 (although I had to reverse Tx and Rx).
The solder points on the KT-LCD3 are close together so I checked for shorts between them. I was getting continuity between connectors 1 and 2 ('(P+) battery voltage' and 'Vin') but there was definately no solder connecting them so I assumed this was as per design.

I hooked it all up and flashed the Open Source firmware (18.2) on the LCD3 and TSDZ2 and everything appeared to work (display, speed indicator etc) but there was no powered assistance.

I hooked the VLCD5 back and re-flashed the TDSZ2 to factory firmware but now I have no speed indicated and no power-assist :confused:

Any suggestions?
Go back to OpenSource firmware and tell us the values you see in 12 menu of options. We need to know if torque sensor is working and pwm value

Hi folks. firstly, thanks to you all for your feedback. Great community!
To be honest, I had resigned myself to replacing the controller. As far as I could tell - rolling back to a known good configuration (the VLCD5 with factory firmware), and it not working, confirmed I had damaged the motor.
Also @vailbiker pointed out that you can still short the controller - even if the battery isn't connected. I didn't cut the cable on my VLCD5 (I bought a new cable) but after my failed tests I did try to straighten a pin on the controller lead with a screwdriver and got a dramatic spark - even with the battery disconnected! From what vailbiker had said I was sure that was the final nail in the coffin.

@casainho asked me for some diagnostic stats, however, and when a rock-star takes the time to ask you something you respond! I flashed back to 18.2 and started getting the readings. I noticed when I put pressure in the pedals the motor was whining quietly - a good sign!

@James Broadhurst had suggested checking the battery config so I did. 0 Amps! I'm afraid I am that RTFM guy :oops:
Works a treat now. That new firmware really gives your bike a shove!

Worth noting that rolling back to VLCD5 doesn't appear to work - but who cares!

Thanks again for all your help folks. Very much appreciated!
 
Hi,

I was reading the source code, really very interesting in passing, and I found a small typo, when you calculated the pedal torque for each unit of torque measurement, you considered a gravity of 9.18 instead of 9.81m/s².

This gives a value of 55 instead of 52 for #define PEDAL_TORQUE_X100 :wink:
 
stancecoke said:
NIPSEN said:
The problem is that you divide torque by voltage to calculate the setpoint current. The consequence is that the current setpoint will be underestimated.
...I am very sorry for not sharing my point of view effectively.
Indeed. :wink:
The behaviour we want to have is

Code:
Pmotor = Assistfactor * Phuman

We ignore that the electrical power is not equal to the mechanical power in a BLDC. Especially at low speeds.
https://www.ebikes.ca/tools/simulator.html

You are right, that the speed can be eliminated in a system with a fixed ratio of pedal speed and motor speed, if you set
Code:
Phuman = speed pedal * torque pedal 
Pmotor = speed motor * torque motor
speed motor = constant* speed pedal
torque motor = Imotor * constant
Imotor = k * torque pedal
Imotor means the motor current that follows

Code:
motor current = battery current / duty cycle

We would have to control the motor current, not the battery current to follow your suggestion.

regards
stancecoke

Thank you stancecoke for your explanations, I continue to improve my understanding of the source code, I still have a little trouble distinguishing the difference between battery current and motor current, but I keep persevering.

Regards,
NIPSEN
 
NIPSEN said:
Thank you stancecoke for your explanations, I continue to improve my understanding of the source code, I still have a little trouble distinguishing the difference between battery current and motor current, but I keep persevering.
Motor current would be the motor phase currents but the hardware can only measure the current on the battery side -- this is very typical on cheap ehike motor controllers.

Read the PDF on this link: https://opensourceebikefirmware.bitbucket.io/development/heets_and_application_notes--Endless-sphere.com_forum_messages--2018.02.20_-_Reading_motor_phase_current_from_the_DC_link_current_(shunt).html

And look at the other notes about motor controller there.
 
Thank you for taking the time to share these very informative documents, I am discovering an exciting field.

I've read STM document (2,5 times) and your measurement, that's what I remember:

_ The current in the phase is not constant during the whole PWM On, so it is interesting to measure the current in the middle of the PWM to know the average current. But that's not the case with our cheap controller.

_ The phase current is a fraction of the battery current (duty cycle).

_ Our cheap controller only measures battery current.

After reading the code, I notice that you control the battery current by modulating the duty cycle.

I think the torque of the motor is proportional to the battery current.
 
NIPSEN said:
I think the torque of the motor is proportional to the battery current.

No, this is definitivly wrong. The torque is proportional to the quadrature part "iq" of the motor current, (motor current = battery current / dutycycle). The direct part "id" produces no torque but only heat and is controlled to zero in a field oriented control (FOC).

You have to do the park/clark-transformations to get iq and id from the phase currents. There is a lot of literature available e.g. here:
https://www.st.com/content/ccc/resource/technical/document/user_manual/5e/5e/d2/cb/07/35/45/a6/CD00298474.pdf/files/CD00298474.pdf/jcr:content/translations/en.CD00298474.pdf

In our code, we use a simplifyed way of FOC by controlling the zero-crossing of a single phase current.

regards
stancecoke
 
I managed to do some good testing of 0.18.2 in the past 3 weeks.
A strange thing that I noticed is that in some cases even if the human power increases, the motor power in W drops. This happens at higher speeds. Also if I use assist of 0.6 and assist of 4 it is almost same difficulty to pass 42-43 km/h.
Scenario:
- Setup: run 0.6 assistance, speed 35km/h
- Start to press harder maintaining the cadence
- Screen shows a drop from 400w to 300w

Any ideas? It looks like the easier you press the harder you are assisted.
 
stancecoke said:
In our code, we use a simplifyed way of FOC by controlling the zero-crossing of a single phase current.
You mean that on KT motor controllers because on TSDZ2 is even different the FOC implementation.

Also, on KT there is hardware to fast read the motor total phase current and so we can control it.

On TSDZ2, there is no such hardware and motor total phase current can be calculated as said before: motor current = battery current / duty cycle. And the battery current we can read has a low pass filter and so we read only slow changes, so we can't control powerful motors as KT controllers can. Anyway, TSDZ2 controller hardware works perfectly for the TSDZ2 motors, which are not so powerful -- because KT motor controllers hardware are both for small ebike power motors up to powerful trikes/small cars: 0.25kW version up to 5kW (72V, 70A, 24 mosfets).
 
maximusdm said:
I managed to do some good testing of 0.18.2 in the past 3 weeks.
A strange thing that I noticed is that in some cases even if the human power increases, the motor power in W drops. This happens at higher speeds. Also if I use assist of 0.6 and assist of 4 it is almost same difficulty to pass 42-43 km/h.
Scenario:
- Setup: run 0.6 assistance, speed 35km/h
- Start to press harder maintaining the cadence
- Screen shows a drop from 400w to 300w

Any ideas? It looks like the easier you press the harder you are assisted.
At higher speeds you may be near the limit of motor speed. Please look on LCD3 for the motor erps speed and the PWM duty-cycle value. If PWM duty-cycle is like 250 at that situations, then you are on the limit of the motor and the energy that flows to the motor drops. You can get the max energy flow to the motor at near 0 speed of the motor and vice-versa.
 
I am definitely not hitting the max cadence because in that case the motor cuts the power to 0.
I will check the values you mentioned on my way back from work today and come back with the info.
 
stancecoke said:
casainho said:
on TSDZ2 is even different the FOC implementation.

Ah, I remember, you calculate the advance angle from battery current and erps :)
And here are the comments I wrote on TSDZ2 firmware sources, including the part to calculate the total phase current, as did mention before:

Code:
  // FOC implementation by calculating the angle between phase current and rotor magnetic flux (BEMF)
  // 1. phase voltage is calculated
  // 2. I*w*L is calculated, where I is the phase current. L was a measured value for 48V motor.
  // 3. inverse sin is calculated of (I*w*L) / phase voltage, were we obtain the angle
  // 4. previous calculated angle is applied to phase voltage vector angle and so the
  // angle between phase current and rotor magnetic flux (BEMF) is kept at 0 (max torque per amp)

  // calc I phase current
  if (ui8_duty_cycle > 10)
  {
    ui16_temp = ((uint16_t) ui8_adc_battery_current_filtered_10b) * ADC_BATTERY_CURRENT_PER_ADC_STEP_X512;
    ui32_i_phase_current_x2 = ui16_temp / ui8_duty_cycle;
  }
  else
  {
    ui32_i_phase_current_x2 = 0;
  }
 
stancecoke said:
NIPSEN said:
I think the torque of the motor is proportional to the battery current.

No, this is definitivly wrong.

This is not wrong, it is an approximation, and it is as accurate as the one currently used.
 
NIPSEN said:
This is not wrong, it is an approximation, and it is as accurate as the one currently used.

No. The way it is implemented at the moment, it's based on a proper physical correlation, with the known issue of ignored losses.

With your suggestion, it's just not correct, especially at low duty cycles and low speed.

regards
stancecoke
 
Hello Everyone,

I would like to thank you for doing such a great job!

For those interested in this solution for future, I wanted to confirm where I bought parts for TSDZ2 OpenSource Firmware - I have chosen Ebird Store (AliExpress), for now looks like is the cheapest place to buy kit.
1. Kit 48V 500W + front 6V light, 8pin connector, speed sensor with extension port (for controller and light, you can damage light port like jbalatube on YouTube, resign from lights and you don't need to buy cable to cut off to program TSDZ2 - this is the cheapest solution I suppose): https://www.aliexpress.com/item/FREE-SHIPPING-NEW-Tongsheng-TSDZ2-ebike-Kit-Mid-Motor-Torque-Sensor-36V-48V-Ebike-Motor-Throttle/32834396644.html
2. Cable to cut off and to program TSDZ2 in case you want to save light(s) working: https://www.aliexpress.com/item/tongsheng-tsdz-speed-sensor-extension-cable-110cm-length/32833464583.html
3. Brake sensors to cut off and connect with kit: https://www.aliexpress.com/item/BAFANG-8Fun-Mechanical-Hydraulic-Brake-Sensor-BBS01-BBS02-BBSHD/32794811566.html
(Don't play with magnets, I damaged by mistake by hitting themselfs - are strong, but I bought similar locally in my country in two days.)
4. The same Ebird Store shop has KT-LCD3 but I bought from local country shop in EU (little bit more expensive here).
5. ST-Link I bought locally in EU with additional 10 wires (kit by default has only 4 for one microcontroller, we need for 2).

I selected UPS shipping method ($16.84), asked for reducing shipping price for other small parts (Ebird Store did it), and I received kit in 6 calendar's days in EU.

And... I successfully flashed these things! :) TSDZ2 flashed at first time, but KT-LCD3 in a second try - probably due to too long wires.

Currently I am a step before installing kit on the bike. Could you advise me how many milliohms is recommended to set for my battery (13s5p Sanyo 17,5A NCR18650GA 840Wh)? I set default 130 but I guess this number have to be different.
 
bs47G said:
Currently I am a step before installing kit on the bike. Could you advise me how many milliohms is recommended to set for my battery (13s5p Sanyo 17,5A NCR18650GA 840Wh)? I set default 130 but I guess this number have to be different.

It seems that the internal resistance of one cell is 40mOhm, as you have 13 in series, this gives a total resistance of 520mOhm.
 
NIPSEN said:
bs47G said:
Currently I am a step before installing kit on the bike. Could you advise me how many milliohms is recommended to set for my battery (13s5p Sanyo 17,5A NCR18650GA 840Wh)? I set default 130 but I guess this number have to be different.
It seems that the internal resistance of one cell is 40mOhm, as you have 13 in series, this gives a total resistance of 520mOhm.
5 in parallel, 13 in serie : 105 mOhms
 
Back
Top