www.mikrocontroller.net

Forum: Projekte & Code Protokoll DC-3840 Handycam


Autor: Uli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hier das Protokoll der Philips DC - 3840 Handycam.
Die DC - 3840 arbeitet mit 921600 Baud. Das Protokoll entspricht soweit 
der C328. Komando ID6 und ID7 werden nicht unterstützt! Der 
Kommandoheader ist hier nicht AAh sondern FFh FFh FFh. Also sieht das 
Synckommando wie folgt aus FFh FFh FFh AAh 0Dh 00h 00h 00h anstelle wie 
bei der C328 AAh 0Dh 00h 00h 00h 00h. Interessant ist noch der Inhalt 
des EEProms zu debuggen, um z.B. die RS232 Schnittstelle etwas langsamer 
zu betreiben.

Gruß
Uli

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann solltest du deinen Shop mal updaten. Da steht noch 
"Kameradatenstrom noch nicht entschlüsselt!"

;-)

Autor: Uli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hier ein Bild(320x240) welches ich mit hterm ausgelesen habe.
http://www.der-hammer.info/terminal/index.htm

Sync der Kamera
FF FF FF 0D 00 00 00 00
FF FF FF 0E 0D 00 00 00

Bild 640 x 480
FF FF FF 08 01 00 00 00
FF FF FF 01 01 07 09 07
FF FF FF 05 00 00 00 00
FF FF FF 04 01 00 00 00
Bilddaten werden gesendet

Bild 320 x 240
FF FF FF 08 01 00 00 00
FF FF FF 01 01 07 09 05
FF FF FF 05 00 00 00 00
FF FF FF 04 01 00 00 00
Bilddaten werden gesendet

Bild 160 x 120
FF FF FF 08 01 00 00 00
FF FF FF 01 01 07 19 13
FF FF FF 05 00 00 00 00
FF FF FF 04 01 00 00 00
Bilddaten werden gesendet

Gruß
Uli

Autor: radiguli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hier mal ein kleiner DC-3840 Kameratreiber für einen ATmega644. Wichtig 
ist dabei dass der Quarz mit 14,7456Mhz schwingt!! Die Kamera wird dabei 
direkt an den USART des Prozessors angeschlossen. An Pin D.5 stehen die 
Daten seriell zur Verfügung (Softuart, 1 Startbit, 8 Datenbits, 1 
Stoppbit, 38400Baud).

Gruß
Ulrich

Autor: radiguli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Bild des Versuchsaufbaus.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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.

Autor: Ralf K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand eine günstige Bezugsquelle für diese Handycam DC-3840?
Danke.

Autor: radiguli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ralf K.

Schau mal in meinen Shop auf meiner HP!

Gruß
Uli

Autor: Ralf K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, habs gefunden.
Dass man sich im Shop erst anmelden muss, um die Versandkosten zu 
erfahren, finde ich prinzipiell schlecht. Kannst Du das nicht ändern?

Autor: Bernd P. (bertron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Gruß
Ulrich

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Uli!

Mal schauen, ob ich die Kamera in mein Hausbus-System integrieren kann 
(um zu sehen, wer an der Türe geklingelt hat). Weil ich eine relativ 
geringe Baudrate fahre, kommt es sehr auf die Größe der Bild-Dateien an. 
5kb sind aber zienlich problmlos.

Viele Grüße, Stefan

Autor: Ralf K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Uli:
Kann man in Deinem Shop auch per Paypal bezahlen?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf K.

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

Gruß
Ulrich

Autor: Ralf K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nein!
Ok, man wird ja wohl noch fragen dürfen...

> Desweiteren ist dies nicht mein Shop sondern der von meiner Frau.
Ein paar Beiträge weiter oben hast Du noch geschrieben:
"Schau mal in meinen Shop auf meiner HP!"

SCNR

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

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

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Ulrich, das kenne ich irgendwoher!

Ihr habt euch im letzten Jahr Idealismus und Gewinn redlich miteinander 
geteilt, du darfst den Idealismus auch im kommenden Jahr behalten!

:-D

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt K.

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

Gruß
Uli

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist ein kleines Datenblatt einer Kamera, die auch den OV528 
benutzt.
Dort sind einige Commands beschrieben.

www.electronics123.net/amazon/datasheet/C328R_UM.pdf

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: radiguli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Bei der DC-3840 gibt es den Befehl für die Packetgröße nicht, alle Daten 
werden hintereinander gesendet! Das Bild bleibt aber im Speicher und 
kann so oft wiederholt gesendet werden wie man will.

Gruß
Ulrich

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: radiguli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, mit dem Längenangabenbefehl FF FF FF 0A xx xx xx xx.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: radiguli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo so ist es, hätte man mehr Speicher könnte auch das ganze Bild 
genommen werden. Der Block kann aber auch kleiner als 512Bytes sein.

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum musst das Quarz 14,7456Mhz sein? Wieso kann ich nicht 18.4320MHz 
benutzen?

Wegen den Warteschleifen?

Autor: radiguli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe 14,7456 gewählt weil sonst ein Mega32 übertacktet wird. 
18.4320Mhz könnte auch klappen evt. die Warteschleifen verlängern. Hatte 
den SourceCode nur mal in der schnelle geschrieben.

Gruß
Ulrich

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok ich werde es heute testen.
Die Platine und die Kamera sind von deiner Frau da:-)

