DIY: Wireless-Funk-Transmitter mit dem Raspberry PI

Marcus. · 3 Januar 2013

Hallo Leute,

im Moment beschäftige ich mich mit dem Bau eines WFT auf Basis eines Raspberry-PI.

Wer das Gerät noch nicht kennt, kann sich hier oder hier ein wenig umsehen.

Eingesetzte Hardware:
- Raspberry PI (Bild 1)
- WLAN-Adapter (Bild 2)
- Portabler Akku
- Optional zur Statusanzeige: RGB LED

Aktuelle Features:

Optional koennen nur JPEG's uebertragen werden
Zielsystem kann via ssh, smb oder ftp angesprochen werden
Uebertragungsdauer für ein 22MB RAW ca 12 sek!

Erfolgreich gestestet mit folgenden Kameras:

Canon EOS 5D
Canon EOS 5D MK2
Canon EOS 5D MK3
Canon EOS 7D
Canon EOS 50D
Canon EOS 300D (mit 10D FW)
Nikon D90

Erfolgreich getestet mit folgenden Zielsystemen:

MacBook mit OSX (via ssh)
MacBook mit Win-XP (via smb)
PC mit Linux (via ssh)
PC mit Win-XP (via smb)
iPad mit Shuttersnitch (via ftp)
iPad mit Shuttersnitch (via webdav)
Native FTP-Server (via ftp)

Das Projekt ist in zwei Teile untergliedert,

Realisierung der Software bzw Konfiguration des PI
Modifikation eines BG um den PI nebst Akku einzubauen

Die Software funktioniert mit Canon sowie Nikon als Quelle und mit Linux, Mac-OS und Windows XP (und höher) als Ziel.
Mangels Eigentum von Geräten anderer Hersteller kann ich leider nichts zu Sony, Pentax usw, sagen, wäre hier also auf das Feedback anderer angewiesen.
Hier bräuchte ich bei angeschlossener und eingeschaltener Kamera die Ausgabe des Befehls

lsusb -vv

und die Information ob sich überhaupt noch Fotos in dieser Betriebsart machen lassen (ggfs. muss man den USB Modus im Menu der Kamera passend einstellen).

Es würde mich freuen wenn hier Mitstreiter, Tester oder Ideengeber einen wesentlichen Teil zur Verbesserung beitragen.

Dieser Post soll allg. Informationen über das Projekt enthalten,
Post #2 befasst sich mit der Software und Funktionsweise
Post #3 wird den Hardwareumbau beinhalten

Installation:
Das Paket beinhaltet nun eine README mit der Installations- und Konfigurationsanleitung.

Download:
Das WFT-Paket: http://www.distorted-photography.com/projects/wft_pi/

Marcus. · 3 Januar 2013

DIY: Wireless-Funk-Transmitter mit dem Raspberri PI - SOFTWARE

Pruefen der Kameraunterstuetzung:
Die Kamera muss entweder per Mass Storage oder PTP ansprechbar sein. Hierzu die Cam am pi anschließen und in den Aufnahmemodus wechseln
Danach in einer Konsole den Befehle „lsusb -vv“ ausführen.
Man sollte einen Abschnitt betreffend der Kamera mit folgenden Angaben erhalten:

Code:

	Bus 001 Device 004: ID 04a9:319b Canon, Inc. 
	Device Descriptor:
	…
    	Interface Descriptor:
    	...
      	bInterfaceProtocol      1 [B]Picture Transfer Protocol[/B] (PIMA 15470)
    	...

Es werden immer alle Bilddaten auf der Speicherkarte übertragen bzw. für den Übertragungsvorgang verglichen, daher sollte man mit einer leeren Karte starten.

Das Szenario beschreibt den Einsatz eines W-LAN Sticks zur Übertragung der Kameradaten via AdHoc-Netzwerk zu einem Anzeigegerät (Notebook/Tablet-PC/Fileserver). Die LAN Schnittstelle soll hierbei nur zur Konfiguration bzw. Diagnose des Pi im Bedarfsfalle dienen.

