• Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2025
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien und Schutzgläser der Eigenmarken
    "Upscreen", "Screenleaf", BROTECT" und "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs Mai 2025.
    Thema: "Grün"

    Nur noch bis zum 31.05.2025 23:59!
    Jeder darf abstimmen!
    Zur Abstimmung und Bewertung hier lang
  • 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 ...

  • Nicht erreichbare Adressen im Benutzerkonto
    Wir bekommen zurzeit eine große Anzahl an E-Mails, die das System zum Beispiel als Benachrichtigungen an Nutzer verschickt,
    als unzustellbar zurück, weil z.B. die Adressen nicht erreichbar sind oder das Postfach gar nicht existiert.
    Stellt doch bitte sicher, dass die Benachrichtigungen, die ihr vom System erwartet, auch zugestellt werden können.
    Nicht erreichbare E-Mail-Adressen sind dazu wenig hilfreich.
    Danke!
WERBUNG

Funkauslöser advanced ATMEL / RFM12

logout1984

Themenersteller
Hi *,

es mag sein, dass es hier im Forum wenige gibt die mit der Thematik hinreichend
vertraut sind, aber ich versuch's einfach mal:

Worum geht es:
Sieht man z.B. strobist an, dann stellt man fest,
- dass Funkauslöser eine feine Sache sind
- dass man u.U. viel laufen muss bis man die Blitze eingestellt hat

Schließt man z.B. einen Metz 45CT4 (der für die strobisten Lösung ohne Modifikation
wegen unzureichender Regelbarkeit nur bedingt einsetzbar ist) über Optokoppler an
einen Mikrocontroller an läßt dieser sich wunderbar über x-sync zünden und über Quench
(TTL, auch wenn's dann eben nicht mehr TTL ist) regeln (z.B. zünde blitz und sende
nach 100 us Quench ~1/40 Leistung).

RFM12 sind Funksender/empfänger für microcontroller wie dem ATMEL. Damit ließe
sich u.U. ein Funkauslöser realisieren, wäre aber in anbetracht der Preise für billige
Funkauslöser wenig sinnvoll sowas selbst zu bauen. Anders wäre die Situation
allerdings wenn das selbst gebaute Funksystem ein paar goodies hätte die es bei
kommerziellen Produkten entweder nicht gibt, bzw. richtig in's Geld gehen. Es wäre ja
z.B. denkbar die Leistung der verschiedenen Blitze von zentraler stelle zu regeln, was
spätestens dann interessant wird wenn die Blitze z.B. weiter oben stehen oder in
irgendwelchen Lichtformern "verschwunden" sind. Für die Highspeed Fotografen könnte
ich mir vorstellen, dass Blitzverzögerung interessant sein könnte (x-sync kann ja z.B.
auch von einer Lichtschranke kommen). Statt nun die Position der Lichtschranke
solange zu verändern bis es passt, stellt man einfach eine Blitzauslöseverzögerung ein
(im Fall von Highspeed Fotografie aber vermutlich keine Auslösung per Funk, dass
könnte dann doch zu langsam werden).

Ich hoffe die kurze Beschreibung reicht um zu zeigen um was es geht....

Nun zu Euch:
Wenn man sich die oben skizierten Anforderungen ansieht, stellt man fest das es für
einen alleine eine ganze menge Arbeit ist und zwar nicht nur in bezug auf Programmieren
Blöten (Löten), testen, verbessern usw. aber auch in Bezug auf Ideen was so ein
System können sollte.

Stellt sich die Frage, ob sich hier ein paar Leute finden würden, die an so einem Projekt
mitarbeiten würden??

