Lishui "Open Source Firmware" project / KingMeter 5S

[stancecoke]

Any idea what can be wrong here?

Which display are you using exactly? The original Fischer display uses a handshake with the controller at startup, the algorithm in the controller firmware expects the right sequence of commands. If there is a delay or even a different sequence at startup, the communication gets out of sync. The algorithm in the recent master is much more flexible than the old one in the VESC sensorless branch. Perhaps it's worth to update the old branch with the new algorithm.

regards
stancecoke

 

[szupek]

I am using SW900 the picture is from the auction I bought it
It might be that I flashed latest version using java tool and it worked also after power cycle. I do not remember if I rested it extensively after flashing sensorless firmware. Your explanation makes sense actually. Can you please navigate me a bit in which source file I can find this script? I will try to merge it, but it might be difficult with my miserable coding capabilities

 

[stancecoke]

Can you please navigate me a bit in which source file I can find this script?

That's quite complex, as I use a different interrupt source in the new logic.
Perhaps I'll find the time this weekend to update the sensorless branch.

regards
stancecoke

 

[szupek]

You are outstanding! I confirm that using master branch display works like a charm even after power cycle.
Thank you once more - it would be great if you managed to update the sensorless branch
Cheers,
Łukasz

 

[stancecoke]

it would be great if you managed to update the sensorless branch

I've merged the recent UART logic from the Master to the sensorless Branch now and tested it with a BionX DD on my test bench. It works fine, but of course, now the motor parameters for the BionX are set in the config.h
https://github.com/EBiCS/EBiCS_Firmware/commits/Sensorless_VESC/

You have to look into an older commit to get the settings for the Shengyi hubmotor in the Fischer ETH1606.


regards
stancecoke

 

[consp]

