CAN-BUS im F11 / F10

[Rostlöser135742]

Hallo liebe Gemeinde,

ich würde gerne bei meinem nächsten Projekt den CAN Bus abreifen und mit einer eigenständigen Hardware auslesen und mit eigener Software versehen.

OBD-BlueTooth resp. OBD Kabel möchte ich NICHT verwenden

Dazu benötige ich von euch ein paar Schlaumacher-Informationen.

Wer von euch hat zu den folgenden Punkten ggf. Links oder Tipps ?

a) Wo könnte ich bei einem F11 am schlausten (hinten) den Bus abgreiffen ?

b) Gibt es bei uns unterschiedliche Bus-Typen ? High / Low - Wenn ja - worauf ist zu achten ?

c) Gibt es technische Spezifikationen , die ich beim BMW Bus unbedingt beachten sollte ?

(nicht alle Hardwarelösungen aus den Netz sehen irgendwie Strahlungs/Störsicher aus.

An dieser Stelle erst mal lieben Dank

 

P.S Falls jemand von euch meinen sollte, ich würde etwas illegales basteln - keine Sorge :-)

Das Ergebnis wird hier eh zum nachbauen veröffentlicht

lg

Stefan

 

 

 

 

[atzebmw]

Na Stefan, läuft dein Rheingold etwa nicht? :)

Also ich hab jetzt mal so auf die Schnelle 2 Möglichkeiten gefunden.

Am AHM (Anhängermodul) und am Steuergerät HKL (Heckklappenlift) kommt der K-CAN2 an.

Aber ich kenne mich damit nicht aus.

Es gibt ja noch den K-CAN, den PT-CAN und den PT-CAN2.

[Rostlöser135742]

Moin Atze, doch läuft :-)

Du hast es auf den Punkt gebracht : Mir fehlen die Infos , welcher Bus, welcher Stecker genau, welche 2/3 Pins etc etc.

Und so wie ich das sehe , hilft mir ISTA-D auch nicht wirklich weiter, oder ich bin schlichtweg zu doof :-)

[gpanter22]

Warum willst du was eigenes Bauen ?

Reicht hier kein ENET oder ICOM aus ?

[atzebmw]

Zitat:

@swa00 schrieb am 12. Mai 2016 um 23:49:27 Uhr:

Moin Atze, doch läuft :-)

Du hast es auf den Punkt gebracht : Mir fehlen die Infos , welcher Bus, welcher Stecker genau, welche 2/3 Pins etc etc.

Und so wie ich das sehe , hilft mir ISTA-D auch nicht wirklich weiter, oder ich bin schlichtweg zu doof :-)

Aber genau das kann doch Rheingold/ISTA-D.

Ich hab als Suchbegriff einfach "CAN" eingegeben und da kamen schonmal einige Schaltpläne.

Beim K-CAN ist auch immer die gleiche Kabelfarbe (K_CAN_H ist or/gn und K_CAN_L ist gn).

So, und wenn du dann 2 Kabel von der Farbe gefunden hast, kannst du sie ja direkt irgendwo abgreifen.

PIN-Belegung sieht man auch dort.

[gpanter22]

Übersicht der Bus-Systeme

Prinzipiell werden zwei Gruppen von Bus-Systemen unterschieden:

-> Hauptbus-Systeme: Ethernet, FlexRay, K-CAN, K-CAN2, MOST, PT-CAN und PT-CAN2

-> Sub-BUS-Systeme: BSD, D-CAN (Diagnose-CAN), LIN, Local-CAN

Karosserie-CAN K-CAN

Der K-CAN ist für die Kommunikation der Bauteile mit geringer Datenübertragungsrate zuständig. Über das zentrale Gateway-Modul ist der K-CAN auch mit den anderen Bus-Systemen verknüpft. Einige Steuergeräte im K-CAN besitzen einen LIN-Bus als Sub-Bus. Der K-CAN hat eine Datenübertragungsrate von 100kBit/s und ist zweiadrig verdrillt (zwei verdrillte Adern) ausgeführt. Der K-CAN hat die Möglichkeit, im Fehlerfall als Eindrahtbus betrieben zu werden.

Karosserie-CAN2 K-CAN2

Der K-CAN2 ist für die Kommunikation der Steuergeräte mit hoher Datenübertragungsrate zuständig. Über das zentrale Gateway-Modul ist der K-CAN2 auch mit den anderen Bus-Systemen verknüpft. An allen Steuergeräten im K-CAN2 ist ein LIN-Bus als Sub-Bus angeschlossen. Der K-CAN2 hat eine Datenübertragungsrate von 500kBit/s und ist zweiadrig verdrillt ausgeführt.

Powertrain-CAN PT-CAN

Der PT-CAN verbindet die Motorsteuerung mit der Getriebesteuerung, aber auch Systeme im Bereich der Sicherheits- und Fahrerassistenzsysteme miteinander. Er ist linienförmig mit Stichleitungen zu den einzelnen Systemen aufgebaut. Der PT-CAN hat eine Datenübertragungsrate von 500kBit/s und ist zweiadrig verdrillt ausgeführt.

Powertrain-CAN2 PT-CAN2

Der PT-CAN2 bildet eine Redundanz zum PT-CAN im Bereich der Motorsteuerung und dient auch der Signalübermittlung an die Kraftstoffpumpensteuerung. Der PT-CAN2 hat eine Datenübertragungsrate von 500kBit/s und ist zweiadrig mit zusätzlicher Wake-up-Leitung ausgeführt.

Ethernet

Ethernet ist eine herstellerneutrale, kabelgebundene Netzwerktechnologie. Als Übertragungsprotokolle werden die Protokolle TCP/IP (Transmission Control Protocol/ Internet Protocol) und UDP (User Datagramm Protocol) verwendet.

FlexRay

Mit einer maximalen Datenübertragungsrate von 10 MBit/s pro Kanal ist FlexRay deutlich schneller als die bisher in Kraftfahrzeugen eingesetzten Datenbusse im Bereich Karosserie und Antrieb/Fahrwerk. Das zentrale Gateway-Modul stellt die Verbindung zwischen den verschiedenen Bus-Systemen und dem FlexRay her. Je nach Ausrüstungsstand des Fahrzeuges sind im ZGM ein oder zwei so genannte Sternkoppler mit jeweils vier Bustreibern vorhanden. Die Bustreiber leiten die Daten der Steuergeräte über den Communication-Controller zum zentralen Gateway-Modul (ZGM) weiter. Die deterministische Datenübertragung stellt sicher, dass jede Botschaft im zeitgesteuerten Teil in Echtzeit übertragen wird. Echtzeit bedeutet, dass die Übertragung in einer festgelegten Zeit erfolgt.

MOST-Bus-System

MOST ist eine Datenbustechnologie für Multimedia-Anwendungen. Der MOST-Bus nutzt Lichtimpulse zur Datenübertragung und ist in Ringstruktur aufgebaut. Die Datenübertragung im Ring findet dabei nur in eine Richtung statt. Nur das zentrale Gateway-Modul kann einen Datenaustausch zwischen dem MOST-Bus und anderen Bus-Systemen realisieren. Als Master-Steuergerät fungiert der Car Information Computer, das Gateway zum restlichen Bus-System ist das zentrale Gateway-Modul.

[gpanter22]

Zentrales Gateway-Modul (ZGM)

Das zentrale Gateway-Modul (ZGM) verknüpft die Haupt-Busse miteinander. Ein Haupt-Bus ist beispielsweise der FlexRay, MOST oder K-CAN. Somit ermöglicht die Gateway-Funktion des zentralen Gateway-Moduls einen Datenaustausch zwischen den unterschiedlichen Bus-Systemen.

Wenn das Diagnosesystem über D-CAN (Diagnose-on-CAN) angeschlossen ist, übersetzt das zentrale Gateway-Modul die Anfragen des Diagnosesystems an die internen Busse. Die Antworttelegramme durchlaufen den Prozess in der umgekehrten Richtung.

 

