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

[stancecoke]

I've figured out the problem now

It was just the value of ADC_MOTOR_CURRENT_MAX_ZERO_VALUE_10B. It has to be a little lower for my controller. Now it works with speed and current control enabled, see the branch "SC_Experimenting".

So I think we have to add a function that sets the value for zero current.

regards
stancecoke

 

[casainho]

I've figured out the problem now

It was just the value of ADC_MOTOR_CURRENT_MAX_ZERO_VALUE_10B. It has to be a little lower for my controller. Now it works with speed and current control enabled, see the branch "SC_Experimenting".

So I think we have to add a function that sets the value for zero current.

Well spotted!! I found myself with the same issue, like sometimes not working and was probably due to that code, which I prefer now to force a zero value so the algorithm should work and not return zero:

  i16_motor_current = ui16_ADC_motor_current_filtered - ADC_MOTOR_CURRENT_MAX_ZERO_VALUE_10B;
  // make sure current is not negative, we are not here to control negative/regen current
  if (i16_motor_current < 0)
  {
//    return 0;
    i16_motor_current = 0;
  }

You can try and see. And yes, we need to add that function. Anyway, I think even with that, that correction is needed.

 

[casainho]

Well spotted!! I found myself with the same issue, like sometimes not working and was probably due to that code, which I prefer now to force a zero value so the algorithm should work and not return zero:

Just pushed to master branch that correction and now the max speed can be defined on the LCD. What is working on LCD (from LCD to the controller):
- assist level
- max motor speed

 

[casainho]

What is working on LCD (from LCD to the controller):
- assist level
- max motor speed
- P3: Power Assist Control Mode

I implemented P3: Power Assist Control Mode because it will be useful for my 90km ride. Also I want to implement C5:

 

[casainho]

C5 is now implemented:

What is working on LCD (from LCD to the controller):
- assist level
- max motor speed
- P3: Power Assist Control Mode
- C5: Controller Maximum Current Adjustment Mode

 

[stancecoke]

Your last few commits on the master branch don't work for me, even if I set the ADC_MOTOR_CURRENT_MAX_ZERO_VALUE_10B to the value that worked in the SC_Experimenting branch.

Please, can you rebase the master branch to the state of yesterday morning (or put the SC_Experimenting branch to master, in this branch, speed and current control works), to have a working version in the master branch?

Or make sure, that the code works, if no display is connected, perhaps in AssistLevel 3 e.g.

For getting the right value for the ADC value of Motor total current if motor is not runnung, we should add a function in the adc init that reads in the "zero" value that is then used in the further code.
I'll add this in the SC-Experimenting branch.

Regards
stancecoke

 

[casainho]

Or make sure, that the code works, if no display is connected, perhaps in AssistLevel 3 e.g.

Done. I can't test right now but I put default values on the needed variables.

For getting the right value for the ADC value of Motor total current if motor is not runnung, we should add a function in the adc init that reads in the "zero" value that is then used in the furter code.
I'll add this in the SC-Experimenting branch.

Ok. I tried before, you need to call adc_trigger ();, give a delay, read value, and do it again a few times (all this before enabling interrupts). Maybe you can use for delay:

    ui16_TIM2_counter = TIM2_GetCounter ();
    if ((ui16_TIM2_counter - ui16_throttle_pas_torque_sensor_controller_counter) > 100) // every 100ms

Be prepared to debug the code, since I remember, the first ADC readings are bad.
And you can use the low pass filter we are already using:

  // low pass filter the voltage readed value, to avoid possible fast spikes/noise
  ui16_ADC_battery_voltage_accumulated -= ui16_ADC_battery_voltage_accumulated >> 6;
  ui16_ADC_battery_voltage_accumulated += ui8_adc_read_battery_voltage ();
  ui8_ADC_battery_voltage_filtered = ui16_ADC_battery_voltage_accumulated >> 6;

I think I will now test current code by doing a ride. Next I will focus on the S12S

 

[stancecoke]

OK, it works now. I've just pushed a commit directly to the master branch, that adds the autozero function to the adc_init. The printf commands are good for debugging, but they are the delays for the adc process, also
Even the jerk of the motor at powering up the system happens no longer with this change of the code.

regards
stancecoke

 

[casainho]

OK, it works now. I've just pushed a commit directly to the master branch, that adds the autozero function to the adc_init. The printf commands are good for debugging, but they are the delays for the adc process, also
Even the jerk of the motor at powering up the system happens no longer with this change of the code.

