Show HN: I made a tiny camera with super long battery life (toaster.llc)
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
307 comments
[ 0.59 ms ] story [ 265 ms ] threadFor 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.)
I tried to make SDController.v and RAMController.v as re-usable as possible.
Why not just have it connect as a generic mass-storage device?
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!
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.
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.
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...
SD cards aren't really black magic since they "speak" SPI, meaning people have been interfacing basic microcontrollers to them since forever.
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.
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!
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.
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.
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?
[1] https://www.infineon.com/cms/en/product/memories/f-ram-ferro...
[2] https://ambiq.com/apollo3-blue-thin/
(FWIW Photon's USB stack is handled by a STM32F730 and I've been perfectly happy with it. Expensive though.)
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.
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'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.
The guys with the purple LiSoCl2 batteries make ones with up to 40 years of usable life
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...?
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.
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?
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?
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.
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?
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.
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.
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.
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.
If you’re doing something as a passion project you should absolutely do things based on what you’re a fan of.
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.
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
- 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.
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.
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.
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.
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.
> 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!
...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.
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.
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'm really struggling to figure out why people are excited about this. Do they not know trail cameras exist?
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.
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.
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.
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.
[1] https://toaster.llc/blog/architecture/index.html
Website is painfully custom haha. Credit to the wonderful Iconfactory for the Photon art!
I need to make a blog post showing how to replace the battery.
(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...
> 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 just put one on my kitchen scale: 70g.
I need to add support to the companion app to make exporting videos convenient though. Right now it only allows batch-exporting images.
- 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
https://apps.apple.com/us/app/photon-transfer/id6476578040
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.)
Personally I'd much rather just drop the custom Mac app and replace it with:
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.
I just don't like being threatened on their download page.
Love this, well done, looks like a great product.
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.