Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: I made a tiny camera with super long battery life (toaster.llc)
843 points by davekeck 6 months ago | hide | past | favorite | 299 comments
Hey HN!

A few years ago someone kept trying to steal my motorcycle, so I decided to make a small camera with really long battery life to catch them.

The hardware/software is totally open source, but the companion app only supports macOS currently. (I'm a big fan of native apps, and didn't want to block releasing on Linux/Windows support.)

I wrote some blog posts about the process:

PCB design: https://toaster.llc/blog/pcb

Enclosure design: https://toaster.llc/blog/enclosure

Image pipeline: https://toaster.llc/blog/image-pipeline

Rainproofing: https://toaster.llc/blog/rainproofing

Source: https://github.com/toasterllc/Photon




I don't really understand why this has to be heavily marketed as Mac-only. As an open-source product, restricting the application to the most restricted of consumer operating systems (namely that any consumer hardware can run Linux or Windows, either bare metal or through a VM, whereas only Macs can easily run macOS) seems a bit sad. I had to read through the comments here to realize that as someone who doesn't own a Mac, I _could_ theoretically purchase this and use it, even if it meant sacrificing some UX.

Reading the comments, it would be trivial to even at minimum state that there could exist community support for Linux, in the form of a command-line tool, even if it's not as polished as a Mac app, considering how open this product is about its limitations, and would likely bring in more customers.


I'm not sure I follow the criticism here. Is the issue that a paid product only supports Mac, or an open source project didn't build for multiple OSs?

If it's the first; I've seen tons of Mac only software due to the perception that it's a more lucrative platform. (Users are price tolerant for good products).

If it's the last; scratch your own itch. Since it's open source you can write the softer yourself. I'm not sure if this outlook is the diy zeitgeist I grew up in, or just being old. I'm curious if this is still a common belief.


Looking back, I could have phrased my original comment better, but my criticism is neither of those things. I'm just saying that as an open-source project that has an open-source specification, the author could make it clearer that an interested customer could buy one of these and write their own open-source Linux/Windows implementations as opposed to making it sound like "if you don't own a Mac, this product isn't for you."

Reading the comments, it looks like the author already made a command-line tool that might let the camera work on Linux; why not say that it's Mac-only but community support for other platforms based on the open nature of this camera is appreciated (and provide whatever links [eg. that command-line tool] that were mentioned in this forum)?


Appreciate your thoughts.

In case it helps explain the wording: I went with "exclusively for Mac" because I intended it to be an in-group signal to Mac folks that the product is high quality and conforms to the norms of the Mac platform. In my experience, cross-platform GUI software usually doesn't conform to Mac software conventions (and IMO just kinda sucks by Mac software standards). So my wording is trying to convey that the software isn't your typical cross-platform Electron/QT/GTK app.

Anyway, would love to add Linux support, just trying to figure out if that's what I want to do with my life right now.


This is top comment for a reason.


What a weird bone to pick. You could say “would support for other platforms be on the horizon?” but instead you take it almost maliciously. This take is very compatible with what I’ve read about why people stop writing Linux commercial software: 95% of the support, 2% of the sales.

If it’s open and you want to create Linux / windows support, just do that versus complain that the creator of a $200 small scale device hasn’t.


There is a pretty big gap between the narrative in the post here: "only supports macOS currently", and what the website says: "Exclusively for Mac" in a Just Girly Things cursive font. The latter makes it sound like they'd reject support if someone handed to them on a silver MR shaped platter.


It just sounds like they’re turning the single plat aspect into the selling point that it was built for the audience’s platform as opposed to some crappy multi-plat app.

I’d say that’s a good call for a $200 app. The HNers showing up here to announce that they closed the browser tab couldn’t run the app anyways lol.


Support is not a one time thing. It's perpetual. Bugs will happen, feature requests will come, especially with Linux, cause there is no such thing as standard Linux. Nobody has to support your things for free. Support it yourself. Wait, that is hard work? Well...

This entittled atittude is how open source maintainers get burned out. If you care about OSS, stop it. Get your hands dirty.


> in a Just Girly Things cursive font.

The font isn’t cursive. It’s exactly the same as every other section.


ctrl+f "Exclusively for Mac". There is one hit (though there is another similar message that is not cursive).


Thank you for the correction, I missed that one. At first I thought maybe the one I saw might’ve changed, but a quick trip to the Internet Archive showed it looked like that in April.


I would guess you saw the other message:

> Photon Transfer is designed with love exclusively for your Mac

Which isn't cursive


When I read the page, it was implied that it's not possible to support other platforms or wouldn't be appreciated by the heavy Mac marketing. Now that I know more of the technical details of the product and seeing that it would definitely be possible to add Windows/Linux support, I am more inclined to buy it and write software for it myself, and I think it would be good to include that on the page more.

Something like "Open hardware/software means that the community could write Linux/Windows support" and a link to the tool that the author said could be used to transfer files on Linux: https://github.com/toasterllc/MDCCode/blob/rev10/Tools/MDCUt... somewhere more prominent on the page would be helpful, as this was not clear to me until I read the comments here.


I did not interpret their post in as rude a manner as you portray it (their feedback is on point, so thanks kaladin-jasnah), but your characterization of their post as "weird" and 'a bone to pick' and 'almost malicious' and 'complaining' is itself multiple-times rude.

Is there a connection between you and the subject matter that might have caused you to interpret the post in a less charitable way than others?


I never said rude, and maybe I was less charitable than I should have been with malicious. But reading that comment and all of the others here that mirror it there is a kind of almost malicious assumption, or at least a very non understanding dismissal of the choice.


This is just a toxic attitude from Linux people you see on everything. They're always finding a way to be slighted by software not being made for their niche platform, as though it's trivial to support multiple platforms properly.


> toxic attitude

If everything you see is toxic maybe the problem is you.

> as though it's trivial to support multiple platforms properly

It is trivial compared to creating something useful in the first place.


If it's so trivial then why hasn't the author done it? Do you really think there is some kind of malicious motivation here?


I, without looking at the comments here, immediately returned to homepage to unvote after seeing this on the homepage. Weird flex by creator; ironic that the OS community will happily ignore his creative intentions to use as needed if the value prop fits. I get that Dave is a boss of a dev/designer, and the product isn't unimpressive in its own ways. I'd like to see data on how 'mac only' products do out there in the wild.


Strongly agreed. I started scrolling through the website, was somewhat interested, and might have considered it, but just closed the tab when I saw mac only.


Sounds like this guy is a Mac programmer, and couldn’t afford to hire folks to write for other platforms.

I feel that pain. I write native Apple software, and the torrents of hate that I get, for not spending tens of thousands of my own dollars on multi-platform development (for a free app), is ridiculous.

It sucks to be hated for something I love to do.

It appears as if he’s opened the communication architecture, so it’s probably possible for someone to throw up their own drivers.


Yea I get that it's no BT/Wifi so probably USB. But I don't get why USB would require a mac. I personally like the hardware but don't care about the rebase or whatever software addons he strapped to it. If I just plugged in a USB cord and used any OS to copy off the photos, it would make sense. This is basically the same usage as a thumbdrive or point-and-click camera from early 2000s and shouldn't be limited to a particular OS.... if I'm understanding it correctly


Okay, you also made a drag and drop terminal app for rebasing?? Super cool products all round. True hacker news.

https://toaster.llc/debase/index.html


Blows my mind how much this guy knows. From embedded to native apps to fabrication. I feel lazy as fuck.


drag and drop in the terminal is certainly cool but I've been recently getting into lazy git, also a terminal git client and it's workflows are all keyboard driven. It presents a mental model that is much easier to deal with than standard git terminal command line.

https://github.com/jesseduffield/lazygit


I’ll always endorse the heck out of lazygit when I see it mentioned, it’s one of the best pieces of software I have used. Sure it can’t do everything git cli can, obviously, but it makes 95% of what you do 100% better.


Oh wow! I’ve wanted this for ages, even started making it myself at some point!


This is awesome!


Are there sample images from the camera on the product website? This is a neat idea but it would be nice to gauge to what extent it is fit for purpose, and a helpful way to do this is with a bunch of sample images.


I should definitely add some sample images...

For now, the Mac app has real imagery in the demo mode:

https://apps.apple.com/us/app/photon-transfer/id6476578040

(The demo photos are from the Lick Observatory on Mount Hamilton.)


This is an amazing project, but you are pitching it as an engineer. As an amateur photographer, the first thing I want to see are sample photos. Super cool little device!


You should really put up some sample images.


This looks really cool. I've made my living a photographer for over 30 years and I'm very tempted to purchase. This small form factor would be perfect for a project I'm doing documenting California condors rearing their young. Sadly, I would also need it to shoot video to be effective for my needs (and I'm sure this would kill the battery). Its one of these situations where I setup the camera system in November, and then can't touch it again till after the young have left the nesting site in Fall. Its been tough to come up with a solution that provides good image quality along with the unique demands of the project.

I wish you great success.

For those wondering why I can't use a GoPro for this project - I have several reasons. Power consumption is one. This is in a breeding facility, and although I can turn off the beep in GoPro menu settings, I've had the beep spontaneously reset after a power outage (which are frequent). Also - Gopros don't turn back on after losing power and must be manually powered back on - something I can't do when chicks and parents are present.


Why not use a trail camera? They do everything this device does but better, plus they have video and night vision. And you can buy one for $50 instead of $200.


Look for one designed to use external power. Lots of people have connected them to car batteries (there are projects on the web). The consumer ones tend to use PIR sensors to trigger short video recordings, which might be a problem if the camera is too far away. Birds tend to be well insulated and may not emit much IR. Maybe pro ones use doppler radar to trigger recordings? You might want to choose one based on how long it can be configured to record video after being triggered, 30 seconds for example may not be long enough for what you want to capture. This is not a normal use of a trail camera so figure out what your needs are and see if there is one that meets them.


Do you have any suggestions for a good one?


Unrelated to the camera. But couldn't you add a long cable to a place where you can change a battery occasionally? Or use an external solar rechargeable battery pack?


