Forum: Mikrocontroller und Digitale Elektronik Echo HC-SR04 auswerten


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Axel H. (mf-futzi)


Lesenswert?

Hallo an das Forum,
ich will mit einem ATmega32 einen Ultraschallsensor auswerten. Ich 
programmiere in asm.
Der Aufbau auf dem Steckbrett funktioniert bereits, d.h. ich schicke ein 
Triggersignal an den Sensor und ich erhalte danach vom Sensor auch das 
Echosignal.
Mein Plan war jetzt das Echosignal an INT0 und INT1 zugeben und dadurch 
im jeweiligen Interrupt ein Start-/Stopflag zu setzen und dann in der 
Main die beiden Zählerstände des Timers auszulesen und zu subtrahieren, 
um die Länge des Signals zu berechnen. Das klappt jetzt aber (noch) 
nicht.

Meine Fräge wäre: ist das überhaupt die richtige Vorgehensweise, oder 
wie bekomme ich richtiger Weise die beiden Zählerstände des Timers?

Für Eure Hilfe wäre ich sehr dankbar!

von Wolfgang (Gast)


Lesenswert?

Axel H. schrieb:
> Mein Plan war jetzt das Echosignal an INT0 und INT1 zugeben und dadurch
> im jeweiligen Interrupt ein Start-/Stopflag zu setzen und dann in der
> Main die beiden Zählerstände des Timers auszulesen

Die Zeit zwischen Interrupt und Befehlsausführung in der Main geht als 
Zeitfehler beim Auslesen der Zählerstände ein. Willst du das?
Besser wäre es, direkt in der Interruptroutine den Zähler zu lesen.

Noch besser wäre die Nutzung der Capture Funktion des Timers.
https://www.electronicwings.com/avr-atmega/atmega1632-timer-input-capture-mode

von Stefan F. (stefanus)


Lesenswert?

Axel H. schrieb:
> ist das überhaupt die richtige Vorgehensweise

Kann man so machen, why not?

Wenn dein Programm während der Messung nichts andere zu tun, geht es 
noch simpler: http://stefanfrings.de/hc-sr04/index.html

Wolfgang schrieb:
> Die Zeit zwischen Interrupt und Befehlsausführung in der Main geht als
> Zeitfehler beim Auslesen der Zählerstände ein. Willst du das?

Ja das stimmt. Ich denke aber, man kann das vernachlässigen. Man muss 
sowieso mit Abweichungen bis 1cm rechnen, das sind 58µs. Für einen 16 Mz 
Mikrocontroller ist das eine kleine Ewigkeit. Die Zeitfehler die der 
Mikrocontroller hinzufügt, fallen da gar nicht auf.

Es sei denn, da läuft ein Programm das Interrupt länger als 50µs 
blockiert. Aber wer macht das schon?

: Bearbeitet durch User
von Axel H. (mf-futzi)


Lesenswert?

Wolfgang schrieb:

> Noch besser wäre die Nutzung der Capture Funktion des Timers.
> https://www.electronicwings.com/avr-atmega/atmega1632-timer-input-capture-mode

Also ich möchte das mit dem Input Capture Mode umsetzen. Ich habe o.g. 
Beitrag und auch den Abschnitt im Datenblatt nachgelesen, verstehe aber 
trotzdem die Arbeitsweise (noch) nicht ganz.

1. zuerst kommt eine steigende Flanke des Echo-Signals. Der Timerwert 
wird ins ICR geschrieben und kann in der Hauptroutine verarbeitet 
werden.
2. Dann tritt der Interrupt auf. Was mache ich in diesem Interrupt?

Und jetzt brauche ich ja noch den Timerwert bei fallender Flanke. Muss 
ich dazu die Flankenerkennung umschalten?

Danke für die Hilfe im Voraus!
Axel

von Wolfgang (Gast)


Lesenswert?

Stefan F. schrieb:
> Für einen 16 Mz Mikrocontroller ist das eine kleine Ewigkeit. Die
> Zeitfehler die der Mikrocontroller hinzufügt, fallen da gar nicht auf.

