Hinweis vom 01. Oktober 2008: eine abschließene Zusammenfassung gibt es hier.
Titel am 22März08 editiert: "Probleme bei" wurde gestrichen, denn die Probleme sind ja eigentlich gelöst.
--------------------------------------------------------------------------------------
Hallo alle,
über Unklarheiten bei der IR-Schnittstelle zur Hinderniserkennung bzw. zur Abstandsmessung habe ich hier bereits kurz berichtet. Nun habe ich weitere Probleme damit. Was mache ich falsch?
Über die Schwierigkeiten des SFH5110 sich für "ein" oder "aus" zu entscheiden habe ich im genannten posting bereits berichtet. Ich kann aber auch die Ergebnisse zur Entfernungsmessungen nur schwer nachzvollziehen.
Hintergrund: ich will diese asuro-Abstandsmessung als irDME (IR-Entfernungsmesser) einsetzen - preislich ist es ja unschlagbar. Deshalb habe ich eine kleine Einheit aufgebaut, die genauso bestückt ist, wie die entsprechenden Schaltkreise beim asuro (Ausnahme: der 490R für Vcc-5110 ist hier nur 330 - die Drähte im Bild sind für einen Spindeltrimmer, mit dem ich die 415 trimmen konnte - alle hier genannten Messungen wurden mit 220R gemacht). Dass der Testaufbau auf einem m168/20MHz läuft, sollte meiner Meinung nix ausmachen ! ?
..........................Bild hier
Erstmal habe ich festgestellt, dass ich wesentlich besser Abstände messen kann bei 38 kHz im Vergleich zu 36 kHz. (Wieweit die RS232 dabei besser ginge, habe ich noch nicht untersucht).
Um die Entscheidung auf "ein" oder "aus" auf etwas bessere Beine zu stellen, habe ich eine Art primitiver Statistik eingeführt:
Damit erreiche ich eine Hysterese von etwa 10 .. 20 % bezogen auf den Schaltabstand. Im Vergleich dazu beträgt die Hysterese ohne diese einfache Rechnerei rund 50 % des Schaltabstandes.Code:for(uint16_t k=0; k<=1000; k=k+1) { for(uint16_t m=0; m<=2000; m=m+1) // { // tmp = PINB; // if (!(tmp & 0x08)) // Aktionen für gelöschtes Bit if (istaus > 0) istaus = istaus--; // heisst: Counter runterzählen else // .. wenn Bit nicht gelöscht, dann ist es gesetzt { inix = istaus; // Dummyaktion } else // wenns nicht gelöscht ist, ist es gesetzt :) if (istaus < 1000) istaus = istaus++; // also Counter raufzählen bis 1 000 else { inix = istaus; // DD doofer Dummy, nix machen } // ##### danach vergleiche was größer ist: // ##### wenn über xxx , Port einschalten, wenn unter xxx Port ausschalten if (istaus < 10) { // hier die Anweisungen, wenn das Bit gelöscht ist PORTC &= ~(1<<PC0); // lösche PC0 } else // .. wenn Bit nicht gelöscht, dann ist es gesetzt if (istaus > 990) PORTC |= (1<<PC0); // Setze PC0 else { } { } } // waitms(1); // }
Schaltabstände über 40 cm konnte ich praktisch nicht messen. Ich bewerte die "Entfernung" erstmal mit dem von mir gesetzten Rampenwert der PWM und nenne das "AktRampe". Bei 36 kHz geht der 5110 auf low bereits bei einem Rampenwert von 17 (ich schalte mit dem Signal des 5110 eine "Kopier"-Led, um eine schnelle optische Kontrolle zu erhalten). Bei 38 kHz tritt ohne Statistik ein sichtbares Flattern (sichtbar an der LED, am Oskar schon früher) bei Rampenwert 20 auf, deutliches Flackern der Kontroll-LED bei 30, LED ist fast aus bei 50 und nicht mehr feststellbar bei 60. Dann ist am Oskar noch hin und wieder was zu sehen.
Mit "Statistik" 10/990 - siehe Code oben - bekomme ich:Lasse ich die 415 frei nach vorne in den Raum strahlen - sie ist natürlich abgeschirmt mit einer Schlauchblende - bekomme ich folgende Terminalmitschrift:Code:AktRampe Schaltabstand ca. cm 5/263 5 10 11 15 17 20 17 30 40 36 low
.......................Bild hier
Dabei ist mittendrin mal eine Bedämpfung des Messstrahls mit der Hand zu erkennen an dem Absinken der Statistikwerte "stt" unter 1000. Gegen Ende der Aufzeichung strahlt die SFH415 aber wieder unbedämpft und man sieht den aktuellen Statistikwert. Deutlich ist zu sehen, dass bei einer Ansteuerung mit "Rampe" 40 der 5110 praktisch auf low ist. Der maximale "Rampenwert", d.h. der Wert im ICR1 beträgt 263 - daher insgesamt eben maximal 264 Werte.
Fragen:
Habe ich Fehler gemacht? Wenn ja, welche?
Wieso messe ich nur maximale Entfernungen bis etwas 30 cm einigermassen vertrauenswürdig?
Wurde ähnliches Flattern am 5110 schon von euch beobachtet - aber bei mir machen es alle Aufbauten - auch der asuro.
Wieso funzt die Abstandsmessung am asuro so gut? Oder: wieso ist meine Messeinheit so anders?
Hat jemand auch schon mit Frequenzen "neben" der Nennfrequenz des SFH5110 experimentiert? Mit welchem Ergebnis?
Ok, etwas komplex, vielleicht findet jemand die Würmer? Danke im Voraus,
Geändert von oberallgeier (20.11.2018 um 17:59 Uhr)
Ciao sagt der JoeamBerg
Hallo oberallgeier,
habe dich gerade erst hier entdeckt. Ich hatte vor einer Minute in dem oben von dir angegeben Thread geantwortet.
Dies hier muss ich mir dann doch wohl etwas genauer ansehen. Aber nicht mehr heute.
Gute Nacht oder guten Morgen. Wie ihr gerade wollt.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Danke für Deinen Kommentar hier (und im Ursprungsthread). In meinem Datenblatt "Infineon / OSRAM" ID "2000-02-02" sah ich nichts von einem empfohlenen Tastverhältnis. Lediglich von der Burstlänge von min. 6 Pulsen ist die Rede und ein Tastverhältnis (duty cycle) von 50% ist beispielhaft genannt. Auch die ausführlichere General Application Note for SFH511X, die ich mir wegen Deines Hinweises gerade geholt hatte, Stand January 30, 2002, zeigt gleiche Werte.
Dafür war mir schon aufgefallen, dass die Datenblätter eine Peripherie des 5110 als typisch zeigen, die deutlich anders ist als beim asuro. Ich hatte die Beschaltung des asuro nachgebaut, weil ich mich auf die Erfahrungen dieses Forums stützen möchte.
Mit "Entscheidungsschwäche" meine ich die Tatsache, dass ich bei der Entfernungsmessung keine eindeutige Schaltschwelle bekomme. Der 5110 zittert in der Art:
___________ _ _ _ _ _ _ _ _ _ _
.....................\ _ _ _ _ _ _ _ _ _ _\___________ (Anmerkung: die hellen Punkte bitte wegdenken)
zwischen high und low, wenn ich ein Testobjekt, z.B. meine Hand, von "eindeutig high" z.B. bei 30 cm, zu "eindeutig low" z.B. bei 20 cm bewege. Dabei schwankt der high und der low-Anteil je nachdem, bei welchem Abstand ich näher bin.
Unklar ist mir dabei, ob vielleicht durch geeigntete Dimensionierung der erwähnten bursts (min 6 Pulse) eine bessere Messmöglichkeit für Entfernungen besteht. Ich habe das auf meinem Testprogramm, da ja (siehe die jüngere doc, S3, unten) die "typische" Empfindlichkeit spezifiziert wird für bursts von 600 µS Länge, also 23 Pulsen.
Aber das Eingangsbeispiel von waste zeigt ja im Code auch (nur) die Änderung des OCR2, während PD1 nicht getaktet wird. Meine "AktiveRampe" variiert ebenso, es ist mein OCR1A mit ICR1 = 263 als TOP.
Mit meinem Posting hoffte ich (als elektronischer Blindgänger) zu erfahren, ob ich a) irgendwie falsch liege und/oder b) ähnliche Erfahrungen zu dem Thema vorhanden sind.
Andererseits könnte ich mit dem derzeitigen Zustand meiner Abstandsmessung garnicht so schlecht leben. Es wär nur interessant ....
Ciao sagt der JoeamBerg
Hossa oberallgeier,
ach das meinst du mit der "Entscheidungsschwäche".
Ja, da hast du das gleiche Problem, das auch im Asuro bei den original Bauteilen vorhanden ist.
Hier mal die aus dem waste-Original-Thread gesammelten Daten:
robo.fr gibt in seinem Programm und seiner Tabelle folgendes an:
Ich hatte in der Tabelle ungefähr so etwas:Code:OCR2= 254-X Abstand[cm] 0 5 1 7 2 13 3 15 4 16 5 17 6 18 7 22
Und inka hat laut seinem Beitrag die von mir ermittelten Abstände mathematisch halbiert auf:Code:OCR2= 254-X Abstand[cm] 0 6 1 14 2 20 3 28 4 32 5 38 6 42 7 47 . . 32 120
Unterm Strich sind die Programme extrem ähnlich.Code:OCR2= 254-X Abstand[cm] 0 3 1 7 2 10 3 14 4 16 5 19 6 21 7 23 . . 32 60
Sternthaler und inka sind identisch, außer dass inka die Entfernungsberechnung (aber nicht die Ermittlung) angepasst hat.
robo.fr hat etwas umgebaut (Die Struktur sieht nach meinem Programm aus). Er hat vor allem in der Schleife zum testen von Pin D0, dahingehend geändert, dass 'nur' 30 mal geprüft wird. In der Schleife wird künstlich mit Sleep() gewartet.
Genau dieses Sleep()-Konstrukt hatte ich nach einigen eigenen Tests komplett aus meiner ersten veröffentlichen Version "Chirpen-über-IR" durch Massenmessungen ersetzt. Ich loope über der "teste Pin D0"-Stelle bewusst sehr häufig (1000 mal) ohne Sleep() damit die Statistik "erkannt / nicht erkannt" mit vielen Daten arbeiten kann. Das hatte sich bei mir mit höheren Messanzahlen bzw. mehr Statistik gut bewährt um relativ wenig "Entscheidungsschwäche" zu erhalten. Immerhin hatte ich damit bei mir festgestellt, dass ein 'Umschalten' von einem Entfernungsbereich in den Anderen, immer bei ca. 0,5 cm liegt. Bei einer Auflösung von ca. 3 cm ab ungefähr 40 cm hört sich das zwar nicht gut an, da der Chirp aber immer von 'Nah nach Fern' messen muss, nähern wir uns also immer aus der gleichen Richtung der 'tatsächlichen' Entfernung an, und somit gibt es dort keine Hysterese. Und das 'schlackern' vom Ergebnis am Umschaltpunkt ist nur relativ selten.
robo.fr und inka habe beide ungefähr die gleiche Beziehung zwischen OCR2-Wert und Entfernung. Bei mir ist 'nur' die Skalierung' anders.
Ich hatte ein graues Mauspad an die Wand gestellt und den Asuro, auf dem Fußboden stehend, die Messungen machen lassen.
robo.fr mag gerne Joghurt und nutzt diese Hindernisse.
Als logische Konsequenz muss inka somit auch Joghurt mögen.
Hier sollten wir eventuell mal eine genormte 'Test-Reflektorfläche' definieren und für teuer Geld verkaufen. Haben die Banken ja auch schon lange Zeit gute Erfahrung gemacht die Leute zu veräppeln. Früh genug aus dem Geschäft muss man halt nur aussteigen.
Wenn ich mir nun deinen Programmausschnitt ansehe, und deine Beschreibung dazu durchacker, dann bin ich mir relativ sicher, dass du auf den gleichen Mist gestoßen bist wie ich auch.
Die von dir angesteuerte "Kopier"-Led hängt an Port C0. Die Statistik, die du betreibst, liegt in deinen beiden for(k und n)-Schleifen. Aber auch die Auswertung ist noch innerhalb beider Schleifen. Somit sammelst du keine Daten in einer inneren Messschleife; betreibst Statistik; und schaltest dann nur die LED entsprechend. >= Ergo: Deine LED und natürlich der Oska 'flattern' wie die Weltmeister.
Genau das Problem hatte ich auch zu Anfang, bis ich eben diese Statistik eingebaut hatte und die Auswertung hinter die Statistik-Sammel-Loop gelegt hatte um dann erst daraus die Entfernung/Aktion ("Kopier"-Led) zu machen.
Ich habe das, wie oben schon angedeutet, mit 1000-fachem Statistik sammeln getan. Das entspricht deiner inneren for(m)-Loop. Und robo.fr hat weniger Statistik, verzögert mit einem Sleep() betrieben, und auch dann erst ausgewertet.
Somit ist ein 'flattern' der ermittelten Entfernung nur in der Frequenz reduziert, aber eben durch die Statistik besser 'untermauert'.
Hier noch mal dein Programmstück mit der von mir markierten Stelle, an der du ändern solltest für weitere Tests:
Als kleine 'Unschönheit' versaust du dir die Statistik auch noch an 2 Stellen:Code:for (uint16_t k = 0; k <= 1000; k = k + 1) { for (uint16_t m = 0; m <= 2000; m = m + 1) { tmp = PINB; if (!(tmp & 0x08)) // Aktionen für gelöschtes Bit if (istaus > 0) istaus = istaus--; // heisst: Counter runterzählen else // .. wenn Bit nicht gelöscht, dann ist es gesetzt { inix = istaus; // Dummyaktion } else // wenns nicht gelöscht ist, ist es gesetzt :) if (istaus < 1000) istaus = istaus++; // also Counter raufzählen bis 1 000 else { inix = istaus; // DD doofer Dummy, nix machen } } // <==== Hier die Statistik-Sammlung OHNE AUSWERTUNG loopen lassen // <==== Ab hier erst nach der Datenerhebung diese nun auswerten. // ##### danach vergleiche was größer ist: // ##### wenn über xxx, Port einschalten, wenn unter xxx Port ausschalten if (istaus < 10) { // hier die Anweisungen, wenn das Bit gelöscht ist PORTC &= ~(1<<PC0); // lösche PC0 } else // .. wenn Bit nicht gelöscht, dann ist es gesetzt if (istaus > 990) PORTC |= (1<<PC0); // Setze PC0 else { } // } // <==== Ist nun ueberfluessig }
1) Variable istaus wird bei dir zwischen 0 und 1000 begrenzt. Damit verlierst du Statistikinformationen.
2) Nach der Auswertung der Statistik machst du keinen Reset auf diese Variable. Du nimmst somit (das begrenzte) Vorgängerergebnis in die nächste Runde mit.
So, mehr Sermon kann ich im Moment nicht mehr von mir geben.
Berichte mal über deine Reflektorfläche(n), die du zum testen nutzt. Nicht die Hand, sondern so etwas wie Mauspads, Füchse oder Joghurtbecher meine ich
Gruß Sternthaler
P.S.: Das mit dem von mir angegebene 'Taktverhältnis von <40%' kommt aus dem I-Net von hier.
Ob ich da mit dem Verstehen klar gekommen bin müßt ihr entscheiden.
Wahrscheinlich ist die Angabe '2theta½: 55 °' eher zuständig. Aber damit kann ich rein gar nix anfangen.
P.P.S.: (Wenn schon lang, dann richtig) Im übrigen gefällt mir deine Platine sehr gut. Stecker deutet auf viele Anwendungsideen hin.
Lieber Asuro programieren als arbeiten gehen.
Hallo Sternthaler,
einfach klar: Deine Gedanken, Dein Urteil - sehr schön dargestellt. Vielen Dank. Ich hatte das Programm ja mal so als ersten Versuch zu diesem Thema geschrieben und die "Kopier-LED" eingeführt, weil der Oskar bei mir seitlich am Boden steht. So habe ich die Wirkung der Bedämpfung immer vor Augen.
Mittlerweile habe ich auch meine Lochrasterplatine verkleinert (um 20%) - LxBxH = 21x14x11,5 - Lüa incl. Steckkontakte 28,2 - und mit getrenntem GND für LED und Receiver versehen - so ist sie für die Testphase universeller. Da bei konkreten Anwendungen ein Stecker nicht dranmuss, können dann dieser und nochmal 10 % Lochreihen vermieden werden.
...............Bild hier
Ein wesentlicher Grund für das neue Platinchen waren die Schaltungsbeispiele in den doc´s. Beim Vergleich beider Platinen konnte ich feststellen, dass die Peripherie recht unkritisch ist. In der kleinen Platine, im Bild oben, habe ich jetzt einen (klein geratenen) 100 µF, und den SIG-GND-Widerstand, der in den doc´s gezeigt ist! 47k sind hoffentlich >10k. Die Ergebnisse sind nicht erkennbar besser, aber offensichtlich keinesfalls schlechter als früher mit der "asuro-like" Peripherie.
Wichtig erscheint mir folgendes Zwischenergebnis: "eure" OCR-Werte gehen ja von FE runter, meine gehen von 1 hoch! Und wenn ich das testweise vergleiche, stelle ich fest, dass bei meiner Fahrweise ein ziemlich gut abgestufter Nahbereich existiert, während die LED-Anregung von "oben herunter" offenbar im Fernbereich Vorteile bietet. Das muss ich noch ein bisschen besser untermauern. Und irgendwann werde ich aus diesen - schon eher spielerischen Variationen - eine konkrete Entfernungsmessung machen.
Meine gegenwärtige Reflektorfläche ist die verfügbarste, die ich kenne: die Hand. Ich hätte keinerlei Problem, das wirklich prädestinierte Normteil dafür zu nehmen - die Graukarte (Wozu ne gute Nikon, wenn die ohne Graukarte ist
PS: mit ".. Schnittstelle des asuro" bin ich natürlich mittlerweile OT geraten, ist das noch akzeptabel?
Geändert von oberallgeier (04.01.2018 um 10:01 Uhr)
Ciao sagt der JoeamBerg
Klar, ist interessantes OTist das noch akzeptabel?
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Ohhh .Zitat von Sternthaler
Na ja, ich bin da auch etwas durcheinander, weder kenne ich alle Datenblätter, noch habe ich Lust zu viele zu sammeln.
Mit θ wird ja allgemein auch der Polarwinkel benannt. Die General Application Note for SFH511X schreibt auf Seite 4:
In x-direction (horizontal, landscape) the half angle is bigger, even at 55° the transmission distance is still at 70% of it’s on axis figure ...
Nun haben ja manche englisch sprechende Wesen nix am Hut mit Azimut oder so, aber die Linse des 511x ist ja oval und landscape-weise länger als in "y-direction (vertical, portrait)". Daher denke ich, das ist ein Hinweis auf die Größe des Erfassungswinkels. Damit wäre der SFH5110 als IR-Empfänger in Unterhaltungselektronik gut, aber mit der SFH415 für UNSERE Zwecke schlecht abgestimmt. Durcheinander bin ich blos, weil unterschiedlich zur Gen App Note der Infineon/Osram flyer diesen Winkel mit φ benennt, z.B. "Vertical Directivity φy". Ok, viel Unklares über Unklares.
Ciao sagt der JoeamBerg
Na dann wollen wir doch die Datenblätter vergessen und uns wieder dem OT zuwenden.
Ach nee, im Moment interessiert mich eher, wie du dein komplettes Testprogramm gebaut hast. Wenn du hier davon sprichst, dass du die OCR-Werte bei 1 beginnen lässt, dann muss deine Signalauswertung ja 'umgedreht' arbeiten. (Männchen machen, wenn das Hindernis gerade nicht mehr gesehen wird.)
Ich hatte bei meinen Versuchen sehr schnell festgestellt, dass die Reichweite irgendwo bei 0xFE-60 schon über 2 Metern beträgt. Soll heißen, wenn ich bis 0xFE-253, zu deiner 1 kommend, messen würde, dann hätte ich eine, bestimmt nur theoretische, Reichweite von fast 8 Metern.
Ich hatte so für mich entschieden, dass ich mit dem Wert 0xFE-32, und damit erkennbaren Hindernissen in ca. 1,2 Metern, zufrieden bin. (Bis zu 2 Meter habe ich erfolgreich ausgetestete.)
Irgendwie habe ich im Ohr, dass du nur eine Reichweite von ca. 40 cm schaffst.
Kannst du mich aufklären, ob das so stimmt, und was dann vor allem bei dir ein "Fernbereich" ist, bei dem du von "oben herunter" Vorteile siehst.
Diesen Aspekt, Nah- und Fernsensor, finde ich recht spannend.
Gruß Sternthaler
@radbruch
Wie schaffst du es immer, dich so kurz und präzise auszudrücken?Ich kann das irgendwie nicht
Lieber Asuro programieren als arbeiten gehen.
Hallo Sternthaler, ok, ich geh mal drüber, brauche aber mindestens bis morgen.
Ciao sagt der JoeamBerg
Das Entscheidende an dem ganzen Aufbau ist, dass der Sender und der Empfänger ziemlich lichtdicht voneinander abgeschirmt sind. Das war im ersten Bild nicht der Fall. Beim 2ten Bild mit dem Schrumpfschlauch wäre die Frage, ob der Boden der IR-Sendediode zuviel Licht nach hinten abstrahlt.
Ach ja, ein kleiner Wermutstropfen bei dieser Art der Abstandsmessung gibt es: Die Empfindlichkeit des IR-Empfängers ist auch vom Umgebungslicht abhängig. Je nach eingeschalteter Umgebungsbeleuchtung wird der Detektionsabstand verändert.
Ausserdem vermute ich, dass die einzelnen SF5110 große Toleranzen haben. Beim Zusammenbau eines ASURO ging die Programmierung so schlecht, dass der SFH5110 ausgetauscht werden musste. Danach lief die Programmierung einwandfrei. Die Dantenübertragung bei der Programmierung nutzt den SFH5110 auch ausserhalb der Spezifikation.
Gruß,
robo
Berechtigungen
Zitieren
Lesezeichen