Close
projekt-mx5.de

Ergebnis 1 bis 13 von 13
  1. #1

    Registriert seit
    18.07.2017
    Beiträge
    6
    Danke Dank erhalten 14 in 3 Posts  Bedankt 0

    NB (nicht FL) kann doch OBD

    Hallo,

    nach intensiver Suche habe ich festgestellt, dass der NB sehr wohl OBD Faehigkeiten besitzt. Das ist auch deshalb naheliegend, weil das Teil in USA bereits mit OBD verkauft wurde, und die Fehlercodes ebenfalls 4-stellige OBS2 Fehlercodes sind (im Gegensatz zum NA). Allerdings entspricht das Protokoll eben nicht dem OBD2 Standard. Es ist ein OBD Derivat, dass wohl seinerzeit zusammen mit Ford entwickelt wurde.

    Um mir der ECU zu kommunizieren, braucht man zunaechst ein ELM Modul, dass nach folgendem Schema mit der 17pol. Diagnosebuchse verbunden werden muss:

    screen_mazda4.jpg

    (Die Grafik stammt aus dem forscan.org Forum).

    Man sieht, dass die MEM Leitung die K-Line der OBD Schnittstelle darstellt. Ueber diese Leitung ist auch eine selbstgebastelte Kommunikation moeglich. Die elektrische Spezifikation dieser Schnittstelle werde ich spaeter noch genauer beschreiben.

    Als naechstes braucht man die "Forscan" App. Da die Schnittstelle nicht dem OBD2 Standard entspricht, kommmt man mit der "Torque" App hier nicht weiter. Zum Testen gibt es die Forscan App auch als Lite Version. Einschraenkung hierbei ist, dass nur ein Parameter zu einem Zeitpunkt ausgelesen werden kann.

    Nach Installation und Starten der App verbindet man sich mit dem Fahrzeug und laesst sich die PIDs anzeigen, die der MX5 anbietet. Ich hab die PID meines MX mal als Screenshots zusammengestellt:

    pids.jpg

    Wie man sieht, bietet der MX5 ca. 70 Werte zum Auslesen an. Ob auch wirklich alle sinnvoll sind, habe ich nicht durchgetestet. Die, die ich ausprobiert habe, funktionieren. Dass einige der Sensoren doppelt vertreten sind, liegt daran, dass sie einerseits die physikalische Messwerte (idR. Spannung) und andererzeits umgerechnete Werte zurueckgegeben werden (zB. Temperatur in C).
    Geändert von neurin (02.09.2019 um 14:39 Uhr)

  2. #2
    Avatar von 81kW
    Registriert seit
    21.04.2018
    Ort
    D-905..
    Beiträge
    482
    Danke Dank erhalten 28 in 23 Posts  Bedankt 1
    Höchst interessant, das werde ich bei Gelegenheit ausprobieren.
    Vielen Dank für die Info!

  3. #3
    Avatar von da_user
    Registriert seit
    16.08.2009
    Ort
    D-931..
    Beiträge
    3.189
    Danke Dank erhalten 262 in 196 Posts  Bedankt 476
    Den entsprechenden Artikel von Forscan habe ich hier schonmal in einem ELM327-Thread verlinkt:
    https://forscan.org/forum/viewtopic.php?f=4&t=5

    Als Software würde ich hier übrigens eher das vollwertige ForScan für Windows empfehlen. Braucht halt einen Laptop od. ähnl. mit Windows. Ist dafür allerdings bei praktisch vollem Funktionsumfang kostenlos.

    M.W. hat ja der NA("FL") auch eine solche Diagnosebuchse. Interessant wäre, ob da auch dieser Bus anliegt und man diesen auslesen kann.

  4. #4

    Registriert seit
    18.07.2017
    Beiträge
    6
    Danke Dank erhalten 14 in 3 Posts  Bedankt 0

    K-Line

    Schliesst man ein Oszi an die K-Line an, ergibt sich folgendes Bild, sofern man ueber den ELM eine PID von der ECU anfordert:

    IMG_20190730_100125.jpg

    Die 7 linken senkrechten Striche sind die Anfragen des ELM an die ECU (7 Byte mit Pausen zwischen die Bytes), der breitere Strich links der Mitte ist die Antwort der ECU (8 bzw. 9 Byte fast ohne Pausen). Nach einer Pause von ca. 120ms wiederholt sich das Ganze. Im Prinzip handelt es sich um eine serielle Schnittstelle, aehnlich der RS232. Allerdings sind die Pegel 12V und 0V, wobei 12V einer logischen 1 entspricht, und 0V entsprechend logisch 0. Die Geschwindigkeit der Schnittsytelle betraegt ungewoehnliche 10400 Baud. Das Uebertragungsformat ist 8N1, dh. nach einem Startbit (log 0) folgt ein Byte (8 Bit), und als Abschluss wieder ein Stoppbit (log 1). Auf ein Paritaetsbit wird verzichtet. Idle (Stille) ist hier ebenfalls log 1. Beim Byte wird das niederwertigste Bit zuerst uebertragen (LSB first)

    IMG_20190730_100246.jpg

    Eine typische Antwort der ECU ist im Oszillogramm zu sehen. Die Kaestchenbreite betraegt 1ms, dh in ein Kaestchen passen etwa 10 Bit (bei 10400 Baud). nach dem Startbit ganz links (erster 1-0 Uebergang ) folgt 00100001 nach einer Pause von etwa 0,2ms kommt das naechste Startbit und die Folge 10101111 usw. Hexadezimal wird also zuerst eine 0x84 und dann eine 0xF5 gesendet (Achtung LSB first: dh Bitstrom rueckwaerts interpretieren).

    Fuer mein Projekt (Spritverbrauchsmesser) brauche ich folgende Sensoren, und auf die beschraenke ich mich erstmal auch:

    - FUELPW1: Oeffnungszeit der Einspritzduesen
    - RPM: (selbsterklaerend)
    - VSS: Geschwindigkeit

    Fordert man diese Sensorwerte an, kann man auf der K-Line folgende Byte an die MCU mitlesen:
    FUELPW1 0x64,0x10,0xF5,0x22,0x17,0x62,0x04
    RPM 0x64,0x10,0xF5,0x22,0x17,0x38,0xDA
    VSS 0x64,0x10,0xF5,0x22,0x17,0x4A,0xEC

    Ab hier wird jetzt tlws. Raterei, weil das Protokoll nirgends beschrieben wird. Falls jemand das Ford Protokoll kennt, bin ich fuer Erhellung dankbar....

    Man erkennt , dass die ersten 5 Byte immer dieselben sind. Wahrscheinlich bedeutet 0x64 "Anfrage einer PID". 0x10 und 0xF5 sind moeglicherweise Sende und Empfangsadressen der beiden Kommunikationspartner ELM und ECU, da diese sich bei den Anworten der ECU getauscht gesendet werden (s.u.). Fuer 0x22 und 0x17 habe ich leider keine Erklaerung.

    Das sechste Byte beschreibt jeweils die PID, dh 0x62 ist die Einspritzzeit, 0x38 die Umdrehungen und 0x4A die Geschwindigkeit. Das letzte Byte ist ein Checksummen Byte. Es berechnet sich einfach aus der Summe der bereits gesendeten 6 Byte, abgeschnitten auf 8 Bit (modulo 0xFF):

    0x64+0x10+0xF5+0x22+0x17+0x4A = 0x1EC ( modulo 0xFF: 0xEC)

    Die Antworten der ECU sehen jeweils exemplarisch so aus:
    FUELPW1 0x84,0xF5,0x10,0x62,0x17,0x62,0x04,0x90,0xF8
    RPM 0x84,0xF5,0x10,0x62,0x17,0x38,0x0D,0xAC,0xF3
    VSS 0x74,0xF5,0x10,0x62,0x17,0x4a,0x26,0x62
    Man sieht, dass die ECU unterschiedlich lange Antworten zurueckliefert. Die reinen Sensorwerte sind dabei 1 oder 2 Byte lang. Das erste Byte immer entweder 0x74 oder 0x84. Dann folgen wieder die Adressen 0xF5 und 0x10. Es folgt eine 0x62, 0x17 und schliesslich wieder die angeforderte PID Adresse (0x62 , 0x38 oder 0x4A). Danach folgen die Sensorwerte.

    Ist das erste Byte 0x74, ist der Sensorwert 1 Byte lang, waehrend er bei 0x84 2 Byte lang ist. Abschliessend folgt wieder eine Checksumme, die wie oben berechnet wird.

    Interpretation der Werte:
    Die uebermittelten Sensorwerte muessen in physikalische Groessen umgerechnet werden. Dabei sind 2 Byte als 16-Bit Zahlen zu interpretieren die wie folgt berechnet werden: 7te Byte * 256 + 8te Byte.

    Als Ergebniss erhalten wir in unserem Beispiel also als Dezimalwerte:
    FUELPW1 1164
    RPM 3500
    VSS 38
    Fuer die Einspitzzeit muss der Wert durch 512 geteilt werden, der Zahlenwert ist als ms zu interpretieren. In diesem Beispiel bedeutet es eine Einspritzzeit von 2,27 ms. Die Umdrehung kann direkt als Umdrehung pro Minute interpretiert werden, also hier 3500 upm. Fuer die Geschwindigkeit wird der Zahlenwert verdoppelt, also hier 76 km/h.


    Beitrag automatisch zusammengeführt


    Zitat Zitat von da_user Beitrag anzeigen
    Den entsprechenden Artikel von Forscan habe ich hier schonmal in einem ELM327-Thread verlinkt:
    https://forscan.org/forum/viewtopic.php?f=4&t=5

    Als Software würde ich hier übrigens eher das vollwertige ForScan für Windows empfehlen. Braucht halt einen Laptop od. ähnl. mit Windows. Ist dafür allerdings bei praktisch vollem Funktionsumfang kostenlos.

    M.W. hat ja der NA("FL") auch eine solche Diagnosebuchse. Interessant wäre, ob da auch dieser Bus anliegt und man diesen auslesen kann.
    Ich vermute nein:

    Erstens war zur NA-Zeit noch kein OBD in den USA vorgeschrieben, und zweitens blinkt der NA zweistellige Fehler, waehrend der NB 4-stellige OBD2 Errors ausblinkt.

    Aber das sagt mir nur die Kristallkugel. Leider habe ich keinen NA, das muss ein Dritter testen
    Geändert von neurin (04.09.2019 um 02:24 Uhr)

  5. #5
    Avatar von HansHansen
    Registriert seit
    21.02.2005
    Ort
    DE-Süd
    Beiträge
    7.467
    Danke Dank erhalten 741 in 542 Posts  Bedankt 881
    Zitat Zitat von neurin Beitrag anzeigen

    Ich vermute nein:

    Erstens war zur NA-Zeit noch kein OBD in den USA vorgeschrieben, und zweitens blinkt der NA zweistellige Fehler, waehrend der NB 4-stellige OBD2 Errors ausblinkt.

    Aber das sagt mir nur die Kristallkugel. Leider habe ich keinen NA, das muss ein Dritter testen
    Hallo,

    wow. Ganz schön reingefuchst in die Thematik, das sind mal echt interessante Infos.

    Zum NA vielleicht zwei Anmerkungen: Für Kalifornien sind die '97er-Modelle (wahrscheinlich schon Spät-'96) mit OBD2 ausgerüstet worden.
    Technische Daten haben sich dabei leicht geändert, 133PS statt bisher 131. Vorne an der Kurbelwelle kam ein zusätzlicher OT-Geber zum Einsatz.
    Laut US-Foren nicht benötigt für's Motormanagement, nur für Diagnose.

    Gerade mal bei einem Euro-NA, frühes '96er-Modell nachgesehen: Der Kontakt "MEN" in der Diagnosebuchse ist tatsächlich belegt.
    Was er ausgibt, kann ich leider nicht ermitteln, kein Equipment dafür zur Hand.

    Vielleicht hat ja mal jemand Zeit und Muße.

    Grüße
    HansHansen

  6. #6

    Registriert seit
    14.12.2015
    Ort
    D-44...
    Beiträge
    568
    Danke Dank erhalten 137 in 92 Posts  Bedankt 46
    Zitat Zitat von neurin Beitrag anzeigen
    0x64,0x10,0xF5,0x22,0x17,0x62,0x04
    [...]
    0x84,0xF5,0x10,0x62,0x17,0x62,0x04,0x90,0xF8
    Die Ford-Protokolle kenne ich auch nicht, aber so vom Aussehen her erinnert das ein wenig an KWP2000. Das Formatbyte (Byte 1) scheint abzuweichen. These: Das obere Nibble ist die Gesamtlänge mit Formatbyte und ohne Checksumme, das untere Nibble evtl. der Adressierungsmodus (in KWP2000 sind die Adressen optional). Wahrscheinlich gibts hier auch noch einen Adressierungsmodus mit eigenständigem Längenbyte, wenn 15 Byte nicht reichen.
    Die nächsten beiden Bytes würde ich auch als Target/Originator ansehen, vor allem weil 0x10 auch bei KWP2000 das Motorsteuergerät ist (allerdings ist da 0xF1 für den Tester, und nicht 0xF5).
    Wenn man dann sich weiter an KWP2000 entlanghangelt, wäre 0x22 der Service-Identifier (ReadPID?), der auch bei KWP in der Antwort bei Erfolg mit gesetztem Bit 6 echoed wird. 0x17 ist dann möglicherweise eine Protokoll-ID.

  7. #7

    Registriert seit
    18.07.2017
    Beiträge
    6
    Danke Dank erhalten 14 in 3 Posts  Bedankt 0

    Mikrocontroller

    Will man einen Mikrocontroller (MCU) an die ECU anschliessen, sind die unterschiedlichen Spannungen zu beachten. Die Kommunikationsleitung hat 12V Pegel, eine MCU kann idR. nur 5V verarbeiten.
    Daher ist ein Pegelumsetzer noetig. Ich habe diese Schaltung aus dem AVR-Forum verwendet:

    obdii_avr.gif

    Als MCU habe ich einen Arduino Uno mit einem 2.4" TFT Display mit Touch Funktion verwendet. Ich habe es anstelle der Digitaluhr eingebaut. Dazu wurde die Uhr entfernt, der Ausschnitt passend fuer das Display ausgefraest und der Hinterbau passend gedremelt, und das Ganze verkehrt herum wieder eingebaut. Die Spannungsversorgung +12V und Masse habe ich vom Stecker der Digitaluhr entnommen, die Datenleitung direkt an der Motorsteuerung im Fussraum des Beifahrers abgegriffen. (Das war einfacher als es vom Diagnosestecker im Motorrraum abzugreifen). Es ist das gruen-weisse Kabel Nummer 1D aus http://www.mellens.net/mazda/mazda_m...000_wiring.pdf, Seite Z-22.

    Eingebaut sieht das Ganze so aus:
    IMG_20190902_161714.jpg


    Der Controller zeigt den aktuellen Verbrauch (hier 8.21 l/100km) den Durchschnittsverbrauch (9.96 l/100km) die aktuelle Geschwindigkeit (30 km/h), die gefahrenen Kilometer im gesammten Messzeitraum (92,6 km) und den Gesamtverbrauch (9.22 l) an. Dazu werden regelmaessig die gefahrene Wegstecke sowie der momentane absolute Verbrauch ermittelt. Der Controller fragt dazu in einer Endlosschleife die aktuellen Werte (Einspritzzeit, RPM und Geschwindigkeit) ab, und ermittelt die Zeit zur letzen Messung (ca 0.5s). Daraus berechnet er die Wegstecke in km (Geschwindigkeit * Zeit) sowie den absoluten Verbrauch in ml (5ml/s * Zeit * 2 * RPM / 60). Dabei ist 5ml/s ist die geschaetzte Einspritzmenge je Duese pro Sekunde (dazu spaeter mehr), das Messintervall in Sekunden, 2 Einspritzvorgaenge pro Umdrehung und die Umdrehungen pro Sekunde. Beide Werte ergeben als Quotient den momentanen Verbrauch, integriert man beide Werte ueber die Zeit, erhaelt man die gefahrene Wegstrecke, den absoluten Verbrauch, sowie den Durchschnittsverbrauch.

    Momentan ist die Einheit noch nicht geeicht. Die Abweichung der gefahrenen Kilometer im Vergleich zur Tachoanzeige liegt bei etwa +3% (ca. +3km bei 90km). Das ist akzeptabel und noch korrigierbar. Der echte Verbrauch wurde noch nicht ermittelt. Tatsaechlich sind wirklich erst knapp 100km auf der Uhr, ich habe noch nicht nachgetankt. Der Verbauch mit ca 10l/100km ist aber definitiv zu hoch. Meine Erfahrungen liegen bei etwa 8,5 /100km. Moeglicherweise sind die 5ml/s der Duesen zu hoch eingeschaetzt.

    Der Wert habe ich aus der Reparaturanleitung http://www.mellens.net/mazda/Mazda-Miata-1999-2001.pdf Seite 01-14-15. Dort heisst es, dass eine Duese zwischen 66 und 82 ml in 15 Sekunden ausspruehen soll. Nimmt man den Mittelwert 75ml ergibt es genau 5ml/s. Allerdings ist mir nicht klar, auf welchen Motor sich die Anleitung bezieht. Ich habe den 1.6er.

    In http://mxfive.at/einspritzduesen-wis...tes-reinigung/ werden die Duesen wie folgt angegeben:

    MX-5 NA 1.6 Düse: Blaue Kappe / 212cc@3Bar
    MX-5 NA 1.8 Düse: Braune Kappe / 254cc@3Bar

    Der MX 5 betreibt die Duesen allerdings mit 4 bar (http://www.mellens.net/mazda/Mazda-Miata-1999-2001.pdf Seite 01-14-16). Geht man davon aus, dass bei 4 bar 1/3 mehr eingespritzt wird als bei 3 Bar, entsprechen die Grenzwerte der Reparaturanleitung etwa diesen beiden Duesen. Moeglicherweise ist dann 66 ml (etwa 4,4 ml/s) der bessere Wert fuer den 1.6er. Das ergaebe dann ca. 8,8l Durchschnitt, was bei reinem Stadtverkehr nicht unrealistisch ist.

    Man wird sehen....


    Beitrag automatisch zusammengeführt


    Neben der Verbrauchsmessung hab ich noch schnell 'ne Ueberwachung fuer die Lamdasonde realisiert. Ich hatte da mal schlechte Erfahrungen damit gemacht: https://mx-5.de/forum/showthread.php...11#post9836111

    Die Abfrage ist einfach: PID ist 0x95, die gesamte Abfrage sieht somit so aus:

    0x64,0x10,0xF5,0x22,0x17,0x95,0x37

    Die Anwort der ECU betraegt nur 1 Byte. Der Wert muss mit 200 geteilt werden, um die Ausgabespannung der Lambdasonde zu berechnen. Graphisch dargestellt sieht das im Stadtverkehr bei mir so aus:
    IMG_20190902_163033.jpg

    Lambda laeuft....
    Geändert von neurin (03.09.2019 um 15:08 Uhr)

  8. #8
    Avatar von da_user
    Registriert seit
    16.08.2009
    Ort
    D-931..
    Beiträge
    3.189
    Danke Dank erhalten 262 in 196 Posts  Bedankt 476

  9. #9
    Avatar von GAFCOT
    Registriert seit
    23.07.2002
    Ort
    Bassum
    Beiträge
    19.646
    Danke Dank erhalten 608 in 444 Posts  Bedankt 955
    Dieses Forum haut mich immer wieder vom Hocker - erstaunlich, was da so alles unter der Oberfläche lauert.
    Jörg (Kürschrauber)

  10. #10

    Registriert seit
    18.07.2017
    Beiträge
    6
    Danke Dank erhalten 14 in 3 Posts  Bedankt 0

    Erstes mal Tanken

    Habe heute mit der besten Ehefrau von allen eine Spritztour am Rhein und durchs Ahrtal gemacht. Danach waren ca. 250 km auf der Uhr, erstmal genug um zu tanken und nachzurechnen.

    Bei den Kilometern zeigte der Tacho 252,3km, der Verbrauchsmesser 261,4km an. Der Unterschied betraegt +3,6%. Da diese Abweichung im Beobachtungszeitraum sehr konstant war, wurde sie in der neuen Firmware als Konstante einfach mit eingerechnet.

    Es stellt sich nur die Frage, welcher Streckenzaehler richtig rechnet. Vielleicht werde ich das mit einem Navi mal ueberpruefen.

    Der Verbrauch war (mit der 5ml Duese) zu 25,99l berechnet. Tatsaechlich passten nur 20,45l in den Tank. Das war zu erwarten. Das Verhaeltniss dieser Volumina betraegt fast genau 5:4. Deshalb wurde auch in der neuen Firmware der Duesendurchsatz von von 5ml/s auf 4ml/s reduziert.

    Leider bin ich nun erstmal afk. Morgen gehts in den Urlaub, leider nicht im MX, sondern im Flieger. Fruehestens in 14 Tagen geht's daher erst weiter.....
    Geändert von neurin (04.09.2019 um 02:35 Uhr)

  11. #11
    Avatar von Itte
    Registriert seit
    05.08.2009
    Ort
    D-74223
    Beiträge
    1.416
    Danke Dank erhalten 151 in 112 Posts  Bedankt 119
    Zitat Zitat von HansHansen Beitrag anzeigen

    Zum NA vielleicht zwei Anmerkungen: Für Kalifornien sind die '97er-Modelle (wahrscheinlich schon Spät-'96) mit OBD2 ausgerüstet worden.
    Technische Daten haben sich dabei leicht geändert, 133PS statt bisher 131. Vorne an der Kurbelwelle kam ein zusätzlicher OT-Geber zum Einsatz.
    Laut US-Foren nicht benötigt für's Motormanagement, nur für Diagnose.

    Hatten die miatas ab Mitte 1996. Mit der App "Piston" kann man da ganz nett Werte auslesen und auch mal einen Fehler zurücksetzen.


    Grüße
    Christian

  12. #12

    Registriert seit
    18.07.2017
    Beiträge
    6
    Danke Dank erhalten 14 in 3 Posts  Bedankt 0

    Erste richtige Ergebnisse

    Es ist tatsaechlich 6 Wochen her, seit dem letzten Tanken. Momentan fahre ich nur extreme Kurzstrecken, und muss daher kaum tanken. Dadurch ist aber auch der Verbrauch sehr hoch, er liegt bei ca 9,3 l/100km...

    Zur Erinnerung: Ich messe in kurzen Zeitabstaenden (ca 0.7 sek), die momentane Geschwindigkeit und die Oeffnungszeit der Einspritzduesen. Daraus berechne ich die gefahrene Strecke und den absoluten Verbrauch. Integriert ueber die Zeit ergibt sich die Gesamtstrecke in km und den Gesamtverbrauch in l. Der Durchschnittsverbrauch in l/100km laesst sich dann leicht berechnen.

    Ergebnisse:
    Meine berechneten Kilometer betrugen 430,4km der Tageskilometerzaehler zeigte 430,0 an.
    Der berechnete Verbrauch lag bei 40,12l, in den Tank passten 39,63l. Die Abweichung liegt bei ca 0,5l.

    Im Stadtverkehr ist die Messung nahezu perfekt. Ob es auf Autobahn oder Landstrasse genauso ist, wird die Zeit zeigen.

  13. #13

    Registriert seit
    09.03.2023
    Ort
    63110
    Beiträge
    3
    Danke Dank erhalten 0  Bedankt 0
    Abend,

    Ich probiere aktuell etwas Ähnliches umzusetzen, allerdings klappt bei mir die Verbindung zwischen Arduino und Auto nicht so wie ich mir das vorstelle.

    Hast du eventuell noch den Code für den Arduino. Den Schaltplan habe ich so gemacht wie in deinem einen Bild.

    Freue mich auf eine Antwort (bin echt am verzweifeln)

Ähnliche Themen

  1. [NB⁄NBFL] Längsträger: und man kann sie doch fachgerecht reparieren
    Von Schoetti im Forum Technik Serie
    Antworten: 15
    Letzter Beitrag: 17.10.2019, 22:24
  2. [NC/NCFL] (NC) Tüv AU mit OBD oder normal?
    Von AdrianS im Forum Allgemeines
    Antworten: 5
    Letzter Beitrag: 06.06.2009, 20:50
  3. Standalone OBD-Analyser (Elektor)
    Von gewa im Forum Allgemeines
    Antworten: 49
    Letzter Beitrag: 18.07.2007, 12:45
  4. [NA] (NA) tankinhalt etwa 40 liter? kann doch nicht sein, oder?
    Von bratfass im Forum Allgemeines
    Antworten: 9
    Letzter Beitrag: 08.03.2006, 14:25
  5. Das kann doch wohl nicht wahr sein...
    Von erdbaere im Forum Optik und Komfort
    Antworten: 1
    Letzter Beitrag: 16.02.2005, 13:14

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •