1. Man nehme eine stinknormale Sim-Karte
2. Man stecke sie in sein GM862
3. Man kombinert das Ganze mit dem entsprechenden Shield und einem Arduino
4. Man lasse sein Testprogramm so lange die richtige PIN an der falschen Stelle der Bootreihenfolge absenden, bis die PIN 3x falsch eingegeben ist bzw. anstelle der PIN falsche Daten übertragen worden sind
5. Man wiederhole dies noch mindestens zehn weitere Male, bis dann auch die SuperPIN / PUK entsprechend oft falsch eingegeben wurde
6. Herzlichen Glückwunsch: Sie haben Ihre erste SIM komplett geschrottet.

Ich bin gespannt, was mein Provider dazu sagen wird…

Zufällig habe ich dann etwas Spanisches gefunden, noch dazu unheimlich günstig (im Gegensatz zum CameraAxe, der inzwischen ganz schön im Preis zugelegt hat – $95 als Selbstbaukit):

Der Photoduino.

Kostenpunkt: 10 € für den PCB und 4 € für den Versand innerhalb der EU.

Zugegeben, mein Vorteil ist, dass sich im Laufe des vergangenen Jahres einiges an elektronischem Kleinkram angesammelt hat, so dass ich im wesentlichen außer der Platine nichts benötige.

Aktueller Stand:

• Die Platine ist verlötet, das Display angeschlossen, ein Gehäuse gefunden.
• Fünf Ein-/Ausgänge am Gehäuse angebracht, ebenso die beiden Menü-Taster
• Festgestellt, dass runde Löcher in Plastikgehäuse bohren gerade noch machbar ist, diese aber freihändig in eine Flucht zu bringen genauso unmöglich ist wie mit einer Dremel-Schleifscheiben-Kombination gerade Schnitte zu erstellen
• Bemerkt, dass min. zwei bis drei geeignete Klinkenbuchsen fehlen
• Entdeckt, dass das Gehäuse doch schon ziemlich gefüllt ist – auch ohne die fehlenden Klinkenbuchsen und den fehlenden 9V-Block
• Das Gehäuse für zu klein befunden.

Welches Projekt genau ich damit umsetzen werde, steht jedoch noch in den Sternen… Aber “Sensordaten visualisieren mit dem Arduino Ethernet Shield und Google Chart Tools API” wär da ja schon mal ein Anfang…

Das ich zunächst das falsche Shield bekommen habe, nämlich ein Relay-Shield, hatte jedoch definitiv nichts mit der Sprachbarriere zu tun, wenngleich dieses Missgeschick durchaus das ein oder andere Vorurteil geschürt haben könnte ^^

Und wenn ich jetzt eh schon völlig vom eigentlichen Thema abdrifte: zum einen war ich positiv überrascht von der Geschwindigkeit, mit der FedEx über den großen Teich hinweg ausliefert, zum anderen war ich ebenfalls positiv davon überrascht, dass FedEx direkt das ganze Zollgedöns abhandelt – weniger positiv überrascht hingegen war ich davon, dass sich FedEx diesen Service (ohne mein Wissen) pauschal mit 10 € vergüten lässt, was vor allem bei Fehllieferungen (s.o.) eher weniger prickelnd ist…

Dennoch ist dann irgendwann das richtige Shield in meinen Händen und auf dem Arduino gelandet. Die ersten Tests jedoch wollten so gar nicht funktionieren, obwohl das andere bereits erfolgreich hinbekommen hatten. Ziemlich frustriert habe ich das Shield dann auch erstmal wieder in meinem Regal verstaubt – bis ich heute des Rätsels Lösung gefunden habe:

Das Telit GM862 Modul benötigt zum herstellen einer Verbindung ins GSM-Netz satte 2A Anlaufstrom – die der Arduino alleine nicht packt. Hilfsweise mit einem 9V-Block unterstützt funktionierte das einwählen und Test-SMS-an-mich-selber-schicken dann auf Anhieb!

Somit kann es dann beizeiten weiter gehen mit dem testen und basteln und rumprobieren und sich durch magere spanische Bedienungsanleitungen quälen…

Ideen entwickeln sich. So wurde aus der VespaCam™ mittlerweile das ArduMoped™. Und auch wenn es noch nicht ansatzweise zusammengestellt ist, scheint es bis dato zumindest technisch funktionieren zu können. Oder wenigstens kann ich (noch) behaupten, dass ein Arduino genügend Pins hat, um meine Ideen umzusetzen. Ob dann im Endeffekt auch noch ein lauffähiges Programm entsteht, das wird wie immer die Zukunft zeigen. Aber der Wille ist da, und zwar für folgende Funktionen:

• Serial-LCD / S65 / DOGM
• Tachometer
• Drehzahlmesser
• iPod-Steuerung
• Drehencoder
• FlyCamOne³-Steuerung
• Joypad
• ADXL345
• Power Failure Detection
• MAX 691

