EBiCS firmware on ecoride 2018 ebike

hinxx

hinxx

1 mW
Joined
Jun 25, 2023
Messages
19
Location
Earth
I've managed to build and load the GitHub - EBiCS/EBiCS_Firmware: Free FOC firmware for Lishui E-Bike-Controllers onto Ecoride 2018 ebike that has LSW1108-25-2F (PCB marking LSW6G-90B-FOC-160704) controller. My goal is to remove the speed limit that stock firmware has at 25 km/h. Stock firmware stops assisting at 25 km/h and it feels like hitting the wall even when going down hill or pedaling really hard. Using a throttle on a bike stand (front wheel free running) I can see ~30 km/h peak speed that settles at 26 km/h after a while.

EBiCS looks promising. But by just setting '#define SPEEDLIMIT 40' things have not improved much. On a bike stand I can still see ~30 km/h max. The difference is that is that the speed remains at that level and does NOT drop to 26 km/h. On the road though, there is no difference; 26 km/h still feels like hitting the wall no matter how hard I pedal..

Is there something else that needs configuring in order to lift the speed limit in EBiCS?

BTW, the bike has a LCD that seems to speak King-Meter 901U protocol, although a bit different. Sniffing out the LCD <-> controller communication allowed me to code the LCD support seen here: EBiCS_Firmware/Src/display_ecoride.c at ecoride · hinxx/EBiCS_Firmware.

I've also managed to read out the stock firmware by utilizing f103-analysis/h3 at master · JohannesObermaier/f103-analysis attack if anyone is interested..
 
Is the speed the same with wheel offground as when riding?

If so, it's still speed limiting.

If not, and riding speed is lower than offground (usually by around 15-20%), it might just not have enough available power to go any faster, *or* the system voltage is not high enough to spin the motor any faster, or both.
 
It's the second case. The riding speed is 4-5 km/h lower than the offground. It's a front hub 250 W motor with 36V controller.

I was hoping to get the bike go faster at least downhill and not to feel like it is "braking" as soon as it gets to 26 km/h. With what you said, I'm guessing that the motor is preventing me from going faster. Is there something that could be done is this case? I was experimenting by switch the assist to off when going downhill but it does not make any difference; which is kind of not supporting the theory that the motor is limiting the speed. If I try to spin the front wheel by hand when it is offground with the motor off I do not sense any resistance. It does not add up for me why it is not going faster down the hill..
 
hinxx said:
I'm guessing that the motor is preventing me from going faster. Is there something that could be done is this case
Click to expand...
Two ways: use a 48V battery or do field weakening. Field weakening is not implemented in the master, but in the M365 fork.
But I don't like field weakening, it produces losses/heat.
Nice to hear that you got EBiCS running!:bigthumb:

regards
stancecoke
 
Thanks for the great work on the EBiCS stancecoke!!

My bike now really runs better than it did with the stock firmware. I just did a longer ride for the first time with the EBiCS and I can see that the 25 km/h limit is not there anymore. Biking with battery fully charged it was easy to get it to 29 km/h, and with the half of battery it was able to do about 27 km/h. Without load the wheel speed was 33 km/h (full battery) and 27 km/h (half battery). That is telling me that the motor is running a much as it can now and it is a matter of supplying more voltage to spin it faster as you guys are pointing out.

I'll take a look at the field weakening code and give it a run for sure!

I'll try to find a 48V battery, too. Do you think the controller needs to be replaced with the one rated for 48V or would existing one cope? Also would I need to redo the motor power cabling in that case?
 

Attachments

  • IMG_0979.png
    IMG_0979.png
    10.5 MB · Views: 10
  • IMG_01029.png
    IMG_01029.png
    13.3 MB · Views: 10
hinxx said:
Do you think the controller needs to be replaced
Click to expand...
No, the big caps are rated for 63V, normally. So no problem to drive the controller with 48V. Maybe the bars in the display will always show full battery.
Is there an imprint on the back of the display, that shows the nominal voltage?
Seems the display has an integrated thumb throttle?

Ecoride-2021-Ambassador-H8-AXS-Svart-LO-3-1080x608.jpg


regards
stancecoke
 
No, the big caps are rated for 63V, normally. So no problem to drive the controller with 48V.
Click to expand...
Great!
Is there an imprint on the back of the display, that shows the nominal voltage?
Click to expand...
Yes there is a little sticker saying: 36V/700
Seems the display has an integrated thumb throttle?
Click to expand...
Yes it has. The display on the image is model C3, mine is C2 from 2016/2018 series.
 
Following up on the field weakening code. I found this SmartESC_STM32_v3/Core/Src/main.c at 4bd351263779947dabdfd69c4bce9a643eabba9e · Koxx3/SmartESC_STM32_v3 (in v0.5 branch). Is this what you were referring to?

I've copied the relevant lines to my fork of EBiCS seen here: trying out field weakening · hinxx/EBiCS_Firmware@4c9df90.

I'm not sure it is proper, especially with scaling of the current / voltages. Also max current probably isn't correct. Any pointers on how to proceed?

What can I expect from this modification in terms of motor behavior? How do I tell if field weakening is doing its thing?
I've been reading up and watching some videos about the field weakening in order to understand what it is and what it does but it is going to take some time to wrap my head around it.
 
hinxx said:
What can I expect from this modification in terms of motor behavior?
Click to expand...
With field weakening, part of the magnetic field of the permanent magnets is cancelled out. This causes the motor to generate fewer volts per speed, allowing it to turn faster at the available battery voltage.

Be careful. A negative id causes field weakening, that's quite easy. But the code in the master calculates the battery current only from iq, as id is always controlled to be zero, normally (EBiCS does no MTPA). So check the calculation of MS.Battery_Current in the M365 fork also.
And be aware, that I implemented field weakening just quick and dirty in the M365 fork. It works, but maybe there are much smarter ways to implement it.

regards
stancecoke

Field-Weakening Control (with MTPA) of PMSM - MATLAB & Simulink Example - MathWorks Deutschland

This example implements the field-oriented control (FOC) technique to control the torque and speed of a three-phase permanent magnet synchronous motor (PMSM).
de.mathworks.com

xxmcb_mtpa_charac.png
 
Last edited:
Just tested the code as-is and this is how it looks like at the startup with debug build.


About 2/3 into the the video the wheel speed goes into super speed mode :)

So check the calculation of MS.battery_current in the M365 fork also.
Click to expand...
Will do!

Thanks for the help!!!!
 
hinxx said:
goes into super speed mode
Click to expand...
you stopped just before take off :ROFLMAO:

Was that a start with autodetct?! You could try to fine tune the value of SIXSTEPTHRESHOLD, it doesn't sound good at starting from standstill :eek:

regards
stancecoke
 
Last edited:
you stopped just before take off :ROFLMAO:
Click to expand...
I wasn't doing anything in that video. That was the autodetect. I was a bit scared that it will fall off the stands though, lol.

I've adopted the calculation of MS.Battery_Current in the M365 fork and changed master code to match what is there. I also took the part where MS.i_setpoint_abs is made to then set MS.i_q_setpoint and MS.i_d_setpoint. I have to use
tics_to_speed(MS.Speed) when mapping the speed to MS.i_d_setpoint_temp. I also adjusted the two constants for minimum and maximum input speed to get:
C: 
MS.i_d_setpoint_temp=-map(tics_to_speed(MS.Speed),(ui32_KV*MS.Voltage/10000)-10,(ui32_KV*MS.Voltage/10000)+20,0,fw_current_max);

The debug mode is still funky at the autodetect. But the bike version is better:


50 km/h with no load. I'm happy.

I have not touched other parts nor did I try tuning SIXSTEPTHRESHOLD (no idea what that is / does).. just hacking here :D

I think this is good for a test run tomorrow !
 
hinxx said:
That was the autodetect
Click to expand...
You have to disable field weakening during autodetect, as the motor constant Kv can't be detected properly otherwise. With a wrong Kv you will get ugly current peaks, when you activate the PWM while rolling.

regards
stancecoke
 
Got it! I can see the spikes on the LCD, too. It uses a tiny bar to show the battery current level (assist level) that controller is applying and it is all over the place. Without field weakening it is steady increasing / decreasing.

I was thinking about how the field weakening should not be active all the time but only in the certain "region" ; need to study the Matlab material a bit more.
 
hinxx said:
should not be active all the time but only in the certain "region"
Click to expand...
this was my idea with the map function. Depending on the battery voltage and the speed, id only gets negative, if the wheel is forced to turn faster than the BEMF would allow normally. But as I said, it was just quick and dirty. It works in principle, as your video shows :bigthumb:

regards
stancecoke
 
Kudoz to stancecoke and his predecessors for the work on EBiCS!!! I'm very happy that I can play around with EBiCS firmware even though I barely understand anything about motor control :).

I've been tinkering with the area where the flux weakening is applied yesterday. Just laying out some thoughts / findings here.

In my initial stab the flux weakening was done across all speed range and during the hall angle and KV autodetect periods. Did not sound good but the wheel spun up to 50km/h offground in debug mode. On the road I could get to 33 km/h with little effort (full battery), reaching 38 km/h downhill was possible with ease. I would observe battery current level on the LCD being quite high (> 60 %) most of the time. Also when reducing speed the current level would fluctuate from 0 to max several times before it settled on 0. I observed this in debug mode, too; the battery current would flip from (high) positive to negative values when I left the wheel spin down without braking. It also makes me think that the battery would be drained faster since I'm creating large negative Id all the time.

