Ultraschall - Entfernunsmessung mit Ultraschall Interface aus RN

[Searcher]

Mit US habe ich noch nichts gemacht, deshalb ist die Frage vielleicht blöd. Warum macht ihr es nicht so?

Keine Ahnung. Dann hätten wir keine Probleme mit dem Interrupt Timing und wir müßten kein ASM lernen

Nein, etwas ernster: Ich denke nicht, daß das speziell was mit Ultraschall zu tun hat. Per Interrupt zu messen hätte den Vorteil, daß während der Meßzeit noch was in der Hauptschleife gemacht werden könnte. In der while Schleife zu zählen ist sehr einfach und ressourceschonend, vielleicht auch genauer, blockiert aber während der Meßzeit die Hauptschleife.

Thegon müßte auswählen, was besser in sein Konzept paßt. Ich würde für diese Anwendung wahrscheinlich per Interrupt und einem 16Bit Timer messen. Hoffentlich kommt die HW zum Probieren ans Laufen.

Gruß
Searcher

[radbruch]

Hallo

Danke für die "ernste" Antwort. Ein paar Millisekunden nicht blockierende US-Auswertung gegen schlanken Code. Ich verstehe ;) In der Praxis wird es wohl eh ein blockierendes getAbstand() werden...

Was mir noch aufgefallen ist: Der US-Simulator antwortet schon beim ersten Low des Burst, der echte Empfänger wird wohl mehrere Amplituten benötigen bevor er anspricht. Da sind dann wohl schnell ein paar waitus 11 zusammen. Da bringt das µs-Optimieren bei der Timerlösung auch nicht mehr viel.

btw. Vom Knicklenker zum Programmierer. Klasse wie du das geschafft hast.

Gruß

mic

[Searcher]

Hallo radbruch,

Der US-Simulator antwortet schon beim ersten Low des Burst, der echte Empfänger wird wohl mehrere Amplituten benötigen bevor er anspricht

ich bin mir da nicht so hundertprozentig sicher und "glaube", daß durch das Flip-Flop an "Pulse in" schon beim Eintreffen des ersten low des ersten Pulses des Bursts sofort der "Pulse out" auf low gebracht wird. Zum Meßende (Pulse out wieder auf high) braucht es dann die Anschwingzeit und die Schalllaufzeit.

Ist aber zum Test des Meßprogramms nicht so wichtig. Da wird man sicher noch kalibrieren müssen.

PS.

Vom Knicklenker zum Programmierer. Klasse wie du das geschafft hast

Danke *stolz* . Das RN hat sicher einen sehr großen Anteil daran! Je mehr ich lese (und auch Deine Projekte betrachte), desto mehr ist mir bewußt wie sehr ich noch am Anfang stehe.

Gruß
Searcher

[Besserwessi]

Das Flipflop wird schon auf den ersten Impuls ansprechen. Die Frage ist aber wie das mit dem Schwingkreis ist. Der wird für die volle Amplitude ein paar mehr Perioden brauchen und entsprechend kann man eine Verzögerung von 1-2 Perioden des 40 kHz Signals, also 25-50 µs an Verzögerung durchaus schon mal bekommen, wenn das Signal zu schwach ist um sofort zu reagieren.

[radbruch]

ich ... "glaube", daß durch das Flip-Flop an "Pulse in" schon beim Eintreffen des ersten low des ersten Pulses des Bursts sofort der "Pulse out" auf low gebracht wird.

Das glaube ich nicht. Im Empfänger wird doch wohl irgendwas eingebaut sein das durch den Burst über den Schalldruck in Schwingung versetzt wird. Und dieses "irgendwas" benötigt sicher einige Schwingungen bevor es so sehr mitschwingt dass es reicht, den FlipFlop anzusteuern. Wenn das nicht so wäre, würde ein Burst mit nur einem Impuls ausreichen.

Lösung? Die Anzahl der Bursts langsam erhöhen bis ein Empfang erkannt wird. Dann erst die Laufzeitmessung mit den zuvor ermittelten Bursts.

[PICture]

Hallo!

Ich gebe dem Searcher vorsichtig Recht, weil für mich die Empfängerkapsel grundsätzlich ein US Mikrophon und kein Schwingkreis ist.

Ubrigens, wie bei jedem Mikrophon gibt es sicher mechanische "Resonanze", die aber üblicherweise ausser nutzbarem Frquenzbereich liegen sollten.

[RoboHolIC]

Einspruch, Euer Ehren!
Was ich an Datenblättern über US-Kapseln bisher gesehen habe, waren keine Mikrofone im engeren Sinne sondern schmalbandige Detektoren. Schließlich macht die Schmalbandigkeit auch Sinn, damit der Sensor sich nicht bei jedem Klirren irgendeines Blechs, Glases, PWM-fiependen Motors etc. gleich angesprochen fühlt und ein Signal erzeugt. Sowohl Sender als auch Empfänger machen Einschwingvorgänge durch, die die Zeitauflösung von Laufzeitmessungen auf ein Mehrfaches der Periodendauer der Arbeitsfrequenz begrenzen.

[Thegon]

Hallo,
kommt ja ganz shön was zusammen, wenn man mal kurz nicht hin schaut

Zu den Zeiten, die entstehen, wenn Filter bzw. der Empfangswandler anschwingen müssen:

Ich hatte eigentlich vor, die entgültige umrechnung der Timeroverflows in eine echte Entfernung (in cm) nicht aus der Schallgeschwindigkeit oder so zu berechnen, sondern das ganze rein zu Kalibrieren. Also messungen in entfernungen wie 25cm; 50cm; 1m; 1,5m usw. durchzuführen und so erst einmal alle fixen Reaktionszeiten, (Filteranschwingzeit, Anschwingzeit der US - Kapseln [obwohl mir das auch neu wäre] und noch verzögerungen innerhalb des AVR, falls solche auftreten) auf einmal wegzusubtahieren. Dann ausrechnen, wie oft der Timer pro cm entfernung tickt und den Ausgabewert der messung (Timerticks) durch diesen Wert dividieren.
Alle diese Messungen natürlich oft durchfürhren, um auf einen guten Durchschnitt zu kommen.

Ich denke, das wird genauer als dass ich die Entfernung durch die Schallgeschwindigkeit berechne, auch weil der AVR villeicht nicht ganz so genau (im bezug auf die wahre Echtzeit) ist, könnte nich mir vorstellen.

Die Methode von radbruch würde sicher funktionieren, ich werde sie auch einmal ausprobieren, wenn das IF einmal will, aber irgentwie sagt mir der timer da doch mehr zu, ob nun 8 oder 16 Bit.

Das Oszi hat sich seit dem letzten mal überhaupt nicht mehr anschalten lassen, ich fürchte, es ist seinem Lebensende nah...
Aber ich schätze, dass ich spätestens am Wochenende einmal die Eingansverstärkung duchmessen kann, villeicht auch schon früher, sicher bin ich aber nicht.

Mfg Thegon