Would it have worked to add something like a single GPS module connected to an ESP8266 that sends a pulse every minute to all the Pis' GPIOs so they can sync?
Hm, yeah, you'd need a much more frequent method of synchronization to avoid that. I'm assuming the rate wasn't constant, huh? Because of voltage drops depending on draw?
I want to be a better conversation partner on this, but I am extremely constrained in what I can share and again, it was 8-9 years ago that this was all top of mind.
Can we mutually agree that in a year of not-dumb people trying everything we could manage to achieve the best outcome, we tried a lot of things and we often didn't know what we didn't know?
We cannot, because I'm not trying to find you a solution you didn't think of, I'm trying to learn from your failures so I can skip over them next time I need something similar to this.
First, our failures were not technical. We succeeded at creating a sub-$100 camera node that could be replicated and/or replaced quickly by relatively unskilled talent.
If I was going to do it all over again with the decade of engineering skills I've learned, I would look towards fabbing our own RTC I2C daughterboards and trying some GPIO-based approaches to triggering.
However, given our constraints, the solution I've described above worked incredibly well. I wouldn't be embarrassed to do it again.
I'm not saying you failed at the task, but that you tried a bunch of things along the way (that you've detailed in this thread) and they didn't work for whatever reason. That's valuable to know, it saves me time if I want to do something similar in the future. Plus, it's just nice to hear about the engineering of it all.
However, if we could have used GPS at a marginal cost of $5 at the time, it's very likely we would have been excited to hear about this.
Thanks for the lightbulb moment.