Nach ein
paar Optimierungen sieht es jetzt gut aus. Spannungsteiler von 5V auf 3,3V für das UART Signal vom Motor. End of Frame Erkennung nur noch über das 0xFF, ignorieren von unplausiblen Werten für wheeltime und torque, Neusyncronisierung des Streams bei Checksumfehler. Der kommt noch vor, aber selten, wenn da ab und zu mal ein Frame verschluckt wird, ist das nicht tragisch.
Hier ein Plot meiner Standard-Testrunde. Wie man sieht, bin ich die Steigung hochgeprügelt, ähnliche Geschwindigkeit wie in der Ebene, der Motor schiebt schon gut.

Leider mit einem in meinen Ohren penetranten Surren, ich bin halt komplett lautlose Direktläufer gewöhnt. Aber auch der Shengyi Getriebemotor in meinem Fischer ist deutlich leiser.
Dann habe ich noch das Ausgangssignal bei verschiedenen Übersetzungen geloggt. Mit einer Kofferwaage 5 - 10 - 15 - 20 - 25 - 30kg bei blockiertem Hinterrad auf die waagerechte Pedale mit 170mm Kurbellänge gebracht. Hab die Zähne von Blättern und Ritzeln nicht gezählt, sieht aber plausibel aus.
Fazit: Tut was es soll, ist so nur für den "Otto-Normal-Umbauer" nicht zu gebrauchen, solang man keinen passenden Controller dazukaufen kann. Für mich wäre ein leiseres Getriebe auf jeden Fall Pflicht. Auch habe ich keine Temperaturinformation im Stream identifizieren können. Vielleicht versteckt es sich noch irgendwo. Da müsste ich den Motor doch noch auseinanderbauen und schauen, ob da ein Thermistor verbaut ist. Dann könnte ich dem Motor eine hohe Temperatur vorgaukeln und schauen, was sich im Byte-Stream tut....
Mit KCLamber habe ich zwar ein paar Mails hin- und hergeschrieben, die wollten aber nur wissen, warum mich solche Details interessieren. Die angefragten Infos zum UART-Protokoll haben sie nicht rausgerückt...
Gruß
hochsitzcola