Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What went wrong there? Surely the pulse propagated at close to the speed of light? What kind of synchronization accuracy did you need?


<1ms

The internal "clock" time would start to drift immediately after it was set.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: