RaspberryPi/ESP8266/ESP32 an OBD/Can-Bus

[nemesis03]

Hallo zusammen,

 

ich werde mich in nächster Zeit mit der Möglichkeit beschäftigen, einen Raspberry Pi oder später einen ESP8366 oder ESP32 an den VW Bus anzuschließen und wollte fragen, ob es hier im Forum Mitstreiter, bzw. weitere interessierte gibt. Evtl. hat auch schon mal jemand so ein Projekt angefangen.

 

Ziel des Projekts ist es mit dem zusätzlichen Gerät (Komfort-) Verbesserungen zu ermöglichen. Meine Liste an ggf. geplanten Optimierungen umfasst aktuell folgende Punkte:

• Verbesserung Start-Stopp-System: Hier ist geplant, dass die Start-Stopp-Automatik standardmäßg aktiviert ist. Wenn man dann hält (z.B. an einer roten Ampel) und weiß, dass man länger steht, kann man eine Taste drücken (z.B. die "OK"-Taste am Multifunktionslenkrad). Über den Can-Bus wird erkannt, dass die Taste gedrückt wird und das Auto auf Aktivierung des Start-Stopp-Systems wartet. Das Start-Stopp-System wird dann aktiviert und der Motor geht aus. Nach dem Losfahren wird das Start-Stopp-System wieder deaktiviert.
• Stop and Go mit Standzeit bis 3 Minuten: Beim T6.1 mit DSG kann das ACC ja Follow to Stop, jedoch muss dann nach ca. 3 Sekunden die Bremse betätigt, da sonst ACC deaktiviert wird und das Auto losrollt. Dies kann man umgehen, indem man wiederholt die "RES"-Taste am Multifunktionslenkrad drückt (ca. 1 Mal pro Sekunde). Dadurch wird das Fahrzeug durch das ABS für 3 Minuten im Stand gehalten, bevor sich das ACC deaktiviert. Da es etwas nervig ist ca. 1 Mal pro Sekunde die "RES"-Taste zu drücken, könnte man dies ggf. über den Can-Bus simulieren.
• Automatische Reaktivierung der Kindersicherung für die Schiebetür: Die Kindersicherung für die Schiebetür kann über einen Taster an der Fahrertür aktiviert und deaktiviert werden. Leider fehlt eine Funktion, dass man die Kindersicherung einmalig deaktiviert (z.B. damit ein Erwachsener hinten mit dem Kind aussteigen kann) und die Kindersicherung nach dem Schließen der Tür wieder aktiviert ist.
• Akustische Warnung bei Geschwindigkeitsüberschreitung von z.B. 15 km/h: Im Bus kann man bei der Warnung für die Geschwindigkeitsüberschreitung nur ein Offset von 0, 5 oder 10 km/h einstellen.
• pACC Speicherung des Geschwindigkeits-Offsets je nach Geschwindigkeitsbegrenzung: leider unterstützt der ACC-Sensor im T6.1 bei Aktivierung des prädigtiven ACC nicht, die Speicherung der gewünschten Geschwindigkeit pro Geschwindigkeitsbegrenzung (also z.B. wenn 50km/h erlaub ist, fahre 55km/h). Evtl. könnte man ein entsprechendes Verhalten über dan Can-Bus simulieren, indem man bei einem Wechsel der Geschwindigkeitsbegrenzung über die Simulation eines Tastendrucks am Multifunktionslenkrad die Geschwindigkeit einstellt.
• Manuelles Aufheben einer Geschwindigkeitsbegrenzung: Leider kennt die Verkehrszeichenerkennung von VW das Zusatzschild "für X Meter" bei Geschwindigkeitsbegrenzungen nicht, sodass die Verkehrszeichenerkennung nach einer Tempo 30 Strecke noch sehr lange denkt, dass weiterhin Tempo 30 gilt. Hier wäre es schön, die Geschwindigkeitsbegrenzung manuell aufheben zu können. Da habe ich aber noch keine gute Idee, wie man das umsetzt.
• Steuerung der Camping-Lichter: Soll ein Ein- und Ausschalten sowie Dimmen der Camping-Lichter ermöglichen, ggf. könnte man das auch mit einer kleinen Hausautomatisierungszentrale wie Home Assistant verknüpfen. Prinzipiell hat VW ja bereits ein Steuergerät für Sonderfahrzeuge mit WLAN-Unterstützung, dies wurde aber scheinbar noch nicht großflächig verbaut.
• Steuerung des Trennrelais: Aktuell hat man wenig Einfluss auf die Schaltung des Trennrelais. Dies hat zur Folge, dass die Aufbaubatterie auch mit zum Rekuperieren genutzt wird und z.B. bei einer anstehenden Dieselpartikelfilter-Regeneration zusammen mit der Starter-Batterie entladen wird (auch wenn "Max Laden" aktiviert ist. Hier wäre es schön selber einstellen zu können, dass das Trennrelais z.B. nur geschlossen wird um die Camping-Batterie bei einer Fahrt aufzuladen und wenn eine Dieselpartikelfilter-Regeneration ansteht das Trennrelais auf jeden Fall geöffnet wird.
• Steuerung der Seitenspiegel: Hier könnte man z.B. ein Absenken des rechten Spiegels beim Einparken programmieren oder eine automatisch Anpassung auf den Fahrer (das scheint bei VW ja nur zu gehen, wenn man die elektrisch verstellbaren Sitze, bzw. das zugehörige Steuergerät hat.
• Protokollierung von Daten: Da es viele Daten gibt, kann man auch viel Protokollieren und dann ggf. später auswerten...

 

Für den Zugang zum Can-Bus gibt es mehrere Optionen:

• Diagnose-Can über OBD2-Schnittstelle: Dies ist der einfachste Zugang, da am einfachsten zugänglich. Aktuell verwende ich hier ein Splitter-Kabel, sodass ich über meinen Raspberry Pi mitlesen kann, welche Daten der OBDeleven-Stick mit dem Fahrzeug austauscht. Nachteil ist hier, dass das Gateway als Filter zwischengeschaltet ist. Man kann aber über das UDS-Protokoll die Steuergeräte abfragen. Für mache Aktionen muss dann z.B. die Motorhaube entriegelt sein.
• Über einen Zwischenstecker am Gateway: Am Gateway laufen sehr viele der verschiedenen Can-Busse zusammen, insofern ist es eine gute Stelle um direkt auf einen oder mehrere Can-Busse zuzugreifen. Dafür gibt es auch fertige Kabel zu kaufen ("Can Bus Gateway Adapter" oder "Canbus Gateway Splitter"). Leider ist das Gateway schwer zugänglich, dafür müsste man den Schalttafeleinsatz ausbauen.
• Über einen Zwischenstecker am Steuergerät für Sonderfahrzeuge: Auch hier laufen mehrere Can-Busse zusammen (Motor-Can, Komfort-Can und Extended-Can). Hier ist der Vorteil, dass das Steuergerät am Sicherungskasten links unterhalb des Lenkrads sitzt und man an den Stecker direkt rankommt. Es sieht auch so aus, als hätte der Stecker die gleiche Größe wie der am Gateway, sodass man die oben erwähnten Adapterkabel nach eine Modifikation hier verwenden kann. Hierfür muss das Adapterkabel umgepinnt werden, da die Can-Busse hier auf anderen Pins sind. Ob dies wirklich funktioniert, muss ich noch testen.
• Andere Stellen: Natürlich gibt es noch viele andere Stellen, so man auf den Can-Bus zugreifen kann. Falls jemand da noch gute Ideen hat, gerne melden.

 

Momentan lese ich mit dem Raspberry Pi mit, wie der OBDeleven Stick mit dem Fahrzeug kommuniziert. Die Befehle kann man dann selber über den Raspberry Pi senden um damit Daten abzufragen. Es gibt auch Python-Bibliotheken, die dies erleichtern können. Perspektivisch würde ich manche der Optimierungen eher über einen ESP8266 oder ESP32 laufen lassen, finde aber zum Entwickeln den Raspberry Pi angenehmer/flexibler.

 

So jetzt zu den Fragen:

• Hat hier schon mal jemand etwas in diese Richtung entwickelt oder Lust sich zu beteiligen?
• Die Daten, die man per UDS abfragen kann, muss man ja noch interpretieren. Hierfür scheint es ODX-Dateien zu geben, die einem sagen, welches Bit was bedeutet. Diese werden z.B. auch von OBDeleven genutzt. Leider habe ich online noch keine Quelle gefunden, wo man diese Dateien bekommen kann. Hat hier jemand einen Tipp?

 

[nemesis03]

Kurzer Zwischenbericht: Der Zugriff über den Stecker am Steuergerät für Sonderfahrzeuge funktioniert wunderbar. Ich hatte zwei CAN-Bus-Kabel bei aliexpress bestellt, ca. 13 Euro pro Stück (damit deutlich günstiger als deutsche Anbieter). Bei dem Kabel werden nur drei CAN-Busse nach draußen geführt, aber am Steuergerät für Sonderfahrzeuge liegen sowieso nur drei CAN-Busse an.

 

Kabel original (es werden auch drei kleine Stecker mitgeliefert, mit denen man sich dann mit den CAN-Bussen verbinden kann):

You do not have the required permissions to view the image content in this post.

 

Kabel nach dem Umbau für das Steuergerät für Sonderfahrzeuge:

PIN 1: Komfort-CAN high

PIN 2: Komfort-CAN low

PIN 3: Motor-CAN high

PIN 4: Motor-CAN low

PIN 11: Extended-CAN high

PIN 12: Extended-CAN low

PIN 7: LIN-Bus, Verbindung zu Batterieüberwachung 2. Batterie und Wechselrichter

PIN 17: LIN-Bus, Verbindung zu Batterieüberwachung 3. Batterie (habe ich nicht, Kabel gibt es bei mir trotzdem

 

Zwei von den jetzt übrig gebliebenen Kabeln nutze ich als Verbindung zu meinem CAN-Modul (MCP2515), im Bild nach links gehend:

 

Auto original (es geht um den rechten, schwarzen Stecker in der unteren Reihe):

 

Der Stecker aus zwei perspektiven, hier sieht man, dass es nur 8 Pins beschaltet sind:

 

Mit dem neuen Verbindungs/Splitter-Kabel (kann man natürlich noch ordentlich wegsortieren):

 

Und dann zusammen mit dem CAN-Modul und dem Raspberry Pi:

 

Mitlesen von CAN-Informationen war auf allen drei CAN-Bussen möglich, das Auswerten steht noch aus.

 

Nach einem Rückbau auf Originalzustand gab es im Steuergerät Gateway den Fehler, dass das Steuergerät für Sonderfahrzeuge zwischentlich nicht erreichbar war (stimmt ja auch, hatte ja den Stecker gezogen).

[w1ls0n]

Hi,

 

finde es ein super spannendes Projekt und stelle mir schon sehr lange so etwas in der Richtung vor. Leider sind meine Kenntnisse bzgl CanBus gegen null. Hab mich vor langer Zeit

mal ein wenig eingelesen gehabt, aber nie so richtig die Zeit gefunden tiefer in die Materie einzusteigen. 

 

Meine Experimente haben sich dann lediglich auf die Kommunikation mit einem ODB2 ELM327 beschränkt. Aber meine Bestrebungen sind dann auch leider wieder relativ schnell eingeschlafen. 

Finde es klasse was du schon jetzt erreicht hast !  

 

Lust mich zu beteiligen hätte ich generell schon, aber du bist glaub schon mindestens 10 Schritte voraus  

(Zudem wäre das ehrlicherweise bei mir eher ein Thema für den Herbst/Winter)

 

LG,

Wilson 

[derschotte]

Servus, 

hätte grundsätzlich Interesse. Beruflich bin ich da thematisch nicht ganz so weit. 

Sind das CANs oder CAN-FD?

Hast du einen Schaltplan/Vernetzung aus dem ersichtlich ist, welches Steuergerät an welchem Can mit dran hängt? 

Mal alte dbcs zum interpretieren verwendet? Da schwirren doch sicher ein paar im Netz rum. Ich hätte ein paar alte von VW zum testen. 

Kennst du Canape/Canoe/Diadem? Damit ließen sich mittels einfacher Skripte ein paar Botschaften interpretieren.

Mit VCDC ließe sich auch das eine oder andere interpretieren.

 

Gruß

Rico

[nemesis03]

Hallo,

vielen Dank für die Rückmeldungen. Jede Beteiligung ist willkommen, auch wenn es nur Ideen/Denkanstöße sind. Ich versuche möglichst nachvollziehbar zu arbeiten, sodass andere Interessierte mit günstiger Hardware nachbauen können.

 

CAN oder CAN-FD? Ich glaube CAN, weil ich auf allen drei/vier CAN-Bussen mit einer Datenrate von 500.000 Daten mitlesen konnte. Ich glaube der von mir verwendete MCP2515 kann auch kein CAN-FD. 100% sicher bin ich mir nicht. Kann ja auch sein, dass ich nur einen Teil der Datenpakete abgefangen habe.

 

Die Vernetzung habe ich mir aus dem Stromlaufplan Datenvernetzung (gibt es im erWin (

You do not have the required permissions to view the link content in this post.

geholt). Da meine Tabelle da etwas unübersichtlich ist, versuche ich das mal zusammenzufassen:

• CAN-Antrieb: Motorsteuergerät, Airbag, Wählhebelsensorik, DSG, Allrad, elektronische Dämpfung, Einparkhilfe, Lenkhilfe, ABS, Alarmhorn, Airbag, verschiedene Sonsoren im Motorbereich und Steuergerät für Sonderfahrzeuge
• CAN-Extended: Taxameter, Spiegeltaxameter, Funkgerät, Telematik, Unfalldatenspeicher, Reifendruckkontrolle, Spurwechselassistent, Abstandsregelung, Innenspiegel, Frontkamera, Leuchtweitenregelung und Steuergerät für Sonderfahrzeuge sowie CamperUnit
• CAN-Komfort: Fahrtenschreiber, Schalttafeleinsatz, Bordnetzsteuergerät, Notrufmodul, Türsteuergeräte, Anhängererkennung, Fahrersitzverstellung, Heckklappe, Heizung/Klimabedienteil, Steuergerät für Informationselektronik und Steuergerät für Sonderfahrzeuge
• CAN-Infotainment: Steuergerät für Informationselektronik, Luftzusatzheizung, Warmwasserzusatzheizung, Rückfahrkamera, Anzeige und Bedienungseinheit
• Ethernet 1: Steuergerät für Informationselektronik, und Schalttafeleinsatz
• Ethernet 2: Steuergerät für Informationselektronik und Notrufmodul
• Das Steuergerät für externe Fahrzeugkommunikation ist per eigenem CAN-Bus mit dem Fahrtenschreiber verbunden (laut Stromlaufplan)

Alle CAN-Busse liegen auch am Gateway an (außer kleinen CAN-Bussen z.B der CAN-Bus zwischen linken und rechtem Sensor für Spurwechselassistent, etc.). Natürlich sind nicht in allen Fahrzeugen alle Steuergeräte verbaut. Und der Stromlaufplan könnte falsch sein oder ich habe etwas falsch abgeschrieben.

 

Bisher habe ich nur über candump über meinen Raspberry Pi Zero die Datenpakete über das MCP2515-Board beispielhaft mitgeloggt. Auch eine Auswertung direkt in Windows in Wireshark (per sshdump, also Wireshark loggt sich per SSH im Raspberry Pi ein und schneidet von dort die CAN-Schnittstelle mit) funktioniert, brachte aber spontan keine Erkenntnisse.

 

Ich wollte mir als nächstes die Kommunikation zwischen Camper Unit und Steuergerät für Sonderfahrzeuge anschauen. Dafür kann die Zündung ausgeschaltet sein, sodass nicht so viele Datenpakete auf dem Bus sind. Dann wollte ich mal schauen, was sich durch Tastendruck an einer Lampe oder beim Lampe ein-/ausschalten über die Camper Unit ändert. Das könnte man dann auch versuchen per cansend zu simulieren ohne dass ich befürchten würde dabei etwas kaputt zu machen.

Für die Auswertung wollte ich mir per PHP und Javascript eine kleine Anzeige der Pakete programmieren, in der ich Änderungen von Bytes/Bits ehen kann.

Leider ist mir gestern der Raspberry Pi kaputt gegangen, vermutlich die SD-Karte, neue SD-Karte ist unterwegs...

 

Alte DBCs habe ich nicht getestet, teilweise habe ich im Internet Listen mit CAN-IDs gefunden und geschaut, ob ich diese im Paketmitschnitt finde, aber leider ohne Erfolg. Wenn du da etwas gutes hast, was für MQB funktionieren sollte, kann ich das gerne ausprobieren. Mit Software für die Interpretation habe ich noch keine Erfahrung. VCDS habe ich leider auch nicht, nur einen OBDeleven Stick. Wenn du da etwas kostenloses kennst, wäre ich für Tipps dankbar. Bei github findet man ein bisschen was, aber irgendwie schien das alles dann doch nicht zu passen.

 

Ich werde demnächst auch noch testen, was passiert, wenn man den OBDeleven Stick direkt an einen CAN-Bus hängt. Da interessiert mich, ob es immer noch die Beschränkung gibt, dass für manches die Motorhaube entriegelt ist oder ob diese Beschränkung durch das Gateway umgesetzt wird und so umgangen werden kann. Dafür habe ich mir einen männlichen und weiblichen OBD2-Stecker bestellt, um mir z.B. den CAN-Extended in den OBD2-Stecker reinzupinnen, die Stromversorgung wird dann über den eigentlichen OBD2-Anschluss im Fahrzeug in den neuen Stecker reingepinnt.

 

Was ich mich noch gefragt habe: Ich möchte meinen Adapter am Steuergerät für Sonderfahrzeuge eigentlich nicht immer an- und abstecken. Wenn ich den einfach im Auto lasse, haben die drei CAN-Busse ja jeweils ein offenes Ende. Prinzipiell braucht der CAN-Bus ja Abschlusswiderstände, aber nur an den (beiden) Enden und nicht an Stichleitungen. Wie ist das aber, wenn es jetzt an einem CAN-Bus eine offene Stichleitung gibt?

Bearbeitet 5. Juli 2023 von nemesis03
kleine Formatkorrektur

[derschotte]

Servus,

Kannst du mir die IDs mal zukommen lassen bzw. einen Dump. Zu der ein oder anderen ID hab ich was, allerdings unklar welche Vernetzung zu Grund liegt. Wobei nur zu Themen wie Antrieb und Komfort CAN.

Mittels VCDS und mitsniffen auf den CANs wäre es einfach, die Botschaften zu interpretieren. Eine kostenlose Lösung mit dem Funktionsumfang kenn ich leider nicht. 

 

Offenes Ende an den Stichleitungen ist grundsätzlich kein Thema. Wichtig ist, das die beiden Leitungen verdrillt sind. 

Schade das du aus dem anderen Eck von D kommst. 

 

Gibt es einen Thread von dir zum Umbau auf die Schaltpaddels?

[nemesis03]

Bitte entschuldigt die späte Antwort, habe jetzt etwas gebraucht, bis ich Zeit hatte wieder im Auto zu basteln.

Der Bau des Adapters hat funktioniert, jedoch sehen die Lötstellen echt nicht schön aus:

You do not have the required permissions to view the image content in this post.

 

Wenn ich sowohl Strom (vierfach Buchse/Stecker) und CAN-Bus (dreifach Buchse/Stecker) an den OBD2-Port anschließe, konnte mein OBDeleven mit dem Fahrzeug kommunizieren. So wie im letzten Bild angeschlossen (CAN-Bus am Extended-CAN) gab es keine Kommunikation. Ich habe dann erst mal nicht weiter getestet.

 

Bezüglich Auswertung der CAN-Daten bin ich auf das Programm SavvyCAN gestoßen. Das Programm kann über geeignete Hardware einen (oder mehrere) CAN-Busse mitloggen oder Logdateien (z.B. von candump) laden.

Es gibt fertige Hardware zu kaufen, die ist jedoch recht teuer (>100 Euro). Es gibt auch eine kompatible Firmware für einen ESP32 (

You do not have the required permissions to view the link content in this post.

), dann braucht man als Hardware nur noch einen ESP32 und einen CAN-Tranceiver, bzw. ein CAN-Board. Ich habe mir für 5 Euro einen SN65HVD230 bestellt und habe ja noch das CAN-Board, das ich schon am Raspberry Pi eingesetzt habe. Der SN65HVD230 arbeitet über einen im ESP32 eingebauten CAN-Controller und hiermit konnte ich auch Daten empfangen. Leider scheinen die Daten nicht vollständig zu sein. Entweder ist der ESP32 nicht schnell genug oder (und das ist mir leider erst eingefallen, als ich alles wieder abgebaut habe) die serielle Verbindung zum Computer ist nicht schnell genug. Das nächste Mal teste ich noch mal über WLAN. Über meinen MCP2515 konnte ich keine Daten empfangen und kann noch nicht sagen, warum das nicht ging.

 

Dann habe ich noch mal mit dem Raspberry Pi ein paar Daten ausgelesen. Neben cancump gibt es auch cansniffer, wo nur die IDs angezeigt werden, die sich gerade verändern. Auf dem Extended-CAN konnte ich damit schon mal sehen, dass die ID 526 scheinbar die in der CU vorgenommene Lichteinstellung des Wohnraumlichts ist. Die Daten sind z.B. 46 07 26 46

wobei jeweils die ersten und letzten zwei Bytes fest sind, Byte 3/4 ("07") die ID der gewählten Lampe anzeigt und "26" die Helligkeit ist. Wann man selber die Daten über den CAN-Bus sendet, wird die Helligkeit auch wie gewünscht eingestellt, wobei teilweise ein mehrfaches Senden (insbesondere bem Hoch- und Runterdimmen) erforderlich ist.

Die ID 528 scheint dann die Lichteinstellung am Steuergerät für Sonderfahrzeuge zu sein, wobei die Daten aus der CU auch hierhin übernommen werden. Daten sind z.B. 80 26 46 07. Dabei ist "26" wieder die Helligkeit und "07" wieder die Lampen-ID, wobei die Lampen-ID nicht gesetzt wird, wenn die Lampe über einen Hardware-Taster geschaltet wird. Die "46" ist wieder fest und die "80" ist auch irgendwie eine Lampen-ID.

Im Byte 53A gibt es einen Counter, der jede Sekunde hochzählt, evtl. die Uhrzeit.

 

Hier die IDs, die ich nach Zündung an auf dem Motor-CAN hatte:

You do not have the required permissions to view the code content in this post.

 

Bezüglich der Schaltpaddels habe ich den Umbau hier beschrieben:

 

[yps77]

Ich bin gerade auf diesen höchst interessanten Thread gestoßen und möchte ihn nach oben holen, um mein Interesse zu bekunden und meine Mithilfe anzubieten.

 

Meine konkrete Motivation ist es herauszufinden, ob man die von Danhag etc. angebotene Zuheizer-Aufrüstung auch selbst auf ESP32-Basis realisieren könnte, kostengünstiger und mit Zusatzfunktionen.

 

Aber auch so ist es natürlich spannend, den CAN-Bus zu erkunden und zu schauen, was das Auto da alles ausspuckt. Erfahrungen mit dem Reverse-Engineering von Protokollen sind berufsbedingt reichlich vorhanden. Und diverse ESP und Raspis liegen noch in der Bastelkiste.

 

Ich werde mal zusehen, dass ich mir die nötige Hardware (Adapterkabel und CAN-Interface) besorge, um jedenfalls schon etwas sniffen zu können. Wenn sich dann noch jemand findet, der so eine Zuheizer-Aufrüstung verbaut hat und mich mal mithören ließe, wäre das natürlich das i-Tüpfelchen.

 

Disclaimer: Ich will den Wert der Danhag-Aufrüstungen auf keinen Fall in Frage stellen. Da steckt bestimmt etliches an Engineering dahinter, daraus ein marktfähiges Produkt zu machen, das man auch offiziell verkaufen kann, mit allen damit verbundemen regulatorischen Aufwand. Ich würde die 500 Euro dafür auch auf den Tisch legen. Aber mich reizt die Vorstellung, ein eigenes Interface zu haben, das einem Zugang zu diesen und sehr viel mehr Funktionen bietet, vielleicht über standardisierte Protokolle wie MQTT.

[pulleman]

Dann werf' ich Mal 

You do not have the required permissions to view the link content in this post.

 

In den Raum

 

[yps77]

You do not have the required permissions to view the quote content in this post.

 

Sicherlich ein spannendes Projekt. Da geht es aber mehr darum, ein lokales Dashboard zu bauen, richtig?

 

Meine Überlegungen gehen ja in Richtung Fernsteuerung der Standheizung, also ohne WLAN sondern mit Mobilfunk. Quasi ein zweites WeConnect, nur besser. Daher die Idee mit MQTT, auch um den Traffic gering zu halten. Ein hübsches Web-Frontend kann man dann irgendwo auf einem Server laufen lassen, und belastet weder den Datentarif noch den ESP mit dem Web-Traffic.

[pulleman]

Ja, an "schreiben" traut sich anscheinend noch keiner.

Man kann sich aber bei dem Projekt gut abgucken, wie er beide cores nimmt um im Timing zu bleiben.