Canon-EOS-Protokoll

[schubbser]

1) Ob ein Canon Objektiv TK-tauglich ist, lässt sich leicht an den 3 zusätzlichen Kontakten erkennen. Canon benutzt NUR diese Systematik: der TK schließt die dem Faktor entsprechenden Pins objektivseitig kurz und das Objektiv reagiert dementsprechend. Eine aktive Elektronik gibt es in den Orginal-TKs ja nicht.
2) Ob der AF noch geht oder nicht, entscheidet m.W. die Kamera und daran lässt sich dann ja schlecht etwas ändern, WENN die Exif-Daten stimmen sollen.

1.Welche Pins werden denn kurzgeschlossen?
Du schreibst hier Faktor. Das kann nicht klappen. So viele Faktoren wie es gibt, da reichen die Pins nicht.

2.Die Kamera entscheidet zusammen mit dem Objektiv ob der AF funktioniert. Aber das Objektiv liefert die entscheidenen Werte die der TK "manipulieren" muss um ein scharfes Bild zu bringen.

 

[jar]

1.Welche Pins werden denn kurzgeschlossen?
Du schreibst hier Faktor. Das kann nicht klappen. So viele Faktoren wie es gibt, da reichen die Pins nicht.

klar reichen die dicke,
es gibt 3 Pins und von Canon nur 2 mögliche TC (und nur von Canon für Canon wird das garantiert )

die drei Pins können alleine 2^2 Möglichkeiten bringen also 4 mögliche TC und es gibt von Caanon nur zwei 1,4x und 2x , ist also noch Platz für einen 3x obwohl Canon den bestimmt aus Qualitätsgründen nicht bringt,

mit GND dazu wären sogar 2^3 Möglichkeiten drin, also 8 mögliche TC

2.Die Kamera entscheidet zusammen mit dem Objektiv ob der AF funktioniert. Aber das Objektiv liefert die entscheidenen Werte die der TK "manipulieren" muss um ein scharfes Bild zu bringen.

so stimmt das nicht, der alte Soli ohne Petzkontakte lies mein 24-70 L 2,8 durchrennen, die Linse war zu schnell um im Focus zu stoppen, erst mit Petzkontakte wird der USM eingebremst und der AF findet sein Ziel, wenn ich die Petzkontakte abklebe rennt der AF wieder durch (schon irre, da das 24-70 von Canons Seite nie für TC vorgesehen war)

früher zu meiner D30 Zeit funzten alle Linsen auch USM ohne die Petzkontakte und der AF saß bei F8 gemeldet F4 (EF300 L 4 USM ohne IS) da ohne Petze, dito mit dem 28-80 L 2,8-4,0 USM, die neueren USM sind einfach zu schnell

 

[Thunderclap]

klar reichen die dicke,
es gibt 3 Pins und von Canon nur 2 mögliche TC (und nur von Canon für Canon wird das garantiert )

die drei Pins können alleine 2^2 Möglichkeiten bringen also 4 mögliche TC und es gibt von Caanon nur zwei 1,4x und 2x , ist also noch Platz für einen 3x obwohl Canon den bestimmt aus Qualitätsgründen nicht bringt,

Es gibt 3 Konverter von Canon Der Lifesize-Converter für das 50/2,8 Macro nutzt ebenfalls die Converter-Pins mit einer eigenen Kombination!
Damit sind alle Kombinationen ausgeschöpft... (kein TK, 1,4x, 2x, Lifesize)

Aber hier wird es seit zwei seiten leicht OT... ich hoffe es gibt bald weitere Erkenntnisse zum protokoll

 

[schubbser]

klar reichen die dicke,
es gibt 3 Pins und von Canon nur 2 mögliche TC (und nur von Canon für Canon wird das garantiert )

die drei Pins können alleine 2^2 Möglichkeiten bringen also 4 mögliche TC und es gibt von Caanon nur zwei 1,4x und 2x , ist also noch Platz für einen 3x obwohl Canon den bestimmt aus Qualitätsgründen nicht bringt,

mit GND dazu wären sogar 2^3 Möglichkeiten drin, also 8 mögliche TC

So stimmt das. Ich hatte mit Faktor den Umrechnungsfaktor für die Motorschritte, bzw. den Phasenoffset verstanden.
Das würde bedeuten, dass das Objektiv am TK dann dementsprechend (dem Fakor des TK entsprechend) andere Werte bezüglich des Phasenoffsets an die Kamera liefert, als wenn es dirket an der Kamera hängen würde.
Diese Werte, bzw ihr Unterschied zum Wert ohne Adapter könnte Nightshot vielleicht auch weiterhelfen.

 