Um es gleich vorweg zu nehmen, selbst wenn mehrere daran arbeiten ist es noch
verdammt viel Arbeit, also ehr was für Hobby-Bastler und -programmierer (Leute die
spaß daran haben sowas zu machen - auf ähnliche weise entstehen ganze
Betriebssysteme und WWW ohne Apache wäre auch kaum denkbar). Trotzdem wäre
natürlich Input auch von Leuten die nicht aktiv an so einem Projekt beteiligt sind hilfreich
(z.B. "ich fänd eine Blitzverzögerung brauchbar und sie sollte zwischen 10 und 200 us
einstellbar sein", wäre ja etwas was man berücksichtigen könnte).

Also erstmal die grunsätzliche Frage (bevor ich in's detail gehen würde was schon da
ist, was gemacht werden muss, wie es gemacht werden müßte etc.):

Gibt's hier überhaupt Leute die Interesse an so einem Projekt hätten (aktive wie passive)??

Gruß
Logout


P.S. ich habe mal ein ähnliches selbstbau Projekt im Netz gefunden, leider schrieb der
Autor nur, dass er es gemacht hat, aber Schaltpläne und Code hat er leider vergessen
zu veröffentlichen.
 

Hi *,

so jetzt hab ich mir SPOT mal genauer angesehen... im prinzip geht es in die Richtung
leider sind IMHO eine ganze Reihe von Fehlern gemacht worden die es nun schwer
machen, dass Projekt zu implementieren bzw. vermutlich dazu führen werden, dass es
auf kurz oder lang eingeht.
  • das Nokia Display mag ja nett sein, aber kaum zu beschaffen (und als grafik display
    auch nicht so der hit was code größe angeht)
  • fixe hohe baudrate und ein protokoll was hohe baudraten erfordert. Zünden sollen
    z.B. alle Blitze gleichzeitig, das muss man nicht jedem Blitz einzeln mitteilen,
    ein broadcast genügt, wenn dem Empfänger vorher mitgeteilt wurde was er tun
    soll (z.B nur mit 1/64 Leistung blitzen). Dann klapp's auch mit 9600 was die
    Reichweite widerum erhöht.
  • keine Möglichkeit abbrennzeiten zu verändern und zu speichern, dabei hat der mega8
    ein eeprom das förmlich danach schreit
    usw. usw.

wenn man versuchen wollte SPOT an eigene Bedürfnisse an zu passen (z.B. ein
HDD44780 kompatibles Display, das es an jedem dicken Baum zu kaufen gibt), hat
man soviel zu tun, dass man es gleich ganz neu schreiben könnte.

tja, damit wäre ich wieder bei meiner ursprünglichen Frage:
Gibt's hier Leute die an einem solchen Projekt mitarbeiten würden??

Es geht nicht nur darum etwas zusammen zu schustern was funktioniert - oder auch
nicht - ala, schneiden wir mal Löcher in Salatschüsseln, sondern etwas zu entwickeln,
das gut funktioniert, weiter endwickelbar ist, eine gewisse hardware unabhängigkeit
hat (was einen hohen gard an software-modularität vorraussetzt) etc.
Technisch ist das Projekt mit den zur verfügung stehenden resourcen wie z.B.
die RFM12 Bibliothek von Benedikt K., die auch SPOT verwendet, keine große
Herrausforderung, aber man muss es richtig machen.


Gruß
Logout

P.S. vermutlich habe ich jetzt mit der Salatschüssel den/die letzten C Programmierer,
Elektronikfachfrau oder Mikrocontroller freak hier vergrault, weil er / sie gerade
dabei ist eben solche Löcher in Muttis Tupperware zu schneiden...
 
Moin, also ich wäre wohl dabei. Ich wollte eh demnächst mal das ETTL-Protokoll serialisieren um die ersten Schritte für die Funkübertragung zu machen. Ich habe auch zwei RFM12 hier rumliegen mit denen ich eigentlich mal eine Wetterstation bauen wollte, aber bisher nicht dazu gekommen bin. Oszi etc. ist alles vorhanden. Atmegas und Tinys habe ich hier ebenfalls genug rumliegen, ebenso wie Displays etc. Programmiererfahrung ist genug vorhanden, hatte nebenbei auch einen IR Auslöser für diverse DSLRs gebastelt (siehe HIER)
 
Moin, also ich wäre wohl dabei....


Hallo MasterFX,

na dann sind wir ja schon zu zweit, das ist dann ja mal ein Anfang.
Dann will ich mal ein paar Ideen zum Projekt in den Raum werfen:
Bevor es losgeht sollten wir uns ein paar Gedanken darüber machen, was
das System können soll (in erster zweiter dritter Stufe) und von anfang an
den code so gestalten, dass es hinreichend modular ist (IMHO einer der
größten Fehler bei vielen Projekten, erst wird programmiert und dann
nachgedacht, dann sind aber die Blitzroutinen schon in lcd.c drin).

Hardware und wie ich es mir vorstelle (das sind nur meine Vorstellungen,
Sinn und zweck dieser Übung ist es ja Ideen zu sammeln):
- Blitzcontroller (also das Gerät, über das die verschiedenen Blitze
eingestellt werden können), sitzt nicht auf der Kamera, da es mit
Display usw. es recht groß wird. Ich denke da ehr an ein externes Gerät, an
dem aber auch ein Blitz oder auch die Kamera über Kabel angeschlossen
werden kann (warum auch Kabel erkläre ich später).
- Funkauslöser für Kamera: sollte klein sein, ich könnte mir z.B. eine SCA
Adapter dafür vorstellen (hat auch gleich den Bateriekorb drin und gibt's
für kleines Geld in der Bucht). Der Funkauslöser der Kamera tut eigentlich
nichts außer den Zündenbroadcast zu senden. Einstellmöglichkeiten wären
dann nur noch ein paar Funkparameter z.B. über 7 Segmentanzeige
allerdings könnte ich mir vorstellen, dass es nett wäre einen Blitz auch
über Kabel daran anschließen zu können um z.B. einen Metz Stabblitz
wie gewohnt an der Kamera zu betreiben, dann müßte man noch Leistung
für den Kabelgebundenen Blitz einstellen können.
- Funkempfänger: Brauchen auch nur ein paar Einstellmöglichkeiten für
Funkparameter und BlitzID. Einstellungen wir quench timer etc. werden
über den Blitzcontroller erledigt.

Ich würde übrigens alles in 5V machen, dann läßt sich gleich der 10Mhz Takt
vom RFM12 für den AVR nutzen (der Mega8L mag halt nur 8Mhz und wir
wollen vielleicht nicht gleich von Anfang an etwas bauen was nur hin und
wieder funktioniert)
Als I/O system für den Blitzcontroller habe ich mir übrigens überlegt, das
ganze mit HDD44780 Display und Drehgeber zu machen (den Panasonic
Drehgeber von Pollin, der hat auch gleich noch einen Taster mit drin und
die SW Bibliothek gibs auch schon bei mikrocontroller.net), das Projekt sollte
aber so offen gestalltet werden dass man auch andere Lösungen einfach
implementieren kann.
Ich hatte übrigens noch Kabel als zusätzliche option erwähnt. Wie schon im
Eingangspost geschrieben, wäre die Funkzündung für "high speed" Fotografie
zu langsam, für sowas wäre die Kabellösung als zusätzliche Option bestimmt
sinnvoll.

Software:
- quench timer sollten veränderbar und abspeicherbar sein. Wer die
Parameter des Blitzes kennt, sollte die Werte abspeichern können (statt
alles im Programmcode zu hinterlegen und immer wieder neu zu comilieren
wenn ein neuer Blitz dazu kommt. Im Prinzip würde ich nicht die genauen
us werte abspeichern, sondern zähler für z.B. 5us delays.
Pseudo code on (das Beispiel hinkt, da die Reihe logarithmisch sein müßte,
aber egal):
qtimer={200,100,50,25,12}
qidx = 3;
FLASH;
for (i = 0; i < qtimer[qidx];i++) {
_delay_us(5);
}
QUENCH;
Die Werte im Array qtimer werden dann im eeprom hinterlegt und können
ggf. geändert werden.
Die software umfasst natürlich viel mehr, UserInterface, funkprotokoll etc.


Nimmt man nur das mal alles zusammen wird klar, dass man mit einfach
drauf los programmieren sehr schnell im Chaos landet. Die verschiedenen
Module müssen klar definierte Schnittstellen haben, sonst hat man nachher
was was evtl. funktioniert aber am Ende auf dem großen code
Komposthaufen /dev/null landet. Und wenn wir zu mehreren daran arbeiten
wollen, dann läßt es sich denke ich so am besten realisieren.

RFC (request for comments)

Gruß
Logout

P.S. ETTL u.ä. halte ich für ein sehr hochgestecktes Ziel, aber man wächst
ja mit seinen Aufgaben
 
Ja von dem Drehencoder habe ich mir auch zwei stück bestellt. Aber auch zum testen die von NOBLE, die sind noch ne Ecke kleiner.
Als Display sollte ein zweizeiliges Display eigentlich reichen, z.B. das LCD C0802-04 von Polling, kostet gerade mal 0,95€ und ist HD47780 kompatibel.
 
Hallo

Das hört sich spannend an :top:. Ich bin auch schon geraume Zeit mit so etwas am überlegen. Bei mir wäre auch die RFM12-Transceiver und die ATMega48 und kompatiblen in der näheren Überlegung gewesen. Für die Empfänger bin ich auch beim kleinen zweizeiligen von Pollin gelandet. Beim Sender hätte ich aber wiederum gern einen gehabt, der auf die Kamera paßt. Hier bin ich aber noch auf kein brauchbares Display gestoßen. Ein Zeilen-Display würde aber eigentlich auch hier reichen. Als Eingabe hätte ich aber lieber einen 4-Wege-Wippe genommen, da es sich damit , finde ich, leichter durch Menüs und dann in der quer-Richtung durch die Werte scrollen läßt.
Für die Spannungsversorgung wäre ich sogar auf 3V runter gegangen. Das spart nochmal Strom und hat bei mir zusammen mit dem Dragon-Board weniger Probleme als mit 5V gemacht.
Da in meinem Fall die Metz 45CT/CL4 bedient werden müßten, hätte ich die Empfänger über den Blitzakku mit versorgt. Nur der Sender hätte eine eigene Versorgung.
Mit den Daten hätte ich es ähnlich gemacht, wie logout1984 beschrieben. Die Blitze wären adressierbar, einstellung über Menu und Speicherung im EEPROM, und würden nur Ihre Daten einzeln bekommen. Das Auslösen dann über Boadcast. Als Quittung würden die Empfänger dann Ihrerseits ein alive und evtl. die aktuelle Akkuspannung zurück schicken. Dieser Datenaustausch würden dann alle Sekunde und beim Auslösen erfolgen. Da könnte man sich aber je nach dem wie hoch der tatsächliche Stromverbrauch ist noch drüber reden.
Die Empfänger wollte ich auch über den clock vom RFM12 versorgen, den Sender aber mit nur 1MHz vom internen RC-Oszillator laufen lassen. Dr braucht ja eigentlich keine genaue Zeitbasis.
Die Empfänger sollten auch ohne den Sender bedienbar sein. Soblad aber ein Sender in's Spiel kommt, sollte dieser führend sein.

Ach ja, als Layout-Tool hätte ich eagle bevorzugt. Das hab ich eben, und in der zu erwartenden Leiterplattengöße gibt es da ja die kostenlose Version.

So, das sind so meine noch etwas rudimentären Überlegungen dazu.

Gruß Ulf
 
Ja von dem Drehencoder habe ich mir auch zwei stück bestellt. Aber auch zum testen die von NOBLE, die sind noch ne Ecke kleiner.
Als Display sollte ein zweizeiliges Display eigentlich reichen, z.B. das LCD C0802-04 von Polling, kostet gerade mal 0,95€ und ist HD47780 kompatibel.

genau, 2 Zeilen sollten reichen, allerdings wäre ich mir nicht so sicher ob
2x8 Zeichen ausreichend wären, 2x16 ist vielleicht doch angebrachter.
z.B. Zustandsanzeige für 4 Blitze:

1 2 3 4
1 4 32 16

bei nur 8 Zeichen kommt man vermutlich schnell ins scrollen
und das LCD-Modul HMC16223SG kostet auch nur 1,95 und läßt sich
vermutlich ohne großes gefummel in ein Gehäuse einbauen.

Gruß
Logout
 
Hallo

Das hört sich spannend an :top:. ....

Hallo Ulf,

willkommen im Club und danke für deine Ideen, gut das sich hier ein paar
Leute finden, die soetwas realisieren wollen. Ich denke wir sammeln einfach
mal ein bisschen weiter Vorschläge und überlegen dann was wir wie machen
könnten ...

Weil es mir gerade noch eingefallen ist: Da alle Geräte das gleiche Medium
teilen wird etwas wie alle Sekunde senden vermutlich in die Hose gehen.
Hier ist ehr sowas wie CSMA/CD (carrier sensing, multiple access, collision
detection gefragt). Das Blitzprotokoll wäre dann ehr was wie ein Layer 2
Protokoll (im OSI model). Wenn man es schön designed ist dann auch die
Verwendete Übertragungstechnik egal (Kabel, Funk, nasser Wollfaden).

Nur einfach nochmal ein bisschen Futter zum d'rüber nachdenken.

Gruß
Logout
 
Zuletzt bearbeitet:
Hallo

Auch bei CSMA gibt es die Möglichkeit einen Supervisor zu bestimmen, wobei ich in diesem Projekt das dem Sender zugestanden hätte ;-). Den Zeitslot wann ein Empfänger sendet hätte ich dann einfach mit dessen Adresse verküpft sodaß die sich nicht gegenseitig in's Gehege kommen. Die Antworten der Empfänger sind ja auch wieder nicht zeitkritisch.
Ich denke mal um Kollisionen beim Datenverkehr müßten wir uns bei "unseren" Geräten weniger sorgen machen, als um andere, die sich eben auch in diesem freien Frequenz-Bereich tummeln

Ich muß aber zugeben, daß ich eher der Hardweker bin :o. und an diese Protokoll-Geschichten vielleicht etwas zu blauäugig dran gehe.

Nichts desto trotz ist sammeln erst mal eine gute Idee :D.

Gruß Ulf
 
Das Projekt hört sich interessant an, aber ihr diskutiert z.B. über Displaygrößen, obwohl ihr noch gar nicht festgelegt habt, was auf dem Display zu sehen sein soll. Oder die Idee mit den 5V, weil man damit den Quarz einsparen kann und der Mega8L offiziell nicht mit 10MHz läuft. Damit schränkt man sich aber selber ein - mal ganz abgesehen davon, dass ein Mega88 bei 10MHz auch laut Spec mit 3V auskommt.

Um wieder konstruktiv zu werden:
Ich habe Nikon SB25, die ich gerne steuern würde. Ich hätte auch gerne eine Erkennung, ob der Blitz wirklich ausgelöst hat. Und wenn man den Nikon-Blitzen ETTL beibringen könnte (für wechselnde Lichtsituationen), dann wäre ich wirklich glücklich.:)
 
