Show HN: Bau einer ultrakompakten Kamera mit extrem langer Akkulaufzeit

 (toaster.llc)
1 Punkte von GN⁺ 2024-06-04 | 1 Kommentare | Auf WhatsApp teilen
  • Photon ist eine ultrakompakte Kamera für langfristige Installationen und wirbt vor allem mit einer Akkulaufzeit, die mit einer einzigen Ladung mindestens 50.000 Aufnahmen ermöglicht
  • Sie unterstützt zeitbasiertes und bewegungsbasiertes Fotografieren und kann für Aufnahmen zu bestimmten Uhrzeiten oder Daten, Zeitraffer und bewegungserkannte Aufnahmen genutzt werden
  • Da weder Bluetooth, Wi‑Fi noch Mobilfunk integriert sind, ist für den Zugriff auf Fotos physischer Zugang erforderlich, was das Risiko von Remote-Hacks und heimlichen Cloud-Uploads verringert
  • Hardware und Software sind als Open Source veröffentlicht, und Fotos werden im RAW-Format gespeichert, das die Pixeldaten des Bildsensors unverändert enthält
  • Low-Light-Performance und PIR-basierte Bewegungserkennung erfordern noch Vorsicht; es gibt Grenzen bei Bewegungen hinter Glas oder in Umgebungen mit sich im Wind bewegendem Gras und Laub

Ultrakompakte Kamera für langfristige Installationen

  • Photon ist eine ultrakompakte Kamera mit dem Slogan „tiny camera, out-of-this-world battery life“
    • Preis: 200 $
    • Es gibt die Mac-exklusive App Photon Transfer
    • Verwendet USB‑C
    • Keine Abos, keine Cloud-Dienste, keine wiederkehrenden Zahlungen
  • Sie unterstützt sowohl zeitbasiertes als auch bewegungsbasiertes Fotografieren
    • Fotos können zu bestimmten Uhrzeiten oder an bestimmten Tagen aufgenommen werden und eignen sich damit gut für Zeitraffer
    • Aufnahmen können durch Bewegungserkennung ausgelöst werden
  • Durch den Verzicht auf Netzwerkfunktionen wird der Zugriff auf Fotos eingeschränkt
    • Bluetooth, Wi‑Fi und Mobilfunk werden nicht unterstützt
    • Damit Fotos das Gerät verlassen, ist physischer Zugang erforderlich
    • Das Design verhindert Remote-Hacks oder Uploads zu Cloud-Diensten ohne Wissen der Nutzer
  • Hardware und Software sind vollständig Open Source
    • Fotos werden im RAW-Format gespeichert, das die vom Bildsensor ausgegebenen Pixeldaten unverändert enthält
    • Wenn der Speicher voll ist, überschreiben neue Fotos die ältesten

Technische Daten und Einschränkungen vor dem Kauf

  • Wichtige technische Daten
    • Akkulaufzeit: mindestens 50.000 Aufnahmen
    • Fotoauflösung: 2304 x 1296 Pixel
    • Speicherkapazität: 20.197 Fotos
    • Blickwinkel der Kamera: horizontal 130°, vertikal 75°
    • Blickwinkel der Bewegungserkennung: horizontal 90°, vertikal 90°
    • Reichweite der Bewegungserkennung: bis zu 5 m
    • Betriebstemperatur: 0–50°C
    • Wasserbeständigkeit: hält Regen stand, aber kein Untertauchen
    • Größe: 47 x 36 x 31 mm
    • Aus 6061-Aluminium gefertigt und eloxiert
    • Kleiner als ein AirPods-Case
  • Es gibt Einschränkungen, die vor dem Kauf beachtet werden sollten
    • Die Low-Light-Performance wird noch verbessert; wenn Aufnahmen bei wenig Licht der Hauptzweck sind, kann es sinnvoll sein, auf ein künftiges Software-Update zu warten
    • Der Bewegungssensor kann aufgrund der Grenzen der PIR-Technologie keine Bewegung hinter Glas erkennen
    • In natürlicher Umgebung kann der Bewegungssensor durch im Wind schwankendes Gras oder Laub häufig ausgelöst werden
      • Wenn die Kamera so eingestellt ist, dass sie bei erkannter Bewegung ein Foto macht, kann der Akku schnell entladen werden
      • In einem künftigen Software-Update könnte eine Einstellung für die Bewegungsempfindlichkeit hinzugefügt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-04
