RDrath spielt die Reihenfolge eine Rolle oder ist die egal? Haben die beim Support was zu gesagt? Bei mir steht ATSTFF jetzt an erster Stelle in der Liste!
Die Reihenfolge ist essentiell. Man kann sie durch swipen ändern, ggf. hast Du Dich vertan? Da gibts auch eine Rücksetzen Funktion.
Die Reihenfolge ist essentiell. Man kann sie durch swipen ändern, ggf. hast Du Dich vertan? Da gibts auch eine Rücksetzen Funktion.
Okay habe sie wieder in die Reihenfolge wie auf deinem Bild zurückgeschoben!
Okay habe sie wieder in die Reihenfolge wie auf deinem Bild zurückgeschoben!
Hier die Abfolge der OBD Befehle und ihre Bedeutung, noch mit dem vorigen ATST64 Befehl.
Lustig... das AT am Anfang erinnert mich gerade an Modem-Steuerbefehle (langs ists her) 
Bildschirmfoto 2024-11-05 um 19.06.03.jpg
Hier die Abfolge der OBD Befehle und ihre Bedeutung, noch mit dem vorigen ATST64 Befehl.
Ahh, jetzt wird es klar … ATST steht für AT „Set Timeout“ und die Zahl danach gibt an, wie lange gewartet werden soll. FF (also ATSTFF) ist der Maximalwert. Die Angabe scheint also ein Hexadezimalwert zu sein: FF = 255 = 100% und 64 = 100 = 39%.
Kurzum: ihr habt den Timeout erhöht auf den Maximalwert, weil das Steuergerät nicht schnell genug reagiert hat.
Könnte es sein das ABRP es schon aktualisiert hat? Bei mir gab es kein ATST64 mehr sondern nur den ATSTFF.
Ich habe es eben noch auf ATSTFF korrigieren müssen, das Fahrzeug war allerdings seit Anfang an schon mit der BLE OBD Verbindung bei ABRP eingerichtet.
Kurzer Test hier an der Ladesäule: Zuerst kommt wieder nur ein paarmal lesen schreiben verbunden lesen schreiben verbunden bis dann nur noch schreiben verbunden schreiben verbunden kam.
Aber eigenartigerweise nach einiger Zeit hat es ihn durchgerissen und er liest nun brav die Daten aus.
Mal beobachten ob es bei Neuverbindung am Anfang immer etwas braucht bis es flüssig läuft, oder ob das eine letzte Ausnahme war. 
RDrath Besten Dank für den Hinweis und dein Engagement!
FireSmart#1 hat recht, wenn man die BLE OBD Anbindung in ABRP neu erstellt, dann bekommt man mittlerweile auch schon den neuen geänderten Parameter.
Update:
Leider stottert es bei mir (mit VLinker MC+ und iOS )nach Neustart von ABRP mit dem neuen Parameter genauso wie vorher mit dem ursprünglichen und hört dann auf zu lesen. Schade. 
Funktioniert die Verbindung bei dir mit dem MC+ nun jedes Mal sofort auf Anhieb und dauerhaft?
Kann man die verlängerte Pause die durch den geänderten Parameter entsteht evtl. noch länger machen? Vielleicht hilft es. 
Vor fünf Tagen gab es für die VgateFirmwareUpdater App ein Update. Muss mal prüfen ob es für den MC+ Dongle nun eine neuere Firmware gibt.
Kann man die verlängerte Pause die durch den geänderten Parameter entsteht evtl. noch länger machen? Vielleicht hilft es.
Du kannst dich ja mal in die ELM-Spezifikation einlesen:
https://www.elmelectronics.com/DSheets/ELM327L_DSC.pdf
Relevante Stellen findest du mit den Suchbegriffen
Länger als ST FF kann man den Timeout nicht einstellen, da FF wie gesagt 100% entspricht. Aber man könnte noch versuchen den default timer sowie den Multiplikator zu verändern, was letztendlich in der Zeit in Millisekunden resultiert, die auf eine Antwort gewartet wird, insofern ich das richtig verstanden habe. Der Standard-Multiplikator ist 1 und geht wohl hoch bis auf 5.
Zuvor jedoch könntest du mal versuchen nicht gleich den ST-Maximalwert zu setzen. ST64 ist laut Spezifikation wohl schon nicht der default. Darum würde ich zunächst erstmal den default probieren bzw. den ST-Befehl zur Verlängerung des Timeouts erstmal generell wegzulassen. Ist ja nicht gesagt, dass ein längerer Timeout immer zum Erfolg führen muss. Wenn das nichts bringt, dann versuch mal, ob es mit anderen ST-Werten besser funktioniert. Dazu kannst du z.B hier die benötigten HEX-Werte konvertieren:
Gib den prozentualen Wert größer 0 ein und den angezeigten HEX-Wert verwendest du dann im ATST Command.
Endlich läuft bei mir der Vlinker MC+ mit ABRP. Gemeinsam mit dem Entwickler von ABRP haben wir uns auf Problemsuche gemacht, weil die Verbindung nicht zustande kam oder hakenförmig war. Dabei haben wir ein OBD Kommando modifiziert, das die Antwortzeit bei der Initialisierung verlängert. Sofort lief es.
Läuft es denn weiterhin sofort und jedesmal stabil bei dir?
Läuft es denn weiterhin sofort und jedesmal stabil bei dir?
Die letzten Tage ja, sofort und jedesmal stabil. Aber das ist noch kein Langzeittest, ich werde es weiter beobachten. Heute hat es mal wieder gehakt.
Also ist es doch nicht zu 100% gelöst.
Ich dachte schon nur ich hätte nach der Verbesserung das Problem.
Hast Du nun ausschließlich OBD BLE verbunden und kein Hello # (mehr)?
Ich habe nachwievor beide Quellen verbunden.