Eine "ewig" dauernde Verzögerung entsteht, wenn der µC aus einer nicht 
kooperativen Routine herausgerissen wird, die ihn millisekundenlang in 
einer Schleife auf irgendetwas warten lässt, ohne zwischendurch 
Rechenzeit abzugeben.

> Es sei denn, da läuft ein Programm das Interrupt länger als 50µs
> blockiert. Aber wer macht das schon?

Wenn im Interrupt zwar ein Start-/Stopflag gesetzt wird, der Zähler aber 
erst in der Main() ausgelesen wird, führt sowohl die Ausführungszeit der 
ISR als auch blockierende Funktionen zu Zeitfehlern.

von Stefan F. (stefanus)


Lesenswert?

Axel H. schrieb:
> 2. Dann tritt der Interrupt auf. Was mache ich in diesem Interrupt?

Du liest den gecaptureten Zählwert aus und packst ihn in eine Variable.

> Und jetzt brauche ich ja noch den Timerwert bei fallender Flanke.
> Muss ich dazu die Flankenerkennung umschalten?

Ja. Dann liest du den gecaptureten Zählwert wieder aus und subtrahierst 
ihn von dem vorherigen. Das Ergebnis ist die verstrichene Zeit.

von Axel H. (mf-futzi)


Angehängte Dateien:

Lesenswert?

Hallo,
ich habe mich jetzt mal in der Auwertung des Echo-Signals versucht:

1. Beim Flankenwechsel am ICP-Pin wird die ISR aufgerufen (siehe Anhang)
2. In der ISR wird geprüft, ob steigende oder fallende Flanke 
eingestellt war.
3a. bei steigender Flanke Timer auf 0 stellen, Fl-Erkennung umschalten
3b. bei fallender Flanke Timerwert kopieren, Fl-Erkennung umschalten, 
Flag setzen
4. Im Hauptprogramm bei gesetztem Flag im LCD ausgeben (erstmal nur als 
Funktionskontrolle)

Die Ausgabe im LCD (16-bit Zahl) erscheint mir plausibel. Könntet ihr 
bitte mal nachsehen, ob der Code "sauber" ist, oder ob ich etwas 
ändern/verbessern muss.

Im Moment habe ich den Triggerwert auf 2 Hz eingestellt. Ich werde noch 
etwas erhöhen. 2 bis 4 Auswertungen pro Sekunde sind aber für mich 
ausreichend.

Danke im Voraus!

von Stefan F. (stefanus)


Lesenswert?

Das Konzept ist unsauber. Die ISR wird unregelmäßig verzögert 
aufgerufen. Entsprechend wird der Timer immer mehr oder weniger zu spät 
genullt.

Es kann gut sein, dass diese Verzögerungen in deiner Anwendung 
vernachlässigbar sind. Aber du gast nach "sauber" gefragt.

Warum bleibst du nicht bei der Capture Funktion? Das wäre wesentlich 
sauberer gewesen.

von Axel H. (mf-futzi)


Angehängte Dateien:

Lesenswert?

Stefan F. schrieb:
> Das Konzept ist unsauber. Die ISR wird unregelmäßig verzögert
> aufgerufen. Entsprechend wird der Timer immer mehr oder weniger zu spät
> genullt.

Hallo Stefan,

Warum die ISR unregelmässig verzögert aufgerufen wird verstehe ich 
nicht. Der Interrupt tritt doch immer sofort bei einem Flankenwechsel 
auf.

OK, in der ISR ist vielleicht zu viel Code enthalten. Habe es jetzt so 
geändert, dass beim Interrupt nur der Zählerstand kopiert wird (siehe 
Anhang). Ob der Interrupt jetzt bei einer steigenden oder fallenden 
Flanke aufgetreten ist, wird in der Hauptroutine ausgewertet.

> Warum bleibst du nicht bei der Capture Funktion? Das wäre wesentlich
> sauberer gewesen.

Aber der ICP-Pin ist doch ausdrücklich für Frequenzmessung oder 
Pulsweitenmessung vorgesehen, oder?

Weiterhin vielen Dank für deine/eure Hilfe!

von Aristoteles (Gast)


Lesenswert?

Also mit dem input capture funktioniert dieser Sensor ganz prima. 
Allerdings muss man sich auch ein paar Gedanken darum machen, was bei 
einem Timerüberlauf passiert. Das kann ja durchaus vorkommen.

