EBiCS Firmware on a M365 STM32 Controller

Orange_Crush

1 µW
Joined
May 17, 2021
Messages
4
Started this thread as a small experiment log/report, trying out an stm32-based m365 scooter controller with stancecoke's EBiCS firmware port on a geared motor bike build (xf19) aiming for 20-25A initially, throttle through an esp32 as laid out on the firmware's github page. A 3-position switch to select a max throttle level might be something I'll look into once it's rolling. Just headless, throttle-only operation to begin with - I have a BMS app to monitor the pack and speed with anyway.

To address the obvious 'why?' question, I have a pretty limited amount of space for a controller on this bike without significant redesign or a phaserunner/CA3-sized budget increase, and little need to exceed the 20-25A the motor is rated for without oil or a better connector for phase wires. The M365 controller is a bit more compact where it counts for me, inexpensive, also 52V-compatible with only a reflash, has a 32-bit processor to the KT's 8-bit and can do better FOC calculations the slower KT can't manage. Just looking to achieve smooth, maybe slightly quieter operation and a little efficiency bump as a bonus. The Lishui LSW-675 from BMSBattery, from my measurement/estimation would still be a fairly snug fit, and costs roughly double the shipped price of this controller.

As the plan sits now, I'll start with a v2.1/v3.0 board (slightly reinforced traces with extra solder vs earlier models), add wire to traces and improve fet-heatsink contact over the rubber-pad-and-case-lid factory method with individual screws and thermal silicone pads. The XT30 connector will come out in favor of 12awg wire leading to an XT90 to match the 52V DIY pack, and the spade terminal phase connectors likewise will get 12awg wire soldered on (after drilling the small center hole out on each) going to 4mm bullets. A bit of a list, but easy tasks as far as I'm concerned. Without this extra reinforcement the scooter guys are taking these controllers to 35A or so battery current before they seem to start giving out, and even then usually under regen (not applicable for me), we'll see what it can do in a slightly different application with a larger motor when the parts arrive and update here accordingly.

Following up from the questions in the KT thread to not muddy its waters..

stancecoke said:
It works on the Lishui project, but it should be no problem to make the configurator run on the M365 project also, if there is a bigger user-community for the M365 firmware...

I misread a little there for the status, sorry - it'd be convenient though the config.h file isn't otherwise too difficult to parse to hardcode values into for basic use with my ultra-rusty C++ knowledge, EBiCS documentation referencing and a bit of basic deduction, at least outside of what I've already asked. The M365 scooter community is still kicking, though it seems the many scooter-specific firmware configurators out there cover most of their needs with stock batteries and motors, the hardcoded 15-pole count being a bit of a speedbump for some modders iirc. I don't know if any KT/lishui display options (or the bluetooth app via esp32, if possible) could be made to interface with it, and of course that depends on interest and ideally more people confident/familiar with coding, which I'm sadly not. I'm only one guy exploring a niche solution for what is really a self-created problem, but a good small low-ish-power basic controller with decent FOC, a torque throttle and a price tag this low makes for an interesting experiment in a segment of DIY ebike tech that feels a little stagnant or slow at times compared to mid-drive, e-scooter and e-board development.

Cheers!
 
Orange_Crush said:
I don't know if any KT/lishui display options (or the bluetooth app via esp32, if possible) could be made to interface with it, and of course that depends on interest and ideally more people confident/familiar with coding, which I'm sadly not. I'm only one guy exploring a niche solution for what is really a self-created problem

@Koxx3 has an own project for an user interface, based on an ESP32 + Android app.

20210506_194917.jpg


Tjn6dkqDY5936jPkp6nyWQDFKy3vAT0udtsuWHznkT-h_av4kuJa-R11i-cbM9dUxvo=w1920-h947-rw


Adapting popular OEM displays from Kunteng, Bafang, Kingmeter... would be a project on it's own.

regards
stancecoke
 
stancecoke said:
@Koxx3 has an own project for an user interface, based on an ESP32 + Android app.

For now I know enough to change it from analogRead to digitalRead functions to use a conventional magnet brake sensor (plus a pull-up resistor) to act as a safety cutoff and add a 3-pos switch to adjust the analog throttle signal as a basic 'assist level' control (0%/off in pos 1, 50% in pos 2 and 100% in pos 3 as a baseline, I think) in the simple throttle/brake-only variant, but not enough to add a controller profile to the full app-controllable branch or know if it'll work with minor tweaks (baud rate and serial comms match the smart_esc profile but I haven't gotten my head around the debug serial portion and functionality tweaks yet), I don't want to fall too far in over my head too quickly, but I'll keep at it.

stancecoke said:
Adapting popular OEM displays from Kunteng, Bafang, Kingmeter... would be a project on it's own.

