Funkauslöser advanced ATMEL / RFM12

[logout1984]

Hi *,

leider hab ich es noch nicht geschafft daran weiter zu arbeiten - zu viel was
noch eben schnell erledigt werden muß. Aber ich hoffe das es jetzt ruhiger wird.

Gruß
Logout

 

[berton]

Hi zusammen!

Ich würde auch bei eurem Projekt mitbauen wollen
Was ganz ähnliches habe ich vor einiger Zeit selbst schon einmal angefangen.
Der Grund für mich das Projet zu starten, war allerdings ein etwas anderer.
Ich habe bei ebay ein paar alte Bilze für 1€ bekommen, die richtig Power haben.
Per µC sollten die wollte ich dann die Leistung regelbar machen, weil die Blitze ansich nur 1/1 und 1/16 oder ähnliches können.
Das ist von der Regelung für mich etwas zu wenig.
Im Fotobereich bin ich noch relativ neu, im µC Bereich eher nicht.
Was ich mir vorgestellt hatte:

• Die Blitze sollten von der Leistung relativ gut regelbar sein (quench Signal)
• Auslösung wollte ich möglichst flexibel halten. RFM12 verbauen und zusätzlich noch ext. triggerbar, weil ich noch ein paar günstige Funkauslöser aus China habe. Ich denke, die sind schneller als das ganze Protokoll mt dem RFM12.
• LCD wollte ich garnicht verbauen, weil für mich alleine die Ansteuerung zu komplex war. Wollte alles per Schalter und LEDs regeln.
• Blitze sollen aktustisch und optisch signaisieren, wenn die feuerbereit sind (ein- und ausschaltbar)
• Das ganze sollte sich vom Rechner/Mobiltelefon komfortabel per Software steuern lassen. Leistung, Ready an den Rechner melden, Empfangsqualität, usw...
• Kamera Signale per Optokoppler getrennt
• Die Möglichkeit ein Einstelllicht anzusteuern

Ausgesucht hatte ich mir dazu ein Amega16. Ehrlich gesagt, habe ich aber schon garnicht mehr alles im Kopf.
Guckt einfach mal unter
http://code.google.com/p/pocflash/
und in die xls-Datei im Anhang.

Für das Quench signal hatte ich einen Timer vorgesehen.

Ich bin dafür, dass wir mal eine eigene Seite machen. Da können wir dann mal alle Anforderungen sammeln und mal abstimmen, was wir machen.
Hier im Thread ist es etwas schwer alle Anforderungen zusammenzubekommen.

 

[jar]

Im Fotobereich bin ich noch relativ neu, im µC Bereich eher nicht.
Was ich mir vorgestellt hatte:

• LCD wollte ich garnicht verbauen, weil für mich alleine die Ansteuerung zu komplex war. Wollte alles per Schalter und LEDs regeln.

Ausgesucht hatte ich mir dazu ein Amega16. Ehrlich gesagt, habe ich aber schon garnicht mehr alles im Kopf.

hmm, "eins von diesen dingen passt nicht zu den anderen" ........

schwirrt mir grad im kopp rum

bist du nicht neu in µC dann wähst du atmel und kennst dann die LCD.LIB nicht, fleury oder dannegger muss noch mal gucken, ist jedenfalls easy, lib einbinden C in Atmel Studio und Funktion aufrufen, was ist da schwer ?

 

[berton]

War für mich einfacher, als ein Menü in SW zu entwerfen, den Drehencoder auszuwerten usw...
Wollte mir den SW-Aufwand halt einfach sparen.
Klar gibt es für sogut wie alles SW Libs, aber die funktionieren auch nicht auf anhieb mit allem, was ich noch in meiner Bastelkiste habe. Da hatte ich für ein "kleines" Projekt einfach kein Bock drauf.

 

[VisualPursuit]

Ein Projekt das keine weitere Insellösung mit weniger als
10 Installationen werden soll sollte so geplant werden
dass ein Industriepartner daraus notfalls einen Bausatz
oder gar ein fertiges Gerät machen kann.

Ich wäre immer noch für 2,4 GHz und könnte mir gut vorstellen
dass jemand eine App für Eierphone oder Android schreibt,
die den Controllerpart übernimmt, also die abzufeuernde
Leistung einstellt, während ein deutlich simplerer Sender
den Feuerbefehl abschickt.

 

