Distance IR - Kalibrierung falsch!?

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

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.

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

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.

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?

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?

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.

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

Irgendeine chance, dass die zeilenumbrüche falsch geparsed werden?

#schussinsblaue

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

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

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

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.

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!

Nein, meine 2Y0A02.txt besitzt keine BOM am Anfang. Geht mit 0x23 0x20 los.

Naja, neuer BrickViewer funktioniert, Thema abgeschlossen.