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

[casainho]

I've just uploaded a new branch with improved direction detection on PAS and made Regen like coast brakes availabe in normal PAS/Throttle mode. No wire at X4 is necessary, just a normal PAS at the origin PAS connector.
@casainho: you are right, with your code for handling the PAS signal, the mod of the BMS-Sensor doesn't work. With my interrupt-based handling, it works. Quite strange, but not important, as we won't use this sensor any more, I think....

I was looking at your code and I have some notes/questions:
1. The code have Printfs, please remove and "clean" the code
2. Your improved PAS direction detection is the same I looked before. With this new code, user will need to define another parameter and is also hard to find the correct value: #define PAS_THRESHOLD 1.7 <--- do we really need this improvement? what kind of PAS you have that didn't work with current code? The BMSBattery PAS, and I guess others may be very similar, work very well for me with current code and without the need of that additional parameter.
3. Seems some code is missing, because ui8_pas_flag is tested on read_pas_cadence_and_direction() but I don't see it being changed in any other place
4. This implementation seems to overwrite my implementation using the torque sensor + extra PAS. Please make your implementation to not overwrite, maybe using another define like EBIKE_REGULAR_PAS_REGEN_EBRAKE_LIKE_COAST_BRAKES

 

[stancecoke]

I think the additional parameter PAS_ratio will be OK with 1.7 in most cases, I've tested it with a cheap normal PAS and the modded BMS-Torquesensor, for both it was OK. As geofft already mentioned, the very simple implementation in the recent master branch causes hickups sometimes, that's my experience, too.

The ui8_pas_flag is set at the rising edge of the PAS signal in the motor.c and is reset in the ebike_app.c after processing the PAS information.

Please try to connect your extra PAS from your modded torquesensor to the origin PAS connector. This should work for you also, without the need of using X4.

regards
stancecoke

 

[casainho]

I think the additional parameter PAS_ratio will be OK with 1.7 in most cases, I've tested it with a cheap normal PAS and the modded BMS-Torquesensor, for both it was OK. As geofft already mentioned, the very simple implementation in the recent master branch causes hickups sometimes, that's my experience, too.

For me it is clear that direction can be detected, in a robust way, by comparing if ton is higher than toff, for a regular PAS. And that is working very well on current code, including the cadence value.
What may be failing that wasn't done yet, is the detection of the situation where there is a quick oscillation of the pedals, where ton and toff will have erroneous values and should be the reason for the hickups on the direction changing detection, direction and even cadence. I would implement a validation of min ton and toff values. And maybe after, a needed sequence of at least 1 ton + 1 toff with the correct min times.

I am afraid to regress on the robustness of PAS cadence and direction. Maybe since geofft want to try your code, we should wait for his experience results. I simple can't test on a regular PAS that is what really matters to me.

I saw that Sempu torque sensors, at least the latest version that works with 5V power supply, have specific wire/signal for indicate only the direction and other for indication of cadence. For the implementation of braking like coast brakes, will be much easier and very near of my implementation of the added PAS. In fact, will need 3 wires unlike BMSBattery torque sensor, so, will be 3 wires like my mod for braking like coast brakes.

Also Sempu torque sensor seems to be like 3x expensive, like about 125€...

 

[geofft]

To recap, the issue I had with the master branch (casainho pas) was that it had a tendency to trigger pas on slow reverse pedalling. On casainho's advice I played around with the 'ticks' count in this line (main.h):-

#define PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS (156250 / PAS_NUMBER_MAGNETS) // min hard limit to 6RPM PAS cadence

...and found that changing from 156250 to 100000 reduced the issue. I still get some 'kicks' from the motor with reverse pas on the test stand but it doesn't notice too much in normal use and still gives acceptable response to forward pas. This is the fix I've been using ever since.

@stancecoke

I've tried to install your modified branch with the new pas code but it fails to build and flash - I've attached the CMD DUMP, maybe you could take a look sometime?

Edit to add:- This is the Sempu torquesensor I've ordered (T2)
https://www.aliexpress.com/item/tor...32793693999.html?spm=a2g0s.9042311.0.0.HCKx3b

 

[stancecoke]

I've tried to install your modified branch with the new pas code but it fails to build and flash

I think you have a typo in the config.h.

Please make sure, that you have the right entry for PAS/Throttle mode:

#define EBIKE_THROTTLE_TYPE EBIKE_THROTTLE_TYPE_THROTTLE_PAS

I've changed the code a little to avoid the thing with the motor starting when pulling reverse, please download the latest revision!

I saw that Sempu torque sensors, at least the latest version that works with 5V power supply,

Where you got this information from? In the specification there's this information:

Supply voltage: 10-60V DC

Also Sempu torque sensor seems to be like 3x expensive, like about 125€...

You can get it a little cheaper at aliexpress, see the link from geofft. The second generation is available for 75$...

regards
stancecoke

 

[geofft]

I've tried to install your modified branch with the new pas code but it fails to build and flash

I think you have a typo in the config.h.