Wenn man auf Registerpaare zugreift außerhalb einer ISR,  die in einer 
ISR verändert werden, sollte man sicherstellen das zwischen dem Lesen 
von hi und lo byte die ISR nicht zufällig aufgerufen wird, sonst gibt es 
Salat. Ein cli innerhalb einer ISR macht m.E. keinen Sinn, das das 
I-Flag bis zum reti eh gelöscht ist.

von Stefan F. (stefanus)


Lesenswert?

Axel H. schrieb:
> Warum die ISR unregelmässig verzögert aufgerufen wird verstehe ich
> nicht.

Weil es davon abhängt, welchen Befehl der Mikrocontroller gerade 
ausführt. Steht irgendwo im Datenblatt oder Instruction Set Dokument. 
Außerdem wird dein Programm ab und zu mal Interrupts sperren, das führt 
aus zu Verzögerungen.

Axel H. schrieb:
> Aber der ICP-Pin ist doch ausdrücklich für Frequenzmessung oder
> Pulsweitenmessung vorgesehen, oder?

Ja, dann muss man ihn aber auch als solchen nutzen!

Input Capture heisst: Wenn das Signal von außen kommt, kopiert der 
Zähler (in Hardware, ganz ohne die CPU) seinen aktuellen Stand ins 
Capture Register. Das kann die Software dann (via ISR oder auch nicht) 
in aller Ruhe später auslesen.

: Bearbeitet durch User
von Axel H. (mf-futzi)


Lesenswert?

Hallo an alle,
leider habe ich aus den obigen Antworten noch keinen Erkenntnisgewinn 
ziehen können, was ich ausdrücklich falsch mache, oder wie es richtig 
gemacht wird.

Aristoteles (Gast) schrieb:
> Wenn man auf Registerpaare zugreift außerhalb einer ISR,  die in einer
> ISR verändert werden, sollte man sicherstellen das zwischen dem Lesen
> von hi und lo byte die ISR nicht zufällig aufgerufen wird, sonst gibt es
> Salat.

Stefan F. schrieb:
> Input Capture heisst: Wenn das Signal von außen kommt, kopiert der
> Zähler (in Hardware, ganz ohne die CPU) seinen aktuellen Stand ins
> Capture Register. Das kann die Software dann (via ISR oder auch nicht)
> in aller Ruhe später auslesen.

In meinem Code greife ich doch außerhalb der ISR gar nicht auf Register 
zu, die in der ISR verändert werden. In meiner ISR kopiere ich nur die 
Werte der ICR in 2 andere Register und setze ein Flag. Die 2 Register 
werden dann in der Main verarbeitet.

Ich wäre sehr dankbar, wenn mir jemand schreibt: Bei H-Flanke mache das, 
bei L-Flanke mache das, im Interrupt mache das, im Hauptprogramm mache 
das...

Ich möchte ausdrücklich betonen, dass ich keinen fertigen Code von 
irgend jemand möchte. Das will ich selber machen. Aber wenn ich nicht 
die genaue Abfolge und Zusammenhänge verstehe, kann ich es auch nicht 
programmieren.

Danke für eure Hilfe!

von Stefan F. (stefanus)


Lesenswert?

Axel H. schrieb:
> Ich wäre sehr dankbar, wenn mir jemand schreibt: Bei H-Flanke mache das,
> bei L-Flanke mache das, im Interrupt mache das, im Hauptprogramm mache
> das...

Habe ich doch. Aber wenn du das nicht verstehst, dann ist dieses Projekt 
wohl noch zu kompliziert für dich. Ist nicht schlimm, mach was 
einfacheres, bis du so wie bist.

Hast du denn alle Kapitel zu "Input Capture" im Datenblatt gelesen und 
verstanden? Das wäre mal Voraussetzung um hier weiter zu kommen. Niemand 
wird die das Datenblatt übersetzen oder in eigene Worte fassen. Wir 
helfen aber gerne, wenn du konkrete Fragen zu nicht verstandenen 
Textabschnitten stellst.

: Bearbeitet durch User
von Stefan F. (stefanus)


Lesenswert?

