davekeck

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

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

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

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

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.

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

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

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.

Thanks bud! XD

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.

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

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.

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

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

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.

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.

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.

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!

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

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

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

That means a lot, thanks friend.

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

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

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

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

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?

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

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

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

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?

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.

Totally agree, the time to crack down on these devices was before they were needed in the first place.

Apple created this situation, I just hope they don't feel the need to "fix it". Given their sensitivity to bad PR, I'd be very surprised if they did.