Forum Übersicht - RE: Objektivsimulator für das Minolta-/Sony-A-Bajonett - 8

ZITAT(ddd @ 2010-04-25, 14:40) Matthias, ich hätte früher darauf kommen dürfen, dass die *.dgt-Sample-logs gut komprimierbar sind und dann sehr wohl hier als Anhang gepostet werden können.[/quote]
Ja, als ZIP-Datei gepackt ist das überhaupt kein Problem (bei anderen Packern würde sich nur wieder das Problem ergeben, daß nicht jeder die passenden Entpacker hat). Wir können uns gerne auf gezippte DGT-Dateien als "Austauschformat" für Rohtracedaten einigen.

Sobald wir Glitches ausschließen können und uns das makroskopische Zeitverhalten nicht mehr interessiert, könnte man die Dateien mit dem oben andiskutierten CRUSHDGT.DEB-Skript o.ä. in eine zusammengestauchte Form überführen, in der nach jedem Flankenwechsel der Clock jeweils nur ein Sample aufbewahrt wird. So wird z.B. aus Deiner 1.048.576 Bytes großen Digitrace-DGT-Datei eine nur noch 1.744 Bytes große CRSHTRLG.DGT-Datei, die nach wie vor alle relevanten Informationen für die Analyse enthält und dementsprechend immer noch die gleichen Ergebnisse liefert, wenn wir sie durch Tools wie DGTANA.SH oder DGT2LDMP.DEB schicken, die aber nur noch 1/600 des Platzes benötigt.

ZITAT109 Bytes habe ich auch, dabei werden alle 0xFF und die 0x00 bei SS inaktiv mitgezählt, es ist also die Anzahl der 8bit-SCK-Bursts, welche ja offensichtlich die Bytes darstellen.[/quote]
Exakt.

Übrigens habe ich inzwischen oben auch noch zwei Varianten von DGT2LDMP.DEB eingearbeitet:

http://www.mi-fo.de/forum/index.php?showto...st&p=260688

Mit DGT3LDMP.DEB wird aus einer DGT-Trace-Datei ein Lensdump von Kanal 3 (SS) extrahiert und als LENSDMP3.BIN abgelegt. Und für den Fall, daß wir in Zukunft auch MOSI (auf Kanal 4) verwenden, würde DGT4LDMP.DEB eine analoge Datei namens LENSDMP4.BIN erzeugen. Stellt man diese gegenüber (mit SHOW109.DEB o.ä.), geht auch die Information, ob SS gerade high oder low war, nicht verloren.

http://www.mi-fo.de/forum/index.php?showto...st&p=260698

Viele Grüße,

Matthias

moin,

