Lishui "Open Source Firmware" project / KingMeter 5S

Are most hall sensors bipolar in ebike motors? Could a A20L be replaced with a more common 41F (or a knock-off)?
Most typical hubmotors use UVW hall sensor position sensing, and most of them use bipolar latching open-collector sensors.

If the A20L is that type, then you can use the SS41 or SS411 variants, which ever one is suitable for the votlage and temperature range of your system. (the different letters are usually for different ranges of those).

If it's not the same in the important particulars as the 41xx types, you'd have to see which one has the same particulars and use those.

Latching or not is important, as the controller being used will have to know if it's seeing the passage of one magnet or two.

Same for unipolar vs bipolar.

output signal type, usually open collector, is important, because if the controller is like all the ones I've seen it has pullups on all the hall signal lines to provide the actual output voltage, and the hall just grounds that to turn the signal on. If your controller does not have pullups, then you have to use a sensor that actually outputs the correct signal type/range the controller expects (0-5v, 0-3.3v, 0-12v, etc), or you have to install pullups (at the controller end, preferably) from the 5v (or whatever the controller expects) to the signal lines.

Supply voltage range for the sensor is important, because many controllers have a diode in series with the 5v supply for the halls, so it is really only 4.3v or less (sometimes as low as <4v). Some (very few) controllers use 12v supply for the halls, some (very few) use 5v supply but 12v pullups, etc. If the supply is very close to the lower limit for the sensor, you may have unreliable sensing when you get noise on the supply or ground lines to the sensors (in the noisy motor cabling environment, that's very common).

Temperature range is important, because these are inside the motor, and while yours aren't in the stator where it can get really hot really fast, it can still get pretty hot in there overall after it's been running a while.
 
Hi everyone, I'm new here and looking for help/guidance on using the Ebics open source firmware on a Lishui controller with a Kingmeter display (key disp kd986) and a Bafang G062 hub drive.

I flashed the firmware to my Lishui controller using the LSH file and a UART adapter and I'm experiencing some behavior that I can't understand.

I first flashed the Ebics firmware with debug mode enabled and autodetect set to 1. This made autodetect run as expected, the wheel ran fine, and I hardcoded the various values from the process.

When I flash the firmware with the correct display protocol (which I assume is DISPLAY_TYPE_KINGMETER_901U since it's the only one that doesn't throw an error), the throttle doesn't work: the motor makes weird noises but the wheel doesn't move.

More surprisingly, when I start the controller via the Uart adapter (no display connected, only red and blue wire contact, as described here open_source_firmware_fuer_lishui_-controller:compilieren_bei_github [Wiki Pedelec-Forum] []=Actions), the throttle works properly.

Even worse, the throttle works when I have set the wrong display protocol.

In all these situations, the PAS doesn't work, but I try to get the throttle to work first.

Any idea what could be the problem here?
 
I hardcoded the various values from the process
Happy, to see that you got the motor turning!
You don't have to use the hardcoded options, the values are stored in the virtual EEPROM during the autodetect routine.
the PAS doesn't work
I took a look into your fork at GitHub, you have the torquesensor mode active. You have to comment out the line #define TS_MODE to use the simple PAS mode.

When I flash the firmware with the correct display protocol
I merged a pull request some days ago without testing it in hardware. You could try to use an older commit. I will cross-check the pull request this evening!

regards
stancecoke
 
Thanks, disable the torque sensor helped to fix the PAS issue, but still when using the KMS5 protocol the motor is making noise without turning the wheel. Here's a video that shows the problem
 
but still when using the KMS5 protocol the motor is making noise without turning the wheel.
I found the bug :)
I've implemented the reverse function for the parameter P19 of the EN06 protocol. But this protocol differs from the original 5s that Key-Display uses. The motor runs in the freewheel. I just commented out that function in the master branch:
 
Could it be possible to get this motor to run:
View attachment 363256

This is a smaller (just a bit ;)) front motor from Sparta. No controller inside, just a motor. The funny thing is the magnet ring in the lid. The hall sensors work on this ring, not on the actual magnets that the stators/poles use :rolleyes:. Could it work with the current software; does "autodetect" find the right values to compensate for a difference (angle?) between both rings of magnets?
They are PMSM motors afaik, but are workable. it's not perfect but manegable. And since you can get them for dirt cheap I figured to just try it.

So probably yes, I'll report back (if I do not forget) when I get it running properly. I have it in auto calibration mode for the sensors which works. Open loop is at least a go and since it works in the stm8 controller variant I'm sure it will work with this one. I'm using a rear wheel motor, they are almost the same. I've been running it with the stm8 firmware/hardware for over a year before now "upgrading"

