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, robust funktionieren tut das sicherlich, ich finde es halt nicht besonders elegant, bei jeder Nachricht die DMA zu stoppen und neu zu starten...

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Der ILDE interrupt wird ja pro Nachricht nur einmal ausgelöst.
Hm, robust funktionieren tut das sicherlich, ich finde es halt nicht besonders elegant, bei jeder Nachricht die DMA zu stoppen und neu zu starten. Die Idee der DMA ist ja, daß sie vollständig im Hintergrund läuft ohne den Prozessor zu belasten. Wir haben eine feste Nachrichtenlänge. Anders sähe das aus, wenn unterschiedlich lange Datenblöcke gesendet würden. Dann ist der Idle interrupt eine schöne Lösung.
Wenn bei der Neusyncronisierung ein paar Nachrichtenblöcke durchrutschen, stört das ja nicht, da der Inhalt der Blöcke sowieso immer der Gleiche ist. Es wird maximal das Umschalten der Stufe oder das Schalten des Lichtes um ein paar Zehntelsekunden verzögert.

Meines unterscheidet sich ja stark von 910U / 618U das schon vorhanden ist
Tut es das? Ich denke nicht. Deines braucht offensichtlich den verschlüsselten Handshake beim Start nicht. Aber die eigentliche Datenstruktur ist doch die gleiche wie beim 910U.
Der Handshake mit der LookUp-Tabelle macht die Startprozedur aufwendig (oder ich habe nicht erkannt, wie man die einfacher machen kann. Das will ich nicht ausschließen :)).

Gruß
hochsitzcola
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
Ich glaube den DMA-Restart könnte man sich sparen wenn man die DMA im circular mode laufen lässt, werde das noch ausprobieren.
Melde mich dann auch noch mal wie der PLL mit variablen P&I Faktoren läuft. Nachdem ich nochmals ein paar mal gefahren bin nun doch
der Überzeugung dass der PLL besser funktioniert als die Extrapolation, auch ohne Anpassung der Faktoren.

Aber die eigentliche Datenstruktur ist doch die gleiche wie beim 910U.
Da hast du recht - ist etwas versteckt im ganzen Handshake Overhead.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
wenn man die DMA im circular mode laufen lässt
Rx läuft ja bereits in circular mode. Man muß die DMA nur neu starten, wenn man auf eine andere Nachrichtenlänge umschalten möchte. Das mache ich, um eine aus dem Tritt geratene Kommunikation wieder zu syncronisieren.
Ich habe das im Master gestern so eingebaut und mit den drei verschiedenen Displays, die ich mit KM5S-Protokoll in der Grabbelkiste habe, getestet und für gut befunden :)

Gruß
hochsitzcola
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
Ja stimmt, läuft bereits im circular Mode. ich konnte den DMA-Neustart jetzt umgehen indem ich die Daten in einen circular buffer schreibe, landet morgen auf github.
Ich komme gerne auf die Lösung im master zurück wenn diese auch funktioniert - im Moment bin ich gerade froh dass es läuft und da ich noch einige andere Baustellen habe.

Ich habe gerade noch einen Drehmomentsensor mit einem 4-Pin Kabel geprüft. Auf dem Oszilloskop sieht das PAS und Torque Signal gut aus.
Jedoch finde ich auf dem controller den passenden Pin nicht. Habe gerade alle Channels (1-15) ausprobiert (MX_ADC1_Init funktion):

C:
sConfig.Channel = ADC_CHANNEL_0 ... 15;

und nirgends einen output erhalten. Sieht fast so aus als ob das Torque-Signal dieses Sensors im Controller harwaremässig gar nicht angschlossen ist?
(Das Pas-Signal war wie immer auf B8)
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Jedoch finde ich auf dem controller den passenden Pin nicht.
Hast du denn mal den Controller aufgeschraubt und geschaut, wo das Kabel mit dem Torque-Signal angelötet ist? Normalerweise ist Lishui da vorbildliche, was den Platinenaufdruck angeht. Mach doch mal ein Foto.

Gruß
hochsitzcola
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
Das eine Kabel landet auf dem TA Connector, und das andere auf AD1.
Das ist ein alter Controller welcher ohne Schutzschicht kam. Derjenige den ich gerade brauche hatte eine dicke Schutzschicht und
ich habe gerade so viel entfernt um das Programmierkabel anzubringen.
 