Folgende Funktionen des zentralen Gateway-Moduls (ZGM) werden beschrieben:

Synchronisierung

Um in vernetzten Steuergeräten die synchrone Ausführung einzelner Funktionen zu realisieren, ist eine gemeinsame Zeitbasis notwendig. Da alle Steuergeräte intern mit einem eigenen Taktgenerator arbeiten, muss der Zeitabgleich über den Bus erfolgen. Beim Aufstartvorgang des zentralen Gateway-Moduls fungieren einige Steuergeräte (ZGM, DSC, ICM und DME/DDE) als Synchronisationsknoten. Zur fehlerfreien Synchronisierung des FlexRay ist die Kommunikation vom ZGM zu mindestens 2 der Steuergeräte notwendig. Wenn z. B. die DSC ausgefallen ist, werden die Steuergeräte ICM und DME/DDE als Synchronisationsknoten verwendet. Wenn der FlexRay fehlerhaft ist, müssen unbedingt die Busleitungen der Steuergeräte ZGM, ICM, DSC und DME/DDE überprüft werden.

Fahrzeug Konfigurationsmanagement

Für die Fahrzeugkonfiguration ist im zentralen Gateway-Modul eine Systemfunktion integriert. Diese Systemfunktion hat die Hauptaufgabe, bestimmte Daten (z. B. Fahrzeugauftrag, Fahrzeugprofil, Integrationsstufe) zentral im Fahrzeug abzulegen. Der Fahrzeugauftrag und die Integrationsstufe werden zusätzlich noch im CAS-Steuergerät abgelegt. Somit ist sichergestellt, dass die Information wiederherstellbar ist, wenn das zentrale Gateway-Modul getauscht wurde. Auf Aufforderung vom Diagnosesystem bzw. fahrzeuginternen Systemfunktionen können die in der Fahrzeugkonfiguration gespeicherten Informationen über Diagnosebefehle abgerufen werden.

Zentraler Fehlerspeicher

Die Aufgabe dieser Teilfunktion ist die zentrale Ablage von Check-Control-Meldungen, zusätzlich zu den lokalen Fehlerspeichern der einzelnen Steuergeräte. Das zentrale Gateway-Modul (ZGM) ist der Master für diese Funktion und wird auch Diagnose-Master genannt.

Aufstarten und Herunterfahren des Kommunikationsbordnetzes

Das Fahrzeug-Zustandsmanagement beschreibt das Aufstarten und Herunterfahren des Kommunikationsbordnetzes. Neben allgemeinen Anforderungen, die für alle Steuergeräte verbindlich sind, werden die Kaskadierung (gleichzeitiges Aufstarten und Herunterfahren aller Busse im Bordnetz) und der Weckspeicher und Einschlafspeicher definiert.

Kaskadierung

Die Funktion Kaskadierung stellt sicher, dass alle Busse im Fahrzeugbordnetz koordiniert aufstarten und gleichzeitig herunterfahren ("einschlafen"). Dazu gibt es im zentralen Gateway-Modul (ZGM) eine Masterfunktion, die bestimmt, ob das Fahrzeugbordnetz einschlafen darf. Diese Masterfunktion steuert die so genannten Slaves, die jeweils für einen Bus das Aufstarten und Einschlafen verantworten. Die Slaves befinden sich z. B. in folgenden Steuergeräten:

- Zentrales Gateway-Modul (ZGM), z. B. für die Busse K-CAN, K-CAN2, PT-CAN, FlexRay und MOST

 

- Digitale Motor Elektronik (DME), z. B. für den PT-CAN2

 

Weckspeicher und Einschlafspeicher

Wenn das Fahrzeug nicht korrekt aufwacht oder einschläft, führt dies meist zu einem erhöhten Strombedarf des Gesamtfahrzeugs. Das kann unter Umständen zu einer leeren Batterie und damit zu einem Liegenbleiber führen. Das Fahrzeug Zustandsmanagement stellt mit dem Weckspeicher und Einschlafspeicher Funktionen zur Verfügung, um fehlerhafte Aufwach- und Einschlafvorgänge zu detektieren und Gegenmaßnahmen zu ergreifen.

