CaniOn Verbindungsprobleme

iOnier hat geschrieben:

Mei hat geschrieben:1300 fps kann kein Mensch erfassen.

Die Maschine aber schon. Die App nimmt ja Daten auf, .....

Jo,
meine Ladestation auch
Deshalb rede ich davon.
Aber es gibt eben exceptions
https://de.wikipedia.org/wiki/Ausnahmebehandlung
Da muss man drauf reagieren.

me68 würde die exception Mei vielleicht besser handlen wenn sie den Draht zu ihm freundlicher suchen würde

Wenn die Differentialdiagnose von me68 zutrifft (zu geringe Baudrate oder defekter Dongle) - was ich nicht beurteilen kann - wäre das Senden von STM bei BUFFER FULL ein bloßer workaround für eine schlecht konfigurierte (also lieber: richtig konfigurieren) oder defekte (also besser: reparieren / austauschen) Hardware.

Und warum Du mit fps kommst wo es um eine Baudrate geht erschließt sich mir auch nicht.

Hallo Mei!

Wir haben eine generelle Fehlerbehandlung, wenn keine Daten mehr übertragen werden - da wird nicht nur das Kommando STM gesendet, sondern die ganze Initsequenz.

Bezüglich verarbeiteter Datenmenge: es sind 300 bzw. 420fps, die von canIon verarbeitet werden.

Ein Beispiel warum es für caniOn wichtig ist, dass die Daten unterbrechungsfrei geliefert werden:
In der PID 373 wird die Systemspannung und die Stromstärke an der Traktionsbatterie 100 Mal pro Sekunde gesendet. Wir nutzen dies, um eine Summe des Produkts von Spannung und Strom zu bilden. D.h. wir haben intern einen Wert Ws in 100-facher Genauigkeit, der dann in Wh zur Anzeige gebracht bzw. in die Datenbank geschrieben wird.

Martin

iOnier hat geschrieben:...- wäre das Senden von STM bei BUFFER FULL ein bloßer workaround für eine schlecht konfigurierte (also lieber: richtig konfigurieren) oder defekte (also besser: reparieren / austauschen) Hardware......

ja, die Hardware ist immer Schuld. Das kenne ich. Software ist immer perfekt.

Und ob nun 10 oder 100 Werte für den Strom Verwendet werden, ändert praktisch nix an der Genauigkeit der Wh.

Komplett neu zu initialisieren ist bei Buffer Full nicht nötig. STM reicht.

Mei hat geschrieben:ja, die Hardware ist immer Schuld. Das kenne ich. Software ist immer perfekt.

Selektives Zitieren ist schlechter Diskussionsstil. Ich schrieb nicht umsonst "Wenn die Differentialdiagnose von me68 zutrifft [...]" und hab' das "Wenn" auch noch kursiv gesetzt, um das zu betonen.

Und ob nun 10 oder 100 Werte für den Strom Verwendet werden, ändert praktisch nix an der Genauigkeit der Wh.

Das mag sein; dennoch scheint der Programmierer viel Wert auf hohe Genauigkeit gelegt zu haben, so dass er darauf ein größeres Gewicht gelegt hat als auf Betriebssicherheit unter allen Umständen (z.B. erschwerte Kommunikation mit dem Endgerät).

Komplett neu zu initialisieren ist bei Buffer Full nicht nötig. STM reicht.

Auch das mag sein. Aber statt me68 Überheblichkeit vorzuwerfen hättest Du das sachlich mit ihm diskutieren können. Wäre vielleicht zielführender gewesen.

@me68: wäre es für Dich eine Option, den Quellcode unter einer public license zu veröffentlichen? Dann könnten andere Interessierte an der Weiterentwicklung mitarbeiten und Du wärst einerseits entlastet, andererseits kämen noch andere Denkweisen mit anderen Ideen dazu. Außerdem könnten Besserwisser wie Mei ihre Vorstellungen aktiv umsetzen. Vielleicht eine Entwicklerversion bei github oder so (ich kenne mich da nicht ausreichend aus), aus der "stable" Versionen dann den Weg in den Play Store finden?

So,
am LX liegt es nicht.
Mit einem original S3 mini GT-8190 (4.1.2) geht es ohne Abbrüche.

Hallo iOnier!

Es liegt nicht an übertriebener Genauigkeit, sondern daran, dass das Auto eben diese Werte 100 Mal pro Sekunde liefert - darauf haben wir keinen Einfluss. Wir können nur einen Filter auf die PIDs legen, die wir verwerten wollen, aber nicht auf die Frequenz der Datenlieferung. Wenn wir nun die Daten schon bekommen, können wir die auch gleich verwerten. Behandeln müssen wir die Daten ohnehin, ob ich jetzt 90 von 100 wegwerfe, weil ich die Genauigkeit nicht brauche oder ob ich alle verarbeite - es ändert nichts daran, dass diese Datenmenge auf das Android-Gerät übertragen wird.

Zum Thema Open Source: ja, kein Thema, wenn es nicht Leute geben würde, die daraus Profit schlagen würden und mit dem KnowHow eine eigene kostenpflichtige App bauen - ist leider passiert - deshalb ein Nein von meiner Seite.

Martin

me68 hat geschrieben:Es liegt nicht an übertriebener Genauigkeit, sondern daran, dass das Auto eben diese Werte 100 Mal pro Sekunde liefert - darauf haben wir keinen Einfluss.

Ah, OK. Da hier die Rede von fps und größerer Genauigkeit war als ein Mensch verarbeiten kann ging ich davon aus, dass mglw. der OBDLink so programmiert werden könnte, dass er nur z.B. jeden 10. frame weitergibt.

Zum Thema Open Source: ja, kein Thema, wenn es nicht Leute geben würde, die daraus Profit schlagen würden und mit dem KnowHow eine eigene kostenpflichtige App bauen - ist leider passiert - deshalb ein Nein von meiner Seite.

Warum wäre das schlimm?

so,
hab die btsnoop_hci.log im Handy aktiviert und CaniOn belauscht.
Es kommt wirklich "BUFFER FULL" und danach gar nix mehr.
Irgendwann macht CaniOn die Initialisierung neu und verbindet das BT auch neu.

Den Bluetooth log gibt es erst ab Android 4.4.
Möglicherweise ist da dann mehr "Zeug" dazwischen, sodass die Datenrate nicht mehr ausreicht, auch wenn die Option deaktiviert ist.
Das würde erklären, warum das S3mini mit upgrade auf 5.1 nicht geht, aber mit originalem 4.1.2 schon.
Auch dass das A3-2017 trotz octacore nicht geht, deutet auf mehr "Zeug" im BT Zweig hin.

Wer hat den ein Android gleich oder grösser 4.4 was mit CaniOn geht?

Ich habe hier ein ASUS Tablet P024 mit Android 6.0.1, damit und mit dem OBDLink LX funktioniert CaniOn.