[berton]

Ein Projekt das keine weitere Insellösung mit weniger als
10 Installationen werden soll sollte so geplant werden
dass ein Industriepartner daraus notfalls einen Bausatz
oder gar ein fertiges Gerät machen kann.

Ich wäre immer noch für 2,4 GHz und könnte mir gut vorstellen
dass jemand eine App für Eierphone oder Android schreibt,
die den Controllerpart übernimmt, also die abzufeuernde
Leistung einstellt, während ein deutlich simplerer Sender
den Feuerbefehl abschickt.

Meinst du Bluetooth?
Prinzipiell geht das auch ohne extra 2,4 GHz Band.

# Das ganze sollte sich vom Rechner/Mobiltelefon komfortabel per Software steuern lassen. Leistung, Ready an den Rechner melden, Empfangsqualität, usw...

 

[Bernd71]

Bluetooth, IPhone, Android, Industriepartner, Produkt,...

Was soll das denn für eine Richtung werden? Ich würde erst einmal die Grundfunktion zum Laufen bekommen und die komplizierten Sachen weglassen.
Warum sollte ich am einem Smartphone die Blitzleistung einstellen wollen? Unpraktischer geht es wohl kaum, außer ich benutze das Gerät als Kamera.

Mein Tip: So einfach wie möglich starten. Controller mit Funkmodul. Kurzes Protokoll einfache Checksumme (kein CRC, nur einfache Addition, bzw. XOr). Wenn es dann Probleme gibt kann man es immer noch aufwendiger machen. Viele "Projekte" sind hier schon im Sand verlaufen, trotz oder gerade wegen hochfliegender Pläne.

 

[berton]

Bluetooth, IPhone, Android, Industriepartner, Produkt,...

Was soll das denn für eine Richtung werden? Ich würde erst einmal die Grundfunktion zum Laufen bekommen und die komplizierten Sachen weglassen.
Warum sollte ich am einem Smartphone die Blitzleistung einstellen wollen? Unpraktischer geht es wohl kaum, außer ich benutze das Gerät als Kamera.

Mein Tip: So einfach wie möglich starten. Controller mit Funkmodul. Kurzes Protokoll einfache Checksumme (kein CRC, nur einfache Addition, bzw. XOr). Wenn es dann Probleme gibt kann man es immer noch aufwendiger machen. Viele "Projekte" sind hier schon im Sand verlaufen, trotz oder gerade wegen hochfliegender Pläne.

Stimme ich dir vollkommen zu. Hauptsache erst einmal anfangen. Der Rest ergibt sich später.
Also los. Einfach mal zentral alle Anforderungen sammeln, gucken, welche schnell und einfach umgesetzt werden können und dann los.
Projekt muss halt irgendwie aufgesetzt/koordiniert werden.
Ich kann mich gerne nach den Feiertagen mal drum kümmern.

 

[logout1984]

Bluetooth, IPhone, Android, Industriepartner, Produkt,...

Was soll das denn für eine Richtung werden? Ich würde erst einmal die Grundfunktion zum Laufen bekommen und die komplizierten Sachen weglassen.

Viele "Projekte" sind hier schon im Sand verlaufen, trotz oder gerade wegen hochfliegender Pläne.

Hallo Bernd,
Hallo Berton,

erstmal willkommen im Club....
das mit den hochfliegenden Plänen und dem scheitern der Projekte sehe ich
genau anders. Viele Projekte scheitern, weil erst getan und dann gedacht
wird, aber dann ist es meistens schon zu spät und keiner hat mehr Bock
die gemachten Fehler zu korrigieren. Bei guter Planung kann man immer
noch nur die Basics implementieren, hat aber schon das Gerüst für
Erweiterungen.

@all,

ich weiß, ich bin arg im Rückstand, hatte ja versprochen die
Projektbeschreibung zusammen zu schreiben.... was soll ich sagen, Christ
Mast usw. hält mich noch davon ab, aber ich denke wenn das Beuteschlagen
vorbei ist, hab ich zeit an meinem Entwurf weiter zu arbeiten.

Gruß & schöne Feiertage
Logout

 

[Bernd71]