Der Stecker auf der Kamera ... was ist das für ein Stecker?
Ist das eine ganz normale Sterio Klinge?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Gruß
Ulrich

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wie öffnet man die Kamera? Sehe da keine Schrauben.
Für einen Tip wäre ich dankbar.

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Schraubendreher stark schräg ansetzen, und nach oben drücken.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Uli,

Wie sieht es denn mit der Lichtempfindlichkeit der Kamera aus?
Ist die mit der MCA25 zu vergleichen?

Gruß, Volker

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uii da haste aber für nen guten preis eingekauft g (vermute ich 
einfach mal)
Ebay-Artikel Nr. 110201473298

Ich wär vorsichtig mit dem posten von Bildern aus derm Datasheet auf 
deiner Website (noch dazu ohne Quellenangabe)
Das könnte teuer werden wenn irgendsoein Abmahnanwalt das entdeckt o.ä. 
:-X

Weißt du zufällig was da für ein Bildsensor verbaut ist ?
Hast du mal unter die Linse geguckt ? Bzw wenn überhaupt steht das 
meistens auf der Rückseite vom
Bildsensor (haste nicht zufällig mal einen abgelötet oder ? )

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Unter die Linse habe ich auch schon geschaut. Allerdings kommt man an
>den Sensor alleine nicht dran ist nur ein Siliziumplätchen.
Also der Sensor (Siliziumplätchen) sollte in so einem Glasgehäuse 
stecken.
Das ist dann mit der Platine verlötet (SMD). Und unter dem Gehäuse steht
manchmal die genaue Bezeichnung des sensors.
Mit ein bisschen Geschick könnte man dann uU das Datenblatt finden.
(Ich tippe mal auf einen Micron Sensor, da findet man auch die 
Datenblätter recht einfach)
Dann könnte man den Chip ggf einzeln nutzen ;)

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt ja noch mehr als Atmega CPUs da draußen ;)
Zeitkritisch für nen Atmega ja, nen FPGA machts mit links...

Hast du Fotos von dem Chip ?
Aufgrund deiner Anmerkung wegen der Größe vermute ich die haben nen 1/4" 
Sensor drunter ?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier zum auslöten ;-))))

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok damit hatte ich nicht gerechnet gg
Auslöten geht ja noch (bügeleisen/heissluft von der rückseite)
aber das wars dann auch schon gg
Danke fürs Pic ;)

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Seite hilft dir evt. weiter!!

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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cool! danke !

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss der TX pin der Kamera an den TX Pin des AVRs oder muss TX an RX and 
RX an TX?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

TX an RX und RX an TX!

Gruß
Ulrich

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JEPPI!!! Ich habe mein erstes Testbild. Man die Kamera braucht ja viel 
Licht um gute Fotos zu machen ;-)

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Gruß
Ulrich

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohne digital Zoom
FF FF FF 18 01 00 00 00

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

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S/W
FF FF FF 17 01 00 00 00