Great!! I will look at the code and for I quick saw, you used 16 bits and right shift of PWM fast loop, I will try to go 8 bits only on the fast loop but keep the 16 bits of the slow loop.

[youtube]mb5F7uL4_0Y[/youtube]

I did another ride and everything went well, but just 3 errors on the LCD about the throttle error - this code is giving a false error, maybe we need to low pass filter before evaluate the error of throttle signal:

  // only throttle implemented for now
  ui8_ADC_throttle = ui8_adc_read_throttle ();

  // verify if throttle is connect or if there is any error
  // if error: error symbol on LCD will be shown
  if ((ui8_ADC_throttle < ADC_THROTTLE_MIN_VALUE_ERROR) ||
      (ui8_ADC_throttle > ADC_THROTTLE_MAX_VALUE_ERROR))
  {
    motor_controller_set_state (MOTOR_CONTROLLER_STATE_THROTTLE_ERROR);
    motor_disable_PWM ();
    motor_controller_set_error (MOTOR_CONTROLLER_ERROR_01_THROTTLE);
  }

 

[stancecoke]

I will try to go 8 bits only on the fast loop but keep the 16 bits of the slow loop.

OK, but I think this will not have much effect, as the shift only takes maximum two clock cycles...

regards
stancecoke

 

[daffy99]

the shift only takes maximum two clock cycles...

The page of contents for this course alludes to the fact, that this is for a MIPS CPU.

For the STM8, http://www.st.com/content/ccc/resource/technical/document/programming_manual/43/24/13/9a/89/df/45/ed/CD00161709.pdf/files/CD00161709.pdf/jcr:content/translations/en.CD00161709.pdf would probably be the source of truth.

In that document, you will also find the cycles documented, e.g. SLL [$15] taking 4 cycles. Without looking at the specific assembler output that is being generated, it is hard to make any authoritative statements about the amount of cycles consumed, anyway. Fortunately, the STM8 seems to be so simple that the concepts of (speculative) out-of-order execution, pipeline stall, cache miss, and other fanciness do not apply

 

[stancecoke]

OK, you are the boss... I eat my words.

regards
stancecoke

 

[casainho]

Took me some hours to figure out the issue why TIMER2 wasn't working after reset... last time I could not figure it out.

So, to do the ADC readings I used TIMER2 for delays instead of the printfs and the code size went from 23477 bytes to 21507, about 2000 bytes less!!

  for (ui8_i = 0; ui8_i < 16; ui8_i++)
  {
    ui16_counter = TIM2_GetCounter () + 10;
    while (TIM2_GetCounter () < ui16_counter) ;
    adc_trigger ();
    ui16_motor_total_current_offset_10b += ui16_adc_read_motor_total_current ();
  }

The issue was that TIM2 wasn't working after reset... so after many tries I found that I had to add a delay after init the TIMER2!!:

  // TIM2 Peripheral Configuration
  TIM2_DeInit();
  TIM2_TimeBaseInit(TIM2_PRESCALER_16384, 0xffff); // each incremment at every ~1ms
  TIM2_Cmd(ENABLE); // TIM2 counter enable

  // IMPORTANT: this software delay is needed so timer2 work after this
  for(ui16_i = 0; ui16_i < (29000); ui16_i++) { ; }

And with this changes, by miracle, the ADC reading stopped working!!

//	    ADC1_PRESSEL_FCPU_D2,
	    ADC1_PRESSEL_FCPU_D4, // may take about 35us to convert all 10 channels, which seems ok for the 64us PWM period
				  // being slower should improve the noise on ADC measurements

I had to change to ADC1_PRESSEL_FCPU_D2 as ADC1_PRESSEL_FCPU_D4 didn't work anymore.

In the end, the code works as expected.

 

[casainho]

I think I will change the way throttle and assistance level works. Right now, assistance level changes the motor current + motor speed but I think it should only change motor current.
So throttle will control "torque + speed" and assistance level will only reduce to a fraction the motor max current.

Now I want to jump to S12S!!

 

[stancecoke]

I think I will change the way throttle and assistance level works.

I think, it will be absolutly sufficient, if we just make sure that the speed limit and the maximum current are not exceeded in throttle mode and other than that just put the throttle value to the dutycycle directly. The rider will be the controlling instance with his thumb.