[Nightshot]

WENN die Exif-Daten stimmen sollen. Also, wenn eine f4.0 Linse mit einem 2xTK f8.0 melden soll, kann der AF z.B. an einer 5D nicht mehr funktionieren. Da kann auch ein noch so fuchsiger TK nichts daran ändern.

Na, das stimmt so nicht ganz, es werden getrennte Werte übertragen. Einmal der wahre Blendenwert und einmal der der in der Kamera angezeigt wird und auch ins Exif geschrieben wird. Als Beispiel das 100/2,8 Makro. Wenn es an der Naheinstellgrenze bei 1:1 Abbildungsmaßstab ist hat es nur noch eine effektive Offenblende von 5,6, die Kamera zeigt aber weiter 2,8 an. Der 2,8er AF Sensor ist aber schon ab einer Entfernungseinstellung von 0,8m nicht mehr aktiv, da ab der Grenze die effektive Blende 2,8 unterschritten wird. Die getrennte Übertragung der Blendenwerte kann man auch in anderer Richtung ausnutzen.

Es ließe sich auch eine leicht asynchrone Übertragung realisieren. Nach einer Anfrage von der Kamera schickt man der Kamera ein Busy Signal und schickt die in die Warteschleife. In der Zwischenzeit holt man sich die Antwort vom Objektiv, rechnet den Wert um und gibt den der Kamera zurück. Bedeutet natürlich mehr Aufwand, da man die Clock selbst verwalten muss.

Wie Kenko das jetzt umgesetzt hat kann ich nicht sagen, sonderlich intelligent kann es aber nicht sein. Sonst würde es ein 200/2,0 erkennen und die Befehle ungesehen durchleiten, denn da braucht es nichts verändern, das macht das Objektiv alles ganz allein, wenn man die zusätzlichen Kontakte kurz schließt. Ich wollte es eigentlich vermeiden einen DGX zu kaufen, nur um ihn mal an meinen Adapter anzuschließen.

 

[pspilot]

Na, das stimmt so nicht ganz, es werden getrennte Werte übertragen. Einmal der wahre Blendenwert und einmal der der in der Kamera angezeigt wird und auch ins Exif geschrieben wird.

Zusammengefasst, sprich nochmal nachgefragt :

1) Entscheidet die Kamera alleine, ob sie den AF noch verwendet oder nicht?
2) Falls ja, von welchem Wert ist das abhängig?

Oder stell ich mir das zu einfach vor?

3) Du könntest dir also vorstellen, dass man mit einer 5D(II) ein Bild mit AF machen kann, obwohl bei 'Offenblende' f8 in den EXIFs steht und vermutlich auf der Kameraanzeige (also, generell genug Licht vorausgesetzt)?

P.S.: Stell ich mir vielleicht diese AF-Abschaltung etwas zu einfach vor? Ich dachte bislang, es ist einfach ein Wert (egal mal welcher), _unabhängig_ obs tatsächlich noch ginge oder nicht. Und als 'Sicherheitswert' hat Canon halt bei nicht-1ern >f5.6 genommen, was in schlechteren Lichtverhältnissen auch nicht so verkehrt ist. Das Dilemma bislang ist einfach, entweder wird auch bei strahlender Sonne der AF am 100-400 z.B. abgeschaltet, oder man klebt ab (bzw. hat einen 'dummen' TK), dann aber funktioniert der AF wegen des Pumpens nicht oder schlecht.

 

[drei]

@pspilot:

So, wie ich das verstehe, ist das Problem nicht zu wenig Licht, sondern das Öffnungsverhältnis. Bei zu großem Blendenwert funktioniert der AF-Sensor nicht mehr, weil der Strahlengang sensorseitig gewissermaßen "zu parallel" ist. Teilt man jetzt dem Body einen manipulierten niedrigeren Blendenwert mit, wird der zwar versuchen, zu fokussieren, es funktioniert aber nicht (bzw. nicht zuverlässig), auch wenn es hell und viel Licht da ist.

@nightshot:

Bedeutet der Busy-Trick, dass man damit JEDE Datenübertragung manipulieren könnte, z. B. auch bei inkompatiblen Sigma-Objektiven (also nicht nur ein Bit killen, sondern den Datenstrom "in Ruhe" analysieren und ändern)?

 

