Äußerst genial, Uli!

Ist es möglich die Kamera bei weniger als den 921600 Baud laufen zu
lassen? Beispielsweise bei ganz schnarchlangsamen 9600 Baud? Bei dieser
anderen Handy-Cam ging das ja.

Hintergrund ist, dass mein Miniwebserver nur mit 12,5 MHz läuft (25MHz
des ENC28J60/2).

Und die Geschwindigkeit wäre in dem Falle eigentlich egal.

Hi Uli!

Feine Sache! Wird es auch noch einen Code für den Mega32 mit den Quarzen
der Webserver-Schaltung geben oder schafft der das nicht?

Frohe Weihnachten,
Bernd

Hallo,

Der aktuelle Source Code auf meiner HP schaft es auch mit einem Mega32!
Der Testserver auf meiner HP arbeitet mit einem Mega32 und der Kamera.
Allerdings habe ich hier die kleinste Auflösung gewählt (160 x 120).

Gruß
Ulrich

Hallo Uli,

kannst Du eine ungefähre Hausnummer sagen, wie groß einzelne Bilder in
der Auflösung 160 * 120 werden?
Sind die Bilder in dieser Auflösung noch einigermassen erkennbar?

Vielen Dank, Stefan

Hallo,

Die Bilder mit einer Auflösung von 160x120 haben eine größe von 5kB.
Bilder bei 320x240 etwa 15kB und Bilder mit 640x480 etwa 30 kB. Ob ich
auf den Bildern was erkennen kann? Meine doch, Bilder auf meinem
Handydisplay sind nicht größer. Aber wer mag kann ja die Auflösung noch
etwas vergrößern 320x240 oder 640x480. Wobei sich 320x240 bei mir als
optimale Auflösung herrausstellte.

Gruß
Ulrich

Hallo,

Habe mal mit der Kamera 3 Bilder gemacht. Auflösung 160x120,320x240 und
640x480.

Gruß
Ulrich

@Ralf K.

Nein! Desweiteren ist dies nicht mein Shop sondern der von meiner Frau.

Gruß
Ulrich

;-) Bisher war jeder noch zufrieden. Der Shop ist Offtopic, hier gehts
ums Protokoll!!

Kann die Kamera eigentlich auch unkomprimierte Bilder liefern ? Diese
könnte man leichter mit einem µC weiterverarbeiten um so z.B. erst mal
eine Bewegungserkunnung zu machen, ehe das eigentliche Photo gemacht
wird ?

Hallo,

Ja die Kamera kann auch unkomprimierte Bilder liefern, mit einem
Propeller und der Kamera kam ich auf 6 Frames in der Sekunde. Das lag
aber auch nur an der langsamen Geschwindigkeit der RS232 Schnittstelle
;-)

Ulrich

Der OV528 besitzt einen 8051 µC, dessen Software im externen EEPROM
steht. Ich habe den EEPROM Inhalt mal durch einen Disassembler laufen
lassen: Teilweise macht der Coder sogar Sinn. Da ich leider (noch) keine
solche Kamera habe, kann ich nicht ausprobieren, was passiert wenn man
die Werte ändert. Dem Code nach werden einigen Werte aus dem ROM gelesen
und an irgenwelche Register geschrieben. Im EEPROM steht also
vermutliche die Grundinitialisierung.

@Benedikt K.

Hast du das Datenblatt des OV528 gefunden? Wenn noch nicht schicke mir
mal eine kurze Mail.

Gruß
Uli

Leider nicht. Das ganze steht auf der News Seite von Omnivision, die nur
noch im google Cache ist (1. Ergebnis der google Suche nach OV528):

"The OV528 can be programmed by mobile device manufacturers with
proprietary protocols to customize the interface between the camera and
the host. Protocols are the communications standards used between
electronic devices to exchange information. The OV528 has a built in
8051 micro-controller to process the program, which can be stored in an
EPROM on the camera or downloaded directly from the host."

Wenn man den Code mal ordentlich debuggt, könnte man rausfinden, welche
Werte wohin geschrieben werden (welche Bytes im EEPROM also Daten und
welche Code sind). Das würde es leichter machen, durch Ausprobieren z.B.
die Baudrate anzupassen.

Ich hätte mal eine Frage zur Software:
Wenn ich das richtig verstehe, dann antwortet die Kamera nach einem Get
Picture Befehl mit einem Ack, und danach mit dem Data Befehl, der
mitteilt wie groß das Bild ist.
Dieser muss dann mit Ack beantwortet werden, danach wird das erste
Datenpaket übertragen, das wiederrum mit Ack bestätigt werden muss.

Die Ack Meldungen der Kamera werden beim Empfangen direkt in den
cam_cmd_buffer geladen, und die Daten danach in den cam_dat_buffer.

Was mich jetzt wundert: Du sendest nirgends ein Ack zur Kamera, oder
habe ich etwas übersehen ?

Das heißt, nach dem Get Picture Befehl wird das Bild sofort komplett
gesendet ?

Danke, jetzt habe ich es verstanden:
Es wird jedesmal das komplette Bild gesendet, aber nur der gewünschte
512Byte Block wird im AVR gespeichert, die restlichen Daten werden
verworfen.

Hallo,

Ich habe die Kamera geöffnet, den Stecker abgeschnitten und die Kabel
verlängert. Eine normale Stereoklinke ist das nicht.

Gruß
Ulrich

Schraubendreher stark schräg ansetzen, und nach oben drücken.

Hallo,

Jo die Kameras waren relativ billig aber ich habe 500 Stück, für nur
hundert mache ich mir nicht die ganze Arbeit. Wenn ich die aber für 1€
abgebe, dann würde mir die irgend ein Geschäftsmann alle abkaufen und
für mehr verhökern. Ausserdem ist es mir überlassen für wieviel ich die
Kameras verkaufe. Ich will ja auch neue Projekte damit finanzieren und
Frau beruhigen oder besser bestechen ;-). Erstmal hatte ich des Risiko,
diese mussten auch entschlüsselt werden, desweiteren benötigte ich auch
halt das passende Handy, und die nötigen Gerätschaften waren auch nicht
ganz billig. Beste Beispiel ist die MCA-25 die habe ich noch für 1€
bekommen. Die bekomme ich dafür nimmer.

Unter die Linse habe ich auch schon geschaut. Allerdings kommt man an
den Sensor alleine nicht dran ist nur ein Siliziumplätchen.


Gruß
Ulrich

Eine Direktansteuerung halte ich nicht für sinnvoll. Da das auslesen des
Photoarrays zeitlich kritisch ist. Desweiteren müsste ich dann auch noch
den Speicher bereitstellen 640x480x8Bits (332). Und wer den Chip gesehen
hat wird es sein lassen ;-)

Hier zum auslöten ;-))))

Diese Seite hilft dir evt. weiter!!

http://o-d-v.nm.ru/tel_cam/

Hallo,

TX an RX und RX an TX!

Gruß
Ulrich

Hallo,

Es gibt noch ein Konfigurationsregister für die Beleuchtung das muß ich
mal noch raussuchen.

Gruß
Ulrich

Hallo,

Normal (Kommando)
FF FF FF 12 00 00 00 00

Dunkel (Kommando)
FF FF FF 12 01 00 00 00

siehe auch meine beiden Testbilder gleiche Beleuchtung!

Gruß
Uli

ohne digital Zoom
FF FF FF 18 01 00 00 00

mit 2x digital Zoom
FF FF FF 18 00 00 00 00

S/W
FF FF FF 17 01 00 00 00

Farbig
FF FF FF 17 00 00 00 00

Wo hast du die Werte her ?
Ausprobiert oder aus irgendeiner Beschreibung ?

Funktionieren eigentlich die ganzen Farbmodi (2bpp, 4bpp, 8bpp, 12bpp,
16bpp) aus der Beschreibung der C328 ?

Hallo,

Farbmodis habe ich noch nicht alle durchgetestet. Ich habe den
Datenstrom von Handy und Kamera aufgezeichnet. Und gesendete Register
(Kommandos) durchgetestet.

Gruß
Ulrich

Habe noch die Informationen zur Kamera auf meiner HP erweitert.

Heute kamen endlich meine Kameras. Erstmal bin ich erschrocken, denn die
Bilder waren alle rosa/grün. Grund: Ich hatte die Kamera nur mit 3,3V
betrieben. Mit 5V geht es besser...

Hier noch ein paar Befehle:
0x10,i,0x00,0x00,0x00    i=0..2, JPEG Kompression. 0 ist die beste, 2
die schlechteste
0x17,i,0x00,0x00,0x00    i=0..3, 0=Farbbild, 1=Graustufen, 2=blau,
3=braun

Wenn man die Bilder unkomprimiert anfordert, scheint die Kamera diese
auch JPEG zu komprimiert haben, man sieht nämlich deutlich die
Kompressionsartefakte.

Hallo,

Ja die Kameras arbeiten mit 5V haben einen kleinen Stabi! Intern
arbeiten diese aber mit 3,3V ich finde eine 5V Versorgung besser als
eine 3,3V ;-)

Gruß
Ulrich

Ich hab noch ein paar Befehle durchprobiert:
0x13 (Lichtfrequenz) wird nicht unterstützt, zumindest bekomme ich da
immer ein NAK.
0x21 und 0x22 gibt es noch, aber was diese bewirken konnte ich nicht
herausfinden.

