RP ✔️ VLT Firmwares, in DE 22Kmh⚡ mit Vanilla Firmware und vieles mehr

Auf die Gefahr, dass mein Beitrag etwas untergegangen ist…

Kann die DRV 247 nicht via Scooter Companion updaten, bei der DRV 236 war dies kein Problem.

Woran kann dies liegen? Habe leider nur IOS Equipment.

LG
 
Das müsste der hexcode sein um den Tempomat in der relight Version von Seite 1 auf aus zu stellen.
Code:
A0 F8 3E 51

Passt aber in der relight Version von Seite 1 nicht mehr hin. Dazu müsste der branch zum abbrechen, wenn die Zeit Verzögerung noch nicht erreicht wurde, verschoben werden.
Oder man ersetzt den optionalen kers Level patch in der relight von Seite 1 damit.

Edit:
Wenn man den beep weg lässt, passt es.
Post automatically merged:

Auf die Gefahr, dass mein Beitrag etwas untergegangen ist…

Kann die DRV 247 nicht via Scooter Companion updaten, bei der DRV 236 war dies kein Problem.

Woran kann dies liegen? Habe leider nur IOS Equipment.

LG
Nimm bitte Android. Bei ios kann ich dir leider nicht helfen
 
Zuletzt bearbeitet:
  • Hilfreich!
Reaktionen: mhdot und 4Ultra
Danke für die Rückmeldung, die DRV 236 klappt auch ganz großartig, ich denke ich werde vorerst dabei bleiben und kein Android anschaffen.
 
Hehe, in der Tat tüftele ich seit einiger Zeit an einer Möglichkeit Bluetooth temporär komplett zu deaktivieren. Hätte das am liebsten gern hardwareseitig, so das sich die Radiounit des nRF51822 bei Bedarf einfach ganz abschalten lässt. Hatte bei diversen Versuchen bei ruhiger Hand und einer gehörigen Portion Mut bisher eher nicht den gewünschten Erfolg... immerhin waren die Eingriffe zum Glück reversibel.

Anhang anzeigen 15858 Anhang anzeigen 15859

Es scheint bedauerlicher Weise nicht trivial zu sein dem Chip das Blauzahnen abzugewöhnen. RST auf Masse deaktiviert das Dash kompletto, Abtrennen der Antenne oder Masseschluß bring ebenfalls nix, auch Pulldown Wiederstände auf Ant1,Ant2,VDD_PA und diverse GPIO Pins leider still NoGo. Selbst bei vollständigem Unterbrechen der Stromversorgung der Sendeverstärker Pins (AVDD s. Photo) führte das zumindest im Nahbereich zu keiner nennenswerten Reduktion des Radio Outputs... dat blöde Ding sendet einfach immer lustig weiter!

Dachte ich zeig das Ganze mal, vielleicht gibts hier ja noch andere Gestörte die zum Zeitvertreib gerne Ihre Hardware schrotten, lol.
Hardwareseitig könnte man einen Reedkontakt Unterbrecher bauen der Bluetooth Funkerei nur zulässt wenn man das per Magnet erlaubt. Oder aber man realisiert das in der Firmware selbst, so das sich z.B. nur noch eine bestimmte verifizierte Gegenstelle connecten kann bzw. alternativ das BT erst nach einem definierten Input (z.B. Hebeltrick) aktiviert wird. Finde es obsolet das jeder da von Außen auf der Firmwareebene rumschnüffeln u. flashen kann, BLE mit Tastendruck-Abfrage ist für mich da nur ein schwacher Trost. BT or not BT that's the Question ;)
Ich finde neuen Input auch immer super, nur erschließt sich mir der Mehrwert nicht ganz. Wer Angst vor Bluetooth - Sniffing hat, schaltet eben das Dash stromlos-ob per Schlüsselschalter, Funkrelais oder Reed-Kontakt- warum auf dem Chip rumbrutzeln? Keine Kritik, sondern ne ernstgemeinte Frage 🤓
 
Danke für die Rückmeldung, die DRV 236 klappt auch ganz großartig, ich denke ich werde vorerst dabei bleiben und kein Android anschaffen.
Ja das kannst du natürlich auch machen.
Fahre auch mit der DRV236. Bin mit der sehr zufrieden.

Allerdings kostet ein günstiges Android auch nicht die Welt.
Gerhard Gerhard hat hier eine Liste zusammengestellt:
 
  • Hilfreich!
Reaktionen: mhdot und Gerhard
Lutscher Lutscher erst mal finde ich es genial, dass du da dran rumtüftelst. Den Gedanken kann ich total nachvollziehen.
Oder aber man realisiert das in der Firmware selbst, ... alternativ das BT erst nach einem definierten Input (z.B. Hebeltrick) aktiviert wird.
Ich denke dafür habe ich einen Weg: Deaktivierung der Kommandoverarbeitung durch ein Flag bzw. zwei Flags da es zwei Schnittstellen sind. Für die Testerei fehlt mir aber die Zeit und Lust, deshalb hier die Idee:

DRV304: 0x52b8 und 0x568c
Es wird hier jeweils ein Wert von einer Adresse geladen. Bei dem Wert handelt es sich eigentlich um ein Semaphore Lock. Nun der Trick: Wenn man den Wert an den Adressen irgendwo anders auf "1" setzt wird die Kommandoabarbeitung solange übersprungen bis man den Wert wieder auf "0" setzt. Man könnte also durch die Bremse+Gas Kombi diesen Wert und damit die Freigabe der Kommunikation steuern. So weit die Theorie.
 
