-
In eigener Sache!
Liebe Mitglieder, liebe Besucher und Gäste
ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
Bitte hier weiterlesen ... -
DSLR-Forum Fotowettbewerb neu erfunden!
Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen. -
Neuer Partner: AkkuShop.de
Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2024
Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
Thema: "Sprichwörtlich"
Nur noch bis zum 30.04.2024 23:59!
Jeder darf abstimmen!
Zur Abstimmung und Bewertung hier lang
WERBUNG
Gast_4334
Guest
Nein, ist meine Experimentier-5D und auch mein 50er, da nur mein 50er die neue Platine intus hat, bei der 1er und nicht 1er AF getrennt justiert werden können.
Aha
Ich hab mir gedacht hier sind schlaue Leute anwesend, vielleicht will ja jemand beim Rätseln mit machen. Hier also der AF relevante Dump bei einem 300/4,0. Im Dump sind 5 Blöcke, die bei unterschiedlicher Entfernungseinstellung angenommen wurden, angefangen bei Unendlich bis in den Nachbereich.
Hier was ich schon weiß:
Kamera 160 -> gib mir aktuelle Brennweite: Anwort ist 1 44 (die beiden Int8 Werte werden in einen Int16 gewandelt und schon ergibt das 300mm)
Kamera 228 -> keinen blassen Dunst. Der Wert ist unabhängig von Fokus und Brennweite.
Kamera 178 -> nicht bekannt, ist aber ein Wert der sich bei Zooms mit der Brennweite ändern kann.
Kamera 196 -> fordert Entfernungseinstellung für ETTL2 an: Antwort sind 4x Int8 Werte. Je zwei Werte werden in Int16 gewandelt und gibt den Bereich an, in dem das Objektiv gerade steht. Beispiel: 1 97 1 4 -> 353 260 (das Objektiv steht also im Bereich zwischen 2,6 und 3,53m)
Kamera 176 -> fordert Blendenwerte vom Objektiv an (hab ich oben schon erwähnt)
Kamera 248 -> der AF 5,6 Justagewert. Das ist der einzige Wert, der sich durch Justage verändern lässt.
Kamera 224 -> wahrscheinlich Lens Extension Value. Das sollte der wichtigste Wert sein, wenn es um die Umrechnung Phasendifferenz nach Motorschritte geht.
Kamera 234 und 232 -> wahrscheinlich Lens Extension Correction Value. 234 wird von der Kamera verwendet wenn es in den Nahbereich fokussieren soll, 232 wenn es Richtung unendlich geht.
Wenn also jemand eine zündende Idee hat wie die Werte zu interpretieren sind oder einen Zusammenhang sieht, immer raus damit.
Hier was ich schon weiß:
Kamera 160 -> gib mir aktuelle Brennweite: Anwort ist 1 44 (die beiden Int8 Werte werden in einen Int16 gewandelt und schon ergibt das 300mm)
Kamera 228 -> keinen blassen Dunst. Der Wert ist unabhängig von Fokus und Brennweite.
Kamera 178 -> nicht bekannt, ist aber ein Wert der sich bei Zooms mit der Brennweite ändern kann.
Kamera 196 -> fordert Entfernungseinstellung für ETTL2 an: Antwort sind 4x Int8 Werte. Je zwei Werte werden in Int16 gewandelt und gibt den Bereich an, in dem das Objektiv gerade steht. Beispiel: 1 97 1 4 -> 353 260 (das Objektiv steht also im Bereich zwischen 2,6 und 3,53m)
Kamera 176 -> fordert Blendenwerte vom Objektiv an (hab ich oben schon erwähnt)
Kamera 248 -> der AF 5,6 Justagewert. Das ist der einzige Wert, der sich durch Justage verändern lässt.
Kamera 224 -> wahrscheinlich Lens Extension Value. Das sollte der wichtigste Wert sein, wenn es um die Umrechnung Phasendifferenz nach Motorschritte geht.
Kamera 234 und 232 -> wahrscheinlich Lens Extension Correction Value. 234 wird von der Kamera verwendet wenn es in den Nahbereich fokussieren soll, 232 wenn es Richtung unendlich geht.
Wenn also jemand eine zündende Idee hat wie die Werte zu interpretieren sind oder einen Zusammenhang sieht, immer raus damit.
Siehste genau das meinte ich mit Hex und Dez. Hättest du geschrieben dass 0x01 0x61 bzw. 0x0161 gesendet wird wäre das viel einfacher zu errechnen gewesen. Wir haben bei uns in der Firma auch Leute die alles in dezimal sagen, da kommt man als Hardwaremensch echt nicht mir klar.
Irgendwie ist mir die Formatierung deines Dumps auch nicht ganz einleuchtend. Oben ist das was das Objektiv sendet und unten das von der Kamera. Aber da wo jemand was nicht sendet hast du eine "0" gemacht, richtig? Das ist sehr verwirrend, und führt auch zu Interpretationsfehlern. Zudem sieht es so aus, als wenn Kamera und Objektiv z.B. als erstes gleichzeitig senden?!
Könntest du von 50er auch noch mal ein Dump mit gleichen Einstellungen machen?
Und was ist mit der Blende?
Zuletzt bearbeitet:
Die Datei hat 5 Doppelzeilen (jede Entfernungseinstellung eine). Kamera und Objektiv senden immer gleichzeitig, d.h. eine Antwort auf einen Kamerabefehl kann man erst im nächsten Datenpaar erwarten.
88
160
ist damit das erste byte im Block das gesendet/empfangen wird. 88 kommt vom Objektiv (ist noch die Antwort vom vorherigen Befehl) und 160 ist der neue Befehl von der Kamera. Also nächstes wird
1
0
gesendet. 1 ist der erste Teil der Antwort vom Objektiv und 0 kommt von der Kamera, da sie auf den Befehl 160 zwei byte als Antwort erwartet. Die Kamera dreht also kurz Däumchen.
44
228
Während das Objektiv das letze byte sendet, kommt von der Kamera zeitgleich schon der neue Befehl 228.
Ich hoffe nun wird es klarer. Das ist die Darstellung die damals aus meinem Logicanalyzer so raus kam und die hab ich einfach übernommen.
88
160
ist damit das erste byte im Block das gesendet/empfangen wird. 88 kommt vom Objektiv (ist noch die Antwort vom vorherigen Befehl) und 160 ist der neue Befehl von der Kamera. Also nächstes wird
1
0
gesendet. 1 ist der erste Teil der Antwort vom Objektiv und 0 kommt von der Kamera, da sie auf den Befehl 160 zwei byte als Antwort erwartet. Die Kamera dreht also kurz Däumchen.
44
228
Während das Objektiv das letze byte sendet, kommt von der Kamera zeitgleich schon der neue Befehl 228.
Ich hoffe nun wird es klarer. Das ist die Darstellung die damals aus meinem Logicanalyzer so raus kam und die hab ich einfach übernommen.
Hier die Antwort von ein paar Objektiven auf die Anfrage 228:
50/1,8II: 36 122
50/1,4: 37 231
300/4,0: 167 127
300/4,0IS: 166 30
85/1,8: 160 244
85/1,2: 160 244
24-105: 158 149 (unabhängig der eingestellen Brennweite)
Mhh, interessant ist ja auf jeden Fall schonmal, dass die beiden 85er das gleiche zurückmelden. Die beiden 300er und die beiden 50er liefern zumindest beim ersten 8-Bit Wert, Werte die um "1" von einander abweichen. Hast du noch 50 f/1.2 da, oder das 50er Sigma?
Also uint_16 ergeben die Werte auch nicht wirklich Sinn (echt umständlich mit dem ständigen Umrechen von u8 in u16, in hex könnte man das einfach so eingeben...)
9338
9703
42879
42526
41204
41204
40597
Was aber auffällt ist, dass bei den letzten 5 Objektiven (also alle außer die beiden 50er) das MSB (2^7 beim ersten Byte) 1 ist. Also entweder Vorzeichen, oder ein Status/Info-Bit (z.B. ich habe Ring USM oder so)
EDIT:
Wenn man das MSB vom ersten Byte ignoriert bekommt man folgende Werte
36
37
39
38
32
32
30
Vielleicht auch mal binär betrachten
0010 0100 0111 1010
0010 0101 1110 0111
1010 0111 0111 1111
1010 0110 0001 1110
1010 0000 1111 0100
1010 0000 1111 0100
1001 1110 1001 0101
Es könnte sich zumindest zum Teil um Objektiveigenschaften handeln ala USM, IS etc. z.B. ist beim einzigen Zoom-Objektiv in der Reihe das 2^4-Bit im ersten Byte gesetzt.
Also uint_16 ergeben die Werte auch nicht wirklich Sinn (echt umständlich mit dem ständigen Umrechen von u8 in u16, in hex könnte man das einfach so eingeben...)
9338
9703
42879
42526
41204
41204
40597
Was aber auffällt ist, dass bei den letzten 5 Objektiven (also alle außer die beiden 50er) das MSB (2^7 beim ersten Byte) 1 ist. Also entweder Vorzeichen, oder ein Status/Info-Bit (z.B. ich habe Ring USM oder so)
EDIT:
Wenn man das MSB vom ersten Byte ignoriert bekommt man folgende Werte
36
37
39
38
32
32
30
Vielleicht auch mal binär betrachten
0010 0100 0111 1010
0010 0101 1110 0111
1010 0111 0111 1111
1010 0110 0001 1110
1010 0000 1111 0100
1010 0000 1111 0100
1001 1110 1001 0101
Es könnte sich zumindest zum Teil um Objektiveigenschaften handeln ala USM, IS etc. z.B. ist beim einzigen Zoom-Objektiv in der Reihe das 2^4-Bit im ersten Byte gesetzt.
Zuletzt bearbeitet:
Diese Seite hier könnte die Suche nach der Bedeutung einiger Kommandos erleichtern. Daraus ist zumindest erkennbar, was eine EOS-Linse so an Kommandos versteht ...
Den Adapter hab ich da, bringt einen aber nicht weiter. Das sind auch die Befehle mit denen der Computer mit dem Controller im Adapter spricht, was dann zum Objektiv raus geht ist was anderes.
Ganz nebenbei, dass der Adapter funktioniert hat mit der Gutmütigkeit vom EOS Protokoll zu tun. Wie der Handshake über die Clockleitung funktioniert hat der Hersteller nicht so ganz umrissen.
Ganz nebenbei, dass der Adapter funktioniert hat mit der Gutmütigkeit vom EOS Protokoll zu tun. Wie der Handshake über die Clockleitung funktioniert hat der Hersteller nicht so ganz umrissen.
Das ist mir schon klar, dass das Kommandos für die RS232 sind und nicht die am SPI-Bus. Was man mit dieser Sammlung aber machen kann: da du den Adapter ja hast, kannst du dessen Kommandos einmal durchspielen und schauen, was du alles erkennst. Was auch immer dann sonst noch zwischen Kamera und Linse herumfliegt, müsste dann zumindest was anderes tun als die Birger-Kommandos.
wir haben im CHDK Forum auch nen Thread zu dem Thema, vielleicht gibt es da neue Informationen für euch: http://chdk.setepontos.com/index.php/topic,1331.0.html
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
das es so kompliziert ist habe ich nie gedacht weil ja schon Canon Linsen ans Sigma Bajonett gepflanzt wurden, also muss die "normale" Komunikation erst mal Standard (SPI) sein, sogar die Daten scheinen erst mal zu passen sonst wäre das nicht möglich.
Die immer wieder vielzitierte geheimnissvolle Canon Verschleierungstaktik (alte inkompatible Sigmas) ist IMHO nix weiter als TTL zu CMOS, wobei CMOS Chips eben viel spannungstoleranter sind, ich tippe Canon hatte die eher serienmäßig eingesetzt und Sigma kam erst später dazu
das es so kompliziert ist habe ich nie gedacht weil ja schon Canon Linsen ans Sigma Bajonett gepflanzt wurden, also muss die "normale" Komunikation erst mal Standard (SPI) sein, sogar die Daten scheinen erst mal zu passen sonst wäre das nicht möglich.
Die immer wieder vielzitierte geheimnissvolle Canon Verschleierungstaktik (alte inkompatible Sigmas) ist IMHO nix weiter als TTL zu CMOS, wobei CMOS Chips eben viel spannungstoleranter sind, ich tippe Canon hatte die eher serienmäßig eingesetzt und Sigma kam erst später dazu
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
Vergiss eines nicht: das EOS-Protokoll verwendet meines Wissens keinerlei Byte-Framing, d.h. die Linse muss jedes Kommando verstehen bzw. zumindest wissen, wieviel Antwort zu senden ist, sonst ist sie out of sync mit der Kamera. Canon braucht nur ein einziges neues Kommando aus dem Hut zaubern, und die Sigmalinse ist auf verlorenem Posten.
So, wie nightshot das gepostet hat, gibt es mehrere Protokolle, zusätzlich gibt es ja nicht nur Kommandos zur Steuerung, sondern auch zur Justage, und das kann Sigma völlig anders umgesetzt haben, ohne dass das bei Betrieb der Canonlinse an einer Sigmakamera auffallen würde. Dass es SPI ist, war fast zu erwarten (kann fast jeder µC, Kommunikation zum Blitz läuft ja bekanntermaßen auch über SPI), aber was für Daten da herumflitzen und wie die in der Kamera interpretiert werden, das versuchen wir gerade zu entschlüsseln.
Dir ist schon klar, dass jeder Logikeingang, den du bei TTL auf 0 ziehst, ca. 1.6 mA zieht. Würdest du selbst simple Logik in TTL ausbauen, bräuchtest du einen eigenen Akku für's Objektiv. Interessant ist ja auch, dass Autofokus und andere Funktionen problemlos gegangen sind, nur beim Abblenden spinnen die alten Sigmas. Nein, TTL vs. CMOS war das höchstwahrscheinlich nicht, das war schon eher ein Protokollfehler. Aber jetzt, wo nightshot das so schön für uns rausmisst, vielleicht kann ihm jemand so ein altes Sigma und/oder eine D30/D60 schicken, dann müsste man ja schnell sehen, was los ist.Die immer wieder vielzitierte geheimnissvolle Canon Verschleierungstaktik (alte inkompatible Sigmas) ist IMHO nix weiter als TTL zu CMOS, wobei CMOS Chips eben viel spannungstoleranter sind, ich tippe Canon hatte die eher serienmäßig eingesetzt und Sigma kam erst später dazu
Vergiss eines nicht: das EOS-Protokoll verwendet meines Wissens keinerlei Byte-Framing, d.h. die Linse muss jedes Kommando verstehen bzw. zumindest wissen, wieviel Antwort zu senden ist, sonst ist sie out of sync mit der Kamera. Canon braucht nur ein einziges neues Kommando aus dem Hut zaubern, und die Sigmalinse ist auf verlorenem Posten.
Gast_61052
Guest
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
Nun ja. Canon kann nicht einfach neue Kommandos einbauen. Ich hab hier ein 50/2.5 von 1988 (sagt jedenfalls der Produktionscode). Solche ollen Linsen müssen ja weiterhin unterstützt werden -- oder können die etwa dazu lernen?
Nun ja. Canon kann nicht einfach neue Kommandos einbauen. Ich hab hier ein 50/2.5 von 1988 (sagt jedenfalls der Produktionscode). Solche ollen Linsen müssen ja weiterhin unterstützt werden -- oder können die etwa dazu lernen?
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
Für solche Fälle wird ja von der Kamera erst gefragt welches Protokoll die Linse kann.Nun ja. Canon kann nicht einfach neue Kommandos einbauen. Ich hab hier ein 50/2.5 von 1988 (sagt jedenfalls der Produktionscode). Solche ollen Linsen müssen ja weiterhin unterstützt werden -- oder können die etwa dazu lernen?
Gast_61052
Guest
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
Müssten dann nicht die Sigma-Objektive einfach eine "alte" Version des Protokolls vorgaukeln und gut ist?
PS: Ich weiß das es so einfach nicht ist, aber wie würde mich mal sehr interessieren. Vielleicht bekommt man so auch raus, warum bestimmte Sigma-Objektive zu Fehlfokus neigen und andere nicht.
Müssten dann nicht die Sigma-Objektive einfach eine "alte" Version des Protokolls vorgaukeln und gut ist?
PS: Ich weiß das es so einfach nicht ist, aber wie würde mich mal sehr interessieren. Vielleicht bekommt man so auch raus, warum bestimmte Sigma-Objektive zu Fehlfokus neigen und andere nicht.
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
Wobei ich mir natürlich nicht sicher bin, ob wir da im Handumdrehen ein Problem lösen werden, an dem Sigma seit vielen Jahren herumkaut und das deren Image nicht gerade fördert.
Es kann sich ja nur um eine absolute Bagatelle gehandelt haben. Vergesst nicht, dass die anderen Anbieter (Tamron, Tokina) das Problem nicht hatten und dass der Fehler bei den Sigmas ja nur aufgetreten ist, wenn eine bestimmte Funktion, nämlich "abblenden" aufgerufen wurde. Gut möglich, dass die Funktion von Sigma fehlerhaft umgesetzt wurde und Canon diese fehlerhafte Umsetzung absichtlich oder unbeabsichtigt zu Fall gebracht hat.Müssten dann nicht die Sigma-Objektive einfach eine "alte" Version des Protokolls vorgaukeln und gut ist?
Da nightshot bereits die Infrastruktur hat, um das Protokoll zu dumpen, könnte man das leicht feststellen: man nehme ein fehlfokusierendes Sigma, am besten eines mit großer Offenblende, und schaue, was die vor und nach der Kalibration für Daten schicken. Da Fehlfokus ja bevorzugt bei lichtstarken Sigmas aufzutreten scheint, könnte man schauen, ob die z.B. immer nur für F/5.6 kalibrieren und die F/2.8-Kalibration ab Werk auslassen. Vielleicht ist die F/2.8-Kalibration allgemein ein Buch mit 7 Siegeln, weil beim Tamron 17-50/2.8 raunzen die Leute ja auch.
Wobei ich mir natürlich nicht sicher bin, ob wir da im Handumdrehen ein Problem lösen werden, an dem Sigma seit vielen Jahren herumkaut und das deren Image nicht gerade fördert.
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
Was der Birger kann ist sehr limitiert. Move aperture X stepps, move AF Motor Y stepps und AF seek. Mit den Befehlen baut er sich seine Funktionen zusammen. Ist recht langweilig.
Oh, die Jungs hängen aber noch gewaltig. Über das Stadium war ich nach einer Stunde hinaus. Wer mit machen will, ein einfacher Logicanalyzer für etwa 100 Euro reicht aus, zum Beispiel ein USBee SX.
Ich hab da so eine leise Vermutung. Die Kamera fragt zwischendurch immer mal wieder den Lensstatus ab. Ist die Blende gerade geschlossen meldet das Objektiv 1. Wird der Lensstatus aber direkt nach dem Befehl Blende schließen abgefragt, so meldet das Objektiv 3 zurück. Meine Vermutung: Sigma schickt eine 1 wo eine 3 hin gehört und die Kamera sagt leise Servus. Ältere Kameras haben sich daran nicht gestört, neue schon. Hab aber kein "defektes" Sigma da, mit dem ich das einfach testen könnte.
AW: Grundsätzliche Infos über Fehlfokus-Korrektur gesucht
Klingt interessant. So, wie du das schreibst, könnten wir uns mit einem zerfledderten Zwischenring (Kosten: unter 50€) und ein bisserl Softwareschreiben einen Birger selber bauen, und dazu sogar noch mehr steuern als mit dem 900€-Adapter ...
Hmmm, rein theoretisch müsste man da ja einfach nur einen µC mit 2 SPI Ports hineinhängen und könnte sich die Info bequem über die serielle Schnittstelle auswerfen lassen. Damit würde man sich die elende Bitzählerei am Oszi/Logikanalysator schnell ersparen, sogar relative Timings könnte man auswerfen. Einen Schaltplan könnte ich da schnell einmal vorbereiten und posten, wenn jemandem nach Basteln ist ... die Software dafür würde sich faktisch selber schreiben (zumindest für ATmega)
Wenn das wirklich das ganze Problem ist, müsste man das mit einem µC mit 2 SPI-Anschlüssen beheben können. Schaut zwar nicht sonderlich elegant aus, aber wenn man damit ein paar lichtstarke Teles reanimieren könnte, kann ich mir gut vorstellen, dass sich dafür ein Markt findet.
WERBUNG