Abstandssensor US-100 seriell ansprechen?

[Karl-Heinz V. (khvolk)]

Diese Ultraschall-Sensoren sollen doch auch wie ein serielles Gerät mit 
9600 Baud angesprochen werden können, wenn der Jumper auf der Rückseite 
gesteckt ist. Ich habe das mit einem seriellen Interface Adafruit FT232H 
versucht an meinen PC (Linux) anzuschliessen. 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:

use Device::SerialPort;
my $port = Device::SerialPort->new("/dev/ttyUSB0");

$port->baudrate(9600); # Configure this to match your device
$port->databits(8);
$port->parity("none");
$port->stopbits(1);

while (1) {
    $port->write("P");
    my $char = $port->lookfor();
    if ($char) {
        print "Received character: $char \n";
    }
    $port->lookclear; # needed to prevent blocking
    sleep (2);
    print "\n";
    $port->write("U");
    my $char = $port->lookfor();
    if ($char) {
        print "Received character: $char \n";
    }
    $port->lookclear; # needed to prevent blocking
    sleep (2);
    print "-----------------\n";
}

Auch hier bekomme ich nichts geliefert. Was mache ich falsch?

[Harald A. (embedded)]

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)

[Ob S. (Firma: 1984now) (observer)]

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?

[Yalu X. (yalu) (Moderator)]

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

[Karl-Heinz V. (khvolk)]

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.

[Ob S. (Firma: 1984now) (observer)]

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!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Rainer W. (rawi)]

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

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

[Ob S. (Firma: 1984now) (observer)]

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

[Rainer W. (rawi)]

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.

[Karl-Heinz V. (khvolk)]

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.

[Michi S. (mista_s)]

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.