Farbig
FF FF FF 17 00 00 00 00

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Gruß
Ulrich

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe noch die Informationen zur Kamera auf meiner HP erweitert.

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An welcher stelle müssen die Kommandos kommen für die Einstellungen?

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar habs gefunden ... klappt wunderbar.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kamera gibt es bei ebay ;-)

Ebay-Artikel Nr. 330200819757

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
to: Benedikt K.
921600/(160*120*8)=6
sollte eigentlich funktionieren
laeft es ueberhaupt mit 16p

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich meine die Codierung war so:

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

Gruß
Uli

Autor: Andre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Frage an diejenigen, die die Cam an den AVR MCU bereits angeschlossen 
haben:

Hat auch der MCU in euerer Schlatung die 3,3V Versorgung? (da TX-RX pins 
der Cam anscheinend 3,3V pins sind)

Wenn man doch direkt 5V vom uC's TX und Reset einspeist, wird davon die 
Cam nicht defekt?

Und wenn die nicht defekt wird, ist die Bildquali dann i.O? Ich denke an 
die MCA25... was man da nicht alles vorschalten musste an den TX und 
Reset pins....

Ganz andere Frage. Dem Datenblatt von AVR zufolge gibt's keine Baudrate 
von 921600 Bits/sec (bei Fehler von 0%) wenn man den 18,432 Mhz Oszi 
verwendet (mein MCU ist Atmega644-20). Der relative Fehler wird dann so 
groß, dass er in dem Datenblatt nicht mal angeführt wird (- Zeichen in 
der Spalte).

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

Vielen Dank für euere Infos im Voraus!

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerd G. (elektrikser)
Datum:

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

Das funktioniert schon rechnerisch nicht.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

... hier gibts noch ein älteres, ausführliches Datenblatt zu der 
Philips-CAM ...

http://www.roundsolutions.com/cmos-camera/CAM-VGA1...

... scheint da ja verschiedene Versionen der Firmware zu geben, daher 
wohl das Problem mit der Ansteuerung.

100 Stück von der Kameras gingen übrigens am 12.12.07 bei ebay für 11,50 
Euro weg (Artikelnummer für Suche: 110201473298)

Als Alternative gibts bei ebay zur Zeit eine weitere UART - gesteuerte 
Siemens Cam mit Blitz und verträglicher Baudrate.
Modell: IQP-500/530 (sind baugleich).

Kostet zum SofortKauf nur 1 Euro
(Versand 4,60, jeder weiter 2€  Versand)
ArtikelNummer für Suche: 180151200261

Eine Bauanleitung habe ich auch gefunden, die Details sind für mich 
allerdings nicht verständlich (ist wohl Slowakisch).
Aber vieleicht findet sich ja einer, der es uns übersetzen kann :-)

http://pandatron.info/elektronika2/clanek.php?&rub...

hier noch ein Test von dem Teil:
http://www.xonio.com/features/feature_unterseite_8...

und ein paar Erfahrungsberichte:
http://www.ciao.de/Siemens_QuickPic_Camera_IQP_500...

Grüße

Tim

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

> die Befehle 0x21 und 0x22 gibt es noch,

kann mir jemand sagen was diese Befehle ausloesen ?

Ulrich benutzt den 0x21 auch in cam.c:

in cam_picture_store(char mode)
 cam_command_send (0x21,0x03,0x00,0x00,0x00);

Gruesse
  horst

Autor: gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stecker und Stativ für DC3840

Autor: gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier das orginal Datenblatt!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Geschwindigkeit der RS232 Schnittstelle kann doch nun direkt an die 
richtige Adresse geschrieben werden. Allerdings werden die Werte nur 
nicht dauerhaft gespeichert.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Wenn ich 0xff 0xff 0xff 0x0C 0x05 0x00 0x10 0x00 hinschicke bekomme ich 
ein ACK also wird das Kommando zumindest unterstützt.

Gruß
Uli

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :|

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

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

