Beiträge von Go4IT

Laut Handbuch gibt es diese Schutzarten:

1. Diebstahlwarnanlage ohne Innenraumüberwachung
2. Diebstahlwarnanlage mit Innenraumsensoren
3. Diebstahlwarnanlage der Kategorie 1 mit Innenraumsensoren und batteriegestütztem Alarmsystem
4. Diebstahlwarnanlage der Kategorie 1 mit Innenraumsensoren, batteriegestütztem Alarmsystem und Neigungssensoren

2-3 kennen wir ja nun, wobei ich behaupte das im Handbuch bei 3. ein Fehler drin ist, denn "Cat 1 Thatcham" ist nur die mit Neigungssensoren? Und was bitte soll 1. sein? Das müsste dann doch eigentlich jeder Mondeo haben, sprich, man bricht Tür oder Kofferraum auf (Haubenschloß gab es ja nur bei Alarmanlage) und los geht die wilde Huperei? Unter 1. dürfte grundsätzlich auch die Wegfahrsperre fallen.

Die Thatcham Category 1 umfasst:

Electronic Alarm and Immobiliser
Alarm
Perimeter detection
Ignition detection
Passenger compartment movement detection
Living compartment
movement detection (MandatoryLeisure vehicles only)
Inclination detection (Mandatory Motorcycle)
Audible warning with battery back

up power supply

Immobiliser
Passively set
Isolates a minimum of two operating circuits or systems

Zitat von matthes73

Sie wird erst nach verschließen der Türen vollständig aktiviert....wenn der Motor abgestellt wird....erscheint im Display der Hinweis " Innenraumüberwachung deaktivieren ? " ....Bis heute noch nicht ausgelöst wenn meine Frau shoppen geht und ich im Auto warte....

D.H. Deine Frau schließt das Auto sicherheitshalber ab während Du drin wartest, damit Du nicht wegläufst?

Blöde Frage: wenn ich die Alarmanlage nach abstellen der Zündung mit Innenraumsensor aktiviere, bleibe aber im Fahrzeug sitzen, wird ein Alarm dann erst ausgelöst wenn ich bei Keyless das Fahrzeug von außerhalb verschließe?

Was mich wundert ist das wenn ich das Sensormodul abziehe und die Zündung anmache, keine Fehlermeldung kommt von wegen "Wartung Diebstahlwarnanlage" oder sowas.

Beim EP wird keine Marke angegeben, da hatte ich schon geguckt. Das könnte ein Metzger sein, aber das bekäme man auch fast für die Hälfte https://www.autodoc.de/metzger/19341305 Das werde ich mir jetzt wohl mal bestellen, auf "Gut Glück"... für 28,- €

Nochmal zurück zum LIN-Scan. Wenn ich keinen Alarmsensor am LIN 2 angeschlossen habe und den Traffic sniffe, siehe ich nur ID 0x01, welche somit ganz klar vom BCM kommt:

# LIN Sniffer v1.7.6 (type HELP for commands)
  3996.888 | 39 | UNANSWERED               | --- |          |
  3996.911 | 01 | 20 02                    | CLA |  .       |
  3996.928 | 25 | UNANSWERED               | --- |          |
  3996.943 | 12 | UNANSWERED               | --- |          |
  3996.963 | 34 | UNANSWERED               | --- |          |
  3996.983 | 39 | UNANSWERED               | --- |          |
  3997.006 | 01 | 20 02                    | CLA |  .       |
  3997.023 | 25 | UNANSWERED               | --- |          |
  3997.038 | 12 | UNANSWERED               | --- |          |
  3997.058 | 34 | UNANSWERED               | --- |          |
  3997.078 | 39 | UNANSWERED               | --- |          |
  3997.101 | 01 | 20 02                    | CLA |  .       |
  3997.118 | 25 | UNANSWERED               | --- |          |
  3997.133 | 12 | UNANSWERED               | --- |          |
  3997.153 | 34 | UNANSWERED               | --- |          |
  3997.173 | 39 | UNANSWERED               | --- |          |
  3997.196 | 01 | 20 02                    | CLA |  .       |
  3997.213 | 25 | UNANSWERED               | --- |          |
  3997.228 | 12 | UNANSWERED               | --- |          |
  ...

Das wiederholt sich ein paar Sekunden und verstummt dann einfach. Es gibt keinen erkennbaren LIN SLEEP (0x3C 00 ..) wie auf dem LIN 2.

Schließe ich den Sensor nur an meinen Sniffer an und mache einen ID-SCAN, wird kein einziger Header beantwortet:

