Open Source Firmware für Lishui Controller

[Hochsitzcola]

Wenn ich die main.h NTCE mode Aktiviere lässt sich der Controller nicht mehr einschalten.

Da wird die Sicherheitseinrichtung beim booten zuschlagen, weil der Throttle offset nicht passt.
Setz Throttle Offset mal auf 1900, dann sollte es laufen. Am besten, du schaust dir den Wert von adcData[1] einfach im Debugmode an, dann mußt du nicht im Nebel stochern... Das ist der erste Wert in der Zeile.

Auch beim Sempu musst du Throttle Offset und Throttle max richtig einstellen, damit er läuft....

Gruß
hochsitzcola

 

[eccotec]

Hallo.

Für den sempu müsste ich NTCE auskommentiert lasssen.
sehe ich das richtig?

Welche Daten werden im Debugg modus noch ausgegeben?

Erste Ziffer ist der ADC des Torq Signals.

werde morgen weiter nachen.

Besten Dank

 

[Hochsitzcola]

Welche Daten werden im Debugg modus noch ausgegeben?

Das kann sich mit jedem Commit von mir ändern, da ich mir immer die Werte ausgeben lasse, die für die Lösung des aktuellen Problems relevant sind.

sprintf_(buffer, "%d, %d, %d, %d, %d, %d, %d, %d, %d\r\n", adcData[1],MS.Temperature, ui32_KV, MS.i_q_setpoint, uint32_PAS, int32_temp_current_target , MS.u_d,MS.u_q, SystemState);

Im Moment:
ADC Wert vom Gasgriff
Temperatur
Motorkonstante KV
Sollwert für Motorstrom iq
Timertics zwischen zwei PAS Interrupts
temporäres Zwischenergebnis zum Sollstrom iq
aktuelle Spannung ud
aktuelle Spannung uq (beides im rotierenden Bezugssystem)
Systemstatus

Gruß
hochsitzcola

 

[eccotec]

Hallo Hochsitzcola

Ich habe nun den Sensor erfolgreich Inbetriebgenommen.

Das Bike fährt sich ohne Anpassung der Parameter besser als mein 10 jahre alten Xion Antrieb.

Danke für deine Unterstüzung.

 

[Hochsitzcola]

besser als mein 10 jahre alten Xion Antrieb.

Danke für die erfreuliche Rückmeldung! Welchen Wert hast denn jetzt für Throttle Offset genommen?

Gruß
hochsitzcola

 

[eccotec]

Der Wert passt nicht zum ntce Sensor, sowie das Drehmoment Signal.
Ausgemessen und überprüft habe
ich das im debugg Modus.
Dort wurde mir 50 angezeigt als Offset.
Habe nun 65 eingetragen und nicht ncte in der in der Eclipse oberfläche geändert (auskommentiet gelassen).
Das Drehmoment steigt auch bei Belastung, nicht wie üblich beim ntce abfallend.
Auffällig ist das das troq Signal weggeschatet wird wenn nicht getreten, bzw rückwärts getreten wird.
Maximaler Spannungswert iist 4.3v geprüft mit einem Rollentrainer bei ausgeschaltetem Motor und Treten.
Ein Drehmomentsignal wird nur rausgegeben, wenn getreten wird.
Im stand hat der Sensor 0v torq Signal.
Der Offset hat sich nicht verschoben, nachdem ich das Lager Mal mit dem heisluftfön auf 70 Grad erhitzt habe.
Warscheinlich ist kein DMS verbaut.

Den Sensor hab ich im Pack mit diversen teilen bei eBay gekauft.
Warscheinlich ist es kein ntce und auch kein sempu.

Ich werde nie wieder ein Bike aufbauen mit pas.

Werde nach dem Erfolg weiterhin mit eurer Firmware noch tiefer beschäftigen.

Ist die Java Oberfläche auch offen zum erweitern?
Würde gerne aufgrund der Hilfe die ich bekommen habe dieses zurückkgeben.

 

[Hochsitzcola]

Ist die Java Oberfläche auch offen zum erweitern?

