davekeck

Surprised that folks were still using RealPlayer in 2011

It took me a minute to realize they're not just videos too. Really outstanding work.

“Muitithreabring”

Something I still fail to understand is where you can actually spend 20ms

Aren’t these numbers .2 ms, ie 200 microseconds?

Out of curiosity, how is that measured across machines?

(The first thing that comes to my mind would be to use an oscilloscope with two probes, one to each machine, but I’m guessing that’s not it.)

To work towards eliminating PFAS in everyday products, I envisioned a service where people could send in things they own to have them tested, and the results would be published on a website/app and searchable via barcode. Win/win: users get free PFAS testing, and the service gets free products to test to create a database.

I researched how to perform rigorous PFAS testing but it looks like the best method is PIGE which requires a particle accelerator, which aren’t exactly easy to come by.

Anyway just posting this in case anyone has thoughts or would be interested in working on something like this.

I always assumed it was because FM station bandwidths (200kHz) are much wider than AM (10kHz). AM's 10 kHz chops off a lot of human-hearable frequencies.

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

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

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

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

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

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

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

Definitely, the HN crowd has been kind.

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

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

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

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

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

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

Appreciate your thoughts.

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

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

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?

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

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

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.

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

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

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

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.

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

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.

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.

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

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

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.

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

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

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