# LIN Sniffer v1.7.6 (type HELP for commands)
> scan
+++ LIN Bus Scan  (0x00 - 0x3F) +++
Scanning IDs 0x00-0x3F...
   159.772 | 00 | UNANSWERED               | --- |          |
   159.976 | 01 | UNANSWERED               | --- |          |
   160.181 | 02 | UNANSWERED               | --- |          |
   160.385 | 03 | UNANSWERED               | --- |          |
   160.588 | 04 | UNANSWERED               | --- |          |
   160.793 | 05 | UNANSWERED               | --- |          |
   160.997 | 06 | UNANSWERED               | --- |          |
   161.201 | 07 | UNANSWERED               | --- |          |
   161.405 | 08 | UNANSWERED               | --- |          |
   161.609 | 09 | UNANSWERED               | --- |          |
   161.812 | 0A | UNANSWERED               | --- |          |
   162.016 | 0B | UNANSWERED               | --- |          |
   162.221 | 0C | UNANSWERED               | --- |          |
   162.425 | 0D | UNANSWERED               | --- |          |
   162.628 | 0E | UNANSWERED               | --- |          |
   162.832 | 0F | UNANSWERED               | --- |          |
   163.037 | 10 | UNANSWERED               | --- |          |
   163.241 | 11 | UNANSWERED               | --- |          |
   163.444 | 12 | UNANSWERED               | --- |          |
   163.648 | 13 | UNANSWERED               | --- |          |
   163.853 | 14 | UNANSWERED               | --- |          |
   164.057 | 15 | UNANSWERED               | --- |          |
   164.260 | 16 | UNANSWERED               | --- |          |
   164.464 | 17 | UNANSWERED               | --- |          |
   164.668 | 18 | UNANSWERED               | --- |          |
   164.872 | 19 | UNANSWERED               | --- |          |
   165.077 | 1A | UNANSWERED               | --- |          |
   165.281 | 1B | UNANSWERED               | --- |          |
   165.484 | 1C | UNANSWERED               | --- |          |
   165.689 | 1D | UNANSWERED               | --- |          |
   165.894 | 1E | UNANSWERED               | --- |          |
   166.098 | 1F | UNANSWERED               | --- |          |
   166.302 | 20 | UNANSWERED               | --- |          |
   166.506 | 21 | UNANSWERED               | --- |          |
   166.709 | 22 | UNANSWERED               | --- |          |
   166.913 | 23 | UNANSWERED               | --- |          |
   167.118 | 24 | UNANSWERED               | --- |          |
   167.322 | 25 | UNANSWERED               | --- |          |
   167.526 | 26 | UNANSWERED               | --- |          |
   167.731 | 27 | UNANSWERED               | --- |          |
   167.934 | 28 | UNANSWERED               | --- |          |
   168.138 | 29 | UNANSWERED               | --- |          |
   168.343 | 2A | UNANSWERED               | --- |          |
   168.547 | 2B | UNANSWERED               | --- |          |
   168.750 | 2C | UNANSWERED               | --- |          |
   168.955 | 2D | UNANSWERED               | --- |          |
   169.160 | 2E | UNANSWERED               | --- |          |
   169.365 | 2F | UNANSWERED               | --- |          |
   169.568 | 30 | UNANSWERED               | --- |          |
   169.773 | 31 | UNANSWERED               | --- |          |
   169.978 | 32 | UNANSWERED               | --- |          |
   170.182 | 33 | UNANSWERED               | --- |          |
   170.385 | 34 | UNANSWERED               | --- |          |
   170.590 | 35 | UNANSWERED               | --- |          |
   170.795 | 36 | UNANSWERED               | --- |          |
   170.999 | 37 | UNANSWERED               | --- |          |
   171.204 | 38 | UNANSWERED               | --- |          |
   171.409 | 39 | UNANSWERED               | --- |          |
   171.612 | 3A | UNANSWERED               | --- |          |
   171.816 | 3B | UNANSWERED               | --- |          |
   172.021 | 3C | UNANSWERED               | --- |          |
   172.225 | 3D | UNANSWERED               | --- |          |
   172.428 | 3E | UNANSWERED               | --- |          |
   172.632 | 3F | UNANSWERED               | --- |          |
══════════════════════════════════════════
Scan complete.

