DYP-ME007Y Ultraschall Sensormodul

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,
    ich habe diesen Ultraschallsensor DYP-ME007Y Ultraschall Sensormodul

    an den Pi angeschlossen.
    Nach diesem Schema
    Schaltplan


    inkl. Widerstände usw.

    Auch das Script dieser Seite nutze ich.

    Wenn ich nun dieses Script ausführe, bekomme ich Werte die aber nicht stimmen können:
    Gemessene Entfernung = -1094.4 cm
    Gemessene Entfernung = -4373.6 cm
    Gemessene Entfernung = -1049.8 cm
    Gemessene Entfernung = -1113.7 cm
    Gemessene Entfernung = -1020.4 cm
    Gemessene Entfernung = -4407.6 cm
    Gemessene Entfernung = -4398.3 cm
    Gemessene Entfernung = -6030.0 cm
    Gemessene Entfernung = -1082.3 cm
    Gemessene Entfernung = -4330.4 cm
    Gemessene Entfernung = -11056.2 cm
    Gemessene Entfernung = -1049.8 cm
    Gemessene Entfernung = -6024.4 cm
    Gemessene Entfernung = -1065.9 cm
    Gemessene Entfernung = -2763.7 cm
    Gemessene Entfernung = -1087.4 cm
    Gemessene Entfernung = -4375.6 cm
    Gemessene Entfernung = -1009.9 cm
    Gemessene Entfernung = -7701.1 cm
    Gemessene Entfernung = -2766.4 cm
    Gemessene Entfernung = -1045.9 cm
    Gemessene Entfernung = -9373.5 cm
    Gemessene Entfernung = -1070.3 cm
    Gemessene Entfernung = -2739.1 cm


    Woran kann das liegen?
    Stimmen die Widerstände unter Umständen nicht für den Sensor?
    Ich finde keine Anleitung für den Sensor und bin elektrotechnisch noch in den Anfängen.

    Gruß - Keith

  • Hallo, KeithKeith;
    Das script von wo benützt Du?

    Reine Verkabelung müsste zu dem im Bild dargestellten Sensor passen. Aber Du schreibst von "DYP-ME007Y", der nach Google-Suche ganz anders aussieht und 20$ kostet?

    <recherchier>OK, der Sensor scheint identisch in den Anschlüssen zu sein</recherchier>
    Dann bleibt die Frage nach dem Code und ob Du vielleicht die falschen GPIO's eingetragen hast. Dein Schema ist an 18/24 angeschlossen, ein häufig verwendetes script sieht 17/18 vor. -Vielleicht nicht angepasst?

    rasray

    Einmal editiert, zuletzt von rasray (12. Januar 2016 um 17:57)


  • Hallo, KeithKeith;
    Das script von wo benützt Du?

    Reine Verkabelung müsste zu dem im Bild dargestellten Sensor passen. Aber Du schreibst von "DYP-ME007Y", der nach Google-Suche ganz anders aussieht und 20$ kostet?

    <recherchier>OK, der Sensor scheint identisch in den Anschlüssen zu sein</recherchier>
    Dann bleibt die Frage nach dem Code und ob Du vielleicht die falschen GPIO's eingetragen hast. Dein Schema ist an 18/24 angeschlossen, ein häufig verwendetes script sieht 17/18 vor. -Vielleicht nicht angepasst?

    rasray

    Hallo rasray,
    diese Script:

    Danke für Deine Hilfe :)
    Gruß - Keith

  • Hallo KeithKeith,

    Aufgrund des fehlenden Scriptes ist eigentlich alles Kaffeesatzleserei. Die Schaltung könnte funktionieren - das Datenblatt habe ich mir allerdings nicht angesehen. Per Spannungsteiler bekommst Du (vermutlich) 5V*47Ohm/800Ohm = 2,9V am GPIO Eingang. Das sollte soeben reichen, um als gültiges Hi-Signal erkannt werden zu können.

    Zu den Daten. Zunächst fallen ganz offensichtliche negative Werte auf. Das würde man bei einer richtungslosen Wegmessung nicht erwarten. Hier könnten Integerüberläufe oder falsches Casten des Scripts eine Rolle spielen. Geht man mal davon aus, daß Du bei Deinem Meßaufbau die Entfernung zwischen Sensor und Objekt konstant gelassen hast, dann könnte man weiter orakeln...

    Sortiert man die Werte der Größe nach, so ergibt sich eine Häufung der Werte zwischen -1009 und -1114. (die knappe Hälfte der Werte liegt da). Der Rest liegt zwar weiter entfernt - dennoch lassen sich Paarungen nahe beieinander liegender Werte finden.

    -1009,90 -1020,40 -1045,90 -1049,80 -1049,80 -1065,90 -1070,30 -1082,30 -1087,40 -1094,40 -1113,70
    -2739,10 -2763,70 -2766,40
    -4330,40 -4373,60 -4375,60 -4398,30 -4407,60
    -6024,40 -6030,00
    -7701,10
    -9373,50
    -11056,20

    Das ist insofern interessant, als daß Du kein typisches Fehlerbild eines floatenden Signales siehst. Letzteres würde eher gleichverteilt schwanken. Die Schwankungsbreite würde sich nach der Größe des einkoppelnden Signales richten. Auf jeden Fall ergeben sich in so einem Fall keine Häufungen an diskreten Wertebereichen.

    Die Häufungen lassen also vermuten, daß der Aufbau tatsächlich mißt, der Fehler sonach wohl eher auf Softwareseite zu suchen wäre. Schau' Dir mal kritisch die Datentypen der verwendeten Variable an, ob da irgendetwas überläuft oder abgeschnitten wird. Auch Zeitüberläufe bei Timern kann man mal näher beleuchten - wenngleich fast kein Timer so klein ist, daß er innerhalb der (ich vermute "kurzen") Meßdauer überläuft.

    Aber wie gesagt - das ist hier alles Spekuliererei, betrachtet unter dem Aspekt "versuch mal das Beste aus dem gegeben Datenhaufen zu machen". No less, no more!

    Wenn Du mehr Support willst, dann wirst Du vermutlich nicht umhin kommen, dem Forum Deine Software zu zeigen :) . Vorbereitenderweise solltest Du aber lieber die gemessenen Roh-Zeitwerte posten, als fertig berechnete Entfernungen. Dann läßt sich besser überprüfen, wo der Fehler liegt.

    Ob die Rohwerte plausibel sind läßt sich vermutlich am einfachsten überprüfen, wenn Du die Wegstrecke verdoppelst. Ich würde annehmen, daß die Signallaufzeit sich dann vervierfacht (Hin- + Rückweg). Zudem sollten die Rohwerte bei konstantem Weg auch nur im Rahmen der Meßungenauigkeit schwanken.

    Gruß

    schnasseldag
    Automatisch zusammengefügt:


    Huch, da kamen aber viele Informationen, während ich hier tippte :s

  • ...wenn alle Werte ein negatives Ergebnis liefern, müsste ja die ermittelte StopZeit VOR der StartZeit liegen...?
    Also, wie sieht es mit den Einrückungen aus?

    Braucht man wirklich diese zwei Zeilen:

    StartZeit = time.time()
    StopZeit = time.time() ?

    rasray

  • Ich habe hier ein Minimal-Script, weiß leider nicht mehr, woher. Aber dieser Code funzte bei mir am HCSR04 ohne Probleme.
    Lang lebe der unbekannte Erschaffer dieses Codes :danke_ATDE:
    Hier wird der Trigger-Pin vor dem Messvorgang absichtlich nochmal auf false gesetzt.


  • Ich habe hier ein Minimal-Script, weiß leider nicht mehr, woher. Aber dieser Code funzte bei mir am HCSR04 ohne Probleme.
    Lang lebe der unbekannte Erschaffer dieses Codes :danke_ATDE:
    Hier wird der Trigger-Pin vor dem Messvorgang absichtlich nochmal auf false gesetzt.

    Hallo,
    hab's getestet.

    Code
    ~ $ sudo python ultr.py
    ultr.py:8: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
     GPIO.setup(trig_pin,GPIO.OUT)
    Waiting to settle
    Traceback (most recent call last):
     File "ultr.py", line 24, in <module>
       duration = end - start
    NameError: name 'end' is not defined

    Mit dem HC SR04 läuft Dein Script.
    Mit dem DYP-ME007Y leider nicht.
    Ich verwende ja diese Schaltung inkl Widerstände usw. muss ich dabei etwas ändern?

    Gruß Keith
    Automatisch zusammengefügt:


    Evtl. mal den Trigger auf 20µs setzten.

    Wie mache ich das?
    :)

    Gruß Keith
    Automatisch zusammengefügt:


    ...wenn alle Werte ein negatives Ergebnis liefern, müsste ja die ermittelte StopZeit VOR der StartZeit liegen...?
    Also, wie sieht es mit den Einrückungen aus?

    Braucht man wirklich diese zwei Zeilen:

    StartZeit = time.time()
    StopZeit = time.time() ?

    rasray

    Hi,
    irgendwie gelingt mir das EInrücken nicht.
    Ich nutze diesen Code, dieses Beispiels:
    Beispiel

    Gruß Keith
    Automatisch zusammengefügt:

    Danke für diese ausführliche Antwort.
    Ich verstehe auch ca 20% davon - klasse, ne ;)
    Ne, mal im Ernst. Ich bin Anfänger und verstehe kaum etwas von dem, was Du hier schreibst.

    Gruß Keith
    Automatisch zusammengefügt:
    NOchmal getestet mit dem DYP-ME007Y :

    Code
    $ sudo python ultr.py
    ultr.py:8: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
     GPIO.setup(trig_pin,GPIO.OUT)
    Waiting to settle
    Traceback (most recent call last):
     File "ultr.py", line 24, in <module>
       duration = end - start
    NameError: name 'end' is not defined

    Gruß Keith
    Automatisch zusammengefügt:
    So,
    jetzt habe ich mal einen DYP-ME007Y ohne langes Kabel inkl Sensor angeschlossen.
    Der Sensor ist auf der Platine.
    Dieser Sensor liefert "richtig" Werte und ab ca 30 cm entfernung sogar ganz okay

    (30,7 / 31 / usw)

    Also ist der Sensor "mit Kabel" wohl defekt, oder?
    Gruß Keith

    Einmal editiert, zuletzt von KeithKeith (15. Januar 2016 um 13:32)

  • Hiho KeithKeith;

    so ganz komme Ich noch nicht mit:
    -Du hast zwei verschiedene Versionen des Sensors?
    -Bei einem ist der Sensor direkt in der Platine aufgesteckt? (funktioniert?)
    -Der andere wird mit einem langen Kabel an die gleiche Platine angeschlossen, also sowas: dyp.pdf? (funktioniert nicht?)

    Ansonsten: Trigger auf 20µs bedeutet: "time.sleep(0.00002)"

    Die Widerstände müssten auch zu diesem Sensor passen. Er wird vom Pi mit 5V Spannung versorgt und würde über den Echo-Pin auch 5V als Signal liefern, am GPIO sollten aber maximal 3,3 V ankommen.
    Der eine Widerstand ist ungefähr doppelt so groß wie der andere. Die Spannung teilt sich dadurch genau im umgekehrten Verhältnis auf; 3,3 Volt gehen zum Pin, die Hälfte zu Ground -> 1,65 Volt
    :auslachen: Dat issene Läwwelschifter

  • Ja, genau das :)
    Die Werte beim Sensor auf der Platine stimmen zwar nicht ganz (10 cm zu wenig), aber immerhin.
    Beim Sensor mit langem Kabel zur Platine stimmt nix (negative Werte)
    Gruß - Keith

  • ...also hast Du jetzt zwei Platinen?
    ...oder ist bei beiden Sensoren die gleiche Platine im Einsatz (Fehlereingrenz)?

    Code
    NameError: name 'end' is not defined

    -> diese Meldung kommt dann von dem Sensor mit langem Kabel?
    Bin nicht weniger Anfänger als Du, den Fehler interpretiere Ich aber so, dass kein Echo ankommt??? Weise gefragt!
    Langes Kabel: Da kann auch was vom Saft verloren gehen; also Frage nach ausreichend starkem Netzteil?

    Zuguterletzt: Habe beim kugeln tatsächlich etliche Posts gefunden, die auf "Schlottploduktion" hindeuten. Fände Ich bei dem Preis aber nicht im Sinne von Konfuzius.

    Einmal editiert, zuletzt von rasray (15. Januar 2016 um 17:56)


  • ...also hast Du jetzt zwei Platinen?
    ...oder ist bei beiden Sensoren die gleiche Platine im Einsatz (Fehlereingrenz)?

    Code
    NameError: name 'end' is not defined

    -> diese Meldung kommt dann von dem Sensor mit langem Kabel?
    Bin nicht weniger Anfänger als Du, den Fehler interpretiere Ich aber so, dass kein Echo ankommt??? Weise gefragt!
    Langes Kabel: Da kann auch was vom Saft verloren gehen; also Frage nach ausreichend starkem Netzteil?

    Zuguterletzt: Habe beim kugeln tatsächlich etliche Posts gefunden, die auf "Schlottploduktion" hindeuten. Fände Ich bei dem Preis aber nicht im Sinne von Konfuzius.

    Ja, zwei Platinen
    eine mit festem Sensor
    und eine mit 1,5m Kabel
    Strom vom PI
    Ich teste das mal mit einem Netzteil und melde mich wieder :)

    Gruß Keith

  • ey, Mann, meinen Käse ein Mal zu lesen, ist schon schlimm genug!
    Nimm doch lieber den motivierenden, frühlingsgrünen Antwort-Button unter dem Beitrag und nicht das frustrierende, tristgraue "Antworten (=Zitieren).
    Ich dachte, das Kabel wäre länger, 1,5 m sollte kein Problem sein. Sind die Pin-Bezeichnungen der beiden Platinen wirklich identisch?

  • Nun ja, gleicher Sensor, gleicher Code; der eine geht, der andere nicht -Da fällt mir auch nix Schlaues mehr ein.
    Verzweiflungstest: Trigger auf 2µs und dann mal start + end ausgeben lassen:

  • Vermutlich kenne ich Dein Problem:

    Es scheint von den DYP-ME007Y verschiedene Versionen zu geben, der für dieses Script notwendige ist wohl der am meisten verbreitete aber wohl immer öfter nicht zu bekommen. Stattdessen bekommt man eine Version mit serieller Datenübertragung, die eigentlich DYP-ME007Y-TX heissen müsste, aber wie in meinem Fall nicht so gekennzeichnet ist.

    Vor lauter Frust habe ich mein Oscar angeschlossen und siehe da, auf dem ECHO Pin wird ein serielles Signal ausgegeben: 4 Byte 9600Baud 8N1 und der Sensor misst fortlaufend und nicht erst nach Aufforderung, zu erkennen an der blinkenden LED. Google lieferte mir nach langer Suche eine Seite wo zumindest kurz beschrieben war wie die Daten zu interpretieren sind. Startbyte 0xFF, High-Byte der Entfernung, Low-Byte der Entfernung und ein Prüfsummen-Byte (nur das) Low-Byte.

    Da ich das Teil aus China hatte und nicht reklamieren wollte, habe ich mich als blutiger Anfänger mit dem Raspberry und Google-"Hilfe" daran gesetzt, das Script anzupassen. Das ist dabei herausgekommen und funktioniert :thumbs1:

    #Bibliotheken einbinden
    import time
    import serial

    #seriellen Port einstellen
    ser = serial.Serial("/dev/ttyAMA0")
    ser.baudrate = 9600

    #Funktionen
    def distanze():
    startbyte = ord(ser.read(1))
    while startbyte <> 255:
    startbyte = ord(ser.read(1))
                    
    hbyte = ord(ser.read(1))
    lbyte = ord(ser.read(1))
    sbyte = ord(ser.read(1))
            
    distanz = hbyte * 256 + lbyte

    summe = startbyte + hbyte + lbyte
    summe = summe - (int(summe/256) * 256)
    if summe <> sbyte:
    distanz = 0
    print(startbyte, hbyte, lbyte, sbyte, distanz)
                    
    return distanz

    #Hauptprogramm
    if __name__ == '__main__':
    try:
    while True:
    abstanda = distanze()
    abstandb = distanze()
    vergleiche = 3
    while vergleiche > 0:
    vergleiche = vergleiche - 1
    if abstanda == abstandb:
    gleich = True
    abstandb = abstanda
    abstanda = distanze()
    else:
    gleich = False
    break


    if gleich == True:
    print ("Gemessene Entfernung = " + str(abstandb) + " mm")
    time.sleep(1)

    # Beim Abbruch durch STRG+C resetten
    except KeyboardInterrupt:
    print(" Messung vom User gestoppt ")


    Ist vielleicht nicht ganz sauber programmiert aber läuft. Zu beachten ist das der vermeintliche ECHO-Pin vom Sensor der Tx Pin ist und auf Rx (GPIO15 - UARTT0 RXD) am Raspi angeschlossen werden muß, aber bitte mit Levelshifter. Bei mir habe ich festgestellt, das 470 Ohm zu wenig sind, ich habe 10 kOhm genommen um auf ca. 3V zu kommen. Hängt vermutlich mit dem Tx Ausgang des Sensors zusammen. Der Trigger/Rx Eingang des Sensors wird nicht benötigt, ob man damit evt. dem Sensor noch Einstellungen senden kann hab ich mit Hilfe von Google nicht herausgefunden.

    Das Script besteht aus der Funktion distanze() welches nach erfolgreichem lesen des Startbytes, die 3 Folgebytes liest und prüft. Bei distanz = 0 ist ein Fehler aufgetreten. Das Hauptprogramm ließt nacheinander 2 Werte ein und vergleicht 3 Nachfolgewerte. Erst wenn 3mal nacheinander der gleich Wert gelesen wurde kommt es zur Ausgabe. So verringere ich falsche Messungen.

    Der Vorteil des seriellen Sensors ist die Genauigkeit, diese ist nämlich jetzt unabhängig von der Geschwindigkeit des Scriptes!

    Viel Spaß beim Testen...

    Einmal editiert, zuletzt von kaiserem (1. März 2016 um 18:44)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!