Anhänge

  • lishui_print.jpg
    lishui_print.jpg
    178,7 KB · Aufrufe: 19

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Derjenige den ich gerade brauche hatte eine dicke Schutzschicht
Hm, ich denke da wirst du die die Mühe machen müssen, den Bereich, in den das Torquesignal-Kabel an die Platine geht freizupulen. Am besten misst du dann auch direkt an der Platine, ob die Signalspannung dort auch ankommt. Vielleicht liegt es ja auch nur am Stecker oder am Kabel...

Gruß
hochsitzcola
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
Ok, denke ich kriege das sicher noch hin. Ich werde vermutlich gleich den Controller wechseln..
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
Noch ein paar weitere Fragen und Bemerkungen

TIM3 Frequenz

In der Funktion MX_TIM3_Init müsste htim3.Init.Period nicht auf 8000 gesetzt werden um auf 8kHz zu kommen?

PAS-Signal

Ich glaube es ist von Vorteil die beiden variablen uint32_PAS und uint32PAS_cumulated entsprechend
zu 'reseten' wenn das Timeout erreicht wird. Ansonsten bleibt uint32_PAS bei einem niedrigeren Wert als
das PAS_TIMEOUT hängen und beim erneuten Pedalen muss zuerst ein unpassender Wert in
uint32_PAS_cumulated weg kumuliert werden.


C:
if(uint32_PAS_counter >= PAS_TIMEOUT)
{
    uint32_PAS = PAS_TIMEOUT;
    uint32_PAS_cumulated = PAS_TIMEOUT << 2;
}

PLL

Ich konnte den PLL mit variablen Koeffizienten noch nicht testen, aber es funktioniert eigentlich auch ohne schon
ziemlich gut. Im Moment fahre ich mit fixen Stromstufen, das hilft vermutlich auch.

Ich habe mit jedoch noch ein paar Gedanken gemacht bezüglich der Implementierung.
In der Python-Simulation kann man sehen dass ein abrupter Wechsel der Koeffizienten ebenfalls zu kleinen Schwingungen führt.
Deshalb würde ich vorschlagen die bit-shifts durch Divisionen zu ersetzen und die Werte von der Anzahl tics zwischen
zwei Hall-Events abhängig zu machen. Ist halt etwas aufwendiger, aber da die Hall-Events relativ selten sind sollte das zu verkraften sein.
Hier eine Implementierung in python..

Python:
def get_p_factor_pll(delta_tic):
    if delta_tic > 200:
        return 2000
    if delta_tic < 40:
        return 500
    else:
        d = delta_tic - 40
        return 500 + d / 160 * 1500 

def get_i_factor_pll(delta_tic):
    if delta_tic > 200:
        return 1000
    if delta_tic < 40:
        return 250
    else:
        d = delta_tic - 40
        return 250 + d / 160 * 750


def speed_pll(phi_ist, phi_soll, p_f_pll, i_f_pll):
    global pll_p_, pll_i_
    delta = int(phi_soll - phi_ist)
    #pll_p_ = (delta >> p_f_pll)
    pll_p_ = (delta / p_f_pll)
    #pll_i_ += (delta >> i_f_pll)
    pll_i_ += (delta / i_f_pll)
    return pll_p_ + pll_i_

Allgemeines

