• 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 August 2025.
    Thema: "Kurven"

    Nur noch bis zum 31.08.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

Suche fähigen Elektroniker! ODER: Low-Budget-Blitzcomputer im Eigenbau...

Hallo Mueschel,

das was du schreibst klingt schon sehr sehr ähnlich unserem Vorhaben. Wir wollen auch ca. 3 Varianten der Gerätchen anbieten/ausklügeln, mit jeweils unterschiedlichen Möglichkeiten. Würde mich freuen dich an Bord begrüßen zu dürfen, hab dir eben die Zugangsdaten geschickt. Leider ist grad noch relativ wenig los aber das gibt sich...

Viele Grüße,
Flo
 
Hallo Flo,

für welche Schnittstellen (analog) fehlen Dir noch Schaltungen?

wenn ihr TRX Module verwenden wollt, gibt es auch eine Rück-Kommunikatin vom Blitz zum Steuergerät? Wie wollt Ihr die Zugriffssteuerung realisieren, damit nicht alle auf einmahl senden?


Grüße hot
 
Hallo hottube,

momentan siehts recht gut aus was die Schaltungen angeht (hab jetzt z.B. selbst ein Analog-Interface zum 45 CT-1 gestrickt gekriegt). Was eigentlich immer fehlt sind Leute die da ein wirklich tiefergehendes Verständnis davon haben, insbesondere um die Geschichte dann auch klein und sicher zu machen...ums mal einfach auszudrücken. Wenn du Lust hast dich mal durch unser Zeug zu wühlen und ein kritisches Auge drauf zu haben meld dich einfach nochmal, dann bekommst du Zugangsdaten...

Was die Rückkommunikation angeht steht im Moment zumindest der Blitzstatus in den Specs, mal schauen obs machbar ist :-). Ansonsten haben wir die TRX genommen weil sie nur unwesentlich teurer sind und deshalb für die Zukunft alle Möglichkeiten offen halten (und ein Device so sehr schnell von Slave zu Master werden kann). Betreffs des Protokolls wird dann wohl eine sehr stark abgespeckte Variante von CSMA/CA (wie bei WLAN) zum Einsatz kommen, also mit zufälligen Wartezeiten und Retransmit etc.
Da wir ja aber sehr wenige Datenrahmen zu übertragen haben wirds da denke ich eh wenig Probleme geben...auch solche Sachen wie das Hidden-Terminal-Problem haben denk ich in der Fotoblitzauslösung fast keine praktische Relevanz, daher kann man schonmal RTS/CTS weglassen...

Viele Grüße,
phlo
 
Hallo alle mit einander.
Eure Gedanken geistern mir auch schon eine Ewigkeit durch den Kopf. Leider habe ich vom Elektrotechnischenteil auch nicht so nen Plan.
Ich würde mich euch aber gern anschließen.
Vielleicht kann ich auch den ein oder anderen Gedanken beisteuern.

Meine Grobe Planung sah ein Steuergerät vor welches auf der Kamera Platz findet. An dieses sollten sich die Empfänger "anmelden".
Die Komunikation sollte dabei immer vom Steuermodul ausgehen.
Das heißt die Empfänger reden nur dann wenn sie vom Steuermodul angesprochen werden.
So kann man vermeiden das alle wild durcheinander reden.

Da ich auch ct-1 Benutzer bin hatte ich mir vorgestellt das man auch von Steuergerät die stärke des Biltzes einstellen kann.
Dazu müsste im Empfänger ein Mecamat simuliert werden.
Irgendwo habe ich auf diesem Board mal gelesen, das dass "relativ" leicht per µC und zwei Optokoppler gelöst werden kann.
Auch ein Rückmeldung an das Steuergerät, das der Blitz wieder fertig hatte ich angedacht.
Dazu müsste man die Spannung am Blitz messen.

Weiter als bis zur Anschaffung der RFM12 und nem Avr-Board von Pollin bin ich aber noch nicht gekommen ;)
Bin dann durch Zufall auf diesen Beitrag gestoßen.

Gruß
Christian
 
hmm, verstehe nur Bahnhof

was soll denn der Blitzcomputer machen ?

auf Kommando andere volle Pulle auslösen ? das können Tochterblitzauslöser schon, genau wie den Vorblitz ignorieren

oder etwa E (i) -TTL nachbilden, also gewichten und messen ? da wird ein Atmel wie auch immer zu lahm sein, bis der seine Berechnungen abgeschlossen hat, die Ergebnisse an Slaves im 2kHz-10kHz Takt RF12 o.ä. übermittelt hat ist der Verschluß wieder zu..............
 
