Lishui "Open Source Firmware" project / KingMeter 5S

Hello, and thank you for all your hard work on this project!

I have a Lishui controller for my Bofeili mid-drive bike... it's an LSW 913-33-5F and the board on it is labeled LSW90B-V02-130509. It seems to meet the requirements laid out in the wiki to be re-flashable.

I would like to be able to write to the firmware, mainly so that I can remove the 25mph speed limit and configure the controller to speak to a nice Bafang DPC-18 color display instead of the black & white APT-800S that the bike came with. My biggest concern is this... in order to unlock the stock firmware to be writable, it must be erased??? Is there a way to save the "stock" parameters loaded onto the controller (such as # of pole pairs, no-load speed, stator resistance, and so on) so that I don't have to start from scratch trying to figure those out?

Thanks once again,

-Jon
 
Volvofan said:
Is there a way to save the "stock" parameters loaded onto the controller
No, everything will be erased with unlocking the controller.

Limit and display protocol is settable with the Java GUI, you don't need to do changes in the code manually.

regards
stancecoke
 
stancecoke said:
Volvofan said:
Is there a way to save the "stock" parameters loaded onto the controller
No, everything will be erased with unlocking the controller.

Limit and display protocol is settable with the Java GUI, you don't need to do changes in the code manually.

regards
stancecoke

Ok thank you so much! That is great news. I will try messing with the Java GUI first to see if that gets the job done, then will consider erasing/reflashing if not.

-Jon
 
stancecoke said:
Volvofan said:
Is there a way to save the "stock" parameters loaded onto the controller
No, everything will be erased with unlocking the controller.

Limit and display protocol is settable with the Java GUI, you don't need to do changes in the code manually.

regards
stancecoke

Hello again, and I'm sorry to have to keep asking for help! Trying to find the documentation and FAQs on my own, but I'm hitting some "rookie" dead ends. If there's somewhere else I should be looking rather than posting questions here, please send me on my way and I'll try not to bother again :)

1) When you say that the limit and display protocol are settable with the Java GUI, do you mean the one downloaded from Lishui's website at https://www.lsdzs.com/ls_download/, or the Open Source one at https://github.com/stancecoke/LishuiFOC?

2) If I have to use the Lishui program, can I do that with the generic ST-Link V2 using the controller's programming port (the white plug with the four pin holes for gnd, clock, 3.3v, I/O) or do I *HAVE* to use the display connector and the proprietary "Lishui Controller USB Stick" shown in their manual on the first page (at https://opensourceebikefirmware.bitbucket.io/development/EmbeddedFiles/66-User's_Manual.pdf)?

3) My controller was manufactured in October of 2016. Is it already an "FOC" controller, or should I still upgrade the firmware?

4) If all I am trying to do is to increase the speed limit and change the display protocol, does something still need to be erased? I am worried that I will not be able to find the correct settings to put in for "motor specific angle", "PAS Timeout and Ramp End" etc. if I don't know what they were originally. Perhaps a better option for me might be the Lishui Bluetooth controller (and corresponding iOS software) at https://www.pedelecs.co.uk/forum/threads/lishui-bluetooth-controller-programming-the-easy-way.24210/ (though apparently I would have to go with a non-Bafang display)? It seems that someone on that thread with a Bofeili mid-drive and Lishui controller was indeed able to update their controller using that interface (post #18).

Thank you so much!

-Jon
 
It depends on the stock firmware, if you can use the Bluetooth app.
You can flash a new firmware file with the STM32 Utility or with the Lishui tool, that makes no difference. The open source firmware can be flashed directly from the IDE or with the GUI of the open firmware project.

There is no stock Lishui firmware file available for private persons.

You can find the Wiki for the Open Source Project here:
https://github.com/EBiCS/EBiCS_Firmware/wiki

Regards
stancecoke
 
stancecoke said:
It depends on the stock firmware, if you can use the Bluetooth app.
You can flash a new firmware file with the STM32 Utility or with the Lishui tool, that makes no difference. The open source firmware can be flashed directly from the IDE or with the GUI of the open firmware project.

There is no stock Lishui firmware file available for private persons.

You can find the Wiki for the Open Source Project here:
https://github.com/EBiCS/EBiCS_Firmware/wiki

Regards
stancecoke

Thank you once again for the assistance! Yes, I’ve seen that wiki and it has been a big help so far. I’m sure this is all second nature once you’ve done it a few times, but it’s all a little daunting for a novice. I’ll have another go this weekend and will report back. Thank you!!!

-Jon
 
SUCCESS! Or, at least... more success than I'd had thus far.

