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

Hallöle.
Da brauche ich mich nicht wundern, wieso mein Monster nicht zurecht kommt. In der Front zwei HC-SR04 verbaut (jaha, die billigsten die zu kriegen waren), aber die Dinger funktionieren- jedenfalls bis ca. nen Meter.
Darüber- ab und zu.
Seltsam: nen Timeout gibt es nie, es wird immer irgendwas gemessen- bis rauf zu ungefähr 1.80m (ich habs echt mit verschiedenen Programmen versucht, auch mit verschiedenen Triggerzeiten usw, das Ergebnis ist immer hgalbwegs ähnlich), aber wenn ne Messung 1.70 ergab, bringt die nächste (ich habs auch mit 2s Verzögerung getestet, um irgendwelche Echos auszuschliessen) nur noch die Hälfte oder-irgendwas anderes.
Das Problem tritt bei beiden Sensoren (ich hab noch mehr, die aber jetzt nicht probiert) auf, es ist auch dann, wenn ich sie in der Hand halte (hatte schon was wie Körperschall vermutet, dürft sich so auch ausschliessen lassen), im Freien tritt es ebenfalls auf (auch, wenn ich sie senkrecht nach oben richte)- aber es gibt _immer_ ein Echo, jedoch nie weiter als knappe 2m.

Zugegeben: es sind etwas längere Kabel dran (~ 30 cm), aber _das_ dürft nicht das Problem sein, oder?
Versorgt werden die Brüder mit nem Stepdown-Wandler, es liegen fein 5.27V an..
Kennt das Problem jemand?
Gibts ne Lösung?

Hallo Sly !

Ich habe für mein Sokuti (Solarkunsttier) 5 Stück aus China bei ebay gekauft und warte auf Lieferung. Inzwischen habe ich mich bischen umgeschaut und etwas gelernt: https://www.roboternetz.de/community...ch-vom-HC-SR04 .

Angeblich würde ich davon nur den selektiven Verstärker mit LM324 verwenden und alles Übrige entfernen. Momentan kann ich dir nur empfehlen ohne der 30 cm langen "Antennen" und mit sauberer Spannungsversorgung aus Akku probieren. ;)

Neben den elektrotechnischen Fehlerquellen kann ich mir auch noch eine messtechnische vorstellen:
Es gibt 2 Messmethoden
Methode 1:
Die Dauer des Echopulses wird gemessen (Methode, die das Datenblatt vorschlägt).
Methode 2:
Zeit, die vergeht, bis der Sensor nach Triggerung einen Echo-Puls sendet, wird gemessen.

Ich sebst besitze keinen dieser Sensoren, also kann ich das nicht testen.
Ich hab mal einen Arduino-Testprogramm vorbereitet, das beide Methoden verwendet.
Das Ergebnis könnte aufschlussreich sein.

Code:

---

// Ultraschall-Test
// testet die Genauigkeit eines HC-SR04 Ultraschallsensors
// mit 2 Messmethoden:
//  1. measureAirTime
//      Zeit, die vergeht, bis der Sensor nach Triggerung
//      einen Echo-Puls sendet, wird gemessen.
//  2. measurePulseTime
//      Die Dauer des Echo-Pulses wird gemessen.
//
// Datenblatt:
// https://docs.google.com/document/d/1Y-yZnNhMYy7rwhAgyL_pfa39RsB-x2qR4vP8saG73rE/edit?pli=1
//
// Sisor, 23.08.2014

#define PIN_TRIG 8 // Hier Anschluss-Pins definieren
#define PIN_ECHO 9

void trigger() {
  digitalWrite(PIN_TRIG, HIGH);
  delayMicroseconds(10); // 10 µs Triggerzeit (siehe Datenblatt)
  digitalWrite(PIN_TRIG, LOW);
}

long measureAirTime() {
  unsigned long now;
  now = micros();
  trigger();
  while(digitalRead(PIN_ECHO) == LOW);
  return micros() - now;
}

long measurePulseTime() {
  // muss sofort nach measureAirTime()
  // ausgeführt werden!!!
  unsigned long now;
  now = micros();
  while(digitalRead(PIN_ECHO) == HIGH);
  return micros() - now;
}

void printResult(unsigned long airMicros, unsigned long pulseMicros) {
  Serial.print("measured air time  : " );
  Serial.print(airMicros );
  Serial.println(" us");
 
  Serial.print("measured pulse time: " );
  Serial.print(pulseMicros );
  Serial.println(" us");
 
  Serial.println("---");
}

void setup() {
  pinMode(PIN_TRIG, OUTPUT);
  digitalWrite(PIN_TRIG, LOW);
  pinMode(PIN_ECHO, INPUT);
  Serial.begin(57600);
}

void loop() {
  unsigned long airMicros, pulseMicros;
 
  // Messung durchführen
  airMicros  = measureAirTime();
  pulseMicros = measurePulseTime();
 
  // Ausgabe über Serial-Monitor
  printResult(airMicros, pulseMicros);
 
  delay(100);
}

---

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:

Code:

---

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:

Code:

---

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.

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.

Zitat:

---

... 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 :

Code:

---

// ============================================================================= =
//      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 ?

Zitat:

---

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

Zitat:

---

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.

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

Code:

---

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....

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?

Zitat:

---

... 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.

Zitat:

---

... 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.

Zitat:

---

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.

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...:shock:

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.

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 :cool:) 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?

Im Beitrag von PICture (vor allem im Link) steht, dass der Sensor gerne die erste Impulsantwort 'verschluckt', was natürlich zu Fehlmessungen führt.

Es ist dort auch von einer Änderung zweier Widerstände die Rede, welcher den Bandpassfilter auf die richtige Frequenz korrigieren soll.
Damit wäre dann die Empfindlichkeit des Sensors sehr deutlich erhöht.
Ob der Author allerdings richtig gerechnet hat, entzieht sich meinem elektrotechnischen Horizont (leider).

Ansonsten: Man sollte nicht zuviel von einem 2 Euro Sensor erwarten.

Zitat:

---

Zitat von Sisor

Man sollte nicht zuviel von einem 2 Euro Sensor erwarten.

---

Ist spezifikationstreue Funktion zuviel verlangt?
Ich habe eine handvoll von den Teilen zu einem ähnlichen Preis erworben und durchgetestet: alle funktionieren prima, keinerlei sichtbare Ausreisser bei den Messwerten.

@Rabenauge:
Hast du ein Oszilloskop bei der Hand? Dann sieh dir die Signale an und nicht das, was dir eine Bibliothek ausgibt. Ich glaube einfach nicht an einen derartigen Serienfehler sondern tippe auf ein SW-Problem.
Oder geh "back to the roots" und schreib die Messroutine selber.

Zitat:

---

Ich glaube einfach nicht an einen derartigen Serienfehler sondern tippe auf ein SW-Problem.

---

Nicht stichhaltig, da die Messungen bei kurzen Laufwegen zufriedenstellend funktioniert.

Zitat:

---

Oder geh "back to the roots" und schreib die Messroutine selber.

---

Das ist in diesem Thread bereits auf 2 Arten geschehen, die ohne externe Bibliothek auskommen.

Oszilloskop ist leider nich....und wie Sisor schon sagte: ich brauch keine Bibliothek für-der letzte Test war ohne (ausser Wire und LCD, da ich den PC hätte sonst ans Fenster tragen müssen-war bisschen unhandlich).

Ich würd ja auch glauben, dass es nen Softwareproblem wäre- das könnte ich nämlich beheben- aber es gibt irgendwie keine Erklärung für, wieso das Ding ein ankommenes Signal ausgibt, wenn vor dem Sensor nix weiter als nen paar Kilometer freier Luftraum sind.

Im übrigen sehe ichs auch so: die werden-egal wie billig nun-mit 4-5m Reichweite beworben-und genau die will ich auch haben. Nicht mehr und auch nicht weniger.
Dass allerdings drei der Dinger (okok, zusammen gekauft) die selbe Macke haben sollen, ist nicht so recht vorstellbar.
Probehalber werd ich die nächsten Tage (derzeit sitze ich an ner anderen Baustelle, das Monster betreffend) mal noch den 5. , isher unverbauten Sensor an nem Uno testen, mal gucken, was dabei rauskommen wird.

Falls noch jemand Ideen hat: raus mit der Sprache, bitte....:)

Der häusliche Kleiderschrank -sofern gut gefüllt- ist ein subjektiv schallarmer Raum. Vielleicht lässt sich hier eine äußere Schalleinwirkung (Glas, Bremsscheiben etc) aussperren, damit man die Ursache findet.

Hi,

ich nutze die srf05 und die sind echt genau, aber die kosten auch nen Teil mehr. habe eben mal nen Versuchsaufbau mit Arduino Mega 1 Pin Mode SRF05 gemacht.

Code:

---

155in, 396cm
155in, 395cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 396cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 396cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 395cm
155in, 396cm
155in, 396cm
155in, 396cm
155in, 395cm
155in, 395cm
155in, 395cm

---

Anhang 28943Anhang 28944

mit 2x2m Zöllis ;-)

cYa

@RoboHolIC: Danke für den Tipp aber-ich bin überzeugter Single. Da brauch ich keine 5m-Kleiderschränke. ;)
Und auf etwas über nem Meter tun die Gurken ja, was sie sollen...