Noch eine Info: Mit bester Qualität (JPEG Kompression auf 0) kann man
keine 640x480 JPEG Bilder machen, sondern nur 320x240.

Ich hätte da noch eine Frage, und zwar hierzu:

Ulrich Radig wrote:
> mit einem Propeller und der Kamera kam ich auf 6 Frames in der Sekunde.

Wie hast du das gemacht ?
Ich kommt mit viel Glück auf 1fps bei 160x120@8bpp. Die Kamera ist
einfach nicht schneller.
Oder verwendest du den Preview Modus ?

Ab und zu liefert die Kamera bei mir auch anstelle des Bildes bei dem
Get Picture Befehl ein NAK. Den genauen Grund habe ich noch nicht
rausgefunden, aber ich vermute es liegt an der zu kurzen Wartezeit
zwischen dem Snapshot und dem GetPicture Befehl.
Gibt es dazu irgendwelche Infos, Erfahrungswerte o.ä. wie lange man
warten muss ?

Hallo

Ich sende zur Kamera:

FF FF FF 01 01 05 19 13
FF FF FF 10 01 00 00 00
FF FF FF 12 00 00 00 00
FF FF FF 18 01 00 00 00
FF FF FF 17 00 00 00 00
FF FF FF 21 03 00 00 00
FF FF FF 08 01 00 00 00
FF FF FF 04 02 00 00 00

Bild wird ausgegeben

FF FF FF 0E 0A 01 00 00

nächste Bild wird ausgegeben

FF FF FF 0E 0A 02 00 00

nächste Bild wird ausgegeben usw.

Ich bekomme als Antwort auf den letzen Befehl (FF FF FF 04 02 00 00 00)
ein NAK.
Muss man nicht vorher erstmal einen Snapshot Befehl senden ?

Zeitweise kann es vorkommen das das FF FF FF 04 02 00 00 00 mehrmals
gesendet werden muß. So macht es auch das Philips Handy!

Das ist auch eine nette Lösung. Es geht zumindest irgendwann nach dem 5.
bis 15. Befehl.

Meine Erfahrung bisher: Wenn die Kamera ein NAK sendet, bzw. garnichts
sendet, dann habe ich zuletzt irgendwas falsches geschickt bzw.
irgendein Ack vergessen zu senden.
Wenn ich normale Bilder mache, dann sendet die Kamera (außer beim Sync)
nie ein NAK bzw. garnichts.

Noch eine letze Frage:
In welchem Format werden die Bilder im Preview Modus ausgegeben ?
Ich erhalte immer 18432Bytes, egal was ich einstelle.
Die Bilder haben eine Auflösung von 192x96, es scheint allerdings kein
8bpp Graustufenformat zu sein.

Hallo,

Ich meine die Codierung war so:

8Bit (3Bit Rot)(3Bit Grün)(2Bit Blau)

Gruß
Uli

Hallo,

Ich habe keine Probleme mit der DC-3840 an einem AVR mit 5V. Man
benötigt keine weitere externe Beschaltung. Die MCA25 benötigte eine
stabilisierte 3,3V Spannung die DC3840 hat ihren eigenen Stabi.
Allerdings wenn man sichergehen will, kann man ja am TX Pin des
Prozessors den Pegel auf 3,3 V herrabgeteilten.

Gruß
Ulrich

>Frage ist ob einer schon den 18,432 Mhz Quarz getestet hat und ob es
>funktionierte?

Das funktioniert schon rechnerisch nicht.

Interessant. Theoretisch sollte man jetzt in der Lage sein, das EEPROM
anzupassen: Die Register sind ja jetzt nun bekannt, der verwendete
Controller im OV528 ist ein 8051, die Initialisierung geschieht dadurch,
dass aus einer Tabelle im EEPROM Werte gelesen und in die OV528 Register
geschrieben werden.
Jetzt muss man nur noch die Startadresse von dieser Tabelle ermitteln
und kann dann die Register beliebig anpassen.

Die Daten in dem EEPROM sind reiner 8051 Programmcode. Die ersten
32Bytes müssen entfernt werden, danach beginnt der Code an Adresse 0.
Dass es wirklich passt, zeigt das angehängte Bild von einem
Dissassembler.

Insgesamt gibt es mehrere Tabellen, und der Befehl um Daten aus dem
Programmspeicher zu lesen wird sehr oft genutzt, was die Suche nach der
richtigen Tabelle schwer macht.
Die erste Tabelle ist 192Bytes lang, und sitzt an Adress 0x0030. Ab
0x0200 kommt der eigentlich Programmcode und vermutlich ab 0x159D kommt
dann eine weitere Tabelle, die in folgender Form aufgebaut ist:
00 00
01 80
02 80
03 60
06 60
07 00
0C 22
0D 22
11 01
usw.
Dies geht bis 0x1614
Wenn man die Werte mit den Registern vergleicht, dann passen die nicht
(die Werte ergeben in den entsprechenden Registern keinen Sinn). Danach
kommen nochmal >1kByte an Tabellendaten. Irgendwo in diesem Bereich
liegen also vermutlich die Registereinstellungen.

Das ganze zu simulieren ist sehr aufwendig, da die Software immer wieder
an irgendwelchen Abfragen hängen bleibt.

Das ist leider das Problem: Man benötigt erstmal die dumme Baudrate, um
diese umzustellen. Es wäre schön wenn man mit einer verträglicheren
anfangen könnte.

Ich habe herausgefunden, wie man die Baudrate anpasst:
Falls jemand den Code debuggen möchte (oder gar eine eigene Firmeware
schreiben), hier ein paar Infos:
Die OV528 Register sind als XRAM in den Speicherbereich des 8051
eingeblendet, und zwar im Bereich 0xFFxx.
Wie bereits gesagt, die ersten 32Bytes der EEPROM Daten wegwerfen, dann
hat man den reinen Programmcode. In diesem steht die Funktion zum
Beschreiben des Baudratenregisters an Adresse 0x0333. Diese wird genau
2x aufgerufen. Einmal wenn der Befehl 0x01 (INITIAL) gesendet wird.
Dessen erster Parameter ist die Baudrate als 2^x Teilerfaktor.
Standardmäßig ist hier 1 eingestellt, also 2^1 =  921kBaud. 4 ergibt
z.B. 115,2kBaud.
Der nächste Aufruf ist die Initialisierung mit dem Standardwert: 0x01.
Dies ergibt den Teilerfaktor 2, also 921kBaud. Hier kann man also den
Startwert einstellen. Ich habe hier 0x0F für 115200Baud hingeschrieben.
Die Adresse ist 0x0308 im Programmcode bzw. 0x0328 im EEPROM. Die Formel
zur Berechnung des Wertes lautet: (1,8432MHz / Baudrate)-1

Es gibt nur ein Problem: Ich habe keine Ahnung wie man den Wert am
besten ins EEPROM bekommt. Es gibt zwar so nette Befehle wie SAVE DATA,
aber wie man die Daten genau sendet, steht nirgends.
Also habe ich das EEPROM per Hand (also per AVR) direkt programmiert:
Die Adresse ist 0xAC und den Writecontrol Pin muss man auf Low legen, um
Daten schreiben zu können.

Super Sache :-)

Ich habe herrausgefunden die Baudrate kann über das Kommando ffffff01
geändert werden allerdings benötigt man am Anfang 921600Baud. Derzeit
versuche ich das EEPROM über ein serielles Kommando dauerhaft zu
beschreiben.

Gruß
Uli

Ja, das habe ich auch schon probiert. Der Befehl um Programmcode zu
laden wird zumindest anscheinend nicht unterstützt.
Im Moment versuche ich gerade den ffffff01 Befehl so umzuschreiben, dass
man nicht nur 2^n Teilerfaktoren, sondern beliebige Faktoren senden
kann. Die Standardbaudrate habe ich auf 19200 gestellt, das sollte
maximale Kompatibilität bieten. Erhöhen kann man ja immer noch. Momentan
habe ich nur noch das Problem, dass es irgendwo in der Software einen
Vergleich gibt: Ist der 1. Parameter beim ffffff01 Befehl >9 wird ein
NAK zurückgeliefert. Das muss ich noch entfernen. Dann lade ich hier
fertige Hex Datei hoch, die nur noch irgendwie ins EEPROM kommen muss.

Wie versprochen, hier ist die Hex Datei für das EEPROM. Geändert ist
folgendes:
- Baudrate auf 19200 eingestellt
- Parameter 1 von Befehl FFFFFF01 ist der Baudratenteiler, also
(1,8432MHz / Baudrate)-1
Die Baudrate wird übrigends erst nach dem Ack auf diesen Befehl
geändert.

gast wrote:

> Wenn ich 0xff 0xff 0xff 0x0C 0x05 0x00 0x10 0x00 hinschicke bekomme ich
> ein ACK

Seltsam, ich nicht:
TX Data: 0x0C, 0x05, 0x00, 0x10, 0x00
RX Data: 0x0F, 0x00, 0x00, 0x09, 0x00

Benedikt K. wrote:
> Wie versprochen, hier ist die Hex Datei für das EEPROM. Geändert ist
> folgendes:
> - Baudrate auf 19200 eingestellt
> - Parameter 1 von Befehl FFFFFF01 ist der Baudratenteiler, also
> (1,8432MHz / Baudrate)-1
> Die Baudrate wird übrigends erst nach dem Ack auf diesen Befehl
> geändert.

