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.

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.

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)?

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

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

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.

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.

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

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

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

I 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.

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?

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?

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

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.

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.

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.

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.

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?

(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.

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?

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.

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.

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

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 ([email protected]) with your address and I can send a Stripe invoice.

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.

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.

- 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.

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.

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.

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...

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])

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).

- 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

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

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?

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.

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.

Haha me too man, me too.

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

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.

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.

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.

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.

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.)

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).

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.

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.

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...

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.

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.

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

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.

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.

...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.

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

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

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

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

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

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.

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.

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

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)?

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!

Otherwise, I'm very impressed, it requires a lot of dedication and different abilities to makes something like 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.

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

> 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 need to add support to the companion app to make exporting videos convenient though. Right now it only allows batch-exporting images.

I salute you.

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!

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.

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

> 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.

> 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.

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

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

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

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.

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.

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.

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

Oh and they take video too.

Plus all the other reasons others said.

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.

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?

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

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

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

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

(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...

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.