Open Source Firmware für Lishui Controller

Diskutiere Open Source Firmware für Lishui Controller im Controller/Regler, Fahrerinformation, Elektronik Forum im Bereich Diskussionen; Hm, da sind die User bei ES anderer Meinung, da hagelt es gerade einen shitstorm nach dem anderen. Keine Ahnung, ob Kunteng was an seinen...

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
die Kunteng Software ist sicher so gut wie ausentwickelt und läuft völlig stabil.
Hm, da sind die User bei ES anderer Meinung, da hagelt es gerade einen shitstorm nach dem anderen. Keine Ahnung, ob Kunteng was an seinen Controllern geändert hat, am Code habe ich auf jeden Fall schon ewig nichts mehr gemacht.... Vielleicht auch eine neue Android-Version, mit der die BluOsec App den Controller noch mehr vollspamt als bisher, keine Ahnung wie @Xnyle damals das Timing in Android gemacht hat.

der Lishui wurde mir am Ende etwas zu kompliziert.
Das hörte sich doch hier schon mal recht zufrieden an?! Die letzten Änderungen mit dem 6 Step und der PLL waren ja "nur" zur Lösung von speziellen Problemen und sind nicht umsonst auf dem "Advanced Settings" Tab, von dem man eigentlich die Finger lassen sollte. 6 Step macht der Kunteng beim Start übrigens auch, allerdings ist das alles hardgecodet, so daß der "Otto-Normal-User" da gar nichts dran einstellen kann....
Vielleicht sollte ich bei proven settings eine Einstellung hinterlegen, die für die meisten User out of the box funktionieren sollte. Also PLL deaktiviert und Umschaltung von Six Step auf FOC sehr früh...

Gruß
hochsitzcola
 

reinosmart

Dabei seit
29.04.2017
Beiträge
547
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
Hm, da sind die User bei ES anderer Meinung
Ich benutzte ja den torque-x4 Branch mit der Integerarithmetik, der Master lief am Schluss ja nicht mehr sonderlich stabil.
Das hörte sich doch hier schon mal recht zufrieden an?!
war ich ja auch, bis auf die Fehlzündungen. Wie gesagt, ich kann alles jederzeit umstecken. 3 Räder mit jeweils verschiedenen Controllern und Software hat mich zuletzt etwas irre gemacht.
 

Fluctuator

Dabei seit
05.04.2021
Beiträge
6
Meine Drähte der HALL-Sensoren sind alle in Ordnung, weil ich die Master-Version gefunden habe, die ich letzten Sommer 28.06.2020 ausprobiert habe
und sie funktioniert jetzt mit meinem Motor. Aber der neue nicht.
Hier ist der Screenshot der alten Firmware:

Screen Shot 2021-04-06 at 21.09.55.png

Motor dreht sich, aber meiner Meinung nach, Mosfets immer heiß. nicht so viel, aber Strom ist etwa 1,5A auf Leerlauf

Ich werde jetzt wieder New Master versuchen, und arozhkov2001 hilft mir per Chat

English:
My wires of HALL sensors are all ok, because I have found Master version which i tried last summer 28.06.2020
and it works with my motor right now. But new one doesnt.
Here is the screenshot of old firmware:

Motor is spinning, but to my opinion, Mosfets getting hot. not so much but current is about 1.5A on idling

I will try now again New Master, and arozhkov2001 is helping me by chat
 

Fluctuator

Dabei seit
05.04.2021
Beiträge
6
Gute Nachrichten. Ich möchte berichten, dass alle begonnen, jetzt zu arbeiten. auf meinem Tisch stehen. morgen wird auf der Straße versuchen! vielen Dank arozhkov2001und Hochsitzcola!!!

wird später auch sensorless ausprobieren
 

Fluctuator

Dabei seit
05.04.2021
Beiträge
6
ich denke, ich habe vielleicht einen BUG gefunden:

Mit dieser Config alles funktionieren.

/*
* config.h
*
* Automatically created by Lishui Parameter Configurator
* Author: stancecoke
*/