ich habe mal ein wenig Doku gemacht, weitere Timing-Diagramme folgen:
[attachment=7671:timing_einzelbyte.gif]
Die Spannungspegel liegen knapp unter 4,9V. Zur Flankensteilheit (tTLH</sub>, tTHL</sub> kann ich nix sagen, ohne Oszilloskop sehe ich nur digitale Zustände.
edit: Abbildung aktualisiert.

Der 74HC244 (ebenso der 74HC240, 74HC245 und deren Brüder aus den anderen Logikfamilien wie 74LS, 74F usw.) ist ein Schmitt-Trigger, schaltet also sehr definiert.
Bei mir wird durch Digitrace der 74HC244 mit 3,4V (! versorgt, vmtl. durch Anschneiden das als Vcc missbrauchten /STROBE-Signals, d.h. high-Pegel wird ab ca. 2,4V (min ca. 0,7x Vcc) erkannt, low-Pegel unter 1,0V (max. ca. 0,3x Vcc) (s.h.: Datenblatt nxp vormals Philips meine PC74HC244 sind von Philips Baujahr 1991). Damit wird der eigentlich nicht TTL-kompatible HC ungefähr auf TTL-kompatible Pegel gezwungen; um den Preis von Überspannung an den Eingängen. Dies ist "not recommended", aber innerhalb der Limits, wenn der Strom auf 20mA beschränkt wird.

Hans@littlelamb, Deine Daten enthalten viele Fehler, aber (fast?) nur Ein-Bit-Fehler (oder Abbrüche). Daher tippe ich auf minimal zu knappe Pegel oder Flankensteilheit.
Welchen der LAs hast Du? Die haben deutlich höhere Arbeitsfrequenzen als meine Bastel-Minimal-Lösung, daher schließe ich Flankenprobleme erstmal aus. Also Pegel...
Auch Wolframs Probleme mit dem (Kanda)AVR-ParPort-Adapter könnten auf Pegelfehler zurückgehen, dort wird der HC244 mit 5V betrieben (die LensChips müssen 4,9-5,0V haben!

edit: die Überlegungen zu den Pegeln und Treibern sind teilweise Murks.
Die LensChips liefern saubere CMOS-Pegel mit Vcc=4,9V (soweit ohne Oszco feststellbar), ich habe mich von den highZ-Zuständen irritieren lassen.
Die Vcc des HC244 im ParPort-Adapter wird nicht von Digitrace geregelt, sonden bricht von 4,4V bei allen Eingängen low auf 3,4V ein, sobald auch nur ein Eingang high ist.
Die out-Pegel liegen dann bei Vcc=3,4V für high und 0V für low, also saubere CMOS-Pegel und klar innerhalb der Spec des ParPorts, egal ob nun CMOS- oder TTL-LS-Eingänge vorhanden sind und diese mit 5V oder 3,3V betrieben werden.
Vorsicht beim Messen und Basteln: offene Eingänge eiern fröhlich in der Gegend herum und führen zu beliebig unvorhersehbarem Verhalten. Offene Ausgänge sind unkritisch, allerdings sind die dort hochohmig (DMM) gemessenen Spannungen nicht auswertbar (man sieht z.B. 2,4V, die aber in keinster Weise echt sind. Sobald eine Last am Ausgang liegt, selbst ein hochohmiger CMOS-Eingang, verschwinden diese).
Klassisch ist ein ParPort ein Latch 74LS374, Bidi ab PS/2 kommt als Eingang ein 74LS244 dazu, wobei die /OE von Latch und Treiber antiparallel geschaltet sind. Heute ist das vollintegriert, muss aber zu diesem klassischen Aufbau vollständig kompatibel sein.

Hans, bei Dir könnten es auch parasitäre Kapazitäten an den Probes sein oder schwingende offene Probes. Hier wird es ohne Oszco auch schwierig, die Ursache weiter einzugrenzen.
edit -ende-

@Matthias: ich habe die *.dgt auch im ersten Schritt auf die Pegelwechsel reduziert, Du kannst Dir das in der *.uat-Datei ansehen (am Anfang, *.ua* ist plain ascii/CRLF=*.txt).
Für raw-Daten ist das dgt-"Format" optimal, es müssen nur die Kanalbelegung und die Auflösung bekannt sein. Sobald das Timing gut genug bekannt ist, kann man das dgt-Format mit einer Auflösung von 2xfSCK kompakt nutzen.
zip ist als Austausch-Packer optimal, unter win (ab XP) oder linux sind zumindest die Entpacker im System voll integriert.
Sonst ziehe ich unter win 7z und unter linux tar/bzip2 vor, aber damit werden wir wieder abhängig von Zusatz-SW, was ich vermeiden möchte.

Austauschformate sollten so simpel wie möglich sein. Lieber etwas weniger effektiv, dafür lesbar!

Letzte Sache: da wir mittlerweile wissen, dass die LensChips selbst der toshiba ML00?-Urbaureihe keine Masken-ROMs wie ursprünglich vermutet sind, sondern innere Zustände haben (FlipFlops, Latches); strebe ich an, die Zustandsdiagramme aufzumalen. Dann ein wenig Boolsche Schaltalgebra, vereinfachen, und wir wissen, wie wir einen Mikrokontroller programmieren müssen, damit dieser einen LensChip erfolgreich emulieren kann. D.h aber, alle möglichen und unmöglichen Zustandskombinationen durchtesten... allein das 70300G-SSM hat an 5 Kontakten schon durch seinen großen Brennweitenbereich und den AF-(Limit)Schalter und Fokusstopp Dutzende von möglichen Konfigurationen. Mustererkennung und statistisch abgesicherte Stichproben sind der einzige Weg, wir können niemals alle Varianten wirklich durchtesten.

so, Schluss für heute. Ende der Woche sollte die D5 da sein, dann wird es richtig lustig.

gruesze, thomas

ZITAT(ddd @ 2010-04-25, 23:29) ...dann wird es richtig lustig.[/quote]
Ansichtssache! Als "Mechaniker" stehe ich mit großen staunenden Augen vor diesem Projekt und bewundere Euren Mut und die viele Arbeit.

ZITAT(BerndFranzen @ 2010-04-26, 8:53) ZITAT(ddd @ 2010-04-25, 23:29) ...dann wird es richtig lustig.[/quote]
Ansichtssache! Als "Mechaniker" stehe ich mit großen staunenden Augen vor diesem Projekt und bewundere Euren Mut und die viele Arbeit.
[/quote]
Elektronik und Software sind doch in gewisser Weise auch nur Mechanik, nur halt in einem anderen Medium... ;-)

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2010-04-26, 9:48) ZITAT(BerndFranzen @ 2010-04-26, 8:53) ZITAT(ddd @ 2010-04-25, 23:29) ...dann wird es richtig lustig.[/quote]
Ansichtssache! Als "Mechaniker" stehe ich mit großen staunenden Augen vor diesem Projekt und bewundere Euren Mut und die viele Arbeit.
[/quote]
Elektronik und Software sind doch in gewisser Weise auch nur Mechanik, nur halt in einem anderen Medium... ;-)

