Moin in die Runde! Ich hab zwar schon versucht, etwas passendes zu finden, bin aber noch nicht auf den richtigen Beitrag gestoßen. Folgende Idee, bei der ich noch nicht so richtig weiter weiß... Bei Fahrzeugen mit Ambientebeleuchtung ist in den meisten Fällen die LED der LIN-Slave, welcher einen bestimmten Befehl in eine RGB-Farbe umwandelt. Es müsste doch also möglich sein, diesen Befehl separat zu lesen und mit entsprechendem IC weitere blinde Slaves (also Fahrzeug kennt diese nicht, sie lesen aber den Befehl einfach mit) zu programmieren, damit man beliebig viele weitere LED's ansteuern kann. Soll also heißen, ich möchte z.B. pro Tür ein IC verbauen, mit dem ich dann einer normales RGB-LED sage, welche Farbe sie jetzt ausstrahlt. Im speziellen Fall wäre es möglich, dass ich R G und B separat codieren und ansteuern kann, damit ich die einzelnen LIN-Befehle der Grundfarben schon mal habe. Es können in diesem Fahrzeug maximal 10 Farben hinterlegt werden, die per RGB-Wert codiert werden (VCDS, VW-Plattform). Ich kann also zwischen 0 und 255 für Rot, Blau und Grün angeben, der Master wandelt es in LIN um und die LED dann logisch wieder in RGB zurück. Ich habe nun auch schon einige Hersteller gefunden, die solche IC's anbieten, teilweise auch gleich mit der LED, bei denen sich die Industrie wohl auch bedient. Leider fehlt mir da noch das technische Know-How in der Programmierung. Ich bin aber nicht auf den Kopf gefallen, habe diverse Sachen mit Arduinos und Pi's umgesetzt und bin gewillt, bestimmt Sachen zu erlesen um sie zu verstehen. Mir würde hier also durchaus reichen, wenn man mir gewisse Richtungen vorgäben könnte, damit ich Ideen bekomme, wie ich das Ganze umsetzen kann. Meine Idee wäre nun folgende: Ich nehme einen Arduino oder Rasp-Pi mit entsprechendem Board und lese mir den LIN direkt an der LED aus. Mit VCDS fange ich mit jeder Farbe erstmal einzeln an, damit ich die Grundfarben habe, mache dann Mischfarben und speicher mir die einzelnen Datensätze ab. Wenn ich diese habe, nutze ich das Board, um den Befehl aus dem LIN per Befehl in eine RGB zu wandeln und an eine LED weiter zu geben. Da käme dann schon die erste Frage, falls das so überhaupt geht... Müsste hier jede LIN-Farbe per "if" an RGB weitergegeben werden oder gibt es da einen Algorythmus, der anhand von den R's, G's und B's errechnet, welcher Wert das aktuell genau ist? (Ich hoffe ihr versteht, was ich meine) Ich würde mich über Unterstützung freuen! Liebe Grüße Max
:
Bearbeitet durch User
Max W. schrieb: > Bei Fahrzeugen mit Ambientebeleuchtung ist in den meisten Fällen die LED > der LIN-Slave, welcher einen bestimmten Befehl in eine RGB-Farbe > umwandelt. > Es müsste doch also möglich sein, diesen Befehl separat zu lesen und mit > entsprechendem IC weitere blinde Slaves (also Fahrzeug kennt diese > nicht, sie lesen aber den Befehl einfach mit) zu programmieren, damit > man beliebig viele weitere LED's ansteuern kann Ja. Max W. schrieb: > Da käme dann schon die erste Frage, falls das so überhaupt geht Es geht, aber deine Frage zeigt, dass du es nicht hinbekommen wirst. Wünschen alleine reicht nicht, man muss auch (programmieren) können. Also das, was andere in der Zeit gelernt haben, als du dich um Autos gekümmert hast.
Max W. schrieb: > Müsste hier jede LIN-Farbe per "if" an RGB weitergegeben werden oder > gibt es da einen Algorythmus, der anhand von den R's, G's und B's > errechnet, welcher Wert das aktuell genau ist? Wenn du das LDF hast, geht's einfach. Könnte man in dem Fall bestimmt auch reverse engineeren. Vermutlich ist für R G B jeweils ein Byte in einem der LIN-Frames vorgesehen, das dann jeweils proportional zur Intensität der Grundfarben ist. Also einfach PWM draus machen oder der WS1812-Library übergeben. 256³ = 16777216 if-statements kannst du vergessen. Und was, wenn das noch zwischendurch mit der im Fahrzeugmenü einstellbaren Helligkeit der Ambientebeleuchtung verrechnet wird oder von Abblendlicht an/aus abhängig ist, werden dir deine 3 exakt definierten Lieblingsfarben nicht ausreichen. mfg mf
Max W. schrieb: > Soll also heißen, ich möchte z.B. pro Tür ein IC verbauen, mit dem ich > dann einer normales RGB-LED sage, welche Farbe sie jetzt ausstrahlt. Ein IC reicht da nicht. Zum ersten brauchst Du einen LIN-Transceiver, der aus dem Bus-Signal TX und RX für die uC macht. Da gibts dann auch welche, die gleich noch den Spannungsregler drin haben, um aus den 12V dr Busspannung 5V oder 3.3V für den uC zu machen. Dahier ist z.B. so einer: https://www.onsemi.com/download/data-sheet/pdf/ncv7428-d.pdf Der gibt bis zu 70mA an Strom raus. Viel zu wenig für einen Pi. Vergiss den einfach, der ist dafür nicht gedacht. LIN ist im Prinzip eine serielle Schnittstelle, aber mit ein paar Besonderheiten. Die klassischen Atmel-AVRs, die auch auf den meisten Arduinos drauf sind, kamen mit diesen Besonderheiten nicht gut zurecht. Die moderneren von Microchip haben extra LIN-Support in der Hardware und sind für Dein Vorhaben besser geeignet. Beispiel der hier: https://www.microchip.com/en-us/product/attiny3216 Der hat dann auch Timer und PWM-Ausgänge, mit denen Du Deine R, G, B LEDs dimmen kannst. Denke daran, insgesamt nicht über 70mA zu kommen. Wie das genau geht, liest Du am besten irgendwo nach. Ein Forum ist nicht der geeignete Ort für Grundlagenwissen, eher für kurze Detailfragen. Dann wirst Du den passenden LIN-Standard brauchen. Weißt Du, ob Dein Fahrzeug LIN 1.3 oder LIN 2.x benutzt? Danach richtet sich auch z.B. die Prüfsummenberechnung. Das mal so ganz kurz. fchk
Im ersten Moment würde ich Dir mal einen LIN-Analysetool anraten, damit Du überhaupt nachvollziehen kannst auf welcher ID was wie wo wann gesendet wird. Wenn ich das richtig verstanden habe kannst Du per VCDS Farben gezielt auslösen. Dann würdest Du sehen, wie das im Protokoll umgesetzt ist. Danach kann man weiter sehen. Fertige Bausteine, die direkt auf das Protokoll gemünzt sind, halte ich für unwahrscheinlich. Zum Analyse-Tool. Ich gehe mal nicht davon aus, dass Du viel Geld ausgeben möchtest für ein Profi-Tool. Auf Ali gibt es einen samt Software, ob der aber etwas taugt musst Du selber rausfinden. https://de.aliexpress.com/item/1005007460915625.html
Frank K. schrieb: > Die klassischen Atmel-AVRs, die auch auf den meisten > Arduinos drauf sind, kamen mit diesen Besonderheiten nicht gut zurecht. Du spielst vermutlich auf die Break-Erkennung an? Ich kann man nicht genau erinnern welche es war, aber ich habe das auf CPUs ohne LIN-Support schon so gemacht, dass ich gezielt auf den Empfang eines Bytes mit dem Wert 0 warte, welches gleichzeitig einen Frame-Error ausgelöst hat. Keine echte Break-Erkennung, funktionierte aber recht zuverlässig.
:
Bearbeitet durch User
Frank K. schrieb: > Zum ersten brauchst Du einen LIN-Transceiver, der aus dem Bus-Signal TX > und RX für die uC macht TX braucht er nicht, weil er nur mitlauschen möchte. Der antwortende LIN-Slave wird wohl am Bus belassen. Frank K. schrieb: > Weißt Du, ob Dein Fahrzeug LIN 1.3 oder LIN 2.x benutzt? Danach richtet > sich auch z.B. die Prüfsummenberechnung. Braucht er vielleicht empfangsseitig. Weil der TO die Farben per VCDS parametrieren kann (VAG "codieren" und andere OEMs "kalibrieren"), gehe ich mindestens von einem "Diagnoseklasse 3"-Steuergerät aus, wo auch die Parameter (Farben) gespeichert sind. Also sind die Farben nicht im EEPROM des LIN-Slave. Vielleicht noch als Anmerkung, LIN ist nicht standardisiert in Bezug auf die Dateninhalte, also kein Protokoll zur Lichtsteuerung wie z.B. DMX-512:1990... Max W. schrieb: > der LIN-Slave, Mitschnitte dessen Kommunikation bei einfachen Kombinationen der Grundfarben (z.B. nur rot, nur grün, nur blau, gelb, magenta, türkis, weiß und schwarz/aus) helfen beim reverse engineeren. mfg mf
Harald A. schrieb: > Keine echte Break-Erkennung, funktionierte aber recht zuverlässig. Yes. Der Frame-Error bei den Atmels gehorcht auf Stoppbit = 0. Zusammen mit den 55er Syncbytes und protected identifiern ist das wirklich gut genug 👍 Wenn man seinem Knoten einen Quarz spendiert, ist auch kein vermessen der Bitrate während der Syncbytes nötig... mfg mf
Und auf die Berechnung der Checksumme kannst Du für ein Bastelprojekt beim reinen Mitlesen auch verzichten. Im Grunde wäre es also nicht mal so schwer: Break erkennen, 0x55 prüfen, folgende ID korrekt? Falls ja, Folgebytes abzählen und verwerten. Falls nein, auf das nächste Break warten.
:
Bearbeitet durch User
Michael B. schrieb: > Wünschen alleine reicht nicht, man muss auch (programmieren) können. > Also das, was andere in der Zeit gelernt haben, als du dich um Autos > gekümmert hast. Stimmt! Aber du freust dich ja sicherlich auch, wenn man dir das ein oder andere erklärt, wenn es um dein Auto geht, oder? ;) Achim M. schrieb: > Wenn du das LDF hast, geht's einfach. > Könnte man in dem Fall bestimmt auch reverse engineeren. -LDF? > Vermutlich ist für R G B jeweils ein Byte in einem der LIN-Frames > vorgesehen, das dann jeweils proportional zur Intensität der Grundfarben > ist. Also einfach PWM draus machen oder der WS1812-Library übergeben. -WS2812 meinst du, oder? > 256³ = 16777216 if-statements kannst du vergessen. Und was, wenn das > noch zwischendurch mit der im Fahrzeugmenü einstellbaren Helligkeit der > Ambientebeleuchtung verrechnet wird oder von Abblendlicht an/aus > abhängig ist, werden dir deine 3 exakt definierten Lieblingsfarben nicht > ausreichen. -Dachte ich mir, deswegen ja direkt die Frage der Algorythmus oder vergleichbarem? Frank K. schrieb: > Dann wirst Du den passenden LIN-Standard brauchen. Weißt Du, ob Dein > Fahrzeug LIN 1.3 oder LIN 2.x benutzt? Danach richtet sich auch z.B. die > Prüfsummenberechnung. Nein, weiß ich leider nicht. Gibts Möglichkeiten das zu erkennen? Kann ein entsprechendes Analysetool das, anhand von bestimmten Datensätzen die vom Master kommen, erkennen? Frank K. schrieb: > Wie das genau geht, liest Du am besten irgendwo nach. Das werde ich machen! Harald A. schrieb: > Wenn ich das richtig verstanden habe kannst Du per VCDS > Farben gezielt auslösen. Das ist korrekt. Harald A. schrieb: > Fertige Bausteine, die > direkt auf das Protokoll gemünzt sind, halte ich für unwahrscheinlich Gibt es zumindest in der Theorie. Ich könnte zu Seat gehen, mir eine LED nachbestellen, die dann in Spanien fertig codiert zugeschickt wird. Kostenpunkt ca. 130€ für eine LED... Danke, Nein! Harald A. schrieb: > dass Du viel Geld > ausgeben möchtest Zumindest vorerst nicht. Wenn es auf halber Strecke scheitert, dann soll natürlich nicht zu viel Geld für so eine Spielerei verbrannt sein. Werde mir aber dein Tool von ALI mal angucken! Danke dafür!!! Achim M. schrieb: > TX braucht er nicht, weil er nur mitlauschen möchte. Der antwortende > LIN-Slave wird wohl am Bus belassen. So siehts aus. Achim M. schrieb: > Also sind die Farben nicht im > EEPROM des LIN-Slave. Wie interpretiert der Slave dann die Empfangenen Daten? Achim M. schrieb: > Vielleicht noch als Anmerkung, LIN ist nicht standardisiert in Bezug auf > die Dateninhalte Das ist klar. Ist ja auch kein Licht-Bus :P Achim M. schrieb: > Mitschnitte dessen Kommunikation bei einfachen Kombinationen der > Grundfarben (z.B. nur rot, nur grün, nur blau, gelb, magenta, türkis, > weiß und schwarz/aus) helfen beim reverse engineeren. Würde ich mir zutrauen und werde mir, wie geschrieben, das Tool vom ALI mal angucken und bestellen. Ist sonst jemand aus der Region Hannover hier unterwegs, der Zeit und Lust hätte, da etwas zu unterstützen? Ich bin da echt gewillt zu lernen!
Alles klar. Aktuell noch etwas Magie für mich, aber ich werde mir das Protokoll mal weiter verinnerlichen. Mir ist zumindest schon mal klar, was du meinst
Der Link auf die Software auf Baidu funktioniert übrigens. Da sind auch einige PDF als Installationsanleitung. Zwar alles auf Chinesisch aber durchaus nachvollziehbar. Ansonsten gibt es ja auch mittlerweile genügend Übersetzungsmöglichkeiten, Google Translator per Kamera auf dem Handy, Google Translate oder ChatGPT.
Frank K. schrieb: > Zum ersten brauchst Du einen LIN-Transceiver, der aus dem Bus-Signal TX > und RX für die uC macht. Es gibt auch SoCs, die das LIN-Interface gleich zusammen mit einem ARM-Core auf dem Chip haben, so wie die Autoindustrie sie nutzt.
Rainer W. schrieb: > Es gibt auch SoCs, die das LIN-Interface gleich zusammen mit einem > ARM-Core auf dem Chip haben, so wie die Autoindustrie sie nutzt. Na ja, nach seinem Eingangspost bzgl. geringer Kenntnisse (Arduino geht aber) würde ich mal nicht unbedingt einen solchen SoC empfehlen.
Harald A. schrieb: > Rainer W. schrieb: >> Es gibt auch SoCs, die das LIN-Interface gleich zusammen mit einem >> ARM-Core auf dem Chip haben, so wie die Autoindustrie sie nutzt. > > Na ja, nach seinem Eingangspost bzgl. geringer Kenntnisse (Arduino geht > aber) würde ich mal nicht unbedingt einen solchen SoC empfehlen. Weil deutlich komplizierter zu programmieren? Ich habe mir jetzt mal die beiden LIN-Datenblätter vorgenommen, damit ich besser verstehe, wie das ganze aufgebaut ist. Für mich mal als Verständnisfrage: Es gibt ja Bausteine wie einen Elmos E521.30, um den es sich sehr wahrscheinlich auch im Fahrzeug bei mir handelt. Zu bekommen bei bekannten Elektronikvertrieben ab minimum 3000 Stück. Kommt man an sowas auch in geringerer Stückzahl ran? Und ist es Sinnvoll, diesen Baustein für solch ein Projekt zu nutzen? Ich lese dann mal weiter im Datenblatt…
:
Bearbeitet durch User
Max W. schrieb: > Weil deutlich komplizierter zu programmieren? Da steht mal ganz allgemein "16 bit Microcontroller" - welcher das genau ist geht nicht hervor. Du kommst bei ELMOS als Privatkunde an keinerlei Infos (detaillierte Datenblätter, Programmierwerkzeuge etc.). Diesen Weg kannst Du komplett vergessen. > Kommt man an sowas auch in geringerer Stückzahl ran? Und ist es > Sinnvoll, diesen Baustein für solch ein Projekt zu nutzen? Kaum. Bleibe als Privatperson bei einem Controller, den Du kennst und nehme dann einfach APA102-LEDs, die gibt es in allen Größen und sind sehr einfach anzusteuern. Bei den allseits beliebten WS2812 musst Du schon wieder Klimmzüge beim Timing machen, wenn Du gleichzeitig LIN empfangen willst und ein ungestörtes Protokoll Richtung LED ausgeben musst - ist grundsätzlich möglich, würde ich mit deinen von Dir beschriebenen Vorkenntnissen lassen.
Max W. schrieb: > Bei Fahrzeugen mit Ambientebeleuchtung ist in den meisten Fällen die LED > der LIN-Slave, welcher einen bestimmten Befehl in eine RGB-Farbe > umwandelt. Die meisten Einkoppelelemente (z.B. Hella oder Dräxlmaier) haben vier Anschlüsse. KL15, Masse, LIN rein und LIN raus. Die Module sind in Reihe geschaltet und der LIN wird durchgeschleift. Nach dem Einschalten erfolgt eine Slave Node-Erkennung. Die LEDs reagieren erstmal alle auf die gleichen IDs und die Verbindung zum LIN out ist getrennt. So empfängt nur das erste Modul. Dem teilt man seine neue ID mit und aktiviert es, damit leitet es den LIN durch an das folgende Modul. Das wird ebenfalls konfiguriert, usw. > Es müsste doch also möglich sein, diesen Befehl separat zu lesen und mit > entsprechendem IC weitere blinde Slaves (also Fahrzeug kennt diese > nicht, sie lesen aber den Befehl einfach mit) zu programmieren, damit > man beliebig viele weitere LED's ansteuern kann. Weitere Slaves müssten passend konfiguriert werden. Du brauchst also ein aktives Gateway, das erst Deine Teilnehmer konfiguriert, dann den offiziellen LIN beobachtet und die Daten von dort zu Deinen Modulen sendet. > Es können in diesem Fahrzeug maximal 10 Farben hinterlegt werden, die > per RGB-Wert codiert werden (VCDS, VW-Plattform). Ich kann also zwischen > 0 und 255 für Rot, Blau und Grün angeben, der Master wandelt es in LIN > um und die LED dann logisch wieder in RGB zurück. Das EKE bekommt Farbnummer (Palette, nicht RGB) und Helligkeit. Es kann die Werte direkt übernehmen, oder in einer vorgegebenen Zeit von der alten Farbe auf die neue überblenden. Mach 100 Ohm in die LIN-Leitung und häng jeweils einen Tastkopf des Oszis davor und dahinter. So siehst Du, welche Bits vom Master kommen und welche vom Slave.
Soul E. schrieb: > Weitere Slaves müssten passend konfiguriert werden. Du brauchst also ein > aktives Gateway, das erst Deine Teilnehmer konfiguriert, dann den > offiziellen LIN beobachtet und die Daten von dort zu Deinen Modulen > sendet. Wenn er nur die gleiche Farbe an eine andere Stelle übertragen möchte kann er eine Botschaft parallel abhören und verwerten. Einbindung als neuer Teilnehmer ist doch völlig überzogen.
Harald A. schrieb: > Wenn er nur die gleiche Farbe an eine andere Stelle übertragen möchte > kann er eine Botschaft parallel abhören und verwerten. Einbindung als > neuer Teilnehmer ist doch völlig überzogen. Einen zweiten Strang parallel klemmen könnte klappen, wenn die Statusbotschaften einigermaßen gleich sind. Es antworten dann ja immer zwei Slaves, einer aus jeder Kette. Eventuell könnte man den zweiten Strang mit einer Diode im LIN auf Read-only stellen. Die Diode so einbauen, dass der dominante Pegel (low) vom Master zum Slave kann, aber nicht umgekehrt. Dann sieht der Master nur die Statusbits von den original verbauten EKE.
Angehängte Dateien:
https://www.amazon.de/gp/product/B0CFFGS5XF Kaufen, Software installieren, Masse und LIN anklemmen und lauschen. Reengineering. Wenn du das Protokoll verstanden hast, dann nimmst du dir einen STM32F103 (BluePill) + LIN Interface Chip (MCP2025 mit 3.3V an Board), stellst den UART des STM auf LIN ein und bist schon zu 50% am Ziel. Sieht dann so wie im Anhang aus, dass ist ein Mitschnitt von einer Webasto Thermo TopC, die nutzen zwar kein "genormtes LIN", aber das Prinzip ist fast gleich.
Soul E. schrieb: > Eventuell könnte man den zweiten Strang mit einer Diode im LIN auf > Read-only stellen. Warum möchtest Du eine Diode einsetzen? Mir wäre es in diesem Fall vollkommen egal, ob der Master oder ein Teilnehmer die Nachricht auf den Bus bringt. Den LIN-Transceiver (falls man den überhaupt verwendet) nur zum Lesen der Nachrichten verwenden, TX vollständig deaktivieren. Jetzt auf den Break, den Sync und die entsprechende ID warten und die Bytes der Nachricht auswerten. Er muss ja nicht einmal die Prüfsumme auswerten, denn hier wird kein wichtiges Bauteil gesteuert. Wenn es wirklich einmal für den Bruchteil einer Sekunnde aufgrund einer falschen Nachricht eine andere Farbe gibt (sowieso eher unwahrscheinlich) ist das kein Weltuntergang. Du scheinst dich ja auszukennen, da Du Hersteller benennst und Palette anstelle RGB in Spiel bringst. Weißt Du, wie die Farbinfo aufgebaut ist?
:
Bearbeitet durch User
Harald A. schrieb: > Warum möchtest Du eine Diode einsetzen? Mir wäre es in diesem Fall > vollkommen egal, ob der Master oder ein Teilnehmer die Nachricht auf den > Bus bringt. Dir schon, aber dem Master vielleicht nicht. Ich weiss nicht, ob das BCM die Statusworte der EKE liest und was es damit anstellt. Wenn da nun ein zweiter Strang danebenhängt, dann kommt bei unterschiedlichen Inhalten Datenmüll an. Wenn man dem Fremd-Strang das Senden verbietet, dann nimmt er die Konfigurationsdaten vom Master an, stört aber die Statusabfragen nicht. Bzgl Palettendefinition: ich weiss nicht, ob da jeder OEM was eigenes bekommt oder ob die Hersteller da mehr oder weniger Katalogteile verkaufen. Theoretisch könnte man über den LIN auch RGB oder YUV schicken. Umrechnen muss das Ding sowieso, denn da ist eine Temperaturkompensation und eine Weisspunkt-Kalibrierung drin. Sonst könnte man ja auch billige WS8211 nehmen, da sieht im Gurt jeder anders aus.
Ich denke wir reden letztlich über das Gleiche. Um eben Datenmüll zu verhindern sollte das zu bauende Gerät wie ein Analysetool nur auf dem Bus lauschen und keinem einzigen Bit ein Haar krümmen. Kann sein, dass es nicht perfekt wird (keine Statusrückmeldung, Weißabgleich, Temperaturkompensation etc.), aber darauf kommt es dem TE vermutlich garnicht an.
:
Bearbeitet durch User
Ich danke euch sehr für eure Gedankenanstöße! Ich werde mir jetzt den Logic Analyzer bestellen und dann mal Stück für Stück weiter schauen. Es waren bis hier auf jeden Fall sehr viele sehr kompetente und hilfreiche Antworten dabei und das ist wirklich sehr löblich und echt nicht selbstverständlich. Freut mich! Wenn ich wieder Hilfe brauche, würde ich dann gerne wieder auf euch zurück kommen. Ich denke in den nächsten 14 Tagen wird aber Funkstille sein, denn die Zeit ist momentan doch sehr eingeschränkt. Liebe Grüße
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.