Erst anfangen und dann nachdenken: So habe ich das nicht gemeint. Ich würde mich zunächst auf die Kernfunktionen Auslösen mit kurzer Auslösungsverzögerung und Leistungsteuerung konzentrieren.
Welches Funkmodul nachher verwendet wird, wie viele Blitze angesteuert werden können, Steuerung über Display, Display zwei oder vierzeilig usw. Das sind Sachen die man anschließend je nach Bedarf erweitern kann. Bei privaten Basteleien finde ich frühe Erfolgserlebnisse wichtig für die Motivation, muss ja nicht wie auf der Arbeit sein. Aber das ist nur meine Meinung, andere sind da vielleicht disziplinierter.

 

[VisualPursuit]

Bluetooth, IPhone, Android, Industriepartner, Produkt,...

Was soll das denn für eine Richtung werden?

Eine die die Chance hat mehr als ein Dutzend Installationen bei
Hardcorebastlern und Programmierspezis zu schaffen.

Dafür muss eine Schnittstelle her die jeder Depp bedienen
kann, und das ist sinnvollerweise eine grafische Schnittstelle.

iPads, iPhones, Android, notfalls eine Applikation die auf
konventionellem WLAN aufsetzt und auf einem gewöhnlichen
Netbook, Laptop oder sonstigem Computer läuft für die
Steuerung und dazu dann ein Sender der nichts tut ausser
"Feuer" zu brüllen.

Ich hab SPOT verfolgt, und der Strobist Open Source Wireless
Controller ist auch nach vier bis fünf Installationen gestorben.
Zu allem Überfluss waren alle 5 Installationen anders, und jede
nur von einem erfahrenen Spezialisten und nur mit schwer zu
bekommenden Teilen nachzubauen.

Deswegen würde ich dafür plädieren das so aufzusetzen
dass ausser den aktuell beteiligten Entwicklern jemand eine
Chance hat das zu realisieren. Oder wahlweise eben dass man
das als Open Source so regelt dass notfalls ein Industriepartner
die Fertigung übernehmen kann.

Ich bin der Ansicht dass das Projekt eine Lücke schliessen soll
deretwegen Dutzende von Leuten schreien. Lasst uns das doch
so universell machen dass alle mitspielen können.

 

[VisualPursuit]

Kann jemand was zum Timing von WLAN sagen?
Ist es zeitlich möglich UDP zum Zünden zu verwenden?

Ich stelle mir folgendes vor:

1) Ein TTL-Blitz. Kann ein schimmliger Metz 30TTL1 sein, 5 Euro in der Bucht.
2) Ein Adapter der den Blitz festhält, und die Kontakte für Zündung, Feuer
und Quench nach aussen leitet:
So einer, wahlweise Canon oder Nikon.
3) Ein Kästchen mit WLAN drin, einer RJ45 Buchse, einem Klinkenstecker
zum Blitz und einem Miniphonestecker zum optionalen kabelgebundenen
Zünden.

Über das Netzwerkkabel wird der Client konfiguriert, bekommt eine ID
verpasst und das Timing für den jeweiligen Blitz mitgeteilt, das man
natürlich vorher auslitern muss. Ggf sagt man dem Blitz noch auf welchen
Sender er reagieren soll, dann brüllt der Sender eben nicht "Feuer"
sondern "Kai-Uwe", und jeder Client der auf Kai-Uwe programmiert ist
feuert dann eben.

Jeder Client kann dann von einem Netbook oder einem iPad sogar
mit grafischer Oberfläche gesteuert werden, Settings können
abgespeichert und wieder abgerufen werden, man hat alle Optionen
idiotensicher im Griff.

So ein Programm zu schreiben halte ich für nicht unmöglich.
Schaue ich mir an dass ein WLAN-Stick schon für 10 Euro geht
kann das auch nicht soo teuer werden.

Da ist dann nur die Frage ob das vom Timing her geht.

Wie hoch schätzt die Gemeinde den Aufwand ein den
Client per TCP/IP anzusprechen?

Oder gar einen Miniwebserver in den Client zu integrieren?

Bonbon ist dass man sich über die Zulassung nun gar keine
Gedanken mehr machen muss.

 

[Markus42]

3) Ein Kästchen mit WLAN drin, einer RJ45 Buchse, einem Klinkenstecker
zum Blitz und einem Miniphonestecker zum optionalen kabelgebundenen
Zünden.