I will talk through my experience to help fill in the blanks from the wikis below for other novices who may not be as familiar/comfortable with programming.

By comparing the wiki at: https://github.com/EBiCS/EBiCS_Firmware/wiki shown below on the left to the English-translated (thank you, Google!) version of the instructions on the pedelecs.de forum at: https://www.pedelecforum.de/wiki/do...:open_source_firmware_fuer_lishui_-controller shown below on the right, I discovered a critical step I was missing - installing the STM32 Link utility!



As an added challenge, when I tried to run the STM32 utility, I got an error that "mfc140.dll is missing" or something like that. A quick internet search led me to the following post on the Microsoft support forum: https://answers.microsoft.com/en-us...fc140dll/fd263446-82bd-4fdf-8e50-a0a2c0cf8486. Following the link in the third post from DaveM121, I downloaded and installed the Visual C++ Redistributable for Visual Studio 2015 from https://www.microsoft.com/en-ie/download/details.aspx?id=48145. Once I did that, all the other steps worked perfectly. Before that, I could click on "Unlock Controller" or "Compile & Flash" and it would run through all sorts of command-line magic, but would never actually write anything to the controller :)

As soon as I flashed in the new firmware, my Bafang display was working properly with no "Error Code 30". YESSS!!!

Next task was understanding your instructions about the "autodetect" feature. I was able to eventually figure out that you want to hold down the brake for a wheel that is NOT being driven by the motor! Hold down full throttle, AND hold down brake (for a non-driven wheel), AND power up controller. Once motor starts to move (in my mid-drive motor's case it moved VERY slowly... only a couple degrees of crank rotation every second or so) you can release brake and throttle and it'll run all by itself. My motor still ran very rough after this procedure, so I decided to try the "autodetect on startup" feature. For this, don't forget to not only click that "enable autodetect in debug mode" setting on the "advanced settings" tab, but ALSO select "debug" for the display on the "basic settings" tab. Finally, remember that if the controller is still plugged into your computer, it will not power down
when you shut off the power at your bike.

Even after doing the autodetect procedure a few times in both modes (brake-and-throttle and do-on-startup), my motor was still running very rough. This was my fear! What settings do I need to alter on the basic (or --gasp-- advanced) page to make it proper? Here was my "learning process."

First, I ignored the PAS settings and torque sensor settings as I use a throttle so no worries there.

Next, Batterycurrent max and regencurrent max. Values are inputted in milliamps, so that's easy enough! So far, so good!

On to motorcurrent max and regencurrent. Wha? These numbers are very low, if they're supposed to be milliamps. ::flips back to wiki instructions for parameters:: Okay, what the hell is an ADC? --<<5 minutes of Googling later>>-- It means "analog-to-digital converter." The microprocessor doesn't know what volts, amps, RPMs, microhenrys, or whatever are... it just knows ONES and ZEROES. The various sensors (hall sensors, torque sensors, throttle sensors) talk to the ADC and convert the sensor's various things they are measuring into those ones and zeroes. Motorcurrent max and regencurrent are given in the "ones and zeroes" value, not the actual amperage. To calculate, you simply multiply by a... "38LL<<8"?!?! Now what the F is this?! Common core math? --<<10 minutes of Googling later>>-- ok, that wasn't so bad. LL = "long long" which is programming lingo for a placeholder for a very big (64-bit) value. <<8 is a bitwise conversion used in C++ programming that "shifts" values x number of bits to the left or right within their placeholder in memory. Google yourself if you want to learn more... otherwise all you need to know is "DROP THE EXTRA BS AND JUST KEEP THE NUMBER." Basic settings had "600" for motorcurrent max. multiply that by 38 (from "advanced settings" tab, "FOC Current" field minus all the extra non-integer stuff) and you get 22,800 milliamps, or 22.8 amps. Phew! It's all downhill from here, right.....?

Next, for Voltage min/max and throttle offset/max, same deal. They are also an "ADC value" that we need to convert to volts somehow. Unfortunately, unlike I did with the motorcurrent max and regencurrent values, I could not figure out how to use the "calibration battery voltage" value from the advanced settings tab as described here https://github.com/EBiCS/EBiCS_Firmware/wiki/The-Lishui-Parameter-Configuator#battery-voltage to figure out what to set! The default value on the "advanced settings" tab is 256. 256 x the default "voltage min" value of 500 gives me, uh, 128 THOUSAND millivolts, or 128 V? Something is not making sense to me, here. Let me move on and come back to it.

Push assist in KPH, speed limit, pulses per revolution (WHEEL revolution), and wheel circumference were all pretty self-explanatory. For Gear Ratio, I was not 100% certain. Fortunately, I was able to find some disassembled photos of a Bofeili motor and was able to see that it had 10 pole pairs of magnets and I could see all the planetary gear train and figure out how it was driven... the ring gear is the driving gear (attached to the motor's rotor) and the sun gear is the driven gear (attached to the cranks). Because the planetary carrier remains stationary in the motor housing, the ratio is actually the # of ring teeth / # of sun teeth, or 88/17 or 5.17 to 1. Interestingly enough, the motor rotates in the OPPOSITE direction of the cranks in this configuration.

So, I set everything up on the "basic settings" according to the above, then re-flashed and re-did the "auto detect" procedure. Still very rough running! Damnit! I guess I'll have to try and tinker with the "advanced settings" page. Here, I got lucky. First thing I did was try unchecking "enable position PLL" and when I reflashed, everything ran perfectly fine!

LONG STORY short... happy endings all around. Using the instructions provided in the wiki AND filling in the blanks as I described above, I was able to get what I was looking for - Lishui true FOC control AND the display of my choice AND bumped up the speed limit to accommodate my new gearing.

THANK YOU for all the support! (though I would still love to know what I'm messing up with the voltage calculation).

-Jon
 
@stancecoke

firstly thank you for your OSF, I really appreciate your work!

I happened to get a cheap second hand controller made by Yuyangking, it looks the same as this link
https://www.alibaba.com/product-detail/Brushless-dc-48V60V72V-35A-1200W-sinusoidal_62205382159.html?spm=a2700.7724857.normal_offer.d_title.7fba5a39ckntGt

after I disassembled it, the hardware in general is in line with Lishui controller (stm32F103C8T6, 3 phase shunt with 3 ops), since the original firmware has a few limits I don't like - can't regen, no cruise control, etc I immediately flashed your OSF and it succeeded! however and unfortunately when I power the controller, it triggers the over current protection, I believe the up and down mosfet are shorted, because two of them touched warm. the power I applied is actually 36V battery charger with 2A current limit, so I think the mosfets are still ok with that much current.

so my question is, do you think there is any possibility that different manufacturer use totally different pins as input and output? though I know there are some limited choice for ADC, PWM, etc.

I unlocked the chip and overwrote the original firmware without any backup... do you have any suggest that by any chance I still can use your firmware to make it work?
 

Attachments

  • IMG_20210714_231751.jpg
    IMG_20210714_231751.jpg
    372.6 KB · Views: 2,840
flute2k3@hotmail.com said:
the hardware in general is in line with Lishui controller
Hm, there seem to be no halfbridge driver, but discrete bootstrap circuits. The drivers that are used in the Lishui-boards are expecting an inverted low-side signal. You can try change this in the timer1 initialisation.

https://github.com/EBiCS/EBiCS_Firmware/blob/389e455aeb39692c452523e9d8ec7e3e086fc112/Src/main.c#L1173

But I don't believe, that the pin usage for current sensing, hall sensing, throttle input etc. is exactly the same on your controller. So you have to check every pin and reassign it to the right function, I guess.

fetch.php


regards
stancecoke
 
exactly, I thought it could be inverted low/high signal causes at initial stage the two mosfets shorted, the check the pin will be a little bit headache, I will try and share if I get any progress.

BTW I also enjoy running and swimming, did an Olympic distance and a 70.3, good to know you do as well.
 
looks the pins are totally messed up, the Hall sensor A socket wired to PA2, which assigned by OSF as throttle, means the controller energized with throttle in max position; the Hall sensor B wired to PA15, which defined by OSF as EBS regen. I'm yet in checking the current sensor pins.

So @stancecoke, what is the most efficient way to reassign those pins? or which portion of the codes I need to check and modify?

Thanks in advance!
 
flute2k3@hotmail.com said:
what is the most efficient way to reassign those pins?
Hm, that's quite difficult, if you are not familiar with the code. Lishui uses the hardware input capture lines of Timer2 for the Hall sensors, so it is very easy to get an interrupt at every change and to read the state directly from the register.
The regular and injected ADC reading is set up in the Timer1 initialisation, there you can adapt the ADC channels to read from.
I suggest, you check the pin functions of your hardware, then I can take a look.

regards
stancecoke
 
Thank you stancecoke, I'm studying your codes (I'm not good at stm32 C/HAL coding, only use Arduino, I have some C/C++ knowledge), looks to me the pin definition is under main.h, I suppose reconfigure there is more than enough? I will spent my weekend figure out all the inputs/outputs associated with my GPIOs.

will keep you posted here.
 
flute2k3@hotmail.com said:
I suppose reconfigure there is more than enough?

No, as there are several direct register readings / writings and peripheral setups, that are not using the defines from the main.h
Not every pin can be configured to every function, a sharp look into the processors datasheet is always necessary :)

regards
stancecoke
 
I spent almost 7 hours testing using a multimeter, finally get all the details, below is the terminal box (TB) with number shown on PCB
IMG_20210716_220841.jpg
and below table shows the stm32 pins used by my board (clockwise), corresponding TB No, its function and the pin defined by Lishui board:
pins.JPG

I do not expect to use all the TBs... could you help me or guild me reassign the pins for my board? my big thanks in advance!
 
flute2k3@hotmail.com said:
could you help me or guild me reassign the pins for my board?
Hm, you'll need at least the Hallsensor pins, the phasecurrent pins and the throttle pin, to make the motor spin.

That's a lot of work, as you have to change almost everything :shock:
Perhaps it is easier to use the ST Motor Control Workbench and start a completely new project....
You can ask Koxx3, he has published a version, that works for the STM32F103

https://github.com/Koxx3/MC_SDK_5.4.5_F103C8T6

regards
stancecoke
 
I might be thinking too easier :)
yep, it is a good chance to start from scratch, try to check if there is some framework using Arduino, the traditional stm32 c coding looks too complicated to me.
 