#ifndef CONFIG_H_
#define CONFIG_H_
#include "stdint.h"
#define DISPLAY_TYPE_EBiCS (1<<5)
#define DISPLAY_TYPE_KINGMETER_618U (1<<4) // King-Meter 618U protocol (KM5s, EBS-LCD2, J-LCD, SW-LCD)
#define DISPLAY_TYPE_KINGMETER_901U (1<<8) // King-Meter 901U protocol (KM5s)
#define DISPLAY_TYPE_KINGMETER (DISPLAY_TYPE_KINGMETER_618U|DISPLAY_TYPE_KINGMETER_901U)
#define DISPLAY_TYPE_BAFANG (1<<2) // For 'Blaupunkt' Display of Prophete Entdecker
#define DISPLAY_TYPE_KUNTENG (1<<1) // For ASCII-Output in Debug mode
#define DISPLAY_TYPE_DEBUG (1<<0) // For ASCII-Output in Debug mode);
#define EXTERNAL 1
#define INTERNAL 0

#define TRIGGER_OFFSET_ADC 50
#define TRIGGER_DEFAULT 2020
#define _T 2028
#define CAL_BAT_V 256
#define CAL_V 15LL<<8
#define CAL_I 38LL<<8
#define INDUCTANCE 6
#define RESISTANCE 40
#define FLUX_LINKAGE 1200
#define GAMMA 9
#define BATTERY_LEVEL_1 323000
#define BATTERY_LEVEL_2 329000
#define BATTERY_LEVEL_3 344000
#define BATTERY_LEVEL_4 368000
#define BATTERY_LEVEL_5 380000
#define P_FACTOR_I_Q 200
#define I_FACTOR_I_Q 1
#define P_FACTOR_I_D 450
#define I_FACTOR_I_D 12
#define P_FACTOR_PLL 5
#define I_FACTOR_PLL 11
#define P_FACTOR_SPEED 100
#define I_FACTOR_SPEED 10
#define SPDSHFT 0
#define SPEEDFILTER 1
#define SIXSTEPTHRESHOLD 10000
#define TS_COEF 60000
#define PAS_TIMEOUT 8000
#define RAMP_END 1600
#define FRAC_HIGH 30
#define FRAC_LOW 15
#define THROTTLE_OFFSET 100
#define THROTTLE_MAX 2600
#define PUSHASSIST_CURRENT 30
#define WHEEL_CIRCUMFERENCE 2200
#define GEAR_RATIO 60
#define SPEEDLIMIT 25
#define PULSES_PER_REVOLUTION 1
#define PH_CURRENT_MAX 600
#define BATTERYCURRENT_MAX 15000
#define REGEN_CURRENT 200
#define REGEN_CURRENT_MAX 10000
#define VOLTAGE_MIN 1
#define VOLTAGE_MAX 1600
#define SPEC_ANGLE -715827882
#define DISPLAY_TYPE DISPLAY_TYPE_EBiCS
#define SPEEDSOURCE INTERNAL
#define AUTODETECT 0
#define REVERSE 1
#define THROTTLE_OVERRIDE

#endif /* CONFIG_H_ */

aber wenn ich in der config.h nur eine Zeile ändere:

#define DISPLAY_TYPE DISPLAY_TYPE_EBiCS

zu
#define DISPLAY_TYPE DISPLAY_TYPE_DEBUG

Motor reagiert nicht mehr auf Throttle

Ist das normal?
 

tomsen61

Dabei seit
18.09.2014
Beiträge
115
Ort
Raum Würzburg
Habe ich auch einen Bug gefunden?
Im Display typ Debug wird der Winkel aus dem EEprom genommen und nicht der Eintrag SPEC_ANGLE aus der config.h.
Wenn ich die Zeilen richtig interpretiere sollte das aber nicht so sein. Er sollte nur den Winkel aus dem EEprom nehmen wenn Display_type nicht Debug oder Autodetect:
Code:
#if (DISPLAY_TYPE != DISPLAY_TYPE_DEBUG || !AUTODETECT)
       EE_ReadVariable(EEPROM_POS_SPEC_ANGLE, &MP.spec_angle);

