Funkauslöser advanced ATMEL / RFM12

[Bernd71]

Hallo Bernd,

das hast Du falsch verstanden, es geht nicht darum das zu machen, sondern
nur es beim Design zu berücksichtigen. Als Gelegenheitsknipser werde ich
wohl auch nicht 50 Blitze steuern wollen, aber es mag ja Leute geben die
das tun wollen und die drücken dem Assi dann sowas wie 'nen iPad in die
Hand mit dem dann sehr schnell aus hunderten von Presets ausgewählt
werden kann - schneller als mit Drehgeber und Zwei-Zeilen Display. Auch
hier geht es nicht darum das zu implementieren, sondern lediglich es vor zu
sehen.

Gruß
Logout

Warum sollte man Sachen berücksichtigen für die es keinen realen Bedarf gibt? Presets kann man auch auf den Gerät direkt speichern und auswählen. Mit Presets kann man wahrscheinlich sowieso nur bei wenigen Blitzen arbeiten. Ich würde meine Zeit nicht dafür verschwenden was eventuell jemand mal haben/verwenden möchte.
Man kann sich darin sicherlich reinsteigern und auch eine schicke Anwendung erstellen, aber warum nicht einfach. Für dein Szenario reicht eine USB Verbindung zu einem Notebook, das bei solchen Installationen eher vorhanden ist als ein iPad. Den USB Anschluss kann man sogar mit einem USB Adapter für Seriellen Schnittstellen realisieren. Dann hat man eine super einfache Hardware und alle Möglichkeiten. Eine SmartPhone Anwendng kann man dann so realisieren das es auf einen Sender an einem Notebook zugreift, wenn es denn sein muss.

Bei WLAN und Konsorten sollte man den Installationsaufwand nicht vernachlässigen! Man muss dann jeden Empfänger in das Netz einbuchen. Das ist ja auch nicht immer lustig. Außerdem sind Reichweiten ja auch noch ein Thema. Bluetooth scheide da ja sowieso schon gleich aus.

Controller, Funkmodul, Display und Eingabeelemente (z.B. Tasten). Das ist das was benötigt wird. Über die vorhandenen seriellen Schnittstelle kann man bei Bedarf einen PC/Notebook anschließen. Das ist doch eine gute Ausgangsposition, oder?

 

[Bernd71]

Eine Anforderung hätte ich vielleicht noch. Ein Empfänger sollte mehr als einen Blitz steuern können. So kann man mehrere Blitze zu einem zusammenfassen. Die könnte man in einem Gehäuse zusammenfassen und mit einem gängigen Bajonett für Lichtformer versehen. Dann noch ein Akkupack rein und schon hat man eine leistungsfähigen Blitz für unterwegs.
Die gängigen Bajonettdurchmesser reichen wahrscheinlich nur für zwei Blitze, vier wären schöner da hätte man dann ca. 400Ws Leistung.

 

[ulf_l]

Hallo Bernd

Da die Blitzleistung von außen nur über die Blitzdauer geregelt werden kann, müßte man eh zwei / vier "gleiche" Blitze zusammenschalten. Daher müßte das eigentlich keine Anforderung an den Auslöser sein.
Aber an sonsten bin ich ganz bei Dir. Am Anfang war das eine klar umrissene Geschichte, die sich mittlerweile so aufgebläht hat, daß es nicht mehr das ist, was mir dabei vorschwebt: Ein einfacher, kostengünstiger Funkauslöser, der die Blitzdauer per Funk eingestellt bekommt und das per X- und TTL.-Kontakt realisiert.

Gruß Ulf

 

[berton]

und? Gibt es schon was neues von der Projekthomepage?

 

[ElNinio]

Moinsen,

So ohne einen komentar der vielleicht auch kostruktiv ist möchte ich das ganze "Projekt" nicht an mit vorbei gehen Lassen.

So wie mir das scheint wollt ihr den Blitz über die Abbrenndauer Regeln A la Metz CT45 denke ich mal.

Kommen denn dan nicht mehrere Blitze "durcheinander" bei der Lichtmessung da ja alle auf einmal feuern. Vor allem wenn sie Nahe bei einander Stehen ?

Das andere was mir so im Kopf rumspinnt ist aus alten zeiten dieser CT Microkontroller Webserver mit dem man Relais schalten konnte über ein webinterface. So in der art wäre doch eine recht komfortable Steuerung bzw. Setup des Ganzen möglich. Über die W-Lan geschichte würde ich mir nicht all zu viele sorgen machen das würde sich mit einem Kleinen alten Acesspoint oder Router erledigen lassen. zumal man dort im gehäuse auch noch platz hätte um die "Blitzssteuereinheit" einzubauen. Anbschließend möchte ich noch los werden das die meisten Router ja über ein Netzteil meist mit ca 12 V versorgt erden, eine versorgung mit einem Bleiakku wäre demnach unproblematisch.


An sonsten würde mir eine recht einfache regelbarkeit der Blitze reichen. Eine Gruppensteuerung für bis zu 4 Gruppen, eine reichweite von ca 50m - 100 wäre natürlich toll, Und eine Blitzbereit LED am "auslöser" wäre auch dolle die angeht sobald alle blitze bereit sind.

Als Kleine ergänzug noch zu alle dem und gedankenanstoß möchte ich noch das alte SCA 333 (Minolta) (Metz 312 Canon, Metz 346 Nikon) ansprechen welches sich herforragend als AF Hilfslicht eigenet ansprechen und auch gleich einen Kamerasockel für jedes system mitbringt Den Trigger könnte man dort mit einem Gehäuse Oben drauf Kleben z.B.

 

[Markus42]

So wie mir das scheint wollt ihr den Blitz über die Abbrenndauer Regeln A la Metz CT45 denke ich mal.

Kommen denn dan nicht mehrere Blitze "durcheinander" bei der Lichtmessung da ja alle auf einmal feuern. Vor allem wenn sie Nahe bei einander Stehen ?

Welche Lichtmessung? Die gibt es an der Stelle nur bei iTTL/eTTL, aber ob das hier unterstützt wird ist eher fraglich.

Es geht einfach darum, die Blitze bequem von einer Stelle aus steuern zu können und da braucht man keine Lichtmessung.

Das andere was mir so im Kopf rumspinnt ist aus alten zeiten dieser CT Microkontroller Webserver mit dem man Relais schalten konnte über ein webinterface. So in der art wäre doch eine recht komfortable Steuerung bzw. Setup des Ganzen möglich.

Das wurde doch schon erwähnt. Damit brauchst Du irgendwas PC-artiges zum steuern - das will nicht jeder haben und ist vergleichsweise aufwändig.

Über die W-Lan geschichte würde ich mir nicht all zu viele sorgen machen das würde sich mit einem Kleinen alten Acesspoint oder Router erledigen lassen.

Das Problem ist, dass man vom Mikrocontroller aus auf den Acesspoint connecten muss (d.h. Auswahl des richtigen Accesspoints, Passwort eingeben usw.) und außerdem die WLAN-Module für Mikrocontroller relativ teuer sind.

 

[mysth]

Nabend zusammen,
den Thread hab ich eben erst entdeckt.

Ich hab mich mit dem Thema auch ganz unabhängig von dieser Diskusion
beschäftigt.

Ich seh das Problem nach wie vor in der Latenz.

Die mir bekannten Protokoll-Stacks haben dafür einfach zuviel Overhead..
Meine Überlegungen gingen dahin, das CD-Signal auszuwerten (nur für die Blitzzündung!), und da z.B. 3 100µs-Pulse mit jeweils 100µs Pause zu generieren, indem man einfach den Sender tastet.
Das kann ein Atmel problemlos auswerten, und incl. Software sollte das in ~600-700µs zu schaffen sein...(bisher nur eine Idee und nicht verifiziert...hab die PLL-Locktime nicht im Kopf)

Sollte noch Bedarf an einer Projekt-Seite bestehen, kann ich euch anbieten ein Wiki und/oder Forum auf meinem Server aufzusetzen.

Gruss

Harry

 