Habe noch was zu Interruptverzögerung gefunden, dass du lesen solltest.
http://nerdralph.blogspot.com/2020/04/measuring-avr-interrupt-latency.html

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

Axel H. schrieb:

> In meinem Code greife ich doch außerhalb der ISR gar nicht auf Register
> zu, die in der ISR verändert werden. In meiner ISR kopiere ich nur die
> Werte der ICR in 2 andere Register und setze ein Flag. Die 2 Register
> werden dann in der Main verarbeitet.

Das hat nichts mit deiner eigentlichen Frage zu tun, aber...:

Doch Du benutzt in deiner ISR


cli
in    yl, ICR1L
in    yh, ICR1H


im Hauptprogramm

Main1:
mov  E_StartL, yl
mov  E_StartH, yh

Dazu kommt, das Du in der ISR yl und yh nicht auf dem Stack sicherst. 
Das ist unsauber und bricht dir bei ISR'S früher oder später das Genick.

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

> Ich wäre sehr dankbar, wenn mir jemand schreibt: Bei H-Flanke mache das,
> bei L-Flanke mache das, im Interrupt mache das, im Hauptprogramm mache
> das...

Ich kann Dir gerne die genaue Abfolge Skizzieren. Aber ich möchte ein 
paar generelle Dinge vorwegschicken. Insbesondere bei zeitkritischen 
Aufgaben und Assemblerfragen ist die genaue Typenangabe des verwendeten 
Controllers sehr wichtig und vor allem auch die Angabe mit welcher 
Frequenz die clk läuft und wie der prescaler  eines Timers läuft.

Denn und bevor man mit der Programmierung startet sollte eine 
Mathestunde stehen. Man muss sich im Klaren sein. Welche Genauigkeit 
brauche ich am Ende des Tages und wie groß soll der Messbereich sein. 
Denn Du hast bei einem Atmega 32 maximal einen 16 Bit Zähler. Wenn deine 
MCU mit 16 Mhz rennt und du einen prescaler von 1 wählst, dann wird dein 
gerade mal 65535 counts fassender TIMERCONTER alle 0,0625µs um 1 
Hochgezählt. Und wie weit kommt der Schall bei 15°C ungefähr in der Zeit 
wo dein Zähler bereits sein Maximum erreicht hat und überläuft? Ungefähr 
1392mm. Also bei voller Timer Speed kann man z.B. nicht den kompletten 
Range von ungefähr 3000mm abdecken. Und wundert sich dann dass man 
plötzlich bei größeren Entfernungen seltsame Ergebnisse bekommt. Ein 
TimerCounter überlauf kann auch auftreten bei Fehlessungen oder 
Störsignalen, wenn z.b. mal eine faling edge verschluckt wird. Also 
sollte man das Overflow Bit auch checken. Nicht uninteressant ist es 
auch zu wissen wie lange das Delay nach dem 10µs Triggerpulse bis zum 
Beginn des Response ist. Hier hilft ein DSO ungemein. So kann man den 
TimerCounter z.B. mit einer gewissen Verzögerung starten um nicht zu 
früh in einen Timer Overflow zu laufen.


Übrigens kann man die US Sensoren auch mit einfachem Arduino Code mm 
genau abfragen ohne Input Capture. C würde auch reichen. Schall ist eben 
relativ langsam ;-)

Wie gehe ich in meinem AssemblerCode in der ISR zum Erfassen eines Pulse 
With vor

1. Alle in der ISR verwendeten Register auf den Stack!
2. Als aller aller erstes ICR1L und dann ICR1H auslesen und in Registern 
zwischenspeichern und zwar deshalb weil der TimerCounter auch während 
der ISR weiterzählt!
3. checken ob die ISR wegen eines faling- oder rising Ereignisses 
aufgerufen wurde.

Wenn RisingEdge:

1.  Am Anfang zwischengespeicherten 16Bit Wert für Rising ( aus ICR1L 
und ICR1H) z.B. im SRAM speichern.
2.  Ein StstusBit für RisingCaptureDone setzen
3.  Umschalten auf FalingEdgeCapture hierbei nicht vergessen das ICF Bit 
in TIFR1 zu löschen. Bitte beachten: After a change of the edge, the 
Input Capture Flag (ICF) must be cleared by software (writing a
logical one to the I/O bit location)
4.  Zum Endpunkt der RSI springen