So I found out the hall offsets were too variable. Worked "okish" with the stm8 firmware (since at low speeds it doesn't matter and by shifting the angle when speeding up it worked ok) but as soon as you start using it in practice with this firmware the variation in the hall effect sensors becomes too much. I got the engine to turn backwards once after a very shoddy autodetect and a "perfect" start position with the normal values. Also the reason I changed the autodetect angle from one to 0.2 degrees.
Before I started trying the sensorless branch I looked if a "dynamic 30 degree" variable setting might fix is (mostly) and the answer is yes. It now runs smoothly. See here for the code. I have no idea if it's a good idea but it definitely works. My guess is the too large difference in hall positions makes the estimation too variable and causes the engine to fight against itself too much.

Next attempt is trying sensorless, we will see how that goes but that's for another day. Code is not backportable via pull request as is, I'll have a look of making a branch which can be backported if needed.

 

[stancecoke]

So I found out the hall offsets were too variable.

How displaced are your hallsensors??? I never had a motor, where the default interpolation failed....
Can you post the output of the autodetect routine?
You could give the PLL a try, this should give a smooth behaviour also.

regards
stancecoke

 

[consp]

How displaced are your hallsensors???

Very in this motor. The other one it is less, also less issues. It looks like one of the hall sensors got a major slap and went all weird:
Angles in memory in 45, 51, etc transition order: -10, -95, -131, 163, 97, 46
Angles between states: 85, 36, 66, 66, 51, 56

Probably best to switch to sensorless and use it only as a kickoff. I don't really want to open the motor again.

The reason for not directly outputting the sensor routine is because I blew up my last UART by putting 36v on it. More are on order. Just used gdb to fetch the values from memory and convert them.

 

[consp]

Turns out, I was really wrong. The "solution" I made fixed the problem because it was 60 degrees so less "error" prone. The problem was at higher speeds the runaway detection failed for some reason and caused the state to switch from PLL to SIXSTEP once every full rotation (or once every hall event loop at tighter settings is my guess). This caused all kinds of problems. Noticed it when I enabled regen, which was ... terrible. I currently use only SIXSTEP as a kickoff and then switch to pll/interp which works fine with the original 30 degree settings. Now runs a lot better. Enabeling SPEED_PLL makes it even smoother and the current with a speed limit in free air is about as I would expect from air/friction ristance and motor losses.

 

[szupek]

Stancecoke, you will not believe it behaves the same way, ie. right after programming it is ok, but after a power cycle error 30 again. The difference is that now if I use WALK function right after programming, mosfets are getting hot, there are some big watt numbers on the display, and after a few seconds e30 starts blinking, if I am not touching it e30 won't appear until another cycle. It is happening regardless I am changing motor settings or not, checksum of file generated directly from sensorless branch is [LishuiFOC_01.hex] checksum : 0x002B8EBA
master branch still works like before, ie. without errors even after power cycle. Could you please check what is the CRC of your hex file showed by st link utility with default settings that are in sensorless branch?

 

[stancecoke]

The difference is that now if I use WALK function right after programming, mosfets are getting hot

Does that happen, if you disconnect the motor cable also? Looks like one or more MOSFETs are defective.

 

[szupek]

I am testing it on my desk, without motor connected. I tested all mosfets and none is shorted beteen drain and source, in reverse direcion diode measurement displays around 0.6V for each. gates are also not shorted. I can sense that all of them are getting warm, but I can keep my fingers on them all the time (without radiator). I am mentioning this because after 2-3 seconds I am getting E30. During this time I see power draw or around 25W (roughly 0.5A) on my bench supply. I guess it looks almost like a normal startup procedure, with FW for hall sensors I could observe only around 50mA of current increase, but most likely due to the fact that motor startup differs for sensor and sensorless modes.

 

[stancecoke]

During this time I see power draw or around 25W (roughly 0.5A

Hm, in the old branch, the dead time of the PWM is not set properly. You should increase it, like in the master.
https://github.com/EBiCS/EBiCS_Firm...f21d52dbe661d53a394d5e81c589d/Src/main.c#L835

This may lead to over current and ends in the error handler...

regards
stancecoke

 

[szupek]

Ok, thanks for this. But why do you think I am getting E30 after a power cycle?

 

[consp]

This may lead to over current and ends in the error handler...

Which would explain why it was drawing 5A in standstil when I tried the sensorless branch. Wasn't working and kept tripping the BMS I used (which is set 5A max for testing) since my bench supply only allows for 3A and it would trip that immediately.

Ok, thanks for this. But why do you think I am getting E30 after a power cycle?

Just random thoughts since I was posting anyway: Either overcurrent protection as mentioned or maybe something keeps eating cpu cycles and stops the UART from transmitting?

[LishuiFOC_01.hex] checksum : 0x002B8EBA

Depending on the compiler you use this will change, it's very unreliable across platforms and compilers to compare.

 

[stancecoke]

Ok, thanks for this. But why do you think I am getting E30 after a power cycle?

The controller, I developed the firmware with, has a half bridge driver that puts in the deadtime automatically, so it wasn't necessary to set the deadtime in the processor. But obvoiusly, Lishui uses other half bridge drivers without that feature also.

Please set the dead time to 32 as in the master first. Maybe this will solve all problems.

If not, you would have to start debugging from the ST32 Workbench, then you can see, in which part of the code the processor stucks.

regards
stancecoke

 

[Pavlo_LP]

,

Hello. I want to rebuild my bike. My question is: can I use a pedal rotation sensor like this?

 

[stancecoke]

can I use a pedal rotation sensor like this

For what purpose? Of course this standard PAS sensors work for the EBiCS firmware. But they will work with the stock firmware also.
I recomment so called "dual hall sensors" that have the direction detection integrated, as the detection of the crank rotation direction from the duty cycle of the very cheap PAS sensors is slow and and often faulty...

regards
stancecoke

 

[consp]

Can confirm it works, currently have one of those very poor hall sensors on it with 10 magnets. You might want to change the default ramp/end values to suit your need.

 

[szupek]

Please set the dead time to 32 as in the master first. Maybe this will solve all problems.

I changed dead time to 32 and now WALK mode does not trip E30 and I do not see significant increase of current nor can i sense heating transistors, but after powering off and on I see E30
So you suggest uploading the firmware in debug mode? LAst time I got a lot of trouble with ST LINK interface under Eclipse, this is why I am using st link utility.
Stancecoke, you uses this sensorless branch in your fischer 1606, right? hat display did you have? Didn't you experience problems with the deadtime parameter? I recall you mentioned that you did not have any problems riding it

 

[consp]

You can try the following (which is what I did to figure out something else) as a debug tool if you have nothing else:
* check the firmware does not respond to throttle signals (it crashed/halted)
* place the HAL_GPIO_Write for the LED somewhere and check if goes on
* place it further down the code and recompile, keep doing this until it doesn't light anymore. Now you know where it stops.

Same can be done for the loop if you think a place is never reached for instance.

 

[stancecoke]

hat display did you have? Didn't you experience problems with the deadtime parameter?

I had a strange thing with the original display. In the first weeks, it needed a Fischer specific handshake to start properly. Suddenly, one day it behaved different.
https://www.pedelecforum.de/forum/i...are-fuer-lishui-controller.61113/post-1564656

The workbench has a button to start the code in debug mode. This has nothing to do with the display setting "DEBUG"
If you start the code in debug mode, you can run the code step by step, define breakpoints, look at recent variable values, register values and so on....

You can check, what the display sends with the USB UART converter with your laptop first.

I guess Lishui uses different half bridge drivers batchwise, they will buy those, that are available and cheap. There are many suppliers, that are using the same pinout. Some need the dead time in the code, some not...

regards
stancecoke

 

[Pavlo_LP]

For what purpose? Of course this standard PAS sensors work for the EBiCS firmware. But they will work with the stock firmware also.
I recomment so called "dual hall sensors" that have the direction detection integrated, as the detection of the crank rotation direction from the duty cycle of the very cheap PAS sensors is slow and and often faulty...

regards
stancecoke

Guten Morgen!
Vielen Dank für Ihre schnelle Antwort.
Good morning!
Thank you very much for your quick reply.
Perhaps I don't fully understand how everything works, so I apologise for the possibly trivial questions.
I would like to ask you to clarify a few more questions.
1. As far as I know, the standard controller firmware supports only the torque sensor. It was the one that broke in my case (see photo).
Do you know how I can use a disc with magnets, which I mentioned earlier, instead of such a torque sensor? This will make it easy to restore the bike's performance.
2. How can you use a disc with magnets as a torque sensor in your firmware?
3. What other inexpensive sensors can I use as a torque sensor with your firmware? Please provide links or photos if possible.
Thank you in advance.

Mit freundlichen Grüßen, Pavlo

 

[stancecoke]

the standard controller firmware supports only the torque sensor

There are just a few bikes that have a torquesensor installed. Most bottom bracket sensors are just quadrature PAS sensors (e.g. in Fischer bikes). So you should make sure, what your model is. The quadrature PAS connectors have only 4 pins, the torquesensors have 5 or 6 pins.

You can replace the quadrature BB sensors by a quadrature external PAS sensor, sold by EBS or hollandbikeshop for example.

 

[TENET]

Hello stancecoke,

last summer you helped me out in my conversion project in the german forum (you bugfix the code for the BAFANG-DZ41 Display I send to you).

No I´m writing on a detailed dokumentation/instruction of my conversation that i whant to puhlish in this forum, so maybe its more easy for other people to do the same.

During my conversation project i made some improvments mostly on the Java Configurator and also regarding the impulses per turn for the PAS sensor. I make a pull request in github with this improvments. It would be realy nice when you cloud review an maybe accept it. I would like to write the instructions with reference to my improved version.

best regards
tenet