Zuletzt bearbeitet:
Also wenn ich das hier richtig verstehe, sieht es so aus als könne man den nRF51xxx im Prinzip per UART Verbindung mit GDB Realtime-Debuggen. Vielleicht residiert UART Code ja unerkannter Weise bereits in der Firmware..? Wäre doch übelst nais wenn sich rausfinden ließe, ob wir endlich in Echtzeit mitverfolgen können was da auf der Kiste zur Laufzeit passiert.



Das ist zwar für das nRF51 Evaluation Board gedacht, aber womöglich sind gewisse Debugging Funktionalitäten ja bereits in der FW aktiv. Müsste man mal bei ner guten Tasse Kaffee im Disassembler durchwuseln ob irgendwo UART/Debug-Related Code in der FW auftaucht....

Ich finde neuen Input auch immer super, nur erschließt sich mir der Mehrwert nicht ganz. Wer Angst vor Bluetooth - Sniffing hat, schaltet eben das Dash stromlos-ob per Schlüsselschalter, Funkrelais oder Reed-Kontakt- warum auf dem Chip rumbrutzeln? Keine Kritik, sondern ne ernstgemeinte Frage 🤓
Hehe, ja ne gewisse Paranoia gehört schon dazu. Das Dash ist bei mir bei Bedarf ebenfalls über die Reset Leitung im Standby. Aber wenn es in Kürze DRV/BLE Updates gibt die nur noch per ST-Link downgradedable sind, würde ich mich einfach besser fühlen, wenn mich nicht nur der Powerbutton vor einer DPC-Testung oder Auslesen der FW Versionsnummern/Flashen Derselben bewahrt. Aber wie immer gehts auch um's Basteln ;)

Ich denke dafür habe ich einen Weg: Deaktivierung der Kommandoverarbeitung durch ein Flag bzw. zwei Flags da es zwei Schnittstellen sind. Für die Testerei fehlt mir aber die Zeit und Lust, deshalb hier die Idee:

DRV304: 0x52b8 und 0x568c
Es wird hier jeweils ein Wert von einer Adresse geladen. Bei dem Wert handelt es sich eigentlich um ein Semaphore Lock. Nun der Trick: Wenn man den Wert an den Adressen irgendwo anders auf "1" setzt wird die Kommandoabarbeitung solange übersprungen bis man den Wert wieder auf "0" setzt. Man könnte also durch die Hebel+Gas Kombi diesen Wert und damit die Freigabe der Kommunikation steuern. So weit die Theorie.
Wow, das klingt wie ein vortrefflicher Ansatzpunkt... danke für den Tip! Werd die Offsets mal bei meiner DRV223 raussuchen, wenn ich die Zeit dafür finde. Ein erster Schritt wäre ja z.B. ein Deaktivieren über die App bis zum nächsten Einschalten des Scooters.
 
Zuletzt bearbeitet:
UART Code ja unerkannter Weise bereits in der Firmware..
Als ich von Kommandoabarbeitung sprach meinte ich das Lesen vom UART. BLE reicht die Kommandos über UART an das ESC weiter, die werden dann von Unterfunktionen an den von mir genannten Offsets ausgelesen und ausgewertet. Was auf der Kiste passiert weiß man über das BLE schon sehr genau. Das direkte Abgreifen der UART Leitung interessiert mich aber zugegebenermaßen auch sehr :D
 
DRV304: 0x52b8 und 0x568c..... Es wird hier jeweils ein Wert von einer Adresse geladen. Bei dem Wert handelt es sich eigentlich um ein Semaphore Lock

semalock_code_dump.png


Ok, hab mal die Stelle in meiner DRV223 ausfindig gemacht: 0x541C ist die Adresse wo das Semaphore Lock Flag ausgelesen wird.
Sind eigentlich die Offsets der SHU Funktion 'Tail light always active' bekannt? Dieser Switch ließe sich doch hervorragend zum Ausprobieren solcher Dinge verwenden, um damit Flags testweise zu toggeln und so z.B. wie von Nandtek vorgeschlagen die 'Kommandoverarbeitung' einzufrieren.
Wobei das Ziel dürfte ja nicht sein die UART Kommunikation zwischen BLE/ESC komplett lahmzulegen, da davon doch vorraussichtlich weitere Dashboard Funktionalitäten betroffen sein müssten.... nicht wahr?
Ich wäre gern imstande Bluetooth bezogene Code Sections genauer zu lokalisieren, jedoch ohne Live Session wirds schwierig, hehe.
Man könnte eventuell ein paar Standard nRF51 Code Snippets ausprobieren und sehen ob man die in der BLE Firmware irgendwo findet.... hmmmm :unsure:
 
Lutscher Lutscher Ahh herrlich!! mich freut es immer wieder unheimlich hier gleichgesinnte zu treffen :) Das Semaphore ist in deiner DRV aber bei 0x5422, also R4+#4. Erkennt man daran dass er direkt nach dem Laden mit 1 beschrieben wird und vor dem return mit 0.

davon doch vorraussichtlich weitere Dashboard Funktionalitäten betroffen sein müssten
Gas/Bremse und alles was direkt über I/O am ESC hängt würde weiterhin gehen. Aber alle Kommandos wären lahmgelegt, d.h. Aktivieren, Flashen, Sperren, Register Lesen/Schreiben uvm.
Post automatically merged:

Sind eigentlich die Offsets der SHU Funktion 'Tail light always active' bekannt?
ja, ist auch in meiner app eingebaut. kannst die Adresse sicherlich zum testen nutzen.