Wenn FalingEdge:

1.  An Anfang zwischengespeicherten 16Bit Wert für Faling ( aus ICR1L 
und ICR1H) z.B. im SRAM speichern.
2.  Ein StsusBit für FalingCaptureDone setzen
3.  Umschalten auf RisingEdgeCapture. After a change of the edge, the 
Input Capture Flag (ICF) must be cleared by software (writing a
logical one to the I/O bit location)
4.  Prüfen ob TimerCounter Overflow gesetzt, wenn Ja Messergebniss nicht 
valide, alle StstusBits löschen und zum Endpunkt der RSI springen
RSIEndpunkt
Alle Verwendeten Register wieder herstellen.

Initiiert wird die Messung durch eine andere Funktion die den 10µs 
Trigger erzeugt. Wichtig verhindern das der Trigger nicht innerhalb der 
Messsequenz erneut erzeugt wird. Das ist dann wieder Mathe. Viel Spaß!

von Axel H. (mf-futzi)


Lesenswert?

Hallo Thomas,

vielen Dank für deine lange und ausführliche Erklärung. Jetzt mache ich 
mich nochmal dran, es richtig umzusetzen. In meiner ersten ISR war ich 
schon auf dem richtigen Weg. Hatte aber ein paar Fehler eingebaut, u.a. 
das ICF-Bit nicht manuell gelöscht, obwohl es ausdrücklich im datasheet 
drinsteht ;-)

Falls noch Fragen auftreten, komm ich nochmals zurück.

Super! Vielen Dank!Axel

von Axel H. (mf-futzi)


Angehängte Dateien:

Lesenswert?

So,
der erste Schritt ist gemacht! Ich lasse mir am LCD den Startwert und 
den Stoppwert des Timers, sowie die Differenz auf dem LCD ausgeben. Ich 
habe schon verschiedene Entfernungen gemessen und die jeweilige 
Differenz umgerechnet. Und es stimmt jede Messung relativ genau. Umso 
grösser die Entfernung ist umso grösser sind aber auch die Unterschiede 
zwischen den einzelnen Messungen.
Jetzt muss ich "nur" noch den Messwert in eine Entfernung umrechnen.

von HildeK (Gast)


Lesenswert?

Axel H. schrieb:
> Umso
> grösser die Entfernung ist umso grösser sind aber auch die Unterschiede
> zwischen den einzelnen Messungen.

Du könntest ja auch mehrere Messungen nacheinander machen und den 
Mittelwert oder den Median bestimmen.

von Axel H. (mf-futzi)


Lesenswert?

HildeK schrieb:

> Du könntest ja auch mehrere Messungen nacheinander machen und den
> Mittelwert oder den Median bestimmen.

Ja, das hab ich mir auch schon überlegt. Immer 8 Werte speichern. Den 
neuesten Wert dazu und den ältesten Wert wegfallen lassen. Und dann aus 
8 Werten wieder den Durchschnitt bilden.
Muss mal sehen, ob ich das mit meinen geringen Kenntnissen hinkriege.

von HildeK (Gast)


Lesenswert?

Ich habe es mit 5 Werten gemacht. Die nacheinander in ein Array 
geschrieben, dann das Array der Größe nach sortiert (einfachst: 
Bubblesort) und das mittlere Element als Ergebnis genommen: Median. 
Dauert aber eben 5 × (ca.) 20-25ms.

Ist in meiner Garage montiert und zeigt mir ausreichend genau (±1cm) an, 
wenn ich weit genug rückwärts reingefahren bin ... 😀

Dein gleitender Mittelwert ist dann sinnvoller, wenn du nur wenig oder 
langsame Distanzänderungen hast. Es hat aber den Nachteil, dass 
Ausrutscher trotzdem wirken.

Axel H. schrieb:
> Muss mal sehen, ob ich das mit meinen geringen Kenntnissen hinkriege.