flute2k3@hotmail.com said:
stm32 c coding looks too complicated

I don't know if the STM32f103 has enough resources for FOC with Arduino, as Arduino doesn't use hardware-near code, normally. :shock:

With the ST MC Workbench, you don't have to write code yourself. You have to setup your system with your specific pinout in a graphical interface and the code is generated automatically. You'll just have to click on 'compile', that's it...

regards
stancecoke
 
there is an Arduino lib called simpleFOC, and there is a few working video on youtube, problem is currently only in-line current sensing is implemented, mine version is low side current sensing, not yet integrated. your advise looks attractive, let me do some further study on both.
 
flute2k3@hotmail.com said:
Arduino lib called simpleFOC

yes, but I don't know any application with a "standard" E-Bike circuit topology. Please let us know, if you get something working!

Koxx3 gave up also...
https://community.simplefoc.com/t/motor-control-for-escooter-based-on-xiaomi-m365/329

The Xiamo M365 controller works with a port of the EBiCS-Firmware and with a ST-MotorControl-Workbench based firmware meanwhile.

1d6d0addf5d0b0398e6485a9caec3e0c.png


regards
stancecoke
 
after further studying the board, I found it is quite different from Lishui with regard to the phase current sensing. I share for further investigation and study.
scheme.jpg
that phase current sensing does not falls into any of the ST current sensing method (1, 2, 3 resistor current sensing)cs.JPG, need to do some calculation instead. this is very popular for higher voltage/power rating controller, using mosfet on-resistor instead of shunt.

