1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

"Custom Rom" für Kunteng S06S/KT36 Controller

Dieses Thema im Forum "Controller/Regler, Fahrerinformation, Elektronik" wurde erstellt von Hochsitzcola, 03.08.17.

  1. gronph

    gronph

    Beiträge:
    66
    Das heist, der "Controller 36/48 Volt, 25A, Leistung, Sinus, Hall" von Groetech würde funktionieren?

    Ist das jetzt eigentlich noch eine Sinus oder eine FOC Ansteuerung? Irgendwie kann ich das nicht so richtig rauslese.
    Laut deinem Vergleich im anderen Threat scheint FOC ja die Nase etwas vor Sinus zu haben von der Effizienz, oder lese ich das falsch raus?
     
    Zuletzt bearbeitet: 06.09.17
  2. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Das habe ich selber noch nicht ausprobiert, laut dem Kollegen bei Endless Sphere geht das.

    "Sinus" nutzen beide. Der Unterschied liegt in der Art, wie der optimale "Zündwinkel" ermittelt wird. Wie gut sich der Kunteng mit der originalen Firmware schlägt, werde ich ermitteln, sobald der neue Controller angekommen ist.

    Gruß
    hochsitzcola
     
    Pete3 gefällt das.
  3. gronph

    gronph

    Beiträge:
    66
    Vielen Dank für die Erklärung, jetzt verstehe ich endlich was FOC ist :D
    Irgendwo hast du geschrieben das dieser Typ Controller zu schwach vom Prozessor her ist für FOC, habt Ihr da eine Lösung gefunden oder nutzt Ihr einen anderen Weg den "Zündwinkel" zu berechen?
     
  4. Joe23

    Joe23

    Beiträge:
    3.669
    Details E-Antrieb:
    XDURO2011,2XBofeili 1st Gen
    Das ist nicht ganz richtig. Die optimale Phasenverschiebung der Statorphasenströme zur Rotorlage wird bei reiner Sinusansteuerung dem freien Spiel der Kräfte überlassen. D.h. wenn zu wenig Drehmoment abgenommen wird, stellt sich die Rotorposition auf einen nicht drehmomentoptimalen Winkel (nahe am Statorfeld) ein. D.h. der Phasenstrom wird weitgehend (felderzeugend) zum Blindstrom. Der einzige optimale Fall wäre max. Auslastung, aber dann stehst Du aber genau am Kipp-Punkt.
    Die Feld Orientierte Regelung dagegen regelt den Phasenstrom im Betrag passend zurück und hält immer die optimale 90° Phasenbeziehung zum Rotorfeld ein.
    Es sind also zwei rechenintensive geschlossene Regelkreise in hoher Sequenz zu Bedienen. Da brauchts mit Sicherheit mehr als einen 8-Bit Mikrokontroller.
    Bei diesem hohen Aufwand wundert es mich, dass man immer noch meint, den Sensorlosen Betrieb anstreben zu müssen.
     
    Pete3 gefällt das.
  5. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Ja, genau das habe ich versucht in einfacheren Worten auszudrücken ;). Mit Park und Clark Transformation und den Inversen dazu kann wohl kaum jemand was anfangen :eek:.

    Ich stelle auch gerade fest, daß ich in #29 einen falschen Link hinterlegt habe, gemeint war dieser. Der Kollege vom Endless Sphere Forum hat auch noch diesen Link zum Einlesen empfohlen.

    Kunteng hat da wohl einen Trick, wie eine vereinfachte Regelung auch auf einem schwächeren Prozessor mit nur einem Phasenstrom als Eingangsgröße funktioniert. Ich bin mal gespannt auf die Effizienzmessung der orignalen Firmware.

    Prozessorleistung kostet (fast) nix, die STM32 mit 72 MHz Takt kosten keinen Euro. Die Hardware mit den Hallsensoren und der Verkabelung ist sicher teurer und noch dazu fehleranfällig.

    Wir versuchen gerade den Ansatz, den Nulldurchgang des Phasenstroms zum 180° Hall-Signal zu syncronisieren, ob das für alle Betriebspunkte klappt wissen wir noch nicht.

    Gruß
    hochsitzcola
     
    Pete3 gefällt das.
  6. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Es gibt Fortschritte bei der Motoransteuerung :)
    Der Motor läuft jetzt mit der Open Source Firmware genauso effizient wie mit der Originalen, soweit ich das unter "Laborbedingungen" messen kann.
    Jetzt kann man eigentlich darangehen, das Ganze "hübsch" zu machen, also die Funktionen (oder Cheats) einzubauen die dem Nutzer einen Mehrwert gegenüber der originalen Firmware bringen...

    Gruß
    hochsitzcola

    upload_2017-9-12_20-46-31.png
     
    Binsengelb, DuckAmuck und Pete3 gefällt das.
  7. DuckAmuck

    DuckAmuck

    Beiträge:
    188
    Was ist denn "Load Level" in dem Diagramm - und warum sind die Kurven bei dem Lishui (augenscheinlich) unabhängig von dem Load Level?

    Kann man das Diagramm dergestalt interpretieren, dass die Kunteng bei höherem "Load Level" effizienter sind? Und bei Load Level 3 eine gleiche Effizienz aufweisen wie der Lishui?
     
    Pete3 gefällt das.
  8. gronph

    gronph

    Beiträge:
    66
  9. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Der Load Level ist der mechanische Widerstand, der dem Motor entgegengesetzt wird. Load Level 3 ist sozusagen ein steilerer Berg als Load Level 2.
    Eingangsgröße ist immer die elektrische Leistung (aus dem Labornetzteil) Pel = U*I, diese wird umgesetzt in mechanische Leistung Pmech = Drehmoment * Drehzahl. Dazwischen liegt der Wirkungsgrad, Pmech= eta * Pel
    Mit höherem Load Level steigt das Drehmoment, also sinkt die Drehzahl bei konstanter elektrischer Eingangsleistung. Beim Lishui bleibt eta konstant, beim Kunteng sinkt eta mit steigendem Load Level.
    (jetzt kommen bestimmt wieder jede Menge Erbsenzähler und sagen, daß das so einfach aber nicht ist.... :whistle:)

    Das kann ich dir auch nicht genau sagen, entweder liegt es daran, daß der Lishui "echtes" FOC kann, oder daß der Controller mit 12 FET einfach einen geringeren Innenwiderstand hat als der 6 FET.

    Die Quelle bezieht sich auf die STM32 Prozessoren, bei denen geht natürlich "echtes" FOC...

    Gruß
    hochsitzcola
     
    Pete3 und DuckAmuck gefällt das.
  10. DuckAmuck

    DuckAmuck

    Beiträge:
    188
    Leider:

    Übersetzung Chenglish -> Deutsch: "Es kompiliert, hurra!"

    Nun halten wir ganz gespannt den Atem an und ... warten :)

    Die Lookup-Table für die trig-Operationen ist "ganz normale" Performance-Optimierung, sowas kann man im Prinzip überall machen. Mir stellen sich nur die folgenden Fragen:
    • wo genau ist der Flaschenhals auf der 8bit-CPU in den Kunteng-Controllern? Ich hab nicht einmal ansatzweise einen Plan davon, wie diese 8bit-CPUs aufgestellt sind bei MIPS, FLOPS, allfälligen Latenzen auf Bus oder memory, ob die überhaupt sowas wie caches haben (out-of-order execution oder ähnliches werden die ja wohl kaum haben). Scheinbar ist Division ein Problem ("// this division takes ~4.2us"), was auch wieder recht normal ist.
    • Platz kann nicht so das Problem sein, denn die originale Firmware implementiert ja auch noch ein Kommunikationsprotokoll mit Displays.
    • kann man die Firmware in einen stabilen Zustand überführen, dass die Eintrittsbarrieren möglichst minimal werden? Derzeit sehe ich z.B. auf https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware sage und schreibe fünfzehn (15!) Branches, von denen aber vielleicht 2-3 aktiv zu sein scheinen. Ein merge auf Master würde da wohl ein paar Bäume fällen und den Wald lichten.
    • kann man Akku/Motor/Controller beschädigen oder zerstören - und welche präventiven Massnahmen kann man ergreifen, dass das nicht passiert?
    Ich würde das ja wirklich sehr gerne ausprobieren (sobald dann mal der Flasher aus China eingetrudelt ist), aber da es keinen Weg zurück gibt, lümmele ich immer noch auf der Couch, stopfe Bier und Popcorn in mich rein, und werfe ab und zu mal ein Posting-Krümel von der Galerie ins Forum :cautious:.

    Meine Infrastruktur würde dann aber auch nur bestehen aus ... Akku, Controller, (Display!, ) Motor - eingebaut im/am Rad. Vielleicht noch ein Lötkolben. Ich habe keine fancy Netzteile oder Oszilloskope, und mein Multimeter, ja, keine Ahnung wo das gerade ist. :barefoot:
     
    Pete3 gefällt das.
  11. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Im Moment würde ich das nur mit einer flinken Sicherung (max. 10A) an einem Akku betreiben, wenn du kein Labornetzteil hast.

    Da hast du wohl recht, ich werde @casahino mal vorschlagen, den Master auf einen aktuellen Stand der Entwicklung zu bringen....

    Gruß
    hochsitzcola
     
    DuckAmuck und Pete3 gefällt das.
  12. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Ich habe jetzt "meinen" Zweig feature_torque_sensor soweit aktualisiert. Die automatische advance angle Anpassung (FOC für Arme?! :)) funktioniert. Als Basis für Experimente sollte das gehen. Für einen anderen Motor muß ggf. für den "runden" Anlauf der Wert
    Code:
    #define MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT 213
    in der main.h angepasst werden, den Parameter sollte ich ggf. mal in das Java-Tool packen, so lange wir noch keine universell funktionierende Lösung gefunden haben.
    Mit (elektrisch) sehr schnell drehenden Motoren wie dem Q85 läuft diese Version laut @casainho bei hohen Drehzahlen noch nicht so gut. Ich kann das nicht beurteilen, da ich keinen Q85 habe...

    Gruß
    hochsitzcola
     
    DuckAmuck und Pete3 gefällt das.
  13. DuckAmuck

    DuckAmuck

    Beiträge:
    188
    Ich bekomme bald zunächst einmal auch wohl(?) etwas langsamer Laufendes (? vielleicht? 1:5?) ins Haus, das wohl(?) von einem Kunteng-Controller angetrieben wird (so 'nen ebay-Billig-Ding). Man bemerke die vielen Fragezeichen.

    Mittelfristig möchte ich mir aber auch noch Unterstützung anlachen im Form eines Q100 (front), Q100H (front), Q100C, Q128C - was genau muss ich mit Hilfe der ersten Lieferung noch herausfinden. Und die laufen intern schnell, so grob mit 1:12, oder?

    Insofern wäre das Exponieren sämtlicher "tunables" nach aussen schon recht hilfreich?
     
    Pete3 gefällt das.
  14. DuckAmuck

    DuckAmuck

    Beiträge:
    188
    Blöd gefragt - im Prinzip sollte es doch möglich sein, auch das Kommunikationsprotokoll mit den Kunteng Displays zu implementieren, oder? Mindestens ansatzweise dokumentiert ist das Protokoll ja (https://opensourceebikefirmware.bit...ry_S06x--LCD_control_panel--LCD_protocol.html). Ich habe übrigens einen Beifang gemacht, welches offiziell und "Confidential" das Protokoll der lustigen Wuxing Displays beschreibt ("Communications Protocol II for Lithium Consoles- (20170601)" "Console(display) to Controller" - "Controller to Console(display)"). Das sieht zumindest konzeptionell sehr sehr ähnlich aus, aber ist auf den ersten Blick eben nicht identisch.

    Man könnte dann die Parameter, die das Display setzen kann, überladen mit (teils) anderer Bedeutung. Gleichfalls könnte dann auch der Controller mit der Open Source-Firmware einem angeschlossenen Display die aktuelle Geschwindigkeit schicken?
     
    Pete3 gefällt das.
  15. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Klar, ist ja eigentlich schon fertig, siehe Beitrag #14. Es muß nur jemand portieren. Ich lege keinen gesteigerten Wert auf die Einbindung von Monsterdisplays, mir ist ein aufgeräumter Lenker wichtiger :D.

    Gruß
    hochsitzcola
     
    Pete3 und DuckAmuck gefällt das.
  16. DuckAmuck

    DuckAmuck

    Beiträge:
    188
    So ganz grob sieht das für mich so aus, als ob diese komplette Controller-Firmware mit einigen Displays umgehen kann - inklusive einem eigenen Treiber für ein "dummes" LCD.

    Wenn ich das richtig sehe, dann wäre ein Kunteng LCD3 zu finden unter "slcd3_update" (https://github.com/jenkie/Arduino-P...r/Arduino_Pedelec_Controller/display.cpp#L803) - hier holt sich displaySerial->read(); byte für byte was auch immer das Display schickt und displaySerial->write() gibt quasi eine Antwort mit dem eigenen Status wenn denn einmal ein kompletter Display-Buffer empfangen wurde.

    Ich surfe hier gerade auch nur wild auf github herum - was ich schreibe kann meilenweit neben der Realität liegen.

    Ich sehe das genau so.

    Kunteng hat aber auch kleine(re) Displays - und für die Konfiguration ist so ein Display ja auch ganz praktisch. Es muss ja nicht unbedingt am Lenker stecken, sondern kann, z.B. auch in einer Tasche verschwinden.
     
    Zuletzt von einem Moderator bearbeitet: 14.09.17 um 17:01 Uhr
    Hochsitzcola und Pete3 gefällt das.
  17. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    kannst du diesen "Kipp-Punkt" mal beschreiben? Was passiert da? Wir kommen mit unserer aktuellen Regelung des Phasenstroms auf 0 bei 180° Rotorposition bei Lauf ohne Last bei hohen Drehzahlen in instabile Zustände, kann das an diesem "Kipp-Punkt" liegen?!

    Das siehst du richtig :cool:

    casainho hat nun den torquesensor-branch zum Master gemacht.

    Gruß
    hochsitzcola
     
    Zuletzt bearbeitet: 14.09.17 um 16:49 Uhr
    DuckAmuck und Pete3 gefällt das.
  18. labella-baron

    labella-baron

    Beiträge:
    9.803
    Details E-Antrieb:
    Crystalyte 209, LiFePo 36V 4,6Ah von A123
    Nach Kippmoment beim Drehstrommotor googelen unter Einbeziehung variabler Drehzahl.
     
  19. DuckAmuck

    DuckAmuck

    Beiträge:
    188
    Der Postbote hat gerade ein herziges pinkes USB-Dings geliefert, das inklusive Versand grandiose USD 1.74 gekostet hat (via https://www.aliexpress.com/af/stlink-v2-stm32.html). Ich kann jetzt vier Strippen irgendwo hin ziehen und hoffen, dass der (originale) ST-Link-Treiber nicht nur behauptet, dass er auch pink mag.

    Jetzt fehlt nur noch sowas wie ein Controller (den ich bereit bin dem Stromgott zu opfern), und 'nen Akku. Auch ein Motor wäre wohl nicht schlecht. Eile mit Weile. Immerhin war das pinke Ding dann doch innert 22 Kalendertagen da.
     
    Pete3 und Hochsitzcola gefällt das.
  20. Hochsitzcola

    Hochsitzcola

    Beiträge:
    1.071
    Details E-Antrieb:
    NC FH154 mit EB306 und EB-Precontroller
    Nachdem es aufgrund meines Unvermögens, Git gescheit zu bedienen, ein Versions-Kuddelmuddel im alten Branch gab, habe ich den gelöscht und nun den neuen Branch TORQUESENSOR-EXPERIMENTING angelegt. Hier ist jetzt jeweils meine aktuellste Version zu finden. Hier der direkte Downloadlink.

    Gruß
    hochsitzcola
     
    Pete3 gefällt das.