Lishui "Open Source Firmware" project / KingMeter 5S

[BENLY]

Am I right? You suggest that in the procedure for calculating the motor current using the "throttle override" procedure, we substitute the filtered value of the ADC of the torque sensor instead of the filtered value of the ADC of the throttle?

 

[stancecoke]

Am I right?

I don't get your point. In throttle override I read the recent throttle value directly from the ADC array without filtering.

 uint16_mapped_throttle = map(adcData[1], THROTTLE_OFFSET, THROTTLE_MAX, 0,PH_CURRENT_MAX); //throttle override, no torque override in this version actually

adcData[1] contents the value of the "SP" input, that normally is used by the throttle.
adcData[6] contents the value of the "AD1" input that is used by the torquesensor.

uint16_mapped_throttle = map(adcData[6], TORQUE_OFFSET, TORQUE_MAX, 0,PH_CURRENT_MAX);

TORQUE_OFFSET and TORQUE_MAX are defined in the main.h

And of course you can keep a real throttle override, if you want to use a throttle in parallel, if you define a "uint16_mapped_torque"
and check, which is the highest value to apply to the iq setpoint...

I have never implemented this, as I don't like it. The motor always wants to run, if you just rest your foot on the pedal at red traffic light.
For me it's completely OK, if the motor starts smoothly whithin the first quarter of the first pedal revolution.

 

[BENLY]

For me it's completely OK, if the motor starts smoothly whithin the first quarter of the first pedal revolution.

For me it's two pedal turns.

adcData[6] contents the value of the "AD1" input that is used by the torquesensor.

uint16_mapped_throttle = map(adcData[6], TORQUE_OFFSET, TORQUE_MAX, 0,PH_CURRENT_MAX);

But I didn't find such a line in the code.
That's what I'm talking about. Only the TORQUE OFFSET here needs to be greater than when rotating the pedals so that the motor wants to work if you press hard on the pedals.

Of course for the motor power calculation, you can use the speed from the hall sensors always, as you don't need the speed information at standstill.... This would be much faster than the external speed sensor, as you get much more pulses per wheel Revolution.

Is it possible to get the speed for the speedometer and limits from an external sensor on the wheel, and the speed for current calculations from the Hall sensors in the motor?

 

[stancecoke]

But I didn't find such a line in the code.

?! See the link.

For this, you can misuse the function "throttle override".

speed for current calculations from the Hall sensors in the motor?

Sure. But the wheel speed is not in the iq setpoint calculation recently, as written before. Do you want to add it?!

The time between to hall sensors events is represented by the variable ui16_timertics

If you want to use it, you have to scale the whole iq setpoint calculation formula to the expected number range...

 

[BENLY]

Instead of the string
uint16_mapped_throttle = map(adcData[1], THROTTLE_OFFSET, THROTTLE_MAX, 0,PH_CURRENT_MAX); //

I inserted a line

uint16_mapped_throttle = map(adcData[6], TORQUE_OFFSET, TORQUE_MAX, 0,PH_CURRENT_MAX);

The motor started to start when the pedals were depressed.

Question - does the 6 km/h limit work in this situation?

 

[stancecoke]

Question - does the 6 km/h limit work in this situation?

Yes, if the legal flag in the main.h is activated and the pedals are not turning.
But always test with load, otherwise, you will get a great oszillation.

 

[Dingelfing]

Hi,

I have a new Lishui LSW1728-1-1F controller, which came with an EN06 display. I'd like to use it with am AKM100 motor.

I compiled and flashed the current firmware from Aktualisieren von display_kunteng.h · EBiCS/EBiCS_Firmware@858ce2d with AUTODETECT set to 1 (see attachment).

After turning the battery power off and on (read: pulling the plug) the LED on the controller board starts flashing rapidly. The display is on and does not show an error. I expected the autodetect procedure to start turning the wheel but nothing happens.

I've seen that there's a debugging option, but I have not idea how to use that, the docs just say to "look at the UART data". Which device do I use for that and how do I connect it?

In short: I'm lost here. Any help appreciated!

 

[stancecoke]

I expected the autodetect procedure to start turning the wheel but nothing happens

See the Wiki:

you can start the autodetect routine by activating the autodetect and debug option

So you have to set the display to DISPLAY_TYPE_DEBUG. The display will show a communication error then, but this doesn't matter. Just let the autodetect finish, then you can flash with the right display setting again.

Which device do I use for that and how do I connect it?