Viele Grüße,

Matthias
[/quote]
Und Mechanik besteht doch auch nur aus Elektronen, Positronen und anderen "-onen", ich weiß.
Alle eine Sache des Standpunkts.
Nur würde eine Reparaturanleitung für ein mechanisches Problem "erheblich" dicker ausfalle, wenn sie auf der Atom-Ebene geschrieben wäre.

moin, ZITAT(BerndFranzen @ 2010-04-26, 7:53) Ansichtssache! Als "Mechaniker" stehe ich mit großen staunenden Augen vor diesem Projekt und bewundere Euren Mut und die viele Arbeit.[/quote]
mir macht das Spaß
Wenn andere es interessant und/oder nützlich finden, um so besser.
ps: mit der mechanischen Beschreibung auf Elektronen-Ebene gäbe es aber grundsätzliche Probleme: der Kollege Heisenberg hatte da mal so eine gruselige Idee

Kurz was zu Lizenzen usw. meiner Abbildungen und Programme:
Aller Code von mir ist GPLv2only, kann also frei genutzt, modifiziert, weiterverbreitet usw. werden, solange dieser auch bei Modifikation komplett unter GPLv2 bleibt und dieses kenntlich ist. Die GPL selbst packe ich jetzt nicht in die Anlagen, der link muss reichen.
GPLv3 bin ich mir noch nicht einig, da v3 und v2 zueinander inkompatibel sind, wäre es eh eine Doppellizenz.
Die GPLv2 ist sowohl im angloamerikanischen als auch im (kontinental)europäischen Rechtssystem mehrfach erfolgreich gerichtlich getestet worden.
Ich habe an der Analyse von einem Device mitgearbeitet, nach etwa 2 Jahren und Klageerhebung hat der Hersteller endlich die GPLv2 akzeptiert und alles wie gefordert zugänglich gemacht (und gezahlt...).

