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

[Hochsitzcola]

Ich bin mir inzwischen nicht mehr ganz sicher was die Abtastrate im Debug-Modus angeht

Der BMT sendet mit 200 Hz CAN-Nachrichten raus. Im Debug-Modus reicht der BMT jede empfangene CAN-Botschaft als UART weiter.

Ein Frage an @temp : Ich habe gerade einen Ananda Controller mit einem Bafang CAN-Display auf der Werkbank. Ich bekomme meinen Sniffer damit nicht ans Laufen, ich denke, das liegt am CAN Bit-Timing. Ich habe mit dem Oszi diese Nachricht belauscht:

Ich lese daraus ein Periodendauer von ca. 8µs, also 125 kHz Frequenz und habe entsprechend auf Prescaler = 16, Timesegment1 = 15 und Timesegment2 = 2 gestellt. Habe ich da einen Denkfehler drin?!

Gruß
hochsitzcola

 

[temp]

Ich lese daraus ein Periodendauer von ca. 8µs, also 125 kHz Frequenz und habe entsprechend auf Prescaler = 16, Timesegment1 = 15 und Timesegment2 = 2 gestellt. Habe ich da einen Denkfehler drin?!

Auf die Schnelle: Es geht nicht um die Periodendauer, sondern um die Zeit für ein Bit. Da lese ich aber 4µs aus deinen Bildern, was 250k entspricht. In deiner Zeit (8µs) werden 2 Bits übertragen und nicht nur eins.

 

[Hochsitzcola]

sondern um die Zeit für ein Bit.

OK, danke, wieder was gelernt! Dann werde ich es heute Abend mal so versuchen:

hcan.Init.Prescaler = 9;
  hcan.Init.Mode = CAN_MODE_NORMAL;
  hcan.Init.SyncJumpWidth = CAN_SJW_4TQ;
  hcan.Init.TimeSeg1 = CAN_BS1_13TQ;
  hcan.Init.TimeSeg2 = CAN_BS2_2TQ;

@reinosmart : Kannst du doch noch mal ein Layout-Bild aus KiCAD mit der Bauteilbeschriftung hochladen? Die Teile sind gestern von Reichelt gekommen, dann tue ich mich leichter mit der Bestückung!

Gruß
hochsitzcola

 

[reinosmart]

gruß reinosmart

 

[reinosmart]

Habe gestern mit meinen Messdaten etwas rumexperimeniert. Das Gaugesignal erst durch einen Hochpass mit fg=300 Hz gejagt, also deutlich im Sprerrbereich, die Amplitudendämpfung wegskaliert und die Werte dann wieder kumuliert. Dadurch wird die Kadenz belohnt und die Werte für das kumulierte Signal liegen nun im Mittel bei ca. 800 Einheiten auf gleichem Niveau.
Es dürfte gerade noch im Rahmen meiner Fähigkeiten liegen das mal in den Programmcode einzupflegen und dann testen.

 

[Hochsitzcola]

Das Gaugesignal erst durch einen Hochpass mit fg=300 Hz gejagt,

Was für einen Algorithmus willst du denn verwenden? Ich habe mir da nie Gedanken zu gemacht. Mit ein bisschen googlen bin ich z.b. auf diesen Vorschlag gestoßen:

Hochpass (in C):

input = new_value();                        // Neuen Wert holen
output = (input - in_old) + (output * K);   // Ausgabe berechnen
in_old = input;                             // Wieder bereit!

Je größer "K", desto tiefer die Grenzfrequenz.

Gruß
hochsitzcola

 

[reinosmart]

Was für einen Algorithmus willst du denn verwenden?

Hab's im Moment so implementiert, aber irgendwie hat die erste Fahrt noch nicht so recht funktioniert.

 case REG_MOTOR_TORQUE_GAUGE_VALUE:
              i16_Gauge_Torque_HP = (i16_Gauge_Torque_HP + 20 * RxData[3] - i16_Gauge_Torque)>>2; // a=0.25  y(i)=a* (y(i-1)+x(i)-x(i-1))
              i16_Gauge_Torque = 20 * RxData[3];  // *20 wegen Dämpfung
              i32_Gauge_Torque_cumulated -= (i32_Gauge_Torque_cumulated>>MS.Filter); // FILTER = 6 für 1s Zeitkonstante
              i32_Gauge_Torque_cumulated += abs (i16_Gauge_Torque_HP);

Die Formel steht u.a. hier Hochpass

 

[reinosmart]

aber irgendwie hat die erste Fahrt noch nicht so recht funktioniert