It's the same as in the Kunteng project, just the BAUD rate has to be set to 56000:

07 The Diagnostics Mode

OSEC Open Source E-Bike Controller in a Windows toolchain for a STM8 - stancecoke/BMSBattery_S_controllers_firmware

github.com

Some of the parameters are explained in the EBiCS wiki, but of course you can print out any variable, you are interested in.

General debugging

Free FOC firmware for Lishui E-Bike-Controllers. Contribute to EBiCS/EBiCS_Firmware development by creating an account on GitHub.

github.com

 

[Dingelfing]

So you have to set the display to DISPLAY_TYPE_DEBUG. The display will show a communication error then, but this doesn't matter. Just let the autodetect finish, then you can flash with the right display setting again.

Thank you, that was the problem. I got the serial debugger connected, too.

Unfortunatly, I ran right into the next problem: Autodetect seems to complete successfully, however after that (and flashing without autodetect), I cannot get the motor to run. This might be a simple missunderstanding, though.

I currently have the wheel on a workbench. The controller is supposed to be used with a PAS only, no torque, no "thumbthing". When I pass a magnet along the PAS, either way, the controller registers that movement with an ever changing uint32_PAS:

0, 5, 5000, 8000, 0, 0, 0, 0, 0
0, 5, 5000, 7301, 0, 0, 0, 0, 0
0, 5, 5000, 6280, 0, 0, 0, 0, 0
0, 5, 5000, 5381, 0, 0, 0, 0, 0
0, 5, 5000, 4732, 0, 0, 0, 0, 0
0, 5, 5000, 4250, 0, 0, 0, 0, 0
0, 5, 5000, 3823, 0, 0, 0, 0, 0

The motor does not start, though. Is my misunderstanding that the wheel has to be turned, too, in addition to a PAS signal?

I am quite sure that I selected PAS-only mode in the Java config tool by disabling "Torque sensor" and "Torque signal on AD1", but can't find a corresponding setting in the config.h.

---

Unrelated to my current problem: If autodetect doesn't start without DISPLAY_TYPE_DEBUG, shouldn't the code give a hint about this? Something like:

#if (DISPLAY_TYPE == DISPLAY_TYPE_DEBUG)
    printf_("phase current offsets:  %d, %d, %d \n ", ui16_ph1_offset, ui16_ph2_offset, ui16_ph3_offset);
    printf_("internal temperature raw reading:  %d, \n ", adcData[7]);
#endif
#if (AUTODETECT == 1)
#if (DISPLAY_TYPE != DISPLAY_TYPE_DEBUG)
#error "To use autodetect, set DISPLAY_TYPE to DISPLAY_TYPE_DEBUG, too."
#else
    if(adcData[0]>VOLTAGE_MIN) autodetect();
    else printf_("Battery voltage too low!:  %d,\n ",adcData[0]);
#endif

 

[stancecoke]

The motor does not start, though. Is my misunderstanding that the wheel has to be turned, too, in addition to a PAS signal?

No, the motor must start, if a movement of the pedals is detected and the torquesensor mode and is not activated. Try with the direction detection disabled first.
You can cross check, if there are plausible hall angles printed at startup in debug mode.
Or with the display connected, try the walk mode.

 

[Dingelfing]

No, the motor must start, if a movement of the pedals is detected and the torquesensor mode and is not activated. Try with the direction detection disabled first.

Direction detection is disabled. I uncommented the LED toggle at line 742 in the section "SPEED signal processing" and added a toggle at line 710 in "PAS signal processing" (and put the LED toggle in lines 1020 and 1021 in a comment). LED toggles once I turn the wheel and every time I pass a magnet along the PAS – signal input works.

with the display connected, try the walk mode.

That worked – once. The wheel turned quite slowly, seemed rather sneaky than walk-ly. Also, it did not stop after I let go off the button for two or three revolutions of the wheel.
Pressing the button again does not make the wheel move anymore, even after removing and attaching the battery. The transistors get warm, though, so something seems to happen.

Using the PAS magnet alone, the transistors do not get warm.

You can cross check, if there are plausible hall angles printed at startup in debug mode.

Is this plausible?

regular reset

phase current offsets:  2017, 1981, 2001 
internal temperature raw reading:  1743, 
Hall_Order: -1 
Hall_45: 32 
Hall_45: 393674752 
Hall_51: 96 
Hall_51: 1157234688 
Hall_13: 154 
Hall_13: 1849163776 
Hall_32: -148 
Hall_32: 2541158400 
Hall_26: -86 
Hall_26: 3280863232 
Hall_64: -25 
Hall_64: 4008574976 
KV: 560
Lishui FOC v1.0

 