The use of assist levels and the control of current (or perhaps speed, but speed levels make no sense in my eyes) are only necessary in PAS (torque-simulation)- or torquesensor-mode.

Remember this post:
https://endless-sphere.com/forums/viewtopic.php?p=1321496#p1321496

and the suggested code for the "torque-simulation" mode
https://endless-sphere.com/forums/viewtopic.php?p=1326047#p1326047


Regards
stancecoke

 

[casainho]

I have now ready, on the bike training roller, my 48V EBike with Q100 read wheel motor. I use it with KU123 controller and throttle, and I ride it up to 45km/h.
This bike is much bigger and heavy than the other 24V EBike but S12S is also bigger I am now ready to test S12S with his original firmware on this EBike.

Anyone knows if the LCD5 I have and that works with 24V can also work with 48V??

 

[casainho]

Anyone knows if the LCD5 I have and that works with 24V can also work with 48V??

Just verified that at back says 24/36 and 48V and it works

And verified on S12S that motor current signal with motor stopped is the same voltage as on S06S: 1.58V = ADC_10bits: 323 --- I bet will be simple and quick to make the firmware working

 

[timmy66]

Could you make a quick recommendation for helping with the project :

I have a 48V standard "9c" type wheel - what controller would you suggest that would work with your firmware/development, that's around 1000 W or less. Several of the controllers seem to be in the low watt range, I'm more interested in something at least at 750W capable (in the USA). (Sourcing friendly for the US, too)

Thanks for recommendations -- maybe someone else is wondering how best to get involved, there are many options in the US at least for buying a cheap wheel, and then getting one of the less expensive controllers to work with this.

The regen feature is very interesting, and I remember getting started reading about this from another forum message.

 

[casainho]

Could you make a quick recommendation for helping with the project :

I have a 48V standard "9c" type wheel - what controller would you suggest that would work with your firmware/development, that's around 1000 W or less. Several of the controllers seem to be in the low watt range, I'm more interested in something at least at 750W capable (in the USA). (Sourcing friendly for the US, too)

Thanks for recommendations -- maybe someone else is wondering how best to get involved, there are many options in the US at least for buying a cheap wheel, and then getting one of the less expensive controllers to work with this.

The regen feature is very interesting, and I remember getting started reading about this from another forum message.

Hi Timmy66.

I just bought from BMSBattery their Q11 48V1Kw Rear Driving Disc-brake Hub Motor that since I remember is very similar to 9C motor. And I will want to develop the firmware for that direct drive motor and the regen (although regen should work already on current firmware but is not tested).

The controller you want is S12S, search on BMSBattery site as they ship to USA for sure. See my last messages, where I share some pictures of my S12S that I am just start using it and will make the firmware working for in in the next 2 days -- for now I will use it with a Q100 36V 328 motor but that I run at 48V: at battery max voltage of 54.6V and wheel on the air, it runs at 62Km/h.
Please note that there are a few versions of S12S, some that supports more current, choose what fits to you. And note that must be S12S and not S12P, as the firmware works only for the motors with hall sensors - no sensorless.

 

[stancecoke]

I have implemented the "torque-simulation" mode now, as I think that is the most common riding mode for people who have no torque-sensor.

[youtube]K6HPyKxBVL4[/youtube]

You can find the code in the new "Torque_Simulation_Testing" branch.
The Java-Tool is not updated with this new feature yet.

The current is increasing with the cadence until the preselected current level is reached. If you are pedaling faster than the defined cadence limit the current stays at the current level, see the here.

regards
stancecoke

 

[casainho]

I have now the S12S working - after many hours, I was able to test it and found some new information, documented it. Later I dropped a piece of metal on the board I saw some sparks. It failed to work and I found a transistor failing and keeping a phase always to GND, making a short circuit when I increased throttle. I had to repair and used a transistor from an old S06S controller, thanks to the schematic of S06S!!

S12S is working with the same firmware as S06S, I just had to connect the phases and hall sensor wires the same way, following the color codes. But the motor runs with oscillation in speed, I need to look at current signals, FOC, etc.

I documented:
- I did hit the max speed limit of this controller: 520 ERPS / 30 PWM signal periods; I documented here: https://opensourceebikefirmware.bitbucket.io/Motor_controllers--BMSBattery_S_series--BMSBattery_S12S--PWM_signal_at_max_speed_-_sineware.html
- the programming header: https://opensourceebikefirmware.bitbucket.io/Motor_controllers--BMSBattery_S_series--BMSBattery_S12S--Programming_header.html
- Phase B and motor total current signals: https://opensourceebikefirmware.bitbucket.io/Motor_controllers--BMSBattery_S_series--BMSBattery_S12S--Phase_B_and_motor_total_current_signals.html