Genial. :-) Man bräuchte nur noch ne tolle Schnittstelle um das EEPROM
zu programmieren :|

Also bei mir ist definitiv was passiert beim Kommando 0C meine Kamera
funktioniert nich mehr :-) mal schnell wieder flashen.

Seltsam.
Bei mir reagiert die Kamera danach auch nicht wieder. Nach einem Sync
geht es wieder. So wie ich das verstanden habe, beschreibt dieser Befehl
nur den Programmcode RAM im OV528, nicht das EEPROM.
Das EEPROM müsste man mit SAVE DATA 0A, 03 beschreiben können. Ich denke
mal mit Serial Flash ist das EEPROM gemeint. Die nächsten 3 Paramter
sind die Länge, aber wo kommen jetzt die Daten ?

Ich vermute mal im Befehl 0a so wie es beim lesen eines Registers
gemacht wird????

Hi, wie gut das ich das Datenblatt besorgt habe (Habe übrigens direkt
beim Hersteller angefragt und innerhalb von 5 Minuten haben die mir das
zugemailt!)

Das man die Baudrate mit dem x01 Befehl ändert hatte ich ja auch schon
raus, es steht ja so im Datenblatt.
Mein bisheriges vorgehen war auch erst einmal mit der hohen Baudrate
connecten und dann runterschalten.
Habt ihr dann bei der Übertragung mit 115200 auch ein vernünftiges Bild
im Browser bekommen ? Meins sah leider etwas "zerzaust" aus ...
Nächste Woche habe ich endlich Urlaub und kann mich dann auch etwas
näher mit dem Eeprom-Beschreiben beschäftigen, aber auch nur wenn ihr
das bis dahin das Problem nicht schon gelöst habt ;-)

Hier noch ein Bild meiner Webcam bei 115.200

Ich habe gerade ein paar unkomprimierte und auch jpeg Bilder mit 115200
und 19200Baud gemacht: Funktioniert wunderbar.

Mmhh.
Hast Du schon die Werte im eeprom geändert, oder hast Du es vorerst noch
"softwaremäßig" die baudrate in der cam geändert ?

Ich bekomme unterhalb von 115,2 gar keine Verbindung zur Kamera.
Vielleicht hat sie ja schon einen Tick weg, von der ganzen probiererei.
Bei mir ist auch immer das erste Bild nach einem reset immer 1A und wird
dann von Bild zu Bild immer schlechter..

Ich habe ein modifiziertes EEPROM, (die Version die ich hier hochgeladen
habe).  Die startet mit 19200 und danach stelle ich per (modifiziertem)
INITIAL Befehl auf die andere Baudrate um.

Das Verhalten klingt danach, als wenn noch irgendwo alte Daten im Puffer
rumfliegen, die von Bild zu Bild einen größer werdenden Offset
verursachen.

Benedikt: Perfekt. Mit 19200 Baud kann ich die Kamera (auch wenn
langsam) an meinen mit 12MHz getakteten AVR hängen.

Ich glaub ich muss mir mal so eine Kamera bestellen. Hast du schon eine
gute Methode gefunden um das ROM-Image zu flashen? (Außer das schon
angesprochen mit dem AVR Programmieren).

Bei 19200Baud sollten immerhin noch 1,875kByte/s möglich sein. Sprich
~10Sekunden für ein 320x240 Bild. Akzeptabel würde ich sagen.

PS: Ob der ENC28J60 auch noch mit 24,576 MHz funktioniert? Weiß da
jemand wie genau die Toleranzen sind?
Im Datenblatt steht auf Seite 81 etwas von 25MHz +/- 50ppm, was
natürlich somit nicht möglich wäre.

Wäre ja auch zu schade gewesen mit nur einem Quarz so weit zu kommen ;)

Also schnell ist der Shop von der Nicole ja ;)

Michael wrote:
> Das wäre prima, wenn Du das Protokoll mitschneiden könntest.

Was soll das bringen ? Es ist doch bekannt, wie man die Kamera
ansteuert, und  wie man im Datenblatt sieht, ist das Protokoll komplett
willkürlich wählbar, je nach Firmware des µCs.

@Ulrich:
Ich hab nochmal eine Frage. Wenn ich jetzt über HTerm und meinen
High-Speed USB-RS232 Wandler das Bild ausgelesen habe, wie füge ich dann
am einfachsten JPEG-Header hinzu um mir das Bild direkt anschauen zu
können?

Beziehungsweise: Welchen JPEG Header hast du den Bilddaten
vorangestellt?

Hallo,

Es muß nichts mehr hinzugefügt werden, nur die ersten Längenbytes
entfernen und fertig. Ich meine das waren die ersten 16Bytes.

Gruß
Uli

Ulrich Radig wrote:
> Hallo,
>
> Es muß nichts mehr hinzugefügt werden, nur die ersten Längenbytes
> entfernen und fertig. Ich meine das waren die ersten 16Bytes.
>
> Gruß
> Uli

Ich glaube ich habe mich etwas unverständlich ausgedruckt. Ich meinte,
welchen JPEG Header ich voranstellen muss, um die Datei auf dem PC
anschauen zu können.

Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen
Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von
den Längenbytes)

Simon K. wrote:

> Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen
> Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von
> den Längenbytes)

Du glaubst es vielleicht nicht, aber es ist genau so !!!

Benedikt K. wrote:
> Simon K. wrote:
>
>> Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen
>> Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von
>> den Längenbytes)
>
> Du glaubst es vielleicht nicht, aber es ist genau so !!!

Alles klar, dann kommt also das PC-JPEG kompatible Bild (mit allen
Informationen zur Farbspeicherung und so weiter) direkt aus der Kamera.
Danke! :D

Hm. Ich hab hier den Wandler von Pollin. Die sind in der Regel alle
gleich aufgebaut. Also entweder Prolific Chipsatz oder ein FTDI
Chipsatz. Blöderweise ist bei dem Pollin Wandler direkt die RS232
Schnittstelle (ohne Umsetzer von TTL auf RS232 Pegel) aus dem Chip
herausgeführt, sodass ich einen Pegelwandler brauche.

Jedoch sind alle Versuche einen solchen zu bauen fehlgeschlagen. 1MHz
sind nicht zu unterschätzen.

Probiert habe ich es mit einem BC549 und unterschiedlich großen Pullup
und Basiswiderständen. Keine Chance für einen Analog-Laien :-)

Dann bastel ich mir erstmal eine kleine Platine für einen AVR und dann
seh ich mal weiter.

PS: Man kann übrigens auch ein 4poliges (Flachband-)Kabel an die
Kameraplatine löten.

Das Problem bei solchen Wandlern ist der RS232 Teil: MAX232 usw. sind
meist nur bis 115kBaud spezifiziert. Es gibt zwar einige die auch mehr
können, aber die sind eher selten.

Jup, sag ich ja. Ich war zuerst zuversichtlich und hab meinen RS232
drangehangen und mich nur gewundert, was denn da zurückkommt. Kamera
kaputt? Aber irgendwann hats dann auch Klick gemacht und dann ist es mir
aufgefallen.

Naja, Pegelwandler in der Geschwindigkeit für RS232 sind selten,
richtig.

Ulrich hat die Kamera an einen AVR angeschlossen und übertragt das Bild
anschließend mit einer niedrigeren Geschwindigkeit zum PC :D

Hallo,

Ich habe meinen USB nach RS232 TTL Wandler genommen zu finden auf meiner
HP unter Projekte.

Gruß
Uli

Ich hab hier solche Wandler von ner ELV sammelbestellung, gabs als
restposten für 1€ ;) Gehen auch bis knapp über 1MBaud

@Ulrich: Mir sind in der Zwischenzeit noch ein paar Fragen gekommen.

EDIT: Hat sich schon weiter oben erledigt. Wer lesen kann ist klar im
Vorteil ;) Ignoriert den Rest des Postings.

in deinem Code wartest du immer in der Empfangs-Routine für ein Zeichen
über das USART solange, bis du den entsprechenden 512Byte "Block" aus
dem Picture-DatenStream herausgeholt hast. Wird dann ein Byte
angefordert, dass zur Zeit nicht im Buffer liegt, dann wird erneut das
Image abgerufen und wieder solange gewartet, bis der relevante
Code-Block hereinkommt.

Allerdings sagt das Datenblatt des C328 etwas anderes zu dieser
Vorgehensweise:

Man kann die Daten mit Get Picture anfordern, daraufhin sendet die
Kamera, dass die Daten bereit zum senden sind und weiterhin noch die
Länge der Daten.
Anschließend kann man mit ACK Befehlen gezielt die Pakete anfordern.

Bis man irgendwann die Paket-ID 0x5050 sendet. Dann hört die Kamera wohl
auf.

Warum hast du das nicht so gemacht? Ist das etwa in der DC3840 nicht
implementiert? Schickt die DC3840 sofort ~15kB (Bei 320x240px) an Daten
über ihren TxD Draht nach draußen ohne Rücksicht auf Verluste?
Ich kann diese Vorgehensweise nur bei dem Uncompressed Picture finden.
(Vermutlich weil der RAM der Kamera zu klein ist, um es
zwischenzuspeichern)