If you want continuous video for months then you probably need a custom solution using a battery. The battery will have to be somewhat large (solar can help, but don't rely totally on it). LFP batteries like those made by Eco-Worthy might be a good choice, light weight, high power. A $30 battery box (sold for use with lead-acid car batteries) can protect it from weather.

Continuous video for months isn't really possible yet on low power because the camera sensors are not designed for it, current CMOS sensors would have to be totally redesigned. There are people working on custom sensors that are much lower power, rebuilding a camera sensor from the ground up, but it's high level research and I haven't seen that they are commercially available yet (the DOD may have priority, they would love to have long lifetime continuous video on the battlefield). They started working on them about 5 years ago and it involves new micro-fabrication techniques (Chip Elliot was involved), but they weren't entirely sure it was possible.

For time lapse check out the Brinno camera, it's made for time lapse, it has a waterproof shell, it can be powered from USB:

https://brinno.com/

It can be set for automatic exposure so it gathers enough light to record at night (many seconds of exposure if your time lapse interval is long enough) while still handling daylight. It has a lens mount so you can choose wide angle or mild telephoto (maybe others are also available from 3rd parties). A time lapse Brinno plus a custom power system for a continuous video camera would probably at least make sure you get something with two independent systems. Redundency is good in unattended systems.


If you don't mind a tangential question, what are some good places to watch condors in CA? We watched them at the Pinnacles National Park and loved the experience.


I don't have an answer, but at least for Europe you can use www.birdingplaces.eu. The website has some entries for California, but couldn't find condors. Good luck!


Just open the gopro and remove the beeper. Then connect it to a big external battery.


There are lots of tiny low-powered video cameras made for use on mini drones.


Check out CHDK for Canon PowerShot cameras.


> exclusively for Mac

Why not just have it connect as a generic mass-storage device?


Totally fair question! My reasons were:

1. To maximize Photon's battery life I tried to make the hardware do the absolute minimum to record imagery. To that end, Photon stores images on an unformatted SD card (ie one huge linear array of bytes) which is easy and fast to index into.

2. A 16-bit MSP430 handles writing the image data, and the MSP430's codespace is 99% exhausted without dealing with the complexities of a filesystem like FAT32, so adding support for a filesystem wouldn't currently fit. (This line of MSP430, MSP430FR2433, has a maximum of 16 KB of FRAM, but perhaps I could use a different line.)

3. Photon stores images as RAW image data that require post-processing to view the images. Since I wanted to provide a polished app to view the imagery anyway, I figured I'd just make it a requirement.

I'm not saying those are all particularly good reasons, but that was my reasoning anyhow.


It's pretty cool that your MSP handles the SD Card directly!

Personally I think you should keep the focus on a polished mac app. For other platforms you can do just the bare minimum with a web app that uses WebUSB. People will bitch that it's Chromium only but, I mean, chromium has 95% market share outside Apple world (and I say this as a FF user).

A hardware solution could be to add a cheap microcontroller that would handle the usb port. It wouldn't be powered by the battery, only USB and it would act as a proxy between the raw sd card and the computer. Presenting a mass storage to the computer with folders, converting images to PNGs. Such capable MCUs are very cheap (rp2040, esp32-s3) but it certainly adds complexity to your project...


> It's pretty cool that your MSP handles the SD Card directly!

The MSP430 is actually the puppet master for an ICE40 FPGA that does the high-speed transfers (102 MHz) between image sensor -> SDRAM -> SD card.

Here's a post about the architecture if you're curious:

https://toaster.llc/blog/architecture

Thanks for the feedback!


>It's pretty cool that your MSP handles the SD Card directly!

SD cards aren't really black magic since they "speak" SPI, meaning people have been interfacing basic microcontrollers to them since forever.


They speak SPI, but it's a lot slower than SDIO. And there's a lot of work that goes into making an MMC or SD card (or SDHC or SDXC card) into a FAT16 or FAT32 or exFAT filesystem!

If I were doing this project, I'd use an STM32 with its built-in SDIO driver to implement most of the SD card stuff. ST's CubeIDE has easy-to-use filesystem driver that makes this transparent. Use the STM32 to read the card and manage a file for the FPGA to write the bitstream to, then when you plug into USB power, have the STM32 empty this linear file and copy the photos over to BMP images on the SD card. It would be slower, sure, but if you're only using it once a month or once a year, does that really matter? Plug it into USB, go to lunch, and come back to a properly-formatted SDXC card with an exFAT filesystem ready to have the images copied to whatever OS you want to use.


TIL!


I think open source web app with WebUSB is basically the perfect solution as others can then come in and hack a better UI onto it.


I would suggest the same hardware solution, where the USB powers a device-side presentation of the raw data into a more universal mass storage device. This also allows file transfer to any device without requiring special software. I did something like this in 2008 or so (using a FTDI chip and PIC mcu, and boy was it ever slow).


> It's pretty cool that your MSP handles the SD Card directly!

No it isn't. Accessing an SD card from a microcontroller requires you to do that. To use FAT involves more effort, though lightweight libraries are available.


Maybe an electron app? I mean, we all love electron, right?


Can I ask why you went with a MSP430?

I'm not judging, they were all the rage in low-power embedded applications 10-15 years ago, just feels weird to see it in a modern design today, when the market now is flooded with low-power ARM chips that are way more capable than that, and probably easier to program.


Not the OP, but my understanding (admittedly a few years outdated) is that an MSP430 will, in idle, with sleep states properly set up and low power modes in use, drain a coin cell battery (e.g. CR2032) over a period of years - with the current drawn around 1.5 uA in standby and 0.1uA in RAM retention idle.

That is likely even lower than the effective self discharge rate of a lithium coin cell battery. I don't believe the Arm equivalents like the Cortex M0 can deliver such low absolute current - maybe microamps, but more than an MSP430 from what I can see.

Ref - https://metebalci.com/blog/measuring-the-power-consumption-o...


> That is likely even lower than the effective self discharge rate of a lithium coin cell battery.

That's what I've found too. Based on my measurements and calculations, Photon uses 5µA (MSP430 + motion sensor) while sleeping, while the battery's self-discharge is more like 80µA.

That's probably a good argument for using a more powerful chip though, if the battery self-discharge is that high, hah.


Maybe tiny solar panel + capacitor, like 1980/90s calculators had, then it could run "forever" - digital Millennium Camera.


This is a cool idea!


Or a different battery chemistry with a lower self discharge rate. No need to be rechargable in most of the use cases, I'd imagine.


Panasonic BR2032 has 30µA discharge rate https://www.digikey.com/en/products/detail/panasonic-bsg/BR-...


If that's the self discharge rate then the battery would be fully discharged after less than a year on the shelf (given its 190mAh capacity). Coin cells typically have a much longer shelf life than that. I wonder what that figure is, exactly.


This sounds like a job for a lithium thionyl chloride battery.

The guys with the purple LiSoCl2 batteries make ones with up to 40 years of usable life


Some of the SiLabs EFM32 parts have comparable sleep currents.


One main reason I chose the MSP430 was for the FRAM. Photon stores all its state (ie the photo ring buffer indices, and user settings) in one big FRAM struct, which can be read/written just like RAM, but persists across power cycles and crashes.

Another reason was MSP430's low power consumption, but like you said it sounds like ARM has caught up.

Would love to hear about alternative designs -- are there low-power ARM chips that have something like FRAM and don't require erase/programming dances to write data?


If external F-RAM is an option, one can use F-RAM from, say Cypress (now Infineon, [1]) together with ARM chips from Ambiq, e.g. Apollo 3 Blue Thin [2], which likely have even better power consumption than an MSP430.

[1] https://www.infineon.com/cms/en/product/memories/f-ram-ferro...

[2] https://ambiq.com/apollo3-blue-thin/


Dang very cool. If there's ever a Photon 2 I'll definitely look at the low-power ARM world.

(FWIW Photon's USB stack is handled by a STM32F730 and I've been perfectly happy with it. Expensive though.)


IMO that's an odd choice for a micro. It initially looked like it could translate the custom SD card writing to FAT in SW, but with only 64K of flash that's not great. Some STM HAL irqs are almost that size. My recommendation is to find 1 micro that can do low power and USB, and maybe put external FRAM/QSPI for more code storage is needed.


Are there any RISC-V chips that do the same?


ESP32 has a variety of sleep modes down to around 12-20uA and up, depending what you want to leave awake.

With the 3rd CPU, the ULP, running continuously it is around 150uA and then you can be reading from i2c devices, or more. You can get that down to under 50uA with a periodic timed wake up, if you are keen.

Also it will appear as a USB device if needed when fully powered.


Love these answers. I declare you officially to be a badass.


Indeed, kudos for that. Nice to see the out of the box thinking.


Since the read part is handled by another chip (feeding off of USB power, therefore not terribly power constrained), you could present as a MTP device, or even mass storage, while generating the file structure on the fly. Maybe TIFFs are simple enough so you don't have to mess with the actual image bytes.


Thanks for sharing the explanations, and hey it's open source so someone can make a linux version if they want!


> To maximize Photon's battery life I tried to make the hardware do the absolute minimum to record imagery. To that end, Photon stores images on an unformatted SD card (ie one huge linear array of bytes) which is easy and fast to index into.

Hmm, what about a dongle that connects between the camera and computer? The dongle wouldn't have to worry about battery life because it'd have USB power. It could do the translation to mass-storage in hardware so the computer wouldn't have to be running macOS.


Make it a tar archive with some common RAW photo format?

    cat /dev/sda > raws.tar


Ok, so an app is needed to get the data from the device to a computer, and you wanted to focus your efforts on a "polished" Mac app. But why not make a non-polished Windows app as well? Or have someone make it?

Also, is the RAW data specific to the device and if so, why? If the device simply used, say, DNG or TIFF, then decoding could be done by external software, and all your own software would have to do would be to read the SD card and produce RAW files...?


> But why not make a non-polished Windows app as well? Or have someone make it?

If I had more time and money I certainly would!

> Also, is the RAW data specific to the device and if so, why?

To maximize battery life, the hardware does zero processing on the image data; it simply copies the raw pixels output by the image sensor to the unformatted SD card.

> If the device simply used, say, DNG or TIFF, then decoding could be done by external software, and all your own software would have to do would be to read the SD card and produce RAW files...?

True, perhaps I should've used an existing RAW format like DNG and exposed the images as a filesystem. That would require using a different architecture (ie not using an MSP430, like Rinzler89 suggested), and would likely reduce the battery life due to having to maintain a filesystem on the SD card.


It seems it's the filesystem that's most costly? Would it be possible, maybe, to store DNG file data, one after the other, on the card, without a filesystem?


I'm not too familiar with the DNG format, but if a DNG file could be as simple as [header][2304x1296x2 bytes][footer] then it might be possible with the current hardware.

But without a filesystem, would it be useful to have DNG files stored on the SD card? Wouldn't you need special software to read off the "packed" DNG data anyway? And if you need special software anyway, couldn't the special software convert the existing raw image data to the DNG format, instead of requiring the hardware to do it?


Well, yes.

It's unclear from the website what Photon Transfer does exactly, but from the screenshots it seems it's almost a Lightroom-lite?

A super basic utility that would simply extract the data from the device and spit out DNG files, with zero further processin, would not need to have a nice GUI, or even a GUI at all, and may be enough to lure in Windows users?


The DNG/TIFF spec is unreasonably flexible. It would be possible to add just a fixed precalculated header on the image data to make it valid DNG. The lack of filesystem is still a bigger issue.


Your header for your DNGs, I think, is going to be the same for every single file you write. DNG is just a kinda superset of TIFF, IIRC.


how do you manage the balancing of card use, or is there still a card firmware layer in the loop that does that?

eg lower memory being used far more often over the life so wearing out well before upper memory?

how do you handle memory dropouts for a given address/cell/whatever you call a memory location, or as above?


> how do you manage the balancing of card use, or is there still a card firmware layer in the loop that does that?

The SD card is accessed as a ring buffer, so all addresses are written evenly. (It was my understanding that SD cards implement wear leveling themselves though, so the wear leveling should be free even if the SD card was written to randomly -- if my understanding is correct.)

> how do you handle memory dropouts for a given address/cell/whatever you call a memory location, or as above?

SD card write failures cause the firmware to crash and reset itself, so it'll try again when another photo is triggered. (It also logs the reset so it can be debugged.)

FWIW I'm using Samsung 128 GB "PRO Endurance" SD cards, with endurance == 820 TBW, which works out to 820e12 / 5.97e6 (size of one photo) == 137e6. So you can capture 137 million photos before the SD card is expected to fail.


Perhaps your perspective would be better reflected on the site if instead of just saying "exclusively for mac" it said open source right there with it-- I closed the page as "not for me" before getting down to the open source part.


I (as a non-mac user, but impulse buyer of odd camera gear) appreciate the "exclusively for Mac" label put just after the fold. I usually have to read pages (about software) on HN for minutes before finding out (in a footer or "get it here" link) that it's Mac-only. This way I just know it's not for me and I can continue with my boring life.


It looks like the companion app is in the App Store, but yeah if it's going to be open source then I don't understand either.


> Why not just have it connect as a generic mass-storage device?

Actually have it present itself as a MTP (0) compatible device would have been better, but that would require an underlying filesystem, and as the author explained there's no space to add more features. The product is interesting though, and the code is free (thanks!) so I'm positive that Linux support will eventually happen.

0: https://en.wikipedia.org/wiki/Media_Transfer_Protocol


Why MTP? It's strictly less functional and more annoying to user than presenting as mass-storage device, and since you need a filesystem either way, might as well go with a protocol that gives you access to files, instead of a slow, half-working abstraction over them.


The software being exclusive to Mac is apparently a feature in this case.


I'm admittedly trying to "celebrate my constraints" of finite time and money haha. I would love to support more systems if there's enough interest.


Nothing wrong with prioritizing one platform. It's just presented in a strange way on the website which suggests to me that it will only ever work on Mac.


Amazing project. Would consider buying one, if you sent to Germany. Did you consider writing your app using the Web Serial API? If you did, why did you decide to go the native route?


> Did you consider writing your app using the Web Serial API? If you did, why did you decide to go the native route?

I went the native route mainly because I love native software, particularly native Mac software. I never quite enjoy using web apps, but I certainly understand the appeal.

Until I get the ordering system taking international addresses, send me an email (support@toaster.llc) with your address and I can send a Stripe invoice.


Saw it on EEVBlog, even owning a Mac is not sufficient if its not the latest OS version. SD Card doesnt store pictures in windows readable format either.


Most recent mailbag, EEVblog1619: https://youtu.be/ABqDGjcwMsg?t=1118


Dang I haven't mustered the courage to watch Dave's critique yet!

I wrote/tested Photon Transfer (the companion app) on macOS 10.15 (Intel), so it should work on that and above. If not it's a bug that I need to fix!


Your handling of folks' feedback in this thread is impressively graceful, fwiw.


He gave you a pretty good review, I thought. I'd have been interested in the camera myself if it supported Windows.

Given the rate at which the data flows -- nothing at all for a long time, then a burst that isn't particularly time-sensitive, then nothing at all again for a while -- I wonder if the right way to do something like this is with LoRA. That way the camera could be mounted someplace hard to access, with no need for a file system at all. There would then be a separate receiver module that could listen for traffic from multiple cameras and store it for later access by a PC/Mac/whatever.


I cant find the video now somehow (otherwise would link it). TLDR: he loved it, both idea and design, but could test due to Mac store requirements.


Yeah, even if you're a mac guy, it doesn't make sense to make hardware that is mac only.


The website states he's a "big fan of native apps."

You shouldn't build software based on what you're a fan of. You should built it based on its usefulness to users. Very silly to limit the customer base so much to perfect something very tangential to the experience.


> You shouldn't build software based on what you're a fan of.

Why not? For a solo/passion/hobby product like this, I'd argue you 100% absolutely should build it based on what you're a fan of. My experience is people like Dave who approach things with opinionated laser focus and solve a personal/niche need tend to build things with much higher quality and better experience because they essentially build it for themselves. They are the customer.

> Very silly to limit the customer base so much to perfect something very tangential to the experience.

This presupposes the goal here is to reach the broadest customer base possible, like this camera+software is supposed to be a rocket ship. What if it's not? What if the goal is to build a high quality, highly-polished product? Focusing on a single OS (one that the maker is obviously a fan of) makes a ton of sense.

The style of the website and the focus of the product remind me a lot of the software company Panic (https://panic.com). They make extremely high quality software, with excellent design & experience, and a very narrow focus (unapologetically Apple-only). They don't make any concessions or sacrifice user experience to appease users of other operating systems. I respect them a whole lot more for that.


It's being sold, presumably for a profit, on a platform with a ~14% market share. Less if we count compatible devices based on OS version.

That is entirely the author's choice, but it isn't without consequence. For example, I have never heard of Panic despite owning a Mac myself.


> You shouldn't build software based on what you're a fan of.

If you’re doing something as a passion project you should absolutely do things based on what you’re a fan of.


Cool project, here's a few comments after a quick glance over:

- There's no license on the code and design files in the Github repo, thus this currently isn't open source but rather "source-available". If you plan to allow others to modify the code and build their own cameras you should add an appropriate license.

- The Mac only support (and it's MacOS only, with no iPad/iPhone support) with a dedicated app to operate it seems to really limit the market for this device. Since all the app does is allow you to view/transfer photos and configure the device you probably could make do with a simple MTP interface for access to the photo files and have a second interface for configuration. Also if you do plan to release this under an OSS license and market it as a hackable + privacy friendly device Linux support is pretty much a requirement.

- Consider using automotive grade ICs to allow the device to function below freezing. The current stuff may be fine for Cali but people in northern states won't be able to use it outdoors in the winter.


> Linux support is pretty much a requirement

Support isn't required for linux: I think there will be people who will be keen to hack up Linux support based on the open source code available, and the same with Windows. However if "Dave" wants access a larger market, Windows or even Android support would make sense.


>Windows or even Android support would make sense.

How about an SD card slot with a configuration in a plaintext file, so that one isn't tied to the software which may or may not be available in the future.

I just got myself a Sony Mavica which shoots photos on a floppy disk, and I can still use it without thinking about which OS my computer runs.

For a camera that boasts battery life in years, needing "exclusive" software (that may or may not be available years down the line) defies the point.


> Support isn't required for linux: I think there will be people who will be keen to hack up Linux support based on the open source code available, and the same with Windows.

I guess this is more of a marketing thing but I wouldn't be interested in buying this as a Linux user even with the other benefits if it came with unknown DIY support. If you're advertising it as an open source device and such then the people willing to play with it and pay a premium are typically Linux makers/hackers. If it's being sold as a Mac only device with a slick interface and app-only control that appeals to a different market entirely.


This looks exceptionally cool. Thank you for writing an excellent Mac app - forget the rest of the hate here.

Do you think this would be appropriate for turning into a long form video? I’m imagining seeing videos of my boys growing and playing where I just periodically dump the camera and eventually sitch it as frames into a movie.

Anyway to know when it’s about to write over itself in storage?


> Do you think this would be appropriate for turning into a long form video?

Time-lapses are certainly one of the intended use-cases. I still need to add video-export features to the companion app though. Right now it only supports exporting images.

> Anyway to know when it’s about to write over itself in storage?

Currently it silently overwrites the oldest photos once the storage is filled, but I've been thinking it should have a setting to prevent that.

When the battery gets below 2%, the device enters "battery trap", where it stops capturing images and simply blinks the red LED every 5 seconds. Maybe there should be an optional setting to enter that mode when the storage is filled. Would that work for you?


I could always just use ffmpeg to turn into a video.

Blinking when full would work. I think it’d also be helpful to know when that might be- like could I see the expected date somehow based on the rate of capture? Maybe that’s too niche of a feature.


Since there is so much anxiety about mac-only -- could you provide a small python file to read out the raw photos on any platform ?

It looks like you could just 'dd if=/dev/disk123 of=/tmp/bigrawfiles' and then postprocess with said python script.

Yes, not as good as a polished apple app, but for many people that really like the hardware and don't mind a bit of DIY, it's maybe enough...


That actually kind of exists currently via "MDCUtil", which should work on both macOS and Linux:

https://github.com/toasterllc/MDCCode/blob/rev10/Tools/MDCUt...

For example:

    $ MDCUtil ImgReadFull <image number> output.cfa
That outputs the raw data stored on the SD card though, so I need to implement converting that to a standard format like DNG.


Few questions come to mind:

- what’s the image resolution? Is it fixed or can it be changed in the settings?

- can you attach an actual image file? The previews are barely clear to show anything.

- any info about operating temperature? The battery might not die but the camera shuts off due to high temperatures, happens to me all the time with gopro and the likes.

- what’s the storage capacity? Not mentioned anywhere.

Edit: ok I see now the footer of the site, it didn’t load before


Until I add some good imagery to the site, you can see real imagery in the demo mode of Photon Transfer:

https://apps.apple.com/us/app/photon-transfer/id6476578040


Hi Dave, nice project!

I'd love to hear more about the low power design. You mentioned going for a MSP430 on here, and the high level architecture blogpost has some infos about the power domains too. But I'd love to see another blog post with some more nitty-gritty powersaving stuff.

I was also wondering... have you thought about adding a simple streaming compression algorithm to increase battery life? Less data to write would mean less time of VDD_B being active. Could maybe even be implemented on the FPGA. I was thinking of something like delta encoding, with two different code lengths for small and big brightness changes (per color channel.

E.g. first bit 0 -> 5 bits of +/-32 brightness delta following. First bit 1, 11 bits of brightness delta.

You'd loose some minimal information if brightness changes by more than 2048 between two pixels, but you could just "smear" that change over two consecutive values (e.g. [0, 0, 4096, 4096, 4096] would end up as [0, 0, 2048, 4096, 4096])


Thanks for the suggestions! The compression is an interesting idea. It's been a while since I touched the FPGA RTL but I think there might be space to fit something like that.

Related to compression -- a dirty little Photon secret is that currently, the 12-bit RAW pixels are written as 16-bit words, so 25% of the SD card (the high 4 bits of every pixel) is actually zeroes. So an easy compression win is to compact those pixels, and we'll go from being able to store 20k photos to 27k photos, and spend less time writing the photos (like you said) which should translate to longer battery life.

It would be interesting to quantify what the biggest consumer of power is while capturing a photo. I'm honestly not sure what the power breakdown would look like (image sensor vs SDRAM vs SD card vs ICE40).


Your "fine print" is an honest breath of fresh air.

Excellent communication throughout the page!


> A few years ago someone kept trying to steal my motorcycle, so I decided to make a small camera with really long battery life to catch them.

The camera seems really cool. But given that the device has no way to get photos off it without physical access, it seems like this wouldn't be super useful for your original purpose. If someone just takes the camera (or manages to successfully steal your motorcycle), then then camera doesn't provide any value.


I don't think the camera goes on the motorcycle.


Yeah my plan was to hide it in the garage's rafters. (I ended up moving out of my apartment complex anyway though, so I ended up not needing it for that anyway.)


That makes a lot more sense :) Although you still have the problem of someone potentially finding it.


The one use case he mentions could also be satisfied by a $50 trail camera with video capability, better photo quality, better low light performance and better motion sensing.

I'm really struggling to figure out why people are excited about this. Do they not know trail cameras exist?


If you don't mind me asking, what is Mac-specific about it? Is it the GUI toolkit? The PC-program toolkits I've used to transfer data to and from embedded devices using USB-C: (Qt, EGUI) don't care what OS you use. The web-based ones like Electron don't either. So, there would be nothing blocking the release; they just work on any OS you compile on or cross-compile for.


The Mac-specific parts of Photon Transfer (the companion app) are really just the GUI stuff (AppKit) and the GPU shaders (Metal) for the image pipeline. In fact the "MDCUtil" tool should still work on Linux (I haven't tested it in a bit though), and that allows reading imagery from the camera along with lots of other fun debug stuff.

A big part of porting Photon Transfer to Linux would be converting the image pipeline from Metal to... Vulcan (?). The main chunks of that are FFCC illuminant estimation (for white balancing) and LMMSE debayering:

https://github.com/toasterllc/FFCC-Metal https://github.com/toasterllc/LMMSE-Metal

The GUI stuff (list views, image grids, image zooming, oh my) would be a good chunk of work too.


To be frank the "mac exclusive" marketing is a huge turn off for something that should obviously be nearly completely agnostic regarding PC operating systems. Makes me wonder what other poor decisions went into the design of this thing.


It's not marketing. They're just upfront about limitations (software is single-platform) while trying to present it positively (it will feel native on that platform). The entire page seems to make a point of being upfront about limitations, which is kind of a rare thing. That said I agree that making it cross-platform would have been wise, since the software is entirely secondary to the physical product.


> Makes me wonder what other poor decisions went into the design of this thing.

Haha me too man, me too.

(Edit: I don't mean that sarcastically, I'm genuinely interested how others would make this thing.)


Yeah, I actually physically rolled my eyes when I read the "exclusively for Mac" copy on the website. I get it if you want to build a cool photo transfer/view app as an add on to the experience, and want to do it native, and only have time to build for one platform. But calling that out in that way makes it sound like some sort of "feature", which is a huge turn-off, regardless of whether or not they're building exclusively for my platform of choice.

But the camera itself should support MTP, USB mass storage, or something of that nature, and should just work on any platform. If it doesn't, that's a pretty silly oversight.


It's not an oversight. There are very good reasons for it, which are detailed elsewhere in the comments thread.


> should obviously be nearly completely agnostic

Is it obvious? Is it free (as in resources) to support agnostic platforms and systems? Is the threshold for making anything that it needs to be compatible with everything?


In general, no.

However a security camera that works with all operating systems just needs to expose a drive via USB… as has been done for decades now.


Apparently, to take the processing off of the camera chip, the decision was to:

1. Not use a filesystem on the SD card;

2. Write RAW files only

This means software is needed to both transfer files, and to convert them into an image format.

Personally, I'd put that software on board, with extra dedicated hardware if necessary (it can be powered off of USB), and make the device appear as a massage storage device to a USB host.


Why not just use something like Qt to build a native cross platform app? As others have mentioned, advertising a device as open source and yet Mac only is going to turn away a lot of people.


Really appreciate the feedback.

The honest answer is I'm a Mac guy, and a terrible businessman.

FWIW I love Linux and used it extensively to develop Photon. (In fact the "MDCUtil" tool for debugging Photon already supports Linux.) I'd love to add Linux support for the app if there's enough interest in this thing.


Qt apps, even in 2024, still don't feel native when used on Mac.

Personally I'd much rather just drop the custom Mac app and replace it with:

  - firmware that can read/write a proper filesystem
  - firmware that can create e.g. DNG files that can be handled by regular photo editors like Lightroom, RawTherapee, Darktable, etc.
  - A webapp that lets you generate a configuration file and does the battery life estimation.


Can he afford Qt? He'd need a lawyer on retainer.


If the app is opensource, Qt is 100% free under GPLv3.


Most of it is LGPL, so the app doesn't even need to be open-source and on desktop compliance is quite easy.


Technically, you're correct.

I just don't like being threatened on their download page.


Neat, if there was something like this that was more like a car dashcam, I'd really like something for my bicycle helmet, I want a dashcam like experience incase someone hits me, but the battery life and charging ergonomics combined with having to empty the flash card on a gopro makes it not work well for the usecase.


For this I use a Virb Elite mounted on the bike itself. Garmin stopped making them in 2013 I think, and they can be found in mint condition for $40-50. They're very sturdy, waterproof, and have GPS. The battery life is reasonnable (with new batteries).

The mounting system is very practical, they can be taken off or put back on with one hand, something I was never able to do with a GoPro.

And they just... look weird, so they don't get stolen.


Congratulations on the launch! Not sure if anyone mentioned it already - huge kudos for publishing insights of your journey in the detailed posts on your blog. I learned so much! Loved the details, photos, clips demonstrating problems you encountered. Thanks and good luck!


I try to avoid devices with built in batteries. Could a version be created that uses a replaceable 18350, 18650 or even AA? I'm OK swapping every few months etc, but when its time to dispose of it, I don't want to fret about how to remove the battery for recycling.


Totally fair, I feel the same way. Originally Photon was going to use AAs but I changed course when I decided I wanted to make it water resistant.

(FWIW Photon uses a 103040 which is pretty commonly available, the only caveat is it needs a Molex Pico-EZmate connector, which is a super-low-profile connector since interior space is scarce.)

I'd love to revisit the battery story some day...


Also when the battery dies and it renders the product garbage that only someone with fairly advanced skills can fix.


I 1000% agree with the sentiment, I hate that we throw so many electronics away.

I need to make a blog post showing how to replace the battery.


Is the battery soldered? Is it a fairly standard kind of thing like an 18650 (obviously not the same size, but I'm not familiar with what "standard" pouch style batteries exist)?


It’s not soldered, but it does have a Molex Pico-EZmate connector (chosen for its low profile), and I’m not sure you can find batteries premade with that kind of connector. You could reuse the existing connector with a new battery, but that would ideally involve soldering.


I really like the focused idea. This is likely the best product in its niche. It's an oddly large niche--this is a tool that can solve a lot of problems.

Is the battery replaceable if it fails?


> Is the battery replaceable if it fails?

It's replaceable but I hadn't thought that far ahead regarding end-users doing it. The caveats are:

1. I made a special tool to avoid scuffing the aluminum when removing the backplate:

https://toaster.llc/blog/rainproofing

Search for "Backplate Removal"

2. The backplate needs to be re-sealed (with standard RTV sealant).

3. The PCB uses a Molex Pico-EZmate connector. (It could be transferred from the old battery to the new battery, or I could sell pre-made batteries if there was interest.)


What an excellent post. I love it and learned so much.

Would you be willing to share a ballpark price for what you pay for the enclosure? And maybe ballpark how many you ordered at once? I have found getting enclosures made to be incredibly expensive -- but I have only ever done VERY low volumes (5-10).


Sure! Checking the invoice, I paid $2205 (including anodizing and shipping) to make 125 enclosures (which includes 125x enclosures, backplates, and buttons).

So that works out to $18 per unit. This is my first time doing something like this so I have no idea if that's a good deal or not.


Reasonable. I find anodizers are easy to find, good ones hard, and great ones almost impossible. I found a great one in Auburn and I feel lucky I did.

Iirc you’re paying for the batch. If you pick a color they don’t do a lot, you’re paying the same for 1pc or 2000. The dye and handling is pretty much the same.


Interesting! I had the same experience with anodization, the quality between manufacturers varied a lot.

So it sounds like you use different companies for machining and anodizing? It certainly seems like you'd get better results from someone that specializes in each...


https://www.kickstarter.com/projects/cwandt/55-66-88-by-cwan... My buddies have some good horror stories trying to get metal parts tumbled and anodized. You do have to nail down quality standards beforehand, and even then they may just give up and ship back to you, or disappear.


absolutely. I don't know if your camera body would allow it, but if you can get a die and extrusion, buying two or three tons of near net shape extrusion that you do a machine pass on, pass to anodizing, and assemble might reduce your cogs. Friend's COGS was cut by 2/3 switching from raw stock to custom extrusion.


$200 is a very fair price given the capabilities and novelty – since you're at it, would love to hear your BOM cost too!


IIRC all the chips were about $100 per unit, but of course that depended on the quantity that I was building (~120). When I looked at it briefly, it looked like I might be able to get the BOM price down to $50-70/unit if I made 1k-10k units.

There was a ton of manual assembly for each unit (some due to my errors, some due to the PCBA's errors, some simply due to the design of the device). All in all, it's not get-rich-quick/ever scheme haha.


I would market it as a security camera.

Just “camera” implies I might take this to the colosseum or to take family photos.

But without a view finder and with deleting old photos I don’t think that is the use case.

It is super niche though. Most security cam buyers would at least want cellular or wifi to capture the images “so far” before the thief steals the cam itself.

So this is for situations where small is the main thing, I suppose almost for spying.


Brilliant suggestion

I have been in the market for something like this forever for security cameras near sheds I have on properties I check on once every couple of months

First time that I’ll be buying something of hacker news this quickly


I want to know who designed your site and who implemented it :-) One of the best sites I have ever seen.


so cool!

For your next trick, how about a super long battery life MP3 player? A friend asked if I knew of an MP3 player that would be good for a two-week hike with no access to electricity, and it really seems like there's nothing out there beyond carrying around a bunch of batteries.


>A friend asked if I knew of an MP3 player that would be good for a two-week hike with no access to electricity, and it really seems like there's nothing out there beyond carrying around a bunch of batteries.

Go on the used market and look for old iRiver players if you can, preferably the T10. They take AA batteries and last forever (45+ hours), have a rugged sporty design and had the best non-Apple quality and UX.

The only downside is the small flash storage on them for today's standards but only the old players were feature AA batteries, before they all switched to sealed internal lithium meaning they are now dead.

But on the upside the name brand players from 20 years ago had higher quality MP3 decoding SoCs and audio DACs, while the new MP3 players with AA batteries you can buy today are all bottom of the barrel chinesium e-waste.


FiiO M3 Pro? https://www.amazon.com/FiiO-M3-Pro-Resolution-Touchscreen/dp...

> 15 hours battery life and 35 days standby time: Adopt 1000 mAh high-capacity lithium-ion battery and USB-C charging technology. The M3 Pro has a battery life up to 15 hours and standby time up to 35 days. That means if you listen 3.5 hours every day, the M3 Pro can go for a whopping 1 week before needing to be charged again!


15 hours seems not that much considering an iPod nano can do 30 hours (according to Apple)


My Cowon D2 might be old but it still goes on for days and days and ... you get it, it's awesome!


Fifteen hours is not enough for a two-week hike. That gives you one hour of listening per day, maximum.


A modded iPod classic is hard to beat. Replace the HDD with a CF card (many of the SD and SATA adapter boards don't have support the drive's power saving features) and stick the biggest battery you can get in there. I've seen people get 100+ hours of playback from a modded iPod.


https://www.amazon.com/dp/B01NAJ3KQB

...probably at least 10-25 hours playback on a single battery, which means 8 batteries gives you 80 hours of listening (2 weeks).

For that space though, you could scavenge a solar garden light charger and get indefinite listening with ~4 batteries. 1 loaded, 3 charging, with a nominal "fully charge 3 batteries with 16 hours of daylight", which means a ~33% duty cycle.

One sunny day charges 3 batteries, which means you have 45 hours of charge before needing to obtain another 16 hours of sunlight.


I was surprised to see that company is still around. I used to love their cameras because of their limitations. Unless I’m mixing them up with a similarly named company.


There are other options such as chargers powered by solar power, hand crank, fire, etc.


Just bring a power bank.


Really well done! I also love the design of your website, is it a boilerplate/template or did you design it yourself?

Is this the same sensor as the rpi hq cam? Would be cool to have interchangeable lenses on this, but that might make weatherproofing it difficult.


It says here [1] that the image sensor is AR0330.

[1] https://toaster.llc/blog/architecture/index.html


> I also love the design of your website, is it a boilerplate/template or did you design it yourself?

Website is painfully custom haha. Credit to the wonderful Iconfactory for the Photon art!


This is super cool. Custom FPGA based camera with this magnificent machined case is something I can only wish I could build.

I kind of wonder, is it going to hurt aesthetics too much to replace the lens mount with a transparent window, with the lens mounted to the board and PIR sensor off a short cable, so the front face would require less machining and that the board can be secured to the bottom plate? That would save machining time and also might allow use of customizing options on existing enclosures, if it would make sense to do so.


Off topic, but all the camera nerds are here, so I'm gonna ask:

I want to attach a cheap camera to an arrow, which may be single use depending on the target. Ideally it would attach with 1/8" thread (presently unknown pitch) or smooth (glueable) 6.2mm shaft. The total weight must be no more than 200 grains.

Any suggestions? I'm pretty ignorant with cameras.

Regarding the Photon, seems really appealing, but I'm an old Linux curmudgeon. The only Mac I ever had ran debian.


Wonder if this could be co-opted to function like a Narrative Clip. Take a photo every 30 seconds (or something like that). I had mine for 3 years before it died


50,000 pic battery life * 1 pic every 30 seconds = ~17 day battery life. Not bad


Small note: though the battery will last for 50k pictures, the storage will begin overwriting old photos after ~20k.


It does feel a little weird that the battery outlasts the storage. Maybe I should've gone with 256 GB SD cards == 40k photos.


Does it start replacing the oldest photos?


Currently it replaces the oldest photos, yes. (There might be use cases where you only want to keep the first 20k photos though -- if anyone wants that, get in touch and I can add a setting.)


I figured that was the case. That makes the most sense for your original use-case. I ordered one last night, are you seeing a large uptick of orders from this post?


Definitely, the HN crowd has been kind.


Would this be suitable for strapping on a helmet to take a picture every (other) second on a bike ride and turn into a time lapse video afterwards?


Looks like yes

> capture photos at particular times or on certain dates, perfect for time-lapse photography

With 50k photos on a single charge you could capture almost 28h of continuous 0.5fps video.


I was wondering about the weight which I couldn't find specified (although at that size it can't be much) and about ways that you could attach a strap to it.


For some reason I never thought to weigh it! Need to update the website.

I just put one on my kitchen scale: 70g.


Oh wow, that's almost as light as a Scatt (totally different domain, but also a very customized/specialized camera).


I think it should work pretty well for that use case.

I need to add support to the companion app to make exporting videos convenient though. Right now it only allows batch-exporting images.


No. You need some motion smoothing for that too look good. At 3MP it does not have enough CCD to stablize and transcode into smooth pics.


It usually makes sense to have a slew of tests formally defined and to write a test that functionally checks every subsystem. If you don't test, Murphy ensures you always make errors before ordering next revision boards. Rushing never helps. Assumptions always fail. Hardware's very unforgiving coming from software, just because our brains are too impatient and we feel it's OK to cowboy all the time.

For most of my boards I wound up writing a bunch of tests that automate current readings across different power rails while stepping boards through different states. This verifies that subsystems are moving approximately how I expect them to move without having to make too much of a manual test, and allowing full validation of remote control round trips. Really makes proper testing easier.

For a camera, having an LED rig on your test jig to check pixels move in the right direction when lit in different colors would be a reasonable approach.

Cool fix though... at least until the components age and the net properties shift subtly...


That is neat and your project docs are a fun read.

You'd get a design identity ++ if the dovetail backplate was more similar to ejecting toast. . . .but looks like that isn't in the final anyway.

Did you consider radar[0] instead of PIR with the MPS430?

0/ https://www.youtube.com/watch?v=9WiJJgIi3W0


Ohh fancy! No I didn't consider radar, watching that video now.

The main consideration for the motion sensor is power consumption -- Photon's PIR consumes ~2µA. Any idea what the power consumption is for these radar sensors?


Speiss’ videos are good about measuring current. He was an early one on the coin operated ESP8266 movement. Looks like they are outside your energy budget: 2.3mA is the lowest.

The video I linked was from 7 years ago? Here is a more recent one but it doesn’t seem like he measured energy consumption: https://youtu.be/s-GzUTyIH9c

As validation of your PIR-Cam idea, LilyGo sells a PIR-Cam-SSD1306 combo board: https://www.lilygo.cc/products/t-camera-s3


Thanks for putting in the effort and time into this cool project. My question is: How does your manufacturing process look like if someone decides to click the "buy" button and do you have any open orders currently?

Also do you actively use it currently on your bike or do you know some use cases of someone that bought/has it?


> How does your manufacturing process look like if someone decides to click the "buy" button and do you have any open orders currently?

I assembled ~120 of these devices beforehand so I just need to package them up and ship them out when I get an order.

> Also do you actively use it currently on your bike or do you know some use cases of someone that bought/has it?

I intended to put the device in the garage to catch the thief, rather than attach it to the bike. But with a good mounting solution (which I should invest some time into!) you could certainly use it on a bike for time-lapses. It should work great for a cross-country road trip.

A friend of mine is using it to do a timelapse of a house construction project, and I mailed out the first orders today so they're in the wild now!


Thanks for sharing your product journey. Making hardware products is very interesting, when a single guy does it.

Would you mind sharing some of your prototype to production journey?

- How did you find companies that make the parts (pcb, enclosure)?

- How do you assemble all the parts (do you do that yourself or did you find a company to do that for you)?


> - How did you find companies that make the parts (pcb, enclosure)?

For the PCB, it came down to who could meet the specs that I needed for the board. I recall the three important specs being BGA pad spacing, wire thickness, and wire spacing. The ICE40 was the aggressing chip IIRC. I ended up using nextpcb.com.

For the enclosure, I think I just Googled some and had 3 different manufacturers make the same enclosure, and chose the best one to mass produce. I ended up using mfgproto.com.

> - How do you assemble all the parts (do you do that yourself or did you find a company to do that for you)?

For the PCB, I had NextPCB do PCBA, except for the BGAs (which I soldered myself, 500 of them!) and motion sensors, because I didn't trust mailing my high-value stock to China during Chipageddon. That was likely a mistake -- in the future I would have them assemble everything, because their process isn't designed for how I wanted to do things, and soldering that many BGAs sucked.

For the final assembly I did everything by hand (insert PCB into the enclosure, screw in PCB screws, connect battery, add battery shims [to prevent rattling], add RTV gasket to the backplate, screw in backplate screws, add lens adhesive, focus lens while streaming images). It's a ton of manual labor!


Nice work! It would be cool if you would make a schematic PDF available, the KiCad 7 import of your Eagle files doesn't give a very readable result.

How did you choose the image sensor? Why an ON AR0330, and not OmniVision?

Nice choice to use an MSP430, this is a good application for using FRAM. But why use an ICE40 and an STM32 together? Why not use an STM32 with a DCMI peripheral?


> “made by Dave in California”

Love this, well done, looks like a great product.


very cool, love the website design and the blog posts had a lot of interesting bits, like the backplate removal jig. I was kinda surprised to see an fpga in there but makes sense. Could that design be repurposed as a general image sensor -> sd card module or is it pretty specific to the sensor?


Hmm interesting question. I think a lot of the FPGA RTL should be reusable for most parallel-output image sensors. (It seems like all the really nice image sensors are headed towards MIPI nowadays though...)

I tried to make SDController.v and RAMController.v as re-usable as possible.


Does it have a standard tripod mount? Also, maybe for a later iteration, if you could make a case that enables compatibility with GoPro accesories would be plus.

Otherwise, I'm very impressed, it requires a lot of dedication and different abilities to makes something like that!


It unfortunately doesn't have a mount. (A friend has been hounding me for months about that...)

I've been using adhesive pads to mount it to things. The Gorilla "mounting tape squares" are strong and don't leave any residue.


'The Gorilla "mounting tape squares" are strong and don't leave any residue.'

Which is also an engineering marvel: https://www.youtube.com/watch?v=E-F2QQuZZGk


This is fantastic! I’ve been looking for something like this to take on my runs forever, as I hate bringing my phone while running. Also for people who want to replace their phone with a smartwatch, the only thing missing is this.


The brownout prevention hack you mentioned in the pcb design page is really neat!


I got so lucky with that, still can't believe I could work around it!


Excellent information. Thank you for releasing all of this, I particularly enjoyed reading through the rainproofing as I am building a raspberry pi camera and there really aren’t any examples out there that I could find.


The camera and the blog posts are lovely! Beautiful and inspiring work. Is there any way you could publish an RSS or Atom feed? I'd love to follow your blog in my feed reader (NetNewsWire, fwiw).


I absolutely love this. Well done ! If I set a camera with 1 picture every 30 minutes, how long would the battery last ? Can I set it up outside, will it take a beating under the sun and rain ?


The best way to calculate the battery life is in terms of photos. It can take a minimum of 50k photos on a single charge, so 50k photos * 30 minutes == 2.8 years. The battery self-discharge will deplete before that though, so I'd expect 12-24 months.

Note though that the SD card can only fit 20k photos, so the battery typically lasts longer than the SD card, and after that the oldest photos are overwritten!


All of this is answered in the first 100 words of the website.


“USB C, just like god intended”

I like USB C more than A. Also quite like that this thing isn’t making itself available via wireless methods. Getting quite tired of every random thing having WiFi.


NGL, my favorite part of USB C is that the plug works both ways.


Just bought one. Not totally sure how I'll use it, but we shall see.

I think addressing the waterproofing, glass blocking motion sensor, or the non-wirelessness will improve it...


“Photon's motion sensor can't detect motion behind glass.”

That’s a pity. Though probably the use cases behind a window usually have access to power anyway and wouldn’t need this.


The real problem for me is the next point on the page:

> When placed in nature, Photon's motion sensor tends to trigger often due to grass or leaves blowing in the wind, which can cause Photon's battery to deplete quickly if configured to capture a photo when motion occurs. A future software update may provide a motion-sensitivity setting to help address this scenario.

So, not behind a glass and not outside a glass. Maybe I could place it close to my front door and check who rings to me and which cats pass by? I hope that software update will happen soon. On the other side, the demo images on the Mac app page seem to be all outdoor pictures, so I wonder if excessive motion sensitivity is really an issue.


Yeah, I was trying to set appropriate expectations for the motion capabilities. The sensor is pretty sensitive, so if there's movement within the spec'd range (~5m) it can trigger. It works quite well indoors / in garages / outdoors where there isn't constant movement in the ~5m region.

> On the other side, the demo images on the Mac app page seem to be all outdoor pictures, so I wonder if excessive motion sensitivity is really an issue.

FWIW I captured those using the time-based triggering (every 30 seconds), so the motion sensor was disabled for those photos.


Took a while to find the image resolution - 2304 x 1296 pixels. Or, 3 megapixels.

I love the website and the product's design. But I'm not sure what the use case is. Spy cam?


I originally wanted this to try to catch a thief, so there's that. My neighbor recently wanted to figure out what animal is invading their garage, so that's another one.

I spent a lot of time working on the time-tracking aspect too, so making time-lapses is a third:

https://toaster.llc/blog/timekeeping

Another (incredibly stupid or delightfully whimsical, your call XD) is putting it in your fridge to have a collection of images yourself / your family when they're hungry.


The fridge image idea is so cool!! Love that. Could the cold become a problem though?

It would be so funny to have such a device with wifi enabled, to live-blog trips to the fridge. But then the battery would become an issue of course.

Instead of making Internet-enabled fridges that serve no purpose, manufacturers should include USB ports inside their fridges.


What is the use case? Trail cameras already do this and they cost $50 instead of $200 with better photo quality and better motion sensing.

Oh and they take video too.


Trail cameras are much larger. So if size is a restraint this could be better, but valid point. Most trail cameras use 8x AA batteries!


I can customize the code for this project where I cant with a trail cam. I wish my $50 trail cam would do timelapse and motion detection at the same time. Really I want timelapsed phones and videos if motion detection.

Plus all the other reasons others said.


> better photo quality and better motion sensing

Would you have some specific model in mind, and what aspects of photo quality & motion sensing are better ?

For sure, I never seen a so nicely managed battery life.


His camera costs $200 and takes 3MP photos with no video capability and poor low light performance.

A $50 trail cam will take at least 10MP photos, will have night vision and will be able to take videos. People have left trail cams out for over a year and they were still taking photos.

Battery life is cool, but if existing devices already have more life than anyone needs what's the point?


I feel like there's a huge market for this, especially as it can be used so well by consumers a fun (non) disposable camera.

Lots of my friends have started buying disposables or point and shoot cameras as an excuse to solely take pictures and not worry about how they look until after they been developed. This is perfect for that, will start recommending it!


re: Footprints being a solved problem, SnapEDA/SnapMagic is a great place to start for beginners. You still want to verify, but they have metrics on how many users have used the footprint and other "trustworthiness" indicators.

re: the sealing, you may want to test the seals over a temp cycle. fully enclosed housings sometimes need a vent to prevent pressurizing the housing and, literally, blowing a gasket.


Cool hardware. It's DOA because the software is Mac only. You're selling a product, so if you don't put the features of that product in the hands of consumers, they will not consume.

"Native apps" are proprietary junk. Make an electron app, flutter, or react app in a week for all platforms and your users will thank you for it.


I truly admire when someone takes an hint of an idea iterates and iterates and iterates and gets into every nitty gritty detail.

I salute you.


Is there a way to have these shipped to Canada?


Send me an email (support@toaster.llc) and I can make a custom Stripe invoice / shipping label. Still need to figure out how to automate international shipping!


Would buy, but doesn't ship to Europe...


Dang I need to fix that! If you send me an email (support@toaster.llc) I'll let you know when that works.


(Another potential buyer of this camera from outside the US)

By the way, some users might be unwilling to provide credit card details without knowing whether the product can be shipped to their country. Knowing that in advance IMHO is a much better UX.


Another EU purchaser here. I've passed the link around - I think there would be many people over here that would be interested.

Also...consider, dare I say it, Windows? Or am I mis-reading "delightful, Mac-tastic software Photon Transfer is designed with love exclusively for your Mac", though I'm sure the usb c is er...bipartisan?

I'd say 30% of the people I know use a mac, the rest windows, all with linux for work etc.

*getting stuff from the states via post is no problem, just gotta check on import fees (relatively easy to circumnavigate, but I'd rather not).


Really cool! How much does it weigh? I'd love to attach it to a collar on my cat to track their fun adventures.


I just put one on my kitchen scale: 70g.


Amazing post, read through all blog posts in a single beat. I would be great to have a final blogpost on assembly process.

On a different note, it's mind-blowing that today one person today can do small scale design and manufacturing of a consumer electronics product. Super inspiring.


I love this idea! I think it would be really fun for my kids to use - maybe if it had a chunky wrap-around case so they wouldn't lose it. :) But overall this is such an elegantly executed concept. Did you ever catch the motorcycle thief?


Great product!

Out of topic: I see this trend where people do not capitalize the first letter of their title. Any reason ?


All-lowercase is an aesthetic choice. For example, Keybase doesn't capitalize the first letter of their email subjects. I believe it's meant to seem friendlier / more informal than perfect capitalization.


Makes it feel less corporate, more authentic, I feel


Except this is often done by corporations (or their spokesperson) to exploit that feeling. So we’re back to square one.


Love this - congrats Dave on the launch


Thanks bud! XD


Nice. Ever read The Circle? Bet you could get some good SeeChange camera streams going from this :)


Would be great if it had Zwave and Zigbee support... Would love this for home automation use cases


I wonder how much would it decrease the battery life to add a screen. Maybe just an e-ink display that refreshes to show the most recent image? I'd love to have a dead-simple point-and-shoot camera for my little kids to play with.


That market already exists, for example I got a simple camera from kidamento.com for my kids.

I hope OP doesn’t increase the cost of the product and decrease the battery life by adding edge case features like this.


I love "the fine print" section. This is so great. Congrats on all your hard work


The flying through space graphic is beautiful. Looks like a great product!


Plenty of small form, battery life conscious cameras out there but they all have one thing in common: shit picture quality.

Please add image samples to the website. Sunny days, well lit, cloud cover, dusk, night time etc


Love that everything is open source! Code relating to cameras have been traditionally locked down and hidden under NDAs. Surprised there's no sample photos nor specifications on image sensor.


Looks like 5MP but saves as 3MP files. https://github.com/toasterllc/MDCCode/blob/6afdde594861264f8...

Pixel resolution Size = 2304 x 1296 = 2,985,984 pixels Pixel count = 2.99 million pixels Resolution = 2.99 mega pixels Aspect Ratio Width / Height: 1.78 "landscape" (horizontal) orientation Type of aspect ratio = "HD 16:9"

Couple photos here too: https://github.com/toasterllc/MDCCode/tree/6afdde594861264f8...

I guess its for hiding a camera near where you park your bike and see who stole it or looked at it.


> Looks like 5MP but saves as 3MP files.

OMG that's so refreshing. Just recently I've come across, both from garage sales, a "40MP" camera smartphone (Chinese brand-X) that actually has, probably, a 13MP class sensor in it and upscales, and a wildlife camera that does the same.

Waste a great deal of storage just to fool people into thinking they got a better camera, and then you have to downscale all that again to achieve something like pixel-level sharpness.


Indeed it's 2304 x 1296, 12-bit color. (That .jpg in the repo was a test image from a different camera.)


Omnivision's camera datasheets and sample code can be found everywhere on the Internet.


Although it’s advertised as MAC only, most of the code looks like it’ll work cross platform. I’m sure people can hack together a CLI if they need to on Linux


Side note for those with ... let's just say unhealthy spending habits: is there a list of all the hardware stuff that HN'ers launched/kickstartered?


Hi, I really like the webcam and its long battery life, on the landing page I prefer any comparison or more specific details. Bravo


Can it record continously and for how long?


It can't record video, just stills. (In my testing I usually got ~80k stills out of the device with a new battery.)


This is really cool.

As a software guy, how can I learn more about making PCBs (other than the linked blog)?


One way is to find something you want to make that has schematics available and then hack on it. For audio stuff https://sound-au.com has lots to start from. Use jlcpcb or similar and you can get small boards made for $1 each plus shipping


hey Dave,

what would you recommend if someone wanted to go from nothing (maybe some softw. experience) to be able to do a hardware design like this? Is there any book/courses you consider to be a must?


- I think the most important skill for making hardware is just having a good fundamental understanding of electricity. Just developing an intuition around Ohm's law gets you remarkably far in terms of developing and debugging circuits. Towards that end, Khan's "Introduction to electrical engineering" and MIT's 6.01SC Unit 3 both look great.

- For this specific project, I needed to program an FPGA so I drew on my college experience (18-240) where we learned about FPGAs and Verilog. Coursera's "Introduction to FPGA Design for Embedded Systems" looks like a good option.

- Don't be discouraged by hardware tools. Coming from a software background, using hardware tools is like traveling to a foreign land where good UX is punishable by death. At its core, designing PCBs is really just drawing 2D shapes, and it's striking how painful drawing is using hardware tools (eg Eagle, Kicad) versus how delightful drawing is using artistic tools (eg Sketch, Figma).


thanks!


I really appreciate the considerations at the bottom of the page. Excellent


The fix for the MSP di/dt bug made me smile. Lucky but also smart!


10/10 landing page


Refreshing ! I'd like to see more products like these.


I wish more products had a page like this


Exclusive for Mac... Sigh...


can you make a microphone? I would buy that


Awesome project.


$200?


great landing page! "IOT? how about NOT"...i lol'd


Can it record videos?


>USB-C

>just as god intended

???


Not sure about god inventing USB-C but satan definitely invented usb 3.0 micro b


ewwww i havent seen that one used in a long time thank god


Analysis: true


For He saw that his minions required a minimal of three frustrating attempts to connect devices, in all His wisdom He required a connector that worked in just one attempt. And He saw it was pretty ok.


I'm not interested in the product, but I have to say this site is great. Too many sites that get posted in Show HN are so difficult to decipher what service they provide or function they serve. This landing page is about as clear as you could be straight away: it's a small camera -> great battery life -> pricing (without going to another page!) -> Mac Only -> Buy/Download links. You provide use cases, your tech specs are visible just by scrolling a bit, there's photos of the device that highlight its size. It even looks good. Only downside is a lack of example photos (which sound like they'll be added).

This is a breath of fresh air and I applaud your effort on it.


Yes, the site is very authentic but at first glance I was pretty confused. The animated cartoony camera followed by "only for mac" and "download" made me think this was an app, not a hardware camera.

I'd put a real photo of the camera in the hero section so people instantly grok that it's a real device.


As opposed to https://news.ycombinator.com/item?id=40557726 yesterday though it came with a disclaimer.


Yeah echoing this. Everything about the design is technically immaculate (color contrasts & usage, consistent styling, and a satisfying visual variety), but it has that super important element that most product pages lack: a cohesive narrative. Not, like, a literal narrative (though the motorcycle story sounds intense!), more like… being introduced to a friend’s friend for the first time. I guess I’d give credit for this effect to my internal questions coming up in the same order as they were answered by the page!

As a fellow solo-webdev/“founder”/layabout, OP I’d love to hear your comments on design and how you got to this point, if you find the time and interest. The camera itself looks sleek as hell and I’d love to hear about the physical design too, but that’s much less my bailiwick lol


That means a lot, thanks friend.


Mr Dave, much appreciated for the post.

Looking for help how to learn from your github where the raw data for building is located.

As an aspiring creator of similar things, I'd very much appreciate a road map from your view on how to best approach the github source... from a learners perspective.

So for example, if a break down was based on complexity, barrier of entry, activation energy of baseline starting... etc.

the key areas I see are:

- hardware design

- hardware ordering

- software design and interface with hardware

- materials selection - chips - case/3dprint/scaffolding

- time constraints to keep in mind for the above so as not to 'overload the novice'

So ... Thanks for the post and the clear historical reference frame. If you end up answering this post, it will only add to the appreciation!

:D


> simply unhackable. Photon doesn't do Bluetooth, Wi-Fi, or cellular, so your photos can't leave the device without physical access to it

saying that something is "unhackable" makes me very uncomfortable, like saying something is "bulletproof". Having no external wireless connectivity also doesn't make something unhackable. If it communicates to a host app on the computer, and that app is vulnerable, it could be hacked through that. if it has a firmware update option, you can hack it through that. I'm reminded of smea's smart sex toy hacking video, where he exploited a sex toy by going through a chat client, then exploiting its bluetooth connection via a vulnerable usb dongle. Replace bluetooth with a usb c cable and it could be vulnerable


Fair enough. When I was writing that I wasn't 100% comfortable with that wording either. I couldn't find a phrasing that meant "100% unhackable over the internet when in service", so I just went with "unhackable" and let the description clarify. But point taken.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: