BMT - BionX-Motor mit No-Name-Akku und Kunteng-Display betreiben

[Con_Air]

@Hochsitzcola

Vielen Dank für den Werbeblock.

Meine Anzeige ist hier im Forum geschaltet.

 

[fitzelfritz]

Also ich habe bei mir jetzt nochmal alles doppelt überprüft und den Fehler gefunden. @temp hat seine Glaskugel wohl sehr ordentlich poliert, es war tatsächlich so, dass CAN high und low vertauscht waren.
Wie konnte sowas triviales passieren und so lange unentdeckt bleiben? Ich hatte mir ein paar wasserdichte Stecker/Buchsenpaare bestellt. Und bei einer dieser Buchsen ist das grüne Kabel mit dem blauen des Steckers, und das blaue Kabel mit dem grünen des Steckers verbunden. Bei allen anderen passen die Farben zueinander...ziemlich ärgerlich das Ganze, aber zum Glück ist nichts kaputt gegangen.
Jetzt läuft es

Und nachdem ich schon eine erste Probefahrt machen konnte, habe ich mir auch Gedanken zur Auswertung des Gauge Signals gemacht und wollte diese mit euch teilen.
Ich mache es bei mir so, dass ich in dem Signal nach Peaks suche (also den Maximalausschlag während einer Kurbelhalbdrehung).
Nur aus den Peakwerten bilde ich dann einen gleitenden Durchschnitt. Zwischen den Peaks wird mit dem aktuellen Durchschnitt weiter unterstützt. Kommt eine weile nichts mehr (=kein treten mehr) wird die Unterstützung zurückgenommen.

Das hat den Vorteil, dass man einerseits die Peaks recht stark glätten kann (-> die Unterstützung bleibt recht konstant, bei auch leichter Fluktuation von Tritt zu Tritt), gleichzeitig aber auch schnell auf neu einsetzendes und beendetes Treten reagieren kann.
Auf den Screenshots sieht man in rot den gauge value (0x21) und in blau die berechnete Unterstützung (die natürlich noch je nach Level skaliert werden kann).
Den Code kopiere ich unten rein, bei Bedarf kann ich auch gerne den Code zum erzeugen des Plots und das Log noch hochladen.

Bei einem ersten Test fühlt sich das schon ganz gut an, eine richtige Probefahrt steht aber noch aus.

Eine andere Sache ist mir noch aufgefallen:
Bei höheren Geschwindigkeiten (>25kmh) geht die vom Motor gelieferte Leistung (REG_MOTOR_STATUS_POWER_METER 0x14) deutlich zurück, obwohl ich per level (0x09) (fast) Maximalleistung fordere. Bei 30 km/h gibts nur noch rund 65%.
Der Akku sollte mit 48V eigentlich noch Reserven haben, das Speedlimit im Motor (REG_MOTOR_ASSIST_MAXSPEED 0x8B) habe ich eigentlich auf 50 hochgesetzt.
Weiß jemand, woran das liegen kann? Bzw. gibt es noch andere Limits/Register, die ich evtl. ändern muss?

Hier noch der Code zu meiner Gauge Auswertung:
(eine Anmerkung noch: bei mir wird jedes erhaltene CAN-Paket zur späteren Verarbeitung mit einem timestamp versehen, wenn man von einer einigermaßen regelmäßigen Abtastung ausgeht kann man das denke ich auch weglassen..)

