We needed it to be small, low power, low heat, provide hardware level access to a camera module, be ethernet accessible. Oh, and under $100 including a fixed M-mount lens.
At the time, it didn't seem like rolling our own hardware would have been faster.
I would argue - given we succeeded at sub 1ms syncronization - that the Pi was close to the perfect tool.
It just would have been even more perfect if it had an RTC.
For my Pi's I buy a separate RTC (uses GPIO pins). There's various available, the DS3231 is the most expensive but also the best. If you buy it in bulk (70+) I suppose you could shave some money off. If you're OK with a cheaper one (less than half the price) which functions less well (but still does the job) then PCF8523. I got mine from a local Adafruit reseller.
We couldn't justify adding ~$2500 to the bottom line, but you can be confident that we sure did argue about it.
I'd say 50/50 that I didn't know what I2C was in 2014.
Still, if we had gone and designed our own RTC daughterboard, it would have replaced the UBEC in our architecture diagram. We were buying those for $3-4 in 1000 unit quantities.
So, had you been on hand a decade ago, you might have won the argument although if I put on my board member hat, fabbing our own PCB sounds a lot scarier than buying boxes of buck converters.
It's hard to express how wild it is that they just pop right on and guarantee close to perfect voltage to each device.
https://www.alibaba.com/product-detail/UBEC-5V-3A-5A-7A-15A_...
From your URL, the second part made me wonder if the statement is correct: "UBEC 5V 3A/5A/7A/15A BEC 2-12S Lipo Step-down Module External Power Supply Full Shielding Antijamming For FPV Airplane" would this actually work?
And now, you too can share in the late night cackling joy we experienced so many years ago.
Those three pin headers on the UBEC just glide right into place on the +5/GND pins at the top of GPIO row.
Note that the graphic animation also explains that this UBEC is certified unisex... so make of that what you will.
You can attach a function to a pin, and CPU force-jump into a preprogrammed address for a handler routine, which leads into your code, then return(return(return())) back to where it came from. The trigger can be delivered by, say, a Xenon flash pointed at the ceiling and a light sensor, or a dedicated pair of wires from a master Arduino, or a intentional glitch in power line, a drone receiver per each pi all on a same channel, etc.
> fixed M-mount lens
I assume this is meant to say metric threaded C/CS mount for surveillance cameras, as M-mount is boutique full-frame Leica mount.
The RP2 was indeed low powered compared to the Intel/AMD powered systems we were otherwise familiar with.
Outside of the bubble of people with EE skills, however big the bubble is, stopping to learn expert-level mcu programming from scratch is rarely the way things work in a software startup. Despite the obvious focus of this thread, the hardware we assembled and configured was all in support of our software.
On the contrary, I've had a number of solid back-and-forths with folks about GPS, GPIO and homebrew RTC daughterboards that we could likely find success with today - almost a decade after we built what we built.
I'm honestly not sure what else you expect from me. Should I apologize for our relative ignorance at the time? Are you upset that I'm proud we managed to succeed despite doing things differently than others might have?
Still, I would politely suggest that you're underestimating the part where we needed low level access to a camera module that came with the RPi.
Even if the ESP32 had been out, we didn't have anyone handy to spend six months reverse engineering CMOS registers.
Everything is super easy a) in hindsight and b) when you're commenting on Hacker News and not actually doing it.
(And I would politely ask that you don't make assumptions about what I might or might not have actually accomplished in similar spheres, you have zero idea.)
Happy to answer any further questions you might have to the degree that I'm able.