I know the protocols for the usual displays are well-understood and used in the full lishui firmware/controllers with conventional display connectors, but the esp32 layer here is beyond me at this time. Fortunately I'm not too attached to having a display permanently mounted, whichever direction this takes in the future. Once I've had a little time to play with it and see basic (positive) results I might contact Koxx about including the m365 controller into the presets (if possible/he is interested), and build my own SmartController shield.
 
I am interested on this as I now own a M365 and I am very happy with this alternative to a bicycle or a motorcycle.

I will look at the firmware on the https://github.com/Koxx3/SmartESC_STM32_v3 and try to learn and test on my hardware. Great what was achieved already using the OpenSource!!
 
stancecoke said:
casainho said:
I will look at the firmware
Great! Looking forward to hear your comments! :idea:

regards
stancecoke
Can you just clarify that you have a branch for VESC observer that it starts using the hall sensors and then switchs to using the observer?
 
casainho said:
it starts using the hall sensors
No, the sensorless branch starts open loop and then switches to FOC. But it's no problem to do the startup from the hallsensors. But I see no advantage to use the observer, if you have working Hallsensors. We have the option to use a PLL for the rotorposition estimation, that works really smooth. Much less noise than with position extrapolation from the hallevents...
Sadly the M365 port has not the newest features from the EBiCS master, like autodetect of the kv motor constant an switching the PWM off/on while the motor is running...

You could join the Telegram chatgroup for the M365 project, see the invitation link at the EBiCS GitHub issue.

regards
stancecoke
 
stancecoke said:
casainho said:
it starts using the hall sensors
No, the sensorless branch starts open loop and then switches to FOC. But it's no problem to do the startup from the hallsensors. But I see no advantage to use the observer, if you have working Hallsensors. We have the option to use a PLL for the rotorposition estimation, that works really smooth. Much less noise than with position extrapolation from the hallevents...
Sadly the M365 port has not the newest features from the EBiCS master, like autodetect of the kv motor constant an switching the PWM off/on while the motor is running...

You could join the Telegram chatgroup for the M365 project, see the invitation link at the EBiCS GitHub issue.

regards
stancecoke
I wish this firmware for STM32F103 could be a bit more hardware generic, but yes, I also understand why so many forks, I also do that kindo forks.

Anyway, I need to learn and have a tool like this to use on other projects, like TSDZ2 V2 motor controller and Bafang M600 and M800 motors.
The M365 board is very cheap and accessible to mod and devlop, the same for the scooter itself, very popular and cheap to buy even as second hand and very easy to mod.
There is an OpenSource firmware for the BMS to be used on the M365, as it communicates with the motor controller and it need to be working.

Maybe I will make some small pull request to your code just to add some comments ans translate from german to EN.
 
Hello everybody!
I am trying to run the m365 controller with the board version as in the photo with the analog throttle control via ESP 32. I plan to use from a voltage of 48 volts. Edited as I could config.h. Compiled into STM32CubeIDE 1.7.0. I flashed through the STM32 ST-LINK Utility using the ST LINK V2 programmer. Connected the CH431 adapter to UART3. And then I stopped. In the terminal, I receive the following messages like:

001875 22:39:27.944 20 30 0D 0A 30 2C 20 30 2C 20 30 2C 20 30 2C 20 || 0..0, 0, 0, 0,
001876 22:39:27.990 30 2C 20 30 2C 20 32 37 35 38 2C 20 32 30 32 30 || 0, 0, 2758, 2020
001877 22:39:27.990 2C 20 32 30 34 35 2C 20 32 30 33 34 2C 20 32 30 || , 2045, 2034, 20
001878 22:39:27.996 31 36 2C 20 32 30 34 34 2C 20 54 3A 20 30 2C 20 || 16, 2044, T: 0,
001879 22:39:27.996 51 3A 20 30 2C 20 44 3A 20 30 2C 20 30 2C 20 30 || Q: 0, D: 0, 0, 0
001880 22:39:28.002 2C 20 53 3A 20 31 39 34 33 38 2C 20 31 37 37 2C || , S: 19438, 177,
001881 22:39:28.002 20 56 3A 20 33 38 30 35 2C 20 43 3A 20 30 0D 0A || V: 3805, C: 0..
001882 22:39:28.052 30 2C 20 30 2C 20 30 2C 20 30 2C 20 30 2C 20 30 || 0, 0, 0, 0, 0, 0

How should I send the command 00 00 00 06 01 00 00 00 00 00 00 00 to the auto - detection of hall sensors ?
The config.h file is attached. And also, where should the power button contact be connected?
It turns on the controller both when connected to the ground and when connected to 5V.

