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

[jur]

@jur, are that values for 48v or 36v motor?

48V.

I have assumed that the motor is Y.

 

[casainho]

@jur, are that values for 48v or 36v motor?

48V.

I have assumed that the motor is Y.

Oh, my motor for development is 36V...

 

[jur]

@jur, are that values for 48v or 36v motor?

48V.

I have assumed that the motor is Y.

Oh, my motor for development is 36V...

Let's make some assumptions and deductions to get you going:
1. From my job I know that lower voltage electromagnetic components have fewer turns per winding. The number of turns is directly proportional to applied voltage. So, the ratio of turns between 36V and 48V is 36/48 = 3/4.
2. Inductance is proportional to the square of number of turns, so the ratio of inductance is therefore 3*3/4/4=9/16.
3. Assume the 36V motor follows these rules. therefore, its inductance is
L = 135u * 9/16 = 76u.
4. Resistance is directly proportional to number of turns, so the 36V motor resistance is
R = 0.125 * 3/4 = 0.094 ohm

Use these deduced values for development. The worst that can happen, is the optimum phase will be out by some amount. Between the 2 of us testing, we can tweak that experimentally to hone in on the correct value for L. I will give you guidance on how to tackle this.

 

[casainho]

Oh, my motor for development is 36V...

Let's make some assumptions and deductions to get you going:
1. From my job I know that lower voltage electromagnetic components have fewer turns per winding. The number of turns is directly proportional to applied voltage. So, the ratio of turns between 36V and 48V is 36/48 = 3/4.
2. Inductance is proportional to the square of number of turns, so the ratio of inductance is therefore 3*3/4/4=9/16.
3. Assume the 36V motor follows these rules. therefore, its inductance is
L = 135u * 9/16 = 76u.
4. Resistance is directly proportional to number of turns, so the 36V motor resistance is
R = 0.125 * 3/4 = 0.094 ohm

Use these deduced values for development. The worst that can happen, is the optimum phase will be out by some amount. Between the 2 of us testing, we can tweak that experimentally to hone in on the correct value for L. I will give you guidance on how to tackle this.

Great!!

My plan for next step is the following: use the same code and current code for Kunteng controllers but without FOC enabled. This means using a fixed angle and I expect to get a silent running motor at lower speed and without load, must be lower noise similar to original firmware and more silent than current 6 steps / square wave.

Then, I can start implement the algorithm for this system so we can get "FOC".

 

[jur]

That would be great. I am working on getting a simulation running on my PC based on Colter's work. It's slow going because of other commitments.

 

[casainho]

Here is the config.h file on firmware were the user should choose which options do prefer.

Nothing is implemented yet for TSDZ2 but all of that is implemented for Kunteng motor controllers and should be very easy to put working on TSDZ2:

/*
 * TongSheng TSDZ2 motor controller firmware/
 *
 * Copyright (C) Casainho, 2018.
 *
 * Released under the GPL License, Version 3
 */

#ifndef CONFIG_H_
#define CONFIG_H_

// This file is the firmware configuration for the TSDZ2 motor controller,
// to run the 2 different available motors of 36V or 48V motor,
// and from 24V battery (7S) up to 52V battery pack (14S).

// *************************************************************************** //
// THROTTLE
//
// choose between following modes. You can choose for instance TORQUE_SENSOR_AND_THROTTLE and if you have
// throttle connected, the output signal used to control the motor will be the max value of both torque sensor or throttle
#define EBIKE_THROTTLE_TYPE	EBIKE_THROTTLE_TYPE_TORQUE_SENSOR_AND_THROTTLE
//#define EBIKE_THROTTLE_TYPE	EBIKE_THROTTLE_TYPE_PAS_AND_THROTTLE
//#define EBIKE_THROTTLE_TYPE EBIKE_THROTTLE_TYPE_THROTTLE_ONLY

// next, choose one of the both (only apply to throttle and/or PAS)
//#define EBIKE_THROTTLE_TYPE_THROTTLE_PAS_PWM_DUTY_CYCLE // direct PWM duty_cycle control, important for developers
#define EBIKE_THROTTLE_TYPE_THROTTLE_PAS_CURRENT_SPEED // control using motor current/torque and/or wheel speed

// next, if enabled, output of torque sensor algorithm is the human power (torque * cadence) other way will be the same as the torque signal
// (only apply to torque sensor)
#define EBIKE_THROTTLE_TYPE_TORQUE_SENSOR_HUMAN_POWER

