Abstandssensor US-100 seriell ansprechen?

Hast Du noch einen weiteren seriellen Adapter? Dann könnte man zunächst einmal schauen ob die 0x55 überhaupt rauskommen und wenn ja, ob auch etwas zurückkommt. Oder einen 10€ Logic-Analyzer (auch immer mal nützlich für die Zukunft)

Karl-Heinz V. schrieb:

Diese Ultraschall-Sensoren

Welche genau?

sollen doch auch wie ein serielles Gerät mit 9600 Baud angesprochen werden können, wenn der Jumper auf der Rückseite gesteckt ist.

Sagt welches Datenblatt?

Karl-Heinz V. schrieb:

Ich habe das mit einem seriellen Interface Adafruit FT232H versucht an meinen PC (Linux) anzuschliessen.

Beachte dabei, dass die Beschriftung der Pins des US-100 etwas seltsam ist: Tx ist der Eingang und muss mit Tx des USB-UART verbunden werden. Rx ist der Ausgang und muss mit Rx des USB-UART verbunden werden.

Aber weder mit picocom und der Eingage eines "U" (= 0x55) oder eines "P" (= 0x50) bekomme ich irgendwelche Daten zurück.

Ich habe es auch mit einem Perl-Script probiert: ...

Der US-100 sendet die Daten binär als vorzeichenlose 16-Bit-Big-Endian- (Distanz) bzw. 8-Bit-Zahl (Temperatur). Von letzterer muss man noch 45 subtrahieren, um den Wert in °C zu erhalten. In Perl musst du die Daten mit /read/ lesen und mit /unpack/ konvertieren (s. Anhang).