https://endless-sphere.com/forums/download/file.php?mode=view&id=303374&sid=1dc96f0d1ab18a03032bf8b356fef2f0
https://endless-sphere.com/forums/download/file.php?mode=view&id=303375&sid=1dc96f0d1ab18a03032bf8b356fef2f0
https://endless-sphere.com/forums/download/file.php?mode=view&id=303376&sid=1dc96f0d1ab18a03032bf8b356fef2f0
https://endless-sphere.com/forums/download/file.php?mode=view&id=303377&sid=1dc96f0d1ab18a03032bf8b356fef2f0
 

Attachments

  • 20210927_133726.jpg
    20210927_133726.jpg
    326.4 KB · Views: 1,671
  • 20210927_133757.jpg
    20210927_133757.jpg
    450.6 KB · Views: 1,671
  • 20210928_221143.jpg
    20210928_221143.jpg
    382.8 KB · Views: 1,672
  • config.h
    1.3 KB · Views: 37
stancecoke said:
No, the sensorless branch starts open loop and then switches to FOC. But it's no problem to do the startup from the hallsensors. But I see no advantage to use the observer, if you have working Hallsensors. We have the option to use a PLL for the rotorposition estimation, that works really smooth. Much less noise than with position extrapolation from the hallevents...
I see big advantage that is not depending on the motor currents and motor resistance and inductance value, since is not always easy to have this data from our hardware.

I saw the PLL code but I did not understand it well, can you please explain the idea?

stancecoke said:
Sadly the M365 port has not the newest features from the EBiCS master, like autodetect of the kv motor constant an switching the PWM off/on while the motor is running...
Can you explain the auto KV detect??

This lines....

Code:
				  ui32_KV -=ui32_KV>>4;
				  ui32_KV += ((uint32_SPEEDx100_cumulated*_T))/(MS.Voltage*MS.u_q);

and

Code:
PI_iq.integral_part = ((((uint32_SPEEDx100_cumulated*_T))/(MS.Voltage*ui32_KV))<<4)<<PI_iq.shift;
 
miklelv said:
How should I send the command 00 00 00 06 01 00 00 00 00 00 00 00 to the auto - detection of hall sensors ?
You can send the command by any terminal program that allows to send hex data. E.g. HTerm

casainho said:
Can you explain the auto KV detect??

After the motor angle autodetect, the controller increases iq slowly, so that the motor spins up slowly. During this the value of speed per (Duty cycle * battery voltage) is averaged.
Code:
_T/MS.u_q
represents the dutycycle (not exactly, ignoring u_d).
The line with PI_iq.integral_part sets the dutycycle to the value that fits to the recent wheel speed when switching on the PWM while the wheel is turning.

This is much more important for scooters with direct drives, when you start kicking and pull the throttle later.

Bikes with motors with freewheel doesn't have that problem...

The PLL is a PI control in principle, that adjustst the angle increment per PWM cycle. The hall events are used for comparing the estimated angle with the hall angle.

regards
stancecoke
 
miklelv said:
How should I send the command 00 00 00 06 01 00 00 00 00 00 00 00 to the auto - detection of hall sensors ?
The config.h file is attached.