Hierzu hat das Fahrzeug Zustandsmanagement zunächst alle möglichen Gründe erfasst, die dazu führen dürfen, dass ein Steuergerät das Fahrzeug wecken darf. Wenn ein solcher Grund vorliegt, so muss das weckende Steuergerät diesen Grund an den Weckspeicher und Einschlafspeicher melden, der im ZGM enthalten ist. Wenn ein fehlerhaftes Wecken vorliegt, wird dies im ZGM protokolliert (Fehlerspeichereintrag, der unter anderem das weckende Steuergerät und den Weckgrund als Umweltbedingungen enthält). Als weitere Umweltbedingungen werden immer die Uhrzeit und der aktuelle Kilometerstand gespeichert. Das ZGM ergreift in diesem Fall Gegenmaßnahmen, in dem es den Power-Down-Befehl versendet. Wenn danach weiterhin fehlerhafte Weckvorgänge passieren, wird ein Reset der Klemme 30F und danach ein permanentes Abschalten der Klemme 30F angefordert.

Ebenso wie beim Wecken kann es auch beim Einschlafen zu Fehlern kommen. Auch bei solch einem Fehler erstellt der Weckspeicher und Einschlafspeicher einen Fehlerspeichereintrag und ergreift die gleichen Maßnahmen wie bei fehlerhaftem Wecken. Alle Steuergeräte, die das Fahrzeug wecken dürfen, sind definiert und mit einer Identifikationsnummer versehen (hexadezimale Zahl).

Jedes Steuergerät, das weckt, sendet 2 Sekunden nach dem Weckvorgang eine Botschaft an das ZGM. Mit dieser Botschaft wird dem ZGM der Grund für das Wecken mitgeteilt (Beispiel Fußraummodul beim Wecken über Öffnen der Fahrertür: Weckursache "Türkontakt vorn links").

Aktivierung des Zugangs Ethernet

Der Zugang Ethernet ist im normalen Betrieb im deaktiviert. Vor jeder Nutzung muss dieser Zugang aktiviert bzw. nach Benutzung wieder deaktiviert werden. Durch Anstecken des ICOM A wird die Aktivierungsleitung (Pin 8) mit der Klemme 30B (Pin 16) verbunden und somit der Zugang Ethernet aktiviert. Dabei erhält der Baustein für das Ethernet im zentralen Gateway-Modul (ZGM) das Signal (Spannungspegel der Klemme 30B) über die Aktivierungsleitung. Durch Abstecken des ICOM A von der Diagnosesteckdose wird der Zugang Ethernet deaktiviert.

Jeder Teilnehmer in einem Ethernet hat eine weltweit eindeutig vergebene Identifikationsnummer, die MAC-Adresse (Media Access Control). Über die MAC-Adresse ist ein Teilnehmer in einem Netzwerk eindeutig identifizierbar. Die MAC-Adresse des Fahrzeugs befindet sich im ZGM und kann nicht geändert werden.

Die Fahrgestellnummer identifiziert das Fahrzeug gegenüber dem BMW Programmiersystem. Bevor die Kommunikation mit dem Fahrzeug stattfinden kann, ist es notwendig, dass jedes Gerät in einem IP-basierten Netzwerk eine logische Identifikation die so genannte IP-Adresse erhalten hat. Die IP-Adresse ist nur im jeweiligen Netzwerksegment (Subnetz) eindeutig und kann dynamisch oder statisch vergeben werden. Nach dem Aktivieren der Verbindung über Ethernet und der Herstellung der physikalischen Verbindung bekommt das zentrale Gateway-Modul vom ICOM A die IP-Adresse zugewiesen. Durch ein spezielles Verfahren, der so genannten "Fahrzeugidentifikation", werden zwischen Diagnosesystem oder Programmiersystem und ZGM die IP-Adresse, Fahrgestellnummer und MAC-Adresse ausgetauscht. Dabei kann das Fahrzeug im Werkstattnetzwerk eindeutig identifiziert werden und damit auch eine Kommunikationsverbindung aufgebaut werden.