lag wohl auch daran, dass ich gain_gauge zwar auf c5*10=30 gesetzt habe, das im Debug Mode aber immer auf c5*25=75 zurückgesetzt wurde, keine Ahnung warum. Dummerweise ist bei geringen Werten für gain_gauge die Kadenzbestrafung noch deutlicher.
Eines muss klar sein, selbst wenn sich die Kadenzbestrafung wegfiltern lässt, so funktioniert das nur bei den Ritzeln. Beim Schalten der Kettenblätten geht das in die Hose. Man kann es drehen und wenden wie man will, der interne DMS ist nur ein Schätzeisen. Ein BB-Sensor, den man sauber in Watt skalieren kann ist eine ganz andere Klasse.

 

[reinosmart]

Der Hochpass funktioniert, ich habe die Log-Daten mit meiner Excel Simulation abgeglichen und das passt. Die Wirkung ist aber noch nicht so wie gewünscht. Das liegt wohl in erster Linie daran, dass das Gauge Signal nicht wie ein gleichgerichteter Sinus ausschaut, sondern eher aus Nadeln besteht. Eigenartigerweise ist in letzter Zeit jeweils jede 2. Nadel höher, keine Ahnung warum. Im Bereich Z20..26 ist das Ergebnis ganz ok, bei Z26 nicht, allerdings ist hier der Pedaldruck auch so niedrig, dass ich so nicht fahren würde. Ich lasse es jetzt erst einmal so, langsam nervt es auch ein wenig
Noch eine Frage an @Hochsitzcola? Ich fahre immer mit ca. 12 km/h, nach Display und Tacho, im Debug Modus wird am immer ca. 14 km/h daraus??

 

[Hochsitzcola]

Eigenartigerweise ist in letzter Zeit jeweils jede 2. Nadel höher,

Hast du so einen unrunden Tritt?

Ich fahre immer mit ca. 12 km/h, nach Display und Tacho, im Debug Modus wird am immer ca. 14 km/h daraus??

Hm, es wird ja einfach nur der Wert weitergereicht, den der BionX-Controller sendet. Ggf. müsste man den Wert für Wheel Circumference anpassen, damit der BionX-Controller richtig rechnet.

Ich staune ja, wie viel Arbeit du in die Aufbereitung des Gauge-Wertes steckst. Ist die Unterstützung denn ansonsten schön geschmeidig und dich stört nur, daß "niedrige Kadenz belohnt" wird, oder fährt es sich von Grund auf nicht schön?!

Gruß
hochsitzcola

 

[reinosmart]

Hm, es wird ja einfach nur der Wert weitergereicht

Auf dem Display ist der Wert ja richtig, aber im Debug Modus kommt der Wert falsch rüber. Ich glaube, dass im Debug Modus ein falscher Wert für den Radumfang benutzt wird, der ja sonst vom Dispay kommt. Naja, ist nicht so schlimm.

fährt es sich von Grund auf nicht schön?

Es fährt sich sehr angenehm, keine Frage, insofern besteht da wirklich kein Leidensdruck, ich wollte es nur physikalisch sauber hinbekommen. Zur Not kann man ja immer noch mit der throttle etwas korrigieren.

gruß reinosmart

 

[reinosmart]

Jetzt ist doch noch ein Problem aufgetaucht. Es betrifft die Anfahrunterstützung, die am Anfang meiner Fahrerprobung recht ordentlich war. Jetzt komme ich aus dem Stand mit Daumengas kaum noch weg, erst nach 1-2 m schießt das Rad dann vehement los. Die Wattanzeige auf dem LCD steht dann auch auf nur ca. 100 Watt, irgendwie wird nicht genug Strom freigegeben. Ich hab keine Ahnung was ich mir da verbogen habe.
Mir ist auch aufgefallen, das beim ersten Gasgeben gar nichts passiert, sondern erst beim 2. Mal.

 

[Hochsitzcola]

die am Anfang meiner Fahrerprobung recht ordentlich war

War das bei dir tatsächlich mal anders? Ich kenne das von meinem Rollentrainer, das Rad dreht erst mal sehr zögerlich los, bevor es dann richtig Gas gibt...