As stancecoke pointed out, I then mapped the Id setpoint value to non zero only within a certain speed range. The autodetect is performed as in master, with Id always set to 0. Now the flux weakening is applied at ~28 km/h and would last up to 47km/h. When pedaling I feel like I need to pedal harder to get past 30km/h compared to before. But, I do not see the battery current level go from 0 to max when slowing down and the battery current level is very low at those speeds.

While trying to adjust the speed range for flux weakening range in debug mode by changing the two constants that offset minimum and maximum speed I would either manage to get the wheel to spin about 36 km//h or 50 km/h. It seemed like it was not possible to get something in between.

The idea now is to be able to get to 40 km/h fairly easy should the conditions allow (battery full, slight downhill) without seeing battery current level fluctuate and not having to big of an impact on the battery drain. With what I know so far the speed range for flux weakening would be from ~25 km/h onward up to 50 km/h (not sure if the upper limit matters that much, but it affect the mapping of speed to Id).

What would be expected or acceptable levels for the negative Id during the flux weakening at speeds 25-40 km/h?

I'll try to show some plots of the measured data like Iq, Id, speed, battery voltage and battery current level during the debug mode. I also need to come up with a way to quickly change some of the parameters on-the-fly without rebuilding the firmware each time I adjust a constant in the equation..
 
I'm trying to understand this piece of code from EBiCS_firmware / EBiCS_motor_FOC projects.
Where do the constants come from?
C: 
int8_t tics_to_speed(uint32_t tics) {
  return WHEEL_CIRCUMFERENCE * 5 * 3600 / (6 * GEAR_RATIO * tics * 10);
}

Correct me if I'm wrong, the 'tics' are from TIM2, and they update once per 128 ms.
 
This is crazy. I have the exact same bike, display and controller and just sat down to check wether there is some tweaks that can be made on it to raise the top speed. Seems like you have already found the buried treasure :D

Since u have done a lot of your own research on this... Which fork do you suggest that I flash my controller with, and what settings should I use?
 
In my fork of the repo there is a branch called ecoride. Its been a while since I pushed anything to it and can’t quite remember what state is it in.
My initial hacks with field weakening were showing good potential but were rough around the edges so to speak. I could reach higher speeds ~ 35 km/h without hitting the ”speed wall”. The issues I noticed were related to the jerky current draw when freewheeling. Then I started to look into the whole theory of FOC et. al. trying to understand how to fix that. Along the way I started playing with the FOC only code from another repo and made it work on my bike. That code seems to not have the issue with jerky current draw, but lacks PAS and display support.

These days I’m adding the PAS and display code and getting ready to run it on the bike. Still have some work to do.

So I can’t say anything of quality exists but there is stuff you could experiment with..
 
hinxx said:
Along the way I started playing with the FOC only code from another repo and made it work on my bike.
Click to expand...
Interesting news! Please share some details! Which 'other repo' are you using now?

regards
stancecoke
 
So do you think your fork is safe enough for regular use?
Click to expand...
I was riding my bike with it for a week or so. It worked but I did not like the fact that when freewheeling it would cause erratic current consumption (seen by the large changes in small bar on the C2 display). It could be that the problem is in field weakening code I took and plugged into the existing EBiCS_firmware code base and didn't do a good job at it. Here is the info on where it came from EBiCS firmware on ecoride 2018 ebike.

There are no guaranties, I can not say that it is safe or not or that it will work for you as it did for me. Sorry.

You are welcome to try it out, though, if you are brave enough;).

Is it this one? GitHub - hinxx/EBiCS_Firmware: Free FOC firmware for Lishui E-Bike-Controllers
Click to expand...

That is the repo, yes, that I'm referring to above.

Or do you recommend me using that other repo you are talking about?
Click to expand...
The one I'm currently focusing on is here: GitHub - hinxx/EBiCS_motor_FOC at ecoride. It will not work on the bike at the moment; I'm still working on the PAS, LCD and other bits that it is missing compared to the GitHub - hinxx/EBiCS_Firmware: Free FOC firmware for Lishui E-Bike-Controllers. Again, the reason I'm doing this is because I do not observe the same current fluctuations using field weakening on this repo (EBiCS_FOC_motor) compared to the EBiCS_firmware repo.

I'll try to commit and finish the work in the coming week and will post the results here.
 
Oh that sounds like you have a good plan. Please feel free to ask for help with testing or whatever. I have the same bike and everything as you do.
 
You must log in or register to reply here.
Back
Top