[HN Gopher] Show HN: I made a tiny camera with super long batter...
___________________________________________________________________
Show HN: I made a tiny camera with super long battery life
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
Author : davekeck
Score : 752 points
Date : 2024-06-03 13:31 UTC (1 days ago)
(HTM) web link (toaster.llc)
(TXT) w3m dump (toaster.llc)
| mariocesar wrote:
| I love "the fine print" section. This is so great. Congrats on
| all your hard work
| idiot900 wrote:
| 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.
| davekeck wrote:
| 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.)
| fogleman wrote:
| You should really put up some sample images.
| tmountain wrote:
| 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!
| aconz2 wrote:
| 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?
| davekeck wrote:
| 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.
| laweijfmvo wrote:
| > exclusively for Mac
|
| Why not just have it connect as a generic mass-storage device?
| Suppafly wrote:
| Yeah, even if you're a mac guy, it doesn't make sense to make
| hardware that is mac only.
| jackstraw14 wrote:
| 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.
| rasz wrote:
| 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.
| davekeck wrote:
| 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!
| rasz wrote:
| 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.
| CamperBob2 wrote:
| 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.
| zelse wrote:
| Your handling of folks' feedback in this thread is
| impressively graceful, fwiw.
| mjard wrote:
| Most recent mailbag, EEVblog1619:
| https://youtu.be/ABqDGjcwMsg?t=1118
| miahi wrote:
| 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.
| davekeck wrote:
| 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.
| tredre3 wrote:
| 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...
| foofoo55 wrote:
| 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).
| Rinzler89 wrote:
| _> 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.
| throw46365 wrote:
| TIL!
| LeifCarrotson wrote:
| 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.
| davekeck wrote:
| > 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!
| qingcharles wrote:
| 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.
| beardyw wrote:
| > 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.
| barbs wrote:
| Maybe an electron app? I mean, we all love electron, right?
| Rinzler89 wrote:
| 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.
| davekeck wrote:
| 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?
| nereye wrote:
| 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/
| davekeck wrote:
| 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.)
| abdullahkhalids wrote:
| Are there any RISC-V chips that do the same?
| airbreather wrote:
| 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.
| g_p wrote:
| 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...
| davekeck wrote:
| > 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 5uA (MSP430 + motion sensor)
| while sleeping, while the battery's self-discharge is
| more like 80uA.
|
| That's probably a good argument for using a more powerful
| chip though, if the battery self-discharge is that high,
| hah.
| geocrasher wrote:
| 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.
| balou23 wrote:
| 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
| imhoguy wrote:
| Panasonic BR2032 has 30uA discharge rate
| https://www.digikey.com/en/products/detail/panasonic-
| bsg/BR-...
| foldr wrote:
| 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.
| imhoguy wrote:
| Maybe tiny solar panel + capacitor, like 1980/90s
| calculators had, then it could run "forever" - digital
| Millennium Camera.
| glial wrote:
| This is a cool idea!
| foldr wrote:
| Some of the SiLabs EFM32 parts have comparable sleep
| currents.
| laweijfmvo wrote:
| Thanks for sharing the explanations, and hey it's open source
| so someone can make a linux version if they want!
| bambax wrote:
| 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...?
| davekeck wrote:
| > 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.
| bambax wrote:
| 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?
| davekeck wrote:
| 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?
| MartijnBraam wrote:
| 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.
| bambax wrote:
| 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?
| qingcharles wrote:
| 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.
| tomcam wrote:
| Love these answers. I declare you officially to be a badass.
| hcfman wrote:
| Indeed, kudos for that. Nice to see the out of the box
| thinking.
| taldo wrote:
| 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.
| nullc wrote:
| 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.
| LoganDark wrote:
| > 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.
| airbreather wrote:
| 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?
| davekeck wrote:
| > 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.
| bombela wrote:
| Make it a tar archive with some common RAW photo format?
| cat /dev/sda > raws.tar
| Rohansi wrote:
| The software being exclusive to Mac is apparently a feature in
| this case.
| davekeck wrote:
| 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.
| Rohansi wrote:
| 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.
| asdfman123 wrote:
| 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.
| caseyohara wrote:
| > 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.
| NBJack wrote:
| 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.
| manuelmoreale wrote:
| > 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.
| kekub wrote:
| 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?
| davekeck wrote:
| > 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.
| squarefoot wrote:
| > 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
| TeMPOraL wrote:
| 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.
| mysteria wrote:
| 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.
| kristianp wrote:
| > 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.
| romwell wrote:
| >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.
| mysteria wrote:
| > 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.
| Eric_WVGG wrote:
| 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.
| michaelmior wrote:
| There are other options such as chargers powered by solar
| power, hand crank, fire, etc.
| walterbell wrote:
| 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!_
| taid9iK- wrote:
| My Cowon D2 might be old but it still goes on for days and
| days and ... you get it, it's awesome!
| mixermachine wrote:
| 15 hours seems not that much considering an iPod nano can do
| 30 hours (according to Apple)
| latexr wrote:
| Fifteen hours is not enough for a two-week hike. That gives
| you one hour of listening per day, maximum.
| ramses0 wrote:
| 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.
| codazoda wrote:
| 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.
| Rinzler89 wrote:
| _> 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.
| fmj wrote:
| 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.
| bufferoverflow wrote:
| Just bring a power bank.
| michaelmior wrote:
| > 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.
| nicwolff wrote:
| I don't think the camera goes on the motorcycle.
| davekeck wrote:
| 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.)
| michaelmior wrote:
| That makes a lot more sense :) Although you still have the
| problem of someone potentially finding it.
| whatahw wrote:
| 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?
| ipsum2 wrote:
| 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.
| instagib wrote:
| 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.
| MarkusWandel wrote:
| > 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.
| davekeck wrote:
| Indeed it's 2304 x 1296, 12-bit color. (That .jpg in the repo
| was a test image from a different camera.)
| userbinator wrote:
| Omnivision's camera datasheets and sample code can be found
| everywhere on the Internet.
| peterhi wrote:
| 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
| designed wrote:
| 50,000 pic battery life * 1 pic every 30 seconds = ~17 day
| battery life. Not bad
| hiatus wrote:
| Small note: though the battery will last for 50k pictures,
| the storage will begin overwriting old photos after ~20k.
| davekeck wrote:
| It does feel a little weird that the battery outlasts the
| storage. Maybe I should've gone with 256 GB SD cards == 40k
| photos.
| mjard wrote:
| Does it start replacing the oldest photos?
| davekeck wrote:
| 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.)
| mjard wrote:
| 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?
| scld wrote:
| 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.
| polalavik wrote:
| 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.
| abdullahkhalids wrote:
| It says here [1] that the image sensor is AR0330.
|
| [1] https://toaster.llc/blog/architecture/index.html
| davekeck wrote:
| > 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!
| clumsysmurf wrote:
| 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.
| NegativeLatency wrote:
| Also when the battery dies and it renders the product garbage
| that only someone with fairly advanced skills can fix.
| davekeck wrote:
| 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...
| tromp wrote:
| 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?
| thih9 wrote:
| 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.
| tromp wrote:
| 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.
| davekeck wrote:
| For some reason I never thought to weigh it! Need to update
| the website.
|
| I just put one on my kitchen scale: 70g.
| dmoy wrote:
| Oh wow, that's almost as light as a Scatt (totally
| different domain, but also a very customized/specialized
| camera).
| davekeck wrote:
| 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.
| euniceee3 wrote:
| 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.
| b20000 wrote:
| I want to know who designed your site and who implemented it :-)
| One of the best sites I have ever seen.
| tamimio wrote:
| 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
| davekeck wrote:
| 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
| higgins wrote:
| great landing page! "IOT? how about NOT"...i lol'd
| qup wrote:
| 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?
| davekeck wrote:
| > 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.)
| davtbaum wrote:
| Love this - congrats Dave on the launch
| davekeck wrote:
| Thanks bud! XD
| k2xl wrote:
| Would be great if it had Zwave and Zigbee support... Would love
| this for home automation use cases
| rossant wrote:
| Can it record videos?
| LorenDB wrote:
| 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.
| meatmanek wrote:
| 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.
| davekeck wrote:
| 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.
| nottorp wrote:
| Can he afford Qt? He'd need a lawyer on retainer.
| LorenDB wrote:
| If the app is opensource, Qt is 100% free under GPLv3.
| detaro wrote:
| Most of it is LGPL, so the app doesn't even need to be
| open-source and on desktop compliance is quite easy.
| nottorp wrote:
| Technically, you're correct.
|
| I just don't like being threatened on their download
| page.
| dbish wrote:
| Nice. Ever read The Circle? Bet you could get some good SeeChange
| camera streams going from this :)
| _Bruno42 wrote:
| Really cool! How much does it weigh? I'd love to attach it to a
| collar on my cat to track their fun adventures.
| davekeck wrote:
| I just put one on my kitchen scale: 70g.
| carl_dr wrote:
| > "made by Dave in California"
|
| Love this, well done, looks like a great product.
| NegativeLatency wrote:
| 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.
| bambax wrote:
| 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.
| mschuster91 wrote:
| 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?
| scosman wrote:
| 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
| ozzydave wrote:
| Oh wow! I've wanted this for ages, even started making it
| myself at some point!
| demondemidi wrote:
| Blows my mind how much this guy knows. From embedded to native
| apps to fabrication. I feel lazy as fuck.
| nl wrote:
| This is awesome!
| injidup wrote:
| 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
| corytheboyd wrote:
| 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.
| foehrenwald wrote:
| >USB-C
|
| >just as god intended
|
| ???
| thebruce87m wrote:
| Not sure about god inventing USB-C but satan definitely
| invented usb 3.0 micro b
| tomcam wrote:
| Analysis: true
| anon115 wrote:
| ewwww i havent seen that one used in a long time thank god
| b3lvedere wrote:
| 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.
| rrr_oh_man wrote:
| Your "fine print" is an honest breath of fresh air.
|
| Excellent communication throughout the page!
| adolph wrote:
| 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
| davekeck wrote:
| 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 ~2uA. Any idea what the
| power consumption is for these radar sensors?
| adolph wrote:
| 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
| WhackyIdeas wrote:
| 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.
| pineaux wrote:
| Would buy, but doesn't ship to Europe...
| davekeck wrote:
| Dang I need to fix that! If you send me an email
| (support@toaster.llc) I'll let you know when that works.
| rpozarickij wrote:
| (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.
| InCityDreams wrote:
| 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).
| apocalyptic0n3 wrote:
| 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.
| davekeck wrote:
| That means a lot, thanks friend.
| bbor wrote:
| 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
| sgallant wrote:
| 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.
| password4321 wrote:
| As opposed to https://news.ycombinator.com/item?id=40557726
| yesterday though it came with a disclaimer.
| hm-nah wrote:
| I really appreciate the considerations at the bottom of the page.
| Excellent
| wferrell wrote:
| 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).
| davekeck wrote:
| 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.
| 23B1 wrote:
| $200 is a very fair price given the capabilities and novelty
| - since you're at it, would love to hear your BOM cost too!
| davekeck wrote:
| 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.
| RyJones wrote:
| 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.
| davekeck wrote:
| 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...
| RyJones wrote:
| 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.
| jkestner wrote:
| 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.
| j1mmie wrote:
| 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?
| davekeck wrote:
| 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.
| bambax wrote:
| 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.
| lofaszvanitt wrote:
| Can it record continously and for how long?
| davekeck wrote:
| It can't record video, just stills. (In my testing I usually
| got ~80k stills out of the device with a new battery.)
| eth0up wrote:
| 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.
| supportengineer wrote:
| The flying through space graphic is beautiful. Looks like a great
| product!
| the__alchemist wrote:
| 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.
| colordrops wrote:
| 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.
| davekeck wrote:
| > 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.)
| kelnos wrote:
| 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.
| zoky wrote:
| It's not an oversight. There are very good reasons for it,
| which are detailed elsewhere in the comments thread.
| pierrec wrote:
| 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.
| 627467 wrote:
| > 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?
| temp20240604 wrote:
| 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.
| romwell wrote:
| 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.
| davekeck wrote:
| 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.
| iends wrote:
| This is really cool.
|
| As a software guy, how can I learn more about making PCBs (other
| than the linked blog)?
| mattclarkdotnet wrote:
| 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
| LiquidPolymer wrote:
| 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.
| geocrasher wrote:
| Check out CHDK for Canon PowerShot cameras.
| abhgh wrote:
| 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.
| alexdig wrote:
| 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!
| micw wrote:
| 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?
| whatahw wrote:
| 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.
| jtriangle wrote:
| Just open the gopro and remove the beeper. Then connect it to a
| big external battery.
| throwaway81523 wrote:
| There are lots of tiny low-powered video cameras made for use
| on mini drones.
| holografix wrote:
| 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
| WheatMillington wrote:
| Awesome project.
| numpad0 wrote:
| 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.
| temp20240604 wrote:
| 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.
| r0fl wrote:
| 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
| remywang wrote:
| 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.
| r0fl wrote:
| Is there a way to have these shipped to Canada?
| FredPret wrote:
| I wish more products had a page like this
| demondemidi wrote:
| The fix for the MSP di/dt bug made me smile. Lucky but also
| smart!
| edweis wrote:
| Great product!
|
| Out of topic: I see this trend where people do not capitalize the
| first letter of their title. Any reason ?
| LoganDark wrote:
| 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.
| xelia wrote:
| Makes it feel less corporate, more authentic, I feel
| latexr wrote:
| Except this is often done by corporations (or their
| spokesperson) to exploit that feeling. So we're back to
| square one.
| e-_pusher wrote:
| The brownout prevention hack you mentioned in the pcb design page
| is really neat!
| jrussino wrote:
| 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.
| labaron wrote:
| 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.
| contingencies wrote:
| 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...
| sgt wrote:
| Refreshing ! I'd like to see more products like these.
| owenpalmer wrote:
| 10/10 landing page
| max-ibel wrote:
| 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...
| davekeck wrote:
| 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.
| spaceman10 wrote:
| 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
| voidUpdate wrote:
| > 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
| davekeck wrote:
| 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.
| mlukaszek wrote:
| 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!
| labaron wrote:
| "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.
| pmontra wrote:
| 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.
| davekeck wrote:
| 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.
| phito wrote:
| Exclusive for Mac... Sigh...
| anxioustech wrote:
| 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
| ?
| unglaublich wrote:
| All of this is answered in the first 100 words of the website.
| davekeck wrote:
| 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!
| tcmb wrote:
| 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!
| davekeck wrote:
| 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.
| wilgertvelinga wrote:
| '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
| balou23 wrote:
| 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])
| davekeck wrote:
| 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).
| julius wrote:
| 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)?
| davekeck wrote:
| > - 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!
| nusl wrote:
| "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.
| conductr wrote:
| NGL, my favorite part of USB C is that the plug works both
| ways.
| kaladin-jasnah wrote:
| 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.
| xur17 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| conductr wrote:
| 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
| rtaylorgarlock wrote:
| 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.
| azinman2 wrote:
| 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.
| kaladin-jasnah wrote:
| 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/To
| ols/MDCUt... somewhere more prominent on the page would be
| helpful, as this was not clear to me until I read the
| comments here.
| ImPostingOnHN wrote:
| 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?
| azinman2 wrote:
| 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.
| Zambyte wrote:
| 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.
| latexr wrote:
| > in a Just Girly Things cursive font.
|
| The font isn't cursive. It's exactly the same as every
| other section.
| Zambyte wrote:
| ctrl+f "Exclusively for Mac". There is one hit (though
| there is another similar message that is not cursive).
| latexr wrote:
| 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.
| Zambyte wrote:
| I would guess you saw the other message:
|
| > Photon Transfer is designed with love exclusively for
| your Mac
|
| Which isn't cursive
| hombre_fatal wrote:
| 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.
| wilg wrote:
| 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.
| flapjaxy wrote:
| 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.
| kaladin-jasnah wrote:
| 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)?
| whatahw wrote:
| 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.
| ocal5 wrote:
| > 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.
| whatahw wrote:
| 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?
| dsalzman wrote:
| 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!
| euniceee3 wrote:
| 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.
| azinman2 wrote:
| 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?
| davekeck wrote:
| > 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?
| zellyn wrote:
| 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).
| romanzubenko wrote:
| 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.
| parag0n wrote:
| 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?
| chrisallick wrote:
| 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...
| ezl wrote:
| 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.
| devwastaken wrote:
| 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.
___________________________________________________________________
(page generated 2024-06-04 23:02 UTC)