DIY: Wireless-Funk-Transmitter mit dem Raspberry PI

[Racoon100]

Ein sehr gutes Projekt, ich bin begeistert !
Ich habe meine Wireless Lösung mit einem Hama W-USB Stick und dem gleichen Akkupack realisiert. Funktioniert auch sehr zuverlässig und schnell (5DMk2 RAW & JPG ca. 6-8s) und es sind keine Programmierkünste erforderlich ! Falls jemand mal schauen möchte... einen Bauplan gibt es auf Anfrage (info@fotolabsie.de)

Bilder per Funk-USB

 

[Marcus.]

...
Leider gibt es hier noch keine ftp integration in Richtung shuttersnitch (sftp mit keys ist leider nicht möglich -- wir kennen ja apple -.-). habe selber versucht ein wenig damit rumzuspielen, jedoch hakt es bei mir beim ausführen beim erstellen der mountpoints. ...

So auf die Schnelle würde ich sagen Du wirfst mal einen Blick auf curlftpfs. Damit kannst Du FTP-Verzeichnisse lokal mounten. Damit die lästige Authentifizierung erledigt ist, einfach eine Datei ".netrc" im Homeverzeichnis des PI anlegen (Rechte 600!) und dann z.B. so füllen:

machine <DeinFtpserver>
	login <DeinUsername>
	password <DeinPassword>

Ich werd das dei tage mal genauer anschauen und auch als mögl. Option mit einbauen.

....
Wie habt ihr den Raspberry eingehaust? Im Batteriegriff? Hatte überlegt am CAD ein kleines, 2-teiliges Gehäuse mit Batteriefach (4xaa oder aaa), an/aus Schalter sowie Leds zu erstellen, ...

Klingt auch sehr interessant diese Variante. Ich hab mir hier nen defekten BG-E7 besorgt und ausgeschlachtet. Bin aktuell noch am umbauen und ausprobieren, deswegen hab ich hierzu noch nichts gepostet.


@Racoon100:
Das ist endlich mal ne wirkliche gute Mod des WUSB von Hama. Würde es mir nur um die WFT-Funktion gehen, würde ich das sogar vorziehen.

 

[paynemaster]

Hallo,

curlftpfs hatte ich dafür auch schon angedacht und ausprobiert, aber die Authentifizierung ist echt blöd, wenn man es versucht in einer Codezeile zu lösen. Da ist das mit der .netrc sicherlich eine gute Lösung, die kannte ich noch nicht. Danke für den Tipp
Denke das iPad und Shuttersnitch ist etwas mobiler und schlanker als ein ganzer Laptop. und dafür gibt es ja auch Stativhalter.

