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:

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

at+cnmi=1,1,0,0,1
OK

Im Gegensatz zum Handy beherrscht dieses Modul den SMS-Text Modus, was ein echter Segen ist. Also schalten wir diesen nun ein:

at+cmgf=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:

+CMTI: "SM",1
at+cmgr=1
+CMGR: "REC UNREAD","+49151123456789",,"12/03/31,17:18:07+08"
Hello world.

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...

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:

at+cclk?
+CCLK: "00/01/01,00:39:13"

OK

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^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

Und der folgende Befehl liefert mehr Info über die aktuell genutzte Zelle, als ich je haben wollte:

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

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, ...

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.

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!

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?

1. IR-Tester sind extrem simpel!
2. Meine Fernbedienung funktioniert.

Und wieso geht das ohne Spannungsversorgung?

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:

Coole Online Schaltungssimulation: Circuitlab.com

Hi. Kurz zur Info: es gibt neuerdings eine coole Schaltungssimulation online: circuitlab.com.

Tutorialfilmchen ansehen und loslegen. Funktioniert echt gut (akueller Firefox oder Chromeist nötig, mit anderen Browsen bin ich nicht zum Ziel gekommen. Dürfte ein Spice-Klon dahint liegen. Bedienung ist aber echt viel besser und einfacher als bei einem klassischen Spice.

Dann viel Spass beim Simulieren.

Panelmeter Teil #2: Opamp Magic

Prolog

Und nun der zweite Teil des Panelmeter-Projektes. Das Problem war ja, dass das Meter seine eigene Versorgungsspannung nicht messen kann und auch in Schaltungen, wo die zu messende Spannung einen gemeinsamen Bezugspunkt mit der Versorgungsspannung hat. Berichte denenzufolge sich das Panelmeter in Rauch auflöst, wenn man es versucht, halte ich für übertrieben ;-). Ich konnte (bis jetzt) das Ding nicht kaputt kriegen...

Jetzt stellt sich die Frage: warum ist das eigentlich so? Ich habe also ein bißchen im Internet recherchiert und auch ein paar eigeneMessungen gemacht, und der Grund ist folgender: die Eingänge des Panelmeters (IN und COM) liegen +2.9V bzw. +5.8V (beachte: ohne, dass eine zu messende Spannung angelegt ist) über dem Beszugspunkt der Spannungsversorgung GND. Es ist also eine Skalierung und Verschiebung der Spannungsniveaus nötig, wenn man in einer "common ground"-Konfiguration arbeiten möchte.

Ich habe insgesamt drei verschiedene Lösungen für dieses Problem gefunden. Ich stelle heute die erste der drei vor, die mit Operationsverstärkern arbeitet. Ich glaube, mittlerweile verstehe ich sie einigermaßen und ich werde mein Bestes tun, um sie zu erklären. Bin für euren Input und Korrekturen sehr dankbar.

Die erste Lösung: bloß keine Differenzen...

Das ist also die geheimnisvolle Schaltung, die mir zu anfangs aufgrund meiner noch wachsenden Elektronikerfahrung (bin bei Winfield/Hill erst im Kapitel 2) großes Kopfzerbrechen bereitet hat. Aber na gut, ich versuch mal zu erklären was ungefähr passiert (zumindest was ich glaube, dass passiert). Um es vorwegzunehmen: die Schaltung scheint zu funktionieren, wobei noch zusätzliche Maßnahmen nötig sind...

Also los gehts: links kommt die Versorgungsspannung (z.B. von der Batterie) rein. Dann geht das ganze in einen Differenzverstärker (grauer Kasten), wobei aber der COM-Level am Panelmeter sozusagen als "virtuelle Masse" reinspielt. Weiters wird der COM-Level über einen Opamp-Puffer (Spannungsfolger) eingespeist, sodass es keine Rückwirkung gibt. Die beiden Kapazitäten sind glaub ich nur dazu da, um Schwingneigung des Opamps zu unterdrücken.

Ok, also hab ichs aufgebaut und gemesse, was es macht.Ich bekomme am Ausgang des Opamps +8V und an IN ca. +6.4V, also eine Differenz zwischen IN und COM von 0.695V. Hmmm. Die Schaltung macht also eine Skalierung und Levelshifting, aber noch nicht so ganz korrekt von den Werten her.Irgendwie scheint die Ausgangsspannung schon proportial zur Versorgungsspannung zu sein, aber auf jeden Fall eine Größenordnung zu groß für den 200mV Inputrange des Meters. Kleiner Trost: hab die Schaltung mit iCircuit simuliert und komme auf die gleichen Ergebnisse.

