Open Source Firmware für Lishui Controller

Diskutiere Open Source Firmware für Lishui Controller im Controller/Regler, Fahrerinformation, Elektronik Forum im Bereich Diskussionen; Mich wundert halt vor allem, dass diese Verschiebung einfach so aufgetaucht ist. Ich bin 300km problemlos gefahren und dann ging mit einem Mal...

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Mich wundert halt vor allem, dass diese Verschiebung einfach so aufgetaucht ist. Ich bin 300km problemlos gefahren und dann ging mit einem Mal nichts mehr. Der einzige Unterschied den ich spontan gefunden hab ist, dass sich der Handshake-Code von 01 auf 00 geändert hat. Wenn das Display etwa alle 300km den Code ändert bin ich mal gespannt ob sich bei der 600km Marke die Verschiebung wieder ändert 😬
Noch was anderes was ich an diesem Wochenende versuchen wollte: Wie ist denn die assist_profile Konstante zu verstehen? Ich würde gerne mal die Unterstützungsprofile ausprobieren, werd aber aus den Code noch nicht ganz schlau
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Ich glaub ich weiß warum der Handshake anfangs funktioniert hat. Ganz am Anfang war die Nachricht vom Display folgende:
3A 1A 53 07 02 40 01 00 D4 01 72 FE 01 0D 0A
Byte Nummer 9 ist ja das Handshake-Byte. interessanterweise hat Byte 6 den gleichen Wert und der Controller hat nach dem was ich hier sehe immer Byte 6 ausgewertet. Damit kam durch Zufall die richtige Antwort raus und das Display war happy.
Inzwischen sehen die Daten vom Display so aus:
3A1A 53 07 02 40 06 00 D4 00 7D 0D 02 0D 0A
Byte 6 != Byte 9 und nichts geht mehr.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Wie ist denn die assist_profile Konstante zu verstehen?
Das hatte ich hier erklärt:
Open Source Firmware für Lishui Controller

Code:
const uint8_t assist_profile[2][6]= {    {0,10,20,30,45,48},
                                        {64,64,128,200,255,0}};

Das ist eine Tabelle, in der ersten Zeile stehen die Geschwindigkeiten in km/h, in der zweiten die Unterstützungsfaktoren, Zahlenbereich 0 bis 255.
Der aktuelle Code war ja für ein S-Pedelec gedacht, darum geht die Geschwindigkeit bis 48 km/h. Als x-y-Diagramm aufgetragen gibt das dann die bekannten Bildchen vom Bosch Nyon.

Screenshot_2015-09-11-23-43-55.png


Für welches Streckenprofil man welche Charakteristik wählen kann, wird in diesem Artikel vorgeschlagen:
Bosch Nyon - Individuelle Fahrmodi

Ich habe es ehrlich gesagt nie ausprobiert, durch unseren "Bug" in der Firmware, daß die abgegebene mechanische Leistung des Motors linear mit der Geschwindigkeit steigt, lässt sich das S-Pedelec auch ohne die individuellen Modi wunderbar fahren. It's not a bug, it's a feature :)

Gruß
hochsitzcola
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware
Für jemanden der mit einem Nicht-S-Pedelec Berge hochfahren will ist das ein Bug 😜
Ich hatte mir überlegt ob man nicht vielleicht stromsparender unterwegs ist wenn bei hohen Geschwindigkeiten auf der Ebene die Unterstützung langsam schwächer wird. Das werd ich dann auf meiner Pendelstrecke die nächste Woche über beobachten.
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
@Millimeter94
Ich habe inzwischen ein reverse engineering des shake-hands byte bei meinem Display gemacht und herausgefunden
das die Korrekte shake-hands Tabelle bereits im Array KM_901U_HANDSHAKE (file display_kingmeter.c) steht.

Das shake-hand byte vom Display (Byte 9) sollte eine Zahl zwischen 0 und 63 sein. Die richtige Antwort steht dann im erwähnten Array. In meinem Fall
muss ich das an der Position 7 (erstes Byte = Position 0) zurücksenden ... bis jetzt funktioniert mein Display.
 

-benno-

Dabei seit
03.01.2021
Beiträge
23
Noch eine Frage zum 6-Step Mode.
Soweit ich das verstehe startet man den Motor im 6-Step Mode weil man am Anfang noch
keine gute Winkel Approximation hat.
Spricht etwas dagegen den Übergang von der Anzahl elektrischen Zyklen abhängig zu machen?
Man würde z.B. fix nach 10-15 Zyklen (wenn der PLL eingeschwungen ist) auf die kontinuierliche Vektor-Modulation wechseln.
Mein Motor starte immer noch ziemlich rauh (vor allem wenn man langsam anfährt) und dies obwohl ich mit dem six-step-threshold schon ziemlich runter bin.

Ich sollte in der Kommenden Woche endlich dazu kommen die verschiedenen Ideen zu implementieren und testen!
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
obwohl ich mit dem six-step-threshold schon ziemlich runter bin
Das macht mich stutzig :) Runter ist die falsche Richtung, wenn die Umschaltung schon bei langsamerer Geschwindigkeit erfolgen soll, mußt du den Wert für Threshold größer machen... 10000 oder sogar 15000

Spricht etwas dagegen den Übergang von der Anzahl elektrischen Zyklen abhängig zu machen?
Wenn du dir sicher sein kannst, daß die elektrischen Zyklen auch die entsprechende Bewegung des Rotors zur Folge hatten, sollte das auch gehen..

Für jemanden der mit einem Nicht-S-Pedelec Berge hochfahren will ist das ein Bug
Dann müsstest du bei der Berechnung des Motorstrom-Sollwertes noch mal durch die Geschwindigkeit teilen.
Dann passt wieder die Gleichung

Code:
mechanische Motorleistung = Konstante * Motorstrom * Raddrehzahl * 2Pi = Eigenleistung = Drehmoment an der Kurbel * Kadenz * 2Pi

Gruß
hochsitzcola
 

Fluctuator

Dabei seit
05.04.2021
Beiträge
6
Hallo Leute

mein Tesxt wird hier automatisch übersetzt:

Ich habe 3 Tage gebraucht, um 69 Seiten zu lesen, :)
Vielen Dank für Ihre Arbeit, jetzt weiß ich ein wenig mehr, wie dieses OpenSource-Projekt entwickelt wurde.

Ich arbeite an meinem kleinen faltbaren Fahrrad-Projekt, das zu meinem Kajak passt.
2021-02-07 11.42.22.jpg
2021-02-07 11.44.30.jpg


Ich habe 2 Lishui FOC kontrollere wie diese:

2021-04-01 00.41.49.jpg


Ich habe Maid elektrische Schaltpläne.
Und einer von ihnen ich entlötet für die Herstellung von Lern-Experimentier-Board. CPU ist Stm32F103C8

2021-04-01 00.42.24.jpg


Den zweiten FOC möchte ich in Zukunft mit einem BLDC-Kajakmotor verwenden. (Ich habe sehr billig Motor im Flohmarkt gefunden) Aber es hat keine Hall-Sensoren, so später werde ich versuchen, mit Sensorless Zweig zu experimentieren.

Jetzt ist mein Setup wie folgt, und das Problem, dass autodetect nicht funktioniert :(

2021-04-05 13.51.52.jpg



Der Motor schüttelt nur ein wenig rhythmisch, und sendet nicht einmal "Hall state"
Dies ist ein UART-Screenshot:

Screen Shot 2021-04-05 at 13.52.45.png


Die Spannungsversorgung ist 42V 3A. Während AUTODETECT geht der Versuch in PROTECTION "OFF" dann wieder "ON" immer wieder. Ich möchte die Batterie jetzt nicht anschließen. Ein paar Tage gehen, ich irgendwie maid dieser Motor spinnt mit POT-Widerstand ohne AUTODETECT.
Auch dieses kleine 8inch Rad hat ein weißes Kabel, das ich vermute, sollte oder Geschwindigkeitssensor oder Temperatursensor sein. Aber ich messe und es hat 0V. (Der Geschwindigkeitssensor sollte 4,3V haben, richtig?) Kein gleichmäßiger Widerstand (Die Temperatur-NTC-Sensoren sollten etwas wie 10k oder 20k haben, richtig?) Andere Drähte aus diesem Motor sind ziemlich Standard: GELB, BLAU, GRÜN und Hallsensoren die gleiche Farbe. Außerdem ROT und SCHWARZ wie üblich.



Könnten Sie etwas raten?
Vielen Dank!

Übersetzt mit www.DeepL.com/Translator

original in english:
Hello people

It took me 3 days to read all 69 pages, :)
Thank you for your work, now I know a little bit more how this opensource project was developing.