Hintergrund war, dass ich mal mit dem motorspez. Winkel spielen wollte.
Ich plage mich immer noch mit sporadischen "Zündaussetzern" rum, die man aber deutlich hört und auch spürt. Es ist nicht das mechanische Problem, das ich mal hatte. Mit einem orignial Lishui FOC controller hat der Motor keine "Fehlzündungen".


Ansonsten kann ich @reinosmart zustimmen
Lishui wurde mir am Ende etwas zu kompliziert.
Seit Weihnachten sind viele neue Funktionen hinzugekommen - vermutlich auch mit einigen Bugs versehen. Das will erstmal verarbeitet werden. Im Prinzip trete auch ich seitdem auf der Stelle.

Gruß Tomsen61
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Motor reagiert nicht mehr auf Throttle Ist das normal?
Nein, natürlich nicht. Die Funktion von Throttle hat nichts mit dem gewählten Display zu tun.

Im Display typ Debug wird der Winkel aus dem EEprom genommen und nicht der Eintrag SPEC_ANGLE aus der config.h.
Nein, der Winkel wird nur aus der config.h genommen, wenn noch nichts im EEPROM steht. Sobald einmal die Autodetect Routine mit dem Controller durchgeführt wurde, wird immer der Wert aus dem EEPROM genommen, bzw. wenn Autodetect aktiv ist, beim Einschalten neu ermittelt und neu ins EEPROM geschrieben. Die Abfrage ist ja ein || also ein "oder".
Das emulierte EEPROM kann man nur löschen, indem man einen "full chip erase" mit dem STLink Utility macht.

vermutlich auch mit einigen Bugs versehen
Ich hoffe mal, das es keine Bugs sind, sondern nur Unwissen um den Sinn und die Anwendung der neuen Optionen. Ich habe im Wiki bei github aber alles auf den neuesten Stand gebracht und hoffe meine Ausführungen sind verständlich. Je mehr man einstellen kann, um so mehr kann man auch "verstellen":). Natürlich kann ich nicht alle Eventualitäten auf dem Prüfstand bzw. dem Rollentrainer erschlagen. z.B. die "Fehlzündungen" kann ich überhaupt nicht nachvollziehen, da sie mit keinem meiner Motoren auftreten.
Da muß die Community helfen...

Gruß
hochsitzcola
 
Zuletzt bearbeitet:

tomsen61

Dabei seit
18.09.2014
Beiträge
115
Ort
Raum Würzburg
Das emulierte EEPROM kann man nur löschen, indem man einen "full chip erase" mit dem STLink Utility macht.
Gut. Wieder was dazu gelernt (y)
Ich hoffe mal, das es keine Bugs sind, sondern nur Unwissen um den Sinn und die Anwendung der neuen Optionen.
Ja, bin halt nur ein Hinterherhechelnder und hatte das "!" bei !AUTODETECT übersehen. PEBCAK

Aber nochmal zu den "Fehlzündungen". Habe den Motor nochmal zerlegt, aber keine mechanischen Auffälligkeiten gefunden.
Dann Fahrrad auf Lenker u. Sattel gestellt und Controller mit OS im Vergleich zu Original Lishui controller getestet. OS-C. hatte wieder diese "Fehlzündunen" der originial C. hatte keine.
Die beiden C. hatten jeweils ein Daumengas. Das vom beim OS-C. funktionierte manchmal nicht (Wackelkontakt?). Das wäre eine Erklärung. Oszi zeigt Spannungspitzen von 0,4V, von denen einige zeitlich zu den "Fehlzündungen" passen könnten.
1617915495881.pngOS 1617916139827.pngoriginal Lishui
Das Daumengas am original Lishui controller zeigt diese leider aber auch.
Könnte es sein, dass diese Spitzen vom Lishui Controller weggefiltert werden, in der OS aber als Sollwert durchschlagen?
Wie könnte ich das throttle signal in der OS glätten?

Gruß Tomsen61
 
Zuletzt bearbeitet:

tomsen61

Dabei seit
18.09.2014
Beiträge
115
Ort
Raum Würzburg
Also, Poti statt Daumengas hat keine Spitzen von 0,4V im Signal gehabt, die "Fehlzündungen" sind aber unverändert da.

