So, jetzt muss ich als Projektvorantreiber in dieser Angelegenheit doch nochmal groß meinen Senf ablassen. Allgemein sieht es gerade so aus, dass wir durchaus schon einiges geschafft haben bis hin zum fertigen Schaltplan, allerdings machen wir das verständlicherweise nicht mehr hier im Forum, das wäre sonst der Informations-Overkill schlechthin. Um auch nicht zuviel Ablenkung durch irgendwelche "mal-reinschauen-und-alles-saugen"-Mitglieder zu erzeugen ist das ganze im Moment auch nur so halb öffentlich (wer mitmachen will muss sich bei mir melden). Es hat sich also durchaus was getan, nur momentan ist alles wieder etwas zum erliegen gekommen, woran aber mit auch ich schuld bin weil meine Lebensumstände leider grade nur wenig Zeit übrig lassen für das Projekt. Aber das Interesse ist vorhanden wie nie...
Zu den angesprochenen Problemen:
1. Die "Zeit bis zum Auslösen"-Problematik: Wir haben bisher ebenfalls so geplant dass der µC die Steuerungsinformationen "onChange" broadcastet an alle Clients, d.h. die werden beim Auslösepaket schon einmal nicht mit übertragen (und selbst wenn würde das rechnerisch noch grade so gehen). Weiterhin ist zur Unterscheidung verschiedener Gruppen ein CDM-ähnliches Verfahren vorgesehen, womit ein Auslösepaket insgesamt 8 bit haben wird. Ich habe Versuche mit einem AVR auf 8 MHz gemacht, bei denen ich die Zeit zwischen Interrupt von der Kamera (=Auslösung) und Zündung des Blitzes kontinuierlich vergrößert habe, und habe auf diesem (experimentellen) Weg festgestellt dass durchaus 4000-5000 Cycles (so um die 0,5-0,7ms bei 8 MHz) vergehen dürfen um bei einer Belichtungszeit von 1/500s (=2mx) garantiert noch die komplette Abbrenndauer im Zeitfenster zu haben. Das mag sicherlich auch noch durch andere Faktoren beeinflusst sein, aber es ist definitiv machbar. In 5000 Cycles optimiertem Assembler abzüglich der Laufzeit des Signals über Funk, SPI und sonstigen Unwägbarkeiten einen Blitz auszulösen ist kein großes Problem. Zumal die meisten Kameras ja dann wieder mit einer X-Sync-Zeit von 1/250 bedient sind.
Ich habe hier btw. einen Testaufbau stehen, bei dem ein AVR @ 8MHz über eine Fotodiode und einen Interrupt einen Blitz detektiert, dann über die Diode + ADC die Helligkeit mehrmals misst und integriert und dann passend zur Helligkeit über eine Kennlinie einen zweiten Blitz (45 CT1) ansteuert. Und das alles während der Verschluss offen ist und belichtet wird. Das ganze Teil ist zwar für sich relativ sinnlos (war gerade für die Blitzcomputer-Bastelei gedacht), zeigt aber wieviel machbar ist in der vorhandenen Zeit.
2. Die "Man kann den Blitz nicht exakt steuern"-Problematik: Das stimmt so nur zum Teil. Wir haben z.B. Schaltpläne und Kennlinien des 45 CT1 hier, welcher ja auch über einen Mecamaten in definierten Stufen in seiner Leistung eingestellt werden kann. Die Problematik bei den alten Blitzen ist, dass sie theoretisch schon während des Wiederaufladens nochmal ausgelöst werden können, so denn die Spannung überhaupt schon ausreicht um die Röhre durchzuzünden. Es gibt aber eine Schwelle (genau die Schwelle, bei der das "Ready"-Lämpchen angehen sollte), ab der die abgegebene Leistung durchaus vorherberechenbar bzw. linear ist, sonst würde ja auch die manuelle Regelung des Mecamaten niemals funktionieren. Diese macht im übrigen nix anderes als unsere Optokoppler-Lösung, sie sorgt als einstellbares RC-Zeitglied nach einer bestimmten, festen Zeit dafür dass der Blitz wieder abgewürgt wird...und wenn man dann bei der AVR-Lösung auch die Spannung am Blitzkondensator misst, und damit weiß ob der Blitz Ready ist oder nicht, ist das ganze kein großes Problem mehr.
Ich habe den Aufbau so schon auf einem Steckbrett vor mir und schon vor längerer Zeit Testfotos gemacht um herauszufinden welche Zeit welchem Wert entspricht, und die Lichtmenge war bei gleichen Zeiten auch definitiv gleich (zumindest innerhalb definierter Grenzen, für weniger als +/-5% Toleranz würde ich nicht meine Hand ins Feuer legen, hab aber da auch keine Messungen dazu).
Soviel mal von mir dazu,
Viele Grüße,
phlo