Meinungen auf Hacker News

  • Ich verstehe nicht ganz, warum dieses Produkt so stark als Mac-only vermarktet werden sollte.
    Es ist schade, bei einem Open-Source-Produkt die App an das restriktivste der Verbraucher-Betriebssysteme zu binden. Linux oder Windows lassen sich auf normaler Hardware nativ oder in einer VM ausführen, macOS läuft dagegen nur auf Macs wirklich unkompliziert. Erst nach dem Lesen der Kommentare wurde mir klar, dass man es theoretisch auch ohne Mac kaufen und nutzen kann, dann aber wohl auf Teile der Nutzererfahrung verzichten muss.
    Zumindest die Möglichkeit von Community-Support in Form eines Kommandozeilen-Tools für Linux ausdrücklich zu erwähnen, erscheint einfach. Selbst wenn es nicht so ausgefeilt wäre wie die Mac-App, würde das zur ehrlichen Offenlegung der Produktgrenzen passen und vermutlich auch die Kundschaft vergrößern.

    • Ich bin mir nicht sicher, ob sich die Kritik darauf richtet, dass ein kostenpflichtiges Produkt nur den Mac unterstützt, oder darauf, dass ein Open-Source-Projekt nicht mehrere Betriebssysteme unterstützt.
      Falls Ersteres: Mac-only-Software habe ich schon oft gesehen, und ich nehme an, das liegt an der Wahrnehmung, dass es eine Plattform ist, auf der Nutzer eher für gute Produkte bezahlen.
      Falls Letzteres: Es ist Open Source, also kann man die benötigten Teile selbst bauen. Ich weiß nicht, ob diese Sichtweise zur DIY-Kultur gehört, mit der ich aufgewachsen bin, oder ob ich einfach alt geworden bin; ich frage mich aber, ob das heute noch eine verbreitete Überzeugung ist.
    • Ich frage mich, ob man daraus wirklich so ein Problem machen muss. Man hätte auch fragen können: „Gibt es Pläne zur Unterstützung anderer Plattformen?“ Stattdessen wirkt es fast so, als würde man es böswillig auslegen.
      Das passt gut zu der Begründung, warum Leute kommerzielle Linux-Software aufgeben: „95 % des Supports, 2 % des Umsatzes“. Wenn es offen ist und man Linux-/Windows-Support will, sollte man ihn selbst bauen, statt sich darüber zu beschweren, dass die Person, die ein kleines 200-Dollar-Gerät gebaut hat, es nicht getan hat.
    • Als ich diesen Satz auf der Homepage sah, bin ich sofort zurückgegangen und habe meine Empfehlung zurückgezogen. Es fühlte sich wie eine seltsame Angeberei des Machers an; ironischerweise wird die Open-Source-Community die schöpferische Absicht wohl ignorieren und es nach Bedarf nutzen, solange das Wertversprechen stimmt.
      Ich räume ein, dass Dave ein hervorragender Entwickler/Designer ist und das Produkt auf seine Weise beeindruckend ist. Ich würde gern Daten dazu sehen, wie gut sich Mac-only-Produkte im echten Markt schlagen.
    • Stimme stark zu. Beim Durchsehen der Website wurde ich neugierig und hätte es vielleicht in Betracht gezogen, aber sobald ich „Mac-only“ sah, habe ich den Tab geschlossen.

  • Beeindruckend, dass er auch eine Drag-and-drop-Terminal-App für Rebase gebaut hat. Insgesamt coole Produkte und wirklich sehr Hacker-News-mäßig.
    https://toaster.llc/debase/index.html

    • Es ist erstaunlich, wie breit das Spektrum dieser Person ist. Von Embedded über native Apps bis zur Fertigung deckt sie alles ab; da fühle ich mich richtig faul.
    • Drag and Drop im Terminal ist schon cool, aber in letzter Zeit nutze ich lazygit, einen Git-Client fürs Terminal. Der Workflow ist komplett tastaturbasiert und bietet ein viel leichter handhabbares Mental Model als die Standard-Git-Kommandozeile.
      https://github.com/jesseduffield/lazygit
    • Wow, so etwas wollte ich schon seit Langem, und ich hatte sogar einmal angefangen, es selbst zu bauen.

  • Gibt es auf der Produktwebsite Beispielbilder der Kamera? Die Idee ist cool, aber um einschätzen zu können, wie gut sie für den Zweck geeignet ist, wären mehrere Beispielbilder hilfreich.

  • Sieht wirklich großartig aus. Ich verdiene seit über 30 Jahren meinen Lebensunterhalt mit Fotografie und habe durchaus Kaufinteresse.
    Für mein aktuelles Projekt zur Dokumentation der Aufzucht von Kalifornienkondoren wäre dieser kleine Formfaktor genau richtig. Schade ist nur, dass ich für meine Zwecke auch Videoaufnahmen brauche, und dann dürfte die Akkulaufzeit deutlich schrumpfen.
    Wenn wir das Kamerasystem im November installieren, können wir es nicht mehr anfassen, bis das Jungtier im Herbst das Nest verlässt. Deshalb war es schwierig, eine Lösung zu finden, die sowohl gute Bildqualität als auch die speziellen Anforderungen des Projekts erfüllt.
    Es gibt auch mehrere Gründe, warum wir keine GoPro verwenden können. Sie verbraucht viel Strom, und weil es sich um eine Zuchtanlage handelt: Selbst wenn man den Signalton im Menü deaktiviert, hat er sich nach einem Stromausfall schon einmal von selbst wieder eingeschaltet. Stromausfälle kommen außerdem häufig vor. Zudem schaltet sich eine GoPro nach einer Unterbrechung der Stromversorgung nicht automatisch wieder ein; man muss sie manuell einschalten, was nicht möglich ist, solange Jungtier und Elternvögel dort sind.

    • Warum nicht eine Wildkamera verwenden? Die kann das, was dieses Gerät macht, besser, hat außerdem Video und Nachtsicht und kostet nicht 200, sondern 50 Dollar.
    • Unabhängig von der Kamera: Könnte man nicht ein langes Kabel bis zu einer Stelle verlegen, an der man den Akku gelegentlich wechseln kann? Oder alternativ einen externen solar geladenen Akkupack verwenden?
    • Wenn du über Monate hinweg kontinuierliches Video willst, brauchst du wahrscheinlich eine maßgeschneiderte Lösung mit Akku. Der Akku muss eine gewisse Größe haben, und Solar kann helfen, sollte aber nicht die einzige Grundlage sein. LFP-Akkus von Anbietern wie Eco-Worthy sind leicht und haben eine hohe Ausgangsleistung, daher könnten sie eine gute Wahl sein. Eine 30-Dollar-Batteriebox, wie sie für Blei-Säure-Autobatterien verkauft wird, kann man ebenfalls als Wetterschutz verwenden.
      Monatelanges kontinuierliches Video ist mit Niedrigenergie-Technik derzeit praktisch noch schwierig. Kamerasensoren sind nicht für diesen Zweck ausgelegt, und aktuelle CMOS-Sensoren müssten dafür komplett neu entworfen werden. Es gibt zwar Forschung daran, deutlich stromsparendere, maßgeschneiderte Sensoren von Grund auf zu bauen, aber das ist High-End-Forschung, und ich habe noch nichts Kommerzielles gesehen. Das Verteidigungsministerium dürfte ein Interesse an langlebigem kontinuierlichem Video auf dem Schlachtfeld haben, also könnte es Priorität haben. Vor etwa fünf Jahren begannen Arbeiten mit neuen Mikrofertigungstechniken, und Chip Elliot war ebenfalls beteiligt, aber es war nicht völlig sicher, ob es machbar ist.
      Für Timelapse könntest du dir Brinno-Kameras ansehen. Sie sind für Timelapse gemacht, haben ein wasserdichtes Gehäuse und können auch per USB mit Strom versorgt werden.
      https://brinno.com/
      Wenn man die automatische Belichtung einstellt, kann sie nachts genug Licht sammeln, sofern das Timelapse-Intervall lang genug ist, und sie kommt auch mit Tageslicht zurecht. Es gibt einen Objektivanschluss, sodass man Weitwinkel oder ein leichtes Tele wählen kann; möglicherweise gibt es auch Objektive von Drittanbietern. Wenn man eine Brinno für Timelapse und ein maßgeschneidertes Stromversorgungssystem für kontinuierliches Video kombiniert, hat man zumindest zwei unabhängige Systeme, die etwas liefern können. Bei unbeaufsichtigten Systemen ist Redundanz gut.
    • Nebenfrage: Wo kann man in Kalifornien gut Kondore sehen? Ich habe sie im Pinnacles National Park gesehen, das war wirklich großartig.
    • Man kann die GoPro öffnen, den Beeper entfernen und sie an einen großen externen Akku anschließen.

  • Ich frage mich, warum man sie nicht einfach als universelles Massenspeichergerät anschließbar gemacht hat.

    • Berechtigte Frage. Es gab ein paar Gründe.
      Um die Akkulaufzeit von Photon zu maximieren, habe ich die Hardware so ausgelegt, dass sie nur das absolute Minimum tut, das zum Aufzeichnen von Bildern nötig ist. Deshalb speichert Photon die Bilder auf einer unformatierten SD-Karte, also in einem riesigen linearen Byte-Array, was einfach und schnell zu indizieren ist.
      Ein 16-Bit-MSP430 schreibt die Bilddaten, und der Codespeicher des MSP430 ist schon zu 99 % voll, ohne dass er die Komplexität eines Dateisystems wie FAT32 handhaben muss. Es bleibt also kein Platz, um Dateisystemunterstützung hinzuzufügen. Diese MSP430FR2433-Familie hat maximal 16 KB FRAM; man könnte zwar auch eine andere Familie verwenden.
      Photon speichert die Bilder als RAW-Bilddaten, die eine Nachbearbeitung benötigen, um sie ansehen zu können. Da ich ohnehin eine ausgefeilte App zum Betrachten der Bilder anbieten wollte, dachte ich, man könne diese App dann auch zur Voraussetzung machen.
      Ich will nicht behaupten, dass all diese Gründe hervorragend sind, aber so war damals die Abwägung.
    • Ich bin kein Mac-Nutzer, aber als jemand, der seltsame Kameraausrüstung impulsiv kauft, bin ich für das Label nur für Mac direkt unter dem eingeklappten Bereich dankbar. Normalerweise liest man auf HN erst ein paar Minuten lang eine Softwareseite und merkt dann erst im Footer oder über einen „get it here“-Link, dass es nur für Mac ist. Hier weiß ich sofort, dass es nichts für mich ist, und kann in mein langweiliges Leben zurückkehren.
    • Die Begleit-App scheint im App Store zu sein. Trotzdem verstehe ich es nicht ganz, wenn es als Open Source veröffentlicht werden soll.
    • Statt als universelles Massenspeichergerät wäre es in der Praxis vielleicht besser gewesen, es als MTP-kompatibles Gerät erscheinen zu lassen. Dafür bräuchte man allerdings ein zugrunde liegendes Dateisystem, und wie der Autor erklärt hat, ist kein Platz für weitere Funktionen vorhanden.
      Das Produkt ist interessant, und der Code ist offen, daher denke ich, dass Linux-Unterstützung dankenswerterweise wahrscheinlich irgendwann entstehen wird.
      0: https://en.wikipedia.org/wiki/Media_Transfer_Protocol
    • In diesem Fall wirkt es wie ein Feature, dass die Software nur für Mac ist.

  • Cooles Projekt. Beim schnellen Durchsehen sind mir ein paar Dinge eingefallen.
    Im GitHub-Repository haben Code und Designdateien keine Lizenz, daher ist es derzeit eher Source Available als Open Source. Wenn geplant ist, dass andere den Code ändern und eigene Kameras bauen können, sollte eine passende Lizenz hinzugefügt werden.
    Dass es nur mit einer speziellen App funktioniert und nur Mac unterstützt, noch dazu nur macOS ohne iPad/iPhone, scheint den Markt stark einzuschränken. Wenn die App nur zum Anzeigen/Übertragen von Fotos und zum Konfigurieren des Geräts dient, könnte der Zugriff auf die Fotodateien über eine einfache MTP-Schnittstelle laufen und es zusätzlich eine zweite Schnittstelle für die Einstellungen geben. Und wenn das Gerät mit Open-Source-Lizenz veröffentlicht und als hackbar sowie privacy-freundlich vermarktet werden soll, ist Linux-Unterstützung im Grunde notwendig.
    Damit es auch bei Minusgraden funktioniert, wäre es überlegenswert, Automotive-Grade-ICs zu verwenden. Die aktuellen Bauteile mögen in Kalifornien in Ordnung sein, könnten aber in nördlichen Bundesstaaten im Winter draußen problematisch sein.

    • Linux-Unterstützung muss nicht unbedingt direkt angeboten werden. Auf Basis des veröffentlichten Open-Source-Codes wird es wahrscheinlich jemanden geben, der Linux-Unterstützung hackt, und bei Windows dürfte es ähnlich sein.
      Wenn Dave allerdings einen größeren Markt erreichen will, wäre Windows- oder Android-Unterstützung sinnvoll.

  • Sieht wirklich großartig aus. Danke, dass du eine gute Mac-App gebaut hast; den Rest der Kritik hier musst du meiner Meinung nach nicht beachten.
    Wäre das geeignet, um daraus lange Videos zu machen? Ich stelle mir vor, regelmäßig von der Kamera Aufnahmen zu dumpen, während die Kinder aufwachsen und spielen, und sie später Frame für Frame zu einem filmartigen Video zusammenzusetzen.
    Gibt es auch eine Möglichkeit zu erkennen, ob der Speicher bald überschrieben wird?

    • Zeitraffer ist einer der vorgesehenen Anwendungsfälle. Allerdings muss die Begleit-App noch um Videoexport erweitert werden. Derzeit unterstützt sie nur den Export von Bildern.
      Momentan werden, wenn der Speicher voll ist, stillschweigend die ältesten Fotos überschrieben; ich dachte aber schon länger, dass es eine Einstellung geben sollte, die das verhindert.
      Wenn der Akku unter 2 % fällt, geht das Gerät in die „battery trap“, stoppt die Aufnahme und lässt nur noch alle 5 Sekunden eine rote LED blinken. Wäre es sinnvoll, eine Einstellung zu haben, die bei vollem Speicher optional ebenfalls in diesen Modus wechselt?

  • Da es viele Bedenken wegen „nur Mac“ gibt: Könntest du nicht eine kleine Python-Datei bereitstellen, mit der man auf jeder Plattform die RAW-Fotos auslesen kann?
    Es sieht so aus, als könnte man mit dd if=/dev/disk123 of=/tmp/bigrawfiles dumpen und anschließend mit diesem Python-Skript nachbearbeiten.
    Das wäre nicht so gut wie eine polierte Apple-App, aber für Leute, denen die Hardware gefällt und die ein wenig DIY in Kauf nehmen, könnte es reichen.

    • Aktuell gibt es mit MDCUtil schon etwas Ähnliches, und es dürfte sowohl unter macOS als auch unter Linux funktionieren.
      https://github.com/toasterllc/MDCCode/blob/rev10/Tools/MDCUt...
      Man kann es zum Beispiel so verwenden:
      $ MDCUtil ImgReadFull output.cfa
      Allerdings gibt es die auf der SD-Karte gespeicherten Rohdaten aus; eine Funktion zur Umwandlung in ein Standardformat wie DNG müsste noch implementiert werden.

  • Mir kommen ein paar Fragen in den Sinn:
    Welche Auflösung haben die Bilder? Ist sie fest, oder lässt sie sich in den Einstellungen ändern?
    Kannst du echte Bilddateien anhängen? Anhand der Vorschau ist kaum etwas zu erkennen.
    Gibt es Angaben zur Betriebstemperatur? Selbst wenn der Akku nicht schlappmacht, kann sich die Kamera wegen Hitze abschalten; das kenne ich häufig von GoPro-ähnlichen Geräten.
    Wie groß ist die Speicherkapazität? Ich sehe nirgends eine Erwähnung.
    Edit: Der Footer der Website ist jetzt sichtbar; vorhin wurde er nicht geladen.

  • Dave, tolles Projekt.
    Ich würde gern mehr über das Low-Power-Design hören. Du hast erwähnt, dass du hier den MSP430 gewählt hast, und im Blogbeitrag zur High-Level-Architektur gab es auch ein paar Informationen zu Power Domains; ein Blogbeitrag mit detaillierteren Stromspartechniken wäre aber schön.
    Ich frage mich, ob du auch darüber nachgedacht hast, einen einfachen Streaming-Kompressionsalgorithmus hinzuzufügen, um die Akkulaufzeit zu verlängern. Wenn weniger Daten geschrieben werden müssen, ist VDD_B kürzer eingeschaltet, und es ließe sich vielleicht auch im FPGA umsetzen. Ich dachte an etwas wie Delta-Encoding, bei dem kleine und große Helligkeitsänderungen je Farbkanal unterschiedliche Codelängen verwenden.
    Zum Beispiel: Wenn das erste Bit 0 ist, folgen 5 Bit für ein Helligkeitsdelta von +/-32; wenn das erste Bit 1 ist, folgen 11 Bit für das Helligkeitsdelta.
    Wenn die Helligkeitsänderung zwischen zwei Pixeln größer als 2048 ist, ginge ein winziger Teil der Information verloren, aber man könnte diese Änderung auf zwei aufeinanderfolgende Werte aufteilen und sie so „verschmieren“. Zum Beispiel würde aus [0, 0, 4096, 4096, 4096] dann [0, 0, 2048, 4096, 4096].

    • Danke für den Vorschlag. Die Kompressionsidee ist interessant. Es ist eine Weile her, dass ich FPGA-RTL angefasst habe, aber vielleicht gibt es dafür sogar Platz.
      Im Zusammenhang mit Kompression hat Photon ein kleines Geheimnis: Aktuell werden 12-Bit-RAW-Pixel als 16-Bit-Wörter geschrieben. Daher sind 25 % der SD-Karte, also die oberen 4 Bit jedes Pixels, tatsächlich 0.
      Der naheliegende Kompressionsgewinn wäre also, diese Pixel dichter zu packen. Dadurch würde die Zahl der speicherbaren Fotos von 20.000 auf 27.000 steigen, und wie du sagst, würde sich auch die Schreibzeit pro Foto verkürzen, was die Akkulaufzeit erhöhen würde.
      Es wäre interessant zu quantifizieren, welche Komponenten beim Aufnehmen eines Fotos am meisten Strom verbrauchen. Ehrlich gesagt weiß ich nicht genau, wie sich die Leistungsaufnahme zwischen Bildsensor, SDRAM, SD-Karte und ICE40 verteilt.