Bin ich zu doof jetzt oder hab ich hier fünf kaputte Sensoren?

Hallöle.

Ich mal wieder- versuche seit zwei Tagen, meinem Krabbler einen US-Sensor (die bekannten HC-Sr04) beizubringen- er will ihn nicht.
Verzweifelt ausgelötet, aufs Steckbrettel getackert, Uno dran, angehängtes Testprogramm dazu, und es schreibt mir die Konsole brav voll mit 0:0
Mit dem Uno hab ich es deshalb versucht, weil ich am Pro Mini (mit dem das Ding eigentlich laufen soll) eine etwas -kreative- Anschlussvariante gewählt hab, also um sicher zu gehen.
Fazit: er ist wohl kaputt.
Kein Problem, ich hab noch welche- inzwischen hab ich alle rumschwirrenden fünf Stück versucht, keiner gibt _irgendwas aus.
Direkt am Uno betrieben (und ja, der hat 5V), und natürlich auch den Pindefinitionen im Programm entsprechend angeschlossen.

Irgendwie nich zu glauben, dass die alle kaputt sein sollen- aber im Code find ich auch nichts unanständiges? Zugegeben, schön ist der Code nicht (fix zusammengeschustert, ist ja nur zum Testen), aber laufen müsste das doch?
Guckt bitte mal drüber....der ist ok so oder?

int triggerFront=4;
int echoFront=5;
long distanzFront;

void setup() {
 pinMode(triggerFront,OUTPUT);
 pinMode(echoFront,INPUT);
 Serial.begin(9600);
}

void loop() {
 long zeit;
  digitalWrite(triggerFront,LOW);
  delayMicroseconds(2);
  digitalWrite(triggerFront, HIGH); //Trigger Impuls 10 us
  delayMicroseconds(10);
  digitalWrite(triggerFront, LOW);
  zeit = pulseIn(echoFront, HIGH,500); // Echo-Zeit messen
  Serial.print(zeit);
  Serial.print(":");
  distanzFront = zeit / 58.2;
  Serial.println(distanzFront);
  delay(500);
}

Deine Anweisung "pulseIn" hat einen Parameter zu viel.
Sieh dir dazu ein Beispiel für den US-Sensor an.
Beispiel

HotSystems:
Deine Anweisung "pulseIn" hat einen Parameter zu viel.
Sieh dir dazu ein Beispiel für den US-Sensor an.
Beispiel

Es gibt pulsIn mit 2 und mit 3 Parametern

Syntax
pulseIn(pin, value)
pulseIn(pin, value, timeout)

siehe: pulseIn() - Arduino Reference

Nimm doch zum testen ein Beispiel aus einer bewährten Lib, z.B. newPing

Genau so isses.
Der dritte Parameter ist das Timeout-ohne das wartet nämlich pulseIn ne volle Sekunde- das dauert mir zu lange.
Wird später dann noch mal deutlich beschleunigt (nicht-blockierend), wir haben da im RN neulich ne Idee zu gehabt, die zu funktionieren scheint.

Und nein: für eine so simple Geschichte benutz ich keine Bibliothek.

Ne bewährte Lib zum testen willste nicht nehmen, aber von den anderen verlangen, dass sie über deinen selbst schnell zusammen genagelten Sketch drüber schauen.

Das verstehe wer will

Hi

Setze das Timeout (wesentlich) höher.
Der Beispiel-Sketch ändert das Timeout bei der ersten 0-Messung auch auf 23000 (um den Dreh).

Trigger und Echo sind nicht vertauscht?
(man kann Trigger und Echo auch zusammen legen - Das habe ich aber bisher nur in ASM so abgefragt - hatte dort aber auch viele Hausnummern)

Momentan empfange ich 11 (oder 21?) Messwerte und nehme den 'dingsbums'-Mittelwert (nach Größe sortiert, Den in der Mitte) - Das klappt halbwegs. (alternierend? bin jetzt zu faul zum googeln und außerdem schon im Bett ... eigentlich)

MfG

PS: Habe Die hier: ST_HW_HC_SR04

dingsbums’-Mittelwert

Median

Idealerweise nimmt man den RunningMedian

Rabenauge:
Und nein: für eine so simple Geschichte benutz ich keine Bibliothek.

Dann nimm den Timeout doch mal raus.

Dann ist es wie im Beispiel von mir.
So funktioniert es bei meinem Test.

Und danke an uxomm für die Aufklärung.

Danke Jungs- das Timeout wars wirklich.

Ich hab mal wieder Milli-und Mikrosekunden durcheinander gebracht (und nebenbei vergessen, dass der Sensor sowieso ne eingebaute Verzögerung von 450µs hat).
Klar-in 50µs geht mit lahmem Schall nix mehr. :o

Zur NewPing: die ist keineswegs sonderlich "bewährt": ich hatte damit mal eine Weile herumprobiert und die Ergebnisse waren eher- ernüchternd. Das lief viel zu unzuverlässig...
Da kann man genausogut bei pulseIn bleiben (das klappt, blockiert aber genauso wie delay).
Einzig das Handling mehrerer US-Sensoren vereinfacht die NewPing ein bisschen.

Aber man kann die US-Sensoren durchaus auch nicht-blockierend handhaben (wahrscheinlich tut die NewPing es in dieser oder ähnlicher Weise)- die Idee hab ich neulich im Roboternetz mal schnell gedanklich entworfen, und ein anderer User hats erfolgreich probiert.
So will ich das bei meinem Crawler auch machen (der ist langsam genug, dass er weiter laufen kann in der Zwischenzeit, so schnell kommt da kein Hindernis näher). Da gibts keinen Grund, zu warten, bis Pulsein mal ausgetrödelt hat.

Wie auch immer- die Sensoren sind nicht kaputt (und ersparen mir somit nen paar Tage Wartezeit auf nen neuen)- Danke!

Rabenauge:
Wie auch immer- die Sensoren sind nicht kaputt (und ersparen mir somit nen paar Tage Wartezeit auf nen neuen)- Danke!

na man gut, das man so ein :grin: Forum :grin: hat.

Und wenn es nicht blockierend sein soll, verwende doch für die US-Sensoren einen eigenen Controller (z.B. ATtiny85).

Nö- muss man gar nicht.
Man verbindet den Echo-Pin ganz einfach mit nem interruptfähigen Eingang.
Dann kann man sich das pulseIn-Getrödel sparen.
Beim auslösen der Messung (triggern) werden die Micros gemerkt, und in der ISR dann wieder- schon kann man die Laufzeit berechnen, und während der eigentlichen Wartezeit noch paar andere Dinge tun.
Abholen kann man das Ergebnis danach.