Führe ich einen sniff auf dem LIN 2 durch, mit angeschlossenem Sensor ist da deutlich mehr los:

 71016.065 | 23 | 01 00 00 00              | CLA | ....     |
 71016.065 | 01 | 20 02                    | CLA |  .       |
 71016.096 | 08 | 01 00                    | CLA | ..       |
 71016.097 | 25 | UNANSWERED               | --- |          |

 71016.129 | 23 | 01 00 00 00              | CLA | ....     |
 71016.130 | 01 | 20 02                    | CLA |  .       |
 71016.162 | 08 | 01 00                    | CLA | ..       |
 71016.162 | 25 | UNANSWERED               | --- |          |
 71016.195 | 23 | 01 00 00 00              | CLA | ....     |
 71016.195 | 01 | 20 02                    | CLA |  .       |

 71016.226 | 08 | 01 00                    | CLA | ..       |
 71016.227 | 25 | UNANSWERED               | --- |          |
 71016.339 | 01 | 20 02                    | CLA |  .       |
 71016.372 | 08 | 01 00                    | CLA | ..       |
 71016.372 | 25 | UNANSWERED               | --- |          |
 71016.405 | 23 | 01 00 00 00              | CLA | ....     |
 71016.405 | 01 | 20 02                    | CLA |  .       |
 71016.437 | 08 | 01 00                    | CLA | ..       |
 71016.437 | 25 | UNANSWERED               | --- |          |

 71016.469 | 23 | 01 00 00 00              | CLA | ....     |
 71016.470 | 01 | 20 02                    | CLA |  .       |

 71016.502 | 08 | 01 00                    | CLA | ..       |
 71016.502 | 25 | UNANSWERED               | --- |          |
 71016.535 | 23 | 01 00 00 00              | CLA | ....     |
 71016.535 | 01 | 20 02                    | CLA |  .       |
 71016.639 | 01 | 20 02                    | CLA |  .       |
 71016.656 | 25 | UNANSWERED               | --- |          |
 71016.692 | 12 | UNANSWERED               | --- |          |
 71016.712 | 39 | UNANSWERED               | --- |          |
 71016.735 | 01 | 20 02                    | CLA |  .       |
 71016.752 | 25 | UNANSWERED               | --- |          |
 71016.787 | 12 | 02 36 47 39 4E 00 00 00  | CLA | .6G9N... |
 71016.787 | 34 | UNANSWERED               | --- |          |
 71016.807 | 39 | UNANSWERED               | --- |          |
 71016.829 | 01 | 20 02                    | CLA |  .       |
 71016.846 | 25 | UNANSWERED               | --- |          |
 71016.882 | 12 | 03 31 35 4B 36 30 37 00  | CLA | .15K607. |
 71016.882 | 34 | UNANSWERED               | --- |          |
 71016.902 | 39 | UNANSWERED               | --- |          |
 71016.925 | 01 | 20 02                    | CLA |  .       |
 71016.942 | 25 | UNANSWERED               | --- |          |
 71016.976 | 12 | 04 43 47 00 00 00 00 00  | CLA | .CG..... |
 71016.977 | 34 | UNANSWERED               | --- |          |
 71016.997 | 39 | UNANSWERED               | --- |          |
 71017.019 | 01 | 20 02                    | CLA |  .       |
 71017.037 | 25 | UNANSWERED               | --- |          |
 71017.072 | 12 | UNANSWERED               | --- |          |
 71017.092 | 39 | UNANSWERED               | --- |          |
 71017.114 | 01 | 20 02                    | CLA |  .       |
 71017.132 | 25 | UNANSWERED               | --- |          |

Gut zu erkennen das auch hier auf einer der höheren IDs die Teilenummer übermittelt wird. Aber man sieht auch das "20 02" Pattern vom BCM mit ID 0x01 periodisch und es scheint als würde der Sensor auf 0x08 oder 0x023 darauf antworten.

Nun prüfe ich mal wie ich mit meinem Sniffer den Code so bauen kann das ich zugleich periodisch das "20 02" vom BCM immitieren, aber auch ID-Abfragen auf 0x08 und 0x23 durchführen kann, ob der Sensor dann antwortet.

Hat jemand bezüglich der Haubenschlösser schon negative Erfahrungen mit OEM-Teilen gemacht? Das Original-Schloß ruft Ford mit gut 230,- € auf, im Zubehör von Metzger gibt es das um die 50,- € und direkt vom Chinesen für 20,- €.

Habe mir jetzt den Kabelbaum erweitert und das Modul mal angesteckt und in der CCC den "Interior Motion Sensor" sowie "Alarm" auf "Stufe 2 (Perimeter Antitheft)" aktiviert. Im Menü habe ich nun die "Alarmanlage" und auf dem LIN zum Modul tut sich auch was, man hört sogar das Sendesignal der US-Sensoren.

