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.
Angehängte Dateien:
-
pdc-sensor_1.PNG
3 KB -
pdc-sensor_2.PNG
3,6 KB -
pdc-sensor_3.PNG
9,8 KB
:
Verschoben durch Moderator
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?
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.
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.
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.
Guck mal hier: http://www.instructables.com/id/Hacking-Automotive-Ultrasonic-Sensors/?ALLSTEPS Das sieht mir ziemlich ähnlich aus.
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.
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.
Guido, das ist eine brilliante Idee! Werde ich gleich heute abend ausprobieren und berichten.
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!
Angehängte Dateien:
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...
Angehängte Dateien:
-
Ultraschall1.jpg
140 KB -
Ultraschall2.jpg
150 KB
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.
Angehängte Dateien:
-
Ultraschall3.jpg
190 KB
...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.
Angehängte Dateien:
-
Ultraschall4.jpg
280 KB
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
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.
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.
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.
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?
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
Angehängte Dateien:
-
sensor_ping.png
42 KB -
sensor_stopseq.png
25 KB
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.
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
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
Olli Z. schrieb: > könnte Guido > vielleicht mal mit seinem US-Mikro nachmessen Mache ich - Ergebnis kommt... 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 Wirklich eine super Hilfe ;-)
Angehängte Dateien:
-
US40kHz.jpg
400 KB
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.
Angehängte Dateien:
-
Send_Request_1.jpg
230 KB -
Receive_Request_1.jpg
230 KB
Hier noch die Screens mit Send- und Receive-Request
Angehängte Dateien:
-
Initialisierung1.jpg
120 KB -
Initialisierung2.jpg
320 KB
...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.
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.
Angehängte Dateien:
-
Init_G203.jpg
200 KB
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.
Angehängte Dateien:
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ß
Angehängte Dateien:
Es funktioniert einwandfrei mit PDC von VAG, Renault und Ford. Der Schaltplan:
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.
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.
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");}
}
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.
Gabriel schrieb: > pinMode(2, INPUT); Warum definierst Du im Setup Pin2 als Output und dann im Loop on the fly als Input?
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.
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
Mess mal den Widerstand zwischen den Pins. Der Data-pin müsste ja einen Pullup zu Vcc haben.
@ Phillip: Output : Low - Ping Das nächste Löw wird vom PDC gesetzt Daher Input Read Time Ping - Löw korreliert zum Abstand Die NewPing Lib kann passend umgeschrieben werden. PDC mit 5,5 V betreiben. Spannungsteiler am Pin, 5,5/5 V, Transistor kann dann wegbleiben. Time auf DSO bei definierte Abstände analysieren und den Code anpassen. Nachteil meiner Schaltung: die PDC werden nacheinander angesteuert und somit ist ein 4 PDC System unbrauchbar lahm. Es braucht ca 1,5 sek um 4 PDC zu lesen. Mit NewPing gelingt die Initialisierung quasi simultan. Beim Read ergeben sich geringe Abweichungen von unter 5 cm. Belegung: Sender zeigt nach vorne, von uns weg Links Minus Mitte Signal Rechts plus 5,5-8,5 V
Anbei der Schaltplan und der Code dazu, Funktioniert mit allen gängigen PDC Sensoren ( VAG, Renault, Ford). Für 6 PDC, wird genutzt für den toten Winkel Assistent, CAN Bus Anschluss, USB Anschluss, I2C Anschluss und ICSP. Zusätzlich 5 Analog IO. Die PDC werden mit ca 6,2 Volt betrieben und über 6 Shifter mit BSS 138 auf 5V gebracht. Die Schaltung ist gesichert ( Littlefuse 350 mA ), die korrekte Polung/ Verplolung der Stromversorgung wird durch LED ( grün / rot ) angezeigt. Die LED für Pin 13 wird über OP AMP gesteuert. Da der der OP AMP ein dual loW voltage ist habe ich zusätzlich noch eine LED an Pin A5 angeschlossen. Die SCK, MOSI und MISO Lötjumper sollten erst nach dem der BL gebrannt wurde, geschlossen werden. MC Atmega 328P, BL für Uno. NANO oder Pro Mini 5/16 geht natürlich auch. Die entsprechende Änderung des 5V Reglers nebst 8 MHz Quarz lässt den MC auf 3.3V laufen, BL ProMini 3.3 / 8MHz. Kritik und Vorschläge erwünscht. Grüsse aus Bukarest
Sehr interessant eire Arbeit. -Danke. PDC6.3.zip scheinen Target3001 files zu sein. Kann einer von euch zumindest den vollständigen Schaltplan auch als Pixelbild posten. - Ich habe leider kein Target 3001 um mir das anzuschauen. - Oder gibt es da irgendwo kostenlose Viewer? Danke und Grüße Oliver
Im Prinzip ja, denn Target 3001 kann man kostenlos runterladen. https://server.ibfriedrich.com/wiki/ibfwikide/index.php?title=DOWNLOAD
:
Bearbeitet durch User
Ga S. schrieb: > Anbei der Schaltplan und der Code dazu, Erstmal viele Dank für die Arbeit und die Veröffentlichung. Aber kann es sein, dass im Zip-File die Hauptdatei *.t300x fehlt ? Schönen Abend Sensorheino
Wahnsinn ! Was für eine Antwortgeschwindigkeit ! Vielen Dank ! und allen ein frohes und gesundes neues Jahr. Heino
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.