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
Dann solltest du deinen Shop mal updaten. Da steht noch "Kameradatenstrom noch nicht entschlüsselt!" ;-)
Angehängte Dateien:
-
test.jpg
15 KB
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
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
Ä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.
Hat jemand eine günstige Bezugsquelle für diese Handycam DC-3840? Danke.
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?
Hi Uli! Feine Sache! Wird es auch noch einen Code für den Mega32 mit den Quarzen der Webserver-Schaltung geben oder schafft der das nicht? Frohe Weihnachten, Bernd
Hallo, Der aktuelle Source Code auf meiner HP schaft es auch mit einem Mega32! Der Testserver auf meiner HP arbeitet mit einem Mega32 und der Kamera. Allerdings habe ich hier die kleinste Auflösung gewählt (160 x 120). Gruß Ulrich
Hallo Uli, kannst Du eine ungefähre Hausnummer sagen, wie groß einzelne Bilder in der Auflösung 160 * 120 werden? Sind die Bilder in dieser Auflösung noch einigermassen erkennbar? Vielen Dank, Stefan
Hallo, Die Bilder mit einer Auflösung von 160x120 haben eine größe von 5kB. Bilder bei 320x240 etwa 15kB und Bilder mit 640x480 etwa 30 kB. Ob ich auf den Bildern was erkennen kann? Meine doch, Bilder auf meinem Handydisplay sind nicht größer. Aber wer mag kann ja die Auflösung noch etwas vergrößern 320x240 oder 640x480. Wobei sich 320x240 bei mir als optimale Auflösung herrausstellte. Gruß Ulrich
Hallo, Habe mal mit der Kamera 3 Bilder gemacht. Auflösung 160x120,320x240 und 640x480. Gruß Ulrich
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
@Ralf K. Nein! Desweiteren ist dies nicht mein Shop sondern der von meiner Frau. Gruß Ulrich
> 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
;-) Bisher war jeder noch zufrieden. Der Shop ist Offtopic, hier gehts ums Protokoll!!
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
Kann die Kamera eigentlich auch unkomprimierte Bilder liefern ? Diese könnte man leichter mit einem µC weiterverarbeiten um so z.B. erst mal eine Bewegungserkunnung zu machen, ehe das eigentliche Photo gemacht wird ?
Hallo, Ja die Kamera kann auch unkomprimierte Bilder liefern, mit einem Propeller und der Kamera kam ich auf 6 Frames in der Sekunde. Das lag aber auch nur an der langsamen Geschwindigkeit der RS232 Schnittstelle ;-) Ulrich
Der OV528 besitzt einen 8051 µC, dessen Software im externen EEPROM steht. Ich habe den EEPROM Inhalt mal durch einen Disassembler laufen lassen: Teilweise macht der Coder sogar Sinn. Da ich leider (noch) keine solche Kamera habe, kann ich nicht ausprobieren, was passiert wenn man die Werte ändert. Dem Code nach werden einigen Werte aus dem ROM gelesen und an irgenwelche Register geschrieben. Im EEPROM steht also vermutliche die Grundinitialisierung.
@Benedikt K. Hast du das Datenblatt des OV528 gefunden? Wenn noch nicht schicke mir mal eine kurze Mail. Gruß Uli
Leider nicht. Das ganze steht auf der News Seite von Omnivision, die nur noch im google Cache ist (1. Ergebnis der google Suche nach OV528): "The OV528 can be programmed by mobile device manufacturers with proprietary protocols to customize the interface between the camera and the host. Protocols are the communications standards used between electronic devices to exchange information. The OV528 has a built in 8051 micro-controller to process the program, which can be stored in an EPROM on the camera or downloaded directly from the host." Wenn man den Code mal ordentlich debuggt, könnte man rausfinden, welche Werte wohin geschrieben werden (welche Bytes im EEPROM also Daten und welche Code sind). Das würde es leichter machen, durch Ausprobieren z.B. die Baudrate anzupassen.
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
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 ?
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
Das heißt, nach dem Get Picture Befehl wird das Bild sofort komplett gesendet ?
Danke, jetzt habe ich es verstanden: Es wird jedesmal das komplette Bild gesendet, aber nur der gewünschte 512Byte Block wird im AVR gespeichert, die restlichen Daten werden verworfen.
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.
Warum musst das Quarz 14,7456Mhz sein? Wieso kann ich nicht 18.4320MHz benutzen? Wegen den Warteschleifen?
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
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?
Hallo, Ich habe die Kamera geöffnet, den Stecker abgeschnitten und die Kabel verlängert. Eine normale Stereoklinke ist das nicht. Gruß Ulrich
Hi, wie öffnet man die Kamera? Sehe da keine Schrauben. Für einen Tip wäre ich dankbar.
Angehängte Dateien:
-
Gehaeuse_oeffnen.JPG
70 KB
Schraubendreher stark schräg ansetzen, und nach oben drücken.
Hallo Uli, Wie sieht es denn mit der Lichtempfindlichkeit der Kamera aus? Ist die mit der MCA25 zu vergleichen? Gruß, Volker
uii da haste aber für nen guten preis eingekauft g (vermute ich einfach mal) http://cgi.ebay.at/Philips-350-VGA-Ansteckkamera-P-N-DC-3840-100-Stueck-neu_W0QQitemZ110201473298QQihZ001QQcategoryZ57528QQcmdZViewItem 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 ? )
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
>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 ;)
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 ;-)
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 ?
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 ;)
JEPPI!!! Ich habe mein erstes Testbild. Man die Kamera braucht ja viel Licht um gute Fotos zu machen ;-)
Hallo, Es gibt noch ein Konfigurationsregister für die Beleuchtung das muß ich mal noch raussuchen. Gruß Ulrich
Hallo, Normal (Kommando) FF FF FF 12 00 00 00 00 Dunkel (Kommando) FF FF FF 12 01 00 00 00 siehe auch meine beiden Testbilder gleiche Beleuchtung! Gruß Uli
ohne digital Zoom FF FF FF 18 01 00 00 00 mit 2x digital Zoom FF FF FF 18 00 00 00 00
S/W FF FF FF 17 01 00 00 00 Farbig FF FF FF 17 00 00 00 00
Wo hast du die Werte her ? Ausprobiert oder aus irgendeiner Beschreibung ? Funktionieren eigentlich die ganzen Farbmodi (2bpp, 4bpp, 8bpp, 12bpp, 16bpp) aus der Beschreibung der C328 ?
Hallo, Farbmodis habe ich noch nicht alle durchgetestet. Ich habe den Datenstrom von Handy und Kamera aufgezeichnet. Und gesendete Register (Kommandos) durchgetestet. Gruß Ulrich
Habe noch die Informationen zur Kamera auf meiner HP erweitert.
Kamera gibt es bei ebay ;-) http://cgi.ebay.de/Ansteckkamera-fuer-Philips-CT-350_W0QQitemZ330200819757QQihZ014QQcategoryZ12439QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
Heute kamen endlich meine Kameras. Erstmal bin ich erschrocken, denn die Bilder waren alle rosa/grün. Grund: Ich hatte die Kamera nur mit 3,3V betrieben. Mit 5V geht es besser... Hier noch ein paar Befehle: 0x10,i,0x00,0x00,0x00 i=0..2, JPEG Kompression. 0 ist die beste, 2 die schlechteste 0x17,i,0x00,0x00,0x00 i=0..3, 0=Farbbild, 1=Graustufen, 2=blau, 3=braun Wenn man die Bilder unkomprimiert anfordert, scheint die Kamera diese auch JPEG zu komprimiert haben, man sieht nämlich deutlich die Kompressionsartefakte.
Hallo, Ja die Kameras arbeiten mit 5V haben einen kleinen Stabi! Intern arbeiten diese aber mit 3,3V ich finde eine 5V Versorgung besser als eine 3,3V ;-) Gruß Ulrich
Ich hab noch ein paar Befehle durchprobiert: 0x13 (Lichtfrequenz) wird nicht unterstützt, zumindest bekomme ich da immer ein NAK. 0x21 und 0x22 gibt es noch, aber was diese bewirken konnte ich nicht herausfinden.
Noch eine Info: Mit bester Qualität (JPEG Kompression auf 0) kann man keine 640x480 JPEG Bilder machen, sondern nur 320x240.
Ich hätte da noch eine Frage, und zwar hierzu:
Ulrich Radig wrote:
> mit einem Propeller und der Kamera kam ich auf 6 Frames in der Sekunde.
Wie hast du das gemacht ?
Ich kommt mit viel Glück auf 1fps bei 160x120@8bpp. Die Kamera ist
einfach nicht schneller.
Oder verwendest du den Preview Modus ?
Ab und zu liefert die Kamera bei mir auch anstelle des Bildes bei dem
Get Picture Befehl ein NAK. Den genauen Grund habe ich noch nicht
rausgefunden, aber ich vermute es liegt an der zu kurzen Wartezeit
zwischen dem Snapshot und dem GetPicture Befehl.
Gibt es dazu irgendwelche Infos, Erfahrungswerte o.ä. wie lange man
warten muss ?
to: Benedikt K. 921600/(160*120*8)=6 sollte eigentlich funktionieren laeft es ueberhaupt mit 16p
Hallo Ich sende zur Kamera: FF FF FF 01 01 05 19 13 FF FF FF 10 01 00 00 00 FF FF FF 12 00 00 00 00 FF FF FF 18 01 00 00 00 FF FF FF 17 00 00 00 00 FF FF FF 21 03 00 00 00 FF FF FF 08 01 00 00 00 FF FF FF 04 02 00 00 00 Bild wird ausgegeben FF FF FF 0E 0A 01 00 00 nächste Bild wird ausgegeben FF FF FF 0E 0A 02 00 00 nächste Bild wird ausgegeben usw.
Ich bekomme als Antwort auf den letzen Befehl (FF FF FF 04 02 00 00 00) ein NAK. Muss man nicht vorher erstmal einen Snapshot Befehl senden ?
Zeitweise kann es vorkommen das das FF FF FF 04 02 00 00 00 mehrmals gesendet werden muß. So macht es auch das Philips Handy!
Das ist auch eine nette Lösung. Es geht zumindest irgendwann nach dem 5. bis 15. Befehl. Meine Erfahrung bisher: Wenn die Kamera ein NAK sendet, bzw. garnichts sendet, dann habe ich zuletzt irgendwas falsches geschickt bzw. irgendein Ack vergessen zu senden. Wenn ich normale Bilder mache, dann sendet die Kamera (außer beim Sync) nie ein NAK bzw. garnichts.
Noch eine letze Frage: In welchem Format werden die Bilder im Preview Modus ausgegeben ? Ich erhalte immer 18432Bytes, egal was ich einstelle. Die Bilder haben eine Auflösung von 192x96, es scheint allerdings kein 8bpp Graustufenformat zu sein.
Hallo, Ich meine die Codierung war so: 8Bit (3Bit Rot)(3Bit Grün)(2Bit Blau) Gruß Uli
Hallo 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!
Hallo, Ich habe keine Probleme mit der DC-3840 an einem AVR mit 5V. Man benötigt keine weitere externe Beschaltung. Die MCA25 benötigte eine stabilisierte 3,3V Spannung die DC3840 hat ihren eigenen Stabi. Allerdings wenn man sichergehen will, kann man ja am TX Pin des Prozessors den Pegel auf 3,3 V herrabgeteilten. Gruß Ulrich
>Frage ist ob einer schon den 18,432 Mhz Quarz getestet hat und ob es >funktionierte? Das funktioniert schon rechnerisch nicht.
Hallo, ... hier gibts noch ein älteres, ausführliches Datenblatt zu der Philips-CAM ... http://www.roundsolutions.com/cmos-camera/CAM-VGA100-User-Manual%20V2-0.pdf ... 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?&rubrika=mi&clanek=38 hier noch ein Test von dem Teil: http://www.xonio.com/features/feature_unterseite_8949906.html und ein paar Erfahrungsberichte: http://www.ciao.de/Siemens_QuickPic_Camera_IQP_500_Mobiltelefon_und_Digitalkamera__1167651 Grüße Tim
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
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.
Angehängte Dateien:
-
dc3840_eep.gif
6,2 KB
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.
Die Geschwindigkeit der RS232 Schnittstelle kann doch nun direkt an die richtige Adresse geschrieben werden. Allerdings werden die Werte nur nicht dauerhaft gespeichert.
Das ist leider das Problem: Man benötigt erstmal die dumme Baudrate, um diese umzustellen. Es wäre schön wenn man mit einer verträglicheren anfangen könnte.
Ich habe herausgefunden, wie man die Baudrate anpasst: Falls jemand den Code debuggen möchte (oder gar eine eigene Firmeware schreiben), hier ein paar Infos: Die OV528 Register sind als XRAM in den Speicherbereich des 8051 eingeblendet, und zwar im Bereich 0xFFxx. Wie bereits gesagt, die ersten 32Bytes der EEPROM Daten wegwerfen, dann hat man den reinen Programmcode. In diesem steht die Funktion zum Beschreiben des Baudratenregisters an Adresse 0x0333. Diese wird genau 2x aufgerufen. Einmal wenn der Befehl 0x01 (INITIAL) gesendet wird. Dessen erster Parameter ist die Baudrate als 2^x Teilerfaktor. Standardmäßig ist hier 1 eingestellt, also 2^1 = 921kBaud. 4 ergibt z.B. 115,2kBaud. Der nächste Aufruf ist die Initialisierung mit dem Standardwert: 0x01. Dies ergibt den Teilerfaktor 2, also 921kBaud. Hier kann man also den Startwert einstellen. Ich habe hier 0x0F für 115200Baud hingeschrieben. Die Adresse ist 0x0308 im Programmcode bzw. 0x0328 im EEPROM. Die Formel zur Berechnung des Wertes lautet: (1,8432MHz / Baudrate)-1 Es gibt nur ein Problem: Ich habe keine Ahnung wie man den Wert am besten ins EEPROM bekommt. Es gibt zwar so nette Befehle wie SAVE DATA, aber wie man die Daten genau sendet, steht nirgends. Also habe ich das EEPROM per Hand (also per AVR) direkt programmiert: Die Adresse ist 0xAC und den Writecontrol Pin muss man auf Low legen, um Daten schreiben zu können.
Super Sache :-) Ich habe herrausgefunden die Baudrate kann über das Kommando ffffff01 geändert werden allerdings benötigt man am Anfang 921600Baud. Derzeit versuche ich das EEPROM über ein serielles Kommando dauerhaft zu beschreiben. Gruß Uli
Ja, das habe ich auch schon probiert. Der Befehl um Programmcode zu laden wird zumindest anscheinend nicht unterstützt. Im Moment versuche ich gerade den ffffff01 Befehl so umzuschreiben, dass man nicht nur 2^n Teilerfaktoren, sondern beliebige Faktoren senden kann. Die Standardbaudrate habe ich auf 19200 gestellt, das sollte maximale Kompatibilität bieten. Erhöhen kann man ja immer noch. Momentan habe ich nur noch das Problem, dass es irgendwo in der Software einen Vergleich gibt: Ist der 1. Parameter beim ffffff01 Befehl >9 wird ein NAK zurückgeliefert. Das muss ich noch entfernen. Dann lade ich hier fertige Hex Datei hoch, die nur noch irgendwie ins EEPROM kommen muss.
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
Wie versprochen, hier ist die Hex Datei für das EEPROM. Geändert ist folgendes: - Baudrate auf 19200 eingestellt - Parameter 1 von Befehl FFFFFF01 ist der Baudratenteiler, also (1,8432MHz / Baudrate)-1 Die Baudrate wird übrigends erst nach dem Ack auf diesen Befehl geändert.
gast wrote: > Wenn ich 0xff 0xff 0xff 0x0C 0x05 0x00 0x10 0x00 hinschicke bekomme ich > ein ACK Seltsam, ich nicht: TX Data: 0x0C, 0x05, 0x00, 0x10, 0x00 RX Data: 0x0F, 0x00, 0x00, 0x09, 0x00
Benedikt K. wrote: > Wie versprochen, hier ist die Hex Datei für das EEPROM. Geändert ist > folgendes: > - Baudrate auf 19200 eingestellt > - Parameter 1 von Befehl FFFFFF01 ist der Baudratenteiler, also > (1,8432MHz / Baudrate)-1 > Die Baudrate wird übrigends erst nach dem Ack auf diesen Befehl > geändert. Genial. :-) Man bräuchte nur noch ne tolle Schnittstelle um das EEPROM zu programmieren :|
Also bei mir ist definitiv was passiert beim Kommando 0C meine Kamera funktioniert nich mehr :-) mal schnell wieder flashen.
Seltsam. Bei mir reagiert die Kamera danach auch nicht wieder. Nach einem Sync geht es wieder. So wie ich das verstanden habe, beschreibt dieser Befehl nur den Programmcode RAM im OV528, nicht das EEPROM. Das EEPROM müsste man mit SAVE DATA 0A, 03 beschreiben können. Ich denke mal mit Serial Flash ist das EEPROM gemeint. Die nächsten 3 Paramter sind die Länge, aber wo kommen jetzt die Daten ?
Ich vermute mal im Befehl 0a so wie es beim lesen eines Registers gemacht wird????
Hi, wie gut das ich das Datenblatt besorgt habe (Habe übrigens direkt beim Hersteller angefragt und innerhalb von 5 Minuten haben die mir das zugemailt!) Das man die Baudrate mit dem x01 Befehl ändert hatte ich ja auch schon raus, es steht ja so im Datenblatt. Mein bisheriges vorgehen war auch erst einmal mit der hohen Baudrate connecten und dann runterschalten. Habt ihr dann bei der Übertragung mit 115200 auch ein vernünftiges Bild im Browser bekommen ? Meins sah leider etwas "zerzaust" aus ... Nächste Woche habe ich endlich Urlaub und kann mich dann auch etwas näher mit dem Eeprom-Beschreiben beschäftigen, aber auch nur wenn ihr das bis dahin das Problem nicht schon gelöst habt ;-)
Ich habe gerade ein paar unkomprimierte und auch jpeg Bilder mit 115200 und 19200Baud gemacht: Funktioniert wunderbar.
Mmhh. Hast Du schon die Werte im eeprom geändert, oder hast Du es vorerst noch "softwaremäßig" die baudrate in der cam geändert ? Ich bekomme unterhalb von 115,2 gar keine Verbindung zur Kamera. Vielleicht hat sie ja schon einen Tick weg, von der ganzen probiererei. Bei mir ist auch immer das erste Bild nach einem reset immer 1A und wird dann von Bild zu Bild immer schlechter..
Ich habe ein modifiziertes EEPROM, (die Version die ich hier hochgeladen habe). Die startet mit 19200 und danach stelle ich per (modifiziertem) INITIAL Befehl auf die andere Baudrate um. Das Verhalten klingt danach, als wenn noch irgendwo alte Daten im Puffer rumfliegen, die von Bild zu Bild einen größer werdenden Offset verursachen.
Benedikt: Perfekt. Mit 19200 Baud kann ich die Kamera (auch wenn langsam) an meinen mit 12MHz getakteten AVR hängen. Ich glaub ich muss mir mal so eine Kamera bestellen. Hast du schon eine gute Methode gefunden um das ROM-Image zu flashen? (Außer das schon angesprochen mit dem AVR Programmieren). Bei 19200Baud sollten immerhin noch 1,875kByte/s möglich sein. Sprich ~10Sekunden für ein 320x240 Bild. Akzeptabel würde ich sagen. PS: Ob der ENC28J60 auch noch mit 24,576 MHz funktioniert? Weiß da jemand wie genau die Toleranzen sind? Im Datenblatt steht auf Seite 81 etwas von 25MHz +/- 50ppm, was natürlich somit nicht möglich wäre. Wäre ja auch zu schade gewesen mit nur einem Quarz so weit zu kommen ;)
Angehängte Dateien:
-
CIMG4460.JPG
46 KB
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: http://cgi.ebay.de/Handy-Motorola-T720i_W0QQitemZ230217304509QQihZ013QQcategoryZ42573QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
> 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.
Michael wrote:
> Das wäre prima, wenn Du das Protokoll mitschneiden könntest.
Was soll das bringen ? Es ist doch bekannt, wie man die Kamera
ansteuert, und wie man im Datenblatt sieht, ist das Protokoll komplett
willkürlich wählbar, je nach Firmware des µCs.
@Ulrich: Ich hab nochmal eine Frage. Wenn ich jetzt über HTerm und meinen High-Speed USB-RS232 Wandler das Bild ausgelesen habe, wie füge ich dann am einfachsten JPEG-Header hinzu um mir das Bild direkt anschauen zu können? Beziehungsweise: Welchen JPEG Header hast du den Bilddaten vorangestellt?
Hallo, Es muß nichts mehr hinzugefügt werden, nur die ersten Längenbytes entfernen und fertig. Ich meine das waren die ersten 16Bytes. Gruß Uli
Ulrich Radig wrote: > Hallo, > > Es muß nichts mehr hinzugefügt werden, nur die ersten Längenbytes > entfernen und fertig. Ich meine das waren die ersten 16Bytes. > > Gruß > Uli Ich glaube ich habe mich etwas unverständlich ausgedruckt. Ich meinte, welchen JPEG Header ich voranstellen muss, um die Datei auf dem PC anschauen zu können. Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von den Längenbytes)
Simon K. wrote: > Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen > Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von > den Längenbytes) Du glaubst es vielleicht nicht, aber es ist genau so !!!
Benedikt K. wrote: > Simon K. wrote: > >> Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen >> Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von >> den Längenbytes) > > Du glaubst es vielleicht nicht, aber es ist genau so !!! Alles klar, dann kommt also das PC-JPEG kompatible Bild (mit allen Informationen zur Farbspeicherung und so weiter) direkt aus der Kamera. Danke! :D
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 ?
Hm. Ich hab hier den Wandler von Pollin. Die sind in der Regel alle gleich aufgebaut. Also entweder Prolific Chipsatz oder ein FTDI Chipsatz. Blöderweise ist bei dem Pollin Wandler direkt die RS232 Schnittstelle (ohne Umsetzer von TTL auf RS232 Pegel) aus dem Chip herausgeführt, sodass ich einen Pegelwandler brauche. Jedoch sind alle Versuche einen solchen zu bauen fehlgeschlagen. 1MHz sind nicht zu unterschätzen. Probiert habe ich es mit einem BC549 und unterschiedlich großen Pullup und Basiswiderständen. Keine Chance für einen Analog-Laien :-) Dann bastel ich mir erstmal eine kleine Platine für einen AVR und dann seh ich mal weiter. PS: Man kann übrigens auch ein 4poliges (Flachband-)Kabel an die Kameraplatine löten.
Das Problem bei solchen Wandlern ist der RS232 Teil: MAX232 usw. sind meist nur bis 115kBaud spezifiziert. Es gibt zwar einige die auch mehr können, aber die sind eher selten.
Jup, sag ich ja. Ich war zuerst zuversichtlich und hab meinen RS232 drangehangen und mich nur gewundert, was denn da zurückkommt. Kamera kaputt? Aber irgendwann hats dann auch Klick gemacht und dann ist es mir aufgefallen. Naja, Pegelwandler in der Geschwindigkeit für RS232 sind selten, richtig. Ulrich hat die Kamera an einen AVR angeschlossen und übertragt das Bild anschließend mit einer niedrigeren Geschwindigkeit zum PC :D
Hallo, Ich habe meinen USB nach RS232 TTL Wandler genommen zu finden auf meiner HP unter Projekte. Gruß Uli
Ich hab hier solche Wandler von ner ELV sammelbestellung, gabs als restposten für 1€ ;) Gehen auch bis knapp über 1MBaud
@Ulrich: Mir sind in der Zwischenzeit noch ein paar Fragen gekommen. EDIT: Hat sich schon weiter oben erledigt. Wer lesen kann ist klar im Vorteil ;) Ignoriert den Rest des Postings. in deinem Code wartest du immer in der Empfangs-Routine für ein Zeichen über das USART solange, bis du den entsprechenden 512Byte "Block" aus dem Picture-DatenStream herausgeholt hast. Wird dann ein Byte angefordert, dass zur Zeit nicht im Buffer liegt, dann wird erneut das Image abgerufen und wieder solange gewartet, bis der relevante Code-Block hereinkommt. Allerdings sagt das Datenblatt des C328 etwas anderes zu dieser Vorgehensweise: Man kann die Daten mit Get Picture anfordern, daraufhin sendet die Kamera, dass die Daten bereit zum senden sind und weiterhin noch die Länge der Daten. Anschließend kann man mit ACK Befehlen gezielt die Pakete anfordern. Bis man irgendwann die Paket-ID 0x5050 sendet. Dann hört die Kamera wohl auf. Warum hast du das nicht so gemacht? Ist das etwa in der DC3840 nicht implementiert? Schickt die DC3840 sofort ~15kB (Bei 320x240px) an Daten über ihren TxD Draht nach draußen ohne Rücksicht auf Verluste? Ich kann diese Vorgehensweise nur bei dem Uncompressed Picture finden. (Vermutlich weil der RAM der Kamera zu klein ist, um es zwischenzuspeichern)
>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.
Simon K. wrote: > Allerdings sagt das Datenblatt des C328 etwas anderes zu dieser > Vorgehensweise: > > Man kann die Daten mit Get Picture anfordern, daraufhin sendet die > Kamera, dass die Daten bereit zum senden sind und weiterhin noch die > Länge der Daten. > Anschließend kann man mit ACK Befehlen gezielt die Pakete anfordern. Der Befehlssatz ist nur ein Beispiel (steht auch dabei). In der Kamera läuft ein µC, der diesen Befehlssatz ausführt. Und der ist von Hersteller zu Hersteller der fertigen Kamera mehr oder weniger unterschiedlich, je nach Software im EEPROM. Mit direktem Zugriff auf die Register, sollte man das umstellen können. Ich habe dies aber noch nicht ausprobiert
Danke Benedikt. Das konnte ich nach dem gründlichen kompletten Lesen des Threads hier auch schon erfahren :-) Übrigens, der MAX3225 ist ein 2/2 RX/TX 1MBaud Wandler für RS232 verfügbar im DIP Gehäuse.
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 ;-)
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.
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.
Den hier: http://www.controllertechnik.de/software.html Er ist nicht der beste, aber anscheinend sind die Assemblertools vom 8051 am Aussterben. Ich habe die erzeugte Datei mal angehängt.
Hallo,
fur interessierten, Siemens Handy Camera IQP-500 510 ....
Camera Atmega oder PC
RTS muss 1 sein
AT&F<CR> 19200
OK<CR>
ATE0<CR>
OK<CR>
AT+CMEE=1<CR>
OK<CR>
AT^SACD=1<CR>
OK<CR>
AT^SACD=2,"17"<CR>
OK<CR>
AT^SACD=2,"17,00,2,IQP5 02.01"<CR>
OK<CR>
AT^SACD=2,"17,04,2,3"<CR> Ready status
^SACD: 17,04,2,1<CR> Fotografieren
AT^SACD=2,"17,04,OK"<CR>
OK<CR>
AT^SACD=2,"17,04,2,1"<CR>
OK<CR>
AT^SACD=2,"17,04,2,2,3490,34882"<CR> 3490 kleine Bilder, 34882
grosse
OK<CR>
^SACD: 17,01,2,1<CR> 1 klein, 2 gross
AT^SACD=2,"17,01,OK"<CR>
OK<CR> 19200
AT^SADT=1,115200<CR> 115200
rts Dateiubertragung ist mit
RTS geregelt ( < 100 Zeichen
)
CONNECT<CR> 115200
data 115200
OK<CR> 115200
rts
OK<CR> 19200
OK<CR> 19200
AT^SADT=2,"17,02,OK"<CR> 19200
OK<CR>
^SACD: 17,02,2<CR>
AT^SACD=2,"17,04,2,3"<CR>
============================================
mit Blitz
AT^SACD=2,"17,04,2,3"<CR>
ok
^SACD: 17,03,2<CR>
AT^SACD=2,"17,03,OK"
OK
Verspatung
AT^SACD=2,"17,04,2,1"
OK
AT^SACD=2,"17,04,2,3"<CR>
OK
^SACD: 17,04,2,2
AT^SACD=2,"17,04,OK"
OK
AT^SACD=2,"17,04,2,1" Fotografieren
Veiter ist das gleich
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
zitat : Hast Du vielleicht schon die Kommunikation in einem Programm umgesetzt? zitat ende. daran hätte ich auch interesse. gruss tom
Da es hier primär um die DC-3840 geht, würde ich zur IQP-500 diesen Thread vorschlagen: Beitrag "IQP500 Kamera vom S55 an AVR?" Dort gibts auch code...
So, ich habe jetzt mal die Kamera an einen Webserver gefriemelt, allerdings habe ich ein paar Probleme. Sende ich - Reset - Initial - Snapshot - 200ms warten - GetPicture dann läuft alles glatt. Aber wenn ich zu einem beliebigen Zeitpunkt nochmal - GetPicture sende, dann dauert es 7 Sekunden bis die Kamera die JPEG Daten rausschmeißt. Ist das ein bekannter Bug? Oder ist das korrekt? Ich glaube ja mal kaum. Ich habs sogar auf dem Speicheroszilloskop mir angeschaut. ~7sekunde nachdem das GetPicture Paket kommt, kommt das große Datenpaket. Jemand eine Idee dazu?
Scheint wohl als hätte noch niemand sonst die Kamera ausprobiert...
Hallo, Simon das kann nicht sein sind schon einige weg. Allerdings konnte ich dein Problem nicht nach vollziehen. Gruß Uli
Was mich übrigens ein bischen stutzig macht, ist, dass du in deinem Sourcecode die serielle Schnittstelle vom Mega644 nur mit 5 Bit betreibst..? Für eine 8Bit Schnittstelle muss 3<<UCSZ00 ins UCSRC Register geschrieben werden, wenn ich mich nicht irre. Und warum fügst du der Länge, die im DATA Befehl von der Kamera kommt 1 hinzu?
Steht im Datenblatt auf Seite 185 im 02/07 Datasheet vom Mega644 (Jaja, etwas antiquitiert): UCSZ01 und UCSZ00 müssen auf 1 sein für einen 8-Bit Transfer. Übrigens hast du auf dem Bild von der Kamera auf deiner Seite auch stehen, dass die Kamera keine Stoppbits braucht. Aber du meintest vermutlich Paritätsbits. EDIT: Ich seh schon, der Defaultwert von UCSRC setzt die beiden Bits automatisch, najo.
Ok, habe nun herausgefunden woran es lag: Ich habe die SendCommand Funktion etwas abgeändert, sodass der Befehl erneut geschickt wird, solange bis ein ACK kommt. (So wie in deinen Sourcen).. Gut, geht nun. Zugegeben eine etwas frickelige Kamera ;)
Mahlzeit, ich hab mir den Cam-Treiber mal nach Pascal übersezt, nun habe ich folgendes Problem: Init klappt, dann sende ich cam_picture_store:
1 | cam_send_cmd (0x08,0x01,0x00,0x00,0x00); |
2 | cam_send_cmd (0x10,0x01,0x00,0x00,0x00); |
3 | cam_send_cmd (0x12,0x00,0x00,0x00,0x00); |
4 | cam_send_cmd (0x18,0x01,0x00,0x00,0x00); |
5 | cam_send_cmd (0x17,0x00,0x00,0x00,0x00); |
6 | cam_send_cmd (0x21,0x03,0x00,0x00,0x00); |
7 | cam_send_cmd (0x01,0x01,0x07,0x19,0x13); |
8 | cam_send_cmd (0x05,0x00,0x00,0x00,0x00); |
9 | cam_send_cmd (0x04,0x01,0x00,0x00,0x00); |
Die Cam antwortet bis einschließlich 0x05 mit ACK, auf 0x04 antwortet sie mit NAK aber ohne Fehlernummer: FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 00 Hat jemand eine Vorstellung, woran das liegen könnte? Gruß Marco
Hallo, mein letztes Problem habe ich gelöst, war ein Fehler in der Int-Routine. Jetzt versuche ich die Baudrate zu senken, aber bisher ohne Erfolg. Wie genau muss der Befehl für die Baudrate aussehen? Laut Benedikt in 2 Aufrufen FFFFFF0104 Und dann FFFFFF0101 Das soll 115200 Baud bewirken. Sehe ich das richtig? Hat evtl Jemand das richtige Datenblatt zur Cam? Ich finde hier immer nur das Datenblatt zur C328. Grüße MArco
Marco Bajerski wrote: > Das soll 115200 Baud bewirken. > Sehe ich das richtig? Ja. > Hat evtl Jemand das richtige Datenblatt zur Cam? > Ich finde hier immer nur das Datenblatt zur C328. Ein Datenblatt zu dem Chip gibt es hier: http://www.mikrocontroller.net/attachment/30805/OV528_DS_1.3.pdf Der Rest ist kundenspezifische Software. Dazu wird man eher nichts finden.
Danke für die Info! Wenn ich die Baudrate mit: cam_send_cmd (0x01,0x04,0x07,0x09,0x05); cam_send_cmd (0x01,0x01,0x07,0x09,0x05); umstelle dann erhalte ich auf den ersten Aufruf von der cam ein ACK, auf den 2. Aufruf antwortet sie dann mit: 80 80 80 00 00 80 00 80 80 00 00 00 00 00 00 00 Es ist also etwas passiert, wenn ich anschließend den UART auf 115200 Baud umstelle, passiert aber garnix mehr. Was mache ich falsch?
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
Lass mal den zweiten Befehl weg, sende also nur cam_send_cmd (0x01,0x04,0x07,0x09,0x05);
Hallo, danke, jetzt klappts ;-) Aber auch mit geringerer Baudrate kommen immer noch fehlerhafte Bilder, die Cam treibt mich in den Wahnsinn. Gruß Marco
Was für eine Takteinstellung/Was für ein Quarz benutzt du?
Hallo, beides 014.745600. Hardwareproblem kann ich ausschließen, denn Ulis Version läuft 1A, nur mit meiner Pascal-Übersetzung haperts. Ungewöhnlich ist, dass ab und zu auch ein brauchbares Bild bei raus kommt.
Allerdings, bin gerade dahinter gekommen warum das so ist. Mein Pascal Compiler kann Longint weder multiplizieren noch dividieren, er rechnet dann mit integer, anstatt einen Fehler auszuspucken.
Moin 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.
Angehängte Dateien:
-
image1.gif
31 KB
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.
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
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 :
1 | X`<\0><17>JFIF<\0><1><1><1><1>,<1>,<\0><\0><\n>[<\0>C<\0><16><\f><\f><14><\f><\n><16><14><14><14><18><18><16><20><24>(<26><24><22><22><24>2$&<30>(:4><:488@H\N@DXF88PnRX`bhhh>Nrzpdx\fhd[<\0>C<1><18><18><18><24><22><24>0<26><26>0dB8BddddddddddddddddddddddddddddddddddddddddddddddddddD<\0><31><\0><\0><1><5><1><1><1><1><1><1><\0><\0><\0><\0><\0><\0><\0><\0><1><2><3><4><5><6><7><\b><9><\n><11>D<\0>5<16><\0><2><1><3><3><2><4><3><5><5><4><4><\0><\0><1>}<1><2><3><\0><4><17><5><18>!1A<6><19>Qa<7>"q<20>2<1><17>!<\b>#B1A<21>RQp$3br<2><9><\n><22><23><24><25><26>%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz<3><4><5><6><7><\b><9><\n><18><19><20><21><22><23><24><25><26>"#$%&'()*23456789:BCDEFGHIJRSTUVWXYZabcdefghijqrstuvwxyzD<\0><31><1><\0><3><1><1><1><1><1><1><1><1><1><\0><\0><\0><\0><\0><\0><1><2><3><4><5><6><7><\b><9><\n><11>D<\0>5<17><\0><2><1><2><4><4><3><4><7><5><4><4><\0><1><2>w<\0><1><2><3><17><4><5>!1<6><18>AQ<7>aq<19>"2<1><\b><20>B<17>!1A<9>#3Rp<21>brQ<\n><22>$4a%q<23><24><25><26>&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz<2><3><4><5><6><7><\b><9><\n><18><19><20><21><22><23><24><25><26>"#$%&'()*23456789:BCDEFGHIJRSTUVWXYZbcdefghijrstuvwxyz@<\0><17><\b><\0><\0><\0> <3><1>"<\0><2><17><1><3><17><1>Z<\0><\f><3><1><\0><2><17><3><17><\0>?<\0>`("<\n>H<16>"<\n>(<\0>"<\n>)<\0>QE<20>@("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n><\0>("<\n>@<20>QE<\0><20>QE<\0><20>QE<\0><20>QE0<\n>("<\0><\n>("<\0><\n>("<1> "<\n>)<\f>("<\n>`<20>QE <\n>("<24><5><20>QH<2><\n>( <2><\n>(&<1>E<20>P<1>E<20>P<1>E<20>P "<\n>)<\f>("<\n>`<20>QE<\0><20>QE <\n>("<\0><\n>("<24><5><20>Q@<5><20>QH<2><\n>(&<1>E<20>P "<\n>(<24>QE<20><\0>("<\n>`<20>QE <\n>("<\0><\n>("<\0><\n>("<24><5><20>Q@<5><20>Q@<5><20>Q@<2><\n>( h("<\n>@<20>QE<\0><20>QE<\0><20>QE<\0><20>QE<\0><20>QE0<\n>("<\0><\n>("<\0><\n>("<1><5><20>Q@<5><20>QHaE<20>P<1>E<20>P<1>E<20>P<1>E<20>P<1>E<20>S<\0>"<\n>(<\0>"<\n>(<3>Y<\0><\0>aq
|
was mir immerhin nicht komplett falsch erscheint. das "JFIF" in den ersten paar bytes scheint mir fuer einen jpg header typisch zu sein. ich las dass ich die ersten 16 bytes loeschen sollte ... habe ich auch probiert, das erste bis inc dem 16. das hat alles nicht dazu gefuehrt, dass diese daten als jpg interpretiert werden koennen. hat jemand eine ahnung wo der fehler liegen koennte ? mir erscheint der ganze datensatz auch relativ klein. ich habe jetzt noch nicht ueberprueft in welchem modus das programm von uli sdtmaessg ein bild aufnimmt. evtl ist es ja eine sehr geringe aufloesung. ich habe auch schon versucht die ersten paar bytes aus einem der anderen bilder die hier mit der camera gemacht und gepostet wurden zu ersetzen, das hat aber nur dazu gefuehrt, das irfan view sagte : "jpg datastream contains no image" ob das nun aber bei einem ersetzten header irgendwelche aussage hat weiss ich leider nicht. es kann ja sein, das der header aus dem funktionierendem bild den ich verwendet habe bei dem bild das ich gemacht habe einfach der falsche ist, weil andere farbeinstellungen/aufloesung oder was auch immer. ich verwendete "ÿØÿà JFIF" statt meinen ersten bytes. evtl hat sich ja schon jemand mit aehnlichen problemen konfrontiert gesehen. vielen dank fuer eure zeit.
Hallo, soweit ich weiß, werden die ersten 16 Bytes beim aktuellen Beispiel schon von der Software gelöscht. Lass dir das mal mit hterm im hex-Format ausgeben und dann speicher das ganze im RAW-Format, dann sollte es klappen. Die JPEG Files beginnen übrigens mit FF D8. Gruß Marco
aha. danke, das ist schonmal ein guter tip. jo ich habe das auch so wie von dir beschrieben mit hterm gemacht. aber leider kein erfolg. ich bin mittlerweile der meinung, das die daten schlicht nicht in dem bild vorhanden sind. ich habe aus ulis programm den softuart ausgetauscht gegen einen normalen uart (atmega 162 mit 2 uarts) und dabei ist mir wohl ein fehler unterlaufen. das nicht funktionieren unten beschriebener codezeile würde auch dazu passen, dass in meinem bild scheinbar keine daten vorhanden sind, sondern nur header und drumherum. ich habe jetzt um dem nachzugehen den modus der bildaufname auch mal von 160*120 auf 640*480 geschaltet. die erhaltenen daten bleiben in etwa gleich gross. das kann schonmal nicht angehen.
1 | //Ausgabe eines Bytes vom Bild
|
2 | char cam_data_get (unsigned long byte) |
3 | {
|
4 | byte = byte + 1; |
5 | unsigned long byte_tmp1 = byte / DAT_BUFFER_SIZE; |
6 | |
7 | if(byte < (cam_dat_start-CAM_HEADER) || byte >= (cam_dat_stop-CAM_HEADER)) |
8 | {
|
9 | cam_dat_start = CAM_HEADER + (byte_tmp1 * DAT_BUFFER_SIZE); |
10 | cam_dat_stop = CAM_HEADER + DAT_BUFFER_SIZE + (byte_tmp1 * DAT_BUFFER_SIZE); |
11 | |
12 | //request Data
|
13 | //PORTD |= (1<<6);
|
14 | UCR =(1<< RXC1);//<-- hier bin ich mir nicht sicher. |
15 | |
16 | cam_command_send (0x04,0x01,0x00,0x00,0x00); |
17 | for(unsigned long a = 0;a<100000;a++){asm("nop");}; |
18 | }
|
19 | byte = byte % DAT_BUFFER_SIZE; |
20 | |
21 | return (cam_dat_buffer[byte]); |
22 | }
|
die eine zeile von uli habe ich mal auskommentiert. die hatte ich bishher noch nicht ersetzt durch eine fuer den normalen uart passenden zeile (uart1 in meinem fall fuer die camera). nun weiss ich nicht, was nach ulis softuart mit diesem D6 da eigentlich gemacht wird. der D5 scheint ja der über software emulierte TX pin zu sein. ist der D6 dann als RX pin geplant ? das steht da so explizit leider nirgends. oder aus welchem grund wird hier D6 gesetzt ? wie muesste das für einen normalen uart ausschauen ?
wer 7 statt 8 databits einstellt, der darf sich ueber datenmuell nicht wundern.... ich poste den code fuer 2 uart controller an einem atmega spaeter sobald ich ihn bereinigt habe. es laeuft jetzt. danke.
Moin. Mein aktuelles Problem ist nun, dass ich 2 Bilder hintereinander machen möchte und zwar in Graustufen. Diese beiden Bilder möchte ich dann pro Pixel in Ihren Helligkeitswerten auf einem AVR voneinander abziehen. Die daraus Resultierende Matrix aus Grauwerten soll dann weiter verarbeitet werden. Es ist in diesem Fall nicht wichtig, dass diese Matrix noch irgendein Bildformat hat. Dazu stellt sich jetzt die Frage wie ich das am besten machen. A) ich verwende jpg Dekomprimierungsbibliotheken für c um an die Grauwerte der einzelnen Pixel zu kommen B) ich lasse mir von der Kamera direkt ein Bild übertragen welches unkomprimiert die Grauwerte in einer Matrix enthält. zu B habe ich leider noch keine möglichen Kameraeinstellungen gefunden. Ist da jemand schon weiter? ich habe es bisher mit
1 | cam_command_send (0x05,0x01,0x00,0x00,0x00);//snapshot, UNcompressed |
probiert, bin mir aber bei der interpretation der Daten nicht sicher. Es werden viel weniger Bytes bei gleicher Auflösung zurückgegeben als bei einem komprimierten Bild, das kann ja schonmal nicht sein.... zu A) fehlt mir im Moment eine Bibliothek zum dekomprimieren von .jpg Dateien. Diese finden sich zwar haufenweise für c++ aber so gut wie nicht fuer c. Hat jemand ähnliches Probiert oder einen Tip ? Danke für Eure Zeit
Moin 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
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.
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
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
Hi Das Datenblatt zum OV528 wurde schon in diesem Thread gepostet! Oder aber auch bei Uli im Forum.
@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
an: Timebeast (Gast) Ich Arbeite mit der C328R hier fangen die commandos immer mit AA an.
Hallo Ich versuche gerade die DC-3840 an einen PIC18F2550 zu hängen und Bilder über die USB-Schnittstelle zum PC zu übertragen. Der USB Stack läuft und ich kann bereits mittels MPUSBAPI Daten im Burstmode vom PC zum PIC und zurück übertragen. Momentan versuche ich das Kameraprotokoll in eine State-Maschiene zu packen. Diese soll in einer Endloschleife gepollt werden. Jetzt frage ich mich wann die Kamera genau mit einem ACK antwortet? ??? ??? sind die Stellen bei denen ich mir nicht sicher bin. Bei der Synchronisation scheint es klar zu sein. PIC->CAM : SYNC solange bis ACK von CAM CAM->PIC : ACK CAM->PIC : SYNC PIC->CAM : ACK Dann die Initalisierung PIC->CAM : RESET ??? CAM->PIC : ACK ??? PIC->CAM : INIT ??? CAM->PIC : ACK ??? Dann Bilder abrufen PIC->CAM : SNAPSHOOT ??? CAM->PIC : ACK ??? PIC->CAM : Get Picture Bilddatenübertragung CAM->PIC : Data CAM->PIC : Bilddaten [x Bytes] ??? PIC->ACK : ACK ??? Dann zurück nach Bild abrufen. Grüße und vielen Dank Dirk PS: Nachdem ich mir das Datenblatt noch einmal angesehen habe, beschäftigen mich die Fragen in meinem obrigen Post [[Beitrag "Re: Protokoll DC-3840 Handycam"]] immer noch.
Dirk F. wrote: > Jetzt frage ich mich wann die Kamera genau mit einem ACK antwortet? > ??? ??? sind die Stellen bei denen ich mir nicht sicher bin. Nach jedem Befehl entweder mit einem ACK oder NACK.
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.
Hallo, ich fange auch gerade mit der Cam an, nur leider bekomme ich als antwort auf den Sync immer nur "0C 80 80 80". Momentan hängt mein Aufbau an einem MAX3225 und darüber am PC, am PC lese ich mit HTerm. Ich schicke "FF FF FF 0D 00 00 00 00" zur Cam, mehrmals, und erhalte iwann genauso oft "0C 80 80 80" als Antwort, wie ich zuvor "FF FF FF 0D 00 00 00 00" gesendet hab. Dass es immer bisschen dauert liegt iwie an der Verbindung HTerm mit meiner RS232 Karte, Windows Hypterterminal geht einandfrei, da empfange ich alles sofort, nur leider kann ich da keine Hex-Eingaben machen. Ne Idee an was es liegen könnte? Loopback nach dem MAX3225 zurück zum PC zeigte eine einwandfreie Übertragung. Kamera läuf wie der MAX an 5V. MFG µLuxx
Hi, mich beschäftigt das Thema auch schon 'ne ganze Weile und verstanden habe ich dieses Ding noch nicht so ganz. Das, was du da schilderst, habe ich auch so erlebt, als ich die Kamera mal direkt an einen PC durchgereicht habe. Mit Hterm habe ich im Übrigen auch gute Erfahrungen gemacht, das Bray-Terminal hat ein Datendurchsatzproblem und verschluckt gerne etliche Bytes. Ich benutze mittlerweile einen virtuellen COM-Port via USB (FTDI 245), damit man überhaupt über 115200 hinaus kommt. Was ich bislang festgestellt habe ist, dass das Timing schon sehr scharf ist und entsprechend bedient werden muss. Man kann sehr leicht asynchron werden. Und dann klappt einfach nix. Zudem kann ich die Ausführungen hier im Thread als auch die von Ulrich auf seiner Homepage nicht alle so ganz nachvollziehen. Ich habe es bislang z.B. noch nicht hinbekommen, dass die Kamera mit weniger als 230400 Baud sauber funktioniert. Dann scheint es 18 Bytes und nicht 16 Bytes nach Senden des Get-Pic-Befehls zu dauern, bis das JPG-Bild kommt - so ist es jedenfalls bei mir. Ich frage mich mittlerweile, ob diese Kamera es wert ist, soviel Zeit damit zu verbringen. Gibt's nicht noch was Besseres?
Hallo @µluxx Möglicherweise liegt das Problem an der Datenleitung von der Kamera zum PC. Bei mir erreicht die Spannung für den High Pegel der Kamera ca. 2,6V. Für den Input-Pin der UART in meinem PIC ist das zu wenig. Die UART hat CMOS-Schmitttrigger Eingangsstufen (Highpegel = 5V * 0,7) und keinen TTL-Eingang, da wäre der High-Pegel 2V. Deshalb scheint es auch mit einem MEGA zu funktioniern. Ich habe zwei 74 HCT 04 Inverter (nicht HC) in Reihe an den Ausgang der Kamera gelegt. Die haben TTL-Inputs und CMOS Outputs. Beim MAX3225 ist der Input Logic Threshold High (bei Vcc = 5V) = 2,4V. Je nach dem wäre es vielleicht ratsam den Baustein mit 3,3V zu betreiben, da sind es dann 2V. Je nachdem was für ein Spannungsabfall auf den Leitungen dazu kommt und sich die Sache bei 900kbit verhält. Grüße Dirk
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!
also daran lag es nicht, ich habe eher den verdacht dass es iwie an meiner rs232 karte liegt, ich hab mir jetzt nen MBaud USB-RS232 wandler gekauft, mal schaun was der bringt...
Hallo, die letzten Nächte habe ich mit der Kamera von Ulrich Radig und einem ATmega32 auf dem STK500 verbracht und sind schon fast Freunde :-) 0) Was geht... JPEG-Snapshot und Übertragung mit der SoftUART zum Windows-PC, allerdings nur mit 34800 Baud. Habe dazu die alte CAM_Testsoftware (01/2008) mit dem Code aus dem aktuellen Webserver-Projekt aktualisiert. Empfang und Anzeige des JPEG-Bildes auf dem PC mit einem kleinen selbstgeschriebenen Tool: -> ca. 6s/Frame (0.17fps) bei JPEG@320x240 color low_compression Ich dachte es läge an der SoftUART. Wenn ich aber die Daten nicht übertrage, sondern nur ins Leere laufen lasse, dann braucht die Schleife mit cam_data_get(a) aber trotzdem noch ca. 4 Sekunden. Das ist nicht unbedingt das was ich erwartet hatte. Woran kann das liegen? STK500? SoftUART? Kamera defekt? Oder ist das Auslesen eines Snapshots immer so langsam? 1) max. sinnvolle Baudrate der SoftUART Ist vermutlich nicht die Lösung zu obigem Problem, aber welche max. Baudrate konntet Ihr bei Euch einstellen? 2) Unterschied Preview vs. Snapshot Ich habe es noch nicht geschafft ein Preview richtig auszulesen. Wozu braucht man es? Was ist der Unterschied zum Snapshot? Ich vermute beim Preview wird kein Bild im Speicher der Kamera abgelegt wie beim Snapshot. Ist der Datenstrom fortlaufend oder nur ein Bild? Ist die Qualität schlechter? Ist die Übertragung schneller, siehe Punkt 0)? 3) Preview, uncompressed 8Bit gray (kein JPEG!) Habe ich noch nicht geschafft auszulesen. Der Datenstrom über die SoftUART ist sehr lang. Zunächst dachte ich, dass fortlaufend Previews gesendet werden, aber nach etlichen Sekunden ist es vorbei. Ich bastel mir das was ich empfange in eine PGM-Datei. Manchmal sieht es so aus als wären dort Bruchstücke eines Bildes drin. Ist die SoftUART zu langsam? Vielen Dank Gruß Jörg
Angehängte Dateien:
-
forum_2.jpg
9,2 KB
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
1 | unsigned long cam_preview (char mode) |
2 | {
|
3 | unsigned long bytes = 0; |
4 | unsigned long timeout = 300000; |
5 | |
6 | |
7 | // Initialisierung
|
8 | //////////////////////////////////////////////////
|
9 | cam_command_send (0x08,0x01,0x00,0x00,0x00); // Reset |
10 | cam_command_send (0x10,0x00,0x00,0x00,0x00); // Compression (0:low, 2:high) |
11 | cam_command_send (0x12,0x00,0x00,0x00,0x00); // Light (0:day, 1:night) |
12 | cam_command_send (0x18,0x01,0x00,0x00,0x00); // Zoom 0:2x, 1:normal) |
13 | cam_command_send (0x17,0x01,0x00,0x00,0x00); // Color (0:color, 1:grey) |
14 | cam_command_send (0x21,0x03,0x00,0x00,0x00); // ??? |
15 | |
16 | cam_command_send (0x01,0x01,0x03,0x03,0x03); |
17 | |
18 | cam_command_send (0x04,0x02,0x00,0x00,0x00); |
19 | |
20 | cam_dat_start = CAM_HEADER; |
21 | cam_dat_stop = CAM_HEADER + DAT_BUFFER_SIZE; |
22 | |
23 | while((cmd_buffercounter) < CMD_BUFFER_SIZE && (timeout--) != 0); |
24 | |
25 | bytes = (unsigned long)cam_cmd_buffer[13]; |
26 | bytes+= ((unsigned long)cam_cmd_buffer[14]<<8); |
27 | bytes+= ((unsigned long)cam_cmd_buffer[15]<<16); |
28 | |
29 | return(bytes+1); |
30 | }// cam_preview() |
2) Lesen der Preview-Daten
1 | char cam_data_get (unsigned long byte) |
2 | {
|
3 | byte = byte + 1; |
4 | unsigned long timeout = 300000; |
5 | unsigned long byte_tmp1 = byte / DAT_BUFFER_SIZE; |
6 | |
7 | if(byte < (cam_dat_start-CAM_HEADER) || byte >= (cam_dat_stop-CAM_HEADER)) |
8 | {
|
9 | cam_dat_start = CAM_HEADER + (byte_tmp1 * DAT_BUFFER_SIZE); |
10 | cam_dat_stop = CAM_HEADER + DAT_BUFFER_SIZE + (byte_tmp1 * DAT_BUFFER_SIZE); |
11 | |
12 | cam_command_send (0x04,0x02,0x00,0x00,0x00); |
13 | |
14 | while(cmd_buffercounter<cam_dat_stop && cmd_buffercounter<max_bytes && (timeout--) != 0); |
15 | |
16 | }
|
17 | byte = byte % DAT_BUFFER_SIZE; |
18 | return (cam_dat_buffer[byte]); |
19 | }
|
3) Aufruf aus der Main
1 | void GetSnapshot(void) |
2 | {
|
3 | max_bytes = cam_preview(0); |
4 | |
5 | // subsampling
|
6 | int ss =4; // subsampling-Faktor |
7 | bytes_to_send /=ss*ss; |
8 | |
9 | // subsampling in Zwischenspeicher
|
10 | char* pBuffer =NULL; |
11 | int i =0; |
12 | int col =0; |
13 | int row =0; |
14 | if ( NULL!= (pBuffer=(char*)malloc(bytes_to_send)) ) |
15 | {
|
16 | // Daten in Buffer ablegen
|
17 | for(unsigned long a=0;a<max_bytes;a++) |
18 | {
|
19 | col =a%160; // Bildspalte x |
20 | row =a/160; // Bildzeile y |
21 | |
22 | // subsampling-Maske = 8x8 Block
|
23 | if ( 0==col%ss && 0==row%ss ) |
24 | pBuffer[i++] =cam_data_get(a); |
25 | }
|
26 | }
|
27 | |
28 | // UART
|
29 | //////////////////////
|
30 | if ( NULL!=pBuffer ) |
31 | {
|
32 | // Buffer senden
|
33 | for(i=0;i<bytes_to_send;i++) |
34 | {
|
35 | uart_write_char(pBuffer[i]); |
36 | }
|
37 | |
38 | free(pBuffer); |
39 | }
|
40 | |
41 | }// GetSnapshot() |
Lasse ich nun in 2) cam_data_get() die zeile
1 | cam_command_send (0x04,0x02,0x00,0x00,0x00); |
weg, so ist es sehr schnell (ca. 1 s) aber die Daten sind nicht korrekt (siehe Anhang). Wofür ist dieses nochmalige Anfordern gut? Ich hoffe, mir kann jemand weiterhelfen. Anscheinend kann es ja auch anders gehen, wie ich hier im Thread gelesen habe. Vielen Dank für Eure Hilfe. Gruß Jörg
Hallo, man merkt, dass Herbstferien sind :-) Ein 160x120 Preview (8Bit Grey) mit cam_data_get() zu holen benötigt leider immer noch ca. 17 Sekunden. Ich verwende cam_command_send (0x01,0x01,0x03,0x03,0x03); Heute konnte ich die Kommunikation der UART auf einem Oszilloskop verifizieren: es scheinen wirklich 921600Baud zu sein, daran liegt es also nicht. @Uli et. al. Da hier im Forum noch viele Fragen unbeantwortet blieben und auch sonst im www kein HowTo gefunden habe, wäre es super, wenn jemand folgende Aussagen bestätigt oder kommentiert: A) Ein Preview wird nicht im Kameraspeicher abgelegt, sondern sofort übertragen? B) Was ist ein uncompressed snapshot picture? Unkomprimiertes JPEG oder Rohdaten? C) Unkomprimierte Bilder (Rohdaten, z.B. (Bit Gray) können nur als Preview übertragen werden? (siehe B) C) Ein Preview wird nicht als einzelne Pakete gesendet, sondern am Stück? D) Ist es möglich, wie in dem C328 User Manual beschrieben, auch bei der DC-3840 eine Paketgröße mit Kommando cam_command_send (0x06,0x08,0x00,0x0X,0x00); anzufordern und dann die einzelnen Paket zu quittieren? Wenn ja, geht das auch mit unkompressed Daten (z.B. 8Bit Gray)? E) Die cam_get_data(a) Funktion schaut, ob das angeforderte Byte a aktuell im Buffer cam_dat_buffer[] vorhanden ist? Wenn a bereits von der Kamera gesendet worden ist (aber nicht mehr im Buffer vorhanden) oder noch nicht gesendet wurde, dann wird ein neues Bild angefordert. F) Warum war in früheren Code-Versionen von Uli CMD_BUFFER_SIZE 16, aktuell sind 17 eingestellt? Fragen über Fragen. Bisher habe ich die Kamera nur ausgeliehen, aber es sollte schon laufen bevor ich solche Kameras kaufe. Vielen Dank nochml. Für irgendeine Antwort wäre ich immer dankbar. Gruß
Hallo @ Jörg zu D. Wenn ich es richtig verstanden habe, wird nicht wie bei der C328 Blockweise übertragen, sondern immer das ganze Bild. Daraus wird dann je nach Größe des Pufferspeichers ein Teil herausgegriffen und anschießend versandt. Der Rest der Über- tragung wird ignoriert. Also Datenmenge = (Bildgröße / Puffergröße) * Bildgröße Daher die langen Übertragungsdauern. Grüße Dirk
Hallo, 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
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
1 | for(unsigned long a=0;a<max_bytes;a++) |
2 | {
|
3 | test =cam_data_get(a); |
4 | }
|
es dann schneller geht, aber hier dauert es trotzdem in etwas so lange. Kann es sein, dass ich dann zu schnell bin und cam_data_get() auch ein neues Bild anfordert, wenn dieses betreffende 'a' noch nicht gesendet wurde? Hier werde ich morgen mal näher hinschaun. Vielen Dank nochmal und vielleicht weiß ja noch jemand auf die anderen Fragen Rat. Grüße an alle Jörg
Hallo allerseits, so, viele Nächte sind vorüber... Es läuft mittlerweile ganz gut. Die Funktion cam_data_get() gibt es bei mir allerdings nicht mehr. In der ISR speichere ich nun die einkommenden Daten in 2 Zeilenbuffer (immer abwechselnd). Im main() kann ich dann auf das fertige Zeilenbuffer zugreifen, natürlich hat man da nur soviel Zeit wie die Zeile gültig ist. Das reicht z.Zt. für ein einfaches Downsampling mit arithm. Mittelwert oder aber auch für 2 einfache Sobel-Kantenoperatoren, also d/dx bzw. d/dy. Durch diese Einschränkung (kein externes SRAM, keine 2. UART) schaffe ich dann allerdings auch das ganze Bild in einem Rutsch zu verarbeiten, d.h. das was die 921600 kBaud hergeben ( Was mir allerdings noch aufgefallen ist: beim Preview ist die Belichtungssteurung doch sehr am Schwingen. Habt Ihr das auch beobachtet? Das war auch unschön bei der cam_data_get(), da die Helligkeit der Teilbilder (wenn Daten neu angefordert werden) variiert. Vielleicht war das auch das Problem bei Marco Bajerski (earlyperl). Grüße Jörg
hi, kann man die cam auch an einen comport vom pc direct anschliessen? mfg mentox
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
Hi, ja ist mir klar, aber wie machst du es, dass die ersten 16 byte nicht mitkonvertiert werden? mfg
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
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ß
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
Hallo, Kennt ihr einen Konverter, mit dem ich aus der empfangenen Hex-datei wieder ein jpg machen kann? (also hex to raw?) mfg
Hallo Wie hast du es gemacht. Ich hänge gerade auch dabei, die Hex-Daten ein JPG zu machen gruess Doc
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.
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
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.
Hi nochmal, meine Kamera steht schon fast 1 Jahr auf meinem Werktisch. Daneben das STK500. Mich wundert es, dass die Kinder noch nicht an den Kabeln gezogen haben :-) Ich hoffe, dass ich irgendwann wieder Zeit habe dafür. Wenn es Tool gibt, wäre ich natürlich auch interessiert... Ich habe den Thread in meiner Benachrichtungsliste, d.h. ich bekomme eine email, wenn es einen neuen Beitrag gibt. Ansonsten noch schöne Feiertage und einen guten Rutsch! Grüße Jörg
Hi 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
Hi, gibt es auch die moeglichkeit die cam an zwei normale I/O pins zu haengen .. oder muss es zwingen uart sein .. hab naemlich kein uart :-( gruesse dominique
Hallo Dominique, theoretisch könntest Du das vielleicht auch mit einer Soft-UART hinbekommen. Ich schätze aber, dass Du so keine 9xx kBit/s hinbekommst. Ansonsten dauert der Datentransfer halt wirklich lange... Ich bin mir jetzt nicht sicher, ob es nicht sogar eine Mindest-Rate für die Cam gibt, oder eine Default-Rate (9xx kBit/s ?), die man dann runtersetzen kann. Ist schon so lange her... Grüße Jörg
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.