Ich hab mal die Ausgangsspannung am Meter gemessen, wenn ich die Eingangsspannung zwischen 8V und 12V variiere. Leider tut sich kaum was. Nur die letzte Stelle ändert sich leicht von 0.695V bei 8V auf 0.692V bei 12V. Mist.

Ich vermute, dass im Schaltplan ein Fehler vorliegt, und statt der 33k nur 3.3k Widerstände rein müssen (um den Faktor 10 wegzukriegen). Wenn ich das mit iCircuit ausprobiere bekomme ich folgendes:

Vs =   8.0V --> IN/COM = 0.08V
Vs =   8.5V --> IN/COM = 0.085V
Vs =   9.0V --> IN/COM = 0.09V
Vs = 12.0V --> IN/COM = 0.12V

Das sieht ja schon ganz gut aus. Die Ausgangsspannung ändert sich exakt um einen Faktor 100 kleiner im Zielrange des Meters. Perfekt. Gleich mal in der echten Schaltung ausprobieren.

Oje... in der Theroie alles super, aber einmal mehr zeigt sich, dass sich ein realer Opamp anders verhält als ein idealer... In der echten Schaltung erhalte ich nur 0.4mV - es tut sich also gar nichts am Ausgang. Na dann lass ich es jetzt mal und versuche was anderes. Vielleicht kann ich ja später nochmal was debuggen.

Handy und eingehende SMS

In der letzten Folge hatte ich mich am Kopf gekratzt, ob und ggf. wie ich denn mitbekommen soll, wenn eine SMS eingeht, da das Handy sich per Datenkabel nicht dazu geäußert hat. Zunächst dachte ich an einen dreckigen Hack: bei eingehenden Nachrichten piepst das Handy kurz und das Display Licht geht an. Also hätte ich mich ggf. an den Lautsprecher anklemmen können oder das Displaylicht mit einem Fototransistor beobachten. Alles sehr dirty! Also habe ich weiter die Doku der AT-Kommandos gelesen und siehe da – es gibt eine Lösung: der Befehl AT+CNMI=x,x,x,x,x regelt, wie sich das Handy bei eingehenden Nachrichten verhält. Mit etwas Ausprobieren und Lektüre der Doku ist es mir schließlich gelungen, eine Benachrichtigung am Terminal zu kriegen:
Kurze Führung:

• zunächst nur höflicher Smalltalk (AT)
• Dann Einstellen des mode Teils auf 1, d.h. Meldung über die Datenschnittstelle, falls diese nicht gerade belegt ist. (at+cnmi=1,1,0,1)
• Nochmal Smalltalk
• Dann habe ich eine SMS geschickt und wurde durch die Rückmeldung +CMTI: "SM",2 über deren Eingang in Kenntnis gesetzt :-)
• Diese habe ich dann, wie beim letzten Mal gezeigt abgerufen
• Und das gleiche Spiel nochmal

So – das sieht also ganz gut aus. Das Einzige, was immer noch rumzickt ist das Handy selbst: Trotz diverser Experimente mit verschiedenen Spannungen und diversen Beschaltungen des mittleren Pins schaltet es sich nicht zuverlässig ein, meckert unvorhersehbar über leeren Akku und schaltet sich manchmal schlagartig ab, wenn einen SMS eingeht. Grumpf!
Einige Recherche im Netz hat mich nun auf eine neue Idee gebracht: Angeblich können diese Handies kurzfristig einen Haufen Strom Konsumieren, wenn die Funke aktiv wird – von 1 oder gar 2A war die Rede. Das kann die Versorgungsspannung bei dünnen Kabeln und Aufbau auf dem Breadboard möglicherweise kurz überfordern, Zudem hatte ich die Strombegrenzung meines Labornetzteils natürlich nicht gerade in den Ampere-Bereich gelegt - eher so 300mA. Sobald da mal kein dickes Labornetzteil mehr dranhängt, sondern ein chinesisches Steckernetzteil wird es aber eh nicht mehr Saft geben, daher habe ich nun einen 2200µF Elko parallel geschaltet. Der sollte die Stromspitzen abpuffern können. Auf den ersten Blick scheint es geholfen zu haben, aber ich werde das mal weiter beobachten – dachte schließlich schon öfter ich hätte das endgültig gelöst...