I am working on my little foldable bike project which fits to my kayak.

I have 2 Lishui FOC controlers like this:

I have maid electric schematics.
And one of them I desoldered for making learning experimentation board.

Second controller I want in future use with BLDC kayak motor. (I have found very cheap motor in fleemarket) But It has no Hall Sensors, so later I will try to experiment with Sensorless branch.

Now my setup is like this, and the problem that autodetect is not working :(
Motor just shakes a little bit rhythmically, and not even sending "Hall state"
This is UART screenshot:


Powersupply is 42V 3A. During AUTODETECT trying goes in PROTECTION "OFF" then "ON" again over and over. I dont want to connect battery now. Few days go I somehow maid this motor spinning with POT resistor without AUTODETECT.
Also this small 8inch wheel has one white wire, which I guess should be or speed sensor or temperature sensor. But I measure and it has 0V. (Speed sensor should have 4.3V out right?) No even resistance (The temperature NTC sensors should have something like 10k or 20k right?) Other wires out of this motor is pretty standard: YELLOW, BLUE, GREEN and Hall sensors the same color. Also RED and BLACK as usual.


Could you advise something?
Thanks a lot.
 

Anhänge

  • 2021-04-01 00.41.49.jpg
    2021-04-01 00.41.49.jpg
    166,5 KB · Aufrufe: 5

-benno-

Dabei seit
03.01.2021
Beiträge
23
Das macht mich stutzig :) Runter ist die falsche Richtung, wenn die Umschaltung schon bei langsamerer Geschwindigkeit erfolgen soll, mußt du den Wert für Threshold größer machen... 10000 oder sogar 15000
Habe das richtige gemacht aber das falsche geschrieben, bin jetzt bei 17000 ;)

Wenn du dir sicher sein kannst, daß die elektrischen Zyklen auch die entsprechende Bewegung des Rotors zur Folge hatten, sollte das auch gehen..
Oder nach einer fixen Anzahl Hall-Übergängen?


Ich habe inzwischen ein bluetooth-modul zusammengestellt wie im wiki beschrieben.
Wie plottet ihr die Daten? Mit blueterm auf die SD-Karte und dan am PC?

Mit dem dem visual logger app kann man die Daten in Echtzeit ansehen. Habes jedoch noch nicht am E-Bike getestet.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Ich habe 3 Tage gebraucht, um 69 Seiten zu lesen

Erst mal schön, daß du den Weg von ES hierher gefunden hast :) (y)

Die Spannungsversorgung ist 42V 3A.
Da wird bei deinem kleinen Motörchen der Strom bei ud=200 während der Autodetect-Routine zu hoch sein.
Setze ud=50 und probiere dann noch mal.
In der Scooter-Diskussion war das Problem auch schon mal angesprochen worden. Es wäre schlauer, wir würden einen konstanten Strom id = xx und iq = 0 vorgeben und aktiv regeln lassen. Wir geben derzeit eine Spannung ohne jegliche Stromüberwachung vor. Das kann in die Hose gehen. Bei üblichen Pedelec-Motoren wohl nicht, aber bei kleinen Motoren mit sehr geringer Induktivität.

Mit blueterm auf die SD-Karte und dan am PC?
Ja, so mache ich das. Am PC mit Excel, oder neuerdings auch gern mit Python ;)

import matplotlib.pyplot as plt
import numpy as np
import tkinter as tk
from tkinter import filedialog

root = tk.Tk()
root.withdraw()

file_path = filedialog.askopenfilename()
na=np.genfromtxt(file_path,delimiter=',')
na=na.astype(int)

x=na[:,7:8]
y=na[:,8:9]
z=na[:,3:4]
fig, axs = plt.subplots(3,sharex='all')

fig.suptitle('EBiCS log plotter')

axs[0].plot(x, label="speedx100")
axs[0].legend(loc="upper right")
axs[1].plot(z,color='g', label="error")
axs[1].legend(loc="upper right")
axs[2].plot(y,color='r', label="speedadapt")
axs[2].legend(loc="upper right")

plt.show()

Gruß
hochsitzcola
 

Fluctuator