Simon K. wrote:
> Allerdings sagt das Datenblatt des C328 etwas anderes zu dieser
> Vorgehensweise:
>
> Man kann die Daten mit Get Picture anfordern, daraufhin sendet die
> Kamera, dass die Daten bereit zum senden sind und weiterhin noch die
> Länge der Daten.
> Anschließend kann man mit ACK Befehlen gezielt die Pakete anfordern.

Der Befehlssatz ist nur ein Beispiel (steht auch dabei). In der Kamera
läuft ein µC, der diesen Befehlssatz ausführt. Und der ist von
Hersteller zu Hersteller der fertigen Kamera mehr oder weniger
unterschiedlich, je nach Software im EEPROM.
Mit direktem Zugriff auf die Register, sollte man das umstellen können.
Ich habe dies aber noch nicht ausprobiert

Danke Benedikt. Das konnte ich nach dem gründlichen kompletten Lesen des
Threads hier auch schon erfahren :-)

Übrigens, der MAX3225 ist ein 2/2 RX/TX 1MBaud Wandler für RS232
verfügbar im DIP Gehäuse.

Michi Müller wrote:
> Ich habe mal ein bischen herumgespielt und die Ack_befehle durch die der
> Phillips ersetzt und mit dem Hammer-Terminal (Super Teil !) zur Kamera
> geschickt, aber leider reagiert die cam danach nicht mehr und spuckt
> leider nicht denn eeprom-Inhalt aus :-(
> Mann muß sie erst wieder neu initialisieren bevor wieder eine Reaktion
> kommt.

Ja, genau das passiert bei mir auch.

> Was mich noch interessieren würde ist, was das Firmwartool in die Kamera
> schreibt. Es ist ja wohl auch 8051 Assembler, hab da aber mit einem
> Disassembler nix entschlüsseln können. Vielleicht kann da jemand anderes
> was entschlüsseln.

Wenn ich das richtig sehe, wird nach dem 0C Befehl das Register 0x0C mit
0x1F beschrieben. Und danach hängt sich die Software auf !!!
05EF  A1  EF    ajmp 5EFh

Das ist genau das Verhalten, das man auch sieht. Anscheinend gibt es
irgendeinen Watchdog o.ä. der nach einer bestimmten Zeit oder Anzahl
nicht beantworteten Anzahl an Bytes den 8051 neu startet.
Ich vermute also, der Download Befehl wurde auf diese Art entfernt.

Den hier:
http://www.controllertechnik.de/software.html

Er ist nicht der beste, aber anscheinend sind die Assemblertools vom
8051 am Aussterben.
Ich habe die erzeugte Datei mal angehängt.

Hallo,
fur interessierten, Siemens Handy Camera IQP-500 510 ....

Camera                              Atmega oder PC
RTS muss 1 sein
AT&F<CR>                                       19200
        OK<CR>
ATE0<CR>
        OK<CR>
AT+CMEE=1<CR>
         OK<CR>
AT^SACD=1<CR>
        OK<CR>
AT^SACD=2,"17"<CR>
        OK<CR>
AT^SACD=2,"17,00,2,IQP5 02.01"<CR>
        OK<CR>
AT^SACD=2,"17,04,2,3"<CR>                                  Ready status

        ^SACD: 17,04,2,1<CR>  Fotografieren
AT^SACD=2,"17,04,OK"<CR>
        OK<CR>
AT^SACD=2,"17,04,2,1"<CR>
        OK<CR>
AT^SACD=2,"17,04,2,2,3490,34882"<CR>       3490 kleine Bilder, 34882
grosse
        OK<CR>
        ^SACD: 17,01,2,1<CR>  1 klein, 2 gross
AT^SACD=2,"17,01,OK"<CR>
        OK<CR>    19200
AT^SADT=1,115200<CR>        115200
        rts  Dateiubertragung ist mit
                                          RTS geregelt  ( < 100 Zeichen
)
        CONNECT<CR>  115200
data            115200
        OK<CR>    115200
        rts
        OK<CR>    19200
        OK<CR>    19200
AT^SADT=2,"17,02,OK"<CR>      19200
        OK<CR>
        ^SACD: 17,02,2<CR>
AT^SACD=2,"17,04,2,3"<CR>

============================================
mit Blitz
AT^SACD=2,"17,04,2,3"<CR>
        ok
        ^SACD: 17,03,2<CR>
AT^SACD=2,"17,03,OK"
        OK
Verspatung
AT^SACD=2,"17,04,2,1"
        OK
AT^SACD=2,"17,04,2,3"<CR>
        OK
        ^SACD: 17,04,2,2
AT^SACD=2,"17,04,OK"
        OK
AT^SACD=2,"17,04,2,1"                      Fotografieren
                                           Veiter ist das gleich

Da es hier primär um die DC-3840 geht, würde ich zur IQP-500 diesen
Thread vorschlagen: Beitrag "IQP500 Kamera vom S55 an AVR?"

Dort gibts auch code...

So, ich habe jetzt mal die Kamera an einen Webserver gefriemelt,
allerdings habe ich ein paar Probleme.

Sende ich
- Reset
- Initial
- Snapshot
- 200ms warten
- GetPicture

dann läuft alles glatt.

Aber wenn ich zu einem beliebigen Zeitpunkt nochmal
- GetPicture
sende, dann dauert es 7 Sekunden bis die Kamera die JPEG Daten
rausschmeißt. Ist das ein bekannter Bug? Oder ist das korrekt? Ich
glaube ja mal kaum.
Ich habs sogar auf dem Speicheroszilloskop mir angeschaut. ~7sekunde
nachdem das GetPicture Paket kommt, kommt das große Datenpaket.

Jemand eine Idee dazu?

Scheint wohl als hätte noch niemand sonst die Kamera ausprobiert...

Ok, dann werde ich mal weiterforschen.

Was mich übrigens ein bischen stutzig macht, ist, dass du in deinem
Sourcecode die serielle Schnittstelle vom Mega644 nur mit 5 Bit
betreibst..?

Für eine 8Bit Schnittstelle muss 3<<UCSZ00 ins UCSRC Register
geschrieben werden, wenn ich mich nicht irre.

Und warum fügst du der Länge, die im DATA Befehl von der Kamera kommt 1
hinzu?

Steht im Datenblatt auf Seite 185 im 02/07 Datasheet vom Mega644 (Jaja,
etwas antiquitiert):

UCSZ01 und UCSZ00 müssen auf 1 sein für einen 8-Bit Transfer. Übrigens
hast du auf dem Bild von der Kamera auf deiner Seite auch stehen, dass
die Kamera keine Stoppbits braucht. Aber du meintest vermutlich
Paritätsbits.

EDIT: Ich seh schon, der Defaultwert von UCSRC setzt die beiden Bits
automatisch, najo.

Ok, habe nun herausgefunden woran es lag: Ich habe die SendCommand
Funktion etwas abgeändert, sodass der Befehl erneut geschickt wird,
solange bis ein ACK kommt. (So wie in deinen Sourcen)..

Gut, geht nun. Zugegeben eine etwas frickelige Kamera ;)

Mahlzeit,
ich hab mir den Cam-Treiber mal nach Pascal übersezt,
nun habe ich folgendes Problem:

Init klappt,
dann sende ich cam_picture_store:

cam_send_cmd (0x08,0x01,0x00,0x00,0x00);
  cam_send_cmd (0x10,0x01,0x00,0x00,0x00);
  cam_send_cmd (0x12,0x00,0x00,0x00,0x00);
  cam_send_cmd (0x18,0x01,0x00,0x00,0x00);
  cam_send_cmd (0x17,0x00,0x00,0x00,0x00);
  cam_send_cmd (0x21,0x03,0x00,0x00,0x00);
  cam_send_cmd (0x01,0x01,0x07,0x19,0x13);
  cam_send_cmd (0x05,0x00,0x00,0x00,0x00);
  cam_send_cmd (0x04,0x01,0x00,0x00,0x00);

Die Cam antwortet bis einschließlich 0x05 mit ACK,
auf 0x04 antwortet sie mit NAK aber ohne Fehlernummer:
FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 00

Hat jemand eine Vorstellung, woran das liegen könnte?

Gruß
Marco

Hallo,
mein letztes Problem habe ich gelöst,
war ein Fehler in der Int-Routine.

Jetzt versuche ich die Baudrate zu senken,
aber bisher ohne Erfolg.

Wie genau muss der Befehl für die Baudrate aussehen?
Laut Benedikt in 2 Aufrufen FFFFFF0104
Und dann FFFFFF0101

Das soll 115200 Baud bewirken.
Sehe ich das richtig?

Hat evtl Jemand das richtige Datenblatt zur Cam?
Ich finde hier immer nur das Datenblatt zur C328.

Grüße
MArco

Marco Bajerski wrote:

> Das soll 115200 Baud bewirken.
> Sehe ich das richtig?

Ja.

> Hat evtl Jemand das richtige Datenblatt zur Cam?
> Ich finde hier immer nur das Datenblatt zur C328.

Ein Datenblatt zu dem Chip gibt es hier:
http://www.mikrocontroller.net/attachment/30805/OV...

Der Rest ist kundenspezifische Software. Dazu wird man eher nichts
finden.

Danke für die Info!