Scriptablauf:
Phase 1 (Allg.):
Zunächst erfolgt eine kurze Prüfung des Environment (korrekte Konfig vorhanden, ...), falls nicht erfolgt ein Abbruch (Exit status 2, LED 100).
Phase 2 (Netzwerk):
Danach werden die Netzwerkeinstellungen geprüft (Interface vorhanden und UP, ...), falls nicht erfolgreich kommt es zum Abbruch (Exit status 1, LED 100).
Ist alles in Ordnung verbleibt das Script in einer Warteschleife bis das Zielsystem erreichbar ist (LED 001<->000).
Phase 3 (Kamera):
Die USB-Schnittstelle wird zurückgesetzt und das Script verbleibt in einer Warteschleife bis die Kamera angeschlossen und ansprechbar ist (LED 101<->000).
Der Mountpoint wird angelegt und es wird versucht den Kameraspeicher einzuhängen. Schlägt dies fehl, erfolgt ein Abbruch ( Exit status 1, LED 210).
Im anderen Falle wird die Kamera wieder ausgehängt und es erfolgt ein USB Reset.
Phase 4 (Transfer):
Es findet ein Schreibversuch auf dem Zielmedium statt, indem die Datei wft.pid (Inhalt aktuelle Prozess-ID) übertragen wird, im Fehlerfalle erfolgt ein Abbruch (exit status 1, LED 100).
Es kommt nun zur Hauptschleife in der folgende Aktionen ausgelöst werden:
- Kameraspeicher einhängen
- Vorhandene Dateien auslesen und via rsync mit Zielmedium abgleichen
- Warten bis rsync abgeschlossen (Poll alle 2sek)
- Kameraspeicher aushängen
- USB-Reset ausführen
- Datei wft.pid von Zielmedium holen und auswerten (Stop-kriterium)
- Falls kein Stop, 5 Sekunden warten bis Schleife erneut starten kann
- Falls Stop, Zielmedium aushängen und Script beenden ( Exit status 0, LED 000)

Installation:
Das Paket beinhaltet nun eine README mit der Installations- und Konfigurationsanleitung.

Download:
Das WFT-Paket: http://www.distorted-photography.com/projects/wft_pi/

Marcus. · 3 Januar 2013

DIY: Wireless-Funk-Transmitter mit dem Raspberri PI - HARDWARE

Aktuell ist der BG Umbau auf Eis, habe jedoch eine provisorische Halterung gebaut.
Die besteht aus einer Aluschiene (B=30mm/L=200mm) welche ich in der Mitte um 90° gebogen habe.
Daran befestigt ist der PI nebst Akkupack mittels Klettband. Die USB Leitungen sind selbst konfektioniert, da ich diese mit abgewinkelten Steckern nicht in der passenden Länge finden konnte.

facet · 4 Januar 2013

Hallo,

tolle Story! Bin mal auf das Endergebnis gespannt.
Kurze Frage:
Wie lange dauert es jetzt bis die ganze Geschichte Betriebsbereit ist?
Sprich das fertig und dauerhaft konfigurierte Gerät vom einschalten bis zur ersten Datenübertragung (Booten etc).

Edit: Da kam mir noch eine Frage

Wie sieht es aus andersrum Daten bzw Befehle an die Kamera zu schicken um diese so fernzusteuern? Gibts da schon Ansätze (Gibts da ne Liste oder Library für verschiedene Kameras)?

Grüße

Marcus. · 4 Januar 2013

Vom booten bis zum Zeitpunkt der Übertragungsbereitschaft vergeht etwas weniger als 1 Minute.
Bei mir läuft Raspbian ohne X.11 und das ist fix gestaret.

Die Übertragungsdauer eines 22MB RAW's per WIFI beträgt etwa 45 sek., JPEG's werden binnen weniger Sekunden übertragen.

Natürlich unter der Vorraussetzung dass keine Wände oder sonstiges dazwischen ist, aber damit lässt sichs im Studio sehr gut leben.

//EDIT:
Bezüglich Kamerasteuerung kann man gphoto2 nehmen, damit lässt sich alles notwendige wie Blende, Verschlusszeit, Auslöser usw. (zumindest bei Canon) steuern. Habe mich aber nur kurz damit auseinander gesetzt, da es mir primär erstmal um den direkten Zugriff auf die Speicherkarte ging.

Markus42 · 5 Januar 2013

Woran liegt das, dass es so langsam ist? 22MB in 45s sind gerade mal 0,5MB/s. Kann das noch optimiert werden?

Kann man RAW+JPeg aufnehmen und dann nur die jpegs übertragen?

Marcus. · 6 Januar 2013

Im Moment kopiert das Script noch alles von der Speicherkarte, eine Nur-JPEG Option werde ich aber als Option vorsehen, danke für den Einwand.

Ein Grund für die langsame Übertragung könnte sein, dass ich den rsync im Archiv-Modus mit der Option "compress" laufen lasse, d.h. er gleicht immer alle Dateien zwischen Quelle und Ziel ab und komprimiert dabei noch zu übertragende Daten.
Die von mir genannte Zeit bezog sich auf einen kompletten Abgleichvorgang, nicht auf den reinen Netto-Transfer (via ssh auf den Mac).

Sollte es am AdHoc-NW liegen findet sich da sicher auch noch Potential

Markus42 · 6 Januar 2013

Der Raspberry Pi hat nur einen USB-Port, d.h. mehr als ca. 15MB/s (30MB/s / 2) geht sowieso nicht. Was aber natürlich schnell genug wäre.

Marcus. · 6 Januar 2013

Das B-Modell hat zwei USB 2.0 Ports, hast Du noch den A?

Markus42 · 6 Januar 2013

Marcus. schrieb:
Das B-Modell hat zwei USB 2.0 Ports, hast Du noch den A?

Ich habe noch gar keines, ich hab nur kurz gegoogelt. Ich verfolg den Rpi schon länger so am Rande, aber bisher hat mir immer die konkrete Anwendung dafür gefehlt.

Ich bin aber prinzipiell von der Idee begeistert, denn mit einem RPi könnte man eben auch die Kamera zB mit einem Handy/Tablett fernsteuern, wie es bei der 6D möglich ist.

Marcus. · 6 Januar 2013

Ja, da geht so einiges. Man könnte einen kleinen webserver mit CGI oder PHP laufen lassen und dann über ein Webfrontend direkt Systemaufrufe via gphoto2 machen.

Aber ich denke solche Diskussionen um die Möglichkeiten wären besser in dem Thread Raspberry PI im BG aufgehoben.

Mapan · 8 Januar 2013

Mein Pi kam auch kurz vor XMAS und soll u.a. für diese Bastelei herhalten. Allerdings mit Nikon D90 und D700. Bisherige Vorabtests zeigten, dass ich vorläufig mit gphoto2 nur die D90 aktiviert bekomme.

Mein USB-Wlan Stick bringt den PI jedoch zum resetten. Den kann ich wohl nur über einen powered USB Hub verwenden. Funktioniert der Edimax so, dass man ihn einstecken kann, ohne dass der Pi resettet?

Marcus. · 8 Januar 2013

Eben mal ausprobiert, folgendes Verhalten habe ich:
- Booten bei eingestecktem Stick kein Problem

- Ziehen des Sticks im laufenden System auch kein Problem

- Stecken des Sticks ins laufende System --> Reset

Auch wenn ich ohne Stick boote und ihn dann einstecke gibts nen Reset.
Ich war der Meinung ihn bei der ersten Inbetriebnahme im laufenden Betrieb gesteckt zu haben, aber scheinbar wohl doch nicht.

