mikrocontroller.net

Forum: Fahrzeugelektronik Parksensor Protokoll dekodieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe hier so 0815 Ultraschall-Parksensoren vom Auto, sowie ein dazu 
passendes Parkpilot-Modul. Auf der CAN-Seite des Moduls weiss ich wie 
ich die Parkpilotfunktion aktiviere.
Nun möchte ich herausfinden wie die Kommunikation zwischen dem Modul und 
den Sensoren ist. Eine erste Messung ergab, das die Ausgänge scheinbar 
OpenCollector sind, also ohne Sensor LOW und mit Sensor im Ruhezustand 
12V und beim kommunizieren Pulse nach 0V. Ein weiterer Test mit einem 
einfachen 100kOhm Pullup auf 12V bestätigte das, da sehe ich auch die 
Pulse. (ich habe die LA files angefügt. Diese lassen sich mit dem Saleae 
Logic LA öffnen)

Als nächstes habe ich das Signal einmal mit Sensor und einmal ohne mit 
einem LogicAnalyzer aufgezeichnet. Ich glaube darin sowas wie eine 
Initialisierungssequenz zu erkennen (siehe "pdc-sensor_1.png").

Dann hab ich mir das Timing angeschaut und habe eine Bit-Zeit von 310uS 
ermittelt (siehe "pdc-sensor_2.png").

Anschließend habe ich versucht ob das Signal ein einfaches Serialsignal 
ist und den Async-Serial Analyzer mit Autobaud und 8N1 drauf 
losgelassen. Das war direkt ein Treffer, zumindest scheinen die Daten 
sinnvoll (siehe "pdc-sensor_3.png"). Den Code habe ich als Textdatei mal 
angehangen.

Nun weiss ich im Moment nicht weiter. Vielleicht kennt sich ja hier 
jemand mit solchen Sensoren aus. Parksysteme wie dieses von Valeo werden 
ja millionenfach verbaut und unterscheiden sich sicher nicht besonders.

Mein Ziel ist es, den Code zu kennen und die Sensoren vom Arduino aus 
initalisieren und nutzen zu können.

: Verschoben durch Moderator
Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du mal probiert Deinem Sensor die gesampelte 
"Initialisierungssequenz" zuzuspielen?

Also die ganze Sequenz, so wie sie ist, ganz stupide von Deinem Arduino 
aus per Bitbanging zu senden.

Wie reagiert das Ding dann?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nee, hab ich noch nicht. Ich wüsste im Moment nicht was ich damit 
erreichen könnte. Ich müsste ja erstmal wissen was der zurücklieferen 
sollte. Deshalb hab ich ja den Sensorausgang vom Modul einmal mit und 
einmal ohne Sensor gescannt, in der Hoffnung die RX und TX zu 
unterscheiden. Ist ja bei einem single-wire nicht so ganz einfach...

Auch bin ich mir noch nicht sicher ob das wirklich ein einfaches 
Serial-Signal ist. Klingt ja fast zu simpel.

Mir fehlt auch noch die Vorstellung was so ein Sensor für Werte liefern 
könnte. Sicher muss man ihn irgendwie zum aussenden eines PING triggern. 
Die zurückkehrenden Echos, bzw. wenigstens das erste zurückkehrende Echo 
müssten dann ja sicher zum Modul gesendet werden. Jetzt könnte hier 
einfach nur ein Bit anzeigen das was zurückkam und das Modul erreichnet 
anhand der Sende/Empfangs-Zeitdifferenz und der Schallgeschwindigkeit 
die Entfernung. Oder aber der Sensor berechnet das und sendet ein 
Entfernungsbyte zurück.

Autor: August H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Auch bin ich mir noch nicht sicher ob das wirklich ein einfaches
> Serial-Signal ist. Klingt ja fast zu simpel.

Derartige Sensoren werden oft per LIN-Bus angebunden, und das ist nur 
ein verkappter UART. Die LIN-Spezifikation ist öffentlich verfügbar, 
soweit ich weiß, vielleicht hilft dir ein Blick da rein bei der 
Dekodierung.