Es gibt auch noch etwas das heißt Manueller Betrieb. Das heißt man legt vorher fest wie hoch die abgegebene Leistung ist. Hat also nichts mit ttl zu tun. Es wird einfach ein Wert eingestellt. Mit anderen Worten man soll am Steuergerät einstellen können: wenn du das nächste mal Blitzt dann doch bitte nur mit 1/8 der Leistung. Die Einstellung speichert der Empfänger und beim nächsten auslöse Impuls wird halt nur mit 1/8 geblitzt.
Ist also völlig zeit unkritsch.
Analog geht das mit dem Mecamat. Es sollte aber möglich sein das Verhalten des Geräts mit nem µC nach zu bilden. Also Blitzauslösen und nach x ms wieder löschen. Dazu verfügt der Metz 45 ct-1 einen speziellen Anschluss.
Ob es am Ende auch funktioniert weiß ich nicht aber es ist einen Versuch wert.
 
Es gibt auch noch etwas das heißt Manueller Betrieb. Das heißt man legt vorher fest wie hoch die abgegebene Leistung ist. Hat also nichts mit ttl zu tun. Es wird einfach ein Wert eingestellt. Mit anderen Worten man soll am Steuergerät einstellen können:

Befehlsübertragung und Auswertung sehe ich als zeitkritisch an !
es ist egal ob das Blitzstärke Kommando am Anfang oder Ende steht, wenn der Befehl kodiert ist und erst mal dekodiert werden muss dauerts IMHO zu lang.

wenn er nur auslösen soll ! brauch ich keinen µC, die Auslösestärke könnte dann evt. am Empfänger voreingestellt sein....

wenn du das nächste mal Blitzt dann doch bitte nur mit 1/8 der Leistung. Die Einstellung speichert der Empfänger und beim nächsten auslöse Impuls wird halt nur mit 1/8 geblitzt.
Ist also völlig zeit unkritsch.
Analog geht das mit dem Mecamat. Es sollte aber möglich sein das Verhalten des Geräts mit nem µC nach zu bilden. Also Blitzauslösen und nach x ms wieder löschen. Dazu verfügt der Metz 45 ct-1 einen speziellen Anschluss.
Ob es am Ende auch funktioniert weiß ich nicht aber es ist einen Versuch wert.

überleg doch mal Kommandolänge, Übertragungsdauer, auswerten, Takte, Verschlußsyncrondauer, bei 1/200s hat man 50ms, nicht viel Rechenzeit

kenne die Baudrate vom RM12 nicht, aber übliche 433 MHz Empfänger takten mit 2 kHz 0,5ms pro bit also 5ms pro byte , bekommt man maximal 10 byte übertragen und hat keine Zeit mehr zu interpretieren oder zu rechnen
 
Du verstehst mich falsch. Die Auslösung ist unabhängig von der Blitzregelung. Die erfolgt nur am Empfänger. In der ersten Stufen sollte die Einstellung auch nur am Empfänger vorgenommen werden.

Ich bin jedoch ein fauler Mensch und möchte nicht jedes mal wenn ich eine Einstellung vor nehmen möchte zu Blitz rennen. Das heißt ich verändere die Einstellung am Steuergerät an der Kamera die überträgt dann die Einstellung auf den Empfänger, welcher diese dann einstellt und speichert. An dieser stelle wird nicht ausgelöst, sondern lediglich die Einstellung verändert. Ist also nicht zeitkritisch. Die Einstellung bleibt erhalten bis ich sie entweder am Steuergerät oder am Empfänger wieder ändere.
Bei der Auslösung wird nur ein Kommando gesendet, nämlich feuer.

Das ganze ist kein "Muss" sondern eher ne Komfort Geschichte. Ginge ja auch erstmal nur mit den CT-1.
 
überleg doch mal Kommandolänge, Übertragungsdauer, auswerten, Takte, Verschlußsyncrondauer, bei 1/200s hat man 50ms, nicht viel Rechenzeit

Erklär mir mal wie du auf 50ms kommst? Der Auslöseimpulse kommt und dann hat man bei einer synczeit von 1/250 genau 4 ms bis der verschluss wieder zu ist. In dieser Zeit ist der Verschluss vermutlich für 1-2 ms komplett offnen damit die Blitzabbrenndauert reinpasst.
Würde gern mal messen wie das genau aussieht, aber das ist etwas schwierig.