Du willst also auch noch eine normalen Ethernet-Anschluß zusätzlich?

So ein Programm zu schreiben halte ich für nicht unmöglich.
Schaue ich mir an dass ein WLAN-Stick schon für 10 Euro geht
kann das auch nicht soo teuer werden.

Den Stick alleine schon, aber dann brauchst Du ja noch den PC dazu. Ich will nicht an jedem Blitz einen PC hängen haben.

Die Standard WLAN-Lösungen für Mikrocontroller sind eher teuer, siehe z.B.
http://www.watterott.com/de/Schnittstellen/Funk/WiFi-WLAN

Wie hoch schätzt die Gemeinde den Aufwand ein den
Client per TCP/IP anzusprechen?

Oder gar einen Miniwebserver in den Client zu integrieren?

Das ist alles ein riesiger Aufwand, ohne dass ich da einen echten Vorteil drin sehen kann.

 

[MasterFX]

Bei WLAN musst du mit Latenzen von bis zu 4ms rechnen. Das könnte schon knapp werden zumindest mit voller X-Sync. Wenn dann nur mit einem anderem 2.4GHz Protokoll, aber nicht IEEE 802.11.

Zur Codegröße nochmal was.
Bei meinem aktuellen Projekt mit LCD und Drehencoder komme ich inkl. kleinem Menü und relativ großer Timer ISR auf 2,1 KB an Codegröße.

 

[Markus42]

Eine die die Chance hat mehr als ein Dutzend Installationen bei
Hardcorebastlern und Programmierspezis zu schaffen.

Dafür muss eine Schnittstelle her die jeder Depp bedienen
kann, und das ist sinnvollerweise eine grafische Schnittstelle.

Fotoapparate wurden von den Menschen auch schon bedient, als sie noch keine grafischen Displays hatten.

iPads, iPhones, Android, notfalls eine Applikation die auf
konventionellem WLAN aufsetzt und auf einem gewöhnlichen
Netbook, Laptop oder sonstigem Computer läuft für die
Steuerung und dazu dann ein Sender der nichts tut ausser
"Feuer" zu brüllen.

Dazu muss aber nicht unbedingt das gesamte System WLAN sprechen. Dazu reicht es, wenn das die Steuerung kann.
Oder ganz ohne WLAN, einfach mit einem USB-Anschluss. Dann hat man eben eine GUI auf dem Notebook, den man für das tethered Shooting eh hat.

Ich bin der Ansicht dass das Projekt eine Lücke schliessen soll
deretwegen Dutzende von Leuten schreien. Lasst uns das doch
so universell machen dass alle mitspielen können.

Ich befürchte, das Projekt soll bei jedem eine andere Lücke schließen. Außerdem ist es wohl so, dass alle Beteiligten hier bereits Funktrigger haben, die sind bloß nicht komfortabel genug. Dadurch ist der Leidensdruck für eine ernsthafte Anwendung gering und der Spaßfaktor umso wichtiger.

 

[berton]

Meine Güte, hier hat sich ja schon wieder eine Menge getan.
Erst einmal frohe Weihnachten an alle!

Ich habe übrigens gerade in der Bucht ein i-TTL Flash trigger gefunden, der fast alle unsere Anforderungen erfüllt.
Vielleicht kann man sich da etwas abgucken. Angeblich soll das Teil bis 1/8000 Verschlusszeit funktionieren (2,4GHz) und lässt sich auch per PC steuern.
Googlet einfach mal nach tr-331.
Kennt jemand eine Seite, auf der man das Projekt mal vernüftig aufziehen kann?
Forum, Issue tracking, CVS/SVN,...???

 

[logout1984]

Hallo *,

Geschenke sind ausgepackt, Essen verputzt...

@VisualPursuit,

im Prinzip hast Du schon recht, IP wäre - weil ja schon da - ideal zumal das
Zünden der Blitze dann über Multicast stattfinden könnte. Wie allerdings
schon erwähnt sind die Hardwareanforderungen dann ganz andere.
Mal davon abgesehen, dass WLAN mit UC's (noch) nicht für kleines Geld zu
haben ist, sind auch die TCP/IP implementierungen für UC's ehr behäbig
(z.B. Adam Dunkels TCP stack, den ich übrigens für ein Musterbeispiel guten
Programmierens halte). Außerdem wäre ich mir nicht sicher ob die
Multicast implementiert haben.
Dazu kämen noch eine Reihe weiterer "Problemchen"....