const float gauge_val_threshold = 2; //  to filter jitter around 0 should it exist
const float peak_decay_timescale = 1300; //[ms] for comping the influence of the next peak on avgpeak. The higher the value, the smoother the power curve (but more delay on changes)
const unsigned long max_time_between_peaks = 700; //[ms] if peaks are further apart than this, power will start decaying inbetween
const float nachlaufzeit_max = 1800; //linearly decrease, no support left after nachlaufzeit_max
float lastgaugeval = 0.0;
unsigned long lasttimest = 0;
unsigned long timelastpeakstart = 0;
float timebetweenpeakstarts = 0; //delta t between peaks. Float, because we do multiplacation (factor <1) with this
float peaktracking = 0; //keep track of peak values
float avgpeak = 0; //smoothed average of the last few peaks
bool wasrising = false;
float last_gauge_support_level = 0;
unsigned int emptycount = 0;
float calc_gauge_support(){
  float gauge_support_level = 0;
  if(mybionx.gauge_queue.empty() && emptycount < 3){ //if no new value arrived, keep the old for a short while (sometimes packets don't sync perfectly)
    gauge_support_level = last_gauge_support_level;
    emptycount++;
  }
  while(!mybionx.gauge_queue.empty()){ //implemented as queue, to make sure we don't miss any measuremnts for calculation, normally this should just be one elemnt
    emptycount = 0;
    if(mybionx.gauge_queue.front().timestamp > lasttimest){ //skip double data
        unsigned long timest = mybionx.gauge_queue.front().timestamp;
        float gaugeval = mybionx.gauge_queue.front().val;
        float deltat = timest - lasttimest;
        bool newstart = false;
        if((gaugeval > lastgaugeval) && gaugeval > gauge_val_threshold){ //gauge value currently rising -> first half of sine
            peaktracking = gaugeval; //keep track of the peak values
            wasrising = true; //when we stopped rising, we reached a peak. Luckily there is very little noise, so no need for fancy filtering (so far)       
            if(timest-timelastpeakstart > 3000){ //after 3 seconds we can assume we restart pedaling -> immidiately support
                avgpeak = gaugeval;
                newstart = true;
            }
        }else{
            if(wasrising){ //gauge was still rising the measurement befor -> this is the first measurement after a peak
                timebetweenpeakstarts = lasttimest - timelastpeakstart;  //use the last, because the last was the peak
                float timefact = min((float)1.0, timebetweenpeakstarts/peak_decay_timescale); //should always be between 0 and 1, after 1.3 sec the last peak is irrelevant
                avgpeak = avgpeak*(1-timefact)  + peaktracking*timefact;
                timelastpeakstart = lasttimest;
            }
            wasrising = false;
        }
        if(timest-timelastpeakstart < max_time_between_peaks || newstart || wasrising){ //wasrising: bei sehr langsamer kd auch wenn der nächste sinusberg nur im onset ist noch weiter untertützen
            gauge_support_level= avgpeak;
        }else{
            gauge_support_level = max((float)0, last_gauge_support_level-(deltat)*100/nachlaufzeit_max ); //linearly decrease, no support after nachlaufzeit_max
        }
        last_gauge_support_level = gauge_support_level;
        lasttimest = timest;
        lastgaugeval = gaugeval;
    }
    mybionx.gauge_queue.pop(); //delete processed value from queue
  }
  return gauge_support_level;
}

 

[reinosmart]

Und nachdem ich schon eine erste Probefahrt machen konnte

schön zu hören, dass noch jemand mit einem BMT unterwegs ist, dann sind wir ja schon zu dritt.
Mich würde noch einiges interessieren. Wie hast du deinen BMT aufgebaut, wie hoch war gauge_gain eingestellt und wie sind deine weiteren Erfahrungen z.B. bezüglich Anfahren und Gangwechsel?

gruß reinosmart

 

[temp]

es war tatsächlich so, dass CAN high und low vertauscht waren.

Freut mich zu hören, dass es jetzt bei dir funktioniert. Und es freut mich auch, dass ich nicht der einzige bin, der Zweifel daran hat, dass ein einfaches Filter erster Ordnung die Lösung sein kann. Diskussionen darüber wurden bisher allerdings abgebügelt mit "wir können das besser". Den Ansatz den du da gewählt hast hätte ich auch von vornherein implementiert. Vor allem sind meines Erachtens nach gesonderte (schnellere) Zeitverläufe nach einer Pause beim Anfahren und beim Aussetzen des Tretens wie du beschrieben hast nötig.
Allerdings fahre ich mit rc3 und da macht der Motor das selbst. Eine Weile bin auch mal mit einer G2 Konsole gefahren als ich meine Akkuelektronik getestet habe. Dabei ist mir auch aufgefallen, dass sich der gleiche Motor im rc3 Moduls wesentlich natürlicher fährt als mit der G2 Konsole. Da ich aber auch nicht vor habe den Motor wieder auf die alte Firmware zu flashen kann ich hier nur theoretisch mit diskutieren.