Autor: Michael Schneider (snickers)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Michael Schneider (snickers)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Bild meiner Webcam bei 115.200

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Michael Schneider (snickers)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: 4apaev (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits!
ich habe etwas für euch! denke ich mal.
Es gibt noch eine Kamerahandy, die gleiche Chipsatz hat: SYN0547A von 
Motorola. Wen ihr Interesse habt, kann ich mitgeschnittene protocol 
Posten. Die läuft übrigens mit 115200.
eBay link cam mit handy:
Ebay-Artikel Nr. 230217304509

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also schnell ist der Shop von der Nicole ja ;)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es gibt noch eine Kamerahandy, die gleiche Chipsatz hat: SYN0547A von
> Motorola. Wen ihr Interesse habt, kann ich mitgeschnittene protocol
> Posten. Die läuft übrigens mit 115200.

Das wäre prima, wenn Du das Protokoll mitschneiden könntest.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !!!

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sir Robin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo bekommt man denn einen High-Speed USB-RS232 Wandler her ?

Sind alle USB-rs232 Wandler auch High-Speed fähig oder gibt da auch 
unterschiede ?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Gruß
Uli

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also entweder Prolific Chipsatz
Mein USB-Seriell Kabel mit dem Chipsatz macht auch nur 115.200 max.

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

Ha, prima das Du das erwähnt hast. Mir ist gerade eingefallen, das ich 
auch noch so ein Modul im Bastelkeller habe. Manchmal geht einen schon 
der Überblick bei seinen Sachen verloren...
Jetzt kann ich wenigstens auch per PC die Kamera ansteuern.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michi Müller (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich Firmeware ändern:

Ich habe ein Firmware-Update Tool, anbei im Anhang, für eine 
C328-ähnliche Kamera (CAM-UCAM100) aus dem Netz geladen und mal den 
Vorgang für den Firmware-Download des Tools mit einen Com-Port-Sniffer 
"mitgesnifft" (Siehe auch den Anhang). So wie es aussieht lädt das 
Programm eine Software in die Kamera (Befehl FF FF FF 0C 05 40 16 00).
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.

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.
Meine Hoffnung ist ja immer noch das wir es hinbekommen den EEpom Inhalt 
Softwaremäßig zu ändern ;-)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Geschwindigkeit mal auf 115.200b runtergeschaltet 
(inspiriert durch deinen Watchdog) und das File nochmal durchgejagt. 
Jetzt gibt er auf die Daten wenigsten schon mal Errors aus und hängt 
sich nicht direkt auf danach.

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Benedikt