[VisualPursuit]

Warum sollte man Sachen berücksichtigen für die es keinen
realen Bedarf gibt?

Nun, *ich* hätte diesen Bedarf, und ich beschäftige mich ausreichend
lange mit Funkauslösern im fotografischen Umfeld um sagen zu können
dass es diesen Bedarf bei zahlreichen weiteren Fotografen gibt.

Was ich hier sehe ist dass jeder Teilnehmer genau sein persönliches
Szenario verfolgt, ggf ergänzt um seine Schwerpunktkenntnisse und
eventuell im Hinblick auf das ihm zur verfügung stehende Material
und Werkzeug.

Jeder dieser Einzelaspekte dürfte für einen anderen Interessenten
zum Ausschlusskriterium werden. Dann baut man ein schönes Wiki,
aber am Ende kommen drei völlig verschiedene Einzelinstallationen
raus die sonst niemand nachbaut - wenn es hochkommt. Alles
andere wird (wie in verschiedenen Projekten zuvor schon) nach einigem
Aufwand, ggf individuellen Kosten und investiertem Gehirnschmalz
im Sande versickern.

Eine auf WLAN basierende Variante mit Webserver drin wäre offen,
jeder könnte verwenden was er hat und für ihn passt. Netbook, Laptop,
Smartphone, iPad, iPod, stationärer Studiorechner.... vielleicht
sogar Spielkonsole. All diese Dinge könnten eingesetzt werden zur
Steuerung.

Das wäre für mich wie skizziert die ideale Lösung.

Die Diskussion erscheint mir momentan eher so dass man ein Werkzeug
gefunden hat (ATMEL/RFM12) und sich dazu das Problem überlegt
statt zu überlegen was so ein System idealerweise tun soll (und für
welche Zielgruppe) und dann herauszufinden wie man das schafft.

Ich würde meine Zeit nicht dafür verschwenden was eventuell
jemand mal haben/verwenden möchte.

Warum nimmst Du dann an dieser Diskussion überhaupt teil und
machst nicht gleich was für Dich allein?

Bei WLAN und Konsorten sollte man den Installationsaufwand nicht vernachlässigen! Man muss dann jeden Empfänger in das Netz
einbuchen.

Probleme die man vermutlich lösen kann.

Außerdem sind Reichweiten ja auch noch ein Thema.

Deswegen WLAN, die Reichweite sollte für die meisten Anwender
hinkommen.

Ich schreibe später mal ein paar Szenarien für die Anwendung.

 

[hottube]

hier ein weiteres Zettelchen für den Kasten...

Der Idee Blitzbefehl und Datenaustausch zwischen Master und Remote zu trennen kann ich nur zustimmen.
Zum Auslösen wird lediglich eine kurze Zeichenfolge ausgesendet. Die Remotes sind zu diesem Zeitpunkt bereits im Vorfeld mit allen erforderlichen Informationen versorgt worden. (alle Blitze)
Um mehrere Blitze zu verwalten ist es sinnvoll mit Gruppe zu arbeiten. 8 Gruppen scheinen mir noch gerade auf einem 2*16 / 3*16 Display (z.B. dogm LCD Module mit SPI Interface - spart Ports) zu verwalten zu sein.
Die Blitze können über die Gruppe angesprochen werden und z.B.in der Intensität angepasst werden.
Einzelne Blitze werden über die ID angesprochen, der Master ist für die hier verwendeten Parameter lediglich Terminal und stellt die Informationen die der Blitz sendet dar, und antwortet mit den Eingaben zum Remote. So bleibt das System offen und Erweiterungen in den Remote müssen nicht im Code am Master nachgezogen werden. So sind beliebige Spezialversionen realisierbar.
Remote dürfen nur antworten, wenn der Master diese angesprochen hat. Bei einem Scan-Befehl antworen alle Blitze, jeweils verzögert um ihre ID multipliziert mi n*ms. (z.B. nach dem Auslösen um ggf. Fehlermeldungen zu übertragen)


Die Organisation der Blitze könnte wie folgt aussehen:

Master auf der Kamera, verwaltet bis zu 255 Blitze in 8 Gruppen.

Jeder Blitz kennt
- seine eigene ID (1 .. 255)
- seine Gruppe ( 0..7)
- die ID seines Masters
- Seine Sende/ Empfangsparameter (Frequenz, Bandbreite, ...)
- - Interne Parameter
- - - Ladezustand des Akkus
- - - Ladezustand des Blitz Elkos (um bei kurzen Blitzfolgen bei noch nicht vollständig geladenem Akku eine definierte Lichtmenge abgeben zu können)
- - - Delay (uS um Blitze innerhalb einer Gruppe anzugleichen ( z.B. um Schatten zu reduzieren))
- - - Feldstärke des Signals vom Master (zur Analyse und Bewertung der Zuverlässigkeit)
- - - Repetition-ID innerhalb der Gruppe (so können z.B. 6 Blitze einer Gruppe genutzt werden, wobei nacheinander jeweils nur ein Blitz auslöst, so können kurze Serien weit unter der Ladezeit eines Einzelblitzes realisiert werden.)
- - - Aktiv (ON/OFF)


Gruppenparameter die der Master kennt:
- Gruppe (0..7)
- Blitz Intensität (0..100)
- Gruppen-Delay (n* ms) (z.B. für mehrfach Belichtungen)
- Repetition (on/off) (schnelle Blitzfolge für kurze Serien)



Für den Remote ist kein Display vorgesehen. Mit einer LED und einem Taster kann hier die ID des Blitzes und die Frequenz eingestellt werden. Danach kann das Modul über den Master erreicht werden - quasi ein Terminal-Mode um auf die im Blitz-Modul benötigten individuellen Parameter zugreifen zu können. Damit können auch unterschiedliche Module bedient werden, ohne Anpassungen am Master.


Wer unbedingt eine Grafische Oberfläche einsetzten will (auch zum Debuggen und Experimentieren gut zu gebrauchen), kann das RS232c Interface am am Atmega des Master mit einem BT222 Bluetooth Modul versehen und dies über Android, PC oder iPhone graphisch oder im Terminal ansteuern.

 

[ulf_l]

Nun, *ich* hätte diesen Bedarf, und ich beschäftige mich ausreichend
lange mit Funkauslösern im fotografischen Umfeld um sagen zu können
dass es diesen Bedarf bei zahlreichen weiteren Fotografen gibt.

Warum hast Du das dann nicht nicht gewinnbringend gebaut und vermarktet ?

Was ich hier sehe ist dass jeder Teilnehmer genau sein persönliches
Szenario verfolgt, ggf ergänzt um seine Schwerpunktkenntnisse und
eventuell im Hinblick auf das ihm zur verfügung stehende Material
und Werkzeug.

Das ist meiner Meinung nach auch der Sinn einer Stoffsammlung, Stichword Zettelkasten

Jeder dieser Einzelaspekte dürfte für einen anderen Interessenten
zum Ausschlusskriterium werden. Dann baut man ein schönes Wiki,
aber am Ende kommen drei völlig verschiedene Einzelinstallationen
raus die sonst niemand nachbaut - wenn es hochkommt. Alles
andere wird (wie in verschiedenen Projekten zuvor schon) nach einigem
Aufwand, ggf individuellen Kosten und investiertem Gehirnschmalz
im Sande versickern.

Das ist mal Deine Meinung ...

Eine auf WLAN basierende Variante mit Webserver drin wäre offen,
jeder könnte verwenden was er hat und für ihn passt. Netbook, Laptop,
Smartphone, iPad, iPod, stationärer Studiorechner.... vielleicht
sogar Spielkonsole. All diese Dinge könnten eingesetzt werden zur
Steuerung.
Das wäre für mich wie skizziert die ideale Lösung.

Ja, genau für Dich. Für mich wäre das der absolute Overkill, an jeden Blitz ein gerät mit WLAN zu hängen. Was für einen Zielpreis stellst Du dir denn für ein System aus Steuerung und sagen wir mal 8 Slaves vor ?

Die Diskussion erscheint mir momentan eher so dass man ein Werkzeug
gefunden hat (ATMEL/RFM12) und sich dazu das Problem überlegt
statt zu überlegen was so ein System idealerweise tun soll (und für
welche Zielgruppe) und dann herauszufinden wie man das schafft.

Hast Du mal zufällig einen Blick in die Überschrift und den ersten Beitrag des Threads geworfen ? Es ging darum kostengünstig eine Fersteuerung der Blitzleistung zu realisieren. Was ist da an der Kombi ATMEL / RFM12 so verkehrt.

Warum nimmst Du dann an dieser Diskussion überhaupt teil und
machst nicht gleich was für Dich allein?

Weil es bei einer Diskussion durchaus verschieden Ansichten gibt, die nicht immer mit deiner übereinstimmen müssen.

Probleme die man vermutlich lösen kann. Deswegen WLAN, die Reichweite sollte für die meisten Anwender hinkommen. Ich schreibe später mal ein paar Szenarien für die Anwendung.

Wie schon gesagt, halte ich das für absolut übertrieben, zu teuer und daher auch für nicht zielführend.

Gruß Ulf

 

[hottube]

Was ist da an der Kombi ATMEL / RFM12 so verkehrt.

Hallo Ulf, für den Anfang auch mein Favorit!
- Kostengünstig
- evaluation Boards verfügbar
- keine Spezialbauteile/Chipsätze
- bereits mehrere Projekte im Internet dokumentiert (Prove of Concept!!!)
- ausreichend weiterführende Dokumentation im Internet
- Tools allgemein Verfügbar

eine allgemeine Betrachtung der Frequenz:

Reine CW Basierte Sendesysteme, z.B. aus Funksteckoden sind zu störanfällig, FSK sollte es schon sein! 70cm ist OK wenn es auf Durchdringung von Mauerwerk ankommt, bei 2,4GHz geht dann nur noch LOS oder sehr kurze Strecken. Die Mobilfunker haben vor Kurzem nicht unerhebliche Summen ausgegeben um die unteren Bänder der Digitalen Dividende zu ersteigern.

Zigbee und Konsorten haben eine Sicherungsschicht, die sicherstellt, dass die Daten die bei A hinein gegeben werden auch sicher bei B ankommen, dass spart Code auf beiden Seiten, geht aber auf die Echtzeitfähigkeit, bzw Übertragungszeiten. Bluetooth ist ebenfalls nicht schneller, da auch hier Päckchen-weise gesichert übertragen wird.

WLAN wird (teilweise) in der Bühnen und Veranstalltungstechnik eingesetzt, Scheinwerfer sind jedoch auch weitestgehend keine Realtime Anwendung im 1/100 sek Bereich, zumal hier auch Sichtverbindung zu den Regie Pulten besteht. Auch angemerkt, dass das ganze nicht allzu zuverlässig ist, mit zunehmender Anzahl WLAN fähiger Handys die sich connecten wollen.

+++
Nachtrag: gerade mal die Ping-Zeiten zu meinem WLAN-Router mit meinem eeePC angesehen: minimal 2 ms, die meisten liegen zwischen 3 - 6 ms, Ausreißer bis > 100ms. (zum Vergleich bei einer 1/100 ist der Verschluss 10 ms vollständig geöffnet, bei 1/250 lediglich 4 ms)

 

[Markus42]

Was ich hier sehe ist dass jeder Teilnehmer genau sein persönliches
Szenario verfolgt,

Genau - so wie Du eben auch.

ggf ergänzt um seine Schwerpunktkenntnisse und
eventuell im Hinblick auf das ihm zur verfügung stehende Material
und Werkzeug.

Das stört mich zwar auch ein bischen, aber es läßt sich kaum vermeiden. Eine CPU in der Arm7-Klasse hat locker mal 1000 Seiten Dokumentation - da liest man sich nicht so schnell mal eben ein. Dazu kommt noch die Hardware (Programmer, Prototypen-Boards) die dann locker auch 100-200€ kosten. Da ist es durchaus verständlich, dass die Leute ihre Atmel AVRs bevorzugen.

Jeder dieser Einzelaspekte dürfte für einen anderen Interessenten
zum Ausschlusskriterium werden. Dann baut man ein schönes Wiki,
aber am Ende kommen drei völlig verschiedene Einzelinstallationen
raus die sonst niemand nachbaut - wenn es hochkommt. Alles
andere wird (wie in verschiedenen Projekten zuvor schon) nach einigem
Aufwand, ggf individuellen Kosten und investiertem Gehirnschmalz
im Sande versickern.

Man wird nie alle Bedürfnisse gleichzeitig befriedigen können. Deswegen findet z.Zt. die Ideensammlung statt und dann schaut man mal, was so machbar ist.

Eine auf WLAN basierende Variante mit Webserver drin wäre offen,
jeder könnte verwenden was er hat und für ihn passt. Netbook, Laptop,
Smartphone, iPad, iPod, stationärer Studiorechner.... vielleicht
sogar Spielkonsole. All diese Dinge könnten eingesetzt werden zur
Steuerung.

Also auf meinen bisherigen Telefonen waren HTML-Interfaces eher schrecklich zu bedienen. Da ist was selbstgebautes 10x besser. Andere Technologien (Java, Flash, native Apps) scheiden aber aus, da das nicht universell unterstützt wird.

Die Diskussion erscheint mir momentan eher so dass man ein Werkzeug
gefunden hat (ATMEL/RFM12) und sich dazu das Problem überlegt
statt zu überlegen was so ein System idealerweise tun soll (und für
welche Zielgruppe) und dann herauszufinden wie man das schafft.

Die Zielgruppe sind die Teilnehmer hier und wir finden gerade unsere Wünsche raus (Zettelsammlung). Wenn man mal von der WLAN-Thematik absieht passt das eigentlich auch ganz gut in einen Atmel AVR.

 

[hottube]

"Fotoopa" ist im Zusammenhang mit seinen Insektenfotos bereits hier im Forum zitiert worden - geniale technische Umsetzung! sowohl photographisch als auch technisch.

auch den RFM12 hatte er schon am Wickel: Timing: http://www.flickr.com/photos/fotoopa_hs/3778250766/in/set-72157604620957208/

RFM12 und Atmega sind mein Vorschlag und das Ergebnis von 2 1/2 Jahren die ich mich mit dem Thema beschäftigt habe. Theoretisch bis zu 1/250 und bis zu 100m Reichweite (LOS) im Rahmen der BNetzA erlaubten Parameter.
Ob der neue RFM22 eine Alternative für unsere Applikation ist kann ich noch nicht sagen. Leider ist dieser nicht Kompatibel und basiert auf einem anderen Chipsatz.
Vorschläge für Alternativen sind m.E. nach wie vor interessant.

Die Funk-Technik muss folgende Eigenschaften haben:
- Synchron alle Remote zum auslösen auffordern (Zeitkritisch)
- Kommunikation mit allen Remote ermöglichen
- geringen Energieverbrauch
- kostengünstig/ verfügbar
- EU Zulassung für Leistung und Frequenz (vorzugsweise 70cm)

++++
Hier noch mein "Usecase": meine 6 Blitze per Funk auslösen, Gruppieren und die Blitz-Intensität nachstellen. Optional Blitze definiert nacheinander auslösen.

 

[mysth]

VisualPursuits Kritik kann ich in den allermeisten Punkten nicht nachvollziehen.
Alle erfolgreichen OpenSource-Projekte haben irgendwann mal genau so angefangen wie dieser Thread.
Sicher sind die meisten über ein gewisses Stadium nicht hinaus gekommen....nur weiß man das vorher eben nicht.

Jetzt mal zur Technik:

An alle, die hier nach WLAN rufen: vergesst es!

Damit sind die geforderten Latenz-Zeiten nicht zuverlässig zu reallisieren.

Zum Thema RFM12 und Atmel:

Also erstmal ist der RFM12 eine naheliegende, und auch keine schlechte Wahl.
Das Ding ist zugelassen, sehr günstig und in D gut verfügbar.
Der Mangel an ausführlicher Dokumentation durch den Hersteller wurde inzwischen duch sehr viele Veröffentlichungen im Netz beseitigt.

Für die 8bittigen Atmels gilt das selbe: Sie sind sehr günstig, leicht verfügbar, fertige Programmieradapter sind für <20€ beschaffbar, oder für noch weniger Geld selbst herzustellen.
Leistungsfähige Programmierumgebungen stehen als Open-Source zur Verfügung.(ich verwende Eclipse und GCC)
Und die Leistung dieser Käfer reicht für das geforderte Einsatz-Scenario völlig aus.

Für den RFM12 gibt es sehr viele verschiedene Protkoll-Stacks, bei denen -je nach Ausrichtung- die unterschiedlichsten Prioritäten gesetzt wurden:

• Datensicherheit
• Multipoint Netzwerk (nicht zu verwechseln mit einer one-to-many Verbindung wie in unserem Fall)
• niedrige Latenz-Zeiten
  

Der letzte Punkt ist in unserem Fall wichtig!
Wenn wir von einer „sicheren“ Baudrate“ von 9600 Baud ausgehen, benötigt jedes Zeichen bereits ca. 1ms, und das ist imho bereits grenzwertig.
Mit steigender Baudrate sinkt die Verbindungsgüte.
Hinzu kommt, daß eine Header-Grösse von 2 Byte eine absolute Untergrenze bei allen mir bekannten Protokollvarianten darstellt. Zusammen mit dem einfachst denkbaren „Fire-Command“ (1 Byte) kommen wir auf insges. 3 Byte. Meist gehört mind. Noch eine Längenangabe und ein Schlussbyte dazu, womit wir bei 5 Bytes, und einer Latenz von min. 5ms. bei 9600 Baud wären, was für den Anwendungsfall völlig inakzeptable ist.

Als Lösung kann man jetzt entweder eine weitere Funkstrecke hinzuziehen -wie ja hier auch schon angedacht wurde- oder, man kann den RFM12 in einer Betriebsart betreiben, für die er eigentlich nicht vorgesehen war....aber das hab ich ja weiter oben bereits angerissen.

Die ganze Programmierung der Steuerung (von mir aus sogar remote E-TTL) seh ich überhaupt nicht als Problem an!

Die Herausforderung liegt imho darin, deterministische Latenzzeiten für den eigentlichen Blitz-Auslöseimpuls via RFM12 zu realisieren.

Gruß

Harry

 

[ulf_l]

[...]
Die ganze Programmierung der Steuerung (von mir aus sogar remote E-TTL) seh ich überhaupt nicht als Problem an!
Die Herausforderung liegt imho darin, deterministische Latenzzeiten für den eigentlichen Blitz-Auslöseimpuls via RFM12 zu realisieren.
Gruß
Harry

Hallo

Das sehe ich genau so. Wenn man sich das aber in aller Konsequenz vor Augen hält, ist das auch der Knackpunkt für den universellen Aufbau der Software. Man wird genau für diese Latenzzeit Alles rauskitzeln müssen, was die jeweilige Funkverbindungs-Hardware her gibt. Das läuft dann aber auf eine proprietäre Lösung hinaus.

Den Erfolg, gemessen in Anzahl der Nachbauten, sehe ich auch eher in der einfachen Verfügbarkeit,dem geringen Preis und möglichst unkomplizierte Bauteile. Hier spielt eben die Hardware noch die entscheidende Rolle, damit das alles auch von Leuten aufgebaut werden kann, die gerade mal wissen an welchem Ende der Lötkolben heiß wird. Auch Gehäuse sollten, ohne Fräsarbeiten daran vornehmen zu müssen, einfach und günstig zu beschaffen sein.

Gruß Ulf

 

[mysth]

Hallo

Das sehe ich genau so. Wenn man sich das aber in aller Konsequenz vor Augen hält, ist das auch der Knackpunkt für den universellen Aufbau der Software. Man wird genau für diese Latenzzeit Alles rauskitzeln müssen, was die jeweilige Funkverbindungs-Hardware her gibt. Das läuft dann aber auf eine proprietäre Lösung hinaus.