Abbildungen/Skizzen/Bilder stehen unter cc3.0-by-nc-sa = creative commons Version 3.0-Namensnennung-Nichtkommerziell-Weitergabe unter gleichen Bedingungen.
Damit darf ebenfalls jeder die verwenden, verändern, weitergeben usw., allerdings nicht zu kommerziellen Zwecken (im Gegensatz zum Code!.

Die LensChip-Inhalte existierender Geräte sind nicht durch mich/uns lizensierbar. Diese sind im Zweifel Eigentum von minolta, Sony oder des jeweiligen Herstellers, können aber nach übereinstimmender Meinung von Matthias und mir zum Zweck der Anbindung anderer Systeme an die Systemschnittstelle und/oder zur Fehlerbehebung und/oder zu akademischen oder Ausbildungszwecken analysiert, genutzt und veröffentlicht werden.

Die selbst erstellten LensChip-Inhalte oder (nur die! Modifikation bestehender wäre dann wieder soweit es mich betrifft GPLv2.

Ich mache das nicht, weil ich so scharf auf die Rechte bin, sondern um die Nutzungsbedingungen zweifelsfrei festzulegen; und zu verhindern, dass diese Infos oder der Code proprietarisiert werden können.
Bei Abbildungen von Pete Ganzel z.B. steht immer sein © drauf, aber es ist nicht klar, wie/ob/zu welchen Bedingungen man die nutzen darf. Gefragt habe ich ihn noch nicht...

Es stecken so viele Infos von anderen darin, die ebenfalls frei zugänglich sind, insbesondere von vasimvyxum.com, Pete Ganzel und Matthias: Deine Blitzprotokoll-Analyse und alles drumherum und daraus abgeleitetes kannte ich seit Jahren und diese ganze Arbeit an Analyse und Zusammentragen ist wesentlicher Bestandteil und Vorraussetzung dieses Projektes, auch wenn ich dass ev. noch nicht in angemessener Form deutlich gemacht habe. Daher will ich sicherstellen, dass auch alles hier, soweit es von mir dargestellt wird, offen und frei für alle zugänglich ist und bleibt.

gruesze, thomas

moin,

nochmal zu Hans' verbuggter Auslesung des 35-105/3.5-4.5n LensID 25858 (das einzige bekannte Objektiv, dessen LensID nicht auf '1' endet):

8000i_mAF35105F3545n (LensID 25858 = 0x6502 byteorder 02 65) kl.Bl. 22-27
 
   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F hex/0base
 
FF 81 26 40 01 1E 21 11 33 23 00 F3 4C F9 00 06 5E 00 AD 01 F0 33 02 E7 20 08 24 00 00 BF 00 00 65
FF 81 26 40 01 1E 21 01 23 3B 00 FB 5C F9 00 06 5E 00 8C 01 F0 33 02 C6 00 4A 24 00 00 BF 00 00 67
FF 81 26 40 00 1E 00 10 32 0B 00 FB 0C F9 00 04 1C 00 AF 01 F1 33 02 E7 20 42 2C 00 00 BF 00 02 65
FF 01 26 50 01 1E 21 11 33 23 00 F3 4C F1 00 06 5E 00 AD 01 E1 23 02 E7 00
FF 81 26 50 00 1E 00 10 32 0B 00 FB 0C F9 00 04 1C 00 AF 01 F1 33 02 E7 20 42 2C 00 00 BF 00 02 65
FF 81 06 50 00 1E 00 10 32 0A 00 FA 0C F9 00 04 1C 00 AF 01 F3 33 00 E7 20
FF 81 26 40 03 1C 21 11 33 2B 00 FB 48 F9 00 06 5E 00 29 01 E1 23 02 E7 20 5A 24 00 00 BE 00 02 44
FF 81 24 10 01 1C 63 13 33 2B 00 FB 48 F9 00 06 5E 00 29 01 F1 33 02 E7 20
FF 81 06 70 01 1E 21 11 33 23 00 F3 4C F1 00 06 5E 00 AD 01 F0 33 02 C6 00 4A 04 00 00 BF 00 00 65
FF 81 26 40 01 1E 21 01 23 0A 00 FA 4C F8 00 06 5E 00 8C 01 F1 33 02 E7 20
FF 83 24 10 01 1E 21 01 23 2B 00 FB 4C F9 00 06 5E 00 8C 01 F3 33 00 E7 20 08 20 00 00 3F 00 02 61
FF 81 26 40 01 1E 21 00 22 0A 00 FA 4C F8 01 06 5E 00 AD 01 E1 23 02 E7 20
FF 01 26 50 00 1E 00 10 32 0A 00 FA 4C F9 00 04 1C 00 AD 01 F1 37 06 E7 20 42 24 00 00 BF 00 02 6D
FF 01 26 D0 01 1E 21 11 33 2B 00 FB C8 F9 00 06 5E 00 29 01 F1 33 02 E7 20
FF 81 26 50 00 1E 21 11 33 2B 00 FB 0C FB 00 04 1C 00 29 01 F1 33 02 E7 20 42 2C 00 00 BF 00 02 65
 
gesichert:
FF 81 26 50 01 1E 21 11 32    00 FB       00       00    01                      00 00 BF 00 02 65
            ?           ?
 
LensID = 02 65 = 25858
RomRev = 81    = 0x81/32
AnfÖff = 26    = 3.67 (f/3.5)
Kl.Bl. = 50    = 22.63 (f/22)
Bl.Off = ??    = welche Brennweite gelesen?
Makrob = 0     = 0 (bit 7 von Bl.Off)
04
05
06
Brennw = 33(51)= 39mm (4.02191663*1.04546283^0x33(=51))
         32(50)= 37mm
         23(35)= 19mm falsch
         22(34)= 18mm falsch
 
der Rest ist nicht wirklich feststellbar.
 

Das Objektiv ist als einer der "ugly birds" sehr interessant, da es eine sonst nicht beobachtete Eigenschaft hat, die auf '8' endende LensID. Das wurde im Rahmen der LensID-threads schon diskutiert, also Hans: wäre sehr nützlich, wenn Du den Fehler, der das Auslesen stört, finden könntest.

gruezse, thomas

ZITAT(ddd @ 2010-04-26, 11:56) nochmal zu Hans' verbuggter Auslesung des 35-105/3.5-4.5n LensID 25858 (das einzige bekannte Objektiv, dessen LensID nicht auf '1' endet):[/quote]
Ich hab inzwischen auch Hans' Tracelog dieses Objektivs an der Minolta 5000 AF in CSV umgewandelt und mit einer überarbeiteten Fassung von CSV2LDMP (die auch mit den von OpenOffice erzeugten CSVs klarkommt) in ein Lensdump konvertiert (als LENSDMP2.BIN oben angehängt). Dabei ist allerdings nur ziemliches Chaos herausgekommen. Beide Tracelogs sind in dieser Form leider unbrauchbar, da die Logs mit erheblichen Lesefehlern behaftet sind.

@Hans:

Kann man bei Zeroplus die Schwellwerte für High- und Low-Zustände einstellen oder sind die fest vorgegeben oder sind sie von der Targetspannung abhängig? Hast Du "L2" (LVDD1) überhaupt angeschlossen oder nur "L5" (DGND)?

In der oben eingestellten Screencopy kann man leider nicht erkennen, mit welchen SPI-Parametern Zeroplus arbeitet. Probiere doch mal andere Trigger-Delay-Einstellungen aus und, falls es einen Dialog mit SPI-Einstellungen gibt, schreib mal, was da eingestellt ist. Bist Du sicher, daß Du auf die fallende Clock-Flanke triggerst und nicht auf die steigende mit einem kurzen Delay?

Viele Grüße,

Matthias

@ matthias

ich habe bei meinen Traces schon einige Fehlerquellen lokalisiert (manchmal sollte man doch das Manual genauer lesen ardon: )

Ich komme leider erst gegen Ende dieser Woche dazu, einen neuen Anlauf zu versuchen.

Bitte in bisschen Geduld, Ihr seid ja verboten schnell.
lg
Hans

moin, ZITAT(littlelamb @ 2010-04-27, 11:08) Bitte in bisschen Geduld, Ihr seid ja verboten schnell. [/quote]
nur die Ruhe!

Wenn Du schon Ideen hast, woran es liegt, brauchen "wir" ja erst mal nicht mehr nach dem Fehler suchen

Aber mal wieder was inhaltliches:

Die Brennweitenformel: Brennweite[mm] = 4.23204858*1.04427378^ROMWERT, R²=1.
Gefällt nicht?

Brennweite = 100*sqr (2^((ROMWERT-72)*0,125)). Diese Formel ist analytisch exakt.

besser? Kommt Euch bekannt vor? Schaut mal hier (post #27).
Genau, derselbe Aufbau wie die Blendenformel. Wetten auf das Format der übrigen nummerischen Parameter werden nicht mehr angenommen

Für die Darstellung in den EXIFs wird der Wert auf typische Stufen "gerundet", also wohl eher aus einer Tabelle entnommen.

gruesze, thomas

Hi Matthias, Thomas,

heute bin ich schon ein bisschen weiter. So wie's aussieht, habe ich die Lesefehler beseitigen können. Ich habe einen neuen Log mit dem 35-135n/3,5-4,5 (auf 35mm Brennweite eingestellt) angehängt. Ich hab die Datenpakete ab dem Einschalten der Kamera mitgeloggt. Denselben Trace mit der Minolta 5000 liefere ich am Wochenende nach.

Dann hab ich mir noch interessehalber zwei Objektive mitgetracet, und zwar das Sigma 75-200/2,8-3,5 , wovon eines an der 8000i problemlos funktioniert (Trace mit ...OK) das andere keinen Mux macht (die haben unterschiedliche ROM's drinnen, Trace mit ...FAIL). Vielleicht lässt das auch Rückschlüsse zu, welche Probleme mit inkompatiblen Sigma's auftreten, ich hab die Traces noch nicht angeschaut. Datenpakete ebenfalls ab Einschalten der Kamera.

Wünsche werden gerne entgegengenommen.

Lg
Hans

Ich habe mich auch recht lange Zeit mit den Objektiv-ROM-Daten auseinandergesetzt.
Ziel war es, ein Novoflex 600/8 an meine Sony Alpha 550 zu adaptieren - was auch geklappt hat (das Objektiv ohne automatische Belichtungsmessung zu nutzen ist schlicht nicht möglich).
Meine Erfahrungen und angesammelten Daten habe ich mal im zip-Archiv zusammengefasst:

- Erkenntnisse zum Protokoll (Lens ROM.xls) mit einer großen Sammlung an ROM-Daten
- EAGLE-Dateien für einen Objektiv-ROM-Adapter (eagle.epf, SOBROM.mpd, SOBROM.lbr, SOBROM.sch, SOBROM.brd)
- Layout & Lötstopplack-Folie (Ordner Fertigungsdaten)
- Assembler-Programm zur entwickelten Platine (Projekt SOBROM.aps) mit selbst erstellten ROM-Daten für ein Novoflex 400/5.6 (400.eep) und 600/8 (600.eep)
- Programm zum Auslesen der ROM-Daten mit einem ATmega16 auf dem STK500-Entwicklungsboard (Ordner LensROMRead)

Was ich noch feststellen konnte, ist die Tatsache, dass das Protokoll Timing-kritisch ist (obwohl man das bei SPI eigentlich nicht erwarten sollte). Die genaueren Timings sind mir aber leider veschütt gegangen, dürften aber durch das Ausleseprogramm rekonstruierbar sein. Der Protokolltyp selbst ist SPI mit LSB first und Mode 1.

Von Sony selbst ist keine Hilfe zu erwarten ("Bitte haben Sie Verständnis, daß wir einen derartigen Service leider nicht anbieten können.".

Ich würde mich freuen, wenn es gelänge, auch noch die restlichen Bytes zu dekodieren.

Hallo DanielSch!

Finde ich toll, dass du auch eine Lösung gefunden und dann noch umgesetzt hast.
Wo hast du die Paltine herstellen lassen bzw. hast du von dieser noch einige auf "Lager"?
Kann ich die von dir kaufen, um mein 200er mit den korrekten Daten zu emulieren?

Gruß,
Wolfram

Hallo Wolfram,

ich habe die Platinen selbst geätzt und gelötet. Allerdings sollte man dafür einige Erfahrung im SMD-Löten besitzen und möglichst auch ein Auflichtmikroskop.

Platinen hätte ich noch zwei auf "Lager", weiß aber nicht, ob die bei dir in den Objektivanschluss passen. Ich habe mal ein Bild davon gemacht, wie das bei meinem Novoflex gelöst ist. Denn auch dessen mechanischer Adapter ist selbst gedreht (habe bei Bedarf auch noch die Fertigungsdaten).

Falls du die fürs 200er benötigten Objektiv-Daten hast, könnte ich sie schon in eine der Platinen programmieren und dir senden. Preislich würde ich's auch nicht allzu teuer machen (Porto + Bauteilkosten; Arbeitszeit wäre unbezahlbar).

Hallo Daniel,

das ging ja schnell. Was ich dem Foto entnehmen kann, sitzt der Microcontroller kameraseitig, was eni Problem mit den Konvertern sein könnte wegen der Chiphöhe und dem geringen Spiel.

Im 200er ist die Bauteillogik im Gehäuse auf einem Flexiboard angebracht (Fotos davon gibt es weiter ob im Thread. Im Objektivgehäuse ist aber meines erachtens genug Platz den Controller im Gehäuse zu führen und mit den Objektivkontakten am Flexiboard oder am alten LensRom-Platz (was natürlich ausgelötet werden müßte). Am Microcontroller muss man, danach das Programm umschreiben da das Obejktiv noch 2 Schalter verwendet und in Abhängigkeit davon sich 4 Datensätze ergeben. Ein Schalter liefert an die Kamera eine Information über die "Nahdistanz" (1.5-2 m) und der andere Schalter ist die Fokusstop-Taste. Für die optimale Fokussierung erscheint mir der Indikator für die Nahdistanz am wichtigsten zu sein.

Ich werde mir das mal genauer im Objektiv ansehen und gebe dir Bescheid.

Danke für deine Hilfe.

Gruß, Wolfram