// PAS configurations
// MAX cadence, where the output value of PAS processiing will be the max value
#define PAS_MAX_CADENCE_RPM 	90
// *************************************************************************** //

// *************************************************************************** //
// LCD
// the firmware supports the original LCD and the more complete Kunteng LCD3 and LCD5
#define LCD_TYPE LCD_TYPE_TSDZ2
#define LCD_TYPE LCD_TYPE_KUNTENG // shows battery voltage, motor real time usage power, etc

// you can tune LCD assist level
#define ASSIST_LEVEL_0			0.00
#define ASSIST_LEVEL_1 			0.44
#define ASSIST_LEVEL_2 			0.66
#define ASSIST_LEVEL_3 			1.00
#define ASSIST_LEVEL_4 			1.5
#define ASSIST_LEVEL_5 			2.25
// *************************************************************************** //

// *************************************************************************** //
// BATTERY
// Choose your battery pack voltage

// the cells number can be a custom value from 7S up to 14S, choose the value of your battery pack
#define BATTERY_LI_ION_CELLS_NUMBER	 7 // 7S = 24V battery pack
//#define BATTERY_LI_ION_CELLS_NUMBER	10 // 10S = 36V battery pack
//#define BATTERY_LI_ION_CELLS_NUMBER	13 // 13S = 48V battery pack
//#define BATTERY_LI_ION_CELLS_NUMBER 14 // 14S = 52V battery pack

// This is the current that motor will draw from the battery
// Higher value will give higher torque and the limit of the controller is 16 amps
#define ADC_BATTERY_CURRENT_MAX		224 // (14 ADC bits step per 1 amp) so, 224 for 16 amps

// Considering the follow voltage values for each li-ion battery cell
// State of charge 		| voltage
#define LI_ION_CELL_VOLTS_100 	4.06 // this value is used to help finding the battery SOC
#define LI_ION_CELL_VOLTS_80 		3.93 // this value is used to help finding the battery SOC
#define LI_ION_CELL_VOLTS_60 		3.78 // this value is used to help finding the battery SOC
#define LI_ION_CELL_VOLTS_40 		3.60 // this value is used to help finding the battery SOC
#define LI_ION_CELL_VOLTS_20 		3.38 // this value is used to help finding the battery SOC
#define LI_ION_CELL_VOLTS_10 		3.25 // this value is used to help finding the battery SOC
#define LI_ION_CELL_VOLTS_0 		3.00 // this value is used to help finding the battery SOC and is the minimum value after which the firmware don't ask more current to battery, to run the motor
// *************************************************************************** //

// *************************************************************************** //
// MOTOR CONTROLLER

// Choose PWM ramp up/down step (higher value will make the motor acceleration slower)
//
// For a 24V battery, 25 for ramp up seems ok. For an higher voltage battery, this values should be higher
#define PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP	25
#define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP	10
// *************************************************************************** //

// *************************************************************************** //
// MOTOR

// Choose some parameters for your motor (if you don't know, just keep the following original values because they should work ok)
//
// This value should be near 0.
// You can try to tune with the whell on the air, full throttle and look at batttery current: adjust for lower battery current
#define MOTOR_ROTOR_OFFSET_ANGLE 0

// This value is ERPS speed after which a transition happens from sinewave no interpolation to have
// interpolation 60 degrees and must be found experimentally but a value of 25 may be good
#define MOTOR_ROTOR_ERPS_START_INTERPOLATION_60_DEGREES 25
// *************************************************************************** //

#endif /* CONFIG_H_ */

 

[casainho]

