On Cameras and Pictures

This day at work, my boss was down with fever and I was taking up the weekly status review in his stead. It took half the time which was well spent, attendance being thinner than usual. The rest of the day was spent in finding another (sigh!) anomaly with camera images on something we were working on. By the end of the day, we did find an answer to it, but we had created collateral restrictions working on it.

Another friend debunks from work to take a really long New year weekend vacation. That would leave me hunting down more bugs sitting by myself. I do like doing it, but sometimes it can grow to become quite a weight bearing down on oneself.

Coming back to the main thing, Camera's are odd devices - the modern digital video sensors. The CMOS Sensor Interface originally dismissed as a lower quality (and therefore low cost) alternative has gained popularity with much change in technology. Most sensor companies have decided to put a Application Specific Digital Signal Processor with their Sensors. This actually means that even if a CMOS Sensor is sensing video with less accuracy and sharpness than its cousin, the CCD, we could have "patches" or workarounds that "post-process" the captured image and show it to be of better quality in digital terms.

As these sensors are intended to be integrated in very small designs, they are generally low power consuming. That might seem like a feature to most people, however that means strict restrictions in communicating/programming a CMOS sensor. The major part of the problem that I've been tackling through the day has been on sequencing the program to the DSP paired with the CSI (CMOS Sensor Interface.)

Debugging it seems would occupy a major portion of the timeline of any product development. It is sometimes an interesting exercise if you would discount the human communication aspects at the time of facing a blocker and working through it. Mildly put whenever you encounter major problems in any product/service that on sale would fetch revenue, someone needs to be "accountable" for the "delay" (therefore loss of opportunity) in providing a consistent solution (even a workaround if it were reasonably secure and consistent.)

I do remember Alan Cox's speech on ratio of errors in hardware versus software on which I disagree entirely with his opinion that hardware is relatively much more bug free. I see that hardware is designed in a generic manner to send most of the complexity to "replaceable" and/or "upgradeable" software. This would mean that with higher complexity and offer of features over a generic platform, software would take the bane of being more buggy whenever engineered within strict time-frames with requirements changing along side (on the assumption that software can adapt and incorporate changes much easier than firmware/hardware.) Further, I see that a good number of hardware bugs (including the infamous pentium f00f bug) were worked around in "software."

So whenever a system as a total malfunctions, as most of its features rest in software, so do most of the errors (proportional to the features.) Unfortunately this relationship of software[features:errors] is not normally linear. I would assume that the mathematical non-linear relationship is statistically acceptable in any system that is operational with almost 0 probability of total failure and almost unity probability of being functionally useful for a predetermined set of tasks.

With reliability paradigms existing, like 5 nines or 7 nines, it is reasonable to assume that man-made system in an open environment has a 0 probability of failure (and therefore total perfection.) So engineering time spent in tilting the probability of failure towards 0 for any system grows in an asymptotic non-linear manner as you close in on the 0 but never reach it. That's a nice way of looking at "systems with embedded software" and their failure.

The unfortunate part is that I'm right now having to spend non-linear time in creating these shifts to close the probability towards 0. It does become exciting quite often as you crack the jigsaw puzzle a few pieces at a time.