Autor: Harald A. (embedded)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim LIN müsste man einen Break sehen (Signal länger '0' als eine 
Byte-Länge) und danach das Sync, bestehend aus dem Byte 0x55. Danach 
folgen Daten und die Checksumme. Bis zum nächsten Break.

Baudrate richtig? Beim LIN höchstens 19.2kBaud.

Autor: Joe F. (easylife)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck mal hier:
http://www.instructables.com/id/Hacking-Automotive-Ultrasonic-Sensors/?ALLSTEPS

Das sieht mir ziemlich ähnlich aus.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Joe, den Link hatte ich zwischenzeitlich auch gefunden. 
Interessant, aber der Spricht darin von Single-Wire CAN??? Das sehe ich 
ja überhaupt nicht im Code. LIN schon eher, vielleicht eine adaptiere 
Version, so wie beim W-Bus, mit BREAK (gut zu erkennen im Diagramm) aber 
ohne Sync und Checksum.

Autor: Guido (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Füge in die Kommunikationsleitung zwischen Sensor und Steuergerät einen 
1 kOhm Widerstand ein und oszilloskopiere auf der Sensorseite. Die Stufe 
im Signal also die unterschiedlichen Lowpegel zeigen Dir dann, was vom 
Steuergerät kommt und was vom Sensor. Es gibt eine 
Initialisierungsfolge, anschließend den Ping und dann ein Lowpegel mit 
der Dauer des gesendeten Ultraschallsignals (Schwingdauer). Sieht man in 
PDC-Sensor_1 auch.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido, das ist eine brilliante Idee! Werde ich gleich heute abend 
ausprobieren und berichten.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch ein wenig dran gearbeitet: also zunächst die 
Initialisierung (zwei Pulse Steuergerät, zwei Sensor, immer gleich 
lang), dann Ping-Kommando und als Antwort die Dauer des Ultraschalls 
plus Reserve, dann offensichtlich ein kurzer Puls vom Steuergerät um den 
Sensor in "Hörmodus" zu bringen, das wiederholt einmal, manchmal 
zweimal. In diesen Zeiten werden die anderen drei Sensoren angepingt.
Die Antworten der Sensoren sind sehr übersichtlich, wenn "255" als 
Ergebnis kommt (also kein Hindernis erkannt); für andere Werte kommt 
eine Pulsfolge, die ich noch nicht dekodiert habe (ich habe noch kein 
vernünftig reproduzierbares Timing erkannt) Könnte UART sein, sicher 
kein LIN und kein SENT. Ich versuche morgen mit einem Signaldekoder dran 
zu gehen, dann kommt ein Bild. Leider habe ich auch kein Patent von 
Valeo gefunden, dass sich mit der Kommunikation befasst und Datenblätter 
gibts anscheinend auch keine...
Dir viel Erfolg, bitte berichte, wenn Du weiter kommt!

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hier mal die ersten Messergebnisse mit 1k in der Signalleitung und 
Tastkopf am Sensor. Die kurzen Striche sind somit Sendesignale vom Modul 
und die langen die Antworten vom Sensor.

Leider habe ich mit meinem Hantek 6022BE noch etwas 
Bedienungsschwierigkeiten. Zum einen kann man zwar ein Datenfile 
sichern, es aber nicht mehr einladen. Zum anderen kann man im 
gespeicherten Signalverlauf zwar mit rechter Maustaste hin und 
herscrollen, ab dem zweiten Bildschirm springt bei mir der Signalverlauf 
wieder zurück auf Anfang. Ein bischen Schrott was ich da gekauft hab...

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hier zunächst mal zwei Screens von den Signalen eines Sensors und seinem 
gesendeten (!) Ultraschallsignal. Damit ist der Impuls auf der 
Kommunikationsleitung definiert, mit dem die Sendeaufforderung kommt - 
die anderen Impulse vom Steuergerät müssen dann "Empfangsaufforderungen" 
sein.

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
...und die gleichzeitige Auswertung der Eigendiagnose: Sensor G205 mit 
3,42 ms, das entspricht genau der Impulslänge während des 
Ultraschallsignals plus Reserve für "zur Ruhe kommen" also den 
Ausschwingvorgang.

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist es ganz einfach: die Dauer zwischen dem Ende der 
Schallzeit und dem nächsten Puls des Sensors ändert sich ziemlich 
proportional zum Abstand:

Abstand [cm] Zeit [ms]
137          7,02
128          6,92
125          6,86
81           3,81
77           3,52
69           3,31
21           1,07

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, Guido!

Erklärst Du mir bitte wie Du zu dem grünen Ulraschallsignal gekommen 
bist? Hast Du am US-Lautsprecher gemessen? Oder mit einem US-Empfänger?

Der "hohe" Low-Pegel, der aufgrund des Widerstandes nicht ganz bis auf 
GND geht, ist das Signal hinter dem Widerstand, direkt vom Sensor.
Der "tiefe" Low-Pegel, der zumindest deutlich näher an GND geht ist der 
vor dem Widerstand, also zur PDC-Modul Seite hin.

Auf Bild "Ultraschall2.jpg" sieht man dann wohl zuerst das Erregersignal 
vom PDC-Modul (hohe Pegel). Diesem folgt dann während der Sendephase des 
Sensors ("PING") ein langer, "tiefer" Low-Pegel. Hast Du eine Idee ob 
die Dauer des Erregegungspulses irgendwie Einfluß auf die Sendedauer 
hat? Oder wird diese immer konstant sein?

"Ultraschall4.jpg" verstehe ich nicht, kannst Du das bitte ausführlicher 
beschreiben?

Ich meine das diese Sensoren ja sowohl als Sender als auch als Empfänger 
arbeiten können, nur halt nicht gleichzeitig. Vermutlich sind die 
Signale die keinen Schall auslösen zum einstellen von Sende- oder 
Empfangsbetrieb. Könnte auch gut sein, das beim Fahrzeug, wo ja immer 
mehrere verbaut sind, jeweils einer sendet und ein anderer empfängt. 
Oder die schalten sehr schnell hin- und her.

Wenn die Signale rein zeit- und flankengetriggert sind, dann kann hier 
doch kein UART-Protokoll oder ähnliches hinter liegen?! Dann sind das 
einfache Taktbefehle, mit Synchronisationstakten.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
also

Olli Z. schrieb:
> Erklärst Du mir bitte wie Du zu dem grünen Ulraschallsignal gekommen
> bist? Hast Du am US-Lautsprecher gemessen? Oder mit einem US-Empfänger?

ja, ein US-Mikro für 40 kHz

Olli Z. schrieb:
> Hast Du eine Idee ob
> die Dauer des Erregegungspulses irgendwie Einfluß auf die Sendedauer
> hat? Oder wird diese immer konstant sein?

Nein (kein Einfluss), bisher waren die immer gleich lang

Olli Z. schrieb:
> "Ultraschall4.jpg" verstehe ich nicht, kannst Du das bitte ausführlicher
> beschreiben?

In dem Impuls vor (!) dem lila markierten Bereich liegt das US-Signal 
(wie in Ultraschall2.jpg). Dann kommt der Sensor am Ende des lila 
Bereichs wieder mit einem Impuls und diese Zeit zwischen US-Ende und 
diesem Impuls nimmt ziemlich linear mit der angezeigten Entfernung in 
der Eigendiagnose zu.

Olli Z. schrieb:
> Könnte auch gut sein, das beim Fahrzeug, wo ja immer
> mehrere verbaut sind, jeweils einer sendet und ein anderer empfängt.

Ich habe mal mit mehreren US-Mikros gemessen: es sendet immer nur einer, 
alle 4 der Reihe nach, dann wieder von vorne.

UART-Auswertung mit dem Oszi brachte tatsächlich nichts, vielleicht 
findest Du ja noch was. Irgendwo müsste auch die Temperatur versteckt 
sein um die Laufzeit zu korrigieren.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Ein US-Mirko habe ich erstmal so nicht zur Verfügung, zumindest 
nichts hochwertiges. Habe nur aus einem Arduino-Shield so ein 
Sender/Empfänger Pärchen für US. Aber offensichtlich wird hier immer 
derselbe Ping gesendet.

Jetzt habe ich das auch mit deinem Meßprotokoll verstanden. Lila ist 
also praktisch die Laufzeit des Signals bis zum eintreffen des Echos. 
Vermutlich sogar des ersten Echos, denn da kommen sicher mehrere an. Für 
die Messung im Fahrzeug ist aber nur das erste PONG interessant, also 
kürzeste Distanz.

Damit der Sensor sein eigenes Signal wiedererkennt muss da irgendeine 
Modulation drin stecken, eine Kodierung. Möglicherweise wird diese bei 
der langen Initialisierungsphase mitgegeben.

Das die Sensoren hintereinander senden sehe ich ja auch in meinen 
Mehrkanal-Aufzeichnungen oben. Könnte gut sein, das jeweils gesendet und 
gleich danach gelauscht wird und das schön hintereinander. Könnte aber 
auch sein das einer sendet und alle andere lauschen.

Da hier scheinbar(!) kein Protokoll auf Byteebene zum Einsatz kommt, 
muss das ganze ja irgendwie statusgesteuert sein. Der Sensor muss 
wissen, das er beim nächsten LOW einen PING senden soll. Gehen wir mal 
davon aus, das er das nur einmal nach Erregung macht und nicht 
wiederholt. Gehen wir weitere davon aus, das er nach dem senden sofort 
in den Lauschmodus wechselt und eintreffende PONGs in Form von LOW-Pegel 
signalisiert. Irgendwann muss das ja mal zuende sein und das geht meiner 
Meinung nach fast nur über einen gemeinsam vereinbarten Timeout.

Eine Laufzeitkompensation aufgrund der Lufttemperatur müsste meiner 
Meinung nach der Sensor selbst regeln.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Eine Laufzeitkompensation aufgrund der Lufttemperatur müsste meiner
> Meinung nach der Sensor selbst regeln.

Da könntest Du Recht haben, dann bekäme das Steuergerät immer angepasste 
Werte.

Wenn das Ganze wirklich zeitgesteuert ist, warum tut der Sensor dann 
noch so, als ob er (digital) mit dem Steuergerät sprechen würde?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie auf Bild "Ultraschall2.jpg" zu sehen, sendet der Sensor ja zu Beginn 
der knapp 3,5 ms langen LOW-Phase vom Steuermodul. Während dieser Zeit 
ist das Modul für eintreffende Echos "blind". Umgerechnet auf die 
Entfernung (bei +20C, ohne Nebel benötigt der Schall 2,939 ms pro Meter) 
liegen wir hier bei ca. 0,6 m. Beim Mondeo liegt die untere Grenze 
(Dauerton) bei so ca. 20-30cm.

Wie man im Bild aber erkennt, ist die eigentliche Sendedauer wesentlich 
kürzer. Wie auch immer, das ist wohl der Grund warum man die letzten 
20cm nach Gefühl fahren muss. Darüber hab ich mich schon oft geärgert, 
denn wenn man echt knapp parken muss, sind das viel.

: Bearbeitet durch User
Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal etwas unsere Signalverläufe verglichen. Dann Deiner 
hervorragenden Arbeit ist die Startsequenz des Signals ja nun klar. Ein 
Vergleich zeigt, das diese bei mir exakt genauso verlaufen 
("sensor_ping.png").

Auffällig ist die in Bild "sensor_stopseq.png" dargestellte Sequenz. 
Diese folgt auch immer einige Zeit nach dem Echo-Auslöser ("PING"). In 
meinen Messungen liegt zwischen PING und diesem Signal ca. 50 ms, bei 
Deinem etwa 65 ms. In dieser Zeitspanne könnten theoretisch Echos von 
bis zu 10 m entfernten Objekten erkannt werden. Eigentlich viel zu weit, 
da die meisten PDC-Systeme einen Erfassungsbereicht von max. 3 Meter 
haben.

Dennoch könnte es sich hierbei um sowas wie eine STOP-Sequenz handeln. 
Oder sogar der Umschaltbefehl von Empfangs auf Sendemodus.

Die Sequenz selbst besteht immer aus einem langen und kurzen Signal vom 
Modul, gefolgt von zwei kurzen des Sensors. Könnte ein einfaches 
Handshake sein. Die Frage ist halt, ob die Dauer so eine entscheidende 
Rolle spielt und ggf. über den Wert eines Signals entscheidet und nicht 
nur binär ist.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Das könnte übrigens sowas hier sein:
> 
http://www.elmos.com/produkte/sensor/ultrasonic.html?tx_pmproductlist_productlist%5Bproduct%5D=99&tx_pmproductlist_productlist%5Baction%5D=showProduct&tx_pmproductlist_productlist%5Bcontroller%5D=Product&cHash=bb1d390f2c3c77d3e3516ea5047ac4fc

Ja, das kommt dem wirklich sehr nahe, SUPER TIPP!!!

Es klingt logisch das dieser erste Burst nach dem einschalten des PAM an 
die Sensoren eine Initialisierung ist, welche im internen EEPROM des 
Sensors gespeichert wird. Zumindest erklärt das, warum sich die Sensoren 
grundsätzlich auch ohne diese Initialisierung ansteuern lassen. Die 
programmierten Werte umfassen dann Sendefrequenz, Sendeleistung, usw.

Auch das umschalten zwischen Sende- und Empfangsbetrieb stimmt mit den 
Parksensoren überein.

Der Logic dieses Sensortyps folgend, wäre der Unterschied zwischen 
Sende- und Empfangsbetrieb durch die Dauer des LOW-Signals zum Sensor 
begründet. Kurzes LOW = Senden, langes LOW = Nur empfangen.

Die Dauer des Sende- oder Empfangsmodus ist auf 15 Intervalle limitiert. 
Die Dauer des Intervalls wird durch die programmierte Schwellwertlänge 
des Sensor bestimmt. Im Nahbereichsmodus sind dies ca. 18ms und im 
Fernbereichsmodus 36ms. Der Bereichsmodus bestimmt halt einfach die 
Länge und Stärke des ausgesendeten Bursts. Je kürzer dieser ist, desto 
schnell kann der Sensor wieder in den Empfangsmodus gehen und auf Echos 
hören.

Abgesehen davon ist es wohl eine gute Strategie bei mehreren Sensoren 
immer einen senden und einen anderen empfangen zu lassen. So hat man 
keine Umschaltzeit und kann auch im Nahbereich noch Objekte 
differenziert erkennen.

Die Bit-Übertragung könnte bei unseren Sensoren auch passen. Die 
BIT-Länge ist 12/f, wobei wohl 48 KHz sein dürfte (könnte Guido 
vielleicht mal mit seinem US-Mikro nachmessen). Somit ergibt sich 250 
uS.

Dabei ist eine logische "0" eine Sequenz aus einem langen LOW (125 uS):
-.    .-----
 |    |
 |____|

und eine logische "1" ist ein kurzes LOW (62,5 uS):
-. .--------
 | |
 |_|
Auch dieses Muster finden wir in unseren Scans. Leider fällt mir 
momentan kein passender Analyzer für einen solchen Code ein.

Für die EEPROM-Programmierung wird eine zusätzliche Spannung (25V) 
benötigt. Die könnte ggf. intern im PDC-Sensor erzeugt werden. In dem 
EEPROM werden 20 Bit an Daten gespeichert. Es gibt einen Modus zum 
auslesen und einen zum beschreiben des EEPROMs.

Ansonsten kennt dann System eigentlich nur einen SND (Sende) oder REC 
(Receive) und einen CMD (Command) Modus.

Damit bestätigt sich, das das Kommunikationsprotokoll eine Mischung aus 
Datenübertragungen und einfachen LOW-Signalen ist.

: Bearbeitet durch User
Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier handelt es sich um ein 40 kHz-Signal (1 / 25 µs), dann ist 12/f_drv 
= 300 µs. Passt aber mit dem Send Reqest und dem Receive Request nicht 
überein, die sind genau doppelt so lang.

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch die Screens mit Send- und Receive-Request

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...und die der Initialisierung nach Anlegen der Spannung. Hier passt die 
Bitbreite für 0 und 1 ebenfalls mit ~600 µs und ~300 µs ganz gut. Einen 
Unterschied im Dateninhalt konnte ich bisher nicht erkennen, weder für 
geänderte Umgebungsbedingungen noch für die einzelnen Sensoren.
Die Initialisierung kommt immer 2 mal nach Power on. Seltsam sind die 73 
Bit Länge dieser Sequenz !?

Die "Bits" der Sensorantworten weisen kein erkennbares Zeitmuster auf, 
auch das Elmos-Datenblatt sagt dazu nichts. Eigentlich geht es nur um 
die Messung der Zeit bis zum Echo.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Hier handelt es sich um ein 40 kHz-Signal (1 / 25 µs), dann ist 12/f_drv
> = 300 µs. Passt aber mit dem Send Reqest und dem Receive Request nicht
> überein, die sind genau doppelt so lang.

Wow, Dein DSO macht echt saubere Graphen! Sind ja wie aus dem Lehrbuch. 
Was haste denn da für ein Teil?

40 kHz sind zwar die untere Grenze, aber warum nicht. Besser als auf 
einem Band wo sich alles andere auch tummelt. Ich muss mal rumtüfteln 
wie ich das für mein Ford Modul rausbekomme.

So, nachdem wir die Frequenz kennen, können wir die Timings ableiten. 
Demnach ist 1/fdrv 25us. Die Bitlänge Tbit sind 12/fdrv, also 
richtigerweise 300us. In den beiden Nachfolgenden Bildern hast Du Send 
und Receive-Request vertauscht. Beim senden wird es vom Modul erst kurz 
low und während der Sendezeit vom Sensor. Laut Datenblatt muss zum 
senden ein Tsnd langer Low anstehen. Tsnd sind 6/fdrv, also 150us. Im 
Bild sind es aber, wie schon erwähnt 300us, also doppelt so lang. Auch 
der Trec ist mit 600us doppelt so lang wie er eigentlich sein sollte 
(12/fdrv, also 300us).

Eigentlich müsste ja zum anzeigen von Echos der Sensor nach der 
Ring-down Phase in den Receivemodus gebracht werden. Das sehe ich aber 
nicht. Stattdessen erkennt man auf den vorherigen Graphen die 
eintreffenden Echos. Daher vermute ich das der Receivemodus eher ein 
Receive-ONLY-Modus ist und das Sendkommando nach dem senden auch 
automatisch empfängt.

Die Initialisierung kann alles mögliche enthalten. Hier ist die Frage ob 
sich die Hersteller nicht ein eigenes Süppchen kochen. Ob Dein Sensor 
intern einen Elmos Chip hat ist ja völlig unklar. Zudem können da noch 
Checksum Bits drin sein. Hast Du mal versucht die Signale in ein 
Bitmuster zu wandeln? Gibt es dafür einen Analyzer? Geht das nicht in 
die Richtung Manchester-Code?

Die Echos haben ja keine Bitinformation, hier ist Zeitmessung angesagt. 
Steht so ja auch im Datenblatt. Die Lowphase muss mindestens 3/fdrv, 
also 75us sein.

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Was haste denn da für ein Teil?

Das ist ein PicoScope 3206D, tatsächlich ganz brauchbar.

Olli Z. schrieb:
> 40 kHz sind zwar die untere Grenze, aber warum nicht.

Auch Bosch schreibt was von 40 kHz in seinem Buch "Sensoren im 
Kraftfahrzeug" aus der Gelben Reihe (s. Anhang)

Olli Z. schrieb:
> Ob Dein Sensor
> intern einen Elmos Chip hat ist ja völlig unklar.

Stimmt, besonders da es ein Valeo-Sensor sein müsste, da Bosch andere 
Pegel verwendet. Auf dem zugehörigen Steuergerät steht ja auch Valeo 
drauf.
Das Bitmuster ist nicht das Problem, aber das ist "Stochern im Moor" 
solange wir nicht etwas über die Rahmenstruktur wissen. Und Analyzer 
dafür kenne ich nicht, wäre aber kein Thema, sobald uns eben hier jemand 
die Rahmenstruktur verrät.

Manchester denke ich nicht der ist ja Flanken gesteuert, hier werden die 
logische 0 und die logische 1 ja durch unterschiedlich lange Low-Phasen 
dargestellt.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...das könnte so was sein wie SAE J1850: eine PWM-Codierung

Autor: Gabriel (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Der Sensor lässt sich fast wie ein Arduino PING betreiben.
An Signal Pin des Sensors liegen ca 85% VCC an. Betreiben lässt sich der 
Sensor mit 5,5-9 V. Die Spannung hat keinen Einfluss auf die Reichweite.
Der Pin muss mit einem Trigger Low gestartet werden. 1 Mikrosekunde 
reicht.
Low 1 im Bild.
Danach setzt der Sensor den Pin Low (2).
Die Zeit bis zum nächsten Low (3) entspricht der Dauer bis zum Echo und 
muss als long erfasst werden. Long/51.3 ergibt die Distanz in cm und 
passt genau für 100 cm. Die Dauer ist nicht linear.
Mit /52:
Abstand = Anzeige
100=100
10=5
20=11
30=23
40=34
220=337
Im Bild Low 5 für 150 cm

Getriggert wird über ein Transistor, BC reicht, der 
digitalWrite(x,HIGH); invertiert.
Das Echo wird über einen zweiten Pin gelesen, digitalRead(y). Nach x Low 
delayMicroseconds(750) bis Read(y).
Duration = pulseIn(y,HIGH);
Der EchoPin wird direkt am SignalPin der PDC angeschlossen.

Gruß

Autor: Gabriel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es funktioniert einwandfrei mit PDC von VAG, Renault und Ford.
Der Schaltplan:

Autor: Gabriel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
220=237 !
Sorry

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cool, muss ich mal nachbauen. Dennoch machen die PDC Module mehr um 
übersprechen zwischen den Sensoren zu verhindern und sie "betanken" den 
Sensor noch initial mit Einstellungen und ein Prüfprotokoll wird es auch 
geben.

Autor: Gabriel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Check geht über das Setup für jeden einzelnen PDC.
Nach dem Trigger muss das LOW vom PDC kommen. Ist die Stromversorgung 
oder die Signalleitung unterbrochen, kommt das LOW nicht. Fail !
Wenn die Sensoren nacheinander, mit Delay(15), abgefragt werden 
beeinflussen sich die sich nicht untereinander.
In der loop muss nach digitalWrite(x,LOW), x auf pinMode(x,INPUT) 
umgestellt werden sonst sperrt x den Transistor.

Autor: Gabriel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es klappt nicht mit dem Code als Anhang. Ich bitte um Nachsicht!


Der Code :

//PDC Test Code by GS, 02 August 2019. Arduino Mega. PDC VCC 6V
//Check PDC pinout!!! 1 VCC, 2 Data, 3 GND

int duration;
int cm;
int check;

void setup() {

  Serial.begin(19600);
  // PDC 1
    pinMode(2, OUTPUT); // Trigger Pin
    pinMode(3, INPUT);// Echo Pin
  // check1
     digitalWrite(2,HIGH);
     delayMicroseconds(1);
     digitalWrite(2,LOW);
     delayMicroseconds(400);
     check = digitalRead(3);
     if (check==1){
      Serial.println(" PDC 1,OK");
     delay(1000);}
     else {
      Serial.println(" PDC 1, Setup - failure");}
}

void loop() {
  if (check==1){
  delay(15);
  digitalWrite(2, HIGH);
  delayMicroseconds(1);
  digitalWrite(2, LOW);
  pinMode(2, INPUT);
  delayMicroseconds(750);
  duration = pulseIn(3, HIGH);
  cm = duration/51.3;
  Serial.print(duration);
  Serial.print("  :  Microseconds Echo; Distance: ");
  Serial.print(cm);
  Serial.print("  cm PDC 1");
  Serial.println();}

  if (check==0){
    Serial.println(" PDC 1 failure, Check Wire and Reset");}
  }

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Moin,

ich will mir das mit den Sensoren auch gern mal ansehen, verstehe ich es 
richtig ihr habt es nun mit der Schaltung nebst Code von Gabriel zum 
laufen bekommen?

Ich würde es gern mit diesem Sensor versuchen:
https://www.kfzteile24.de/artikeldetails?ktypnr=109274&returnTo=rm%3DshowArticles%26ktypnr%3D109274%26node%3D0%252C1%252C100335%252C100618%234&search=2270-118000

Zum einen hab ich den im PKW dann könnte ich die Sensoren mit dieser 
Schaltung testen (gerade ist einer defekt) und zum anderen möchte ich 
mein Wohnmobil gern damit nachrüsten.

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gabriel schrieb:
> pinMode(2, INPUT);

Warum definierst Du im Setup Pin2 als Output und dann im Loop on the fly 
als Input?

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe es mal getestet, kommt immer 0 cm.
Ich hoffe ich habe die Pins des PDC nicht vertauscht, hab am Stecker des 
Fahrzeugs gemessen

zwischen Pin 1 und 2 messe ich 8,5V   (plus dabei an Pin 1)
zwischen Pin 1 und 3 messe ich 7V     (plus dabei an Pin 1)
zwischen Pin 2 und 3 messe ich 0

daher bin ich von dieser Belegung ausgegangen
1 VCC
2 GND
3 Signal

Denkt ihr das passt so? Es ist den PDC aus meinem letzten Post. Im 
Internet finde ich über diesen leider nichts.

Autor: minifloat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olli Z. schrieb:
> Dabei ist eine logische "0" eine Sequenz aus einem langen LOW (125 uS):
> -.    .-----
>  |    |
>  |____|
>
> und eine logische "1" ist ein kurzes LOW (62,5 uS):
> -. .--------
>  | |
>  |_|
> Auch dieses Muster finden wir in unseren Scans. Leider fällt mir
> momentan kein passender Analyzer für einen solchen Code ein.

Ganz oben lese ich das...

Olli Z. schrieb:
> Das war direkt ein Treffer, zumindest scheinen die Daten
> sinnvoll (siehe "pdc-sensor_3.png"). Den Code habe ich als Textdatei mal
> angehangen.

... ein UART-Break und 0xE0 oder 0xFC. Erinnert mich daran, dass man 
Onewire-Chips mit einem UART bedienen kann. Muss nur auf Break prüfen 
und wenn nicht, das Low-Nibble auf kleiner 0x07 prüfen...

Pullup an RX
TX über Diode an RX, dass TX runterziehen kann
RX = Datenleitung

mfg mf

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
niemand eine Idee wie ich die Pinbelegung herausfinden kann?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mess mal den Widerstand zwischen den Pins. Der Data-pin müsste ja einen 
Pullup zu Vcc haben.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.