I updated the code for the motor with SVM -- now it should run silent at low speeds and low current, as "FOC" is not implemented yet.
I did a "copy-paste" from our firmware for Kunteng motor controllers. The mainly different is that I removed the FOC code as TSDZ2 motor controller don't do it in the same way as Kunteng. I also deleted the code for regen, as TSDZ2 can't regen (it can't even measure negative current/regen).

The code is not finished (lacks LCD communications for instance) and already uses 12kbytes!! I wounder how the Chinese engineers could get the full firmware on the 16kbytes flash memory!! -- our luck is that we can use in addition the other "hiden" 16kbytes of flash memory, so in total we have 32kbytes.

For developers or curious, here is the code: https://github.com/OpenSource-EBike-firmware/TongSheng_TSDZ2_motor_controller_firmware

 

[casainho]

I finally opened took out the board - it was not hard after all and the boards seems fine.

So, there is a XL7005 (I think is sued another on top of the board):
- Wide 5V to 80V Operation Voltage
- Output Adjustable from 1.25V to 20V
General Description
The XL7005A is a 150KHz fixed frequency
PWM buck (step-down) DC/DC converter,
capable of driving a 0.4A load with high
efficiency, low ripple and excellent line and
load regulation. Requiring a minimum
number of external components, the regulator
is simple to use and include internal
frequency compensation and a
fixed-frequency oscillator.
The PWM control circuit is able to adjust the
duty ratio linearly from 0 to 100%. An enable
function, an over current protection function
is built inside. When output short protection
function happens, the operation frequency
will be reduced from 150KHz to 45KHz. An
internal compensation block is built in to
minimize external component count.

The other IC is what I think, the popular LM358 - Dual-Operational Amplifier. This must for sure being amplifying the shunt voltage, giving the battery current (at least looking at the signal on oscilloscope).
So, 1 channel is used for the amplification of shunt voltage. I wounder if the second channel is used and if so, for what.

 

[lizardmech]

On another thread I read that there were some doubts if this 8 bitter could implement a good and fast FOC. I haven't looked at the electronics but I'm wondering if it would be interesting to redesign the controller so it has a bit more juice. Like STM32F1/2/4. It allows for more heavy and faster calculations.

No, STM8 can't handle "traditional" FOC.

This project is not about design a controller but instead develop the firmware (the best, hopefully) for original motor controller. I was on another projects before were I dreamed with the idea of replacing the controller and found almost no one will want to mess with prototyping hardware and hardware is also a lot expensive to develop -- firmware/software on the other side is cheap and more people can join the project and develop, because the tools for development are cheap, unlike developing hardware.

That's not true these days, there's services like https://macrofab.com/ and most of the chinese PCB suppliers now offer small run assembly options. You probably can't get them as cheap as the chinese ebike controllers if you use proper parts but sub $100 motor controllers should not be difficult to produce.

 

[fantasy2]

On another thread I read that there were some doubts if this 8 bitter could implement a good and fast FOC. I haven't looked at the electronics but I'm wondering if it would be interesting to redesign the controller so it has a bit more juice. Like STM32F1/2/4. It allows for more heavy and faster calculations.

No, STM8 can't handle "traditional" FOC.

This project is not about design a controller but instead develop the firmware (the best, hopefully) for original motor controller. I was on another projects before were I dreamed with the idea of replacing the controller and found almost no one will want to mess with prototyping hardware and hardware is also a lot expensive to develop -- firmware/software on the other side is cheap and more people can join the project and develop, because the tools for development are cheap, unlike developing hardware.

That's not true these days, there's services like https://macrofab.com/ and most of the chinese PCB suppliers now offer small run assembly options. You probably can't get them as cheap as the chinese ebike controllers if you use proper parts but sub $100 motor controllers should not be difficult to produce.

It's quite a bit of work and more cumbersome to remove the old board and replace it with a new one. Most users aren't interested in that. They prefer just flashing new firmware.

Regarding the size of the code:
As said before, floats are expensive and slow and have rounding errors. Did you set code optimisation levels for speed or size?

 

[casainho]

That's not true these days, there's services like https://macrofab.com/ and most of the chinese PCB suppliers now offer small run assembly options. You probably can't get them as cheap as the chinese ebike controllers if you use proper parts but sub $100 motor controllers should not be difficult to produce.

It's quite a bit of work and more cumbersome to remove the old board and replace it with a new one. Most users aren't interested in that. They prefer just flashing new firmware.

Regarding the size of the code:
As said before, floats are expensive and slow and have rounding errors. Did you set code optimisation levels for speed or size?

We already got that feedback from TSDZ2 users, no one want touch on the motor internals and for instance, use an external controller like the KT that we already have our firmware working.
Luckily, TSDZ2 can be programmed easily from the outside, just connecting some wire pins. On KT controllers, users need to open the controller and solder wires to the board... but at least board is much more accessible than on TSDZ2.

As for code size, I am using recently SDCC 3.7.0 and I saw after a big improvement of 40% code reduction!! But I went to enable the flags for size optimization and got the same, so probably the flag is already enable by default.

Fantasy2, you seem to be experienced, when do you join the firmware development?

 

[fantasy2]

Fantasy2, you seem to be experienced, when do you join the firmware development?

Battery is on the way. However motor is not ordered yet. I was hoping to get info on that new Lingbei LB01 motor. Bit more torque(90Nm), less noise(<52dB) and more solid nylon gear(deeper teeth)... It sounds really appealing. If I don't get new info, I'll get the TSDZ2.

 

[lizardmech]

That's not true these days, there's services like https://macrofab.com/ and most of the chinese PCB suppliers now offer small run assembly options. You probably can't get them as cheap as the chinese ebike controllers if you use proper parts but sub $100 motor controllers should not be difficult to produce.

It's quite a bit of work and more cumbersome to remove the old board and replace it with a new one. Most users aren't interested in that. They prefer just flashing new firmware.

Regarding the size of the code:
As said before, floats are expensive and slow and have rounding errors. Did you set code optimisation levels for speed or size?

We already got that feedback from TSDZ2 users, no one want touch on the motor internals and for instance, use an external controller like the KT that we already have our firmware working.
Luckily, TSDZ2 can be programmed easily from the outside, just connecting some wire pins. On KT controllers, users need to open the controller and solder wires to the board... but at least board is much more accessible than on TSDZ2.

As for code size, I am using recently SDCC 3.7.0 and I saw after a big improvement of 40% code reduction!! But I went to enable the flags for size optimization and got the same, so probably the flag is already enable by default.

Fantasy2, you seem to be experienced, when do you join the firmware development?

Yeah for a mid drive with an integrated controller doesn't seem worthwhile to replace hardware, on the external controllers running more powerful bikes open source hardware would be easy these days.

 

[casainho]

I got the motor running using SVM and so it is much more silent than using block commutation/6 steps (it is near silent as original firmware and also uses less current when running as seen on the video - 1.02A VS 1.25A). See the comparison between the 2 videos showing motor running with block commutation VS SVM.

Next step is try implementing the calculations for FOC...

Block commutation:
[youtube]O9shbfQ9hHk[/youtube]

SVM:
[youtube]EonFwTk2cs8[/youtube]

 

[casainho]

Now that I got TSDZ2 motor running silently at low current/unloaded, my next target is to implement FOC!! See the practical results a tester got with FOC disabled VS FOC enable, on our firmware running on KT motor controllers:

Also, I tested with FOC disabled, with motor current of 3.5 A and found almost no difference in the results: almost the same battery current and speed - I guess a difference may be seen at higher currents, maybe I will try again with 10A using my battery instead of the lab power supply.

FOC definitely makes a difference. I found (on training roller, wheel heavily loaded) with FOC disabled full throttle could only achieve 14mph, with FOC re-enabled this rose to 18.5mph with the motor sounding much more lively.

An increase of 4.5mph/7.2km/h with motor heavily load is a BIG gain!!

 

[casainho]

I hope you guys never get on the LCD the "error 3: controller failure":



because I get it and the controller is not working anymore -- seems the mosfets driver IC is cooked as it get's very hot to touch...
That IC, FAN7888, costs 7€ on Ebay. Don't know if I will try to replace or just use a new controller and use this one for repair parts.

 

[casainho]

Now that my controller board is not working, I decided to give a deep looking at it and found some good new information:

We already new that there was an ADC signal to measure battery current:

* PB5 (ADC_AIN5) | in | battery_current (14 ADC bits step per 1 amp; this signal amplified by the opamp 358)

Also found that there is a signal to protect from battery over current of about 22 amps. Also shunt should be of about 0.023 ohms resistance:

* The battery_current is measured using the LM385 opamp in an non inverting configuration. The pin 1 is the output and has a low pass filter.
* The pin 3 (+) has the signal input and pin 2 (-) has the feedback loop, composed of R1 = 11k and R2 = 1k.
* The gain is: (R1 / R2) + 1 = (11k / 1k) + 1 = 12.
* We know that 1 Amp of battery current is equal to 14 ADC 8 bits steps, so 1 Amp = (5V / 255) * 14 = 0.275V.
* Each 1 Amp at the shunt is then 0.275V / 12 = 0.023V. This also means shunt should has 0.023 ohms resistance.
* Since there is a transistor that has a base resistor connected throught a 1K resisitor to the shunt voltage, and also the base has
* another connected resistor of 27K, I think the transistor will switch on at arround 0.5V on the shunt voltage and that means arround 22 amps.
* The microcontroller should read the turned on transistor signal on PD0, to detect the battery_over_current of 22 amps.

Also, the microcontroller can disable the 5V voltage of the circuit and this way turn it of, including itself:

* PD4 | out | enable/disable 5V output of the circuit, meaning it can turn off all the system including the microcontroller itself

 

[casainho]

Finally!! I was able to disassembly the TSDZ2 motor controller original firmware.

The firmware is small, it should be possible for us (if we join our energies) to identify the code were battery voltage is configure in EEPROM, other codes, which codes the controller accepts sent by the LCD - can it accept configuration for current?? etc:

Original firmware disassembled file: https://opensourceebikefirmware.bitbucket.io/development_tsdz2/EmbeddedFiles/3-TSDZ2_original_firmware.asm

More info here: https://opensourceebikefirmware.bitbucket.io/development_tsdz2/Various--2018.04.18_-_original_firmware_and_debug_session_using_OpenOCD.html

 

[casainho]

Here is the file on google docs so anyone can put comments on sections that understand. For instance, I spotted a big array of values that seems like the same we use on KT, for the phase voltages SVM, but seems they are using a bigger array...

https://drive.google.com/file/d/10TKBj_eeEpHKlMHcyRwxi2huQ99P7OBt/view?usp=drivesdk

Original firmware file, etc is here: https://opensourceebikefirmware.bitbucket.io/development_tsdz2/Various--2018.04.18_-_original_firmware_and_debug_session_using_OpenOCD.html

 

[eyebyesickle]

Hi,

I wonder how easy it would be to use this:

https://eggbikes.com/eggrider-v2-display-android-iphone-bluetooth-mobile-app-e-bike-bafang-sondors-kunteng-lishui

with the TSDZ2. It is compatible with Kuteng controllers...



Also, BTW great progress. I look forward to being able to make an 'OPEN VOLTAGE' motor, where you can run any battery. Then instead of a battery meter, maybe we can just display volts instead!

Let me know if there is anything I can do to help progress!

Thanks

 

[casainho]

That would be great. I am working on getting a simulation running on my PC based on Colter's work. It's slow going because of other commitments.

About the Sin-1, seems the input limits are -1 up to 1. Let's say I have a IwL = 8.5 and a Vphase = 4.8, 8.5 / 4.8 = 1.77... how can I calc the Sin-1??

 

[jur]

That would be great. I am working on getting a simulation running on my PC based on Colter's work. It's slow going because of other commitments.

About the Sin-1, seems the input limits are -1 up to 1. Let's say I have a IwL = 8.5 and a Vphase = 4.8, 8.5 / 4.8 = 1.77... how can I calc the Sin-1??

You are right, the value must lie between -1 and 1. According to the pic I analyzed,

,

V must be bigger than IwL.

Even for pic 1 just before it, same holds.

 

[casainho]

That would be great. I am working on getting a simulation running on my PC based on Colter's work. It's slow going because of other commitments.

About the Sin-1, seems the input limits are -1 up to 1. Let's say I have a IwL = 8.5 and a Vphase = 4.8, 8.5 / 4.8 = 1.77... how can I calc the Sin-1??

You are right, the value must lie between -1 and 1. According to the pic I analyzed,

,

V must be bigger than IwL.

Even for pic 1 just before it, same holds.

Ok, I understand now. I am slowly returning to this project. I will start to run the motor with fixed 0 angle and printing out the various operations to validate that the values do increase when I increase motor speed and/or current.

 

[jur]

That would be great. I am working on getting a simulation running on my PC based on Colter's work. It's slow going because of other commitments.

About the Sin-1, seems the input limits are -1 up to 1. Let's say I have a IwL = 8.5 and a Vphase = 4.8, 8.5 / 4.8 = 1.77... how can I calc the Sin-1??

You are right, the value must lie between -1 and 1. According to the pic I analyzed,

,

V must be bigger than IwL.

Even for pic 1 just before it, same holds.

Ok, I understand now. I am slowly returning to this project. I will start to run the motor with fixed 0 angle and printing out the various operations to validate that the values do increase when I increase motor speed and/or current.

Actually, while cycling to work this morning I realised something important: We don't have the I to plug into IwL! That is actually an unknown quantity. The only thing we have is filtered average battery current.

So back to analysis for me...

 

[casainho]

Actually, while cycling to work this morning I realised something important: We don't have the I to plug into IwL! That is actually an unknown quantity. The only thing we have is filtered average battery current.

So back to analysis for me...

I is the motor phase current. Yes, we have only the battery current mesured on the shunt because the signal is low pass filteed on hardware.

But phase amplitude current should be I battery / duty-cycle, right??