Die Funktion einer IP-Adresse in einem Netzwerk entspricht einer Rufnummer im Telefonnetz. Die Zuteilung dieser IP-Adresse erfolgt per DHCP (Dynamic Host Configuration Protocol). Dies ist ein Verfahren zur automatischen Vergabe von IP-Adressen an neue Endgeräte in einem Netzwerk. Am Endgerät muss lediglich der automatische Bezug der IP-Adresse eingestellt sein. Für den Betrieb in wechselnder Werkstatt-Netzwerkinfrastruktur muss die IP-Adresse dynamisch zugeordnet werden können (DHCP-Server). Das Fahrzeug soll sich an das Netzwerk anpassen und nicht das Netzwerk an das Fahrzeug. Nach Abstecken des ICOM A wird die vergebene IP-Adresse nach Ablauf der im DHCP-Server eingestellten Zeit wieder frei. Über den Zugang Ethernet gelangen die Daten ins Fahrzeug und werden über das zentrale Gateway-Modul im Fahrzeug verteilt. Der Anschluss Ethernet beeinflusst die Funktionsweise und Zeitverhalten des D-CAN-Anschlusses nicht.

Ein gleichzeitiger Betrieb von D-CAN und Zugang Ethernet muss vermieden werden. Durch einen gleichzeitigen Betrieb sind Kollisionen der Diagnosekommandos innerhalb des Fahrzeugs wahrscheinlich. Damit kann die Kommunikation über beide Zugänge gestört werden.

Die Programmierung wird immer über den Zugang Ethernet durchgeführt. Über D-CAN erfolgt nur die Diagnose, aber keine Programmierung. Die Verbindung zum Fahrzeug muss erhalten bleiben, bis die Programmierung vollständig abgeschlossen ist. Das ZGM übernimmt die Gateway-Funktion und verteilt die Daten über die Busse an die anderen Steuergeräte.

Aus Gründen des Manipulationsschutzes ist im zentralen Gateway-Modul ein so genanntes Master Security Modul eingebaut. Des Weiteren sind in einigen ausgewählten Steuergeräten (z. B. Car Information Computer, Instrumentenkombination, Head-Up Display, Controller) so genannte Client Security Module eingebaut. Das Master Security Modul sendet periodisch Anfragen an die einzelnen Client Security Module. Eventuelle Störungen und Abweichungen werden dokumentiert und der Zentrale der BMW AG bei der Übertragung der FASTA-Daten via JETstream beim Service mitgeteilt. Dem Servicemitarbeiter ist es nicht möglich, auf die im Steuergerät gespeicherten Informationen bezüglich Manipulation via Diagnosesysteme zuzugreifen.

Anschluss Diagnosesystem

Das Ethernet wird erst mit dem Einstecken des Diagnosesteckers aktiviert. Im Diagnosestecker ist zwischen Pin 8 und Pin 16 eine Brücke. Die Brücke schaltet die Spannungsversorgung für den Ethernet-Controller im zentralen Gateway-Modul. Das heißt: Der Zugang Ethernet zum zentralen Gateway-Modul ist im Fahrbetrieb beim Kunden deaktiviert. Die Verbindung über Ethernet zwischen den Informationssystemen und den Kommunikationssystemen ist dauerhaft aktiviert.