The rear wheel hall sensor are 38.something degrees apart (mechanically, electrically it's also weird but I cannot remember the offset, the sensors are also non-latching in the rear wheel variant, and the rear wheel contains 6 all in the same orientation). The magnet ring is, as far as I can tell, equivalent to the magnets in the rotor, make sure to align it properly and there is one screw hole with a alignment circle. I made a 120 degree adapter board and put hall sensors in there (Note, Might contain errors, thought snafus and other issues). They work after you get it up to speed, but there is a bit of variation in motors (I have two), and you need to calibrate them properly as in my case they differ from a minimum of ~55 degrees to about 70 degrees (offset between hall transitions). By sample of two I could not determine if this was manufacturing tolerances of my setup or by design but since they are not the same for the two I'm guessing my diy hall-sensor-keep-sensors-in-place thing is not as accurate as I would like. Might just be the offset of the sensors from the ring causing the differences due to earlier/later transition.

On the PMSM issue: the sinus form of the motors is what you expect to get this motor running with the firmware and thus should work when you get it up to speed. They also have very little torque, so no dead-stop starts.

The temperature NTC is either a 100k of 10k variant, you might need to replace it or at least measure it to be sure wich one it is (one of my motors came with the 10k, the other with a 100k, the PCB's were also a different revision but mostly identical).

Additional note: If you get really noisy signal interference, add some low value caps on the hall sensor lines. Or get a scope and calculate the proper value of the caps if you realy need to \_(ツ)_/

edit: Gonna take a while to report back as I killed the MCU. It won't program anymore, got some 103CB's arriving in a few days and testing my LFPQ48 solderings skills.

On the temperature side: I would not bother too much, the max I've ever gotten it to is about 60c in the summer which is well within the range of the sensors I used. I've been running it at ~24V (a 7s pack) at about 300W peak output.
 
Last edited:
Thanks for your response!
I'm using the rear wheel variant, they are almost the same. I've been running it with the stm8 firmware/hardware for over a year
I find that interesting; could the torque sensor be used?
They work after you get it up to speed
Is that "the issue" with a/these PMSM motors? Cannot provide power from standstill?
Might just be the offset of the sensors from the ring causing the differences due to earlier/later transition.
Will the auto-detect not "solve" an offset between magnet-ring, hall-sensors and stator (-position)?

Your adapter-board looks great! Could be a second life for these XHP motors.
 
I find that interesting; could the torque sensor be used?
It's all a bit murky in my memory but if I remember correctly the torque sensor is kind of tied to the controller in the rear hub motor. Never bothered to test it and I didn't want to pull of the gears to find out what it exactly was. You might have some luck there but I have no info for you. If you find out let me know, though you need more cables or a adapter board to send all the signals though. I guess I stopped there as there is barely enough space to get a 9 wire cable through.

Is that "the issue" with a/these PMSM motors? Cannot provide power from standstill?
True afaik, though I'm not too much into how all the configurations work so your expertise is probably more accurate. It's been a while since I took my course on electric motors.

Will the auto-detect not "solve" an offset between magnet-ring, hall-sensors and stator (-position)?
Yup, for the other controller I have in there now you need to measure it yourself. But with this firmware it is easy to do. Also, the ring matches the magnets in the rotor if you pick the correct alignment (Guess how I figured out there was a screwhole with an alignment ring in it).

Your adapter-board looks great! Could be a second life for these XHP motors.
Thanks, you do need a good soldering iron as I left out the heat reliefs on some soldering pads as most PCB manufacturers now only offer cheap pcb's in 1oz copper. I'm sure the board will allow up the the max 24A of the WAGO connectors but to be on the safe side I went with max-contact. And since I have a metcal soldering iron it's not an issue but it might be a bit much for a standard 25w iron.

There is also a complete in-place replacement for the original one afaik. Though I do not know where I learned about that (might be a german forum iirc). You then also still need the **** NiMH battery and the LCD in that case which I also replaced with a 7s9p pack which fits in the versions with the streight in-tube batteries instead of the banana ones (not recommended for anyone with common sense).

You might want to check the angle of the hall sensors i nthe front wheel variant. They might be 120 degrees (check electrically with a scope if you are able to). The rear wheel variant is definately not 60 or 120 degrees and my guess is they are two for each phase.

I also remember that all motors needed to be calibrated anyway from factory (as reported on a dutch forum by one of the engineers working on it). So the ring might not be aligned as you'd expect. Not an issue with the EBiCS firmware but something to keep in mind.

Since you are most likely a dutch speaker, a short thread on circuitsonline about the engine.
 
Last edited:
There is also a complete in-place replacement for the original one afaik.
For me the Sparta-Ion-modify-thingy started with discoveries and work that "infant" did. He did make a drop-in-replacement pcb. However that is for the older "toprun-motors". These motors might not be PMSM motors:
1737202936636.pngreplacement for toprun
You might want to check the angle of the hall sensors i nthe front wheel variant.
There are two variants of the FWD: a bigger one with controller inside (the same as RWD, but without torque sensor). And a smaller one that is used for both Ion bikes as well as the more basic "e-motion" ones that have a speed-sensor and different controller and battery. The hall-sensor (3 pieces) arrangement is more conventional.
1737202646408.pngRWD 1737202767833.png FWD (pcb)
I also remember that all motors needed to be calibrated anyway from factory
I think that would be correct (if I do somewhat understand correctly what "auto-detect" does :rolleyes:).
I did once swap the coverplate with magnet ring between 2 motors and it did work however (might got lucky).
 
if I do somewhat understand correctly what "auto-detect" does
In EBiCS the autodetect routine drives the motor in open loop very slowly first. So it powers the coils in space vector modulation without knowing the rotor position and increases the angle in steps of one degree for three complete electrical revolutions. The rotor follows the electric field from the coils without producing torque. The firmware stores the angle for each hall state transition in the virtual EEPROM. After the hall angle detections has finished, the motor accelerates slowly up to top speed, to get the motor's Kv constant.

But there is no need to have the hallsensors, EBiCS is able to drive the motor with FOC in sensorless mode. In the "New generation" branch there are various strategies implemented, how to start from standstill. For a direct drive you would have to use the "Sensorless_startkick" mode. You have to start the bike for the first meter by your legs, to let the sensorless observer get the rotor angle, then the motor can start assistance. But I never tested that feature with a bike, only with a scooter. And you have to use much faster P and I parameters for the current control loop to avoid a drag at the start.

regards
stancecoke
 
loop very slowly first
MIght be a miss on my part, but it speeds up quite quickly. Though it is in a stand and well lubricated and has no complete wheel on it so very little mass.
But there is no need to have the hallsensors, EBiCS is able to drive the motor with FOC in sensorless mode. In the "New generation" branch there are various strategies implemented, how to start from standstill. For a direct drive you would have to use the "Sensorless_startkick" mode. You have to start the bike for the first meter by your legs, to let the sensorless observer get the rotor angle, then the motor can start assistance. But I never tested that feature with a bike, only with a scooter. And you have to use much faster P and I parameters for the current control loop to avoid a drag at the start.
Definitely going to try that if I can fix the boken MCU. Anyone did a upgrade to a normal STM32F103Cx instead of the chinese variant?
 
"toprun-motors". These motors might not be PMSM motors
Afaik they do not even have the same magnet/pole configuration, but I'm going from memory here. Not interchangable at least.

Do remember that the rear/front need a different axle since one has gears and such ;)
 
isn't the other one also 24v? though running it at 36 should be fine I guess.
The stickers on the XHP motors says "24-36V".

The smaller FWD motors are available in 2 variants: 24V and 36V :mrgreen: .

Sparta made/used quite a bit of different motors for the ION system.
 
Anyone did a upgrade to a normal STM32F103Cx instead of the chinese variant?
Should be possible, but I never tried to do it. I've started to desolder the processor with hot air from a blue pill board and wanted to resolder it to get some practice in SMD soldering, but I've not tried it yet.

Definitely going to try that
You have to tune the relevant parameters by hand, as there is no autodetection for coil resistance, inductivity, flux etc. like in the VESC tool. It's a little trial and error, but finally it worked for every motor I tested....

regards
stancecoke
 
isn't the other one also 24v? though running it at 36 should be fine I guess.
As long as there are no electronics powered by that, just the phases, then "any" brushless motor could be run on any voltage up to it's electrical insulation limit, as long as that doesn't cause a speed higher than the mechanical strength of the spinning parts.
 
Hi folks! I just bought dirt cheap fischer 1606 ebike with mallfunction of electric system. Battery is good, a bit unballanced, but easily handled 13A with electronic load with just a little sag. The funny thing is that it has a bafang C965 display, plug and socket are cut, ane cables are connected with twisting one to another :) After powering up display shows 30h (communication error) which is totally expected since bike as originally supposed to have LCD-SW display, which is using other communication protocol than bafang one. I am wondering how to verify if the controller is working well, If I twist together P+48V and Power Lock cables in harness that goes to the controller, it should start. Does it start with some level of support or is this 0 and has to be adjusted.
I guess that eventually I will flash it with lishui open source, but I ould like to check if it is functional.
BTW, very good piece of work! I was following this topic on pedelec.de and kudos to all contributors :)
 
If I twist together P+48V and Power Lock cables in harness that goes to the controller, it should start.
Yes. You could check, if the 5V supply on the PAS connector is present, with red and blue connected on the display cable.
The default PAS level should be active with no UART communication. Just give it a try (y)
Another option is to connect a throttle to the "SP" solder pad on the PCB, but I guess the controller is potted and not easy to disassemble.
See my mod at pedelecforum.de

index.php
 
Ok, I disassembled controller and display from the bike, wires we wrongly connected P48+ was fed to PL of the display, +48V of display was connected to the TX of controller, Rxes together, only grounds were connected correctly :D
I am hoping that controller Tx did not suffer being connected to P48V of the display.
I connected everything as it should be, after powering up from the display, the controller starts, red LED starts blinking, and there is 5V on PAS pin, but bafand still shows 30h which is communication error - as expected.
I guess that now I am flashing it with this firmware but I got to select BAFANG protocol for the display, right? :)
Thanks a lot, I am really excited to bring this old crate alive :D
 
No, the whole sensorless stuff is not implemented in the master.
You would have to port the BAFANG protocol to the sensorless branch. 🤷‍♂️
 
Back
Top