[Slowmo86]

So, wie ich das verstehe, ist das Problem nicht zu wenig Licht, sondern das Öffnungsverhältnis. Bei zu großem Blendenwert funktioniert der AF-Sensor nicht mehr, weil der Strahlengang sensorseitig gewissermaßen "zu parallel" ist. Teilt man jetzt dem Body einen manipulierten niedrigeren Blendenwert mit, wird der zwar versuchen, zu fokussieren, es funktioniert aber nicht (bzw. nicht zuverlässig), auch wenn es hell und viel Licht da ist.

Die Praxis sagt das Gegenteil. Eine niedrigere Präzision mit 2Tks ( also F8 anstatt F5,6 mit nur einem) konnte ich nicht feststellen. Wenn, dann nur so gering das es auf die geringere ankommende Lichtmenge zurückzuführen ist. Die Beschränkung hat imho reine Marketinghintergründe ( 1ser Schutz ). Bezgl AF Speed gibts auch kaum Unterschiede ( nur die Schärfensuche ist halt lahm... )
Gilt zumindest für die 5D mk2 ( 2x TK von Sigma 1,4x dgx 300 pro von Kenko ) Sogar die äußeren Linienensoren funktionieren noch. Sie treffen genauso zuverlässig wie ganz ohne Tks ( also in der Praxis selbst bei viel Licht kaum sinnvoll verwendbar ).

 

[Nightshot]

1) Entscheidet die Kamera alleine, ob sie den AF noch verwendet oder nicht?
2) Falls ja, von welchem Wert ist das abhängig?

Das entscheidet allein die Kamera. Auch die Entscheidung welchen AF Sensor sie noch verwenden kann liegt allein bei ihr und die Entscheidung macht sie von der effektiven Blende abhängig, die nichts mit der angezeigten Blende im Exif zu tun hat.

3) Du könntest dir also vorstellen, dass man mit einer 5D(II) ein Bild mit AF machen kann, obwohl bei 'Offenblende' f8 in den EXIFs steht und vermutlich auf der Kameraanzeige (also, generell genug Licht vorausgesetzt)?

Wenn die Kamera keine Abfrage [effektiver Blendenwert >= geometrischer Blendenwert] eingebaut hat, dann sicher ja. Das wäre so eine Kontrolle wie "werde ich gerade hinters Licht geführt"?

Bedeutet der Busy-Trick, dass man damit JEDE Datenübertragung manipulieren könnte, z. B. auch bei inkompatiblen Sigma-Objektiven (also nicht nur ein Bit killen, sondern den Datenstrom "in Ruhe" analysieren und ändern)?

Ja das lässt sich umsetzen. Man muss dazu aber zwei Clocks verwalten, eine passiv, eine aktiv und anschließend den Datenstrom wieder parallelisieren. Zudem muss man die Objektivdatenrückleitung eigens überwachen, sonst hat man aus Versehen einen Err01 geschickt obwohl man es nicht wollte.

 

[pspilot]

@drei: Slowmo86 hat eigentlich alles gesagt. Die Praxis zeigt tatsächlich, dass der AF mit abgeklebten Kontakten bzw. TKs die gleich gar nichts übertragen (mein 1.4x Kenko ist so ein 'Dummer', der verhält sich elektrisch komplett 'neutral') häufig noch prima funktioniert, wenn die Kamera ihn nicht abschalten würde. Ich will Canon gar keine böse Absicht unterstellen und '1er-Schutz' ist wahrscheinlich auch nicht der alleinige Grund. Die 1er hat einfach einen leistungsfähigeren AF und Canon vermeidet mit 'konservativer' Abschaltung des AF halt viele Support Anfragen . Ich habe viel mit dem 1.4x & dem 100-400 'rumgespielt' und es gibt durchaus Lichtsituationen, da funktioniert der AF einfach nicht mehr sehr gut. Wenn Canon ganz im Sinne des Kunden bemüht gewesen wäre, hätten sie die Abschaltung vielleicht nicht so starr an die Blende gekoppelt, sondern das verfügbare Licht in die Entscheidung mit einbezogen. Ein bisschen '1er-Protektion' mag also schon dabei sein. Meine Erfahrungen basieren übrigens auch auf der Arbeit mit der 5D, sowie 5DII.