Bei höheren Geschwindigkeiten (>25kmh) geht die vom Motor gelieferte Leistung (REG_MOTOR_STATUS_POWER_METER 0x14) deutlich zurück, obwohl ich per level (0x09) (fast) Maximalleistung fordere. Bei 30 km/h gibts nur noch rund 65%.

Auf die Schnelle fällt mir da nur ein:

<reg id="maxSpeed" when="motor.rev.sw >= 76" type="scalar" persistent="yes" unit="km/h" protect="yes">
<addr>0x8b</addr>
</reg>
<reg id="maxSpeedDerateDelta" when="motor.rev.sw >= 97" type="scalar" factor="9.091" persistent="yes" unit="rpm" protect="yes">
<description>Speed before maxSpeed to start derating.</description>
<addr>0xd3</addr>
</reg>
Damit wird die "Weichheit" des Abregelns gemacht. Allerdings habe ich mit dem Parameter keine praktische Erfahrung.
Eins muss man aber immer noch im Auge behalten. Der Abstand der Betriebsspannung zur EMK des Motors wird mit höheren Drehzahlen immer kleiner und somit auch die theoretisch mögliche Leistung. Ob das in diesem Bereich schon eine Rolle spielt wäre für mich aber wieder Glaskugellesen.

 

[Hochsitzcola]

Ich habe jetzt auch meine Platine fertig gelötet, allerdings auf Basis des ESP32

Hier noch der Code zu meiner Gauge Auswertung:

Erst mal super, daß du es ans Laufen bekommen hast
Mit welcher Toolchain arbeitest du denn? Gibt es dein Projekt auch bei github o.ä.?

Ich habe ja gar kein Rad mit integriertem DMS, darum kann ich bei dem Auswertealgorithmus nicht mitreden. Ich muß aber @reinosmart recht geben, das analoge Signal von einem der üblichen Tretlagersensoren lässt sich deutlich schöner auswerten, als das, was BionX einem als gauge value (0x21) vor die Füße hustet

Gruß
hochsitzcola

 

[fitzelfritz]

Danke für das viele Feedback

Mich würde noch einiges interessieren. Wie hast du deinen BMT aufgebaut, wie hoch war gauge_gain eingestellt und wie sind deine weiteren Erfahrungen z.B. bezüglich Anfahren und Gangwechsel?

Aufgebaut ist er auf Lochraster und auf Basis eines ESP32 (weil ich den da hatte, schon kenne, und er Bluetooth direkt integriert hat).
Display habe ich aktuell noch keins, alle Daten werden per Bluetooth ans Handy übertragen (keine spezielle App, einfach ein Standard-Serial-Bluetooth-Terminal).
Die Stromversorgung für 12V übernimmt nach einem kleinen Kondensator (47uF) und einer Sicherung der Traco DC-DC Wandler, danach noch ein 7805 für 5V für ESP32 Board und CAN Transceiver. (Der ESP32 selbst läuft mit 3.3V, hat aber noch einen Low-Drop Linearregler auf dem Board integriert). Als CAN Transceiver habe ich einen MCP2562, weil der noch einen integrierten 3.3V <-> 5V Levelshifter hat.
Im BMS des Akkus ist ein highside N-Channel Switch inkl. Treiber integriert, den ich mit dem ESP32 schalten kann. Zum Einschalten wird dieser mit einem Taster+Vorwiderstand (ich glaube ca. 10 Ohm) überbrückt, sodass sich die Kondesatoren im Motor aufladen können. Wenn der ESP32 mit Spannung versorgt wird (auch über den Taster) schalter er nach einem kurzen Delay die Mosfets durch und hält sie offen.
Dadurch kann sich nach einem Timeout oder auf Befehl die ganze Schaltung eigenständig komplett stromlos schalten. (Und, was man als Vor- oder Nachteil sehen kann: geht auch von alleine an, wenn die initiale Stromversorgung nicht durch den Taster, sondern durch den drehenden Motor als Generator erzeugt wird).