@piggituX: auch dir Danke-allmählich keimt in mir die Befürchtung, dass ich mit den Teilen einfach auf die Nase gefallen bin-und zu billige genommen habe. Denn: ich hatte schon mal _einen_ HC-SR04, und der hat wunderbar funktioniert (leider ist mir _dieser_ eine, aus Doofheit, kaputt gegangen), mit dem Kann ich also nichts mehr anfangen.
Aber: schon rein optisch machte der deutlich mehr her als die jetztigen, und wenn ich die so vergleiche-er ist auch auf der Rückseite anders bestückt.
Er trägt vorne drauf die Aufschrift: "hexTronic HC-SR04", die billigen nur "HC-SR04", hat nur zwei Befestigungsbohrungen (diagonal in den Ecken), die billigen haben vier (dafür noch kleinere Durchmesser der Löcher, ist echt schwer, dafür noch Schrauben zu finden), und wie egsagt: hinden drauf siehts ähnlich, aber nicht gleich aus.
Der einzig lesbar beschriftete Chip ist bei dem vermeintlich besseren beschriftet mit "074C GZJ4252", bei den anderen heisst er "LM334 HYC 234H". auch sind bei dem "besseren" (ich weiss es nicht, aber der hat gut funktioniert, bis ich ihn aus Dusseligkeit kaputt gemacht habe) die Bauteile auf der Rückseite schön beschriftet, R1, R2, usw. was dem anderen auch völig fehlt.
Kann damit evtl. jemand was anfangen?

Zitat:

---

Zitat von Rabenauge

@RoboHolIC: Danke für den Tipp aber-ich bin überzeugter Single. Da brauch ich keine 5m-Kleiderschränke. ;)
Und auf etwas über nem Meter tun die Gurken ja, was sie sollen...

---

Selbst Großfamilien haben keine Kleiderschränke, die 5m durchgehend sind. Mein Vorschlag bezieht sich auf die Abklärung, ob die Teile externe Ultraschallstörungen einfangen, wenn jenseits der Laufzeit von 2x 1m kein reguläres Echo einrifft. Im US-schalltoten Raum kann man ja erwarten, das die Software einen Überlauf bringt. Das kann im Sinne der differentiellen Diagnostik weiterhelfen.

Nachtrag:

Ich war jetzt etwas unsicher geworden und habe meine sechs Module nochmals getestet. Es handelt sich um zwei verschiedene Produkte, 1 + 5 Stück aus zwei verschiedenen Käufen. Rechnungen finde ich grad nicht, aber der 5er-Pack hat nur unwesentlich mehr gekostet als der einzelne Sensor.
Die Unterschiede bei Bauteilbeschriftung "047C..." bzw. "LM324...." sowie Bestückungsdruck und Leiterplattenlayout kann ich bestätigen.
Meine Sensoren arbeiten aber, soweit ich das mit meinem analogen Oszi beurteilen kann, bis 2,5m Zimmerhöhe einwandfrei; ein tieferer freier Halb-Raumwinkel steht mir nicht zur Verfügung. Ins Freie oder gegen ein Filzkissen gerichtet kommt aber scheinbar unregelmäßige Pulsverläufe raus, die ich ohne Speicheroszi nicht genauer beurteilen kann. Insofern bestätigen sich Rabenauges Beobachtungen, nur, dass meine Sensoren eben deutlich weitere Messdistanzen in den Griff kriegen. Der einzelne teurere Sensor könnte sich aber dennoch etwas besser geschlagen haben als die billigeren - ohne jetzt ausdrücklich diesen Verdacht nähren zu wollen.

Was ich nicht getestet habe, sind Triggerabstände länger als 50ms; vielleicht weichen meine Sensoren in diesem Punkt ab. Die in meinem irgendwo gegrapschten Manual spezifizierten 38ms Echozeit bei fehlendem Hindernis waren jedenfalls nicht eindeutig erkennbar.

Zitat:

---

Zitat von RoboHolIC

Meine Sensoren arbeiten aber, soweit ich das mit meinem analogen Oszi beurteilen kann, bis 2,5m Zimmerhöhe einwandfrei . . . Ins Freie oder gegen ein Filzkissen gerichtet kommt aber scheinbar unregelmäßige Pulsverläufe raus, die ich ohne Speicheroszi nicht genauer beurteilen kann.

---

Ich hab's mit meinem selbstgebauten DSO (2kSPS, PIC16F877A, Pollin-GLCD 192x64) versucht und nun festgestellt, dass meine HC-SR04 bei Entfernungen ab etwa 2m nun doch deutliche Schwächen zeigen:
- die unmittelbare Nachbarschaft von langen und kurzen Echopulsen (sporadisch)
- völlig von der Spezifikation abweichende Pulsformen (durchgehend H, nur vom Triggerpuls unterbrochen, zusätzlich noch ein 3%-Einsacker bei 30ms)

Zitat:

---

Zitat von RoboHolIC

Insofern bestätigen sich Rabenauges Beobachtungen

---

Leider, leider ...

Zitat:

---

Zitat von RoboHolIC

Der einzelne teurere Sensor könnte sich aber dennoch etwas besser geschlagen haben als die billigeren

---

Nein, hat er auch nicht.

Zitat:

---

Zitat von RoboHolIC

Die in meinem irgendwo gegrapschten Manual spezifizierten 38ms Echozeit bei fehlendem Hindernis waren jedenfalls nicht eindeutig erkennbar.

---

Jetzt definitiv NICHT vorhanden.