Einzeln habe ich alles bereits lauffähig gehabt, soweit kann ich mich schon einmal aus dem Fenster lehnen. Nur die Zusammenfassung aller Teilaspekte, sowohl hardware- als auch softwareseitig, die steht noch aus…

Neue / zusätzliche Probleme

Über eine Sache hatte ich mir zunächst nicht genügend Gedanken gemacht: das Speichern der Gesamt- (und evtl. Tages-) Kilometer im Eeprom. Ursprünglich dachte ich mir, dass ich die Werte mit jeder Sekunde, in der ich ohnehin das Tachosignal auswerte, berechnen und direkt speichern würde. Der kleine Schönheitsfehler: das Eeprom hat nur eine begrenzte Lebensdauer von 100.000 Schreibzyklen. Genauere Angaben, ob das ändern eines einzelnen Bytes bereits ein kompletter Schreibzyklus ist oder nicht, konnte ich bis dato nicht finden. Das ist bei der Überlegung aber auch nicht so relevant, denn auch wenn ich ewig brauche, um 100.000km mit dem Roller zu fahren, so möchte ich doch eine Eeprom-schonendere Variante wählen. Die Lösung klingt zunächst simpel: Power Failure Detection.

Prinzipiell ist es möglich, den Arduino prüfen zu lassen, ob genügend Spannung ansteht respektive wenn keine Spannung mehr ansteht, einen Interrupt auszulösen und das System für einige (ausreichende) Milisekunden über einen Kondensator zu betreiben. Soweit die Theorie.

In der Praxis stellen sich mir allerdings noch einige Steine in den Weg: ich habe beide externen Interrupts bereits mit Tacho- und Drehzahlsignal belegt (aber der Arduino kann jeden Pin als zusätzlichen externen Interrupt nutzen, also ein vermutlich lösbares Problem) und ich habe erstmal noch keinen blassen Schimmer, wie genau ich die Stromausfallsicherung in irgendeiner Form realisieren soll.

Anderes Display

Während die Funktionialität mittels 16×2-LCD bereits gegeben ist, habe ich mich mittlerweile dazu entschlossen, stattdessen ein S65-Display zu nutzen. Das ist kleiner, hochauflösender und irgendwie schicker. Auch hier werde ich wieder einige Probleme mit dem Anschluss und dem Ansprechen haben, aber noch bin ich guter Dinge, auch diese Problemchen zu lösen. Erstmal muss es hier ankommen…

]]> http://markus.jabs.name/2010/06/ardumoped/feed/ 0 http://markus.jabs.name/2010/04/vespacam/ http://markus.jabs.name/2010/04/vespacam/#comments Tue, 20 Apr 2010 07:04:08 +0000 mistake http://markus.jabs.name/?p=2217

FlyCamOne³, inkl. Pan-Tilt-Mechanik

Dann war da noch die fixe Idee, eine neigungskorrigierende Onboard-Kamera für meinen Roller zu bauen. Inspiriert von einigen Videos der letzjährigen Velvet & Silk Scooter Cruise, für deren Aufnahme der Sozia wohl eine Kamera rückwärts an den Helm montiert wurde, fiel mir ein, dass ich in irgendeinem Onlineshop vor einiger Zeit die FlyCamOne³ entdeckt hatte. In Kombination mit einem Arduino / Atmega, einem Servo und einem Nunchuk müsste es doch eigentlich relativ leicht machbar sein, eine VespaCam™ zu bauen, die auch bei Schräglage noch horizontale Aufnahmen macht.

Der weitere interessante Aspekt: die FlyCamOne³ hat serienmäßig einen Pan/Tilt-Mechanismus, der (vermutlich) wie jedes andere Servo gesteuert wird – und das schreit doch förmlich nach PWM mit Arduino…

Prototyp

Für meinen Prototypen benutze ich erstmal eines meiner Nunchuks, denn das hat ja bekanntlich sowohl einen Lagesensor als auch einen Joystick integriert – beides benötige ich für meine VespaCam™: Den Lagesensor, um über das erste Servo die Kamera in der Waagerechten zu halten, den Joystick, um den Tilt/Shift-Mechanismus bedienen zu können.

Zwischenüberlegung: Wenn ich so eine Kamera an einem Gelenk aufhänge, baumelt sie doch normalerweise immer senkrecht: warum genau brauche ich dann das Servo?

Mittlerweile sind auch ein paar Teilchen hier aufgetaucht: ein ADXL345-Breakoutboard von Sparkfun und ein Arduino-Pro Mini, ebenfalls von Sparkfun entworfen, gekauft bei Watterott. Allerdings scheint die Verbindung respektive die Kommunikation zwischen beiden Teilen nicht ganz so trivial zu sein wie ich es mir vorgestellt habe. Erste Anlaufpunkte hierfür: Arduino / Wire-Library für I²C und HarleyHacking, und möglicherweise der Sparkfun-Example-Code (zip). Achja, und vor allem wohl Live Fast – Code Young