Jetzt meckert er natürlich wegen der Motorhaube, weil meine keinen Kontakt hat. Ich habe die Abdeckung am Schloß entfernt und den Stecker (grün) entdeckt, abgezogen und mit einer Drahtbrücke kurzgeschlossen. Somit ist erstmal ruhe bis das neue Schloß kommt.

Und genau das hätte ich ja auch erwartet beim aktivieren der Funktion. Ich kann mir aber gut vorstellen das das BCM die Existenz des Innenraumsensors abfragt und ohne diesen das gesamte Alarmsystem garnicht aktiviert.

Ich habe den Innenraum-Sensor (praktisch die kleinste Stufe der Alarmanlage) in der CCC aktiviert, ohne sie einzubauen. Dann passiert auch erstmal nichts, sprich es gibt kein Menü im IPC. Die Tage kommt der Innenraumsensor (in LT für nen 20er geschossen) und dann schaun mer mal. Eigentlich gehört dazu noch die Zusatzhupe in der Kofferraumseitenwand, welche über ein Relais im Kofferraum-Sicherungskasten angesteuert wird. Das wurde wohl gemacht das böse Buben von unten nicht einfach die Hupe kappen können. Da ein Relais aber nicht überwacht wird, kann das System nicht wissen das die fehlt und so hätte man schon eine Alarmanlage mit normaler Hupe.

Die nächste Stufe ist dann die Akkubetriebene Sirene im Motorraum. Die wird über LIN betrieben und ist somit überwacht. Diese gibt es in zwei Ausführungen, mit und ohne Neigungs/Erschütterungssensor. Das wäre dann die Vollausbaustufe, auch "Thatcham" genannt, vermutlich weil das von dem englischen Sicherheitstechnik-Unternehmen https://www.thatcham.org/products/automotive/ kommt.

Um zu erkennen ob in den Payload-Bytes lesbarer Text drin steht (selten, aber gibt manchmal wertvolle Hinweise) habe ich einen Ansatz gewählt bei dem über alle Frames geprüft wird wie oft dieser selbe vorkommt (Unique) und dann die druckbaren ASCII-Zeichen dieser Frames mit dargestellt. Hier man ein Beispiel der ID 0x405 die u.a. Kilometerstand und VIN enthält:

Im ANALYZE wird nun für jedes Byte einer ID ein kleiner Graph ausgegeben, der der Verlauf der Daten über den gesamten Logzeitraum darstellt:

Damit kann man sehr schnell erkennen wo sich Daten ändern und wie. Hier habe ich mal Daten vom HS-CAN Bus geladen und bei ID "0x400" sieht man im ersten Byte "B0" sehr gut diese Rampe, das ist ein typischer Zähler wie er z.B. bei UDS-TP (Multiframe) genutzt wird. Da wird eine Information in viele Pakete aufgeteilt und nacheinander gesendet. Jedes Paket enthält dabei im ersten Byte einen Index-Zähler.

Natürlich gibt es Werte die nicht in ein Byte passen, da muss man wissen welche zusammen gehören und darüber einen Graphen bauen um die Änderung zu erkennen. Dazu lasse ich mir noch was einfallen.

Ab v0.6.3 gibt es nun den ANALYZE Tab. Dort werden alle im Log enthaltenen IDs ihrer Reihenfolge nach aufgelistet:

Die Anzahl Bytes pro ID sind dargestellt. Auch die Werte die dieses Byte im Log hat sind dargestellt, entweder statisch (grau) mit ihrem Wert, oder farbig mit ihrem Wertebereich und der Varianz (Anzahl der unterschiedlichen Werte im Log).

Klickt man eine ID an, expandiert sich die Ansicht und es kommen die analysierten Bytes/Bits zum Vorschein:

Hier kann man der ID direkt ein Label verpassen (z.B. "RSM" oder "Rain-Sensor-Module" oder "Regensensor") welches dann immer im Zusammenhang dieser ID verwendet wird. Weiterhin kann man mit [ EDIT ] einen Editor öffnen der es erlaubt spezifische Inhalte zu deklarieren:

Hier kann man der ID einen Namen geben und einen Kommentar erfassen. Die hell dargestellten Bits sind die die sich im Log geändert haben.

Man kann nun ein oder mehrere Bits markieren und mit "+ Add Field" eine Definition dafür hinzufügen. Oben im Beispiel habe ich das für ID 0x05 (Regensensor) mal gemacht:

• Das Bit 6 von Byte 0 ist "1" wenn der Wischerhebel auf Automatik steht
• Der Tageslicht-Sensor gibt auf Bit 1 von Byte 1 ein "0" wenn es Hell ist und ein "1" wenn es dunkel ist. Man könnte ihn jetzt "Night detector" nennen, dann würde die Bitlogik stimmen, nenne ich ihn aber "Daylight detector" dann muss ich die Logik negieren, was ich über die Formel getan habe.
• Der Regensensor gibt auf Bit 0 von Byte 0 eine "1" bei Regen

Bei ID 0x06 z.B. wird im Byte 0 mit den Bits 1 und 2 die am Wischerhebeldrehrad eingestellte Empfindlichkeit übermittelt, das kann dann so formuliert werden:

Die dokumentierten IDs sind dann anders dargestellt, sodass man sofort erkennt wo man noch ungeklärte IDs/Daten hat:

Ich werde daran noch feilen, aber im Prinzip stelle ich mir das so vor.

Das gefällt mir alles schon ganz gut soweit Muss noch etwas an der UI und UX arbeiten, aber der Anfang ist gemacht! Als nächstes lasse ich mir was einfallen wie ich erkannte Daten, IDs und deren Payloads dokumentieren kann. Meine Idee ist ein Log zu laden oder einen Live-Log zu starten und in dieser Ansicht (vielleicht nenne ich sie "ANALYZE") dann alle IDs untereinander zu sehen, jeweils mit der Anzahl der Payload-Bytes und ein paar exemplarischen Werten. Z.B. wenn ein Wert immer gleich ist, dann den Wert, wenn es sich ändert dann "*" oder den Wertebereich "1A-8E".

Dann die Möglichkeit der ID eine Bezeichnung zu geben (z.B. "BMS" oder "Battery Sensor"). Um die Bytes zu benennen brauche ich vermutlich was komplexeres, da es teilweise einzelne Bits, oder Bitgruppen sind die eine Funktion ausmachen.

Immer dann wenn ich etwas kommentiere soll das grün hinterlegt werden. Im Tool möchte ich dann als ID-Filter auch sowas wie "Hide known" haben um sich eben auf die noch nicht erkannten IDs/Daten konzentrieren zu können.

Die Idee muss jetzt in meinem Kopf und im Code etwas reifen...

Zur grafischen Darstellung von Payload-Bytes habe ich eine "Graph Traces" Option entwickelt. Dazu definiert man einen Graph indem man die ID der darzustellenden Daten angibt (Frame ID) und über eine Formel (JavaScript Syntax) die Berechnung, wie hier im Beispiel "b(2) / 16" was bedeutet: Nehme den Wert aus dem 3. Byte von links der Payload von ID 0x00D und teile den Wert durch 16:

Man erhält dann unten einen schönen Graphen der alle Datenpunkte anzeigt und verbindet:

Über die Bereichswähler am Graph soll man dann den Zeitraum eingrenzen können, also ALL für von Anfang bis zur aktuellen Rekorderposition und die anderen relativ von der aktuellen Rekorderposition rückwärts.

In dieser ersten Version habe ich die Möglichkeit integriert einen Datenstrom über Websocket oder Logfile zu laden. Der "Videorekorder" funktioniert auch schon und man hat div. Möglichkeiten die Daten darzustellen und zu filtern.

(1) Ladebereich (Dropzone) für .log Files im CANDUMP Format (es können auch mehrere Logs geladen werden)
(2) Filter-Bereich für IDs - Hier kann man auswählen welche IDs man sehen möchte. Einzelne lassen sich durch Klick ab/anwählen. Damit kann man sich, auch im LIVE Modus auf einzelne IDs beschränken die man untersuchen will.
(3) Spalteninhalte (da muss ich nochmal ran...) - damit soll man wählen können was man alles sieht, die ID is obligatorisch, aber die anderen Daten kann man wählen. Auch soll man bei Daten die verschiedenen Darstellungsformen (HEX, DEZ, BINÄR) wählen können. Das gefällt mir aber noch nicht so...
(4) Das ist der Rekorder, das Herzstück des Monitor-Modes - Hier kann man mittels dem Slider oder den Tasten vor-/zurückfahren in den Logs oder wieder zum Live-Mode wechseln.
(5) Die Logdaten Darstellung - Wenn sich der Wert einer ID vom letzten zum aktuellen Frame ändert, wird die ID-Zeile kurz grün hinterlegt. So weiß man welche Bytes ihren Wert geändert haben. Auch da muss ich nochmal ran, das gefällt mir aktuell noch nicht wie ich es umgesetzt habe...