Wenn ich die Baudrate mit:
cam_send_cmd (0x01,0x04,0x07,0x09,0x05);
cam_send_cmd (0x01,0x01,0x07,0x09,0x05);
umstelle dann erhalte ich auf den ersten Aufruf von der cam ein ACK,
auf den 2. Aufruf antwortet sie dann mit:
80 80 80 00 00 80 00 80 80 00 00 00 00 00 00 00

Es ist also etwas passiert, wenn ich anschließend den UART auf 115200
Baud umstelle, passiert aber garnix mehr.

Was mache ich falsch?

Lass mal den zweiten Befehl weg, sende also nur cam_send_cmd
(0x01,0x04,0x07,0x09,0x05);

Hallo,
danke, jetzt klappts ;-)

Aber auch mit geringerer Baudrate kommen immer noch fehlerhafte Bilder,
die Cam treibt mich in den Wahnsinn.

Gruß
Marco

Was für eine Takteinstellung/Was für ein Quarz benutzt du?

Hallo,
beides 014.745600.
Hardwareproblem kann ich ausschließen, denn Ulis Version läuft 1A,
nur mit meiner Pascal-Übersetzung haperts.
Ungewöhnlich ist, dass ab und zu auch ein brauchbares Bild bei raus
kommt.

Hier mal ein Beispielbild

Sieht so aus, als wenn irgendwie Daten verschluckt werden.

Allerdings, bin gerade dahinter gekommen warum das so ist.
Mein Pascal Compiler kann Longint weder multiplizieren noch dividieren,
er rechnet dann mit integer, anstatt einen Fehler auszuspucken.

moin. ich bin jetzt auch gerade am rumexperimentieren mit der camera und
habe das bsp programm von uli versucht zu verwenden. ich lese am com
port im moment folgendes aus :

X`<\0><17>JFIF<\0><1><1><1><1>,<1>,<\0><\0><\n>[<\0>C<\0><16><\f><\f><14><\f><\n><16><14><14><14><18><18><16><20><24>(<26><24><22><22><24>2$&<30>(:4><:488@H\N@DXF88PnRX`bhhh>Nrzpdx\fhd[<\0>C<1><18><18><18><24><22><24>0<26><26>0dB8BddddddddddddddddddddddddddddddddddddddddddddddddddD<\0><31><\0><\0><1><5><1><1><1><1><1><1><\0><\0><\0><\0><\0><\0><\0><\0><1><2><3><4><5><6><7><\b><9><\n><11>D<\0>5<16><\0><2><1><3><3><2><4><3><5><5><4><4><\0><\0><1>}<1><2><3><\0><4><17><5><18>!1A<6><19>Qa<7>"q<20>2<1><17>!<\b>#B1A<21>RQp$3br<2><9><\n><22><23><24><25><26>%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz<3><4><5><6><7><\b><9><\n><18><19><20><21><22><23><24><25><26>"#$%&'()*23456789:BCDEFGHIJRSTUVWXYZabcdefghijqrstuvwxyzD<\0><31><1><\0><3><1><1><1><1><1><1><1><1><1><\0><\0><\0><\0><\0><\0><1><2><3><4><5><6><7><\b><9><\n><11>D<\0>5<17><\0><2><1><2><4><4><3><4><7><5><4><4><\0><1><2>w<\0><1><2><3><17><4><5>!1<6><18>AQ<7>aq<19>"2<1><\b><20>B<17>!1A<9>#3Rp<21>brQ<\n><22>$4a%q<23><24><25><26>&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz<2><3><4><5><6><7><\b><9><\n><18><19><20><21><22><23><24><25><26>"#$%&'()*23456789:BCDEFGHIJRSTUVWXYZbcdefghijrstuvwxyz@<\0><17><\b><\0><\0><\0> <3><1>"<\0><2><17><1><3><17><1>Z<\0><\f><3><1><\0><2><17><3><17><\0>?<\0>`("<\n>H<16>"<\n>(<\0>"<\n>)<\0>QE<20>@("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n>@<20>QE<\0><20>QE<\0><20>QE<\0><20>QE0<\n>("<\0><\n>("<\0><\n>("<1> "<\n>)<\f>("<\n>`<20>QE <\n>("<24><5><20>QH<2><\n>( <2><\n>(&<1>E<20>P<1>E<20>P<1>E<20>P "<\n>)<\f>("<\n>`<20>QE<\0><20>QE <\n>("<\0><\n>("<24><5><20>Q@<5><20>QH<2><\n>(&<1>E<20>P "<\n>(<24>QE<20><\0>("<\n>`<20>QE <\n>("<\0><\n>("<\0><\n>("<24><5><20>Q@<5><20>Q@<5><20>Q@<2><\n>( h("<\n>@<20>QE<\0><20>QE<\0><20>QE<\0><20>QE<\0><20>QE0<\n>("<\0><\n>("<\0><\n>("<1><5><20>Q@<5><20>QHaE<20>P<1>E<20>P<1>E<20>P<1>E<20>P<1>E<20>S<\0>"<\n>(<\0>"<\n>(<3>Y<\0><\0>aq

was mir immerhin nicht komplett falsch erscheint. das "JFIF" in den
ersten paar bytes scheint mir fuer einen jpg header typisch zu sein. ich
las dass ich die ersten 16 bytes loeschen sollte ... habe ich auch
probiert, das erste bis inc dem 16. das hat alles nicht dazu gefuehrt,
dass diese daten als jpg interpretiert werden koennen.

hat jemand eine ahnung wo der fehler liegen koennte ?

mir erscheint der ganze datensatz auch relativ klein. ich habe jetzt
noch nicht ueberprueft in welchem modus das programm von uli sdtmaessg
ein bild aufnimmt. evtl ist es ja eine sehr geringe aufloesung.

ich habe auch schon versucht die ersten paar bytes aus einem der anderen
bilder die hier mit der camera gemacht und gepostet wurden zu ersetzen,
das hat aber nur dazu gefuehrt, das irfan view sagte : "jpg datastream
contains no image" ob das nun aber bei einem ersetzten header
irgendwelche aussage hat weiss ich leider nicht. es kann ja sein, das
der header aus dem funktionierendem bild den ich verwendet habe bei dem
bild das ich gemacht habe einfach der falsche ist, weil andere
farbeinstellungen/aufloesung oder was auch immer. ich verwendete "ÿØÿà
JFIF" statt meinen ersten bytes.

evtl hat sich ja schon jemand mit aehnlichen problemen konfrontiert
gesehen. vielen dank fuer eure zeit.

Hallo,
soweit ich weiß, werden die ersten 16 Bytes beim aktuellen Beispiel
schon von der Software gelöscht.

Lass dir das mal mit hterm im hex-Format ausgeben und dann speicher das
ganze im RAW-Format, dann sollte es klappen.

Die JPEG Files beginnen übrigens mit FF D8.

Gruß
Marco

aha. danke, das ist schonmal ein guter tip. jo ich habe das auch so wie
von dir beschrieben mit hterm gemacht. aber leider kein erfolg. ich bin
mittlerweile der meinung, das die daten schlicht nicht in dem bild
vorhanden sind. ich habe aus ulis programm den softuart ausgetauscht
gegen einen normalen uart (atmega 162 mit 2 uarts) und dabei ist mir
wohl ein fehler unterlaufen. das nicht funktionieren unten beschriebener
codezeile würde auch dazu passen, dass in meinem bild scheinbar keine
daten vorhanden sind, sondern nur header und drumherum. ich habe jetzt
um dem nachzugehen den modus der bildaufname auch mal von 160*120 auf
640*480 geschaltet. die erhaltenen daten bleiben in etwa gleich gross.
das kann schonmal nicht angehen.

//Ausgabe eines Bytes vom Bild
char cam_data_get (unsigned long byte)
{
  byte = byte + 1;
  unsigned long byte_tmp1 = byte / DAT_BUFFER_SIZE;
  
  if(byte < (cam_dat_start-CAM_HEADER) || byte >= (cam_dat_stop-CAM_HEADER))
  {
    cam_dat_start = CAM_HEADER + (byte_tmp1 * DAT_BUFFER_SIZE);
    cam_dat_stop = CAM_HEADER + DAT_BUFFER_SIZE + (byte_tmp1 * DAT_BUFFER_SIZE);
    
    //request Data
    //PORTD |= (1<<6);
    UCR =(1<< RXC1);//<-- hier bin ich mir nicht sicher.

    cam_command_send (0x04,0x01,0x00,0x00,0x00);
    for(unsigned long a = 0;a<100000;a++){asm("nop");};
  }
  byte = byte % DAT_BUFFER_SIZE;

return (cam_dat_buffer[byte]);
}

die eine zeile von uli habe ich mal auskommentiert. die hatte ich
bishher noch nicht ersetzt durch eine fuer den normalen uart passenden
zeile (uart1 in meinem fall fuer die camera). nun weiss ich nicht, was
nach ulis softuart mit diesem D6 da eigentlich gemacht wird. der D5
scheint ja der über software emulierte TX pin zu sein. ist der D6 dann
als RX pin geplant ? das steht da so explizit leider nirgends. oder aus
welchem grund wird hier D6 gesetzt ? wie muesste das für einen normalen
uart ausschauen ?

wer 7 statt 8 databits einstellt, der darf sich ueber datenmuell nicht
wundern.... ich poste den code fuer 2 uart controller an einem atmega
spaeter sobald ich ihn bereinigt habe. es laeuft jetzt. danke.