Ja klar! Der Java Quellcode liegt mit im Repo.
EBiCS_Firmware/JavaConfigurator at master · EBiCS/EBiCS_Firmware

Die drei settings aus der main.h müssten in die config.h rüber und vom JavaTool geschrieben werden. Da war ich bisher zu faul zu
Am besten das Repo forken und dann einen Pullrequest stellen!
Ich freue mich, wenn jemand hilft

Gruß
hochsitzcola

 

[eccotec]

Hallo Hochsitzcola

Ich werde erst ende des Jahres dazu kommen. Mit einem Freund werde ich das machen, da meine Programmierkenntnisse sehr mager sind.
Auch wären die Parameter einfacher wenn direkt die Spannung in Volt man angeben kann.

Naja, so habe ich einiges gelernt, begreife aber das ich erst am lack gekratzt habe, und das erst gefühlt in der 2. klasse bin.
Aber die Fachoberschulreife schaffe ich auch noch.

Das Video eines Nachbarn beschreibt warum ich das mache.

Allerbesten Dank. Bekomme das grinsen heute nicht von den Backen.

 

[eccotec]

Hallo mal wieder.

Erster Fahbericht Getriebemotor mit Drehmoment :

Insgesamt werde ich den Motorstrom niedriger stellen, da der Motor zu stark zieht im oberen Bereich der Geschwindigkeit.

Obenherum hat man das Drehmomentgehühl beim Treten was spaß macht.

Beim Anfahren ist es träge. Zu träge.Pas timeout habe ich derzeit auf 1000, werde aber runter gehen um ein früheres Ansprechen zu erreichen.

Bis 13 kmh ist es träge beim Beschleunigen, oder Garagenauffahrten.
Giebt es eine Geschwindigkeis abhängige Stromreglung/Rampe?


Nur zum Verständnis:

Die Motorleistung wird durch Mittelung des Drehmomentes über eine Kurbelumdrehung und der Pas Signale ermittelt. Plus Stufe des Displays.

int32_temp_current_target = (TS_COEF*(int16_t)(MS.assist_level)* (uint32_torque_cumulated>>5 )/uint32_PAS)>>8; //>>5 aus Mittelung über eine Kurbelumdrehung, >>8 aus KM5S-Protokoll Assistlevel 0..255

Wenn ich einen Doppelt wirkenden Dremomentsensor habe, macht es sinn die 5 auf die 2 zu stellen um nur aus einer halben Umdrehung zu mitteln?
Werden dazu die Pas signale gezählt?
Wenn ja wo?

Die Stufen des Displays ist ja ein Zahlenwert zwischen 0.. 255 bei King Meter.
Die Zuortnung von den Stufen zu den Zahlenwerten lege ich im Display fest.
Sehe ich das richtig?
Ist das im J LCD Möglich?
Oder sollte ich ein anderes Display auf dauer mir zulegen?

 

[Hochsitzcola]

Gibt es eine Geschwindigkeis abhängige Stromreglung/Rampe? ...
Nur zum Verständnis:
Die Motorleistung ...

Das ist ein "Bug" in der Berechnung des Motorstrom-Sollwertes. Im Gegensatz zu den üblichen Stromstufen-Controllern, die den Batteriestrom und damit bei einigermaßen gleichbleibender Akkuspannung die Eingangsleistung regeln, regeln wir den Motorstrom und damit direkt das Drehmoment und nicht die Motorleistung.

Richtig für eine eigenleistungsproportionale Unterstützung wäre die Berechnung über

Unterstützungsfaktor * Drehmoment an der Kurbel * Kadenz =  Motorstrom * Raddrehzahl

Die Raddrehzahl geht aber nicht in den Sollwert ein, so daß die Verstärkung der Eigenleistung mit der Geschwindigkeit steigt.
Da mir als Flachländer diese Charakteristik gefällt, habe ich das nie geändert.
Du müsstest also hier ein *MS.Speed ergänzen, (MS.Speed ist ja die Dauer zwischen zwei Speedsignalen, der Wert wird also kleiner, je schneller du fährst) und über TS_COEF den Sollwert wieder in eine sinnvolle Größenordnung bringen. Ggf noch weiter shiften (>>8) wenn der Sollwert über TS_COEF nicht klein genug wird...