Ich habe heute den Lötkolben geschwungen. Die Reichelt-Liste muss ich noch Mal prüfen, es fehlten zwei Widerstände. Und natürlich der JST Header für den externen Drehmomentsensor Braucht es den Kühlkörper für den Transistor wirklich?! Ich habe ihn erst mal weggelassen. Das Bluepill-Board habe ich auf Buchsenleisten gesetzt, damit entschärft sich die Bauraumsituation mit den Steckern und Kondensatoren, außerdem kann man es so leicht rausnehmen und bequem am Schreibtisch flashen. Dem MCP2551 hab ich auch einen IC-Sockel spendiert. Probiert habe ich noch nichts, aber auf der Basis kann ich jetzt mal am Prüfstand anfangen mit dem Ein- und Ausschalten der Spannungen zu experimentieren.

Gruß
hochsitzcola

 

[reinosmart]

War das bei dir tatsächlich mal anders?

Ich bin mir sehr sicher, leider habe ich keine Daten davon. Ich erinnere mich noch an mein Grinsen, als das Rad so schön lautlos aus dem Stand beschleunigt hat. Da zieht der gleiche Motor mit dem Kunteng besser weg, obwohl der Bionx mit dem Originalcontroller sonst deutlich mehr Bumms hat als der gleiche Motor mit Kunteng, immer bezogen auf 10A. Woher kann denn die Verzögerung von MS.power kommen?

Sauber aufgebaut, jetzt gibt es schon zwei. Gute Idee das BP Board etwas höher zu setzten. Wahrscheinlich ist der Kühlkörper für den BD139 wirklich entbehrlich. Ich kann dir gerne noch einen JST schicken, hab noch so ein Set zum selber crimpen.

 

[reinosmart]

Habe jetzt doch noch eine ältere Messung gefunden. Da habe ich eher behutsam Gas gegeben und komme trotzdem schneller in die Puschen.

 

[Hochsitzcola]

Woher kann denn die Verzögerung von MS.power kommen?

Da musst du wohl den BionX-Firmwareentwickler fragen. Ggf. kannst du ja noch mal auf die alte Version von deinem log zurückflashen, um zu schauen, ob es an unserer Software liegt...

Da habe ich eher behutsam Gas gegeben

Vielleicht ist das ja der Trick.

Gruß
hochsitzcola

 

[reinosmart]

Habe gestern versucht das Speed Signal etwas zu glätten. Mit dem Erfolg, dass jetzt mein LCD3 keinen Mucks mehr von sich gibt, auch mit alten SW-Ständen nicht.
Kann man ein Display durch falschen Programmcode zerstören ??!

 

[temp]

Ich will hier noch mal einen anderen Gedanken einwerfen. Das ist mir zwar schon lange aufgefallen, bin mir aber nicht sicher ob das einer hören will.
Das normale Gehirn (die Console) bei BionX fragt die 0x21 (GaugeValue) genau alle 50ms einmal ab. Weiter oben wurde von einer Samplerate von 200Hz gesprochen. Das ist das 10fache. Das der Motor intern das nicht mal so schnell sampelt sieht man daran, dass reinosmart von immer 2 gleichen Werten hintereinander berichtet. Auf alle Fälle weiß keiner, wie die Firmware im Motor aufgebaut ist und ob die mit diesem Bombardement in allen Situationen klar kommt. Jede Spekulation darüber ist auch überflüssig, solange man nicht mehr als eine Glaskugel hat. Ich persönlich wäre näher am Original geblieben. Der Bus läuft mit 125kbaud. Ca.100bit braucht eine Message auf dem Bus oder 0,8ms. Wenn alle 5ms 3 Messages hin und 3 zurück gehen sind wir bei 4,8ms und damit ist sogar der Bus fast dicht.

 

[reinosmart]

An einem Kunteng Controller konnte ich immerhin das Brake Symbol aktivieren, also ist die Kommunikation noch i.O. Da wird doch der Hund in der Pfanne verrückt.

 

[Hochsitzcola]

Habe gestern versucht das Speed Signal etwas zu glätten.

Das hatte ich im letzten Commit schon eingebaut

Mit dem Erfolg, dass jetzt mein LCD3 keinen Mucks mehr von sich gibt

Hast du denn mal geprüft, ob das Display noch Daten über UART sendet? Der BMT sendet ja nichts freiwillig ans Display, er antwortet nur auf gültige empfangene UART- Nachrichten...

Das ist das 10fache.

Na ja, 0x21 ist ja nur jede dritte Nachricht. Aber natürlich kann man die Häufigkeit der CAN-Nachrichten auch reduzieren, man muß nur den Slowloop-Zähler weiter zählen lassen also statt bis 5 bis 10 oder wie weit auch immer.

if (ui16_slow_loop_counter>5){

Timer3_Flag wird mit 1 kHz gesetzt.

Gruß
hochsitzcola