Hi *,

@ Ulf, stimmt, daran hab ich im ersten moment noch nicht gedacht, der
"Blitzmastercontroller" polled einfach die einzelnen Empfänger (ganz wie mit
den Kindern zu Hause, die dürfen auch nur was sagen wenn sie gefragt
werden ;-) )

@ Markus, Du hast natürlich recht, es ist viel zu früh um über technische
Details zu diskutieren, aber genau genommen tun wir das auch garnicht.
Wir sammeln einfach mal Ideen. Was mich betrifft, stehe ich auf dem
Standpunkt, dass wenn das ganze gut gemacht wird - sprich es gibt eine
Reihe von Software Modulen, mit sauberen APIs - dann ist Display usw.
völlig egal. Wer statt Drehgeber Wippen benutzen will soll ebenso in der
Lage sein, dass zu implementieren wie der, der dann doch lieber das
Telepathie UI bauen möchte. Das gleiche gild auch für OSI layer 1, ob Funk,
Draht usw. geschickt gemacht ist der wechsel von einem Medium zu
nächsten relativ einfach.
Was iTTL ETTL oder was auch immer angeht, habe ich Zweifel ob das
machbar ist. Zum einem ist's recht proprietär zum anderem auch nicht
gerade super dokumentiert. Ich bin da jetzt nicht so der Experte, aber alles
was ich darüber bisher gelesen hab, läßt mich erahnen, dass das 'ne echte
Challenge werden wird, wobei der Wert dieser Features, zumindest bei
einigen Leuten hier, auch ehr angezweifelt wird.
Hast Du irgendwelche technische Dokumentation über ETTL ??


Gruß
Logout
 
Hallo

sehr interessante Sache die ihr vorhabt.

Ich würde mich gerne mit meinem bescheidenen Wissen einbringen.

Ich hatte zwar vor einen naja sagen wir sehr dumme Slave Steuerung für mich zu realisieren aber wenn ich mich an so einem Großprojekt beteiligen kann um dann doch an die gewünschten Funktionen zu kommen.

Zu mir ich habe etwas Erfahrung (ein wenig) mit Mikrocontrollern und Hardeware.

Ich würde gerne bei euch Mitmachen und naja an dem Projekt wachsen da ich sowas alleine niemals stemmen könnte.


lg Sven
 
Hast Du irgendwelche technische Dokumentation über ETTL ??

http://kzar.net/wiki/Photo/CanonE-TTLProtocol

http://billgrundmann.wordpress.com/2009/03/04/ettl-interface/
http://billgrundmann.wordpress.com/2009/03/10/ettl-continued/
http://billgrundmann.wordpress.com/2009/03/16/sniffing-canons-ettl-protocol/
http://billgrundmann.wordpress.com/2009/03/18/sniffing-canons-ettl-protocol-2/


Und hier http://userpage.fu-berlin.de/~schae/ETTL_protocol.html gabs mal Messungen zum Blitzprotokoll. Allerdings ohne allzutief reinzugehen, eher so der prinzipielle Aufbau. Die Seite gibts aber nicht mehr und ich kenne auch keinen Mirror (archive.org hat gerade "issues").
 
Zuletzt bearbeitet:
Hallo

Über so Sachen wie HMI schon mal nachzudenken finde ich auch nicht verwerflich da der grobe Funktionsumfang, über Funk Blitze auslösen, Blitzintensität einstellen, ja im ersten Beitrag schon genannt wurde.
Im Moment ist das hier eine "lose Zettelsammlung" und jetzt schon über die Wertigkeit von Vorschlägen zu urteilen finde ich in diesem Stadium eher kontraproduktiv.

Gruß Ulf
 
Hi Markus,

tja, da sind schon eine ganze Reihe von "unknows" drin und wie das ganze z.B.
mit zwei oder drei Blitzen funktionieren soll wäre mir dann endgültig
schleierhaft (woher soll z.B. die Kamera wissen, das Blitz 1 das Motiv, Blitz 2
aber den Hintergrund beleuchten soll - wie heißt es dann so schön, das macht
hell, aber es ist keine Beleuchtung).
Und das wäre ja nur Canon Kamera zu Canon Blitz. Canon Kamera zu Nikon
Blitz wäre dann noch übersetzten von ETTL zu iTTL (über das meines Wissens
nach noch viel weniger bekannt ist).
Ehrlich gesagt, halte ich das für unrealistisch.

Gruß
Logout
 
Hallo


