Freitag, 6. April 2012
Datenkabel einsatzfertig
Mein USB-seriell Datenkabel hatte ich ja vor ein paar Tagen vorgestellt. Funktioniert wunderbar, aber immer mit nackten Kabelenden rumhantieren fand ich lästig. Außerdem kann sich mein vorgealtertes Hirn immer nicht merken, welche Farbe nun gleich wieder welches Signal führt. Und so habe ich beschlossen, dem ganzen ein paar Header Pins und Buchsen sowie eine Legende zu verpassen. Nicht der anspruchvollste Blog-Beitrag der Geschichte, aber egal. Hier isses:
Donnerstag, 5. April 2012
Netzspannungsüberwachung – Teil 2
Erster Praxistest
Nachdem wir nun ein (hoffentlich) µController-freundliches Spannungssignal haben ist es an der Zeit, einen ersten Praxistest zu starten. Dazu habe ich eines der Beispielprogramme für den Arduino (AnalogReadSerial) genommen und minimal modifiziert (konkret: die Datenübertragung über die serielle Schnittstelle auf 115200 bps hoch gesetzt). Das Programm tut nicht anderes, als den vom ADC gelesenen Rohwert über die serielle Schnittstelle zu funken. Mit seinen 16MHz Takt sollte der Arduino locker in der Lage sein, dem Spannungssignal zu folgen. Die Schnittstelle ist hier klar der Flaschenhals, dennoch sieht der erste Test sehr erfreulich aus. Ich habe einfach die Daten einen Moment lang mit geloggt und in eine Datei geschrieben und dann ein paar Datenpunkte einfach der Reihenfolge nach geplottet, d.h. die Zeitachse ist nicht notwendigerweise vertrauenswürdig. Dennoch sieht das Ergebnis einer sinusförmigen Halbwelle schon erfreulich ähnlich:
Quiz
Was wir hier messen ist ja die positive Halbwelle der Wechselspannung. Also sollte die Periode ohne Spannung genauso lang sein, wie die sichtbare Halbwelle. Ist sie aber im obigen Plot nicht! Es sieht eher nach einem Verhältnis von ca. 1:2 aus. Zuerst war ich verwirrt. Könnte es sein, daß die Geschwindigkeit des ADC von der anliegenden Spannung abhängt? Unwahrscheinlich, außerdem ist der ADC um einiges schneller, als die Schnittstelle. Aber welches Geheimnis steckt dann dahinter? Dann dachte ich, es verstanden zu haben und schließlich bin ich wieder verwirrt.
Preisfrage: Wie kommt dieses Artefakt zustande?
Wer es zuerst rauskriegt bekommt einen selbstgebastelten IR-Tester von mir ;-)
Ausblick
Jetzt muss ich nur noch die Software ein bisschen aufbohren: Peak-Spannung über ein bestimmtes Zeitfenster mitteln und die Daten auf SD-Karte speichern. Danach heißt es dann eine ganze Weile Geduld haben, denn wir wollen ja Statistik über ein paar Wochen betreiben.
Nachdem wir nun ein (hoffentlich) µController-freundliches Spannungssignal haben ist es an der Zeit, einen ersten Praxistest zu starten. Dazu habe ich eines der Beispielprogramme für den Arduino (AnalogReadSerial) genommen und minimal modifiziert (konkret: die Datenübertragung über die serielle Schnittstelle auf 115200 bps hoch gesetzt). Das Programm tut nicht anderes, als den vom ADC gelesenen Rohwert über die serielle Schnittstelle zu funken. Mit seinen 16MHz Takt sollte der Arduino locker in der Lage sein, dem Spannungssignal zu folgen. Die Schnittstelle ist hier klar der Flaschenhals, dennoch sieht der erste Test sehr erfreulich aus. Ich habe einfach die Daten einen Moment lang mit geloggt und in eine Datei geschrieben und dann ein paar Datenpunkte einfach der Reihenfolge nach geplottet, d.h. die Zeitachse ist nicht notwendigerweise vertrauenswürdig. Dennoch sieht das Ergebnis einer sinusförmigen Halbwelle schon erfreulich ähnlich:
Quiz
Was wir hier messen ist ja die positive Halbwelle der Wechselspannung. Also sollte die Periode ohne Spannung genauso lang sein, wie die sichtbare Halbwelle. Ist sie aber im obigen Plot nicht! Es sieht eher nach einem Verhältnis von ca. 1:2 aus. Zuerst war ich verwirrt. Könnte es sein, daß die Geschwindigkeit des ADC von der anliegenden Spannung abhängt? Unwahrscheinlich, außerdem ist der ADC um einiges schneller, als die Schnittstelle. Aber welches Geheimnis steckt dann dahinter? Dann dachte ich, es verstanden zu haben und schließlich bin ich wieder verwirrt.
Preisfrage: Wie kommt dieses Artefakt zustande?
Wer es zuerst rauskriegt bekommt einen selbstgebastelten IR-Tester von mir ;-)
Ausblick
Jetzt muss ich nur noch die Software ein bisschen aufbohren: Peak-Spannung über ein bestimmtes Zeitfenster mitteln und die Daten auf SD-Karte speichern. Danach heißt es dann eine ganze Weile Geduld haben, denn wir wollen ja Statistik über ein paar Wochen betreiben.
Mittwoch, 4. April 2012
Netzspannungsüberwachung
Teil 1 – Netzspannung mit einem µController messen?
Neulich stellte jemand die Behauptung auf, sonntags bräuchte der Braten länger, weil da alle kochen und so weniger Strom zur Verfügung stünde. Mal abgesehen davon, daß das extrem unplausibel ist, fand ich dennoch die Idee lustig, mal über einen gewissen Zeitraum Statistik über die Netzspannung zu führen und so ist dieses Projekt entstanden.
Netzspannung messen – nichts leichter als das dachte ich mir. Das kann selbst das billigste Multimeter halbwegs zuverlässig. Aber damit ist es natürlich nicht getan, denn wir wollen ja Statistik treiben und dazu wäre es vernünftig, z.B. alle 5 Minuten zu messen und das Tag und Nacht und mindestens über eine Woche. Also Multimeter mit serieller Schnittstelle am PC? Ginge wohl, aber das einzige Multimeter mit Schnittstelle, das ich besitze ist ein uraltes Voltcraft, dem ich eigentlich nicht mehr recht traue. Außerdem weiß ich nicht, ob die Batterien das mitmachen würden. Ein richtiges Data-logging Multimeter, wie das Fluke 289 wäre eine gute Lösung, aber erstens habe ich keines und zweitens waren mir die 500 bis 700 €, die so ein Ding, je nach Laden und Zubehör, kosten ehrlich gesagt zu viel für ein Spaßprojekt.
Also selbst ist der Mann: Mit einem Mikrocontroller und einem SD-Card Adapter sollte das doch kein Problem sein. Nur wie wollen wir die Netzspannung messen? 240 Volt am ADC-Pin dürfte der Chip übel nehmen. Spannungsteiler? Ginge, aber will ich wirklich 240 Volt nackt auf der Platine haben? Direkt neben dem Controller? Eher nicht, wenn es sich vermeiden lässt. Zudem bin ich mir garnicht sicher, ob die 0.25W Metallfilmwiderstände aus meinem Sortiment überhaupt für so hohe Spannungen geeignet sind. Also anders: AC Steckernetzteil, Gleichrichter und dann ggf. noch Spannungsteiler, um das in den richtigen Spannungsbereich für den ADC zu bringen. Am Ende muß man das dann halt kalibrieren. In der Bastelkiste lag noch ein Steckernetzteil von einem altem Anrufbeantworter (nominell 9V AC, 780mA):
Eine schnelle Messung ergab, daß das Ding im Leerlauf so ca. 11 Volt RMS ausspuckt. Wenn das Netzteil die Sinusform halbwegs erhält, wären das dann also ±11∙SQRT(2) = 15.6 Volt oder ca. 31 Vpp. Also mal am Oszi ansehen:
Nicht der schönste Sinus der Welt, aber gut genug. Nun muß noch die Spannung in einen vernünftigen Bereich gebracht werden, der den Microcontroller nicht ins Schwitzen bringt. Am besten irgendwo in den mittleren Spannungsbereich, damit uns die zu erwartenden Spannungsschwankungen im Netz nicht an irgendwelche Grenzen bringen. Also habe ich einen Spannungsteiler aus 130k und 22k aufgebaut, was die ca. 15Vmax der Halbwelle auf zahme ca. 2Vmax über dem 22k Widerstand herunterbringt. Bei 152k und 15V fließen also maximal 100µA, so daß wir uns über den Stromverbrauch über die Messperiode auch keine Sorgen machen müssen. Eine Diode später hatte ich dann nur noch die positive Halbwelle:
So kann man arbeiten! Fortsetzung folgt...
Neulich stellte jemand die Behauptung auf, sonntags bräuchte der Braten länger, weil da alle kochen und so weniger Strom zur Verfügung stünde. Mal abgesehen davon, daß das extrem unplausibel ist, fand ich dennoch die Idee lustig, mal über einen gewissen Zeitraum Statistik über die Netzspannung zu führen und so ist dieses Projekt entstanden.
Netzspannung messen – nichts leichter als das dachte ich mir. Das kann selbst das billigste Multimeter halbwegs zuverlässig. Aber damit ist es natürlich nicht getan, denn wir wollen ja Statistik treiben und dazu wäre es vernünftig, z.B. alle 5 Minuten zu messen und das Tag und Nacht und mindestens über eine Woche. Also Multimeter mit serieller Schnittstelle am PC? Ginge wohl, aber das einzige Multimeter mit Schnittstelle, das ich besitze ist ein uraltes Voltcraft, dem ich eigentlich nicht mehr recht traue. Außerdem weiß ich nicht, ob die Batterien das mitmachen würden. Ein richtiges Data-logging Multimeter, wie das Fluke 289 wäre eine gute Lösung, aber erstens habe ich keines und zweitens waren mir die 500 bis 700 €, die so ein Ding, je nach Laden und Zubehör, kosten ehrlich gesagt zu viel für ein Spaßprojekt.
Also selbst ist der Mann: Mit einem Mikrocontroller und einem SD-Card Adapter sollte das doch kein Problem sein. Nur wie wollen wir die Netzspannung messen? 240 Volt am ADC-Pin dürfte der Chip übel nehmen. Spannungsteiler? Ginge, aber will ich wirklich 240 Volt nackt auf der Platine haben? Direkt neben dem Controller? Eher nicht, wenn es sich vermeiden lässt. Zudem bin ich mir garnicht sicher, ob die 0.25W Metallfilmwiderstände aus meinem Sortiment überhaupt für so hohe Spannungen geeignet sind. Also anders: AC Steckernetzteil, Gleichrichter und dann ggf. noch Spannungsteiler, um das in den richtigen Spannungsbereich für den ADC zu bringen. Am Ende muß man das dann halt kalibrieren. In der Bastelkiste lag noch ein Steckernetzteil von einem altem Anrufbeantworter (nominell 9V AC, 780mA):
Eine schnelle Messung ergab, daß das Ding im Leerlauf so ca. 11 Volt RMS ausspuckt. Wenn das Netzteil die Sinusform halbwegs erhält, wären das dann also ±11∙SQRT(2) = 15.6 Volt oder ca. 31 Vpp. Also mal am Oszi ansehen:
Nicht der schönste Sinus der Welt, aber gut genug. Nun muß noch die Spannung in einen vernünftigen Bereich gebracht werden, der den Microcontroller nicht ins Schwitzen bringt. Am besten irgendwo in den mittleren Spannungsbereich, damit uns die zu erwartenden Spannungsschwankungen im Netz nicht an irgendwelche Grenzen bringen. Also habe ich einen Spannungsteiler aus 130k und 22k aufgebaut, was die ca. 15Vmax der Halbwelle auf zahme ca. 2Vmax über dem 22k Widerstand herunterbringt. Bei 152k und 15V fließen also maximal 100µA, so daß wir uns über den Stromverbrauch über die Messperiode auch keine Sorgen machen müssen. Eine Diode später hatte ich dann nur noch die positive Halbwelle:
So kann man arbeiten! Fortsetzung folgt...
Montag, 2. April 2012
Serielles TTL Datenkabel
Um das vermaledeite Siemens Handy zu entsperren hatte ich mir ja extra ein USB Datenkabel besorgt – das ist nun arbeitslos. Also ist es an der Zeit auch das Kabel mal einer Obduktion zu unterziehen. Offenbar ist es nichts weiter als ein USB2serial Adapter auf PL2303 Basis – jedenfalls meldet es sich so beim Computer:
Auf der USB-Seite findet sich erwartungsgemäß ein (leider vergossener) IC, ein Quarz (12MHz) und etwas Kleinkram. Die Terminals sind freundlicherweise beschriftet:
Ich würde sagen, das werfe ich nicht weg – sowas kann man ja noch brauchen. Und wenn ich so darüber nachdenke, dann kommt mir eine Idee: Könnt Ihr Euch vorstellen, daß da wirklich ein RS232-Pegelwander a la MAX232 drin ist? Und im Handy dann noch einer? Ich nicht! Wenn ich Siemens wäre, hätte ich da einfach die TTL Pegel aufs Kabel gelegt und mir das Wandeln gespart. Bei den paar Zentimetern Kabel sollte das kein Problem sein. Wenn dem so ist, könnte das Teil recht nützlich sein. Zwar haben die Arduinos einen USB/RS232 Wandler an Bord, aber manche Clones, z.B. das ITeadStudio iBoard, das ich zufällig habe, oder ein nackter Aufbau mit einem Mikrocontroller haben das nicht, so daß ein TTL-Seriell Kabel hilfreich wäre. Nicht umsonst verkaufen diverse Anbieter passende Breakout-Boards. Bleibt die Frage, mit welcher Spannung hier zu rechnen ist. 5V? 3.3V? Also mal anstecken und ein wenig messen. Zwischen GND und VCC liegen 4.6V. Aber gilt das notwendigerweise auch für die Signalpegel? Versuch macht kluch, also habe ich mal das Oszi zwischen GND und TX geklemmt und dann das Interface mit Nullen geflutet:
Laut Wikipedia gilt an Eingängen: ≤ 0.8V ist low und ≥ 2.0V ist high. Das trifft übrigens sowohl für 5V, als auch für 3.3V TTL zu. CMOS will ≤1.5V bzw. ≥ 3.5V. Also ist unser Signal mit beiden TTL Varianten und CMOS kompatibel. Vorausgesetzt ein 3.3V TTL Baustein nimmt die überzähligen 0.4V nicht übel, was ich mir aber eigentlich kaum vorstellen kann. Zumindest das Datenblatt für den ATmega328p, der in den Arduinos verbaut ist sagt unter absolute maximum ratings: „Voltage on any Pin except RESET: Vcc + 0.5V“. D.h. für den wäre das OK.
Also frisch ans Werk und mal die beiden Stecker aufmachen, um zu sehen wie die verbunden sind:Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Auf der USB-Seite findet sich erwartungsgemäß ein (leider vergossener) IC, ein Quarz (12MHz) und etwas Kleinkram. Die Terminals sind freundlicherweise beschriftet:
Auf der Handyseite landen die Kabel auf den entsprechenden Pins des Siemens-Lumberger Steckers.GND weiß
RX grün
DTR –
TX blau
VCC rot
Ich würde sagen, das werfe ich nicht weg – sowas kann man ja noch brauchen. Und wenn ich so darüber nachdenke, dann kommt mir eine Idee: Könnt Ihr Euch vorstellen, daß da wirklich ein RS232-Pegelwander a la MAX232 drin ist? Und im Handy dann noch einer? Ich nicht! Wenn ich Siemens wäre, hätte ich da einfach die TTL Pegel aufs Kabel gelegt und mir das Wandeln gespart. Bei den paar Zentimetern Kabel sollte das kein Problem sein. Wenn dem so ist, könnte das Teil recht nützlich sein. Zwar haben die Arduinos einen USB/RS232 Wandler an Bord, aber manche Clones, z.B. das ITeadStudio iBoard, das ich zufällig habe, oder ein nackter Aufbau mit einem Mikrocontroller haben das nicht, so daß ein TTL-Seriell Kabel hilfreich wäre. Nicht umsonst verkaufen diverse Anbieter passende Breakout-Boards. Bleibt die Frage, mit welcher Spannung hier zu rechnen ist. 5V? 3.3V? Also mal anstecken und ein wenig messen. Zwischen GND und VCC liegen 4.6V. Aber gilt das notwendigerweise auch für die Signalpegel? Versuch macht kluch, also habe ich mal das Oszi zwischen GND und TX geklemmt und dann das Interface mit Nullen geflutet:
Das Ergebnis sah dann so aus:cat /dev/zero > /dev/ttyUSB0
Laut Wikipedia gilt an Eingängen: ≤ 0.8V ist low und ≥ 2.0V ist high. Das trifft übrigens sowohl für 5V, als auch für 3.3V TTL zu. CMOS will ≤1.5V bzw. ≥ 3.5V. Also ist unser Signal mit beiden TTL Varianten und CMOS kompatibel. Vorausgesetzt ein 3.3V TTL Baustein nimmt die überzähligen 0.4V nicht übel, was ich mir aber eigentlich kaum vorstellen kann. Zumindest das Datenblatt für den ATmega328p, der in den Arduinos verbaut ist sagt unter absolute maximum ratings: „Voltage on any Pin except RESET: Vcc + 0.5V“. D.h. für den wäre das OK.
Praxistest
Theoretisch sieht das ja schonmal gut aus, aber klappt es in der Praxis? Dazu habe ich das Kabel mal an einen Arduino angeschlossen (RX-TX, TX-RX, GND-GND) und irgendein Beispiel-Datenlogger-Programm draufgeladen. Und siehe da – ich konnte den Datenstrom über das alte Handykabel ebenso lesen, wie über die USB2RS232 Schnittstelle. Cool! :-)Samstag, 31. März 2012
GSM/GPRS Modem Modul TC35
Nachdem das olle Handy ja nun ausgeschlachtet ist, stellte sich die Frage, wie mein SMS Kommunikationsprojekt nun weitergehen soll. Der Nachschub an alten Handies ist schier unerschöpflich, aber ehrlich gesagt hatte ich die Nase voll von widerspenstigen Handies, die zwar brav kommunizieren, aber ohne Akku rumzicken, blöde Entsperr-Codes von mir wollen etc. Diese Probleme können durchaus relevant werden, wenn man so ein Gerät tatsächlich in ein Heimautomatisierungssystem o.ä. integrieren will. Wer hat schon Lust je nach Laune des Telefons immer wieder mal irgendwelche Codes einzugeben etc.?
Also habe ich mich nach etwas Besserem umgesehen und es auch gefunden. Ein GSM/GPRS-Modem Entwicklerboard auf Basis des Siemens TC35 Moduls. Hat nicht viel gekostet, Doku zum Modul gibt es ohne Ende und das Ganze ist sehr bastlerfreundlich. Und so hüpfte ich vor Freude, als ich das Päckchen heute in unserem Post-Shop abgeholt habe. Hier ist es:
So – und mit dem Ding wollen wir im heutigen Post ein bisschen spielen. Zuerst also mal an den Compi anschließen, Saft drauf und freundlich hallo sagen:
Sieht schonmal gut aus, allerdings musste ich kurz einen Taster drücken, um das Modul zu aktivieren. Das sollte aber auch im unbeaufsichtigten Betrieb kein Problem sein, dann das kann ja ggf. der Mikrocontroller machen. Evtl. muss halt der Taster raus. Zunächst schalten wir nun die Benachrichtigung bei SMS-Eingang ein:
Das Ding kann recht viel – die Doku der AT-Kommandos ist über 400 Seiten lang! Ein paar Aspekte fand ich in Bezug auf künftige Bastelein aber besonders nützlich. Z.B. hat das Modul eine real-time clock, die man zwar erstmal stellen muß, aber das könnte man ja notfalls auch per SMS machen. Ideal, falls man Daten loggen möchte. Hier die Abfrage:
So – das war mein Bericht über den ersten Eindruck über das Modul. Ich bin soweit rundum zufrieden. Ich denke, das ist eine sehr schöne Basis für weitere Basteleien.
Also habe ich mich nach etwas Besserem umgesehen und es auch gefunden. Ein GSM/GPRS-Modem Entwicklerboard auf Basis des Siemens TC35 Moduls. Hat nicht viel gekostet, Doku zum Modul gibt es ohne Ende und das Ganze ist sehr bastlerfreundlich. Und so hüpfte ich vor Freude, als ich das Päckchen heute in unserem Post-Shop abgeholt habe. Hier ist es:
So – und mit dem Ding wollen wir im heutigen Post ein bisschen spielen. Zuerst also mal an den Compi anschließen, Saft drauf und freundlich hallo sagen:$ cu -l /dev/ttyUSB0 -s 57600
Connected.
at
OK
ati
SIEMENS
TC35
REVISION 04.00
OK
Sieht schonmal gut aus, allerdings musste ich kurz einen Taster drücken, um das Modul zu aktivieren. Das sollte aber auch im unbeaufsichtigten Betrieb kein Problem sein, dann das kann ja ggf. der Mikrocontroller machen. Evtl. muss halt der Taster raus. Zunächst schalten wir nun die Benachrichtigung bei SMS-Eingang ein:
Im Gegensatz zum Handy beherrscht dieses Modul den SMS-Text Modus, was ein echter Segen ist. Also schalten wir diesen nun ein:at+cnmi=1,1,0,0,1
OK
D.h. es ist jetzt an der Zeit eine SMS zu schicken, zu prüfen, ob wir benachrichtigt werden und die SMS dann auszulesen:at+cmgf=1
OK
Super – die erste Zeile hat uns, wie gewünscht, darüber informiert, daß eine Nachricht eingegangen ist und in Speicherplatz 1 abgelegt wurde. Und wie man sieht klappt die Abfrage wunderbar. Nur meine Handynummer habe ich verfälscht, denn die muß ja nicht jeder haben...+CMTI: "SM",1
at+cmgr=1
+CMGR: "REC UNREAD","+49151123456789",,"12/03/31,17:18:07+08"
Hello world.
OK
Das Ding kann recht viel – die Doku der AT-Kommandos ist über 400 Seiten lang! Ein paar Aspekte fand ich in Bezug auf künftige Bastelein aber besonders nützlich. Z.B. hat das Modul eine real-time clock, die man zwar erstmal stellen muß, aber das könnte man ja notfalls auch per SMS machen. Ideal, falls man Daten loggen möchte. Hier die Abfrage:
Nach meinem ersten Beitrag zur Handybastelei hatte Harald in einem Kommentar angemerkt, daß es doch cool wäre, wenn man seine Postion grob bestimmen könnte, indem man die Signalstärke diverser Zellen auswertet. Zwar habe ich nicht genau recherchiert, wie das mit Zellen IDs aussieht, aber zumindest kann man die Signalstärken in der Umgebung abfragen:at+cclk?
+CCLK: "00/01/01,00:39:13"
OK
Und der folgende Befehl liefert mehr Info über die aktuell genutzte Zelle, als ich je haben wollte:at^monp
chann rs dBm PLMN BCC C1 C2
42 46 -64 26201 7 43 43
40 35 -75 26201 7 32 32
21 27 -83 26201 3 24 24
124 22 -88 26201 2 19 19
15 6 -104 26201 3 3 3
32 0 -111 26201 6 -4 -4
OK
Ansonsten kann es natürlich alles, was man sich so vorstellt: GPRS Datenverkehr, Faxe senden und empfangen, ein Telefonbuch verwalten, Telefonate initiieren und annehmen (es gibt Mic und Headphone Buchsen), IMEI und IMSI abfragen, SIM-PIN ändern, ...at^smonc
^SMONC: 262,01,4460,36FF,76,94,61,58,58,262,01,4460,A032,07,42,47,44,44,262,01,445E,144A,27,40,36,33,33,262,01,4460,A031,02,124,25,22,22,262,01,4460,107B,23,21,26,23,23,262,01,445E,D0FE,13,15,5,2,2,000,00,0000,0000,00,0,0,0,0
OK
So – das war mein Bericht über den ersten Eindruck über das Modul. Ich bin soweit rundum zufrieden. Ich denke, das ist eine sehr schöne Basis für weitere Basteleien.
Mittwoch, 28. März 2012
Handy-Porno
Ihr erinnert Euch sicher an das alte Siemens Handy, das ich dazu auserkoren hatte, als Funkbasis meines Haustürautomatisierungssystems zu dienen und das sich, sagen wir, nicht völlig im Einklang mit meinen Vorstellungen verhielt. Soll heißen, ich habe das Problem mit der Spannungsversorgung nie wirklich in den Griff gekriegt, obwohl ich viele Male dachte, das sei nun echt erledigt. Dann könnt Ihr sicher nachvollziehen, daß ich das S*****ding nun für eine neue Rolle einplane: als Darsteller in einem Handy-Porno. D.h. das Teil wird sich zu unser aller Freude vollständig entblättern!
Schnell fielen die ersten Hüllen – sofort sieht man auch, daß es sich um eine Schmutzige Episode im Blog handelt:
Nach kurzem Tanz an der Stange entblößt sich das Ding weiter und es kommt ein Lautsprecher und die Platine zum Vorschein:
Eine aufreizende Drehung um die eigene Achse, damit der Blick auf alle Teile fallen kann:
Ein wenig Unterwäsche trug es da noch, aber das sollte sich ändern ...
... bis auch die letzten Hüllen fielen:
Alles ultra mini SMD – viel zum Ausschlachten gab es da nicht, außer dem Display. Mal sehen – vielleicht kann ich damit irgendwann mal was anfangen. Schwups, ab in die Bastelkiste!
Schnell fielen die ersten Hüllen – sofort sieht man auch, daß es sich um eine Schmutzige Episode im Blog handelt:
Nach kurzem Tanz an der Stange entblößt sich das Ding weiter und es kommt ein Lautsprecher und die Platine zum Vorschein:
Eine aufreizende Drehung um die eigene Achse, damit der Blick auf alle Teile fallen kann:
Ein wenig Unterwäsche trug es da noch, aber das sollte sich ändern ...
... bis auch die letzten Hüllen fielen:
Alles ultra mini SMD – viel zum Ausschlachten gab es da nicht, außer dem Display. Mal sehen – vielleicht kann ich damit irgendwann mal was anfangen. Schwups, ab in die Bastelkiste!
Samstag, 24. März 2012
IR-Fernbedienungstester
Nachdem ich heute bei dem schönen Wetter schon fleißig mit dem Rad in der Stadt war und den Frühling genossen habe hat es sich am späteren Nachmittag etwas zugezogen und so bin ich am Basteltisch gelandet. Aus verschiedenen Gründen hatte ich in letzter Zeit ein wenig über IR-Datenübertragung recherchiert und so dachte ich mir, ich könnte eigentlich mal ganz basal damit anfangen, mir ein IR-Debugging-Tool zu besorgen/basteln.
Im großen weiten Netz fand ich auch schnell alle möglichen Hinweise und Geräte, von der bereits in einem vergangenen Blog Beitrag beobachteten IR-Sensitivität von Digitalkameras, über einfache Testgeräte (wie dieses) bis hin zu professionellen Service-Techniker Tools. Aber was ich in erster Linie spannend fand, waren super simple IR-Tester, die man einfach direkt ans Oszi stecken kann - z.B. dieses. Das war genau, was ich mir vorgestellt hatte. Knapp 5 Euro hätte ich auch noch übrig gehabt, aber verdammt, ich will jetzt damit rumspielen! Und wenn ich es mir recht überlege muß man sowas doch selber bauen können, wenn es einfach in so einen kleinen BNC-Stecker reinpasst.
Also weitere Recherche und ich konnte es kaum glauben – offenbar bestehen die Dinger aus sage und schreibe 2 Bauteilen: Einem BNC-Stecker und einer IR-Photodiode. Keine Spannungsversorgung – nix! Also das musste ich genauer wissen und habe in der Bauteilkiste gegraben. Daß ich noch BNC-Stecker zum crimpen hatte, wusste ich sicher und wie es das Schicksal so wollte hatte ich auch noch IR-Dioden :-)
Also darf ich vorstellen? Frau IR-Photodiode (Typ: SFH 205 F, aber ich denke, jede andere täte es ebenso) und Herr BNC-Stecker:
Viel zu tun gab es nicht – Beinchen der Diode auf die richtigen Längen stutzen, eines in den mini-Pin einlöten (zum Crimpen ist das Beinchen zu dünn), alles in den Stecker rein, so daß das andere Beinchen außen liegt, ein wenig Entlöt-Litze als Dickenausgleich auf die gegenüberliegende Seite, Hülse drüber, crimpen – fertig!
Und geht das Ding nun? Und wie es geht – ich hab das erstmal am analogen Oszi getestet und sofort ein Signal gesehen:
Das Signal ist garnichtmal so schwach – das Oszi ist auf 50mV/div eingestellt; die Zeitachse auf 0.5 ms/div.
Allerdings ist das so nicht das Wahre, denn man kann selbst auf dem Foto erkennen, daß hier wild getriggert wird. Ist ja auch nicht verwunderlich, denn ich habe meine Fernbedienung genommen und gehe mal davon aus, daß das Protokoll der selbigen nicht gerade ein exakt periodisches Signal sendet. Also schauen wir uns das mal mit einem single shot auf dem Rigol an:
Besser! Offenbar beginnt das Protokoll mit einem fetten Puls als Startsignal und nach kurzer Pause werden dann die Daten "durchgemorst". Es hat den Anschein, daß die folgenden Pulse in etwa gleich lang sind, aber die Pausen dazwischen nicht einheitlich sind – vermutlich wird so die Information codiert, aber zuerst noch ein paar Impressionen:
So sieht das aus, wenn man mal richtig raus-zoomt. Scheinbar wird der immer gleiche Datenblock (hier: Leiser-Taste) immer wieder ausgestrahlt. Und wenn man mal richtig ins Detail schaut sieht das so aus:
Also ist da noch ein bisschen Unruhe auf dem "high"-Signal.
Wenn man nun etwas recherchiert, erfährt man, daß die meisten Fernbedienungen den Philips RC-5 Code sprechen und selbiger verwendet die Manchester Codierung - d.h. es macht durchaus Sinn, daß die Signale bzw. Pausen von verschiedener Breite sind.
Was haben wir also gelernt?
Weil Lichteinfall in einer Photodiode Ladungsträger (Elektronen-Loch Paare) erzeugt, die dann das Wandern anfangen => Strom. Dieser erzeugt letztlich eine Spannung am Bauteil, die wir oben gesehen haben. Wieder was gelernt...
Nachtrag
Wie oben bereits erwähnt ist die einfachste Methode zur schnellen Funktionsprüfung einer IR-Fernbedienung eine Digitalkamera. Das hatten wir ja schon bei der Lichtschranke gesehen. Aber weil's einfach so schön aussieht hier noch zwei Bilder:
Nachnachtrag
Oben habe ich faulerweise sofort zum DSO gewechselt, aber natürlich hätte ich mir auch erstmal mehr Mühe geben können, das Signal mit dem analogen Oszi vernünftig darzustellen. Und das geht natürlich: Der Trick heißt "hold off" – d.h. das Oszi wartet nach jedem dargestellten Signal erstmal eine Weile, bevor der Trigger wieder freigegeben wird. Und da unser Signal aus Blöcken besteht, zwischen denen immer eine längere Pause liegt, können wir so ein stabiles Signal bekommen. Dazu muß der hold-off lang genug sein, um im selben Block kein neues Trigger Ereignis zu gestatten, aber kurz genug, um rechtzeitig vor dem folgenden Block wieder scharf zu sein. Etwas herumspielen ergab, daß mein Hameg gerade so in der Lage ist das hinzukriegen – wenn der hold off auf Maximal steht:
Im großen weiten Netz fand ich auch schnell alle möglichen Hinweise und Geräte, von der bereits in einem vergangenen Blog Beitrag beobachteten IR-Sensitivität von Digitalkameras, über einfache Testgeräte (wie dieses) bis hin zu professionellen Service-Techniker Tools. Aber was ich in erster Linie spannend fand, waren super simple IR-Tester, die man einfach direkt ans Oszi stecken kann - z.B. dieses. Das war genau, was ich mir vorgestellt hatte. Knapp 5 Euro hätte ich auch noch übrig gehabt, aber verdammt, ich will jetzt damit rumspielen! Und wenn ich es mir recht überlege muß man sowas doch selber bauen können, wenn es einfach in so einen kleinen BNC-Stecker reinpasst.
Also weitere Recherche und ich konnte es kaum glauben – offenbar bestehen die Dinger aus sage und schreibe 2 Bauteilen: Einem BNC-Stecker und einer IR-Photodiode. Keine Spannungsversorgung – nix! Also das musste ich genauer wissen und habe in der Bauteilkiste gegraben. Daß ich noch BNC-Stecker zum crimpen hatte, wusste ich sicher und wie es das Schicksal so wollte hatte ich auch noch IR-Dioden :-)
Also darf ich vorstellen? Frau IR-Photodiode (Typ: SFH 205 F, aber ich denke, jede andere täte es ebenso) und Herr BNC-Stecker:
Viel zu tun gab es nicht – Beinchen der Diode auf die richtigen Längen stutzen, eines in den mini-Pin einlöten (zum Crimpen ist das Beinchen zu dünn), alles in den Stecker rein, so daß das andere Beinchen außen liegt, ein wenig Entlöt-Litze als Dickenausgleich auf die gegenüberliegende Seite, Hülse drüber, crimpen – fertig!
Allerdings ist das so nicht das Wahre, denn man kann selbst auf dem Foto erkennen, daß hier wild getriggert wird. Ist ja auch nicht verwunderlich, denn ich habe meine Fernbedienung genommen und gehe mal davon aus, daß das Protokoll der selbigen nicht gerade ein exakt periodisches Signal sendet. Also schauen wir uns das mal mit einem single shot auf dem Rigol an:
Wenn man nun etwas recherchiert, erfährt man, daß die meisten Fernbedienungen den Philips RC-5 Code sprechen und selbiger verwendet die Manchester Codierung - d.h. es macht durchaus Sinn, daß die Signale bzw. Pausen von verschiedener Breite sind.
Was haben wir also gelernt?
- IR-Tester sind extrem simpel!
- Meine Fernbedienung funktioniert.
Weil Lichteinfall in einer Photodiode Ladungsträger (Elektronen-Loch Paare) erzeugt, die dann das Wandern anfangen => Strom. Dieser erzeugt letztlich eine Spannung am Bauteil, die wir oben gesehen haben. Wieder was gelernt...
Nachtrag
Wie oben bereits erwähnt ist die einfachste Methode zur schnellen Funktionsprüfung einer IR-Fernbedienung eine Digitalkamera. Das hatten wir ja schon bei der Lichtschranke gesehen. Aber weil's einfach so schön aussieht hier noch zwei Bilder:
Nachnachtrag
Oben habe ich faulerweise sofort zum DSO gewechselt, aber natürlich hätte ich mir auch erstmal mehr Mühe geben können, das Signal mit dem analogen Oszi vernünftig darzustellen. Und das geht natürlich: Der Trick heißt "hold off" – d.h. das Oszi wartet nach jedem dargestellten Signal erstmal eine Weile, bevor der Trigger wieder freigegeben wird. Und da unser Signal aus Blöcken besteht, zwischen denen immer eine längere Pause liegt, können wir so ein stabiles Signal bekommen. Dazu muß der hold-off lang genug sein, um im selben Block kein neues Trigger Ereignis zu gestatten, aber kurz genug, um rechtzeitig vor dem folgenden Block wieder scharf zu sein. Etwas herumspielen ergab, daß mein Hameg gerade so in der Lage ist das hinzukriegen – wenn der hold off auf Maximal steht:
Abonnieren
Posts (Atom)