Zum spielen habe ich mal ein paar meiner Debug-Logs beigelegt.

Meine Idee für das Framework:

• Ein Scanner-Task liest live von einem Sniffer-Tool oder aus einer lokalen Log-Datei
• Das Tool hat grundsätzlich eine Darstellungsseite für die Daten, verbunden mit Rekorderfunktionen zum pausieren, vorwärts- rückwärts laufen lassen, ändern der Abspielgeschwindigkeit.

Für den Producer-Task:

1. WebSocket-Verbindung + candump Parser → erzeugt interne Frame-Objekte
2. IndexedDB-Ringpuffer (Producer)
3. Export-Funktion für candump in Datei

Mit 1. verbindet sich das Tool also per HTTP-Websocket mit einer Datenquelle (z.B. meinem LIN-Sniffer, an einem CAN-Sniffer bin ich bereits dran).
Mit 2. werden die dort abgerufenen Daten in einer Browserinternen Datenbankdatei gepuffert um das RAM nicht zu sehr zu belasten bei langen Logs
Mit 3. kann man die in der DB gepufferten Daten dann im CANDUMP Format in eine lokale Log-Datei für spätere Analysen oder zum teilen ablegen.

Für den Consumer-Task:

1. Pivot-Grid (Consumer, auto-refresh)
2. DVR-Controls (Playhead, Live/Pause/Scrub)
3. Graph-Panel
4. Export-Funktion

Moin zusammen, beflügelt von meinem LIN-Sniffer auf ESP32 Basis und der dafür angefangenen LIN-Analyzer Tool Software habe ich das Projekt erweitert und programmiere nun einen LIN-Bus/CAN-Bus Analyzer.

Funktionale Anforderungen:

1. Verarbeiten, analysieren und visualisieren von Dump-Daten im "CANDUMP" (und später auch mal in anderen) Datenformat
2. Daten können aus Datei (Logdatei) gelesen, aber auch Live von einem Websocket geliefert werden (z.B. mein LIN-Sniffer Tool)
3. Mehrere Betriebsmodus:
   1. Offline-Datenanlyse (Sichtung, Filterung, Darstellung von Log-Inhalten in vielen Möglichkeiten) mit Möglichkeit Inhalte zu "taggen" wenn deren Funktion klar ist
   2. Live-Modus zur Darstellung von Daten mit Änderungsanzeige, etc. während diese reintrudeln
   3. Replay-Modus bei dem Logdateien in Echtzeit, verzögert oder schrittweise, vorwärts/rückwärts durchlaufen werden können
   4. Dashboard zur Darstellung von Werten als Graphen, Drehinstrumente, Schalter, Lichtsignalen, etc.
4. Übersichtsseite in der bekannte und unbekannte Werte dargestellt werden, so eine Art TODO um einen Überblick des Reverse Engineerings zu bekommen und wo man noch arbeiten muss
5. Die Einstellungen können in einer lokalen Config-Datei gespeichert und geladen werden. Zusätzlich soll ein Share-Server (den ich selbst betreibe) die Möglichkeit bieten Settings mit anderen zu teilen

Hier mal ein Mockup (also noch ohne besondere Funktion) zum reinklicken und "fühlen" => https://mk4-wiki.denkdose.de/tools/caligraph/index.html

Habe mir jetzt doch noch ein eigenes Analyzer-Tool geschrieben (liegt im Github Repo bei)

UPDATE: Ich habe daraus nun ein eigenes Projekt gemacht und die Funktionalität massiv erweitert. Mehr dazu in einem eigenen Thema =>

Thema

LIN/CAN Analysetool "CaLiGraph"

Moin zusammen, beflügelt von meinem LIN-Sniffer auf ESP32 Basis und der dafür angefangenen LIN-Analyzer Tool Software habe ich das Projekt erweitert und programmiere nun einen LIN-Bus/CAN-Bus Analyzer.

Funktionale Anforderungen:

1. Verarbeiten, analysieren und visualisieren von Dump-Daten im "CANDUMP" (und später auch mal in anderen) Datenformat
2. Daten können aus Datei (Logdatei) gelesen, aber auch Live von einem Websocket geliefert werden (z.B. mein LIN-Sniffer Tool)
3. Mehrere Betriebsmodus:

…

Go4IT

22. Februar 2026 um 14:08

Servus aus BY