Das Anfahren hört sich immer noch etwas unsauber an, ich glaube es liegt am Überfang vom six-step in den foc mode.
Wenn man auf die Bremse geht, brummt der Motor noch 2-3 Sekunden leicht. Ich habe die Vermutung dass es mit dem I-Anteil im Stromregler zu tun hat? Würde es Sinn machen bei einem shut-down den Strom einfach mit einer Rampe herunter zu fahren? Evtl passiert das schon, bin noch nicht mit dem ganzen Code vertraut.
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Warum komm ich eigentlich immer erst sonntagabends dazu am Fahrrad zu basteln wenn ich versuch mir das ganze WE frei zu halten 😒
Ich hab nochmal die Datenleitung belauscht und dieses mal mitgeschrieben. Im normalen Fahrmodus kommt folgendes in Dauerschleife vom Display:
3a 1a 53 07 02 40 06 00 d4 00 7d 0d 02 0d 0a
Der Controller macht keinen Mucks. Er scheint das ganze aber zumindest irgendwie zu empfangen und drauf zu reagieren. Ich hab als Übergangslösung mal in Zeile 180 in der kingmeter.c den Startwert fürs Licht auf KM_HEADLIGHT_ON gesetzt damit ich immerhin Licht zum fahren hab. Das schaltet aber erst an sobald das Display ein mal an war. Irgendwas scheint also anzukommen.
Im Debug-Modus kommt der ganz normale Datenverkehr aus dem Controller. Der TX-Pin ist also scheinbar funktionsfähig.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
3a 1a 53 07 02 40 06 00 d4 00 7d 0d 02 0d 0a
Da passt der Handshake nicht, im Normalmodus ist das dritte Byte 0x52.
Da brauchst du wahrscheinlich eine andere Look-up Tabelle...

Das Anfahren hört sich immer noch etwas unsauber an
Six-Step hört sich nie schön an.... ggf. könnte man aber auch mit nur 30° voreilendem Winkel anfahren. Das kann ich noch mal ändern.

machen bei einem shut-down den Strom einfach mit einer Rampe herunter zu fahren
Das passiert im Torquesensor-Modus bereits, aber eigentlich schaltet die PWM ab, wenn keine halbe Umdrehung innerhalb einer halben Sekunde erkannt wird....

Im PAS Modus gibt es das nicht, ich stelle auch grad fest, daß im PAS-Modus gar nicht abgeschaltet wird, wenn Throttle override deaktivert ist.... :unsure:

Gruß
hochsitzcola
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Da passt der Handshake nicht
Der kann nicht passen weil vom Controller garkeine Daten kommen. Ich hatte auf beiden Datenleitungen einen USB-TTL-Wandler und im Display-Modus kommt da einfach nichts raus.
Ich hab grade aus Neugier mal den aktuellen Master geflasht und da passiert das gleiche. Meine Vemutung grade ist dass der RX-Pin am Display irgendwas abbekommen hat. Ich hatte da mal einen kleinen Unfall mit 50V und der Datenleitung.

Und noch ein letzter Edit: Ich hab grade mal in meinen alten Posts geschaut was denn damals Byte 9 war und das hat sich nicht geändert.
 
Zuletzt bearbeitet:

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
dass der RX-Pin am Display irgendwas abbekommen hat.
Du kannst mal diese Zeile wieder aktivieren, also die beiden Slashs löschen.

Dann bekommst du auf jeden Fall eine Antwort, wenn ein DMA Rx interrupt auftritt. Es wird einfach die empfangene Nachricht wieder zurückgesendet.
Wenn da nichts kommt, ist dein Rx Pin tatsächlich tot :-(

Gruß
hochsitzcola
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Ich hab noch eine Korrektur zu meinem letzten Post: Mit dem neuesten Master kommen tatsächlich Daten vom Controller. Keine Ahnung warum die alte Version mit einem Mal aufgehört hat Daten ans Display zu senden.So wie es aussieht geht der Controller auch die Lookup-Tabelle durch. Nur das Display raegiert auf nichts. Das unterstützt ehrlich gesagt nochmal meine Vermutung, dass im Display was kaputt ist aber der Controller noch komplett läuft.
 

tomsen61

Dabei seit
18.09.2014
Beiträge
115
Ort
Raum Würzburg
Habe auch wieder mal ein paar Testfahrten mit dem Shengyi X2 Getriebemotor gemacht, um die PLL-Faktoren zu optimieren.
Grundsätzlich läuft der Motor mit der PLL-Regelung ohne Vibrationen (y). Mit der normalen Extrapolation hat er Vibrationen zw. 10-15km/h.
Habe mal ausgiebig 😊 Messchriebe mit PPL angehängt.

Seite 1: Speedshiftfaktor variiert (Speedlimit 45km/h) --> da max. 35km/h erreicht werden, wirkt Shiftfaktor kaum. Motor läuft sehr ruhig, aber irgendwann kommt die PLL nicht mehr nach.

Seite 2: das gleiche aber mit Speedlimit 25km/h --> Speedshift wirkt. Aber rauherer Lauf laut Popometer :).

Seite3/4: P-Faktor varriiert (Speedlimit 25km/h) --> P=6 läuft super über 10km/h. Darunter stottern.
Habe dann P schrittweise auf 9 erhöht. Laufgeräusch wird rauher, mit kleinen Unregelmäßigkeiten.

Bei der Regelgröße Speedadapt denke ich, je geringer die Amplitude, umso stabiler die Regelung. Die Schriebe auf Seite 3 u. 4 zeigen da eine kleine Amplitude. Das deckt sich aber nicht mit dem Empfinden auf dem Rad. Da treten dann unregelmäßige kleine Stöße/Ticken auf. Da scheint was außer Tritt zu kommen.

Inwieweit kann mir der Wert temp6 (Error, Soll-Ist) bei der Optimierung des PLL-Faktoren helfen?

In der Python-Simulation kann man sehen dass ein abrupter Wechsel der Koeffizienten ebenfalls zu kleinen Schwingungen führt.
Deshalb würde ich vorschlagen die bit-shifts durch Divisionen zu ersetzen u
Das könnte man aus den Messchrieben auch so interpretieren (blaue Pfeile).

Gruß Tomsen1
 

Anhänge

  • 20210327_PLL_Kommentare.pdf
    1,5 MB · Aufrufe: 10

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Aber rauherer Lauf laut Popometer
Rauherer Lauf am Speedlimit oder immer? Man sieht ja im Log, das es eigentlich nur am Speedlimit zappelt. Das müsste besser werden, wenn du den speed filter höher setzt.

Inwieweit kann mir der Wert temp6 (Error, Soll-Ist) bei der Optimierung des PLL-Faktoren helfen?
Ich denke gar nicht, man sieht halt, wenn der Fehler zu groß wird, kommt die Kommutierung aus dem Tritt. Aber das merkst du auch so :)

Deshalb würde ich vorschlagen die bit-shifts durch Divisionen zu ersetzen
Die Änderung der Shiftfaktoren über den Parameter speedshift ist natürlich ziemlich mit dem Holzhammer. Aber wir sind halt im Integerbereich unterwegs, da kann ich nur durch ganze Zahlen teilen. Mehr als speedshift 2 würde ich sowieso nicht empfehlen, das wird nur instabil, wie @tomsen61 ja schön gezeigt hat.
Man müsste wenn über eine variable Muliplikation arbeiten und entsprechend stärker shiften...

In der Funktion MX_TIM3_Init müsste htim3.Init.Period nicht auf 8000 gesetzt werden um auf 8kHz zu kommen?
Warum ich da so krumme Werte genommen habe, weiß ich ehrlich gesagt auch nicht mehr, wahrscheinlich um den regular ADC Trigger nicht exakt auf dem injected ADC Trigger liegen zu haben.

Gruß
hochsitzcola
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
Ich hab noch eine Korrektur zu meinem letzten Post: Mit dem neuesten Master kommen tatsächlich Daten vom Controller. Keine Ahnung warum die alte Version mit einem Mal aufgehört hat Daten ans Display zu senden.So wie es aussieht geht der Controller auch die Lookup-Tabelle durch. Nur das Display raegiert auf nichts. Das unterstützt ehrlich gesagt nochmal meine Vermutung, dass im Display was kaputt ist aber der Controller noch komplett läuft.

Ich glaube ich habe dasselbe Problem. Bei mir blieb das Display auch immer wieder im Settings mode hängen. Das KMS Protokoll sendet ja zuerst eine Settings-Message (erkennt man am Byte 2 welches dann auf 0x53 = ascii S gesetzt ist) mit generellen parametern. Wenn man eine korrekte Antwort sendet wechselt das Display in den Running-Mode (dann ist das Byte 2 auf 0x52 = ascii R gesetzt). Byte 9 in der Settings-Message ist eine zufällige Zahl (shake hands byte). Bei der Antwort auf die Settings-Message muss dann die korrekte Antwort im Byte 7 gesetzt werden welchs normalerweise das low byte der wheel cycle time ist. Als ich zum x-ten mal die Antwort des Controllers mit original Lishui-Firmware angeschaut habe ist mir aufgefallen dass jeweils einfach das Byte 7 ändert... Es muss also auch irgend ein Shake-Hands Mechanismus eingebaut sein.