Please make sure, that you have the right entry for PAS/Throttle mode:

#define EBIKE_THROTTLE_TYPE EBIKE_THROTTLE_TYPE_THROTTLE_PAS

I've changed the code a little to avoid the thing with the motor starting when pulling reverse, please download the latest revision!

Have downloaded latest revision and checked config.h for correct #define but still won't flash. Guess I'm doing something dumb, could you take a look at my config.h and tell me where I'm going wrong....

 

[stancecoke]

I tried to compile with your config.h and it worked without errors. Can you post the output of the cmd window again?
Have you already updated to SDCC 3.7.0?

regards
stancecoke

 

[geofft]

I tried to compile with your config.h and it worked without errors. Can you post the output of the cmd window again?

Done

Have you already updated to SDCC 3.7.0?

Err......no. So I guess this is my problem?

 

[casainho]

Have you already updated to SDCC 3.7.0?

Err......no. So I guess this is my problem?

I see this errors on log:

ebike_app.asm:378: Error: <a> machine specific addressing or addressing mode error
ebike_app.asm:415: Error: <a> machine specific addressing or addressing mode error

and I don't know what they mean, but is nothing about specific errors on the code - going with SDCC 3.7.0 is a must.

 

[stancecoke]

Yes, that's the fault.

Please see the updated installation instructions:

https://opensourceebikefirmware.bitbucket.io/windows_instructions/index3.html

regards
stancecoke

hmm, I darkly remember that you are using a 32 bit PC?! Sadly, this isn't supported any longer

 

[geofft]

hmm, I darkly remember that you are using a 32 bit PC?! Sadly, this isn't supported any longer

Your dark memory is telling you lies....

Will update SDCC and try again, probably tomorrow.

Thanks guys.

 

[casainho]

Edit to add:- This is the Sempu torquesensor I've ordered (T2)
https://www.aliexpress.com/item/tor...32793693999.html?spm=a2g0s.9042311.0.0.HCKx3b

Thanks. Would be great if you can share pictures of it when you get it, including the installation on the bicycle.
That one has a good price compared to the BMSBattery, considering it will not break. Also, what I don't like much is that BMSBattery one seems to not be water resistance/prof... I hope that Sempu torque sensor is better on that characteristic.

Torque sensor is really "magic"!! Yesterday my girlfriend rode for the first time the ebike with torque sensor and this "stable" firmware. We were 3h outside riding, it was great. Happens that I tried also and ebike with Bionx direct drive motor and torque sensor, really smooth but not much better than our solution. I really need to improve for direct drive motor.
But torque sensor is a way to control the ebike without throttle, which is much more close feeling with the machine, dynamic experience, etc. Also is great for fitness, and user can define "how much fitness" want to do.

 

[geofft]

Torque sensor is really "magic"!!

Yes, I'm looking forward to trying one, but can see another steep learning curve looming to get it all up and running...

 

[stancecoke]

I really need to improve for direct drive motor.

What's the problem with the direct drive? I never got your master branch running satisfying with the torque sensor due to the PAS issue, but with the code from my fork, my BionX direct drive runs really good now, including regen by "thumb-brake" 8)

regards
stancecoke

 

[casainho]

Torque sensor is really "magic"!!

Yes, I'm looking forward to trying one, but can see another steep learning curve looming to get it all up and running...

It is actually very simple!! For my torque sensor ebikes, I am using only the throttle signal and I am ignoring PAS signal. You can go like that, from Sempu, use only torque wire and connect it to throttle wire input of the controller. Yes, I am not using human power, I must say that I am being happy like this and may try later human power (torque * cadence).

 

[casainho]

I really need to improve for direct drive motor.

What's the problem with the direct drive? I never got your master branch running satisfying with the torque sensor due to the PAS issue, but with the code from my fork, my BionX direct drive runs really good now, including regen by "thumb-brake" 8)

Well, regen vibrates the motor and I know FOC is not working while regen. All this needs work. I don't have much time... It will take time.

 

[casainho]

I think I got how TSDZ2 motor controllers run the most efficient possible, without even doing very low resolution FOC:

I am being thinking on how to do the motor control firmware in a way to get the most torque per amp possible, to be the most efficient possible.

I need help from you guys!!
We need to measure the TSDZ2 motor winding resistance and inductance - maybe some of you have a precise multimeter/equipment to do that?? Once some one does it, we can consider that values as a constants for this motors, as I hope TongSheng will not change the motor characteristics over time.

More expensive controllers do FOC and typically have 32 bits microprocessor running at least 50MHz. TSDZ2 has instead a 8 bits running at 16MHz.

Kunteng motor controllers with the same low processing power as TSDZ2, implement "very low resolution FOC" because they has a phase current sensor and they can run many different motors.

