Kennt das jemand ? HC-Sr04 messen Mist...

[Rabenauge]

Danke euch beiden schonmal.
Zur Stromversorung: es handelt sich um so ein Modul: http://www.dx.com/de/p/dc-3-2-40v-to...w#.U_hekfxX18E
Meiner allerdings ist mit 2A angegeben-die Dinger verwende ich dauernd und bin damit eigentlich bestens bedient bisher..die Spannung für das Ding kommt aus nem Akku.
Umbauen ist nicht, da ich halbwegs die volle Reichweite auch brauche (evtl. reichen 2-3m aber die sind das mindeste).

Dein Programm hab ich eben mal probiert- airTime ist nix, womit man was anfangen könnte. Der Wert liegt, auch wenn ich die Hand fast direkt vor das Ding halte, immer so um die 450 herum, ebenso (er schwankt leicht, aber nicht sehr), auch bei grösseren Entfernungen.
Das funktioniert also nicht.
pulseTime dagegen nimmt proportional mit der Entfernung zu. Den Wert durch 58.2 sollte cm ergeben, das haut, so leidlich, hin, aber nur bis 1.20m, ungefähr. Danach wird es einfach nicht mehr...

Die Beispielprogramme zu diesen Sensoren sehn so aus:

const int TrigPin = 29;
const int EchoPin = 28;
float cm;
void setup()
{
Serial.begin(9600);
pinMode(TrigPin, OUTPUT);
pinMode(EchoPin, INPUT);
}
void loop()
{
digitalWrite(TrigPin, LOW); //Low-high-low level sent a short time pulse to TrigPin
delayMicroseconds(2);
digitalWrite(TrigPin, HIGH);
delayMicroseconds(10);
digitalWrite(TrigPin, LOW);
cm = pulseIn(EchoPin, HIGH) / 58.0; //Echo time converted into cm
cm = (int(cm * 100.0)) / 100.0; // retain two decimal places
Serial.print(cm);
Serial.print("cm");
Serial.println();
delay(1000);
}

Allerdings ergibt auch das nur Entfernungen bis ungefähr 1.20.  
Hab da schon extra ne Sekunde Verzögerung eingebaut, um irgendwelche "wilden" Echos auszuschliessen, hilft nix.
Merkwürdig finde ich, dass ganz offenbar das Echo ja empfangen wird- nur die Zeit stimmt irgendwie absolut nicht.
Ausserdem schwanken die Werte extrem: bei beiden Programmen sieht das ungefähr so aus:

122.63cm
93.12cm
76.56cm
88.37cm
90.70cm
74.18cm
91.18cm
121.86cm
77.96cm

Das ist die Ausgabe des von mir geposteten Programms, während der Zeit hat sich vor dem Sensor _nichts_ bewegt- aber mit dem Programm von Sisor sieht es ähnlich aus.

[oberallgeier]

Hallo Sly,

aktuell beschäftige ich mich in einem kleinen Team, aber eher am Rande, mit Ultraschall. Dabei waren mir eklatante Messfehler bei einem bestimmten Messaufbau aufgefallen. Als Grund dafür vermute ich Echos, die von einem anvisierten Objekt ausgestreut werden.

... Das ist die Ausgabe ... während der Zeit hat sich vor dem Sensor _nichts_ bewegt- ...

In dem Rahmen habe ich einen SRF02 getestet - eher nur auf Funktion geprüft :

// ============================================================================= =
//      Daten lesen vom Sensor SRF02, SLAVESR02 = 0xE0/224dez; Ausgabe auf UART0
//              Messvorgang
//      Um einen Messvorgang durchzuführen muss zuerst das Register 0 durch den 
//      Startbefehl (zum Beispiel Code 81/0x51) gestartet werden. 
//      Danach fügt man einfach einen Wartebefehl von 65 Millisekunden ein und 
//      fragt anschließend Register 2 und 3 nach der Entfernung ab. Das war´s scho
// - - - - - - - - - - - - - - - -

Die Genauigkeit hat mich (als alter IR-Sharp-Messfreak) schon begeistert, auch wenn er meine offene Zimmertür auf 2 m Entfernung als Hindernis anmisst. Aber eine Messreihe lief total aus dem Ruder. Dabei lag der Sensor auf dem Tisch und schallte senkrecht hoch an die Decke. Aktueller Messabstand rund 1m 76. Die hatte der Gute auch brav angemessen. Nach ner Weile streuten die Messwerte ähnlich wie Deine. Der Sensor war verschoben worden und peilte nun ne Deckenlampe an - so ne flachgedrückte Papierlampe. Offenbar war diese Lampe beim Anmessen zur Echo-Membran geworden, die mir die Messergebnisse verhunzte. Ein in die Lampe eingelegtes Stück Druckerpapier (80g/m³) beendete den Spuk, das Ergebnis war ziemlich konstant 1,48. Auch wenn ich das Papierblatt vor die Lampe hielt waren die Ergebnisse sinnig und recht ruhig.

Könntest Du ähnliche Probleme in Deinem Messaufbau haben ?

[Sisor]

Dein Programm hab ich eben mal probiert- airTime ist nix, womit man was anfangen könnte. Der Wert liegt, auch wenn ich die Hand fast direkt vor das Ding halte, immer so um die 450 herum, ebenso (er schwankt leicht, aber nicht sehr), auch bei grösseren Entfernungen.
Das funktioniert also nicht.

Ups, dann hatte ich die Funktion des Sensors falsch eingeschätzt.
Der Sensor schaltet also nach Triggerung den Echo-Ausgang solange HIGH, bis ein Echo auftritt.

---
User Manual S.7

When the sensor detected ultrasonic from receiver, it will set the Echo pin to HIGH and delay for a period (width)...

Dieser Teil der Anleitung ist also ist also falsch. Das Echo Pin wird immer sofort nach Triggerung auf HIGH gesetzt, und nicht erst nach einer Ultraschall-Impulsantwort.

[Rabenauge]

Hm, wenn ich das da: http://arduino.cc/en/pmwiki.php?n=Reference/PulseIn richtig interpretiere, dann ist dem tatsächlich so:
nach dem Triggern wird der Echo-Pin (vom Sensor selber) HIGH gesetzt, und wenn das Echo eintrifft, geht er auf LOW.
Die Zeit wird demnach gemessen, denn in den Beipielprogrammen wird ja immer

cm = pulseIn(EchoPin, HIGH) / 58.0; //Echo time converted into cm

benutzt.

Und diese wildgewordenen Echos-hm, ich glaubs nicht, denn ich hab zum einen in einigen Messreihen bewusst immer nach jeder Messung ne Sekunde (ich glaub, auch zwei schon) getrödelt, damit sich irgendwelche Echos verflüchtigen können und: selbst draussen, wenn ich den Sensor zum Himmel gerichtet hatte, gab es das Problem. Und nee: soo niedrig waren die Wolken auch wieder nich, dass ich schon mitm Kopf drin steckte.  

Ich hatte zuerst ja vermutet, dass die Dinger einfach zu "leise" sind (es sind wirklich die billigsten, die ich gefunden hab), aber dann gäb es gar kein Echo- das aber eben ist _nicht_ der Fall-es gibt immer eins, nur irgendwie viel zu schnell.
Und: inzwischen hab ich dreie von denen probiert-überall das selbe, auch mit etwas kürzerem Kabel.

Als nächstes werd ich mir wohl mal nen Testaufbau ausdenken, bei dem ich nur die Laufzeit messe (ohne jede Umrechnung), und das so, dass ich die Ausgabe noch irgendwie ablesen kann, auf 4m erkenn ich auf dem 16x2 LCD nämlich nicht mehr wirklich was.
Mal gucken, ob die soweit reichen oder nicht.
Möglicherweise trödelt der Sensor einfach intern irgendwo rum, und man kanns raus rechnen....

[Sisor]

1. pulseIn() kannte ich noch nicht, ist aber definitiv die richtige Wahl.
2. Ist deine Reflexionsfläche eine ebene harte Fläche, wie z.B. eine Zimmerdecke?

[oberallgeier]

... wohl mal nen Testaufbau ausdenken, bei dem ich nur die Laufzeit messe (ohne jede Umrechnung) ...

Das mache ich in der Testphase eigentlich immer. Ist doch egal welche Längeneinheit man hat - ob ADC-Werte, russische Werst oder Parsec - Umrechnen kann man immer noch später. Und meist bleibt der Code bei mir dann auch drin - allenfalls auskommentiert.

... Und diese wildgewordenen Echos-hm, ich glaubs nicht ...

Na ja, bei mir wars purer Zufall. Und ein schauderschönes Beispiel von Chaos, Interferenz, ungerichteter Abstrahlung etc. Eine (für mich wirklich unwahrscheinliche) Möglichkeit wäre noch ein vibrierender Sensor. Seit ich minikleine Brüllwürfel hab hüpfen sehen . . . aber bei Ultraschall müssten das schon s..schnelle Vibrationen sein; glaub ich hier nicht.

[Sisor]

Als nächstes werd ich mir wohl mal nen Testaufbau ausdenken, bei dem ich nur die Laufzeit messe (ohne jede Umrechnung), und das so, dass ich die Ausgabe noch irgendwie ablesen kann, auf 4m erkenn ich auf dem 16x2 LCD nämlich nicht mehr wirklich was.
Mal gucken, ob die soweit reichen oder nicht.
Möglicherweise trödelt der Sensor einfach intern irgendwo rum, und man kanns raus rechnen....

Da bin ich aber mal gespannt: Das Problem ist doch, dass der Sensor anscheinend beim gleichen Testaufbau unterschiedliche Werte ausspuckt.

[Rabenauge]

Diese "wilden" Echos halte ich schon prinzipiell für möglich, so isses nicht. Aber wenn die nach ner Sekunde nicht abgeklungen sind, gäbe mir das doch irgendwie zu denken....
Vibrationen-hm..während der Fahrt schon denkbar, immerhin haben die Reifen Traktorprofil mit zusätzlichen Stollen. Im Stand aber eher nicht: ich hab die Sensoren mit Stiftleisten bestückt, die wiederum in Streifenrasterplatinen gelötet, zusätzlich auf der Platine mit Heisskleber abgestützt und die Platinenstücke dann am Träger verschraubt. Und: sogar wenn ich den Sensor in der Hand halte, ist das Problem da...glaub nicht, dass ich mit nen paar KHz zittere...  

Allerdings ist mir noch was eingefallen: bei den Tests draussen gestern abend lief das normale Monster-Fahrprogramm. Dort nutze ich die NewPing-Bibliothek, und da die, bei Timeout (also wenn nix in Reichweite ist) ne 0 als Entfernung ausspuckt, hatte ich diese 0 dann auf maxRange gesetzt.
Somit konnt ein timeout praktisch gar nicht auftreten, auch nicht gen Himmel.
Dem muss ich auch noch nachgehen, dass hier drinnen nen Timeout nie eintritt, halte ich für vorstellbar, so gross ist die Bude echt nicht, und irgendwo steht immer was rum.

[Rabenauge]

Hab noch mal etwas rumgetestet, sowohl mit als auch ohne die NewPing-Bibliothek.
In beiden Fällen ist eine Messung immer um die 75cm (4400µS etwa) und die nächste deutlich weiter (meist sowas um nen 1.20m).
Auch dann, wenn ich gar kein Timeout-Limit setze und den Sensor aus dem Dachfenster (da sind dann 20km freie Sicht, und _kein_ Flieger im Umkreis von 10m ) halte dabei.
Bis etwa nen Meter stimmen die Messergebnisse übrigens recht gut, wenn ich innerhalb dieses Bereiches was bewege, haut das durchaus hin (dann gibts auch nicht abwechselnd Fehlmessung und korrekte Messung).

Was ich mich frage ist: wo zum Teufel kommt das Echo her, wenn weit und breit vor dem Sensor wirklich _gar_ nix ist?