KT motor controllers -- Flexible OpenSource firmware for BMSBattery S/Kunteng KT motor controllers (0.25kW up to 5kW)

I received my TSDZ2 motor today and I also officially started the project: Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Please join the thread here: https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818
 
Ok, TSDZ2 is out off topic but I would like to say that the firmware development started the best way possible!!! :) and thanks to all the knowledge earned on this project for Kunteng motor controllers.

casainho said:
VICTORY!!

The connection for firmware programming and debug are available on the connector for the speed sensor.

Seems that the original firmware is not read protected. I was able to read the option bytes, firmware and finally connect with OpenOCD for a debug session.

Please read my full notes here: https://opensourceebikefirmware.bitbucket.io/development_tsdz2/Various--2018.04.18_-_original_firmware_and_debug_session_using_OpenOCD.html

3-2.png


3-4.png
 
casainho said:
Ok, TSDZ2 is out off topic but I would like to say that the firmware development started the best way possible!!! :) and thanks to all the knowledge earned on this project for Kunteng motor controllers.

casainho said:
VICTORY!!

The connection for firmware programming and debug are available on the connector for the speed sensor.

Seems that the original firmware is not read protected. I was able to read the option bytes, firmware and finally connect with OpenOCD for a debug session.

Well done, that's a great start. I guess people will be much more inclined to try the 'new' firmware if they know they can restore the original fw if required.
Have subscribed to the thread, will be watching progress with interest..
 
Hi,
I got controller 60V KT 18 MOSFETS, and motor Nine Continent RH205 kassette. I can`t to configure it to run motor smoothly, i got effect like on the video https://www.youtube.com/watch?v=exmxFgL-Fno&feature=youtu.be&t=13 . Motor has 46 magnets, I set P1 on 46 and still works wrong. Do you think with the new firmware I will be able to make it run well?
 
stancecoke said:
I've implemented it in the latest commit, but I have not tried it on the road,

I've tested it on the road now, but I was not successful. It seems, that the zero crossing of the phase current is not influenced by the correction angle at all... :(

regards
stancecoke
 
stancecoke said:
stancecoke said:
I've implemented it in the latest commit, but I have not tried it on the road,

I've tested it on the road now, but I was not successful. It seems, that the zero crossing of the phase current is not influenced by the correction angle at all... :(
Thanks for logging and testing. Really nice to see that is really different on both situations.
Also see that 2 lines may not be comparable since the current phase displacemente depends on motor speed and current, and I think you can't assure they were registered on that same conditions.

One thing: I remember to play with magnets and if we think we have 2 magnets, were 1 we control his position (by controlling the pahse current), we need to put at a specific distance to have max attraction force (90 degrees per FOC).
At motoring mode, we want let's say to put current at 90 degres. At regen mode, we want to push to the other side, so, at -90 degrees. Maybe at regen mode we need to put current at -90 degrees, or the same as 270 degrees.
And also, since the current is flowing to battery, on the inverse direction, shouldn't the phase current be inverted 180 degrees also??
 
mjentos said:
Hi,
I got controller 60V KT 18 MOSFETS, and motor Nine Continent RH205 kassette. I can`t to configure it to run motor smoothly, i got effect like on the video https://www.youtube.com/watch?v=exmxFgL-Fno&feature=youtu.be&t=13 . Motor has 46 magnets, I set P1 on 46 and still works wrong. Do you think with the new firmware I will be able to make it run well?

Try changing C2 and reset display everytime.
 
After thinking a little: The current controller pulls the dutycycle to zero, if high regen current is wanted. In this case the correction angle can't have any effect, as the PWM puts no sinewave to phase lines.
Can we achieve higher regen current, if we set a higher dutycyle and a "misstuned" correction angle?!
With dutycycle = 0 I get about 1.5A regen current at about 20km/h with my BionX...

regards
stancecoke
 