I also updated the About project and included the current status of the firmware: https://opensourceebikefirmware.bitbucket.io/About_the_project.html

 

[stancecoke]

Great! Now we have got the proof, that the 12 FET controller runs with the same firmware

Very good, that you spent some time to update the project status, this helps a lot for getting a fast introduction into the project!

How can we merge our branches, now? I think, mainly we have to have all user relevant parameters in the config.h to make the Java-tool work and then have to implement the ride modes throttle+pas, torque-simulation and torquesensor to the master.

Regards
stancecoke

 

[stancecoke]

The java tool is updated with the torque-simulation-mode now. The additional parameter "Ramp end" is explained in the wiki.

regards
stancecoke

 

[timmy66]

This is a very interesting project, I can see you've done a lot of work here.

Are you concerned that you won't have a platform for using it if BMSBattery stops selling this? Or if you've gotten the schematic well documented, maybe invite someone else to produce the hardware so there's no issue with availability?

Frustrating shipping costs from BMSB are about the same as the controller price

The controller you want is S12S, search on BMSBattery site as they ship to USA for sure. See my last messages, where I share some pictures of my S12S that I am just start using it and will make the firmware working for in in the next 2 days -- for now I will use it with a Q100 36V 328 motor but that I run at 48V: at battery max voltage of 54.6V and wheel on the air, it runs at 62Km/h.
Please note that there are a few versions of S12S, some that supports more current, choose what fits to you. And note that must be S12S and not S12P, as the firmware works only for the motors with hall sensors - no sensorless.

 

[casainho]

The firmware on it's current state, is a serial killer of Kuntengs

- On the last 3 days, I wanted to make S12S working on my Q100 motor and 48V battery. Before, I only tested the firmware on S06S controller, Q85 motor and 24V battery.

- On the last 3 days did repair my S12S 3 times, exchanging burned mosfets. In the end, I started to use S06S with 48V and I also burned all my S06S!!

- Seems that my Q100 motor is not working correctly (with original controller KU123, sensorless 6 steps, was failing already sometimes) and after buying a S12P to my friend of local workshop for EBikes, it almost always gives the error on LCD about bad hall sensors although even if the wheel run but makes some noise. The S06P of my son EBike also can't run it, can start the motor but after makes noises and fails.

- The controllers with original firmware that I tested with my Q100, they could not run the motor but they never burned. Before I could understand that Q100 is not working correctly, I burned all my controller with our OpenSource firmware!! Why? I now think that was because I had cruise control enable and with that is easy to let the controller giving constant energy to the motor (I did just that) and even if the current controller works, the controller can't handle it many seconds constant. I verified that the controllers with original firmware will shutdown itself after a few seconds if the motor don't rotate -- next task to implement on the firmware!! and I think maybe on the fast loop/low level.

For what I could test, the S12S were working correctly. I had to exchange to were FOC was done, I could see it failing before and working as expected after.

I will need to take a break to make other things and at the same time I am now waiting for new controllers from BMSBattery. Maybe I will be able to repair my S12S...

How can we merge our branches, now? I think, mainly we have to have all user relevant parameters in the config.h to make the Java-tool work and then have to implement the ride modes throttle+pas, torque-simulation and torquesensor to the master.

As you can see, I am being very busy to test the firmware and trying to take it out from the test/development bench. And it is not ready yet for no developers.

This is not going as fast as I expected, but because of complexity of the project. We are getting a lot of help!! but the project is a bit more complex than I thought before starting it

Since it seems very easy to burn controllers (and maybe also unprotected batteries packs), why not focus first on a small set of hardware options and for developers/advanced users only??
Maybe I would for now focus of a config header file only and BMSBattery S motor controllers (sinewave only!) + LCD, motors and throttle, PAS and torque sensor. For instance, my friend have some controllers from Kunteng, bought from them directly and they have different hardware configurations, like one you had, without phase B current sensor.
What is than the advantage of this firmware over the original? The original works very well. With our firmware we can get more flexibility but I think we are not there yet, at least it is the reality for me after all this weeks working almost full time on this project and trying on real ebikes.