Soweit zum Aufbau, falls Bedarf ist kann ich auch gerne mehr ins Detail gehen

Gauge_Gain (0xCE) stand auf 0x40, ich habe es jetzt aber auf 0x30 runtergestellt, weil der Ausschlag schon bei moderat festem Treten bis auf 100 ging...

Bezüglich Anfahren und Nachlaufen bin ich erstmal ganz zufrieden, ich schätze jeweils gefühlt so ca. eine halbe Sekunde (mit dem Orginal hab ich nur ein paar Runden gedreht, aber da kann es denke ich mithalten). Bezüglich Gangwechsel und detailirterem Eindruck müsste ich denke ich noch ein paar Kilometer machen um da wirklich was sagen zu können. (Wobei ich auch dazu sagen muss, dass ich bisher nicht die große Ebike Erfahrung habe und auch das Orginal fast gar nicht gefahren bin, d.h. ich bin vielleicht auch nicht der beste Einschätzer...)

Auf die Schnelle fällt mir da nur ein:

<reg id="maxSpeed" when="motor.rev.sw >= 76" type="scalar" persistent="yes" unit="km/h" protect="yes">
<addr>0x8b</addr>
</reg>
<reg id="maxSpeedDerateDelta" when="motor.rev.sw >= 97" type="scalar" factor="9.091" persistent="yes" unit="rpm" protect="yes">
<description>Speed before maxSpeed to start derating.</description>
<addr>0xd3</addr>
</reg>
Damit wird die "Weichheit" des Abregelns gemacht. Allerdings habe ich mit dem Parameter keine praktische Erfahrung.
Eins muss man aber immer noch im Auge behalten. Der Abstand der Betriebsspannung zur EMK des Motors wird mit höheren Drehzahlen immer kleiner und somit auch die theoretisch mögliche Leistung. Ob das in diesem Bereich schon eine Rolle spielt wäre für mich aber wieder Glaskugellesen.

MaxSpeed steht bei mir auf 50 (km/h) und 0xd3 auf umgerechnet ca. 3 km/h, ich denke die sind es daher leider nicht...