@Nightshot: danke für die Erklärungen. Der Unterschied - also dass die Kamera da einen Unterschied macht - zwischen 'effektiver Blende' und 'angezeigter Blende' war mir nicht bekannt. Das eröffnet natürlich Möglichkeiten. Ich gebe aber zu, dass ich das gesamte System noch nicht gänzlich verstanden habe .

Bezüglich eures 'Sigma-Korrektur-Chips' schreibt z.Z. selbst die c't über neue, noch kleinere ATMEL Tiny's. Die gibts nun in 4 mm2 Gehäusen, das lässt sich totsicher auch in einer Linse noch unterbringen. Den Quartz würde ich mir übrigens sparen, da die internen Oszillatoren eigentlich recht stabil laufen und soweit ich das umreißen kann und ihr sowieso nicht asynchron arbeitet, sprich ihr braucht keinen superstabilen Clock. 8 MHz bedeuten 125nS Zykluszeit und viele Befehle arbeitet der Atmel in einem oder max. 2 Takten ab. Allerdings programmiere ich die Dinger ausschließlich in Assembler, man glaubt gar nicht, was da mit 8 MHz möglich ist . Diese Bitschieberei an den SPI Ports jedenfall wäre Killefitz, wahrscheinlich in Assembler einfacher als in einer Hochsprache. Jedenfalls braucht man für die angepeilte Aufgabe keinerlei Peripherie, der nackte Chip reicht. Und wenn man es schafft, 6 Pins 'andockbar' zu gestalten, ist auch ein Upgrade via 'ICSP' kein Problem (in-circuit serial programming, ein schrecklich schlaues Wort für den primitiven Vorgang, den Controller im eingelöteten Zustand 'reprogrammieren' zu können ).

 

[Nightshot]

Ich bin jetzt einen großen Schritt weiter in der Berechnung der Weltformel, ähhh ich meine AF Parameterumrechnung. Ich konnte die Rechenoperationen auf einfache Additionen und Bitshifts reduzieren und damit haben sich etliche freie Konstanten in Luft aufgelöst. Zwei Probleme gibt es aber noch. Ich muss immer noch 2 bits invertieren und dann gibt es noch eine größere Rechenoperation. Hier kann ich mich entscheiden ob ich lieber die 1000ste Wurzel aus einer ganzen Zahl oder 2^(Floatingpoint) rechne. Wahrscheinlich gibt es da eine schlaue Prozessoroperation die das schnell erledigt und auch gleich die beiden Bits erledigt, aber ich hab noch nichts schlaues gefunden. Irgendwo muss dabei nicht exakt gerechnet werden, ich kann einen Jitter von etwa 1% messen.

Für die "vielen" Justageparameter hab ich eine Idee. Die 5D frägt nur zwei der Werte ab (2,8 und 5,6), die 5DII will aber vier wissen. Neu bei der 5DII ist ja, dass sie die Farbtemperatur vom Licht auswertet und danach den AF korrigiert. Die beiden Bruder und Schwester Werte könnten also die IR Korrekturwerte sein, denn irgend woher muss die Kamera die Info bekommen, ob sich die Fokuslage beim gerade verwendeten Objektiv im IR stark oder schwach ändert.

5 Atmels und ein Proggerboard ich ich inzwischen da, bin aber noch zu nichts gekommen.

 

[MasterFX]

Mhh, bist du sicher, dass du irgendwo wirklich die tausendste Wurzel ziehen musst und dass da nicht eine andere Funktion hintersteckt? Die tausendstel Wurzel aus einem Wert ist doch verdammt klein. Übrigens Floating Point sollte man nie mein einem µC rechnen, das ist verdammt langsam weil die meisten keine FPU haben und das dann kompliziert über eine lib realisiert wird, was das ganze sehr langsam macht und deinen Code extrem aufbläht.

 

[jplatte]

Hier kann ich mich entscheiden ob ich lieber die 1000ste Wurzel aus einer ganzen Zahl oder 2^(Floatingpoint) rechne. Wahrscheinlich gibt es da eine schlaue Prozessoroperation die das schnell erledigt und auch gleich die beiden Bits erledigt, aber ich hab noch nichts schlaues gefunden. Irgendwo muss dabei nicht exakt gerechnet werden, ich kann einen Jitter von etwa 1% messen.

Statt komplexer Berechnungen wird auch oft ein tabellarischer Ansatz gewählt, bei dem dann Zwischenwerte ggf. interpoliert werden. Daher muss es nicht in jedem Fall eine einfach zu berechnende Funktion geben. Zum Jitter: Geht in die Berechnung nicht der Messwert der Phasendifferenz ein? Dies ist doch sicher ein analoger Wert, der mit jeder Messung ein bisschen rauschen kann und daher vielleicht die unterschiedlichen Werte erklärt?