I'm studying the ST MC sdk5.4 now, will work under it as you recommended.
 
flute2k3@hotmail.com said:
this is very popular for higher voltage/power rating controller, using mosfet on-resistor instead of shunt
OK, I didn't know that setup yet, but you can find some articles about it.
https://www.planetanalog.com/low-side-rdson-current-sensing/

But for the Workbench it should make no difference, as the AD-Conversion for phase current measuring is only triggered, when the Lo-side FET is conducting. Then the opamp output should be the same as with a "normal" shunt resistor....
A scope picture of the opamp input and output would be interesting :)
(with a working firmware :shock: )

regards
stancecoke
 
stancecoke said:
flute2k3@hotmail.com said:
this is very popular for higher voltage/power rating controller, using mosfet on-resistor instead of shunt
OK, I didn't know that setup yet, but you can find some articles about it.
https://www.planetanalog.com/low-side-rdson-current-sensing/

But for the Workbench it should make no difference, as the AD-Conversion for phase current measuring is only triggered, when the Lo-side FET is conducting. Then the opamp output should be the same as with a "normal" shunt resistor....
A scope picture of the opamp input and output would be interesting :)
(with a working firmware :shock: )

regards
stancecoke

per my formula listed above, the equivalent opamp output of "normal shut resistor" equals to the opamp output of phase B deducts 1.65, and then deducts the measured opamp out put of the bus shunt volatge with coefficient, in order to do that, I have to find the place to modify the codes.

please notice there is a slight difference to the reference you mentioned in the link, the common negative bus is connected to ground via bus shunt, not directly grounded.
 
Back
Top