Wenn die Funkübertragung nun 1ms dauert, dann kann man immerhin noch mit 1/200 blitzen. Je länger es dauert, desto kürzer wird die benutzbare sync zeit.

Kritischer als der Mikrocontroller ist das Funkmodul. Ein AVR könnte in 1ms immerhin bis zu 20000 Befehle abarbeiten. (bei 20 MHz)
 
Du verstehst mich falsch. Die Auslösung ist unabhängig von der Blitzregelung. Die erfolgt nur am Empfänger. In der ersten Stufen sollte die Einstellung auch nur am Empfänger vorgenommen werden.

Diese Idee hatte ich auch schon und habe mich damit vor etwa einem Jahr ausführlich beschäftigt. Es gibt aber ein paar Probleme damit.
Hauptproblem ist das die abgegebene Lichtmenge eine Abhängigkeit der Zeit besitzt und eine Abhängigkeit des Ladestandes des Kondensators. Sie ist also praktisch nicht vorhersehbar und deshalb bekommt man keine konsistente ausgabe hin. Das heißt wenn du nach 0,5 ms quencht, wird nicht immer die gleiche Energiemenge abgegeben. Man müsste über die Lichtmenge messen (wie das die Kamera über TTL macht) aber das lässt sich nur schwierig realisieren.

Wenn du eine Lösung für diese Probleme findest.. lass es mich wissen.
 
Erklär mir mal wie du auf 50ms kommst? Der Auslöseimpulse kommt und dann hat man bei einer synczeit von 1/250 genau 4 ms bis der verschluss wieder zu ist.

hab mich vielleicht verrechnet, aber 1/200 muss man ja nicht 1/60 reicht ja der Blitz ist eh maximal 1/1000 on, reicht zum einfrieren

Kritischer als der Mikrocontroller ist das Funkmodul. Ein AVR könnte in 1ms immerhin bis zu 20000 Befehle abarbeiten. (bei 20 MHz)

nun ja 20 MHz würde ich nicht gerade laufen lassen wenn der noch batteriekompatibel laufen soll, fg= 8MHz bei 3V somit wären es nur noch 8000 ein Byte Befehle, was nur selten klappt, wer will auf Libs verzichten ? und welche Befehle haben nur ein Byte ?
 
nun ja 20 MHz würde ich nicht gerade laufen lassen wenn der noch batteriekompatibel laufen soll, fg= 8MHz bei 3V somit wären es nur noch 8000 ein Byte Befehle, was nur selten klappt, wer will auf Libs verzichten ? und welche Befehle haben nur ein Byte ?

das ist mir schon klar.. aber auch 3000 befehle wär noch ne ganze menge und auch für kleinere berechnungen ausreichend.. Zeitkritischer ist die SPI schnittstelle zum Funkmodul und die eigentliche übertragung.

Aber das ist nichtmal das Problem an seinem Projekt, das ließe sich umgehen.
Das vorhin geschilderte Problem aber nicht.
 
die idee ist gut. bis ich erstmal vertanden hab, worum es genau geht ;) ich steh auch grade vor den nächsten tests mit meinen funkauslösern, die heute gekommen sind. alles ganz oldschool manuell. herrlisch !!! naja und ab und an kommt dann die idee, die manuellen blitze regeln zu können. technisch gesehen macht das sinn. aber beim aufwand sage ich mir, da kauf ich lieber gut einstellbare blitze und lass es dann krachen.

von der elektronischen seite sicher interessant, keine frage. aber wie wäre es denn, wenn die information für die intensität nach jedem schuss/auslösen übermittelt würde ? dann ist zwar noch der nächste schuss daneben, aber eine manuelle auslösung kan man ja auch einbauen oder aber nach dem einstellen der parameter einmal kurz auslösen.
also das auslösen selber kann man ja über normale trigger machen lassen, aber wenn der blitz dann auslöst, wird ein wartefenster geöffnet, welches zur datenübertragung ausreichen sollte. 1 sekunde könnte man ja mal ansetzen. das sollte reichen, da die blitze im ladefall eh was länger brauchen. die leistung kann man ja kodiert übertragen da sollten 4 bit schon reichen.

ich denke da an ein kistchen, mit drei oder 4 binärdrehschaltern und auch einer 4kanal fernsteuerung, die jedem der 4 empfänger dann die daten zusenden kann. bislang halt alles nur ideen.

gruß
 
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
 
WERBUNG
Zurück
Oben Unten