Es gibt aber auch die Option Individual Modes, mit der kannst du wie beim Bosch Nyon die Unterstützung beliebig Geschwindigkeitsabhängig machen. Ist allerdings im Moment nur hardgecodet, ändern kannst du das Verhalten also nur direkt im Code.

Ist das im J LCD Möglich?

beim J-LCD wird ja nur die Stufe als Zahlenwert übertragen. Für das Bafang-Protokoll habe ich schon eine Individualisierung der Stufen eingebaut, aber nicht für das J-LCD, das hat wie schon geschrieben ewig lang niemand mehr nachgefragt. Statt direkt mit dem Assist-Level zu rechnen, kannst du auch mit assistfactor[MS.assist_level] rechnen, dann kannst du hier die Werte zu jeder Stufe einstellen.

Gruß
hochsitzcola

 

[MatthiasRad]

So, ich hab jetzt auch den elektronischen Freilauf für den "GMAC", hab als Phasenstrom mal "11" genommen (was etwa 1,1A sein sollten), da läuft er in der Luft auch nicht mehr ganz aus - gefällt mir

Hab zudem versucht, von meinem EN06 Display noch Einstellungen zu finden. Das passt mit dem implementierten Protokoll irgendwie garnicht - ich hab jetzt
in KM.Settings.PAS_SCN_Tolerance P13 gefunden mit: 153 (5) 96 (8) 64 (12)
und in KM.Settings.PAS_N_Ratio P12 mit 69 85 101 117 (0-3)

Hab mir auch extra die empfangenen Daten angeschaut und konnte z.B. P14, was eigentlich der Strom sein soll, nirgens finden. Macht nichts, so kann ich jetzt meinen Rekustrom in 3 Stufen einstellen (0 für Frost wie jetzt, 5A für kalt und 25A für warm) und mein Display konfigurieren (Hab auf dem EN06 in der "Geschwindigkeitsanzeige" Phasenstrom, Batteriestrom oder Temperatur).

Ich merk halt schon, dass ich das alles total verbastele und hoffe, dass jemand "HIER" schreit, wenn er/sie irgendwas davon haben will, dann mach ich nen sauberen Patch für das offizielle Repo.

Mich jucks auch in den Fingern, auf Sensorlos umzustellen, aber ohne den neuen Beobachter, Autodetect-Methoden für Induktivität und Widerstand und ner Temperaturkompensation trau ich mich nicht. Ich fahre meinen Motor halt viel am Berg.
Vorhin mit 40kg Hänger langsam den stellenweise leicht rutschig zugeschneiten 7-10% Berg hoch bin ich dann trotzdem auf 56 Grad gekommen.
Es hat nicht zufällig jemand Lust, mir nen 2. Controller zu sponsoren, wenn ich dafür das Sensorlos-Zeugs verbesser? Ist schon einfacher mit Testaufbau am Schreibtisch als im Keller am Radl Nen temperaturüberwachten Bafang SWXB hab ich herumliegen, mit dem würde ich das dann bauen.