Ein Array und einen Schreibzeiger i nehmen, der modulo läuft [i++; 
if(i==8) i=0;] und jeden neuen Wert auf die nächste Stelle schreiben. 
Das Modulo sorgt automatisch dafür, dass der älteste Wert überschrieben 
wird.
Dann alle addieren und durch die Länge (hier 8) teilen.

von HildeK (Gast)


Lesenswert?

HildeK schrieb:
> auf die nächste Stelle schreiben
... auf die nächste Stelle des Schreibzeigers i schreiben ...

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

Axel H. schrieb:

> Jetzt muss ich "nur" noch den Messwert in eine Entfernung umrechnen.

Na, das sollte doch das kleinste Problem sein! Selbst in Assembler. 
Wobei ich bei so was stets C nehmen würde und nur das vermeidlich 
Zeitkritische in Assembler.

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Thomas H. schrieb:
> Wenn deine
> MCU mit 16 Mhz rennt und du einen prescaler von 1 wählst, dann wird dein
> gerade mal 65535 counts fassender TIMERCONTER alle 0,0625µs um 1
> Hochgezählt. Und wie weit kommt der Schall bei 15°C ungefähr in der Zeit
> wo dein Zähler bereits sein Maximum erreicht hat und überläuft? Ungefähr
> 1392mm. Also bei voller Timer Speed kann man z.B. nicht den kompletten
> Range von ungefähr 3000mm abdecken.

Dann ist es vielleicht an der Zeit, den Timer um ein zusätzliches Byte 
zu erweitern. Damit käme man immerhin bis 345352mm. Das hilft doch schon 
mal.
Das zusätzliche Byte im Speicher muss immer dann um 1 hochgezählt 
werden, wenn der Timer einen Overflow Interrupt auslöst.

von Aristoteles (Gast)


Lesenswert?

> Dann ist es vielleicht an der Zeit, den Timer um ein zusätzliches Byte
> zu erweitern. Damit käme man immerhin bis 345352mm. Das hilft doch schon
> mal.
> Das zusätzliche Byte im Speicher muss immer dann um 1 hochgezählt
> werden, wenn der Timer einen Overflow Interrupt auslöst.

..oder einen Baustein mit 32 Bit Timer/Counter zu nehmen oder..., 
oder..., oder..., aber es hat sich auch als Sinnvoll herausgestellt 
Fragestellern die mit einer Basisaufgabe bereits Probleme haben nicht 
gleich die allumfassendste und umfangreichste Lösung aufzutischen....

von Axel H. (mf-futzi)


Lesenswert?

Wolfgang schrieb:

> Dann ist es vielleicht an der Zeit, den Timer um ein zusätzliches Byte
> zu erweitern. Damit käme man immerhin bis 345352mm. Das hilft doch schon
> mal.
> Das zusätzliche Byte im Speicher muss immer dann um 1 hochgezählt
> werden, wenn der Timer einen Overflow Interrupt auslöst.

Ich werde ein komplettes Byte anfügen, um die 3m des Sensors auswerten 
zu können und für die Ausgabe am LCD.

Aristoteles schrieb
> oder..., oder..., aber es hat sich auch als Sinnvoll herausgestellt
> Fragestellern die mit einer Basisaufgabe bereits Probleme haben nicht
> gleich die allumfassendste und umfangreichste Lösung aufzutischen....

Dann würde ich vorschlagen, du übst dich erstmal in der Rechtschreibung, 
bevor du in einem Forum nicht zielführende Kommentare abgibst.
Es gibt eben auch Hobby-Elektroniker, so wie mich, die dieses Hobby aus 
Spass an der Freude betreiben und keine (Berufs-)Progammierer sind. Und 
für Fragen sind Foren eigentlich da.

Von meiner Seite ist meine ursprünglich Frage beantwortet. Den Rest 
werde ich alleine hinbekommen. Herzlichen Dank an Thomas und HildeK, die 
mir die entscheidenden Hinweise und Tipps gegeben haben.

Axel

von Frank E. (Firma: Q3) (qualidat)


Angehängte Dateien:

Lesenswert?

Ich hab mich auch eine zeitlang mit den Dingern rumgequält und am Ende 
eine andere Lösung genommen: Einen US-Sensor mit I2C-Interface "GY-US42 
I2C", dessen Platine die Messung selbstständig vornimmt.