Quellen:

• FlyCamOne³
• “WiiChuck” Wii Nunchuck Adapter Available
• Boarduino, Wii Nunchucks, and Servos
• How to: Arduino and Nintendo Nunchuck for pan and tilt camera interface
• Read wii nunchuck data into arduino
• manage two servos using a joystick

Da es mir allerdings zu langweilig erscheint, nun einfach das Gerät zu kaufen, nehme ich es zum Teil als Basis für die Umsetzung meiner Ideen respektive suche noch nach Verbesserungen. Eine dieser Verbesserungen (hoffentlich wird es auch eine…) ist es, die im Camera Axe 3.0 für Taster verwendeten digitalen Pins des Arduino ATmegas auf ein Minimum zu reduzieren, um sie (gleichfalls eine Verbesserung?!) stattdessen als Stromgeber für (dann zusätzlich vorhandene) Sensoren zu nutzen.

Um das Ganze umzusetzen ist es notwendig, mehrere (bis dato 5) Taster über einen einzelnen Analog-Pin abzufragen. Das ist wesentlich einfacher möglich als ich dachte: man verwendet einfach einen Spannungsteiler, an dessen einzelnen Anschlüssen jeweils ein Taster sitzt. Wird nun ein Taster betätigt, wird eine dem Spannungsteiler entsprechend reduzierte Spannung an den analogen Pin ausgegeben, dessen Wert nun abgefragt werden kann.

Die einzigen Probleme, die hierbei auftauchen (könnten):

1. Werden mehrere Taster gleichzeitig betätigt, entsteht ein Spannungswert, der entweder zwischen den Abgefragten oder aber auch möglicherweise gleich einem Wert eines einzelnen Tasters liegt. Workaround: entweder diese Zwischenwerte mit abfragen und auswerten, oder einfach davon ausgehen, dass derjenige, der sich das Gerät zusammen gebaut hat, weiß, dass dieses “Problem” existiert. Alternativ sollte es auch möglich sein, nicht wie ich gleiche, sondern unterschiedliche Widerstände zu verwenden.
2. Laut dem Erbauer des Camera Axe 3.0, Maurice Ribble, (ich sprach ihn in seinem Forum auf meine Vorschläge hin an) seien die Werte am Analogpin nicht so schnell auszulesen wie an einem Digitalpin, dies könne zu Problemen in zeitnahen Programmschleifen führen. Bis jetzt gehe ich allerdings davon aus, dass die verwendeten Taster eh nur zur Bedienung des Menüs gedacht sind – und dies nicht sonderlich zeitkritisch sein dürfte.
3. Ferner bemerkte er, dass sowohl eine Kalibrierung innerhalb des Programms nötig sein könnte (was ich insofern bestätigen kann, als dass unterschiedliche Widerstände auch unterschiedliche Werte am Analogpin bewirken) und dass diese Werte möglicherweise auch noch temperaturabhängig sein könnten. (Auch das wird sich noch zeigen…)

Unterm Strich ist die Erfindung des Spannungsteilers am Analogpin keinesfalls neu. Aber sie ist praktisch. Meine Tests habe ich primär aus dem Arduino-Forum, weshalb ich hier auch kein eigenes Sketch veröffentliche. Das einzige, was ich am Demo-Sketch geändert hatte waren die Abfragewerte, die über den Serial-Monitor abzulesen sind.

Allerdings gebe ich hier noch meine Variante als Fritzing-Darstellung preis. (Der zusätzliche Widerstand am Anfang beruhte auf der Tatsache, dass ich für den ersten Taster keine eigenständigen Wert auslesen konnte und zu faul war, dem Problem jetzt schon näher auf den Grund zu gehen.)

Quelle:

Wer sich mit einem Arduino beschäftigt, der wird sich über kurz oder lang auch fragen, was es denn überhaupt für ein Chip ist, der auf diesem kleinen Ding rumwerkelt. Und er wird dann erstaunt feststellen, dass es diesen Chip in unzähligen, zum Teil noch wesentlich kleineren, Varianten gibt.

Wer dazu dann noch mehr wissen möchte, dem seien als Erstes die folgenden Seiten ans Herz gelegt:

• Wikipedia
• AVR Freaks
• Evil Mad Scientist

Günstige ISPs findet man übrigens, sofern man in irgendeiner Form Student ist, bei ATMEL’s Hochschulen Programm als Teil des Embedded Projects Shop. Dort ist zum Beispiel der AVRISP mk II für 50% des üblichen Ladenpreises zu kaufen.