@all
Was das scheitern der bissherigen Projekte angeht, denke ich es liegt
vorallem daran, dass Software Module nicht sauber getrennt wurden.
Ein Beispiel:
Natürlich kann man in den Routinen für's UserInterface (LC Display, Wippe,
Drehgeber, was auch immer) die Blitzparameter direkt setzten, nur ist man
dann genau and diese Hardwareroutinen gebunden. Besser geht's über
Funktionsaufruf wie z.B. set_quench_timer(uint16 timer); So kann das
UserInterface irgendwas sein (Wippe, über RS232 oder USB angeschlossenes
Notebook, AVR Webserver auf basis des ENC28J60 - gibt's übrigens gleich
fertig zu kaufen, AVR NetIO board + Erweiterung um z.B. RFM12 daran zu
betreiben, könnte also ein Gateway zwischen iPhone und Funktrigger
sein).
Das gleiche gilt auch für die Übertragungshardware (ob Kabel, Funk oder
nasser Wollfaden ist egal). Sauber getrennte Module ermöglichen es die
Routinen wieder zu verwenden. Adam Dunkels' IP stack ist das perfekte
Beispiel, weil er einfach keine Harwarespezifika enthält - um den nutzen zu
können muss man lediglich die Hardwaretreiber einbinden. Ich hab das mal
vor ein paar Jahren ausprobiert. Das war eine ziemlich einfache Geschichte
und bei weitem nicht so aufwendig wie das Programmieren eines eigenen
IP Stacks - was zumindest damals relative viele auf mikrocontroller.net
beschäftigte. Nichts gegen die Arbeiten, die damals gemacht wurden, aber
mir kam's so vor als würde man das Rad neu erfinden.

Als Projektseite, denke ich, würde sich sourceforge anbieten

So jetzt werde ich mal ein bisschen über die Projektbeschreibung
nachdenken und versuchen das zu Papier zu bringen.

Gruß & schöne Feiertage
Logout

 

[Bernd71]

Frage an die die hier nach WLAN, Bluetoth, TCP usw. rufen: Ist euch eigentlich bewusst was das bedeutet? Stichworte, wie Aufwand, Kosten, Reichweiten, Latenzzeiten...

Für eine SmartPhone Anwendung habe hätten ich gerne mal ein Anwendungsszenario. Beim Fotografieren hab ich die Kamera in der Hand, da will/kann ich nicht noch zusätzlich das SmartPhone jedes mal zücken wenn ein Blitz verstellt werden soll. Das möchte ich einigermaßen komfortabel auf der Kamera machen. Ich will doch nur Blitzleistungen einstellen, da reicht doch ein mehrzeiliges Display und ein paar Tasten.
Für die Steuerung über ein Notebook könnte man eine USB Anbindung für einen Sender vorsehen, das könnte ich noch verstehen. Man stöpselt einen Sender dann an die USB Buchse und kann dann per PC Programm steuern. Aber WLAN und Bluetooth würde ich mir nicht antun. Für die paar Daten braucht man keinen IP-Stack. Ein einfaches Funkmodul reicht doch dafür aus. Keep it simpel!

Btw.: Der TR-331/332 hat sich doch als Flop herausgestellt. Ist doch quasi nur ein Blitzkabelersatz für einen Blitz.

 

[berton]

Btw.: Der TR-331/332 hat sich doch als Flop herausgestellt. Ist doch quasi nur ein Blitzkabelersatz für einen Blitz.

Uh, das wusste ich nicht. Ganz schön teuer für ein Kabelersatz

 

[logout1984]

Frage an die die hier nach WLAN, Bluetoth, TCP usw. rufen: Ist euch eigentlich bewusst was das bedeutet? Stichworte, wie Aufwand, Kosten, Reichweiten, Latenzzeiten...

Für eine SmartPhone Anwendung habe hätten ich gerne mal ein Anwendungsszenario. Beim Fotografieren hab ich die Kamera in der Hand, da will/kann ich nicht noch zusätzlich das SmartPhone jedes mal zücken wenn ein Blitz verstellt werden soll. ....

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