And also, where should the power button contact be connected?
It turns on the controller both when connected to the ground and when connected to 5V.
First this call happens:
void process_ant_page(MotorState_t *MS, MotorParams_t *MP) {

Then this one:
void process_ant_page_one(uint8_t *ui8_pkt, MotorState_t *MS, MotorParams_t *MP){

Look at the source code to understand.
 
stancecoke said:
miklelv said:
How should I send the command 00 00 00 06 01 00 00 00 00 00 00 00 to the auto - detection of hall sensors ?
You can send the command by any terminal program that allows to send hex data. E.g. HTerm

casainho said:
Can you explain the auto KV detect??

After the motor angle autodetect, the controller increases iq slowly, so that the motor spins up slowly. During this the value of speed per (Duty cycle * battery voltage) is averaged.
Code:
_T/MS.u_q
represents the dutycycle (not exactly, ignoring u_d).
The line with PI_iq.integral_part sets the dutycycle to the value that fits to the recent wheel speed when switching on the PWM while the wheel is turning.

This is much more important for scooters with direct drives, when you start kicking and pull the throttle later.

Bikes with motors with freewheel doesn't have that problem...

The PLL is a PI control in principle, that adjustst the angle increment per PWM cycle. The hall events are used for comparing the estimated angle with the hall angle.

regards
stancecoke
Ok, great!!

I missed the turn on motor while it was rotating on the KT firmware I did, great to see this implementation. Luckly this was not needed on the TSDZ2 mid drive :)

I need to better understand the PLL as it seems important.
 
I set #define DISPLAY_TYPE 0. Now in the logs at the start of the controller: phase current offsets: 2018, 2043, 2034 standstill position 0, 0, 2. I did not see any reading from UART3 in the code at all. Maybe something has changed, how to run autodetect?
 
If I change the #define DISPLAY_TYPE DISPLAY_TYPE_EBiCS statement, then I get the error 'ui8_main_lev_page_counter' undeclared (first use in this function) and 'ui8_lev_page_to_send' undeclared (first use in this function) in the compiler.
 
miklelv said:
If I change the #define DISPLAY_TYPE DISPLAY_TYPE_EBiCS
Please let the display type at debug, as in the repo.
https://github.com/Koxx3/SmartESC_STM32_v3/blob/01552b90df5a8644e4f39e972dbc0c106f38abb8/Core/Inc/config.h#L44

It's quite a long time ago, when I played around with the code :D
Please join the Telegram chatgroup to get more help!
https://github.com/EBiCS/EBiCS_Firmware/issues/3#issuecomment-753472158

regards
stancecoke
 
Am i sending command correctly in the terminal ? Are there any other conditions for starting the autodetect process ?
CH341.jpg
 
Ah, we have activated the checksum verification now, so you have to send the correct checksum in the last byte of the command. See here:
https://github.com/Koxx3/SmartESC_STM32_v3/blob/01552b90df5a8644e4f39e972dbc0c106f38abb8/Core/Src/display_ebics.c#L136
We have to update the readme!

Please ask in the Telegram group, see the link in my last post!

regards
stancecoke
 
#include<stdio.h>

int main() {
int x[11]={0xAA,0x00,0x00,0x06,0x01, 0x00,0x00,0x00,0x00,0x00,0x00};
int chkSum = 0;

for (int i = 0; i < 11; i++) {
chkSum ^= x;
}

printf("byte 12 = 0x%02X ", chkSum);
}

You can run this code to get the right checksum:
https://onlinegdb.com/VIHGUEOwa

Click on 'fork' for editing with your own values

regards
stancecoke
 
I also don't understand how to set the values, MIN MAX setpoint for example.
-2096 = AA 00 00 06 00 00 00 ?? ?? 00 00 CC
100 = AA 00 00 06 00 00 00 ?? ?? 00 00 CC
2096 = AA 00 00 06 00 00 00 ?? ?? 00 00 CC
And I would like to try a Simple Analog Throttle Example on the ESP 32 module:)
 
miklelv said:
I also don't understand how to set the values
You can use an online converter like this:
https://www.rapidtables.com/convert/number/decimal-to-hex.html

For example
-100 in dec is FF9C as hex, so LL = 9C and MM = FF
230 in dec is 00E6 as hex, so LL = E6 and MM = 00

regards
stancecoke
 
I dream with the idea to develop the firmware for the M365 display as it is a NRF51, just the same used on SW102 ebike display that we developed the firmware for.

Since there is already OpenSource firmware for the M365 BMS and for the motor controller, the only missing part is the display. Also, we would be able to connect to the EBiCS mobile app, just like I did for the TSDZ2 ebike motor, were we change in real time the configurations for the system on the mobile app.

All that is possible and accessible, but I almost have no free time. I wish there was more developers interested to help.

Anyway, I bought an extra motor controller and display, let´s see if I will be able to do something.

I would be interested to document how to increase the battery to be like 48 or 52V (no hardware changes needed, other than install a new bigger battery and use our OpenSource firmware), to achieve higher motor speeds. Also maybe add a motor temperature sensor and pull more power from it, this would avoid the need to buy and install an expensive 500W motor and new motor controller, etc.
Range is also important, I wish to be able to change to mode with lower acceleration and speed to have more range or doing the contrary on other situations - all this configurations done in real time on the mobile app.
 
I bought 2 controllers on AliExpress and unfortunately, they do not use the same microcontroller, but some RiscV with chinese datasheet only:



I just bought other controllers on AliExpress, the ones advertized as V3.0 hardware and that we can clearly see on the pictures the STM32F103.
 
I'm trying to start such a BLDC 120 degree motor.
I use a power supply and set 40 volts, the current limit is about 10-15 amps. With autodetect, the motor and controller consumes about 6.8 amps. I try to start the engine, it starts spinning smoothly, but then it starts twitching when set to 50 setpoint. I also noticed that the controller shows 29 volts instead of the real 40 volts. What could be the matter, why is the motor twitching? Attached the work log.
https://endless-sphere.com/forums/download/file.php?mode=view&id=303886
https://endless-sphere.com/forums/download/file.php?mode=view&id=303888
https://endless-sphere.com/forums/download/file.php?mode=view&id=303887
 

Attachments

  • 20211005_015649.jpg
    20211005_015649.jpg
    276.3 KB · Views: 1,430
  • log.txt
    111.1 KB · Views: 29
  • 20210717_112331.jpg
    20210717_112331.jpg
    399.2 KB · Views: 1,431
Disable the PLL first. If it runs with disabled PLL try to find the right shift factors for the PLL.

regards
stancecoke
 
Back
Top