[stancecoke]

Is this plausible?

Yes.
The 6th variable (int32_temp_current_target) in the log must be different from zero to start the motor.

What is your battery voltage?
You can replace one of the printed parameters by uint16_mapped_PAS to see what the setpoint from the PAS would be.

 

[Dingelfing]

Battery is fully charged, 41 volt (10S).

I noticed that SystemState is Running (3) for a few lines after reset, but then drops to Stop (0). There's section check if rotor is turning that sets SystemState to Stop – doesn't that turn off the motor if the wheel doesn't turn (which I don't, as mentioned earlier)?

When using the PAS magnet I get the following output:

0, 5, 5000 uint32_PAS=2658 uint16_mapped_PAS=501 0, 0, 0, 0, 0 brake_flag=0
0, 5, 5000 uint32_PAS=3994 uint16_mapped_PAS=376 0, 0, 0, 0, 0 brake_flag=0
0, 5, 5000 uint32_PAS=3330 uint16_mapped_PAS=439 0, 0, 0, 0, 0 brake_flag=0
1, 5, 5000 uint32_PAS=2825 uint16_mapped_PAS=486 0, 0, 0, 0, 0 brake_flag=0
0, 5, 5000 uint32_PAS=2825 uint16_mapped_PAS=486 0, 0, 0, 0, 0 brake_flag=0

_temp_current_target should be set to _mapped_PAS in line 895, if I got that right, but stays at 0 for some reason.

I'll check later if the problem is related to brake_flag and MP.speedLimit or a few lines down at the KM.DirectSetpoint and temperature tests .