Ich gehe jetzt vorerst auf den Softwarestand von Anfang Dezember 20 zurück, da ich ein Rad umgebaut habe, das jetzt laufen soll. Damit habe ich ein zufriedenstellendes Motorgeräusch ohne "FZ".

Ich weiß nicht was ich noch machen könnte. Motorspez. Winkel habe ich variiert. Die statischen Hall-Winkel (120°) nach Messung angepasst. Beide Reglervarianten mit verschiedenen P- u. I-Parametern.

Als nächstes möchte ich meinen ersten DD (GoSwiss drive) mit Drehmomentwelle von Phoebe und der OS-Firmware zum Laufen bringen.

Gruß Tomsen61
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
den Softwarestand von Anfang Dezember 20
Kannst du denn Nachvollziehen, mit welchem Commit die "Fehlzündungen" anfangen? Das würde die Ursachenfindung deutlich einfacher machen.
Ich mache im Moment nichts mehr an der Firmware, da sie von den Features her einen guten Stand erreicht hat, jetzt gilt es "nur" noch Bugs auszubügeln.
Das wird sich ggf. schwierig gestalten, was bei dem einen die Lösung bringt, erzeugt beim nächsten ggf. wieder neue Probleme. Den Eindruck hatte ich jetzt schon öfter bei verschiedenen vermeintlichen Bugfixes.

Gruß
hochsitzcola
 

endlessolli

Dabei seit
01.08.2020
Beiträge
11
Ich benutzte ja den torque-x4 Branch mit der Integerarithmetik, der Master lief am Schluss ja nicht mehr sonderlich stabil.

war ich ja auch, bis auf die Fehlzündungen. Wie gesagt, ich kann alles jederzeit umstecken. 3 Räder mit jeweils verschiedenen Controllern und Software hat mich zuletzt etwas irre gemacht.
Hallo; ich möchte nicht diesen thread kapern - nur kurz eine Frage an @reinosmart und @Hochsitzcola
zu dem oben gesagten bez : torque-x4 Branch der KT OSEC:
-> Was ist an dem Branch funktional anders / negativ im Vergleich zur Masterbranch (außer das positive, dass wg. Integernutzung die BT App Kommunikation funktioniert?

-> Mit anderen Worten: Was funktioniert in der torque-x4 Branch nicht (oder anders), als in der Masterbranch?
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
die "Fehlzündungen" sind aber unverändert da
Ich habe jetzt mal mit einem kleinen Hoverboardmotor experimentiert. Hier bekomme ich tatsächlich auch ab und zu unmotivierte hörbare "Ticks", allerdings nur, wenn beim Starten die autodetect Routine lief. Unabhängig vom Winkel, der während der Routine gefunden wurde und auch nicht bei jedem Neustart.

Wenn ich autodetect deaktiviere, bekomme ich das Ticken nie...

Ich habe bestimmt 30 Neustarts mit verschiedenen Einstellungen gemacht, immer wenn autodetct aktiv war, kam das Ticken bei ca. 2 von 5 Starts, bei deaktiviertem autodetect kam es nie.

Ich habe jetzt mal auch beim autodetect den motorspezifischen Winkel gerundet, wie das beim Schreiben ins EEPROM gemacht wird. (32 bit auf 16 bit gekürzt)
Bei 5 Starts mit autodetect hat es jetzt auch kein einziges mal mehr getickt. Noch keine große Statistik, aber einen Zusammenhang scheint es zu geben.

Kann das von euch mal jemand nachprüfen?

Gruß
hochsitzcola
 

reinosmart

Dabei seit
29.04.2017
Beiträge
547
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
Kann das von euch mal jemand nachprüfen?
Habe gerade einen noch jungfräulichen Lishui geflasht. War ein Master von Ende Januar. Es scheint was dran zu sein! Ohne Autodetect war alles ruhig, mit Autodetect wieder Fehlzündungen. Dafür läuft der Motor anders herum als mit meinem ersten Lishui. Aus der Erinnerung könnte ich schwören, dass ich diese FZ immer hatte, aber so sauber hab ich das nun auch nicht dokumentiert. Ich probier das noch mal mit einem aktuellen Master. ....
Leider läuft mein Trio damit wie ein Sack Kartoffeln, da stimmen wohl die advanced settings überhaupt nicht. 🥴
 
Zuletzt bearbeitet:

tomsen61

Dabei seit
18.09.2014
Beiträge
115
Ort
Raum Würzburg
Kann euch mit einer "Messung" bestätigen. :)
Beim Messen habe ich subjektiv keinen großen Unterschied bemerkt. Die Auswertung der Körperschallmessung mit Smartphone zeigt mit eingeschaltetem Autodetect höhere Amplituden u. mehr "Fehlzündungen".
Die Messungen waren nicht im Debug-Modus sondern mit KT-Display. Wenn ich Autodedect im Debug-Modus einschalte, dann dedected er fortlaufend. Mann kann also so nicht fahren?