Dabei seit
05.04.2021
Beiträge
6
Ich habe u_d=50 gemacht
Wenn ich jetzt einschalte, bewegt sich der Motor langsam und schreibt mir dies:
Screen Shot 2021-04-05 at 18.00.41.png

Dann habe ich diesen Winkel in config.h gesetzt, autodetect=0, und neu kompiliert
Jetzt beim Einschalten, und wenn ich THROTTLE ADC von 200 auf 2000 stelle, bewegt sich der Motor 1mm und dann passiert nichts mehr. Überhaupt keine Bewegung :(

Meine Konfiguration ist hier:

/*


* 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 500


#define I_FACTOR_I_Q 20


#define P_FACTOR_I_D 500


#define I_FACTOR_I_D 20


#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 3500


#define TS_COEF Error


#define PAS_TIMEOUT 8000


#define RAMP_END 1600


#define FRAC_HIGH 30


#define FRAC_LOW 15


#define THROTTLE_OFFSET 50


#define THROTTLE_MAX 3500


#define PUSHASSIST_CURRENT 30


#define WHEEL_CIRCUMFERENCE 570


#define GEAR_RATIO 1


#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 500


#define VOLTAGE_MAX 1600


#define SPEC_ANGLE -715827882 // small wheel


#define DISPLAY_TYPE DISPLAY_TYPE_DEBUG //ASCII Printout for debugging


#define SPEED_PLL


#define SPEEDSOURCE EXTERNAL


#define AUTODETECT 0


#define REVERSE 1


#define THROTTLE_OVERRIDE





#endif /* CONFIG_H_ */
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
und schreibt mir dies
Das Wichtige hast du jetzt im Screenshot weggeschnitten, die Zeilen davor wären die, die interessant sind...

@arozhkov2001 hat auch von Startschwierigkeiten mit einem Scootermotor berichtet. Bei ihm hat es geholfen, im SixStep nicht mit 60° zu viel, sondern nur mit 30° zu viel zu starten. Das hab ich grad im Master nachgezogen.

Gruß
hochsitzcola
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
118
Details E-Antrieb
Bafang Nabenmotor + Lishui mit Opensource Firmware

Fluctuator

Dabei seit
05.04.2021
Beiträge
6
Das Wichtige hast du jetzt im Screenshot weggeschnitten, die Zeilen davor wären die, die interessant sind...

@arozhkov2001 hat auch von Startschwierigkeiten mit einem Scootermotor berichtet. Bei ihm hat es geholfen, im SixStep nicht mit 60° zu viel, sondern nur mit 30° zu viel zu starten. Das hab ich grad im Master nachgezogen.

Gruß
hochsitzcola

Hier ist grosser ScreenBild:
Screen Shot 2021-04-05 at 22.36.20.png


Ich hab das in main.c jetzt:

else { //run in 6 step mode
ui8_overflow_flag=1;
//start with 60 degree advance angle to have positive torque in any case
if(ui16_timertics>SIXSTEPTHRESHOLD<<1)q31_rotorposition_absolute = q31_rotorposition_hall+REVERSE*(DEG_plus60);
if(ui16_timertics>SIXSTEPTHRESHOLD<<1)q31_rotorposition_absolute = q31_rotorposition_hall+REVERSE*(DEG_plus60>>1);
// reduce advance angle to zero with speed increasing to switching speed
else {
q31_rotorposition_absolute = q31_rotorposition_hall+REVERSE*((((DEG_plus60>>22)*(ui16_timertics-SIXSTEPTHRESHOLD))/SIXSTEPTHRESHOLD)<<22);
q31_rotorposition_absolute = q31_rotorposition_hall+REVERSE*((((DEG_plus60>>23)*(ui16_timertics-SIXSTEPTHRESHOLD))/SIXSTEPTHRESHOLD)<<22);
}
}

Aber, leider nicht funktioniert :(
Soll ich DEG_plus60 auf "DEG_plus30" ändern?

im Javakonfigurator sehe ich nur "6 step threshold"

Gruß
Fluct
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Hier ist grosser ScreenBild:
Wenn du sagst, der Motor dreht sich langsam beim autodetect, funktionieren deine Halls nicht. Der output während der Routine muß so aussehen:
Open Source Firmware für Lishui Controller

phase current offsets: 2000, 2021, 1985
angle: -177, hallstate: 4, hallcase 4
angle: -161, hallstate: 5, hallcase 45
angle: -95, hallstate: 1, hallcase 51
angle: -34, hallstate: 3, hallcase 13
angle: 20, hallstate: 2, hallcase 32
angle: 85, hallstate: 6, hallcase 26
angle: 147, hallstate: 4, hallcase 64
angle: -160, hallstate: 5, hallcase 45
angle: -95, hallstate: 1, hallcase 51
angle: -33, hallstate: 3, hallcase 13
angle: 21, hallstate: 2, hallcase 32
angle: 83, hallstate: 6, hallcase 26
angle: 148, hallstate: 4, hallcase 64
angle: -159, hallstate: 5, hallcase 45
angle: -96, hallstate: 1, hallcase 51
angle: -33, hallstate: 3, hallcase 13
angle: 19, hallstate: 2, hallcase 32
angle: 84, hallstate: 6, hallcase 26
angle: 149, hallstate: 4, hallcase 64
Motor specific angle: -1908874088, direction 1

Gruß
hochsitzcola
 

Haze

Dabei seit
04.04.2021
Beiträge
18
nachdem die offene Firmware für den Kunteng ja mehr oder weniger fertig entwickelt ist, habe ich mir einen Lishui als nächstes Opfer ausgesucht. Vorteil der Lishui-Controller:
1. viele haben den Programmieranschluß schon herausgeführt, man muß also nichts auf der Platine rumlöten
2. viel leistungsfähigerer Prozessor, der auch "echtes" FOC ermöglicht
3. auch in vielen Fertigbikes, z. B. Fischer, verwendet, so das die Zielgruppe viel größer ist

Derzeit ist nur reiner Gasgriffbetrieb implementiert, keinerlei Displayunterstützung.
Im Video sieht man im Laptopdisplay den Soll- und den Ist- Phasenstrom, den verwendeten Controller und den drehenden Motor. Der Motor (ein BionX IGH3) wird mit der Hand gebremst (meine armen Finger :)), um eine gewisse Stromaufnahme zu ermöglichen.

Die PWM läuft aktuell noch mit 8kHz, darum das häßliche Fiepen. Die üblichen 16 kHz sind auch möglich, wenn der Code etwas aufgeräumt ist. Die Rotorposition kommt über die Hallsensoren, an sensorless habe ich mich noch nicht rangetraut.

Alles andere als fertig, aber der Motor dreht und die feldorientierte Regelung funktioniert :)