honya96 said:
mjentos said:
Hi,
I got controller 60V KT 18 MOSFETS, and motor Nine Continent RH205 kassette. I can`t to configure it to run motor smoothly, i got effect like on the video https://www.youtube.com/watch?v=exmxFgL-Fno&feature=youtu.be&t=13 . Motor has 46 magnets, I set P1 on 46 and still works wrong. Do you think with the new firmware I will be able to make it run well?

Try changing C2 and reset display everytime.

I tried 0-7, no improvement
 
stancecoke said:
After thinking a little: The current controller pulls the dutycycle to zero, if high regen current is wanted. In this case the correction angle can't have any effect, as the PWM puts no sinewave to phase lines.
Can we achieve higher regen current, if we set a higher dutycyle and a "misstuned" correction angle?!
With dutycycle = 0 I get about 1.5A regen current at about 20km/h with my BionX...
No, the current controller tries to decrease the duty_cycle. Let's say motor is rotating at 100 erps and that gives a 12v BEMF. If duty-cycle value equals to a 12v from battery, no current flows. If you decrease duty-cycle a bit, now the voltage from battery will be lower than the BEMF voltage from motor and current will start to be regen.

So, on motor regen duty-cycle is not always zero but will be a value in a way that regen current is not more the value we define/control, so, there will be sinewave phase voltages while regen. Maybe the current phase will simple invert in direction and so shoild have 180 degrees...
 
stancecoke said:
Can we achieve higher regen current, if we set a higher dutycyle and a "misstuned" correction angle?!
You mean changing the angle to get regen?? Idon't think so. On FOC, for regen and invert rotation, we change Iq current from positive to negative. Let's say motor is running with a reference Iq = 10A, to start regen we should put Iq ref = -10A.

If we imagine 2 parallel rails, with 2 magnets on each rail at a very low distance each one, one north pole and other south, they will attract them selfs and stay inline (0 degrees). Now if we move one, the other will follow and if the other has some contrary force to movement direction, like a pull finger, the max torque will be at 90 degrees an not inline 0 degrees. If we push the first magnet to right to move the second one, max torque will be at 90 degrees and after being moving, to brake, max torque will be at -90 degrees (now on the left side).
 
casainho said:
So, on motor regen duty-cycle is not always zero but will be a value in a way that regen current is not more the value we define/control,

I don't know if it's a matter of the BionX. As I wrote, the max regen current I get at 20 km/h is about 1.5Amps only. If I ask for e.g. 5A regen current, the current controller drives the duty cycle to zero. If I ask for e.g. 0.5 A, of course the dutycycle will be higher than zero...

regards
stancecoke
 
casainho said:
If we push the first magnet to right to move the second one, max torque will be at 90 degrees and after being moving, to brake, max torque will be at -90 degrees (now on the left side).

Have you ever tried to shift the correction angle by 127 (=180°) for doing regen? In the german forum there was a similar suggestion.

regards
stancecoke
 
stancecoke said:
casainho said:
If we push the first magnet to right to move the second one, max torque will be at 90 degrees and after being moving, to brake, max torque will be at -90 degrees (now on the left side).
Have you ever tried to shift the correction angle by 127 (=180°) for doing regen? In the german forum there was a similar suggestion.
Yes, that is one idea but I prefer to keep looking at the same place and consider the signal is now inverted and so invert the logic for increase/decrease the ui8_angle_correction. That's because of possible errors on current implementation, due to overflow of the 8bits variables like this ui8_motor_rotor_angle >= FOC_READ_ID_CURRENT_ANGLE_ADJUST.

Anyway, I also need to see because just recently I started to look for the first time to phase current to understand if the system is doing regen:

Code:
  // make sure we just execute one time per ERPS, so use the flag ui8_flag_foc_read_id_current
  if ((ui8_motor_rotor_angle >= ((uint8_t) FOC_READ_ID_CURRENT_ANGLE_ADJUST)) && (ui8_flag_foc_read_id_current))
  {
    ui8_flag_foc_read_id_current = 0;

    // minimum speed to do FOC
    if (ui16_motor_speed_erps > MOTOR_ROTOR_ERPS_START_INTERPOLATION_60_DEGREES)
    {
      // read here the phase B current: FOC Id current
      ui8_adc_id_current = UI8_ADC_MOTOR_PHASE_B_CURRENT;
      if (ui8_adc_id_current > ADC_PHASE_B_CURRENT_ZERO_AMPS_FOC_MAX)
      {
	// limit max ui8_angle_correction value (127 + 15)
	if ((ui8_angle_correction+1) < 143) { ui8_angle_correction++; }
      }
      else if (ui8_adc_id_current < ADC_PHASE_B_CURRENT_ZERO_AMPS_FOC_MIN)
      {
	// limit min ui8_angle_correction value (127 - 15)
	if ((ui8_angle_correction-1) > 112)
	{
	  // decrease only when not regen!! other way ui8_angle_correction will always decrease... CAN WE IMPROVE THIS??
	  if (UI8_ADC_BATTERY_CURRENT > (ui8_adc_battery_current_offset+2)) { ui8_angle_correction--; }
	}
      }
    }
  }

I can look at 2 different values to understand if regen is happening: shunt value or hall phase current sensor. Unfortunately I can't put my ebike with direct drive motor on the bike training roller because the motor bolts are to large to fix the training roller and so it is hard to me to make regen happen and observe in real time with oscilloscope. Sure there are other ways, but they take much time that I don't have currently.

But one way or the other, I think I have now more knowledge that will permit to solve the problem. I think I really need to phase current in real time and see to where it should be adjusted.... and I think:



is the vector I*w*L that gives the direction for phase voltage V, since for regen I will change in direction, will be -I*w*L (maybe the vectors will now be placed on -Q axis of that graph and V should be adjusted now on the inverse direction, because we want to go to the other side/direction of the magnet (D axis, phi magnetic flux).
When regen, I think the V vector will also be negative because now the voltage differential on the coils also invert directional so both I and V will be placed on -Q axis.

So, to resume, I think we should keep the same reference rotor position (D axis, max phi magnetic flux/BEMF) + 90 degrees and looking to battery current (or phase B current??) to understand if regen is happening and if so, adjust increase/decrease phase B voltage angle (ui8_angle_correction) on the inverse direction. (or at the same reference rotor position (D axis, max phi magnetic flux/BEMF) - 90 degrees and keep the same logic for ui8_angle_correction increase/decrease) and you suggest).
 
Thought I'd better just mention that the current github master branch seems to give no to response to PAS input - this is with throttle/pas mode selected. Have double-checked my config.h settings, all seems ok....
 
geofft said:
Thought I'd better just mention that the current github master branch seems to give no to response to PAS input - this is with throttle/pas mode selected. Have double-checked my config.h settings, all seems ok....
Stancecoke needs to clean up his branch before the merge to master.
Geofft, thank you for testing the new code from Stancecoke. If it works best, let's use it :)
 
casainho said:
geofft said:
Thought I'd better just mention that the current github master branch seems to give no to response to PAS input - this is with throttle/pas mode selected. Have double-checked my config.h settings, all seems ok....
Stancecoke needs to clean up his branch before the merge to master.
Geofft, thank you for testing the new code from Stancecoke. If it works best, let's use it :)

Just to be completely clear, PAS works ok on the 'coast_brakes_at_pas_mode' branch but not on the master branch.
 
stancecoke said:
casainho said:
Stancecoke needs to clean up his branch before the merge to master.
What are your concerns?
Please look at the list I wrote before. At top of my head, try to not remove my implementation for my mod and also remove the printfs even if they are commented, to keep the code clean and easy to read.
 
casainho said:
try to not remove my implementation for my mod

Will you ever use your mod of the BMS-Sensor again, after breaking two bottom bracket axles???
To be honest, I'm not motivated to put any further work on this branch.

regards
stancecoke
 
stancecoke said:
casainho said:
try to not remove my implementation for my mod
Will you ever use your mod of the BMS-Sensor again, after breaking two bottom bracket axles???
To be honest, I'm not motivated to put any further work on this branch.
I am waiting an answer from BMSBattery, they told me they would contact their engineers and also the producer.
I still have that torque sensors on my 3 ebikes, until next fail, I will still be using them.
Also I am waiting for the photos and experience with Sempu torque sensor.

If is hard for you, just comment my mod and I will put it working later again (soon I hope).
 
I've just opened a pull request at github... (I never worked with pull requests before :shock: )

regards
stancecoke
 
Guys, can I make a small suggestion here?

It's clear that you both have differing ideas about the way some things should be done - that's completely normal with intelligent minds of course.
Would it not be best to develop this as two separate 'master' branches (maybe stancecoke master and casainho master, (call them what you like) to prevent 'treading on each others toes'. You would still be able to exchange ideas and code between yourselves, and it would be good for end users to have different options to see what works best for them.

I would be perfectly happy to test and feedback on all available options I have hardware for, I'm sure new takers coming along would also be so..... :)

Edit to add: I'm just talking about the KT thread here, I know very little about the TSDZ2 and can't comment on that.

Also I am waiting for the photos and experience with Sempu torque sensor.

@ Casainho: Still waiting for this, haven't forgotten your request.
 
Back
Top