StefanP Geschrieben October 15, 2013 at 11:19 Geschrieben October 15, 2013 at 11:19 Hallo! Habe gerade ein Distance IR Bricklet mit Sharp 2Y0A02 (20-150cm) in Betrieb genommen. Dazu habe ich, wie auf http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Distance_IR.html#distance-ir-bricklet beschrieben, die für den Sensor gedachte Datei mit der Spannung<->Distanz Tabelle heruntergeladen und mit dem Brick Viewer auf das Bricklet gesichert. https://github.com/Tinkerforge/distance-ir-bricklet/raw/master/software/calibration/2Y0A02.txt Anschließend - wie gefordert - Reset. Leider bekomme ich nur zwei Werte im Viewer. Entweder 150cm oder 15cm. Die "Analog values" wackeln zwischen 0 und 32. Mehr nicht. Was habe ich falsch gemacht? Gruß Stefan Zitieren
photron Geschrieben October 15, 2013 at 12:00 Geschrieben October 15, 2013 at 12:00 Die Anzeige des Analogwertes ist in der Tat in brickv falsch. Das ist ein reines Darstellungsproblem und wird in der nächsten Version behoben sein. Dank für den Hinweise. Die Bricklets werden von uns schon passen für den angesteckten Sensor kalibriert ausgeliefert. Neukalibierien ist nur notwenig, wenn du den Sensor gegen einen anderen Typ tauscht. Es kann aber nicht schaden die Kalibrierung neuzuladen. Das kann dein Problem nicht verursacht haben haben. Unter welchen Bedingungen wird denn 150cm und unter welchen Bedingungen 15cm angezeigt? Schau dir auch einmal die Pins der Brickletstecker am Brick und am Bricklet an, um sicher zu sein, dass dort keiner der Pins krumm ist und einen Kurzschluss verursacht. Zitieren
StefanP Geschrieben October 15, 2013 at 13:00 Autor Geschrieben October 15, 2013 at 13:00 Stecker und Kabel habe ich optisch geprüft -> OK Master-Brick und Kabel getauscht -> Gleiche Problematik Hier eine Übersicht: Real / angezeigt / AnalogValue 0cm / 150cm / 0 0,5cm-20cm / 15cm / 2-32, anfangs nicht stetig steigend 20cm-150cm / 15cm / 32-5, stetig fallend Alle Werte "mit der Hand" gemessen, Messwerte stammen von Brick Viewer 2.0.7. Die Tendenz ist aber so und immer eindeutig wiederholbar. Habe fast das Gefühl, die IR-Diode ist defekt. Was meinst Du? Gruß Stefan Zitieren
photron Geschrieben October 15, 2013 at 14:50 Geschrieben October 15, 2013 at 14:50 Okay, unter 20cm misst der Sensor nicht mehr richtig, da kommen dann falsche Werte raus, das ist okay. Die Distanz in cm ist also entweder 15cm oder 150cm, ohne Zwischenwerte. Der Analogwert verhält sich aber umgekehrt wie die real angelegte Distanz. Wenn dem so ist, dann ist der Sensor an sich okay, aber die Umrechnung im Bricklet passt nicht. Wenn du dir 2Y0A02.txt ansieht, dann steht da die verwendete Umrechnung zwischen Analogwert und Distanz 3230 entspricht 15cm und 518 entspricht 150cm. Da brickv momentan den Analogwert geteilt durch 100 anzeigt siehst du Werte zwischen 5 und 32. Das kommt also hin. Ich nehme mal an, dass du einen Analogwert von etwa 10 (eigentlich 1058) angezeigt bekommst wenn du dem Sensor eine reale Distanz von 70cm vorhältst. Wenn dem so ist und die anzeigten Analogwerte denen in 2Y0A02.txt entsprechen, dann ist der Sensor okay. Warum nun die Umrechnung nicht passt ist nicht ganz klar. Du kannst testen das Plugin des Bricklets neu zu flashen und dann noch mal die Kalibrierung zu laden. Zitieren
StefanP Geschrieben October 15, 2013 at 15:30 Autor Geschrieben October 15, 2013 at 15:30 Danke für die Infos. Aber irgendwie habe ich dann die Doku falsch verstanden. Der AnalogValue (der, den ich per API abfragen kann) ist doch ein einheitenloser 12-Bit Wert, der die Entfernung mit höherer Auflösung repräsentiert. Dagegen sind die Werte in 2Y0A02.txt doch Spannungswerte des Sensors. Steht so zumindest in der Doku als Spannung/Distanz Abbildung. Anders gesagt: Aus den Spannungswerten werden die AnalogValues (0..4095) UND die Distanz-Werte (20-150cm) berechnet, indem die aus den Stützwerten berechneten Korrekturfaktoren "draufmultipliziert" werden. Oder nicht? Zitieren
StefanP Geschrieben October 15, 2013 at 15:54 Autor Geschrieben October 15, 2013 at 15:54 Update: Habe das Bricklet gerade neu geflasht. Danach hat es wieder gelebt. Allerdings so, als wenn ein GP2Y0A21 (10cm-80cm) wäre. Wenn ich dann die vermeintlich korrekte Umrechnung aus 2Y0A02.txt einspiele, dann ist das Problem wieder da. Nur 15cm oder 150cm. Voll digital sozusagen :-( Da scheint etwas mit der Datei oder der Übertragung nicht zu stimmen. Was nun? Zitieren
borg Geschrieben October 15, 2013 at 17:20 Geschrieben October 15, 2013 at 17:20 Hast du schonmal in die Datei reingeguckt, sieht das Sinnvoll aus darin? Sieht so aus als hätte der Brick Viewer ein Problem damit die Datei zu parsen. Welches Betriebssystem nutzt du? Dann testen wir das hier mal. Zitieren
StefanP Geschrieben October 16, 2013 at 06:45 Autor Geschrieben October 16, 2013 at 06:45 Windows 7 Pro, habe es auch von einer Windows XP Pro Installation versucht. Sowohl über USB als auch über Ethernet Extension. Datei sieht normal aus, siehe unten: # cm: analog value 150: 518 140: 555 130: 599 120: 647 110: 694 100: 766 95: 790 90: 838 85: 885 80: 930 75: 998 70: 1058 65: 1140 60: 1234 55: 1355 50: 1472 45: 1632 40: 1812 35: 2068 30: 2337 25: 2652 20: 2959 15: 3230 Zitieren
AuronX Geschrieben October 16, 2013 at 10:13 Geschrieben October 16, 2013 at 10:13 Irgendeine chance, dass die zeilenumbrüche falsch geparsed werden? #schussinsblaue Zitieren
StefanP Geschrieben October 16, 2013 at 11:20 Autor Geschrieben October 16, 2013 at 11:20 Die Dateien hatten CR LF als Zeilenumbruch. Habe jetzt mal nur CR bzw. nur LF probiert. Nur CR: Da passiert gar nichts Nur LF: Verhält sich wie mit CR LF Zitieren
photron Geschrieben October 16, 2013 at 15:21 Geschrieben October 16, 2013 at 15:21 Zeilenenden sollten kein Problem sein. Was ein Problem sein kann ist, wenn die Sample Point Datei mit dem Internet Explorer heruntergeladen wurde. IE ist so frei und ändert den Inhalt der Datei im dem er einen UTF-8 Byte Order Marker vorne davor hängt. Hier jetzt eine Version von brickv mit robusterem Parsing der Datei, das auch mit dem UTF-8 BOM umgehen kann. http://download.tinkerforge.com/_stuff/brickv_windows_2_0_7_distir4.exe Dann noch eine kleines Programm zum Auslesen der Kalibrierung eines Distance IR Bricklets. http://download.tinkerforge.com/_stuff/distance_ir_get_sample_points.exe Einfach das Programm starten, UID des Bricklets eingeben und Enter drücken. Die Ausgabe sollte für den 150cm Sensor so aussehen, wobei ich aber davon ausgehen, dass sie bei dir anders aussieht und genau dass das Problem ist. 0: 15000 1: 15000 2: 15000 3: 15000 4: 15000 5: 15000 6: 15000 7: 15000 8: 15000 9: 15000 10: 15000 11: 15000 12: 15000 13: 15000 14: 15000 15: 15000 16: 15000 17: 14286 18: 13498 19: 12814 20: 12153 21: 11436 22: 10846 23: 10454 24: 9960 25: 9344 26: 9048 27: 8744 28: 8369 29: 8019 30: 7762 31: 7544 32: 7286 33: 7016 34: 6792 35: 6608 36: 6435 37: 6259 38: 6089 39: 5935 40: 5799 41: 5672 42: 5545 43: 5411 44: 5270 45: 5131 46: 5000 47: 4883 48: 4778 49: 4682 50: 4590 51: 4500 52: 4408 53: 4316 54: 4224 55: 4135 56: 4050 57: 3971 58: 3898 59: 3830 60: 3767 61: 3707 62: 3649 63: 3592 64: 3536 65: 3478 66: 3419 67: 3359 68: 3299 69: 3238 70: 3178 71: 3118 72: 3059 73: 3002 74: 2946 75: 2892 76: 2840 77: 2789 78: 2739 79: 2689 80: 2640 81: 2592 82: 2543 83: 2494 84: 2444 85: 2395 86: 2344 87: 2293 88: 2241 89: 2189 90: 2136 91: 2081 92: 2026 93: 1970 94: 1913 95: 1855 96: 1796 97: 1737 98: 1677 99: 1617 100: 1500 101: 1500 102: 1500 103: 1500 104: 1500 105: 1500 106: 1500 107: 1500 108: 1500 109: 1500 110: 1500 111: 1500 112: 1500 113: 1500 114: 1500 115: 1500 116: 1500 117: 1500 118: 1500 119: 1500 120: 1500 121: 1500 122: 1500 123: 1500 124: 1500 125: 1500 126: 1500 127: 1500 Zitieren
StefanP Geschrieben October 16, 2013 at 16:08 Autor Geschrieben October 16, 2013 at 16:08 Jawoll!!! Mit der neuen Version des Brick Viewers funktioniert es! Habe die Werte mal ausgelesen, entspricht jetzt den von Dir gezeigten Werten. Was ärgerlich ist: Ich hatte mir die 2Y0A02.txt im Hex-Viewer angesehen, die 0x23 0x20 am Anfang habe ich aber geflissentlich übersehen :-( Der Download erfolgte übrigens nicht mit dem IE, sondern mit Firefox. Entweder gibt es da dasselbe Problem oder die Datei liegt schon mit BOM auf eurem Server... Naja, Hauptsache Problem gelöst. Danke für den Support sagt Stefan Zitieren
photron Geschrieben October 16, 2013 at 16:45 Geschrieben October 16, 2013 at 16:45 0x23 0x20 ist "# ", das ist okay. UTF-8 BOM ist 0xEF 0xBB 0xBF. Ich habs gerade noch mal geprüft und die Datei liegt ohne BOM auf github.com und mit Chrome unter Linux kann ich sie auch so runterladen. Mit Firefox machts auch keine Probleme. Wie dem auch sei, Hauptsache es funktioniert jetzt Die Verbesserungen werden dann auch Teil der nächsten brickv Version sein. Zitieren
StefanP Geschrieben October 16, 2013 at 17:24 Autor Geschrieben October 16, 2013 at 17:24 Hm, werde morgen nochmal nachsehen, ob mein Editor (PS-Pad) in der Hex-Ansicht eine BOM "schluckt". Gesehen habe ich dann nämlich keine BOM. PS: Die Anzeige des "Analog Value" stimmt jetzt auch im Viewer. Well done! Zitieren
StefanP Geschrieben October 17, 2013 at 07:07 Autor Geschrieben October 17, 2013 at 07:07 Nein, meine 2Y0A02.txt besitzt keine BOM am Anfang. Geht mit 0x23 0x20 los. Naja, neuer BrickViewer funktioniert, Thema abgeschlossen. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.