Ich hab mich jetzt auch erst mit dem Phaserunner nochmal mehr beschäftigt und finde das Config-Tool super. Schade, dass der Flash-Speicher so knapp ist, sonst hätt ich auch Lust, dazu kompatibel zu werden... Und ja, natürlich auch Schade, dass in unseren Lishuis kein vernünftiger Prozessor drin ist, ich träum ja auch ein wenig vom VESC :-(

 

[Hochsitzcola]

Und ja, natürlich auch Schade, dass in unseren Lishuis kein vernünftiger Prozessor drin ist

Hm, da ist ein Prozessor drin, der das beherrscht, was ein E-Bike Controller können muß. Es gibt ja sogar eine Firmware für diesen Prozessor, die VESC-Tool-kompatibel ist, mit automatischer Erkennung von Induktivität, Widerstand und und und....
Den sensorless-Betrieb zu verbessern wäre natürlich noch eine schöne Ergänzung in diesem Projekt. Dann noch mit HFI zum Anfahren unter Last.... Ich habe da manchmal mit geliebäugelt, das hat aber das Potential den Familienfrieden zu gefährden, darum lass ich es. Mein Fischer Bike fährt sensorlos mit der Implementierung aus dem Sensorless-Branch, was will ich mehr

Gruß
hochsitzcola

 

[MatthiasRad]

Naja, der Controller hat zu wenig Flash, läuft nicht mit 72 MHz und hat keine FPU
Achso und ich glaube, vom Pinout ist er auch so unflexibel, dass man keine 2. UART herausbekommt? Ich hatte überlegt, für ein Bluetooth Modul parallel zum Display was zu basteln und bin glaube ich an verfügbaren Kabeln gescheitert. Aber vielleicht verwechsel ich das auch gerade...

 

[Hochsitzcola]

dass man keine 2. UART herausbekommt

UART3 liegt auf PB10 und PB11. PB10 hat Lishui standardmäßig auf einen Header liegen, dort kann man single wire UART drüber realisieren, habe ich beim KClamber-Motor so am Laufen. Je nach Controller-Variante mit etwas löten verbunden.
@mechaniker hat mir freundlicherweise inzwischen einen Controller für den REENTION Flaschen-Akku überlassen, der PB11 direkt mit dem weißen Kabel vom Motorstecker belegt hat, so daß man direkt mit einem Motor wie dem KClamber kommunizieren kann, danke noch mal dafür!
Der Controller ist so super stealthy, nur ein Kabel zum Motor, ein Kabel zum Display und ein Lichtausgang. Aber die Akkukapazität bei dieser Bauart ist natürlich eher was für den Stadtflitzer, nicht für 1000 Höhenmeter...

Gruß
hochsitzola

 

[MatthiasRad]

Hmm ich hatte gerade zum ersten mal eine "gefürchtete" Reaktion des Controllers, kann allerdings die Umstände nicht genau rekonstruieren:
Beim leichten Anstieg vor meinem Endanstieg höre ich bei etwa 20km/h auf zu treten (PAS Modus mit Throttle-Override, eventuell hatte ich auch gerade den Throttle noch gedrückt), schalte den Umwerfer und wollte gerade wieder anfangen zu treten, da blockiert mein Hinterrad kurz aber kräftig (Puma mit festem Freilauf). Ich nehme einen Gummi-Geruch wahr, aber es ist sofort wieder alles in Ordnung. Das Hinterrad ist nicht ausgebrochen, es ist alles super.

Der Controller ist an geblieben, BMS also auch. Es kann sein, dass ich kurz die Bremse betätigt hab (-> Reku, die aber deutlich schwächer hätte sein müssen), aber es ist unklar.

Meine Frage dazu:

Unter welchen Umständen kann das Rad theoretisch blockieren? PWM aus kann es ja eigentlich nicht sein, also bleibt nur eine Fehlkommutierung (vom Gefühl war es länger als ein "Motorschritt", aber das ist schwer zu sagen) bzw. eventuell ein Überlauf im Regler? (Natürlich hab ich die PI-Parameter für den Stromregler kürzlich geändert - deutlich langsamer gestellt & dafür auch den Shift um 1 erhöht).
Edit: Eventuell PWM durch irgendwelche Gründe ausgegangen und dann im falschen Zustand wieder an?

"Disclaimer":
Unter den nun etwas mehr als 1000km die ich so fahre ist das das erste mal, dass ich das erlebt hab. Ich bin zudem aktiv am an-der-Firmware basteln und gehe mit hoher Wahrscheinlichkeit davon aus, da irgendwas "eingebaut" zu haben.

 

[Hochsitzcola]

Unter welchen Umständen kann das Rad theoretisch blockieren?

ich denke mal, daß du eine schlagartige Sollwertänderung produziert hast und der Regler überschwingt, bzw. der Regler die Ist-Wert-Abweichung gar nicht mitbekommen hat, da der Ist-Wert ja über einige PWM-Perioden gemittelt wird und eine physikalisch existierende kurze Stromspitze so weggefiltert wird. Das wirst du auch im Debug-Mode wahrscheinlich gar nicht darstellen können, da die Daten ja nur relativ langsam mit 16Hz ausgegeben werden.

Man kann hier über ein Regler-Feintuning sicher gegensteuern, es gibt zum Beispiel einen Parameter, mit dem man die maximale Änderung des Stellwertes pro PWM Periode einstellen kann.
EBiCS_Firmware/FOC.c at 5efbe3fe55bd8932c0f8dbb34439a15118c218b3 · EBiCS/EBiCS_Firmware

Gruß
hochsitzcola

 

[eriksmit]

I'm trying to use EBiCS on the controller and motor of a RadRhino E-Bike. The PCB says LSW12G-150Z-FOC-160801.
I put some photos on 2022-12 Radrhino ebike for reference.

So far, 2 FETs have blown. I think after the autodetect procedure.

Some questions I have:
1) Is it ok to run the FETs without heatsink for a few seconds or would they probably blow immediately? Second time heat sink was connected. And with the original firmware I've run the motor many times without any issues so far.
2) Is the autodetect procedure supposed to give debug output? My second run I had the debug UART connected, but no output. Running without autodetect does give output. EBiCS_Firmware/main.c at master EBiCS/EBiCS_Firmware suggests to me that it should output a line every time the hall state changes.
3) Do I need to be changing anything anything in the Java Configurator to prevent it from blowing up?
4) Is the autodetect() supposed to return after running? I suspect it is, so maybe something is going wrong.