Moin.

Mein aktuelles Problem ist nun, dass ich 2 Bilder hintereinander machen
möchte und zwar in Graustufen. Diese beiden Bilder möchte ich dann pro
Pixel in Ihren Helligkeitswerten auf einem AVR voneinander abziehen. Die
daraus Resultierende Matrix aus Grauwerten soll dann weiter verarbeitet
werden. Es ist in diesem Fall nicht wichtig, dass diese Matrix noch
irgendein Bildformat hat. Dazu stellt sich jetzt die Frage wie ich das
am besten machen.

A) ich verwende jpg Dekomprimierungsbibliotheken für c um an die
Grauwerte der einzelnen Pixel zu kommen

B) ich lasse mir von der Kamera direkt ein Bild übertragen welches
unkomprimiert die Grauwerte in einer Matrix enthält.

zu B habe ich leider noch keine möglichen Kameraeinstellungen gefunden.
Ist da jemand schon weiter? ich habe es bisher mit

cam_command_send (0x05,0x01,0x00,0x00,0x00);//snapshot, UNcompressed

probiert, bin mir aber bei der interpretation der Daten nicht sicher. Es
werden viel weniger Bytes bei gleicher Auflösung zurückgegeben als bei
einem komprimierten Bild, das kann ja schonmal nicht sein....

zu A) fehlt mir im Moment eine Bibliothek zum dekomprimieren von .jpg
Dateien. Diese finden sich zwar haufenweise für c++ aber so gut wie
nicht fuer c.

Hat jemand ähnliches Probiert oder einen Tip ?

Danke für Eure Zeit

Moin Matatron.

Mich würde gerade mal brennend interessieren wie du es hinbekommst die
bilder unkompressed zu empfangen, das funktioniert bei mir naemlich
derzeit ueberhauptnicht. kannst du mir bitte die commands die du in
folge sendest posten und evtl nen kleinen commentar geben. ich bin mir
recht sicher, dass ich das datenblatt richtig verstanden habe, aber bei
mir will es einfach nicht. ausserdem wuesste ich gerne wie die
unkompressed daten dann zu interpretieren sind. aus dem hterm in eine
.jpg datei kopieren wird ja dann vermutlic nicht mehr möglich sein oder?

ich suche immer noch nach einer möglichkeit ein farb oder grauwertbild
so von der camera anzufordern, dass mir in folge fuer jeden pixel die
farbwerte uebertragen werden, statt das ein komprimiertes bild ankommt,
dessen dekomprimierung auf dem avr zu rechen/speicher-intensiv wird.

zur uebertragungsrate :
80*60 pixel = 4800 pixel
4800 * 8 = 38400; angenommen jeder pixel hat 8bit information. farbwerte
gibts glaube ich bis 12bit rauf ?

da haste du bei 115200 baud also noch 115200/38400 = 3 pro sekunde.

was dabei nicht bedacht ist sind natuerlich saemtliche rechenoperationen
auf den mCs - die werden aber nicht so sehr ins gewicht fallen vermute
ich (es sei denn du rufst jeden pixel einzelnd ab, statt alle am stueck
als stream ausgeben zu lassen) und erkannte uebertragungsfehler/resends
usw. also liegst du mit deinen 3 bildern pro sekunde etwa da wo man es
erwarten wuerde. der flahscenhals sind halt die 115200 baud. die kamera
liefert ja irgendwo im 900.000er bereich an den mC. also koenntest du
den mC einfach ueber eine andere schnittstelle auslesen (usb ist
schneller als der serielle port vermute ich). da muesste man sich
informieren in wieweit ein com zu usb adapter diese geschwindigkeit
nutzen koennte (um weiteres loeten zu vermeiden).

ich habe anstelle das ttl zu rs232 auf den comport noch eine
funkuebertragung ueber zigbee dazwischen und die laeuft stabil mit guten
19200 baud (das ist etwa die geschwindigkeit in der meine oma schreiben
kann), also kopf hoch :) - das ist dann auch der grund warum ich die
bilder nicht am pc dekodieren will, sondern auf dem mC - um nicht
unnoetig sachen zu uebertragen die ich eh nich brauche.

Hallo

Ich habe mir bei Ulrich eine Philips DC-3840 gekauft.

Ich habe mir nun das Datenblatt für den OV528 angesehen und mache mir
darüber Gedanken ob und wie man die „serielle 4 Draht Übertragung“ (“4
wire serial interface”) nutzen kann.
Leider sind die Daten über die Vierleiterschnittstelle mehr als dürftig.

Handelt es sich in beiden Fällen um die gleiche UART? Nur einmal mit und
einmal ohne Hardware Handshake und wo kommt da die Leistungssteigerung
von 920kbps auf 2Mbps her?

Das Layout zeigt das der SXIN (Pin 12) Eingang mit dem UCLK (Pin 16)
Ausgang verbunden ist.

Die Berechnung der Baudrate sollte dann folgendermaßen aussehen.

Der Systemtakt fXIN von 14,7456MHz wird durch einen Frequenzteiler auf
den RS-232-Master-Takt fUCLK herunter geteilt. Es besteht dabei die
Möglichkeit den Systemtakt ungeteilt zu übernehmen oder im Register UDIV
das Teilungsverhältnis einzustellen.
Im Datenblatt angegeben ist folgende Gleichung: UCLK = XIN  2 
(UDIV+1) ODER UDIV = 80h => UCLK = XIN.

Ist damit eigentlich UCLK = (XIN / 2) / (UDIV+1) gemeint?

Der Mastertakt fUCLK speist dann über den SXIN Pin den
Baudratengenerator.
Die Baudrate BaudR berechnet sich nach folgender Formel
Baudrate = (fUCLK /2) / (UBR+1),
wenn ich die im Datenblatt angegebene Formel
Baudrate = SXIN  2  (UBR+1)
richtig interpretiere.
Mit UDIF =1 und UBR=1 folgt dann
Baudrate = ((((14,7456MHz /2) /2) /2)/2) = 921.600bps.

Wenn ich dann UDIV=80h setze und UBR=0 käme man auf eine Baudrate =
((14,7456MHz/2)/1) = 7.372.800bps.

Könnte man aus dem Datenblatt schließen das mehr als 2Mbps nicht drin
sind?
Treiberfähigkeiten der IO-Pins?
Seite 4 sagt „4-wire serial bus: 1~2M bps for transferring JPEG still
pictures or SIF (320x240) preview @4 bpp with 6~8 fp“

Für die Signale RTS_ (Pin17) und CTS_ (Pin 20) finde ich in den
Registern irgendwie keine direkte Abbildung mit den man deren Pegel via
Software steuern kann.
Ich vermute das diese Leitungen per Hardware über die FIFO - Zustände
gesteuert werden?
Diese werden im Register CSS (Chip select & status)
Bit 7: Serial bus received FIFO empty status. Read only
Bit 6: Serial bus received FIFO full status. Read only
Bit 5: Serial bus transmitted FIFO empty status. Read only
Bit 4: Serial bus transmitted FIFO full status. Read only
für das Betriebsprogramm zur Auswertung bereitgestellt.

Das ganze Datenblatt scheint mir nicht alle Informationen zu enthalten?
Vielleicht gab es weitere „Datenblätter“ zum OV528?

Auch zum EEprom stellen sich mir noch ein paar Fragen. Wird das Programm
bei Power Up einmal in der OV528 eingelesen und dann intern in einem RAM
gehalten? Und falls das so ist wäre es möglich das EEprom mit einem MC
zu simulieren? Das würde ein spielen mit dem  Anwendungsprogramm
wesentlich vereinfachen?

Und dann hab ich da noch eine Befürchtung, es handelt sich nicht nur um
eine doppelseitige Platine, sondern und mindestens eine 4 Lagen
Multilayerplatine?

Würde mich über jeden Kommentar freuen.

Grüße Dirk

Hallo

Ich versuche gerade die DC-3840 an einen PIC18F2550 zu hängen
und Bilder über die USB-Schnittstelle zum PC zu übertragen.
Der USB Stack läuft und ich kann bereits mittels MPUSBAPI Daten
im Burstmode vom PC zum PIC und zurück übertragen.
Momentan versuche ich das Kameraprotokoll in eine State-Maschiene
zu packen. Diese soll in einer Endloschleife gepollt werden.

Jetzt frage ich mich wann die Kamera genau mit einem ACK antwortet?
??? ??? sind die Stellen bei denen ich mir nicht sicher bin.

Bei der Synchronisation scheint es klar zu sein.
PIC->CAM : SYNC solange bis ACK von CAM
CAM->PIC : ACK
CAM->PIC : SYNC
PIC->CAM : ACK

Dann die Initalisierung

PIC->CAM : RESET
??? CAM->PIC : ACK ???
PIC->CAM : INIT
??? CAM->PIC : ACK ???

Dann Bilder abrufen

PIC->CAM : SNAPSHOOT
??? CAM->PIC : ACK ???
PIC->CAM : Get Picture

Bilddatenübertragung

CAM->PIC : Data
CAM->PIC : Bilddaten [x Bytes]
??? PIC->ACK : ACK ???

Dann zurück nach Bild abrufen.

Grüße und vielen Dank

Dirk

PS: Nachdem ich mir das Datenblatt noch einmal angesehen
    habe, beschäftigen mich die Fragen in meinem obrigen
    Post [[Beitrag "Re: Protokoll DC-3840 Handycam"]]
    immer noch.