Da ich aber keine Notwendigkeit habe den Wifi-Dongle abzuziehen, kann ich noch damit leben.

Hast Du mal probiert die D700 als anderes Modell anzusprechen?
Was zeigt denn

gphoto2 --auto-detect

an, wenn sie gesteckt ist?

BTW: Könntest Du mir mal die Ausgabe von lsusb -vv schicken (Siehe Post #1). Wäre cool.

Mapan · 8 Januar 2013

Also gphoto2 autodetect ergibt .. nix gefunden..

Die Ausgabe vom lsusb -vv paste ich hier mal ein, weil Dateianhang leider nicht funktioniert...

Code:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            3.02
  iManufacturer           3 Linux 3.2.27+ dwc_otg_hcd
  iProduct                2 DWC OTG Controller
  iSerial                 1 bcm2708_usb
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             1
  wHubCharacteristic 0x0008
    Ganged power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
Device Status:     0x0001
  Self Powered

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x9512 
  bcdDevice            2.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      1 Single TT
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      2 TT per port
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             3
  wHubCharacteristic 0x000d
    Per-port power switching
    Compound device
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent      1 milli Ampere
  DeviceRemovable    0x02
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
   Port 2: 0000.0100 power
   Port 3: 0000.0101 power connect
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0 
  bDeviceProtocol         1 
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0xec00 
  bcdDevice            2.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol    255 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               4
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0 
  bDeviceProtocol         1 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Marcus. · 9 Januar 2013

Danke für die Ausgabe, aber selbst auf Kernel-Ebene scheint er die Nikon nicht zu sehen.
War die an einem USB Hub angeschlossen (und eingeschalten) oder direkt?

Mapan · 9 Januar 2013

Direkt angeschlossen und selbstverständlich "ON".

Marcus. · 9 Januar 2013

Das ist seltsam, die D700 ist ja nicht gerade erst auf den Markt gekommen.

Laut gphoto2 wird diese auch unterstützt (Liste) .

Bleibt die Frage ob es untersch. USB-Modi an der Kamera einzustellen gibt oder ggfs. die Firmware vielleicht nicht aktuell ist.

bws4711 · 9 Januar 2013

Hallo,

Die Idee finde ich super aber das ganze mobil tauglich zu machen wird sicher noch mal einiges an Aufwand und Geld kosten. (Gehäuse, Akku usw.)
Aus diesem Grund habe ich mir mal existierende Lösung angeschaut und durch Zufall festgestellt, das der cam ranger als Hardwarebasis auf einen mobilen wlanrouter aufsetzt. Dieser router hat in einem kleinen Gehäuse alles was man braucht:

Gehäuse
Usb-Port
Open WRT verfügbar
Akku
Sogar noch 3g

Wenn ich das soweit richtig verstehe müßte man auf das openwrt eigenlich "nur" noch die entsprechene software bauen. Da openwrt auf linux basiert sollte das zumindest mal grundsätzlich gehen.Die ganze Hardware gibt es für unter 50,- Euro bei Amazon. Der Router heißt MR3040 von TP-Link.

http://www.tp-link.com/us/products/details/?categoryid=&model=TL-MR3040

Marcus. · 9 Januar 2013

Guter Einwand, aaaaaber ....

Das Teil sieht zwar schick aus, ich habe da jedoch recht große Bedenken ob man sich wirklich einen Gefallen damit macht.

Open-WRT:
Ich selbst Open-WRT Systeme hier laufen und es gibt schlussendlich nur fertige Kompilate die irgendwas mit Netzwerk zu tun haben (mal etwas übertrieben pauschalisiert).
Es wird jedoch sicher notwendig sein, die ein oder andere Bibliothek oder Programm dafür selbst zu kompilieren.
Auf so einem System direkt was kompilieren kann man gleich mal vergessen, also geht es schon damit los dass man sich einen schönen Cross-Compiler auf dem Rechner aufsetzen darf. Viel Spaß dabei

Elektr. Leistung/Nutzungsdauer:
Der PI hat eine Leistung von 3,5W (5V/700mA), das von TP Link hat 5W (5V/1A). Das Teil hat zwar einen Akku, aber mit seinen 2000mAh würde das gerade mal zwei Stunden reichen.
Der von mir in Post #1 genannte Akku hat dafür aber mehr als doppelt so viel Leistung parat. Wären dann knapp 6h max.
Und das sind jeweils Leistungsangaben der Geräte ohne das sie unter Last stehen!
Praktisch gesehen dauert bei mir eine Studio-Session etwa 4-5h, solange muss das Teil heben.

Flexibilität:
Auf dem PI ist ein vollwertiges Debian, der verfügbare Softwareumfang für ARM-Platformen ist groß. Aber selbst kompilieren geht auf der kleinen Kiste recht gut.
Der größte Vorteil hierbei ist jedoch, dass es schon diverse Programme zur Kamerasteuerung hierfür gibt, d.h. ich kann das Teil direkt auch für HDR-Aufnahmen, Time-Laps, Remote-Cam usw. verwenden.

Preis:
Im Vergleich zur restlichen Kameraausrüstung wohl eher sekundär

Aber der TP Link hat da die Nase vorn, da stimme ich Dir zu.

Wenn ich mal kurz überfliege:
- Raspberry ca. 45€
- Akku ca. 32 € (obwohl der tatsächlich für was anderes beschafft wurde)
- Defekter BG-E7 als Gehäuse 15€
- LED-Modul 8€

Bin ich also doppelt so teuer mit meiner Variante. Dennoch würde es mich freuen wenn sich jemand an die von Dir genannte Variante rantraut.

paynemaster · 21 Januar 2013

Hallo,

vor einigen Tagen habe ich mich auch in das Thema wft mit dem RaspberryPi und Nikon D90 eingearbeitet.
Ich habe dies über den Capture-tethered befehl von gphoto realisiert und die aufgenommenen Fotos per hook skript über ftp ans ipad (shuttersnitch) gesendet. Nachteil dieser lösung, der Capture Tethered befehl spuckt andauernd in der Konsole aus, welche kameraparameter geändert wurden (also unwichtig) und das ganze funktioniert auch nur solange die Kamera eingeschaltet ist. wird sie ausgeschaltet bricht das hook skript mit dem transfer ab. Also im prinzip funktioniert auch diese lösung nur leider nicht besonders hübsch.

Durch Zufall habe ich gestern diesen Thread gefunden und mich ein bisschen durch das script gelesen.
Sehr gute Arbeit und tolle Umsetzung

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. Vielleicht liegt es daran, das die Fotos nicht im root verzeichnis der kamera gespeichert werden (gphotofs mountet ja erstmal nur das stammverzeichnis) sondern in diversen Unterordnern. wäre ja nicht so schlimm, leider kommt jedoch shuttersnitch mit Unterordnern nicht klar.
Ich werde es die Tage nochmal versuchen zwar die ganze kameraverzeichnisstruktur zu mounten, aber dann nur auf das Verzeichnis mit den Fotos zu verlinken. Vielleicht klappt es ja.

Weiterhin ist mir eingefallen, ist es vielleicht sinvoll das skript durch Ausschalten der Kamera zurückzusetzen, anstatt durch löschen/bearbeiten der wft.pid.

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, via rapid prototyping "drucken" lassen und dann über den Blitzschuh universell an Kameras montierbar machen. Die Kosten für ein solches Gehäuse errechnen sich nach Volumen, hab da gerade leider den Preis nichtmehr im Kopf.

Werde auf jedenfall zu dem Fortschritt berichten

Viele Grüße

Julian

DIY: Wireless-Funk-Transmitter mit dem Raspberry PI

Anhänge