Die Überlegung bezüglich EMK hatte ich auch, besonders nachdem mir aufgefallen ist, dass die Akkuspannung unter Last auf ca 44-45V runtergeht.
Im Leerlauf läuft er 47 km/h, dann ist das gemeldete Powerlevel aber auch nur noch 1-2 (von 100).
Allerdings kenne ich das von Brushlessmotoren eher so, dass an der Gegeninduktionsspannung eine 'harte' Grenze erreicht wird, d.h. bis kurz davor volle Leistung (da die Spannung, die durch den reinen Wicklungswiderstand der Spulen abfällt fast nichts ist) und dann recht schnell nichts mehr.
Da bei mir bei ca. 25 km/h die Leistung schon zurückgeht, kommt mir das doch recht früh vor...
(Die genauen Motordaten des SL Motors (Wicklungswiderstand, KV) kenne ich leider nicht.

Mit welcher Toolchain arbeitest du denn? Gibt es dein Projekt auch bei github o.ä.?

Ich nutze die Arduino IDE für den ESP32 (mit Platformio und VS Code).
Github gibt es leider (noch) nicht, dafür ist der Code definitiv noch zu unfertig
Aber falls interesse besteht kann ich den aktuellen Stand hier gerne mal hochladen

 

[frejohg]

Fehler, entschuldigung

 

[frejohg]

Mein Motor ist auf 20 km / h begrenzt. Ich habe versucht, Register zu setzen, um ihn zu entsperren. Ich teste es auf 24V, aber ursprünglich war es von einem Smart E-Bike mit 48V. Gibt es einen Niederspannungs- oder Batteriemodus? Aber ich bekomme keine Fehlercodes. Die Batterie, die ich gekauft habe, ist 36V.
Kann jemand helfen?

 

[munlagoon]

Hallo zusammen,
Super cooles Projekt, dass sie hier haben.
reinosmart: darf ich fragen um du ein extra BMT PCB hast? Ich habe auf endless-sphere gehört, du hast vielleicht ein paar extra.
Grüsse

 

[reinosmart]

Ich habe noch einige PCB auf Lager, bei Bedarf PN

 

[munlagoon]

Hi zusammen,

Danke reinosmart für die PCBs. Fast alle Komponenete sind jetzt aufgelötet und ich versuche der STM32F103 zu programmieren.
Ich habe ein generic STM32F103 und ein nanoDAP um es zu programmieren.
Haben sie einige Tipps oder kenne sie einige Guides die wären hilfreiche? Ich fand es mega schwer gute Dokumentation zu finden. Ich weiss eben nicht um es möglich ist, die STM32F103 mit der nanoDAP zu programmieren.

Danke und Grüsse,
Munlagoon

 

[AxelBor]

Reinosmart und/oder Hochsitzcola und/oder Andere leute
Ich bin neu in diesem BMT-Unterforum und sehr an Ihrer BMT-Lösung interessiert. Ich habe selbst eine Reihe von Trek-Bikes, darunter ein X700 (Speed-Pedelec 50km/h). Ich kenne mich mit Elektrotechnik gut aus, habe aber eine Reihe von Fragen.
Hast du eine Platine davon? Ich kann gut löten usw.
Die Verbindungen zu Display, Motor und Akku sind klar.
Die Frage ist auch, welche Software genau hochgeladen werden soll und wie mit welchen Tools und Schnittstellenkabeln? Muss das erst kompiliert werden oder so? Oder ist es so etwas wie die Arduino-Software?
Hilf mir auf meinem Weg. Oder gibt es dazu eine Anleitung?
Ich würde es gerne testen, da einige Teile nicht ohne weiteres erhältlich sind. Zudem ist der BionX Akku nicht gerade erstklassig bzw. wertlos.

 

[Hochsitzcola]

Hast du eine Platine davon?

Ich weiß nicht, ob @reinosmart noch welche hat.

Die Frage ist auch, welche Software genau hochgeladen werden soll und wie mit welchen Tools und Schnittstellenkabeln?

Ich habe das Wiki gerade noch mal etwas ausführlicher gemacht. Wenn dir die Infos nicht reichen, frage einfach noch mal nach!

Home · stancecoke/BionX_Minimal_Translator Wiki

Die Bluepill-Boards sind inzwischen in Deutschland wahnsinnig teuer geworden, (Chipkrise?!) Direkt aus China noch erschwinglich

Gruß
hochsitzcola

 

[reinosmart]

Ich weiß nicht, ob @reinosmart noch welche hat.

Hab noch welche

 

[AxelBor]

reinosmart, Kann ich dann einen bekommen? Welcher Preis und können Sie es nach Holland schicken?

 

[reinosmart]

reinosmart, Kann ich dann einen bekommen? Welcher Preis und können Sie es nach Holland schicken?

schicke mir bitte eine PN

 

[Shane]

Hey reinosmart, can i buy one of you im from Australia

 

[reinosmart]

Sorry, the PCB is sold out

 

[Truman]

Hallo zusammen, ich bin dann endlich mal dazu gekommen mir die Platine zu bestücken und sehe jetzt keine Infos dazu welche Widerstände wo genau hingehören.
Muss ich das versuchen nach den Werten zu bestimmen, oder gibt es dazu vielleicht noch eine Übersicht? Ich habe zumindest keine in dem Projekt gefunden.

VG

 

[Hochsitzcola]

gibt es dazu vielleicht noch eine Übersicht

Die Werte der Widerstände sind in der BOM zu finden und das Platinenlayout, wo welcher Widerstand sitzt, ist hier.

Gruß
hochsitzcola