Dirk F. wrote:
> Jetzt frage ich mich wann die Kamera genau mit einem ACK antwortet?
> ??? ??? sind die Stellen bei denen ich mir nicht sicher bin.

Nach jedem Befehl entweder mit einem ACK oder NACK.

@  Simon K. : Vielen Dank!

Dirk

Hallo, ich fange auch gerade mit der Cam an, nur leider bekomme ich als
antwort auf den Sync immer nur "0C 80 80 80". Momentan hängt mein Aufbau
an einem MAX3225 und darüber am PC, am PC lese ich mit HTerm.

Ich schicke "FF FF FF 0D 00 00 00 00" zur Cam, mehrmals, und erhalte
iwann genauso oft "0C 80 80 80" als Antwort, wie ich zuvor "FF FF FF 0D
00 00 00 00" gesendet hab.
Dass es immer bisschen dauert liegt iwie an der Verbindung HTerm mit
meiner RS232 Karte, Windows Hypterterminal geht einandfrei, da empfange
ich alles sofort, nur leider kann ich da keine Hex-Eingaben machen.

Ne Idee an was es liegen könnte? Loopback nach dem MAX3225 zurück zum PC
zeigte eine einwandfreie Übertragung. Kamera läuf wie der MAX an 5V.

MFG
µLuxx

Hi, mich beschäftigt das Thema auch schon 'ne ganze Weile und verstanden
habe ich dieses Ding noch nicht so ganz. Das, was du da schilderst, habe
ich auch so erlebt, als ich die Kamera mal direkt an einen PC
durchgereicht habe. Mit Hterm habe ich im Übrigen auch gute Erfahrungen
gemacht, das Bray-Terminal hat ein Datendurchsatzproblem und verschluckt
gerne etliche Bytes.

Ich benutze mittlerweile einen virtuellen COM-Port via USB (FTDI 245),
damit man überhaupt über 115200 hinaus kommt. Was ich bislang
festgestellt habe ist, dass das Timing schon sehr scharf ist und
entsprechend bedient werden muss. Man kann sehr leicht asynchron werden.
Und dann klappt einfach nix.

Zudem kann ich die Ausführungen hier im Thread als auch die von Ulrich
auf seiner Homepage nicht alle so ganz nachvollziehen. Ich habe es
bislang z.B. noch nicht hinbekommen, dass die Kamera mit weniger als
230400 Baud sauber funktioniert. Dann scheint es 18 Bytes und nicht 16
Bytes nach Senden des Get-Pic-Befehls zu dauern, bis das JPG-Bild kommt
- so ist es jedenfalls bei mir.

Ich frage mich mittlerweile, ob diese Kamera es wert ist, soviel Zeit
damit zu verbringen. Gibt's nicht noch was Besseres?

Hallo

@µluxx

Möglicherweise liegt das Problem an der Datenleitung von der Kamera zum
PC.
Bei mir erreicht die Spannung für den High Pegel der Kamera ca. 2,6V.
Für den Input-Pin der UART in meinem PIC ist das zu wenig. Die UART hat
CMOS-Schmitttrigger Eingangsstufen (Highpegel = 5V * 0,7) und keinen
TTL-Eingang, da wäre der High-Pegel 2V. Deshalb scheint es auch mit
einem
MEGA zu funktioniern.

Ich habe zwei 74 HCT 04 Inverter (nicht HC) in Reihe an den Ausgang der
Kamera gelegt. Die haben TTL-Inputs und CMOS Outputs.

Beim MAX3225 ist der Input Logic Threshold High (bei Vcc = 5V) = 2,4V.
Je nach dem wäre es vielleicht ratsam den Baustein mit 3,3V zu
betreiben,
da sind es dann 2V. Je nachdem was für ein Spannungsabfall auf den
Leitungen dazu kommt und sich die Sache bei 900kbit verhält.

Grüße Dirk

also daran lag es nicht, ich habe eher den verdacht dass es iwie an
meiner rs232 karte liegt, ich hab mir jetzt nen MBaud USB-RS232 wandler
gekauft, mal schaun was der bringt...

Hallo,

die letzten Nächte habe ich mit der Kamera von Ulrich Radig und einem
ATmega32 auf dem STK500 verbracht und sind schon fast Freunde :-)

0) Was geht...
JPEG-Snapshot und Übertragung mit der SoftUART zum Windows-PC,
allerdings nur mit 34800 Baud. Habe dazu die alte CAM_Testsoftware
(01/2008) mit dem Code aus dem aktuellen Webserver-Projekt aktualisiert.
Empfang und Anzeige des JPEG-Bildes auf dem PC mit einem kleinen
selbstgeschriebenen Tool:

  -> ca. 6s/Frame (0.17fps) bei JPEG@320x240 color low_compression

Ich dachte es läge an der SoftUART.
Wenn ich aber die Daten nicht übertrage, sondern nur ins Leere laufen
lasse, dann braucht die Schleife mit cam_data_get(a) aber trotzdem noch
ca. 4 Sekunden. Das ist nicht unbedingt das was ich erwartet hatte.

Woran kann das liegen? STK500? SoftUART? Kamera defekt?
Oder ist das Auslesen eines Snapshots immer so langsam?

1) max. sinnvolle Baudrate der SoftUART
Ist vermutlich nicht die Lösung zu obigem Problem, aber welche max.
Baudrate konntet Ihr bei Euch einstellen?

2) Unterschied Preview vs. Snapshot
Ich habe es noch nicht geschafft ein Preview richtig auszulesen.
Wozu braucht man es? Was ist der Unterschied zum Snapshot?
Ich vermute beim Preview wird kein Bild im Speicher der Kamera abgelegt
wie beim Snapshot. Ist der Datenstrom fortlaufend oder nur ein Bild?
Ist die Qualität schlechter? Ist die Übertragung schneller, siehe Punkt
0)?

3) Preview, uncompressed 8Bit gray (kein JPEG!)
Habe ich noch nicht geschafft auszulesen. Der Datenstrom über die
SoftUART ist sehr lang. Zunächst dachte ich, dass fortlaufend Previews
gesendet werden, aber nach etlichen Sekunden ist es vorbei. Ich bastel
mir das was ich empfange in eine PGM-Datei. Manchmal sieht es so aus als
wären dort Bruchstücke eines Bildes drin. Ist die SoftUART zu langsam?

Vielen Dank
Gruß Jörg

Hallo nochmal,

habe es geschafft ein 8Bit Gray Preview 160x120 zu empfangen.
Aber das Empfangen der Daten dauert ca. 17 Sekunden.
Ich übertrage die Daten nicht sofort, um Wechselwirkungen mit der
SoftUART auszuschließen.
Vielmehr speichere ich die Daten zunächst in ein Array[40*30], mache
also eine (einfache) 4-fach Unterabstastung (ich benutze den internen
RAM des ATmega32!). Aber warum frage ich mich, dauert es so lange die
1200Bytes über 921600 Baud zu empfangen?????

Mein Code:

1) Anforderung des Previews

unsigned long cam_preview (char mode)
{
  unsigned long bytes = 0;
  unsigned long timeout = 300000;
  

  // Initialisierung
  //////////////////////////////////////////////////
  cam_command_send (0x08,0x01,0x00,0x00,0x00);  // Reset
  cam_command_send (0x10,0x00,0x00,0x00,0x00);  // Compression (0:low, 2:high)
  cam_command_send (0x12,0x00,0x00,0x00,0x00);  // Light (0:day, 1:night)
  cam_command_send (0x18,0x01,0x00,0x00,0x00);  // Zoom 0:2x, 1:normal)
  cam_command_send (0x17,0x01,0x00,0x00,0x00);  // Color (0:color, 1:grey)
  cam_command_send (0x21,0x03,0x00,0x00,0x00);  // ???

  cam_command_send (0x01,0x01,0x03,0x03,0x03);

  cam_command_send (0x04,0x02,0x00,0x00,0x00);

  cam_dat_start = CAM_HEADER;
  cam_dat_stop = CAM_HEADER + DAT_BUFFER_SIZE;

  while((cmd_buffercounter) < CMD_BUFFER_SIZE && (timeout--) != 0);

  bytes = (unsigned long)cam_cmd_buffer[13];
  bytes+= ((unsigned long)cam_cmd_buffer[14]<<8);
  bytes+= ((unsigned long)cam_cmd_buffer[15]<<16);

  return(bytes+1);
}// cam_preview()

2) Lesen der Preview-Daten

char cam_data_get (unsigned long byte)
{
  byte = byte + 1;
  unsigned long timeout = 300000;
  unsigned long byte_tmp1 = byte / DAT_BUFFER_SIZE;
  
  if(byte < (cam_dat_start-CAM_HEADER) || byte >= (cam_dat_stop-CAM_HEADER))
  {
    cam_dat_start = CAM_HEADER + (byte_tmp1 * DAT_BUFFER_SIZE);
    cam_dat_stop = CAM_HEADER + DAT_BUFFER_SIZE + (byte_tmp1 * DAT_BUFFER_SIZE);

    cam_command_send (0x04,0x02,0x00,0x00,0x00);

          while(cmd_buffercounter<cam_dat_stop && cmd_buffercounter<max_bytes && (timeout--) != 0);

  }
  byte = byte % DAT_BUFFER_SIZE;
        return (cam_dat_buffer[byte]);
}