Die Änderung der Shiftfaktoren über den Parameter speedshift ist natürlich ziemlich mit dem Holzhammer. Aber wir sind halt im Integerbereich unterwegs, da kann ich nur durch ganze Zahlen teilen. Mehr als speedshift 2 würde ich sowieso nicht empfehlen

Dein Erfahrungswert mit speedshift = 2 kann ich bestätigen. In der Simulation habe ich gesehen dass ich den I_FACTOR_PLL von 10 (2^10 = 1024) auf 8 (2^8=256)
herabsetzen muss über den Drehzahlbereich. x >> 10 ist ja nichts anderes als eine Division von x durch 1024. Wenn du jetzt den shift factor eins herunternimmst
dividierst du auf einen Schlag nur noch durch 512 und das führt zu Schwingungen. Deshalb war mein Vorschlag einfach mit Integer-Division (mit kontinuierlich variierendem Divisor) zu arbeiten als mit bitshifts.

Warum ich da so krumme Werte genommen habe, weiß ich ehrlich gesagt auch nicht mehr, wahrscheinlich um den regular ADC Trigger nicht exakt auf dem injected ADC Trigger liegen zu haben.
Ok, Macht sicher sinn (y)
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Ich hab mein Display wieder zum funktionieren gebracht. Ich kann mir nur leider nicht ganz erklären warum meine Reparatur funktioniert hat, warum die überhaupt nötig war und wie das bisher funktionieren konnte.
In Zeile 397 in display_kingmeter.c wird mit folgender Codezeile aus der empfangenen Nachricht der Handshake-Code ausgelesen um den nachher aus der Lookup-Table zu holen.
Code:
handshake_position=KM_ctx->RxBuff[9+j];
Aus irgendeinem Grund wurde da die Nachricht an der falschen Stelle ausgewertet. Und zwar immer 3 Byte daneben. Ich hab jetzt aus der 9 eine 12 gemacht und jetzt wird das korrekte Byte ausgelesen.
Mich wundert jetzt nur warum das anfangs mal funktioniert hat und dann mit einem Mal nicht mehr. Soweit ich den Code versteh ist es auch richtiger wenn da die 9 drin steht aber scheinbar funktioniert die for-Schleife direkt drüber die das j ermittelt nicht so wie sie sollte
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Kann es sein, dass sich der Wert in KM_ctx->RxBuff ändert während die letzte Nachricht noch ausgewertet wird? Wenn ich per Debug versuch die Funktion nachzuvollziehen passen die Werte in den Variablen alle nicht so richtig zusammen.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
ändert während die letzte Nachricht noch ausgewertet wird?
ja sicher, so lange first_run_flag = 0 werden ja immer 19 Bytes gelesen, bevor der Interrupt auslöst. Wenn du mit der gleichen Baudrate wieder sendest, wird der Buffer-Inhalt natürlich während des Sendens mit neuen Daten vom Display überschrieben, weil wir dann mitten in der Rx Nachricht sind. Das ließe sich vermeiden, wenn man gleich am Anfang der Interrupt-Routine den Rx-Buffer in einen anderen Buffer kopiert. Das sollte schnell genug gehen und durchsein, bevor das nächste Byte vom Display ankommt.... Wenn du den Inhalt nur wieder zurücksenden willst kannst du einfach sowas machen, allerdings musst du KM_MAX_TXBUFF in der kingmeter.h auf 19 setzten.

Code:
memcpy(TxBuff, KM_ctx->RxBuff,19);
HAL_UART_Transmit_DMA(&huart1, (uint8_t *)&TxBuff, 19);

Die 19 Bytes brauchen wir, da manche Displays beim Einschalten vor der "normalen" Nachrichtenstruktur erst mal 4 Bytes senden und der Controller wiederum mit 4 Bytes antwortet. Darum ja diese aufwändige Behandlung mit dem first_run_flag.

Warum
Code:
handshake_position=KM_ctx->RxBuff[9+j];
um drei Stellen verschoben ist, verstehe ich auch nicht. Wenn es so aber klappt, ist alles gut :)

Gruß
hochsitzcola
 
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