I am thinking that TSDZ2 don't has such phase current sensor but instead uses a look up table with pre defined values on how phase current will change with both motor speed and phase current increasing (this depends only of motor inductance and motor resistance). That should be good because this motor controller only has to drive this specific motor, unlike generic EBike motor controllers.
Using this look up table, there will be few math calculations per PWM cycle and that way PWM frequency can be increased to be able to drive this motor at higher RPMs - unlike on Kunteng where PWM frequency is 16kHz and max motor ERPM is 520, so the SVM/Sinewave is draw with the min of 30 different points at motor max speed.

 

[casainho]

I am being thinking about TSDZ2 motor firmware and I changed my ideas about using the same firmware for both motors, because:
- we need a stable firmware and after 1 year, seems we are close to it
-- keep developing this firmware for other motor would bring instability
- I think is important to have the firmware clean and simple so others can learn with it, to make even more efficient motor controllers in the future and more EVs, that's the biggest point for be because of urgent need for a better green environment
- I think I will create even a dedicated notes files, etc, because current development notes file is "heavy"
- will start a new thread, which may happen soon

 

[bendik.vignes@gmail.com]

Does anyone know if these controllers (with this software) will work fine also for non-hub motors like the GoldenMotor BLT-800?

I have a three-wheel cargo bike with two of these motors (dual motor: two front wheels). For the moment I am using the goldenmotor "cruise" controllers for these motors, but I am not happy with the controllers performance (especially PAS and regen) so I am looking for alternative controllers...

 

[geofft]

Yes, that's the fault.

Please see the updated installation instructions:

https://opensourceebikefirmware.bitbucket.io/windows_instructions/index3.html

regards
stancecoke

I'm struggling to make any sense of the .tar.xz files in that SDCC 3.7.0 download link, getting nowhere trying to unpack them with peazip. I think I'll have to wait for a simpler Windows installer version to become available before I can go any further with this.

 

[casainho]

I'm struggling to make any sense of the .tar.xz files in that SDCC 3.7.0 download link, getting nowhere trying to unpack them with peazip. I think I'll have to wait for a simpler Windows installer version to become available before I can go any further with this.

To extract, use 7Zip for Windows that is OpenSource: https://www.7-zip.org/download.html

After, copy that 3 folders "lib", "local" and "share" to inside C:/SDCC, as per instructions of Stancecoke.

 

[geofft]

I'm struggling to make any sense of the .tar.xz files in that SDCC 3.7.0 download link, getting nowhere trying to unpack them with peazip. I think I'll have to wait for a simpler Windows installer version to become available before I can go any further with this.

To extract, use 7Zip for Windows that is OpenSource: https://www.7-zip.org/download.html

After, copy that 3 folders "lib", "local" and "share" to inside C:/SDCC, as per instructions of Stancecoke.

Thanks - no problem extracting them with 7Zip, think I'll throw Peazip away....

 

[stancecoke]

Winrar works for extracting the files from the archive also, as suggested in the instructions. I'll add the links to the tutorial.

regards
stancecoke

 

[geofft]

I've just uploaded a new branch with improved direction detection on PAS and made Regen like coast brakes availabe in normal PAS/Throttle mode.

Finally got this installed and working today, some early observations:-

1) The modified PAS detection works well once PAS ratio is set. On my installation the range over which PAS operated without malfunction was 1.7 - 2.1, so the default of 1.7 was a little low. Set it at the obvious centre point of 1.9, at this figure it works reliably with no false triggering. So, for me, this is an improvement on the previous code and I found achieving the best setting for PAS ratio is not difficult.

2) Was initially confused by the brake indicator showing at times (lcd3) without the brakes being operated. Guessed this was probably to indicate regen/coast brake in operation(?) but it's a little unnecessary and distracting for gear motors, maybe this function can be switched off in config.h. when not required...?

Probably unrelated to the new pas code, it seems the wattmeter holds zero well now but has lost it's previous accuracy and is now indicating around 60% of its 'expected' value.

Didn't notice any occurrences of this problem:-

Just noticed one small 'glitch' though, often when under full power (800w on my setup, usually using throttle but I think has also happened under pas only) the LCD3 wattmeter reading will suddenly decay down to zero, although the motor is still at full drive. If at this point you release throttle/stop pedalling the motor 'hangs in' at full power for a further 2-3 secs before stopping. Not a big deal but just thought I'd mention it, it can catch you out if it happens at a bad moment.

..not sure if the recent changes could have affected this, maybe I need to do a longer test ride to be sure of this.

 

[stancecoke]

@geofft: Thank you for testing and the feedback!

regen vibrates the motor and I know FOC is not working while regen. All this needs work. I don't have much time... It will take time.

I've logged the phase current while riding and while regeneration with FOC disabled (correction angle always 127). The log shows, that the phase current is 120° late at regen. In my fork I normally read phase current at 180°, now I suggest to do the reading of the phase current at 60° when battery current is negative. I've implemented it in the latest commit, but I have not tried it on the road, as it's already dark outside...

I think you had a similar idea, as you had the parameter

#define FOC_READ_ID_CURRENT_ANGLE_ADJUST_INVERT 242

in your code at an earlier commit, but I can't find that in the recent master branch any more?!

regards
stancecoke