Hallo Ulf,
das ist in der Tat der Knackpunkt.
Das RFM12 wurde nie für solche Anforderungen designed.
Ich hab mir gerade das Datasheet nochmal zu Gemüte geführt.
Die einzige Chance, die ich sehe, wäre, per Software den Modem-Teil des RFM zu umgehen, und durch "Tasten des Senders" ein eigenes Telegramm zu erzeugen, welches auf der Empfängerseite natürlich auch wieder "zu Fuß" dekodiert werden muss.
Auf jeden Fall wird das softwareseitig ein ziemlicher Krampf.

Den Erfolg, gemessen in Anzahl der Nachbauten, sehe ich auch eher in der einfachen Verfügbarkeit,dem geringen Preis und möglichst unkomplizierte Bauteile. Hier spielt eben die Hardware noch die entscheidende Rolle, damit das alles auch von Leuten aufgebaut werden kann, die gerade mal wissen an welchem Ende der Lötkolben heiß wird. Auch Gehäuse sollten, ohne Fräsarbeiten daran vornehmen zu müssen, einfach und günstig zu beschaffen sein.

Gruß Ulf

Naja, falls es genügend Interessenten gibt, kann man drüber nachdenken, Leiterplatten herstellen zu lassen, und den weniger versierten Bastlern teilbestückte Platinen anzubieten, auf denen alle kritischen Bauteile (SMD) bereits bestückt ist.
Allerdings halte ich diese Debatte für verfrüht.

Gruß Harry

 

[ulf_l]

Hallo

Anbei mal mein erster Wurf für die Slave-Hardware. Da ich mich ja eher an die 45er von Metz halte ist das für die Allgemeinheit evtl. etwas zu speziell, aber als Inspiration vielleicht zu gebrauchen . Das Teil wäre ohne den Master auch schon als manueller Mecamat für die 45CT/CL4 zu gebrauchen. Leiterplatte wäre auch schon fertig und passen für das Gehäuse GEH KS28 von Reichelt. Bei den Funk-Modulen werde ich mich jetzt erst mal an den RFM70 versuchen.

Den Master bin ich noch nicht angegangen, weil mir da noch kein passendes günstiges LCD-Display über den Weg gelaufen ist. Wobei man das ja nur einmal für das Set bräuchte, könnte es auch eins der grafischen "DOGS LCDs" vom Reichelt werden. Ich hätte das halt gern hochkant mit vier Zeilen und da schaut es bei vergleichsweise kleinen Zeilen-Display eher mau aus. Als Gehäuse schwebt mir da ein defekter Systemblitz vor. Das hätte gleich den (für mich) passenden Blitzfuß und schon ein Batterie/Akku-fach mit drin.

Gruß Ulf

 

[Bernd71]

Vielleicht wirst Du hier fündig bzgl. eines günstigen Displays, falls Du pollin noch nicht kennst.

 

[ulf_l]

Hallo Bernd

Danke, aber Pollin kenne ich schon. Das 2-zeilige Display vom Slave ist schon von dort. Bei den grafischen gab's eben leider nix passendes für mich.

Gruß Ulf

 

[jar]

Hallo Bernd

Danke, aber Pollin kenne ich schon. Das 2-zeilige Display vom Slave ist schon von dort. Bei den grafischen gab's eben leider nix passendes für mich.

Gruß Ulf

hätte was, ist aber teuer, 30-50 €

Nachteil, läuft nur mit 3,3V , also Spannungsanpassung, 74HC4050 oder 4049 den nicht inversen Typ + 3,3V Regler und somit nur unidirektional, ist aber mit einem Buffer beherrschbar, man muss ja nicht das Display auslesen, kann Daten wie Displayinhalt, Zeilen und Spalten im Atmel buffern, braucht halt nur mehr Platz im RAM auch für Zeichensatz, was die kleinen Atmels ausschliesst, ich würde aber eh nix mehr unterm 644 nehmen, Geld kann dafür kein Argument sein