Ich hab das noch mal mit dem Mikrocontroller ausprobiert, ein Raspberry Pi Pico W, auf dem das hinterher laufen soll und hab auch das Problem gefunden: man muss nach Starten der Messung etwas warten, bevor man Daten zurück bekommt. Auf dem Pico habe ich das MMBasic eines WebMite installiert (https://geoffg.net/webmite.html). Das funktioniert ganz gut ==> siehe Anhang us-100-seriell.bas

Danke für den Hinweis mit Abziehen von 45 von der Temperatur. Adafruit beschreibt das nicht: https://www.adafruit.com/product/4019. Ein richtiges Datenblatt hab ich nicht gefunden.

Und ich muss zugeben, dass ich hier mal wieder überreagiert habe. Der Webmite unterstützt den US-100 in seinem Basic. Mit:

Print Distance (gp0, gp1) ' gp0 = trig, gp1 = echo

einfach so. Man bekommt eine Gleitkommazahl: Distanz in cm. Und das Resultat ist viel präziser, als das Ergebnis des Sensor-Controllers. Die vom Webmite gemessene Distanz kann ich mit dem Zollstock nachmessen. Der interne Controller gibt ca 3 cm weniger aus (hier bei einer Entfernung von 11 cm im Messaufbau).

Wenn ich das fertig habe, soll das eine Webseite über den kontinuierlichen Füllstand meines Öltanks in Litern meiner Zentralheizung liefern.

Karl-Heinz V. schrieb:

Danke für den Hinweis mit Abziehen von 45 von der Temperatur. Adafruit beschreibt das nicht: https://www.adafruit.com/product/4019.

Na toll. Schon 5 Stunden nach dem OT kommt tatsächlich noch ein konkreter Hinweis darauf, um was es eigentlich geht.

Bravo!

Karl-Heinz V. schrieb:

Was mache ich falsch?

Du fügst keine Tags ein. Ich habe das mal für dich gemacht. Das nchste Mal bitte selber machen.

Karl-Heinz V. schrieb:

Danke für den Hinweis mit Abziehen von 45 von der Temperatur. Adafruit beschreibt das nicht: https://www.adafruit.com/product/4019.

Na ja - in der von Adafruit verlinkten PingSerial-Library steht es genau so drin (PingSerial.cpp Zeile 182).

1

   _temperature = read() - 45; // 45 is magic number for US-100

Rainer W. schrieb:

Na ja - in der von Adafruit verlinkten PingSerial-Library steht es genau so drin

Ja. Ich finde insbesondere den Kommentar richtig geil:

// 45 is magic number for US-100

Früher(tm) gab es Datenblätter, die damit genervt haben, wenigstens andeutungsweise zu erklären, wie die Scheiße funktioniert. Brauchen wir heute nicht mehr, da definieren wir eine magic number und alles wird gut...

Schöne neue Arduino-Welt...

Ob S. schrieb:

Brauchen wir heute nicht mehr, da definieren wir eine magic number und alles wird gut...

Früher saß irgendwo auf der Platine ein Trimm-Poti, mit dem der Nullabgleich gemacht wurde. Mit ein bisschen Glück wurde es nach dem Abgleich dann noch versiegelt.

Mit meinem Füllstandsmesser bin ich immer noch nicht weiter! Was ich zusammengebaut hatte, hat im WLAN nicht zuverlässig funktioniert. Das Signal war im Keller einfach zu schwach.

Ich hab jetzt einen anderen Controller für den Distanz-Sensor US-100 genommen: einen Seeed XIAO-ESP32C3. Mit dem messe ich dank der extra Antenne um 10 dB bessere Werte als mit dem Raspi Pico W, den ich eigentlich nehmen wollte.

Hier habe ich nochmal probiert, den US-100 seriell auszulesen (Jumper gesteckt). Hier passiert was merkwürdiges: häufig funktioniert das gut. Ich messe eine gleichbleibende Entfernung in mm und eine Temperatur von 21 Grad. Manchmal (nach einem Neustart) kommen vollkommen idiotische Werte dabei raus. Im Moment gerade 16897 mm und 66 Grad. Ich messe im Sekundentakt. Immer die gleichen Distanz-Werte, auch wenn man die Hand vor den Sensor hält.

Das passiert mit zwei verschiedenen Sensoren. Ziehe ich den Sensor im Betrieb ab und warte etwas, stecke den wieder ran: 355 mm und 21 Grad.

Und diese "magische Nummer 45" für die Temperatur-Korrektur? Ist das nicht einfach eine Umrechnung von Fahrenheit in Celsius für Doofe? Ich konnte kein Datenblatt finden (siehe Anhang) das überhaupt darauf eingeht.

Karl-Heinz V. schrieb:

Manchmal (nach einem Neustart) kommen vollkommen idiotische Werte dabei raus.

Ist jetzt zwar nur ein Schuß ins Blaue, aber zumindest beim ESP8266 gibt der Bootloader beim Start irgendwelche Debug-Daten mit 57,6 kBaud am seriellen Port aus; falls das beim ESP32 ähnlich ist, könnte das den Controller am US100 vielleicht manchmal verwirren bzw. abstürzen lassen? Eventuell mal einen anderen (gg. Soft-) Serial Port probieren oder den US100 etwas verzögert starten lassen könnte helfen.

Karl-Heinz V. schrieb:

das Resultat ist viel präziser, als das Ergebnis des Sensor-Controllers.

Der interne Controller gibt ca 3 cm weniger aus

Das spricht aber ohnehin stark dafür, die Auswertung selbst zu erledigen, wenn der interne Controller so fehlerhafte Werte liefert. Die passende Formel zur Entfernungsberechnung findet sich ja eh in dem Programmbeispiel in dem verlinkten Datenblatt: pulseIn liefert die Zeit (bis zum Eintreffen des Echos) in µs; die Hälfte davon ist die Zeit für die einfache Strecke. Der 'Umrechnungsfaktor' von 29.1 ist 10000/Schallgeschwindigkeit (in Luft, bei 20°C) in m/s. In den 10000 stecken die Umrechnungen von m in cm, sowie von s in µs.

Karl-Heinz V. schrieb:

Und diese "magische Nummer 45" für die Temperatur-Korrektur? Ist das nicht einfach eine Umrechnung von Fahrenheit in Celsius für Doofe?

Nö, dafür bräuchte es auch noch einen multiplikativen Faktor; das dürfte einfach eine Verschiebung des Wertebereichs sein, um auch negative °C messen bzw. in einem Byte (Wertebereich: 0-255) codieren zu können.