MCA25
Jochen und stesie begannen am 25. Juli 2009 (Bastelabend) für Unterstützung der Handykamera MCA25 in Ethersex zu sorgen. Zunächst wurde die Kamera zerlegt und geminsam inspiziert. Jochen machte sich dann an die Hardware, stesie an die Modifikation der Software.
Es gibt ein GPLv2+ Projekt, von dem bestehender Code übernommen wurde. Dieses findet sich unter http://avr.auctionant.de/avr-ip-webcam/index.html. Insbesondere ist dort die Anbindung der Kamera beschrieben. Damit hört's dann aber auch fast schon auf, da die Kameras wohl alle gewisse Eigenheiten haben, was ihre Ausgabe anbelangt und der Code sehr genaue Vorstellungen hat, was er hören will und was nicht :-( Zudem blockiert der Code häufig, was bei dem anderen Projekt vielleicht noch akzeptabel sein mag, für Ethersex aber nicht in Frage kommt.
Das Wichtigste in Kürze: die Kamera spricht zunächst mit 9600 baud; die eigentlichen Bilddaten werden mit 460kbaud übertragen, es ist also (wie bei der dc3840 camera auch) ein spezieller Quarz erforderlich (14,7456 MHz). Solange der 9600 baud Modus aktiv ist, werden ganz normal AT-Befehle über die Leitung geschickt. Diese dienen dann dazu einen Multiplexer-Modus zu initialisieren, der dann zwangsweise mit 460kbaud läuft.
Ein Datenstrom wird dabei grundsätzlich in Häppchen zerlegt:
frame header
,--------------------,
F983EF 3F A00096C30000008B49008E3C63616D6572612D696E666F2076657273696F6E EDF9
^^ ^
frame type data start
^^^^
packet length (msb first)
F983EF 3F 3D22312E30222053572D76657273696F6E3D22523141204358433132353439 EDF9
F983EF 3F 36223E3C6D656D6F727920667265653D223539312220667265652D696D6167 EDF9
F983EF 3F 65733D223130222073746F7265642D696D616765733D2230222066756E2D6C EDF9
F983EF 35 617965723D223130222F3E3C2F63616D6572612D696E666F3E 0000F9
^
data start
^^ segment length: n = (c-1)/2
Inzwischen funktioniert das Ganze so halbwegs. Hier zum einen das erste Bild überhaupt (leicht zu erkennen daran, dass ich die Kamera erstmal falsch herum gehalten habe) und dann ein's bißchen weiter in die "Ferne". Allerdings alles bei künstlicher Beleuchtung -- nachts um halb drei war nichts besseres greifbar (:mrgreen:). Die Streifen kommen wohl durch die übertragung, war nur ein eilig zusammengehackter UDP-Cast vom Ethersex zum Rechner ...
Die Kamera unterstützt auch das Einfügen sog. Fun-Layer. Wo da der tiefere Sinn liegt, ist mir zwar unklar, aber naja. Was ich noch viel weniger begreifen kann, warum machen sowas die Kameras und nicht die Handys?
Kamera verdrahten
Wir haben die Verdrahtung so gelöst, dass wir auf der Rückseite einen 2x5 Header untergebracht haben und von dort mit Fädeldraht in die Kamera hinein kontaktiert haben.
Die Anschlussleiste:
10 11
+--+ +--+ +--+ | +--+
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
+--+ +--+ +--+ +--+
1 2 3 4 5 6 7 8 9 | |
| +----|<|--|<|-- Vcc 5V
T R | --- 2x 1N4148 (o.ä.)
X X +-- Reset
- Den TX-Pin der Kamera (4) auf Usart-RX vom Controller, Pin 5 entsprechend auf Usart-TX
- Der Reset-Pin kann am Controller nach belieben gewählt werden
- Die Kamera will so 3,6 bis 4,2 Volt haben. Also einfach von 5 V weg über zwei Dioden auf den Pin 11.
- Pin 9 ist bei manchen Kameras nicht bestückt, also nicht wundern, wenn der fehlt (:mrgreen:)
Anschluss am Etherrape
Das Etherrape von fd0 hat einen WEBCAM-Anschluss, der für ebendiese Kamera gedacht ist. Die Kamera hängt dann am ersten USART des ATmega644 (der nur eines hat, Debugging wird dann also schwierig). Außerdem muss der Quarz getauscht werden. An dem 14,7456 MHz Quarz führt kein Weg vorbei ;-)
Alternativ kann man nicht nur den Quarz tauschen, sondern auch gleich den Controller. Der ATmega644p hat ein zweites USART, das auf PORTD rausgeführt ist. Man nehme also PORTD und für den Reset-Pin PD4.