Ich würde mich gerne mit meinem bescheidenen Wissen einbringen.


lg Sven

Hallo Sven,

willkommen in Club und keine Sorge wg. Wissen, bei so einem Projekt kann
man sich auf sehr unterschiedliche art und weise einbringen.

@all,

nochmal etwas für die lose Zettelsammlung:
Wenn's soweit ist, entsteht Software (die vermutlich auch zu einem nicht
unerheblichen Teil freie Bibliotheken verwenden wird). Ich würde sowas
unter GPL stellen. Für mich eine Selbstverständlichkeit und vielleicht auch
nur eine Kleinigkeit, aber muß natürlich nicht jedem so gehen daher sollte
man IMHO solche Spielregeln vorher vereinbart haben, dann gibts hinterher
keinen Knatsch.

Gruß
Logout
 
[...]woher soll z.B. die Kamera wissen, das Blitz 1 das Motiv, Blitz 2 aber den Hintergrund beleuchten soll[...]

Hallo

Eine Möglichkeit wäre: Die Kamera "sagt" welche Lichtmenge sie braucht und die Blitze würden dann relativ zueinander eingestellt.
Auch wenn ich jetzt gleich gegen meine eigene Aussage bzgl. Wertung der Vorschläge gehe :o: Ich bin bei mehr als einem Blitz auch kein Freund der Automatik(en).