My next plan is to add some debug messages to autodetect() to answer some of my above questions.

 

[eriksmit]

2) Is the autodetect procedure supposed to give debug output? My second run I had the debug UART connected, but no output. Running without autodetect does give output. EBiCS_Firmware/main.c at master EBiCS/EBiCS_Firmware suggests to me that it should output a line every time the hall state changes.

I've just tried again, and there is debug output:

angle: -88, hall state: 6, hall case 26
angle: -29, hall state: 4, hall case 64
angle: 28, hall state: 5, hall case 45
angle: 92, hall state: 1, hall case 51
angle: 152, hall state: 3, hall case 13
angle: -151, hall state: 2, hall case 32
angle: -88, hall state: 6, hall case 26
angle: -29, hall state: 4, hall case 64
angle: 28, hall state: 5, hall case 45
angle: 92, hall state: 1, hall case 51
angle: 151, hall state: 3, hall case 13
angle: -151, hall state: 2, hall case 32
angle: -88, hall state: 6, hall case 26
angle: -29, hall state: 4, hall case 64
angle: 29, hall state: 5, hall case 45
angle: 92, hall state: 1, hall case 51
angle: 151, hall state: 3, hall case 13

I also added some debug output to check if the autodetect() function completely reaches the end and this is true. But I'm a little confused as to why the firmware doesn't continue after the autodetect() function.
There's no more debug output and also the red LED doesn't blink as usual.
Maybe the autodetect() leaves the CPU in an unusual state.

 

[eriksmit]

Maybe this firmware runs the FETs hotter, because of the control scheme, compared to the original firmware?
And that's why the FETs burn quickly without heatsink?

Since I put the heatsink back and limited the battery current to 2000 I haven't yet had a burned FET.

 

[Hochsitzcola]

First, welcome to the forum!

limited the battery current to 2000

Hm, this seems not to be plausible, as this would be only 2 amps of battery current....

Can you post the content of your config.h?
The MOSFETs should not get hotter, if the deadtime definition is OK and the autodetect went well. You have to be a little patient after the first moves of the motor in autodetect. The motor will spin up to max speed and then will stop again. This is for KV detection. After the motor stopped, the system is in normal mode, so you can start cycling.
If the system hangs up after the first small moves in autodetect, you will have set a wrong value for throttle offset...

What kind of half bridge drivers are installed on your PCB?

regards
hochsitzcola