Jeder Teilnehmer in einem Ethernet hat eine individuell vergebene Identifikationsnummer, eine MAC-Adresse (Media Access Control). Über diese Adresse und die VIN (Vehicle Identification Number) identifiziert sich das Fahrzeug gegenüber dem BMW Programmiersystem beim Verbindungsaufbau. Eine Änderung der Datensätze und Speicherwerte durch Dritte wird somit vermieden. Wie auch bei einem Computer Netzwerk im Büro muss jedes Gerät in einem Netzwerk eine eindeutige Identifikation erhalten. Nach dem Verbindungsaufbau bekommt deshalb das zentrale Gateway-Modul vom Programmiersystem eine so genannte IP-Adresse zugewiesen. Die Funktion einer IP-Adresse in einem Netzwerk entspricht einer Rufnummer im Telefonnetz. Die Zuteilung dieser IP-Adresse erfolgt per DHCP (Dynamic Host Configuration Protocol). Dies ist ein Verfahren zur automatischen Vergabe von IP-Adressen an Endgeräte in einem Netzwerk.

Abschlusswiderstände

Abhängig von der Fahrzeugausstattung sind im zentralen Gateway-Modul (ZGM) so genannte Sternkoppler mit Bus-Treibern vorhanden. An diesen Bus-Treibern sind die FlexRay-Steuergeräte angeschlossen.

Beim FlexRay werden zur Vermeidung von Reflexionen an beiden Enden der Datenleitungen Abschlusswiderstände eingesetzt. Wenn an einem Bus-Treiber nur ein Steuergerät angeschlossen ist, sind die Anschlüsse am Bus-Treiber und am Steuergerät jeweils mit einem Abschlusswiderstand versehen. Wenn der Anschluss am Steuergerät nicht der physikalische Endknoten ist, müssen die beiden Komponenten an den Enden des jeweiligen Buspfads mit Abschlusswiderständen versehen sein. Die Abschlusswiderstände im K-CAN2 befinden sich z. B. im zentralen Gateway-Modul und in der Junction-Box-Elektronik. Die Abschlusswiderstände für den D-CAN befinden sich im zentralen Gateway-Modul und im Diagnosestecker (kabelbaumseitig).

Sollkonfiguration des MOST-Rings

Die Sollkonfiguration des MOST-Rings (= eingebaute Steuergeräte in ihrer Reihenfolge im MOST-Ring) ist in der Headunit und im zentralen Gateway-Modul (ZGM) hinterlegt. Wenn ein Steuergerät nachgerüstet wird oder das zentrale Gateway-Modul beziehungsweise der Car Information Computer erneuert werden, muss die Sollkonfiguration neu gespeichert werden. Die Sollkonfiguration wird mit der Programmierung durchgeführt. Im Falle eines Ringbruchs ist es dann möglich, über die Sollkonfiguration herauszufinden, zwischen welchen Steuergeräten die Unterbrechung vorliegt.

Jedes MOST-Steuergerät kann Daten im MOST-Bus versenden. Nur das zentrale Gateway-Modul (ZGM) kann einen Datenaustausch zwischen dem MOST-Bus und anderen Bus-Systemen realisieren. Dabei fungiert die Headunit als Master-Steuergerät. Das Gateway zum restlichen Bus-System ist das zentrale Gateway-Modul.

 

[gpanter22]

Das ganze ist aufgebaut wie ein Netzwerk und ich glaube nicht das man hier selber was auf die schnelle bauen kann. Wenn man mit Rheingold den FS ausliest dann sieht man alle SG und deren Vernetzung und ganz unten ist die Legende für K CAN , F CAN usw.

[fredicoelbe]

Danke an gpanter22 für das Lehrbuch über die BMW Bussysteme.

Ist schon interessant zu lesen, wie in unser fahrenden IT-Maschine alles zu zusammen hängt.

Ja, früher gab es im Fahrzeug nur Kupferleitungen mit Gleichstrom, da konnte man mit dem Prüflämpchen noch arbeiten.

Wobei für mich das Arbeiten mit Laptop am FZ interessanter ist.

Gruß Manfred

[Rostlöser135742]

Guten Morgen zusammen

@gpanter22 :

Vielen lieben Dank für die ausführliche Erklärung , ich hätte jetzt nicht mit so einer Länge gerechnet :-)

Zu Erklärung und damit auch zur Beantwortung deiner Fragen : Derzeit habe ich eh schon einen Raspberry verbaut , in dem ich einen C++ deamon laufen habe und einen WLAN Access Point betreibt. Dieser Rapberry stellt z.Z nur die Daten einer externen GPS USB Antenne zur Verfügung (Bei meiner Kiste ist nur hinten an der Heckscheibe GPS empfang möglich)

