Ultraschall - Entfernunsmessung mit Ultraschall Interface aus RN

[Manf]

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.

[Thegon]

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:

$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#

[Searcher]

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

[radbruch]

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

[Besserwessi]

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.

[radbruch]

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

[Thegon]

Hallo,

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.

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

[Thegon]

Hmm, der 16 Bit timer macht bei mir nur Käse

Je weiter die Entfernung wird, desto kleiner werden die Zahlen

ich habe auch schon kalibrierungsmessungen durchgefürht, und mich gewundert, wie klein der Unterschied zur Wahren Messung (mit messband) ist. Die Reaktionszeit scheint nur wenige us zu betragen.
Naja, nur eben das Problem mit den bestimmten Stellen, die immer gleich hoch bleiben.
Ach ja, diese Stellen sind übrigens immer ein vielfaches von 256...

Mfg Thegon

[Besserwessi]

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.