Zum Thema Gehäuse bin ich am überlegen, auf den Blitzschuh hat ja doch einen Nachteil, man kann keine Funkauslöser für Blitze mehr verwenden, und ich denke mal der wft kommt überwiegend in der Studioumgebung in Einsatz. Als ich die Lösung von Racoon100 angesehen hab, kam mir die Idee, einfach einen Aluwinkel in die Stativaufnahme der Kamera schrauben und dann den Raspberry Seitlich an die Kamera. Da grabbelt man ja normal eh nicht rum, und der Usb ist ja eingesteckt und an die Anschlüsse muss man nicht weiter. Das spart ein teueres Spezialgehäuse und ist flexibel. Im Gegensatz zur Batteriegrifflösung verliert man auch keinen 2. Akkuplatz (gerade der ist ja durch den erhöhten Stromverbrauch sinvoll. Spannend wäre da nur eine Möglichkeit den Strom direkt zu zapfen, ohne extra Raspberry Akku..

Hoffe ich schaff es die Tage mich weiter mit dem Projekt zu befassen, neben dem Studium und den Klausuren.

Der Wusb ist soweit ich weiß aber nicht Mac kompatibel? und sind die Hama Wusb sticks noch lieferbar?

 

[chmee]

wie sieht es aus, wenn man rsync/compressed auf uncompressed runterschaltet? Da die Übertragungsrate im Status Quo eh lahm ist.. Ob nun compressed@0,5MB/s (->45s) oder möglicherweise bessere uncompressed@4MB/s (theor->5s) könnte für Zweiteres sprechen.. Ich werd mir die Sache mal mit Arduino anschauen.. deutlich kleiner, dabei geringerer Stromverbrauch..

 

[Schimpy84]

klingt auf jeden fall interessant....

aber in dem Bericht werden u.a. 900€ erwähnt?

ne 16GB WiFi Karte kostet vielleicht 50-60€ ? würde die nicht auch ausreichen?!

 

[chmee]

Ne EyeFi überträgt nur die JPGs (aber ist, wenn man nur dies braucht, eine tolle Lösung. Zuhause ankommen, Body anmachen, Kaffee trinken, währenddessen werden die Bilder auf den Rechner/NAS übertragen)

 

[paynemaster]

aber in dem Bericht werden u.a. 900€ erwähnt?

Das war denk ich mal bezogen auf Original WFT's vom Hersteller, für die DSLR Flagschiffe der großen Hersteller...

Ne EyeFi überträgt nur die JPGs (aber ist, wenn man nur dies braucht, eine tolle Lösung. Zuhause ankommen, Body anmachen, Kaffee trinken, währenddessen werden die Bilder auf den Rechner/NAS übertragen)

Hatte ich auch schonmal überlegt auszuprobieren, aber teilweise erschienen mir die Übertragungsraten nicht so super und auch der Empfang wurde mit daraufliegender Hand als nicht so super deklariert. Weiterhin stellt sich mir die Frage, wie sieht das mit der Schreibgeschwindigkeit/Zwischenspeicherung bei Highspeed bildrate aus? mit dem Raspberry kann man ja trotzdem schön Feuern und er überträgt dann nach und nach.

Ich werd mir die Sache mal mit Arduino anschauen..

Das wäre denke ich nochmal ein Sprung besser als per Raspberry?!

... Morgen gehts weiter, curlftpfs genauer antesten

 

[chmee]

Die EyeFi-Karte hat ja auch eigenen Speicher, da landen bei mir im 2. Slot die jpgs, erscheint dem Body also auch als "normale" SD-Karte. Autark pustet das EyeFi-System dann die Bilddaten auf den EyeFi-Server (der bei mir ne NAS ist)

 

[Marcus.]

Das Störende bei der Eye-Fi ist aber, dass zum einen der Ad-Hoc betrieb nach wie vor nicht richtig zu funktionieren scheint und was viel schlimmer ist, dass man zur Konfigurationsänderung immer eine Internetverbindung benötigt.
Und wie gesagt, die kann auch nur die JPEG's übertragen.

Ich hab nun allerdings eine "Nur-Jpeg" Option ins script eingebaut, und die Übertragung auf nen FTP-Server via curlftpfs+rsync ist auch schon drin.
Ich hab ausserdem den Abgleich angepasst (sollte nun schneller sein), muss aber erst nochmal messen.

Bin gerade am Doku überarbeiten, wenn die fertig ist, gehts online.

wie sieht es aus, wenn man rsync/compressed auf uncompressed runterschaltet?

Das muss ich mir auch nochmals anschauen, war der Meinung dass es beim übertragen von RAW Vorteile hat. Vielleicht mach ich ja auch nen Denkfehler.

Der Wusb ist soweit ich weiß aber nicht Mac kompatibel? und sind die Hama Wusb sticks noch lieferbar?

Nein, MAC Kompatibel ist er nicht. Ich hätte zunächst probiert ein XP in einer VM laufen lassen und über einen shared-Folder dem Host die Daten zur Verfügung zu stellen. Wenn dass nicht ginge, dann eben direkt das XP auf dem MacBook gebootet. Alles frickelei, ich weiss
Die Hama Sticks gibts AFAIK nur noch zu teuren Konditionen gebraucht, und ob der Nachfolgetyp eines anderen Herstellers geht weiss ich nicht. Da kann vielleicht Sascha (Racoon100) was dazu sagen.

.. Morgen gehts weiter, curlftpfs genauer antesten

Mach das mal. Ich habe derzeit das Problem dass curlftpfs die .netrc zu ignorieren schein wenn der Aufruf über die fstab erfolgt.
Soll heissen, curlftpfs auf der Kommandozeile direkt nimmt die .netrc, und wenn ich den entspr. Mountpoint in der fstab habe und ein "mount /mnt/ftp" mache, dann will er die credentials auch aus der fstab holen
Bin mal auf Deine Ergebnisse gespannt.

 

[chmee]

Kompression verbrät massig Rechenkraft. Mich würds nicht wundern, wenn die Transferraten uncrompessed deutlich steigen. Bin gespannt. Im Moment "könnte" (wird wohl) die Kompression der Flaschenhals sein.

 

[jar]

Die Hama Sticks gibts AFAIK nur noch zu teuren Konditionen gebraucht, und ob der Nachfolgetyp eines anderen Herstellers geht weiss ich nicht. Da kann vielleicht Sascha (Racoon100) was dazu sagen.

der hier ist lieferbar, sieht baugleich aus und wird es wohl auch sein, das Risiko einer Bestellung ist überschaubar

http://www.elv.de/olidata-wireless-usb-set.html

 

[Marcus.]

@jar:
Das ist genau den Nachfolger den ich meinte, danke.

Neue Version (v0.2) des wft.sh ist online, habe den Downloadlink im Post #2 aktualisiert.

Wesentliche Verbesserungen:

• Optional nur JPEG Transfer
• Transfer via ftp (Tablet-pc, Server)
• Schnellerer Transfer (22MB RAW etwa 12 sek.)

 

[paynemaster]

Heute(gestern) bin ich leider nichtmehr zur Bastelstunde gekommen, musste noch einige Fotos bearbeiten.
Morgen(nachher) sollte sich aber die zeit finden.

Funktioniert der FTP Upload aus dem script denn jetzt?

werde morgen mal direkt versuchen curlftpfs in die fstab mit username und password einzubinden, sodass das skript direkt mit mount auch mountet. dann sollte der .netrc eintrag ja eigentlich überflüssig sein.
Habe aber gerade gesehen, man könnte mit einem Makro in der .netrc ja eigentlich auch den mount definieren und dann das makro über das skript an der entsprechenden stelle ausführen wenn der ftp server via ping erreichbar ist.
Ich denke das größere übel ist die verwendung von port 26000 (shuttersnitch vorgabe, völlig banane) anstatt der üblichen 21

Aber irgendwie sollte das schon funktionieren.

Die EyeFi-Karte hat ja auch eigenen Speicher, da landen bei mir im 2. Slot die jpgs, erscheint dem Body also auch als "normale" SD-Karte. Autark pustet das EyeFi-System dann die Bilddaten auf den EyeFi-Server (der bei mir ne NAS ist)

nur sofern die Kamera 2 slots besitzt... sonst ist das auch eher schlecht. mir war schon bewusst das die eyefi auch speichert, aber ich hab das gefühl nicht in der geschwindigkeit wie die normalen extreme karten?!

der hier ist lieferbar, sieht baugleich aus und wird es wohl auch sein, das Risiko einer Bestellung ist überschaubar

naja 64€ ist schon ne stange geld... ungefähr soviel wie die Raspberry Lösung, und wenn einem der Raspberry nicht zusagt ist das immerhin noch nen gutes mediacenter....
Ich finds echt schade das es in richtung wireless usb keine wirkliche entwicklung gibt, der zug ist ja mittlerweile abgefahren da eigentlich so gut wie alles per wlan oder bluetooth geht, bis auf so kleine spezialfälle wie alte Drucker, oder unsere Dslr's
würden die auch mit Mac kompatibel sein, hätte ich glaube ich schon längst einen. aber vm ware auf dem late 2008 macbook ist immer sehr ressourcenunschonend und hungrig.

 

[Marcus.]

...
Funktioniert der FTP Upload aus dem script denn jetzt?
...
werde morgen mal direkt versuchen curlftpfs in die fstab mit username und password einzubinden, sodass das skript direkt mit mount auch mountet.

...
Ich denke das größere übel ist die verwendung von port 26000 (shuttersnitch vorgabe, völlig banane) anstatt der üblichen 21
...

Zitat gekürzt, um mal auf die wesentlichen Fragen/Punkte einzugehen

Ja, der FTP Upload aus dem Script heraus funktioniert nun.
Getestet habe ich es mit einem reinen FTP-Server, da mir der Preis von Shuttersnitch um nur mal eben die Funktion zu testen doch etwas zu hoch ist.
Ein freier/preiswerter FTP Server fürs iPhone hab ich auch mal "erfolgreich" testweise verwendet, allerdings durfte man da nur JPEG's übertragen. Wie ist dass denn bei Shuttersnitch? Akzeptiert das auch nur ganz bestimmte Dateitypen?

Ich habe es schlussendlich auch so gelöst das der FTP-User und dessen Passwort in der fstab stehen. Nicht gerade das optimale, aber innerhalb dieses Einsatzzweckes IMHO duldbar.

Bei Verwendung eines anderen Ports musst diesen einfach nach der Server-IP durch einen : getrennt angeben, also bei der fstab z.B:

curlftpfs#<FTP-USER>:<FTP-PASS>@<FTP-SERV>:<FTP-PORT> <MOUNTPOINT> fuse rw,user,users,noauto,allow_other 0 0

 

[paynemaster]

Akzeptiert das auch nur ganz bestimmte Dateitypen?

soweit ich weiß nimmt das alle Dateiformate für Bilder, zumindest alles was man so gänging mit ner DSLR erzeugt. Nikon Rohdaten sind jedenfalls kein Problem. auch die Übertragung war ganz ordentlich bei der variante mit gphoto tethered shooting. nur die gesamtlösung ist mit rsync hübscher und runder. die Geschwindigkeit war auch ganz ordentlich.
ganz gut gefällt mir bei shuttersnitch, das er neu empfangene bilder auch direkt anzeigt.
Ich werd mich jetzt auch nochmal dran versuchen

 

[Marcus.]

soweit ich weiß nimmt das alle Dateiformate für Bilder,

Bedeutet für mich, es nimmt nur bestimmte Dateitypen.
Konkret geht es mir darum, dass dann wahrscheinlich die wft.pid und jetzt auch noch die tasklist.txt dort nicht abgelegt werden können.

Kannst Du das mal probieren?

 

[paynemaster]

Also ich hab gerade auch mal bisschen rumgebastelt, erst mein modifizierte script aus meinem alten gphoto tether und teilen des wft v0.1 versucht,
dann weil ich fehler beim mounten hatte, den krams vom raspberry geschmissen und das wft v0.2 drauf und konfiguriert. aufgefallen ist mir dabei, dass in der config als DEST_DIR="/Users/$User/..." angegeben ist. bei mir unter wheezy gibts das Users gar nicht, da liegt der $User under /home/ vielleicht sollte man das nochmal anpassen, dadurch hat er natürlich erstmal den fstab eintrag nicht gefunden weil der auf /home/ und nicht auf /User/ gerichtet war. nichtsdestotrotz habe ich einen ähnlichen Fehler gehabt wie bei meinem script:

fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
fusermount: failed to unmount /home/snitch/Nikon: Device or resource busy
Error in ioctl: No such device

Die verzeichnisse wo die Mountpoints liegen sind alle leer. auch das ftp serververzeichnis und die speicherkarte der Kamera. ich bin mir nur nicht sicher ob es eine rolle spielt, das bei der kamera gphotofs ja ins basisverzeichnis mountet, die aufnahmen aber in unterverzeichnissen liegen (in meinem fall: "/store_00010001/DCIM/100NCD90/") und das ipad die fotos halt direkt im gemounteten ftp verzeichnis haben möchte.
der einzige unterschied zum Fehler meiner Scriptversion ist, das Device or Resource Busy.. da hatte ich Permission denied bei meinem...


Habe gerade getestet, man kann bei shuttersnitch alles draufschmeissen, ne wft.pid hatte ich sogar schon drauf, hab dann einfach mal eine .txt dazugeworfen, kein problem. er zeigt halt in der app selber nur die fotos an, das hab ich bisher mit .nef und .jpg getestet. interessant ist, das man sammlungen erstellt und er den ftp server nur öffnet wenn eine sammlung gewählt ist. per ftp kann man dann nur auf das der sammlung zugehörige verzeichnis zugreifen, bzw.. ist das auch gleich das homeverzeichnis.

wenn interesse besteht hänge ich meine scriptversion mit teilen aus dem wft v0.1 und meiner alten lösung an den post an, aber ich denke das gibt nur unnötig verwirrung und ich glaub es ist effektiver wir gehen einen weg ich werd demnach mein script erstmal beiseite legen und schauen das ich das wft0.2 zum laufen bekomme. Individualisierungen wie z.b. LED ansteuerung kann man ja immernoch machen

 

[Marcus.]

...aufgefallen ist mir dabei, dass in der config als DEST_DIR="/Users/$User/..." angegeben ist. bei mir unter wheezy gibts das Users gar nicht,...

Lies nochmal die Beschreibung in der wft.conf
Da steht nämlich bei DEST_DIR:

Verzeichnisname in welchem die Daten abgelegt werden sollen.
Entspricht entweder dem kompletten Pfad auf dem Zielsystem wenn direkt per rsync via ssh gesichert wird, oder bei Verwendung eines FTP/Windows-Shares dem Namen des lokalen Mountpoint.

Heisst konkret, wenn ich aufs MacBook übertrage, dann habe ich dort den Ordner "/Users/marcus/Pictures/wft".
Zufälligerweise heisst mein user auf dem PI auch marcus, weshalb in diesem Falle "/Users/$USER/Pictures/wft" passt.
Wenn ich jedoch auf einen Windows- oder FTP-Share synce, dann steht da bei mir "/home/marcus/blubb", wobei ich den entspr. share eben nach /home/marcus/blubb gemountet habe.

Bezüglich Deines Mountproblems ist nun folgendes interessant.
Hast Du, wie in der README beschrieben:
- Deinen Benutzer zur Gruppe fuse und zur Gruppe plugdev hinzugefügt?
- Die /etc/fuse.conf angepasst?
- Den Mountpoint in die /etc/fstab aufgenommen?
- Den testweisen Mount der Kamera ausgeführt?

Die Mountpoints selbst müssen vom User angelegt werden !

Bei Canon sieht die Verzeichnisstruktur ähnlich aus (z.B. /store_00010001/DCIM/490_CANON/12345.jpg), das soltle also nicht das Problem sein.

 

[paynemaster]

Lies nochmal die Beschreibung in der wft.conf
Da steht nämlich bei DEST_DIR:

Ja ok wer lesen kann ist im Vorteil keine ahnung was mich da geritten hat.

- Deinen Benutzer zur Gruppe fuse und zur Gruppe plugdev hinzugefügt?

jep

- Die /etc/fuse.conf angepasst?

jep

- Den Mountpoint in die /etc/fstab aufgenommen?

jep, steht drin, auch mit 2 leerzeichen getrennt immer mit nur einem funktioniert es ja nicht.
muss der gphotofs mountpoint da auch eingetragen werden? wenn ja, wie?
mit gphotofs <mountpoint>?

- Den testweisen Mount der Kamera ausgeführt?

Ja schonmal irgendwann, aber könnte ich ja nochmal testen.

ich werde bei Gelegenheit (vl. Samstag) die einzelnen Schritte nochmal genau prüfen...

Bei Canon sieht die Verzeichnisstruktur ähnlich aus (z.B. /store_00010001/DCIM/490_CANON/12345.jpg), das soltle also nicht das Problem sein.

Da war mein gedanke, das er im Dest_DIR auch diese Unterverzeichnisstruktur bastelt.

 

[Marcus.]

muss der gphotofs mountpoint da auch eingetragen werden? wenn ja, wie?
mit gphotofs <mountpoint>?

Nein, der muss nicht in die fstab.
Gphotofs arbeitet da sehr seltsam und so richtig verstehen kann ich das auch nicht, liegt aber wohl an der libgphoto2 auf die es aufbaut.
Die Quelle wird immer dynamisch ermittelt, nur das Ziel (also der Mountpoint) muss vorgegeben werden.

Wenn ich es recht sehe, dann klappt bei Dir das mounten, nur das anschließende umount (via fusermunt -u ...) geht dann schief, richtig?
Kannst Du unterschiedliche USB-Modi an Deiner Kamera einstellen?

Da war mein gedanke, das er im Dest_DIR auch diese Unterverzeichnisstruktur bastelt.

Nein, das wollte ich unbedingt vermeiden.
Es werden immer nur plain die Bilddaten im Zielverzeichnis abgelegt.