...und jetzt?

Also schön, was bleibt denn jetzt übrig, wenn wir über die letzten Analysen schauen?

1. Es ist nicht so einfach mit Li-Akkus. Nicht Tiefentladen, nicht überladen, beim Laden auf das Balancing achten...
2. Was fertiges zu kaufen, sprich Ladegerät, Entladeschutz und Balancer ist teuer und passt oft nicht für die Applikation.
3. Auf dem Markt gibt es keine fertigen Chips zu kaufen (oder nur sehr schwer), mit denen sich unkompliziert Controller aufbauen lassen.
4. Li-Akkus sind aber nicht ohne Charme. Lineare Leistungsabgabe, viel Kapazität auf wenig Bauraum, Kubische Bauweise (LiPo), unkompliziert zu handhaben (wenn die Controller-Elektronik tut).

Es bleiben also zwei Optionen, wenn man Li-Akkus einsetzen will:

• fertige Elektronik ausschlachten, oder
• selber was entwickeln

Ich hab mich die letzten Tage und Nächte gequält mir das Gehirn zermartert, des Königs Krone mit in den Badezuber genommen - und mit Mieze gespielt. Heureka.
Wie ein Selbstbau-Konzept aussehen könnte, hier die paar Kästchen als Ergebnis:

Der Akku-Controller würde am Akku bleiben, und den Spannungsverlauf des Entladevorgangs überwachen. Eine Strommessung macht weniger Sinn, da sie mit einem zusätzlichem OP und einem Shunt nicht im Verhältnis zum Nutzen steht. Statt dessen könnte man einen Schaltregler realisieren, um z.B. neben der ungefilterten Ausgangsspannung 5V oder 3.3V für die Elektronik bereit zu stellen.

Der Lade-Controller müsste ein MMI beinhalten, also Tasten und/oder Drehencoder mit Display. Ebenfalls müsste über diesen Weg der EEPROM in der Akku-Elektronik zu programmieren sein.
Schließt man den Akku an das Ladegerät an, übermittelt er diese gespeicherten Daten, und stellt die zum Laden notwendigen Parameter ein, wie max. Ladestrom, Schlußspannung, usw.
In der Lade-Elektronik wäre auch die Balancer-Logik drin.

Bin ich auf das Balancing überhaupt eingegangen? Ein Nachtrag:

Balancing - der Akku auf dem Drahtseil

Im Akku-Paket sind die Kapazitäten der Zellen nicht alle gleich, was an Toleranzen in der Fertigung, oder unterschiedlicher Alterung liegt. Durch mehrere Lade- / Entladezyklen verliert der Pack erheblich an Leistung (Cell Balancing - Carlos Martinez, Seite zwei). Zellen mit weniger Selbstentladung sind schneller voll, jene mit höherer schneller leer. Dadurch entsteht ein Ungleichgewicht des Ladezustandes (State of Charge - SoC) der Einzelnen Zellen und der Akku-Pack kann weder voll geladen, noch ganz entladen werden.

Es gibt eine ganze Reihe von Methoden, den SoC der Zellen auszugleichen (Continous Cell Balancing / Li-Ion Charge Balancing and Cell Voltage Monitoring). Die Modellbau-Liga hängt bevorzugt einfach beim Laden einen Leistungs-Transistor an jede Zelle und schaltet diesen bei Erreichen von U_max durch (vgl. http://www.aero-hg.de/lipobal.html / http://www.kc-world.de/LiPo-Balancer.htm).
Ich halte diese Methode für recht brutal, da u.U. bei hohen Strömen wieder Energie aus dem Akku genommen wird. Besser ist es den Strom zu begrenzen, also nur einen Teil des Ladestroms umzuleiten, dafür jedoch schon recht früh mit dem Balancing zu beginnen.

So. Wat nu? Bauen oder schlachten? Ebay oder Reichelt? Ich brauch erst mal ein paar Tage Luft. Was will ich mit dem Akku eigentlich? Die Sache mit dem Geo-Caching hat sich ja erledigt. Sohnemann verweigert.

Roboter bauen? Da hab ich doch von meinen Kollegen ein paar Sensoren und einen Arduino bekommen (danke nochmal - Ihr seit echt verrückt!)...
Staubsauger, Rasenmäher, Fensterputzer, Katzenschreck? Jetzt wird's matschig, wie Golo der Gartenzwerg immer sagte.