Da die Ausführung u. die Stärke des Aufsetzen des Handys auf den Rahmen vermutlich Einfluss auf das Messergebnis hat, würde ich für das Ergebnis meine Hand nicht ins Feuer legen.

edit: habe gerade nochmal gemessen. Wie befürchtet Ergebnis genau andersrum. Man sieht allerdings auch hier die Spitzen der "FZ".

Gruß tomsen61

1618419677237.png1618423113992.png
 
Zuletzt bearbeitet:

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Wenn ich Autodedect im Debug-Modus einschalte, dann dedected er fortlaufend.
Da passt was nicht, auch im Debug-Mode läuft autodetect nur einmal beim Einschalten, danach kannst du ganz normal fahren.

Es gab nur für wenige Stunden (wenn überhaupt) einen Commit, nach dem Mergen des Pull Requests von @arozhkov2001, bei dem nach dem autodetect ein reboot durchgeführt wurde. Mit dem aktuellen Master sollte das nicht passieren.

Warum läuft der Motor nur falsch herum?
Reverse aktiviert?! :)

War ein Master von Ende Januar.
kannst du mal den Link auf den konkreten Commit posten? Ende Januar war die PI-Regelung noch in der Hauptschleife, nicht im Interrupt, ggf. wird uns doch die Zeit im Interrupt knapp. Die wieder in die Hauptschleife zu hängen wäre in 2 Minuten gemacht...

Wir könnten auch mal mit den Interruptprioritäten rumprobieren, im Moment haben die alle die gleiche Priorität. Ist nur die Frage, welcher die höchste benötigt. Für die richtige Lageerkennung wohl die Hall-Interrupts. Die UART-Interrupts dafür ganz niedrig....
Beim Injected ADC callback bin ich mir nicht so sicher, eigentlich ist das nicht so wichtig, da die Messwerte ja im Register stehen, ob die einen Moment früher oder später ausgelesen werden, sollte nicht so tragisch sein....

Gruß
hochsitzcola
 
Zuletzt bearbeitet:

reinosmart

Dabei seit
29.04.2017
Beiträge
547
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
kannst du mal den Link auf den konkreten Commit posten?
ich blick's nicht wie man an den Link kommt, der download war vom 31.01.
Hab gerade nochmal auf den 31.01. Master geflasht, mit Drehrichtung reverse. Jetzt läuft der Motor wieder richtig rum, aber wieder massive FZ. Dann Drehrichtung wieder auf normal, dann sind FZ fast weg??
Der alte Master läuft auch unten rum viel ruhiger, beim aktuellen klingt der Motor bei niedrigen Drehzahlen wie eine Turbine.
 
Zuletzt bearbeitet:
Thema:

Open Source Firmware für Lishui Controller

Open Source Firmware für Lishui Controller - Ähnliche Themen

Offene Firmware für viele "Discounter-Räder" (Fischer, Prophete, NCM, ....) mit Lishui FOC Controller: Die Firmware hatte ich schon in verschiedenen Threads angesprochen. Ich habe ihr jetzt noch eine nutzerfreundliche grafische Benutzeroberfläche...
Oben