Aus diesem Grunde kam ich auf die Idee , den CAN-BUS und ausgewählte Datensätze auch zur Verfügung zu stellen - Interfaces hierzu gibt es ja genügend .

Das hätte den Vorteil, dass ich nicht direkt am OBD stecker abgreiffen muss, resp. ständig einen OBD-Bluetooth adapter mit dem üblichen Standard Pairing passwort 1234 im Wagen lassen muss.

Die Anwendungsmöglichkeiten wären dann eigentlich sehr vielfältig.

Ich denke da in erster Line an ein GPS Tracking/Ortungs system mit Notify Funktion in der WakeUp-Phase oder Fahrzeugüberwachung .....

Im Moment habe ich allerdings meinen "Respekt" davor , irgendwelche Käbelchen (gerade bei der durchsatzgeschwindigkeit) einfach auf dem Bus zu patchen und hoffen, dass das erworbene Interface mir nicht irgend einen Mist auf den gesamten Bus einspeist.

Alternative dazu wäre natürlich , eine zweite OBD Buchse im Heck noch zu verbauen und mit dem RJ45 Adapter zu arbeiten. Wahrscheinlich die sicherste Variante

 

@atzebmw:

Siehste , sagte ich doch , ich bin zu doof - ich schau mir das nachher nochmal an. :-)

lg

Stefan

[gpanter22]

Also willst du in dem bereich GPS Ortung und Diebstahl was machen ?

[Rostlöser135742]

Zitat:

@gpanter22 schrieb am 13. Mai 2016 um 10:41:56 Uhr:

Also willst du in dem bereich GPS Ortung und Diebstahl was machen ?

JAIN, Ausgangslage war lediglich , einen GPS empfang im Fahrzeug zu realisieren um damit im Fond die Möglichkeit zu besitzen , "POI-Apps" zu benutzen . Wie erwähnt , ausser an der Heckscheibe , war kein Empfang möglich.

Das Ganze wird derzeit mit einer (selbst entwickelten) erweiterten App ausgewertet.

Nun habe ich das Ganze noch weiter gesponnen und ein Echzeit-Tracking realisiert ( das Auto telefoniert alle 5 Sekunden nach Hause (via i-Net, verschlüsselt etc & bla bla))

Nächster Punkt war dann , den Wakeup-Status des Fahrzeuges abzufangen und einen stummen Alarm incl. Ortungstracking zu realisieren und auch nach Hause zu schicken.

Aus diesem Grund wäre es natürlich recht praktisch, den Bus nach den verschiedenen Stati abzufragen.

Bis dato bleiben mir nur die 12 V übrig die nach dem Wakeup anliegen.

Funktionsweise wird dann auch bei abgeklemmter Batterie (mit Akku) sicher gestellt - bis die Jungs das schwarze Kästchen dann auch gefunden haben :-)

Bin ich dann mal am Bus dran , kann man natürlich auch die "anderen" Daten des Fahrzeuges an die App schicken .

Sinn und zweck ist dann eigentlich jedem Nutzer selbst überlassen. Codierung soll natürlich nicht erfolgen - das Überlasse ich lieber Olli :-)

P.S : Wen es interessiert : derzeitiger Status des Projektes , alles noch alpha .. da reines Freizeit-Vergnügen - ein paar Bilder der Layouts

 

 

 

 

 

 

[Horst696]

Frage zum K-CAN:

Wenn ein Steuergerät vFl mit K-CAN1 angeschlossen war und LCI mit K-CAN2, ist es dann egal welches Steuergerät ich nehme und muss nur auf den Bus achten?

Im Detail geht es um das AHM (A36). Das war vFl auf dem Grün/GrünOrangen K-CAN1 mit 100kBit und beim LCI auf dem Gelb/Roten und Gelb/Braunen K-CAN2 mit 500kBit.