Man muss nur noch die Werte abholen, feddich ...

Man kann die Wandler-Kapsel (2-polig) vorsichtig von der Platine 
entlöten und sie funktioniert bei mir auch noch an 2m langen Kabeln.

: Bearbeitet durch User
von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

Frank E. schrieb:
> Ich hab mich auch eine zeitlang mit den Dingern rumgequält und am Ende
> eine andere Lösung genommen: Einen US-Sensor mit I2C-Interface "GY-US42
> I2C", dessen Platine die Messung selbstständig vornimmt.
>
> Man muss nur noch die Werte abholen, feddich ...
>
> Man kann die Wandler-Kapsel (2-polig) vorsichtig von der Platine
> entlöten und sie funktioniert bei mir auch noch an 2m langen Kabeln.

Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge 
dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Thomas H. schrieb:

> Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge
> dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus.

Warum "schade"? Wenn es einfach zuverlässiger ist, so ist das ja auch 
nicht ohne Reiz. Im Prinzip hat es ja auch funktioniert, aber die 
"Messwerte" tanzten einfach mal +-50cm ohne ersichtliche Ursache. 
Irgendwann hats mir gereicht und ich hatte keine Lust mehr, noch weitere 
Zeit zu versenken. Die I2C-Dinger sind deutlich zuverlässiger und am MC 
werden Ressourcen frei.

von Axel H. (mf-futzi)


Lesenswert?

> Thomas H. schrieb:
>
> Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge
> dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus.

Hallo Thomas,
ist doch alles OK. Bei mir funktioniert die Messung jetzt, dank deiner 
Hilfe. Jetzt will ich noch einen Durchschnitt der letzten x Messungen 
einfügen und das Messergebnis in einen Längenwert umrechnen. Das krieg 
ich hin. Und dann hab ich wieder ein Stück dazu gelernt.
Axel

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

Frank E. schrieb:
> Thomas H. schrieb:
>
>> Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge
>> dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus.
>
> Warum "schade"? Wenn es einfach zuverlässiger ist, so ist das ja auch
> nicht ohne Reiz. Im Prinzip hat es ja auch funktioniert, aber die
> "Messwerte" tanzten einfach mal +-50cm ohne ersichtliche Ursache.
> Irgendwann hats mir gereicht und ich hatte keine Lust mehr, noch weitere
> Zeit zu versenken. Die I2C-Dinger sind deutlich zuverlässiger und am MC
> werden Ressourcen frei.

Schade, weil es nicht funktioniert hat.

Im Prinzip ist das richtig. Nicht Jeder muss immer und für jede Aufgabe 
das Rad neu erfinden. Aber die Fragestellung war eindeutig. Da wollte es 
Jemand selber machen. Das es Leute gibt die so was fertig kaufen finde 
ich natürlich gut. Damit verdiene ich mein Geld.

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

Axel H. schrieb:
>> Thomas H. schrieb:
>>
>> Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge
>> dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus.
>
> Hallo Thomas,
> ist doch alles OK. Bei mir funktioniert die Messung jetzt, dank deiner
> Hilfe. Jetzt will ich noch einen Durchschnitt der letzten x Messungen
> einfügen und das Messergebnis in einen Längenwert umrechnen. Das krieg
> ich hin. Und dann hab ich wieder ein Stück dazu gelernt.
> Axel

Hallo Axel,

viel Spaß dabei. Es ist doch immer ein gutes Gefühl ein komplexes 
Problem selber gelöst zu haben. Wenn das Projekt abgeschlossen ist, 
schau dir mal die Atmegas der NULL Serie an, wie den Atmega4809 o.ä. die 
haben ein Eventsystem, dass einem mit dem Input Capture Pulse-Width 
Measurement Mode, noch mehr Arbeit mit HW abnimmt. Es gibt auch neue 
AtTinny's die so was können. Damit kann man sich dann selber so etwas 
mit I2C Anbindung für seine Seonsoren bauen wie Frank E. beschrieben 
hat. Vieleicht sogar mit Temperaturkompensation. Denn die 
Schallgeschwindigkeit ist nicht unwesentlich von der Temperatur 
abhängig.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.