Ultraschall - Entfernunsmessung mit Ultraschall Interface aus RN

Also, das mit dem Widerstand hats gebracht: Ich erhalte nun am Ausgang der Verstärkung 40kHz 5V amplitude, auch gegen die Decke.
Nur irgentwie so ganz richtig funktioniert das ganze noch nicht:
Ich erhalte weiterhin die 20 Interrupts mit dem Inthalt 0, obwohl die Interrupts erst nach dem Senden Atkiviert werden und beim ersten eintreffenden Interrupt aktiviert werden. Aber das mit dem 5V signal ist schon mal gut.

Auch am Pulse out gibt es weiterhin nichts zu messen, was für mich auf sehr kurze zeiten hindeutet. Sehr seltsam das ganze...
Nun die Frage ist: warum macht der Komperator nichts sinnvolles, wenn er das 5V Signal von der Verstärkung erhält?
Oder kommt das 5V Singal villeicht garnicht vom Empfangswandler ?
Alles so seltsam und man kommt sich so hilflos vor, wenn man keine Sinnvollen Messbilder hat.
Das einzige, was ich sonst noch herausgefunden habe ist dass das Sendesignal wenn es den AVR verlässt, durch irgentwas stark verändert wird.
Es ist kaum noch zu erkennen mit dem Oszilloskop, es verändert sich ständig und hat, wenn man einmal zufällig richtig Triggert, eine gewaltig hohe Frequenz (500kHz) Habe aber auch nicht die geringste Ahnung warum das so ist.

Mfg Thegon

Wenn die 2. verstärkerstufe schon 5 V liefert, braucht man doch keinen "Komperator mehr". Die Stufe sollte aber auch damit klar kommen. Was passieren kann, ist allerdings das man das Laden des Kondensators für die Verstärkungseinstellung mit bis zum Ausgang bekommt. Man hat da noch ein langsames Signal, das den 40 KHz überlagert ist und ggf. am Ausgang jetzt stört, denn die extra Verstärkerstufe invertiert das Signal.

Wenn beim Senden schon ein Starkes Signal ankommt, kann der Schwingkreis noch einige Zeit nach schwingen und auch kurz nach dem Ende des Sendens noch einen Interrupt auslösen.

Das Signal zum Senden sollte einigermaßen Sauber sein. Je nach Logic IC kann es sinnvoll sein einen kleinen Widerstand von vielleicht 100-300 Ohm in Reihe zum Sende Transducer zu haben. Man hat dann keine so kapazitive Last. Damit werden die Oberwellen des Rechtecksignals etwas gedämpft und die Spitzenströme werden begrenzt. Es gibt damit weniger Störungen auf der Versorgung.

Nachdem die Verstärkung die ganze Zeit zu klein war kommt es jetzt mit der zusätzlichen Stufen wenn sie den richtigen Arbeitspunkt haben zu einer recht hohen und ggf. auch zu hohen Verstärkung.
Wenn die Störungen speziell am Anfang nach dem Senden auftreten dann sieht es danach aus, dass der 1MOhm Widerstand für den Baisisstrom des ersten Transistors noch fest an 5V liegt.
Es ist aber schon ein wichtiger Teil des Konzepts mit der Rampe, dass der Eingangsverstärker während des Sendens noch inaktiv ist.

Hallo allerseits

Ich habe den 100 Ohm wiederstand eingebaut und wieder auf Rampenbetrieb umgestellt, weiteres habe ich auch den Triggerlevel um ein gutes stück zurückgesetzt.
Nun: Ich kann es selber kaum glauben:
Ich erhalte nun immer interrupts, auch wenn ich bis zur decke messe, zum Beispiel.
es kommt auch immer nur ein Interrupt, und dieser Braucht um so länger, je weiter die Entfernung ist.
Ich kann nicht einmal Messbilder aus dem Oszi nennen, da es wieder einmal steikt, aber das ist mir jetzt auch egal, Ich nehme an, es wird wohl so stimmen ;-)

Kurz um: Das Interface erfüllt seine Aufgabe!!!


Das einzige was jetzt noch ein bisschen Probleme macht, ist die Software. Erstens stimmen die Ausgegebenen zeiten nicht mit den Soll - us zusammen, was mich aber weniger stören würde, da ich sowieso vor habe, das Interface zu eichen.
Auch kommen ganz bestimmte zeiten (z.B. 1729) besonders oft, sodass ich einen Denkfehler in der Programmstruktur vermute.
Ich hänge den derzeitig benutzten Code unten an den Beitrag an, wäre schön, könnte ihn mal jemand anschauen.

Dann einmal vielen vielen Dank allen Beiteiligten an diesem Thread, im Bezug auf die Hardware besonders Manf und Besserwessi, danke für die vielen Tipps und Lösungsvorschläge!

Naja, an der software gibts schon noch ein bisschen was zu verbessern, denn es gibt teilweise schlimme abweichungen von mehr als 200 us, auf grund dieser Zeiten, die besonders oft kommen, aber ich freue mich schon mal unglaublich, das die Hardware nun einmal keine Probleme macht.


Mfg Thegon

Hier noch einmal den zurzeit verwendeten Code:

Code:

---

$regfile "M48def.dat"
$crystal = 1000000
$hwstack = 100
$swstack = 100
$framesize = 100
$baud = 2400
Dim Endtime As Long
Dim Countperoverflow As Integer
Dim Struser As String * 10
Dim Countperiodes As Byte
Dim Timerstand As Byte

Config Timer0 = Timer , Prescale = 1
On Timer0 Isrtimer
Enable Timer0
Stop Timer0

Config Int0 = Rising
Enable Int0
On Int0 Isr_interrupt
Config Portd.3 = Output
Portd.3 = 1

Do
Input Struser
If Struser = "" Then
'################# den Sendebrust generieren +++++++++
Countperiodes = 0
Do
Portd.3 = 0
Countperiodes = Countperiodes + 2

Portd.3 = 1
Countperiodes = Countperiodes - 1

Loop Until Countperiodes > 20
Countperiodes = 0
Portd.3 = 1
'######################################################

Enable Interrupts
Start Timer0
Timer0 = 0
Struser = "sd"
End If
 
Loop
 

'###############TimerIsR##################
Isrtimer:
Countperoverflow = Countperoverflow + 1
Return
'#########################################

'#########ACI isr################
Isr_interrupt:
Stop Timer0
Timerstand = Timer0
If Tifr0.tov0 = 1 Then
Endtime = Endtime + 256
Set Tifr0.tov0
End If
Endtime = Countperoverflow * 256
Endtime = Endtime + Timerstand

Disable Interrupts
Print Endtime
Timer0 = 0
Timerstand = 0
Endtime = 0
Countperoverflow = 0
Return#

---

Hi,

gratuliere!

Wegen der Abweichungen der Meßwerte bzw häufiges Vorkommen von bestimmten Werten:

Hatte ich in meinem Programmentwurf auch. und ist sehr wahrscheinlich, wie weiter vorne im thread erwähnt, durch Ablauf der "Isrtimer:" verursacht.

Um die Abweichungen kleiner zu bekommen könnte man als erstes den Systemtakt auf 8MHz stellen (Timer Prescaler dann gleichzeitig auf 8 .

Oder Du probierst den Vorschlag von radbruch aus - dann ist das Überschneiden der Interrupts ausgeschlossen.

Besserwessi hat die Verwendung von ICP (Input Capture Funktion) vorgeschlagen. Das scheint mir genau die richtige Methode für solche Messungen zu sein. Allerdings nur für die 16 Bit Timer verfügbar:(

Gruß
Searcher

Da ist ein Problem mit der Berücksichtigung der Überläufe von Timer 0. Einfacher wäre es man würde Timer1 nehmen, da könnte man sich das Problem sparen. Im Idealfall würde man die ISP Funktion nutzen und hätte die Zeitmessung fast komplett durch die Hardware erledigt.

Wenn es unbedingt mit timer 0 sein soll, hat man eine Schwierigkeit, wenn der Timer overflow und der externe Interrupt fast gleichzeitig auftreten. Da ist schon etwas Code in der ISR der wohl versuchen soll, das Problem zu behandeln, allerdings ist der Teil an der Falschen stelle und nur halb richtig. Das Problem ist, dass ggf. die Overfow ISR noch aussteht, also eine Überlauf zu wenig gezählt wurde. Erkennen kann man das am Interrupt-flag in Kombination mit dem Timer Wert:
If Tifr0.tov0 = 1 reicht dabei noch nicht, es muss außerdem der Timer-wert klein (z.B. < 100 sein). Ohne Vorteiler wird es mit den Zeiten aber auch schon recht knapp. Die Overflow ISR wird schon fast 50% der gesamten Rechenzeit verbrauchen.

Nachtrag: Wärend die Überlauf ISR läuft, kann nicht auf den anderen Interrupt reagiert werden. Entsprechend die Werte kurz nach dem Überlauf nicht möglich. Leider braucht auch die einfache ISR in BASCOM schon gut 100 Zyklen. Mit Inline ASM könnte man da noch etwas raushohlen, aber im Prinzip bleibt die kleine Lücke.

Das einzige was mir noch auffällt:

Countperoverflow = 0

erst nach der ersten Messung in der ISR. Vermutlich wird das von Bascom schon beim Programmstart mit 0 belegt, aber darauf würde ich mich nicht verlassen. Die Systemtakterhöhung halte ich auch für sinnvoll.

Zu Rechenzeit in der ISR: Wird "incr Countperoverflow" schneller ausgeführt?

Gruß

mic

Die Rechenzeit wird dominiert durch das Retten der Register auf den Stack. Das sind alleine schon etwas über 100 Zyklen, selbst wenn die ISR leer ist. Da hilft halt inline ASM, weil man da keine 26 Register retten muss, sondern nur 2.

Das Speichern aller Register beim Aufruf der ISR kann man mit dem Parameter "nosave" unterdrücken. Infos in der Bascom-Hilfe unter "On Interrupt"

Hallo,

Zitat:

---

Wenn es unbedingt mit timer 0 sein soll

---

nein, es muss nicht unbedingt Timer0 sein, ich hätte auch nichts gegen Timer1. Du meinst, man spart sich das Problem, weil der Interrupt ja erst bei 65536 ausgelöst wird, und eine So große Entfernung garnicht gemessen werden kann?
Nun das könnte sein, das Probiere ich einmal aus.

Zitat:

---

Das einzige was mir noch auffällt:

Countperoverflow = 0

---

Du hast recht, die Erste messung ist immer unbrauchbar, aber ab der zweiten stimmts. Das werde ich gleich ausbessern.

Sost Input Capture klingt vielversprechend, nur kenne ich mich damit nicht aus, und der Artikel ist in C, und irgentwie steht da zwar drin, wie ICP funktioniert, aber nicht, wie man ihn programmiert.

Naja, probiere jetzt mal den 16bit Timer.

Mfg Thegon