After that, int32_temp_current_target is not touched again in the code until the debug output (where it's 0).

 

[stancecoke]

I'll check later

You can check adcData[0] also, that's the battery voltage.
Was the wheel spinning up to max speed during autodetect? If not, the motor may turn in the wrong direction in the freewheel....

 

[Dingelfing]

Guess I found the problem: Do I have to set THROTTLE_OVERRIDE even though I don't have a throttle?

In line 895 int32_temp_current_target is set to uint16_mapped_PAS. That seems to be the only instance where temp_current_target is set to anything meaningful for my setup.

This is in a section "#ifndef TS_MODE //normal PAS Mode", which in turn is in a section "#ifdef THROTTLE_OVERRIDE". Since THROTTLE_OVERRIDE was not set (I have no throttle), line 895 is never executed and temp_current_target remains at 0.

#define THROTTLE_OVERRIDE 1 now starts the motor if PAS is active.

 

[Dingelfing]

I am a bit surprised that the wheel starts turning rather powerful. Is this because the wheel is currently rotating free or is there a problem with no throttle being connected?

The motor power is first calculated by pedaling speed and the assist level set by the display, is that right?

Then there's a part 'if(uint16_mapped_throttle>int32_temp_current_target)' that affects temp_current_target a few lines down. How does THROTTLE_OVERRIDE affect motor power and what's the difference to SPEEDTHROTTLE?

Which pin is adcData[1] (the throttle) mapped to? My controller has no throttle connector.

 

[stancecoke]

Since THROTTLE_OVERRIDE was not set (I have no throttle), line 895 is never executed and temp_current_target remains at 0.

OK, that's a bug, that no one reported until now.
I don't use the simple PAS mode, so I never recognised that

I am a bit surprised that the wheel starts turning rather powerful.

With iq we set the motor torque. If there is no load, even very little torque will spin the wheel very fast.
Throttle override just checks, which signal is higher. The one from the PAS or the one from the throttle.
The higher one is used for the iq setpoint.
In speedthrottle mode, the throttle doesn't set iq (=torque) of the motor, but the speed. Cheap controllers doesn't set the current, but the voltage with the throttle and just limit the current to the max battery current. The voltage defines the speed mainly. So, many users who were familiar with this behaviour, were irritated that the wheel spins up to top speed with very little throttle with no load. In the EBICS firmware, the speedthrottle does not simply set the voltage, but sets a second control loop for the speed above the current control loop. So the speed is kept constant, even if the load changes. But the PI control for the speed is quite tricky to tune.

 

[Dingelfing]

So, the controller works, I rode the first 50 km. Motor support is way too strong, though. Even in level 1 (of 5) the bike keeps getting faster and faster without me using any force.

Is it correct that motor power is simply calculated using cadence times support level, line 852?

How does assist_profile for INDIVIDUAL_MODES work? It looks like a mapping from km/h to a speed factor, is that correct? I cannot get my head wrapped around how that factor applies to the motor power or if it's even the right place to limit the power in the lowest support level, but not the highest.
My goal would be to lower the support in level 1 of 5, but keep full support in level 5 of 5.

 

[stancecoke]

Is it correct that motor power is simply calculated using cadence times support level, line 852?

Not the power, but the torque. So the power will increase with the speed.

Even in level 1 (of 5) the bike keeps getting faster and faster without me using any force.

What kind of display are you using? This is the big advantage of the 5s protocol, you can set the percentage of the each level individually in the display (if the display firmware has the option to do so). Individual modes are an option for torque sensor mode only.

Individual settings for each level are implemented for the Bafang display. You could use this also for the 5s, If you can find a constant divider, that leads to integer values 0 to 5 from the values, that the display sends for the assist levels. We had this discussion in this thread already.

EBiCS_Firmware/Src/main.c at 858ce2dc9dc7ba1e24f04ec7f098522ed620864b · EBiCS/EBiCS_Firmware

Free FOC firmware for Lishui E-Bike-Controllers. Contribute to EBiCS/EBiCS_Firmware development by creating an account on GitHub.

github.com

 

[BENLY]

Hello.
You probably hoped I wouldn't show up again. But here I am.
I rode the bike and let my sister ride it in real conditions. It rides well.
At some point, my torque sensor started going crazy.
Sometimes it didn't work, sometimes without applying any force to the pedals the bike moved by itself. Let me remind you that I have the torque value inserted into THROTTLE_OVERRIDE. Following the advice of those who've experienced hallucinations with these sensors, I connected the negative battery terminal to the frame. I'll keep an eye on things.

And yet I still couldn't get the bike set up perfectly.
First. When starting off, the THROTTLE_OVERRIDE response to pedal input is too abrupt. Can I add a reduction factor?

Second. When you press the pedals sharply when starting off, the current in the battery becomes too high. My headlight goes out and the controller reboots. How does current limiting work in this situation?

Third. In pedaling mode, on the contrary, the motor response is very weak. It seems to me that the cadence and torque filtering needs to be weakened. How to do this?

To reduce the number of stupid questions, I suggest drawing a diagram of the program's main algorithm blocks with links to specific lines of code. And maybe add links to forum posts where this code is discussed. This will help structure the information. Even if the code changes slightly, such a diagram will be very helpful when starting out.

Once again, I thank you for this project.

 

[stancecoke]

How to do this?

Have you committed your settings to your GitHub repo? Can you post a link to your config.h? Or post it here directly?

 

[BENLY]

I'll try to retrieve my settings. The problem is, the tablet I compiled the firmware on has stopped charging and is sitting like a motherboard next to the soldering station. I need to connect a screen, a fan, and a heatsink to it and copy the folder to my laptop.

 

[BENLY]

This bike is a pain. At home, it's 20 degrees, and everything works fine. I go outside, and it's 5-7 degrees, and the thing cools down for about 15 minutes, then starts running without any external input, and then stops running altogether. I bring it inside, it warms up, and then everything works again. And this happens over and over again. What the hell? The controller works, and the connection to the screen works. I think something's going on in the torque sensor-STM32 input divider circuit. Or the Chinese transistors in the sensor itself are going crazy. Any ideas?

In this regard, a question.

I saw somewhere that you can attach a Bluetooth module instead of the screen and receive debugging information on the phone. Is this possible?

 

[stancecoke]

Any ideas?

Which branch are you using? In the master I have switched to read in the offset of the torquesignal at startup, instead of using a fixed offset, defined in the config.h
I had the same experience, there is a certain drift in the offset value with the temperature.

You can use a Bluetooth module instead of the display, if you set the display type to debug. A how to can be found in the Wiki.
You can use the HM10 BLE module also, the HC-05 is outdated meanwhile.

 

[BENLY]

EBiCS_Firmware-2261029

12 FET new controller. This is the last version that compiled and flashed correctly on my controller. The torque sensor offset is permanent. It is very interesting that you had similar symptoms. Is it possible to enable automatic offset detection when enabling it in my firmware version?
Is there a working program for Android that can read the data stream from Bluetooth and somehow display it?