Jörg

 

[Nightshot]

Mhh, bist du sicher, dass du irgendwo wirklich die tausendste Wurzel ziehen musst und dass da nicht eine andere Funktion hintersteckt? Die tausendstel Wurzel aus einem Wert ist doch verdammt klein.

Ist nur eine der möglichen Umformungen, sonderlich sinnvoll finde ich sie nicht. Das zentrale Element sieht so aus:

2^((16384-x)/1000)

Die 1000 könnten auch 1024 sein, so genau ist die Messung nicht. Gibt es da eine einfache Umformung, die das leicht berechenbar macht und mir einfach nicht auffällt?

Übrigens Floating Point sollte man nie mein einem µC rechnen, das ist verdammt langsam weil die meisten keine FPU haben und das dann kompliziert über eine lib realisiert wird, was das ganze sehr langsam macht und deinen Code extrem aufbläht.

Ich versuch das auch tunlichst zu vermeiden. Die Kamera rechnet auf jeden Fall damit, denn die werden im Justageprogramm angezeigt. Kann auch sein, dass die eine FPU hat.

Statt komplexer Berechnungen wird auch oft ein tabellarischer Ansatz gewählt, bei dem dann Zwischenwerte ggf. interpoliert werden. Daher muss es nicht in jedem Fall eine einfach zu berechnende Funktion geben.

Dann hätte man auch gleich den richtigen Wert ausgeben können, den man nicht erst noch lange umrechnen muss.

Zum Jitter: Geht in die Berechnung nicht der Messwert der Phasendifferenz ein? Dies ist doch sicher ein analoger Wert, der mit jeder Messung ein bisschen rauschen kann und daher vielleicht die unterschiedlichen Werte erklärt?

Um das Rauschen zu eliminieren lass ich 200 Messungen mitteln. Ist auch kein großer Aufwand, das macht mein Programm von selbst. Die Abweichungen sind auch sicher sytematisch, da sie periodisch auftreten, was Rauschen in der Regel nicht tut.

 

[ohoyer]

Mal son Gedanke zur Vereinfachung:

1024=2^10

Somit:

2^((16384-x)/1000)
oder
2^(16-x/1024)

Welchen Wertebereich nimmt x hier an? Dann kann man hier noch ggf. vereinfachen oder Werte vorberechnen- ist ein alter Trick, z.B. in Tagen der alten 386er und 3D-Spiele hat man viele Berechnungen durch simple Sinus/Cosinustabellen ersetzt.

 

[Nightshot]

x ist nach meinen Erkenntnissen ein int15 Wert das 16te Bit ist das Vorzeichen. Kann aber sein, dass ich das schon in die Formel mit aufgenommen habe, dann kann man es stur als unsigned16 lesen.

Die Division durch 1024 ist auch nicht tragisch, das ist nur ein shift im Register. Aber was ist mit der ganzen Infos, die hinten aus dem Register raus fallen? Die sind immer noch wichtig.

 

[spoilerhead]

2^((16384-x)/1024)

-->

1<<( (16384-x)>>10)
ergibt als int aber irgendwie nicht gerade sehr viel sinn
kann aber umformuliert werden

2^((16384-x)/1024) =
2^(16384/1024 - x/1024) = 2^(16384/1024 + (- x/1024)) =
2^(16384/1024) * 2^(- x/1024) = 2^16 * 2^(-x/1024) =
65536 * 2^(-x/1024)

Bist du dir mti dem minus sicher?

 

[MasterFX]

Kann es sein, dass die "65536" einfach nur "-1" ist?
@Nightshot
Könntest du mal eine kleine Tabelle Posten mit deinen X und Y-Werten die durch die Funktion rauskommen sollten?

 

[Nightshot]

Kleinstes Problem:

x y

8064 455
8320 379
8576 310
8832 261
9088 226
9344 188
9600 155
9856 131
10112 113
10368 93
10624 77
10880 64
11136 56
11392 46
11648 37
11904 31
12160 27
12416 22

 

[Dande]

stimmt. lässt sich ziemlich gut durch eine Funktion der Form f(x)=a*exp(b*x) anpassen, mit a=118342 und b=-0,0006906.

PS: Fitfehler für a ist 4,1% und für b 0,7%