stancecoke/LishuiFOC

Gruß
hochsitzcola

Nachtrag: Zwischenzeitlich habe ich in unserem Wiki eine Zusammenfassung des Projekts erstellt:

elektrotechnik:open_source_firmware_fuer_lishui_-controller [Wiki Pedelec-Forum]
Ich hoffe hier bin ich richtig
 

Haze

Dabei seit
04.04.2021
Beiträge
18
Das heißt ich könnte auch Daumengas aktivieren.... und das alles könnte ich am Display was derzeit verbaut ist freischalten oder wie verstehe ich das ..oh Mann ich stell mich bestimmt ziemlich Trottelich an aber bin so gar nicht Technik versiert
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.494
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
1617698133799.png


Jetzt haben wir den Kunteng-Thread in der Anzahl der Antworten überholt, ist das gut oder schlecht?! :)

oh Mann ich stell mich bestimmt ziemlich Trottelich an aber bin so gar nicht Technik versiert
Lies erst mal das Wiki drei mal und entscheide für dich, ob du dir das zutraust....

Gruß
hochsitzcola
 

reinosmart

Dabei seit
29.04.2017
Beiträge
547
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
ist das gut oder schlecht?!
die Kunteng Software ist sicher so gut wie ausentwickelt und läuft völlig stabil. Ich bin bei meinem aktuellen Projekt einstweilen wieder auf Kunteng umgeschwenkt, der Lishui wurde mir am Ende etwas zu kompliziert. Mein Trio DD zieht im Leerlauf am Kunteng sogar rund 50 mA weniger Strom als am Lishui, und die Vorteile der FOC haben sich mir in der Praxis nie so richtig erschlossen. Aber beide Controller habe ich von den Steckern kompatibel aufgebaut, so dass ich jederzeit umstecken kann. Aber vor lauter Bastelei komme ich nicht mal dazu mein BMT Projekt mal ausgiebig Probe zu fahren.
 
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