3) Aufruf aus der Main

void GetSnapshot(void)
{
  max_bytes = cam_preview(0); 
  
  // subsampling
  int ss =4;    // subsampling-Faktor
  bytes_to_send /=ss*ss;
  
  // subsampling in Zwischenspeicher
  char* pBuffer =NULL;
  int i =0;
  int col =0;
  int row =0;
  if ( NULL!= (pBuffer=(char*)malloc(bytes_to_send)) )
  {
    // Daten in Buffer ablegen
    for(unsigned long a=0;a<max_bytes;a++)
    {
      col =a%160;  // Bildspalte x
      row =a/160;  // Bildzeile y

      // subsampling-Maske = 8x8 Block
      if ( 0==col%ss && 0==row%ss )
        pBuffer[i++] =cam_data_get(a);
    }
  }

  // UART
  //////////////////////
  if ( NULL!=pBuffer )
  {
    // Buffer senden
    for(i=0;i<bytes_to_send;i++)
    {
      uart_write_char(pBuffer[i]);
    }

    free(pBuffer);
  }

}// GetSnapshot()

Lasse ich nun in 2) cam_data_get() die zeile

cam_command_send (0x04,0x02,0x00,0x00,0x00);

weg, so ist es sehr schnell (ca. 1 s) aber die Daten sind nicht korrekt
(siehe Anhang). Wofür ist dieses nochmalige Anfordern gut?

Ich hoffe, mir kann jemand weiterhelfen.
Anscheinend kann es ja auch anders gehen, wie ich hier im Thread gelesen
habe. Vielen Dank für Eure Hilfe.

Gruß
Jörg

Hallo,
man merkt, dass Herbstferien sind :-)

Ein 160x120 Preview (8Bit Grey) mit cam_data_get() zu holen benötigt
leider immer noch ca. 17 Sekunden. Ich verwende

  cam_command_send (0x01,0x01,0x03,0x03,0x03);

Heute konnte ich die Kommunikation der UART auf einem Oszilloskop
verifizieren: es scheinen wirklich 921600Baud zu sein, daran liegt es
also nicht.

@Uli et. al.
Da hier im Forum noch viele Fragen unbeantwortet blieben und auch sonst
im www kein HowTo gefunden habe, wäre es super, wenn jemand folgende
Aussagen bestätigt oder kommentiert:

A) Ein Preview wird nicht im Kameraspeicher abgelegt, sondern sofort
übertragen?
B) Was ist ein uncompressed snapshot picture? Unkomprimiertes JPEG oder
Rohdaten?
C) Unkomprimierte Bilder (Rohdaten, z.B. (Bit Gray) können nur als
Preview übertragen werden? (siehe B)
C) Ein Preview wird nicht als einzelne Pakete gesendet, sondern am
Stück?
D) Ist es möglich, wie in dem C328 User Manual beschrieben, auch bei der
DC-3840 eine Paketgröße mit Kommando

  cam_command_send (0x06,0x08,0x00,0x0X,0x00);

anzufordern und dann die einzelnen Paket zu quittieren? Wenn ja, geht
das auch mit unkompressed Daten (z.B. 8Bit Gray)?
E) Die cam_get_data(a) Funktion schaut, ob das angeforderte Byte a
aktuell im Buffer cam_dat_buffer[] vorhanden ist? Wenn a bereits von der
Kamera gesendet worden ist (aber nicht mehr im Buffer vorhanden) oder
noch nicht gesendet wurde, dann wird ein neues Bild angefordert.
F) Warum war in früheren Code-Versionen von Uli CMD_BUFFER_SIZE  16,
aktuell sind 17 eingestellt?

Fragen über Fragen.
Bisher habe ich die Kamera nur ausgeliehen, aber es sollte schon laufen
bevor ich solche Kameras kaufe.

Vielen Dank nochml. Für irgendeine Antwort wäre ich immer dankbar.

Gruß

Hallo

@ Jörg

zu D. Wenn ich es richtig verstanden habe, wird nicht wie bei
der C328 Blockweise übertragen, sondern immer das ganze Bild.
Daraus wird dann je nach Größe des Pufferspeichers ein Teil
herausgegriffen und anschießend versandt. Der Rest der Über-
tragung wird ignoriert.
Also Datenmenge = (Bildgröße / Puffergröße) * Bildgröße
Daher die langen Übertragungsdauern.

Grüße Dirk

Hallo

und vielen Dank für die Antworten.
Das hatte ich vor, morgen mal am Oszilloskop mir anzuschaun, aber ich
hatte schon vermutet, dass das Bild komplett kommt.

@ Uli
Das wußte ich nicht, ich dachte auch auf dem AVR-WebServer hättest Du
mehr als 1 frames per second erreicht.

Dann ist es also davon abhängig, wie schnell man die Daten (Bytes)
ausliest, respektive welches Byte man gerade haben möchte. Falls das
Byte schon von der Kamera gesendet wurde, wird das Bild erneut
angefordert. So, jetzt habe ich es verstanden. Vielen Dank.

@ Uli
Du überträgst dann aber die Daten per HTTP (bzw. in der Testsoftware per
SoftUART), was natürlich langsamer ist. Ich hatte vermutet, dass in
meinem Beispiel, selbst wenn ich die Daten ins Leere laufen lasse

for(unsigned long a=0;a<max_bytes;a++)
    {
        test =cam_data_get(a);
    }

es dann schneller geht, aber hier dauert es trotzdem in etwas so lange.
Kann es sein, dass ich dann zu schnell bin und cam_data_get() auch ein
neues Bild anfordert, wenn dieses betreffende 'a' noch nicht gesendet
wurde? Hier werde ich morgen mal näher hinschaun.

Vielen Dank nochmal
und vielleicht weiß ja noch jemand auf die anderen Fragen Rat.

Grüße an alle
Jörg

Hallo allerseits,

so, viele Nächte sind vorüber...
Es läuft mittlerweile ganz gut.
Die Funktion cam_data_get() gibt es bei mir allerdings nicht mehr.
In der ISR speichere ich nun die einkommenden Daten in 2 Zeilenbuffer
(immer abwechselnd). Im main() kann ich dann auf das fertige
Zeilenbuffer zugreifen, natürlich hat man da nur soviel Zeit wie die
Zeile gültig ist. Das reicht z.Zt. für ein einfaches Downsampling mit
arithm. Mittelwert oder aber auch für 2 einfache Sobel-Kantenoperatoren,
also d/dx bzw. d/dy.
Durch diese Einschränkung (kein externes SRAM, keine 2. UART) schaffe
ich dann allerdings auch das ganze Bild in einem Rutsch zu verarbeiten,
d.h. das was die 921600 kBaud hergeben (

Was mir allerdings noch aufgefallen ist: beim Preview ist die
Belichtungssteurung doch sehr am Schwingen. Habt Ihr das auch
beobachtet?
Das war auch unschön bei der cam_data_get(), da die Helligkeit der
Teilbilder (wenn Daten neu angefordert werden) variiert. Vielleicht war
das auch das Problem bei Marco Bajerski (earlyperl).

Grüße
Jörg

Ich benutze dazu Hterm!

Hi,

ich kam mit HTerm nicht zurecht, aber das war eher ein Problem der
Übertragung selbst. Versuch mal SerialWatcher ...

Noch eine Sache. Ich habe die 16Byte (oder 17?) einfach nicht
übertragen, sondern mir die reinen Bilddaten in einen Buffer
geschrieben. Dann brauchst Du auch nichts ausschneiden...

Gruß

Hallo Karsten,

ist bei mir schon lange her.
Wüßte aber nicht, dass es ein Windows-Programm gibt, was das kann, was
Du willst.
Ich habe ein Tool geschrieben, was per (2.) UART des ATMEL kommuniziert.
Aber das hilft Dir nicht...

Im Prinzip müßte man aber ein Tool schreiben können, was mit der Kamera
direkt spricht...

Grüße

Hi nochmal,
meine Kamera steht schon fast 1 Jahr auf meinem Werktisch.
Daneben das STK500.
Mich wundert es, dass die Kinder noch nicht an den Kabeln gezogen haben
:-)

Ich hoffe, dass ich irgendwann wieder Zeit habe dafür.
Wenn es Tool gibt, wäre ich natürlich auch interessiert...

Ich habe den Thread in meiner Benachrichtungsliste, d.h. ich bekomme
eine email, wenn es einen neuen Beitrag gibt.

Ansonsten noch schöne Feiertage und einen guten Rutsch!

Grüße
Jörg

Hi,

gibt es auch die moeglichkeit die cam an zwei normale I/O pins zu
haengen .. oder muss es zwingen uart sein .. hab naemlich kein uart :-(

gruesse dominique

Hallo Dominique,

theoretisch könntest Du das vielleicht auch mit einer Soft-UART
hinbekommen.
Ich schätze aber, dass Du so keine 9xx kBit/s hinbekommst.
Ansonsten dauert der Datentransfer halt wirklich lange...
Ich bin mir jetzt nicht sicher, ob es nicht sogar eine Mindest-Rate für
die Cam gibt, oder eine Default-Rate (9xx kBit/s ?), die man dann
runtersetzen kann. Ist schon so lange her...

Grüße
Jörg