Was für einen Disassembler benutzt Du eigentlich ?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef Josef (Firma: none) (josef1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Josef,
vielen Dank für die Einstellung des Protokolls der IQP-500. Verstehe ich 
das richtig, dass für die Kommunikation mit der Kamera RTS immer 1 sein 
muss? Was ist mit CTS? Kann man beide (RTS und CTS) permanent auf 1 
setzen?

Hast Du vielleicht schon die Kommunikation in einem Programm umgesetzt?

Gruß

Martin

Autor: tomgr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zitat :
Hast Du vielleicht schon die Kommunikation in einem Programm umgesetzt?
zitat ende.


daran hätte ich auch interesse.

gruss tom

Autor: Star Keeper (starkeeper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Scheint wohl als hätte noch niemand sonst die Kamera ausprobiert...

Autor: uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Simon das kann nicht sein sind schon einige weg. Allerdings konnte ich 
dein Problem nicht nach vollziehen.

Gruß
Uli

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann werde ich mal weiterforschen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kommste denn darauf???

Autor: uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal Defaulteinstellung des Registers an.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ist es ;-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas H (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann mir vllt jemand sagen wie es mit der Infrarot Empfindlichkeit der 
Kamera  aussieht? Sieht man Fernbedienungen damit, ist da ein Filter 
drinn der IR rausfiltert?
Hintergrund wäre die Kamera mit einem Tageslichtfilter zu verwenden um 
ein Objekt mit einem Infrarot Sender zu Tracken.

gr
thomas

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
danke, jetzt klappts ;-)

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

Gruß
Marco

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für eine Takteinstellung/Was für ein Quarz benutzt du?

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco Bajerski (earlyperl)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Beispielbild

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht so aus, als wenn irgendwie Daten verschluckt werden.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matatron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Leute
Ich hab da ein Problem.
Meine Kamera Hängt an einem ARM der mit dem PC verbunden ist. Ich möchte 
gerne ein Preview Bild mit dem C++ Builder darstellen. Nur wird dieses 
nicht richtig Dargestellt.
In welchen Format ist das Preview Bild. Im Moment stelle ich jeden 
ankommenden Wert(s/w(8-Bit)) von links oben Zeile für Zeile nach rechts 
unten dar. Das ist offensichtich falsch.
Gibt es eine bestimmte Struktur wie die Pixel angezeigt werden müssen 
bzw Format.

Autor: Matatron (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zum besseren verständnis hier mal ein Pic. Das aufgenommene Bild ist zur 
hälfte Schwartz und zur Hälfte Weiß. Idealerweise hätte ich eine Klare 
Trennlinie Zwischen diesen bereichen.
Hat jemand die gleiche erfahrung gemacht.

Autor: Matatron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok der Buffer aud der PC seite des UART war zu klein bzw schlecht
programmiert.
Wenn es jemanden interessiert.
Wenn ein Grau Skala Bild gemacht wird, können die Daten Zeile für Zeile
von Links nach Rechts Dargestellt werden.
Tolles Bild

Autor: Mad Tulip (madtulip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mad Tulip (madtulip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Mad Tulip (madtulip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mad Tulip (madtulip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matatron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Forum
Mir ist einiges bei der C328R noch nicht Klar deshalb stelle ich mal ein 
paar Fragen.
1-Was ist genau der Unterschied zwischen Snapshot und Preview?
2-Ich bekomme maximal 3 Bilder/s bei uncompressed preview 115200baut 
80*60(UM Seite12). Geht da noch mehr ohne jpeg?
3!!!!-Nochmal zu 2.
Nach der Initialisierung habe ich 2 bis 3 sec Zeit um das Get Picture 
Com abzusetzen mache ich das nicht ist die Kamera Praktisch tot. d.h. 
Ich kann nicht neu Initialisieren und das Get picture com erneut 
absetzen.
Bleibe ich beim get picture innerhalb der 2-3s kann ich auch 1000 bilder 
machen. Hat oder besser hatte jemand auch dieses Problem und kann 
helfen.
Ich hoffe ich habe das halbwegs verständlich ausgedrückt

Autor: Mad Tulip (madtulip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matatron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry Mad Tulip hab nur auf der Arbeit Internet.

also: Uncompressed Preview 80*60

1.Initialisierung
AA 01 00 02 01 00

AA01=ID
00  =immer
02  =4 bit grau scale für 8 bit grau scale 03 eintragen
01  =80*60
00  =immer

dann bekommst du wenn alles gut geht den ACK

2. Get Pic
AA 04 02 00 00 00
AA04=ID
02  =Preview
00  = immer
"      "

dann wieder ACK & große der Daten

Jetzt kannst du die 4800 punkte direkt von oben Zeile 1 von links nach 
rechts darstellen dann Zeile 2 usw.
das geht im c++ Builder ganz gut. Das ganze steht im User M auf seite 12 
ganz gut erklärt.


ps: bei 4 bit Grau Scale sind in einem Byte 2 Pixel untergebracht für 
die Schnelligkeit

Autor: Dirk F. (sensornix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Das Datenblatt zum OV528 wurde schon in diesem Thread gepostet! Oder 
aber auch bei Uli im Forum.

Autor: Timebeast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matatron:
Kann es sein das Du statt "FF" "AA" geschrieben hast?
1.Initialisierung
AA 01 00 02 01 00
...

Sollte das nicht FF 01 00 02 01 00 heißen?
Ist noch nicht verifiziert, bin noch am Anfang...

Gruß
Ralf

Autor: Matatron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
an: Timebeast (Gast)

Ich Arbeite mit der C328R hier fangen die commandos immer mit AA an.

Autor: Dirk F. (sensornix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk F. (sensornix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Simon K. : Vielen Dank!

Dirk

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst darauf achten, wann genau Du und wann die Kamera den 
Baudratenwechsel durchführt.
Evtl. muss Du noch auf den Ack warten, bevor Du umschaltest.

Ich weiß jetz nicht, ob die Senderoutine mit einem Fifo arbeitet, d.h. 
die Routine wird beendet, bevor alle Bytes rausgesendet sind, wird die 
Baudrate schon während des Sendens umgeschaltet. Das geht natürlich 
schief.

Autor: µluxx .. (uluxx) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: No Name (nohelp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dirk F. (sensornix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: luxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das problem ist aber dass der max3225 nur bei 5V für 1Mbaud spezifiziert 
ist.
andererseits habe ich mit dem bis 250k spezifierten max232 auch 460k 
ohne probleme hinbekommen...mal schaun, aber danke für den Tipp!

Autor: µluxx .. (uluxx) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg T. (brause)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Dirk F. (sensornix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so ist es bei meinem SourceCode da ich im AVR leider nicht mehr Speicher 
habe. Habe ich natürlich noch externen Speicher oder was ähnliches würde 
es auch anders gehen.

Gruß
Uli

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mentox (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi, kann man die cam auch an einen comport vom pc direct anschliessen?
mfg mentox

Autor: jtag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
sry das ich den alten thread nochmal ausgrabe, aber ich habe Probleme 
aus dem Empfangenem ein jpg zu machen. Ich habe die DC-3840 an einen 
FT232RL an den USB angeschlossen und die Kommunikation läuft auch super. 
Ich weiß bloß nicht, wie ich aus dem Empfangenem ein jpg mache. Kann mir 
das jemand alles Schritt für Schritt genau erklären?
Also ich weiß schonmal, dass ich die ersten 16byte entfernen muss, und 
das ich das ganze als RAW speichern muss, aber wie bekomme ich die 
ersten 16Byte weg? Welche Tasten muss ich klicken :D ? Ich kann das 
Hterm einfach nicht bedienen.
mfg, jtag

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze dazu Hterm!

Autor: jtag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ja ist mir klar, aber wie machst du es, dass die ersten 16 byte nicht 
mitkonvertiert werden?

mfg

Autor: jtag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
kann mir keiner helfen? Ich bin schon am verzweifeln. Ich will endlich 
mal Bilder anschauen können :P , aber ich kanns nicht, weil ich es nicht 
richtig abspeichern kann. Wie macht ihr das? Ihr könnt das doch alle als 
Bild anschauen, dann wisst ihr auch wie das geht. Bitte erzählt es mir 
doch.

mfg

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: jtag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Da ich das Ding direkt an den PC angeschlossen habe, kann ich die ersten 
16 Byte nicht weglassen. Wie hast du das gemacht, mit welchem Programm? 
Hast du selber was programmiert? Ich bin leider nicht in der Lage sowas 
selber zu programmieren, dazu fehlen mir die Kenntnisse.

mfg

Autor: jtag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Kennt ihr einen Konverter, mit dem ich aus der empfangenen Hex-datei 
wieder ein jpg machen kann? (also hex to raw?)

mfg

Autor: jtag (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, habs jetzt....

Autor: little_doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Wie hast du es gemacht. Ich hänge gerade auch dabei, die Hex-Daten ein 
JPG zu machen

gruess
Doc

Autor: Karsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich will die Kamera zum laufen bringen. Bevor ich mich an den AVR 
ranmache, möchte ich die Kamera am PC auf Funktionstüchtigkeit prüfen. 
Da ich hier gelesen habe, dass der ein oder andere bereits ein Programm 
in einer Hochsprache verfasst hat, möchte ich fragen und bitten ob sich 
dieser bereit erklärt sein Programm oder auch Quelltext, mit mir / uns 
zu teilen.

Ich wäre sehr dankbar.

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, genau dass ist nötig.
Habe vermutet dass: Matatron 
Beitrag "Re: Protokoll DC-3840 Handycam"
und Marco Bajerski Beitrag "Re: Protokoll DC-3840 Handycam" 
bereits eine Implementierung vorgenommen haben.

Der Beitrag ist wohl schon zu alt...

Ich danke Dir für Deine Antwort. Mglw. meldet sich noch jemand der eine 
winzige selbst geschriebene Anwendung in der Schublade hat.

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: jtag (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi nochmal,
hier ist ein kleiner codeschnipsel, mit dem man die empfangenen hex 
daten in ein jpg umwandeln kann. Einfach compilieren und dann die hex 
datei per drag and drop auf die exe ziehen

Autor: Dom XYZ (mentox)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.