Für den Zettelkasten:
neben dem Signal für das Auslösen und Löschen des Blitzes könnte man noch Eingänge am Empfänger für Blitzbereitschaft und erfolgreiche Auslösung vorsehen. Das wäre dann z.B. Infos, die dann zyklisch an den Sender geschickt und dort im Display dargestellt werden sollten. Beim Metz 45CT/CL4 wären diese Signale direkt verfügbar. Bei anderen Blitzen müßte man da evtl. drauf verzichten oder am Blitz noch "kreativ" werden. Ich würde das aber nur als Info darstellen und nicht mit der Auslösung verknüpfen.

Im Display des Empfängers würde ich die Adresse und die aktuelle Einstellung anzeigen. Da sollten 2 * 8 Zeichen reichen. Beim Sender wäre ein 4 zeiliges Display nicht schlecht. Hier könnte die Einstellung und Status von vier Blitzen (Adressen) gleichzeitig angezeigt werden.
Was meint Ihr:
Bis zu wie viele Blitze (Adressen) sollten da handelbar sein ?
Wenn man das mit der Status-Übertragung machen will, müßte jeder Blitz seine eigene Adresse haben. Gruppen mit gleicher Adresse gingen da ja leider nicht.

Gruß Ulf
 
Hi Markus,

tja, da sind schon eine ganze Reihe von "unknows" drin und wie das ganze z.B.
mit zwei oder drei Blitzen funktionieren soll wäre mir dann endgültig
schleierhaft (woher soll z.B. die Kamera wissen, das Blitz 1 das Motiv, Blitz 2
aber den Hintergrund beleuchten soll - wie heißt es dann so schön, das macht
hell, aber es ist keine Beleuchtung).

Wie ulf_l schon vorgeschlagen hat geht das mit fest eingestelltem Verhältnis. Ich denke das ist bei beim ETTL mit mehreren Blitzen und Original-Zubehör ganz genauso.

Und das wäre ja nur Canon Kamera zu Canon Blitz. Canon Kamera zu Nikon
Blitz wäre dann noch übersetzten von ETTL zu iTTL (über das meines Wissens
nach noch viel weniger bekannt ist).
Ich wollte das nicht nach iTTL umsetzen; ich bin mir auch gar nicht sicher, ob das diese alten Blitze schon können.
Bei ETTL mit mehreren Blitzen ist es so, dass der Master sagt, wann die Slaves den Messblitz zünden sollen sollen und wann sie wie stark den Hauptblitzen zünden sollen. Dann wäre die Frage, ob man mit beliebigen Blitzen den Messblitz hinbekommt. Reicht es, da einfach nur einen ganz kurzen Blitz auszulösen?
 
WERBUNG
Zurück
Oben Unten