ppmax wrote in post #17453079
I have a question that I have thought a lot about but have not been able to wrap my head around...perhaps you can shed some light.
Given a "black box" containing both hardware and software, is it possible to design a test that will enable one to identify the cause of any given behavior? In other words, as it relates to focus issues, how might one devise a test to prove that hardware (perhaps misalignment or a faulty sensor) or software (perhaps a bug in the AF algorithm) was to blame? The catch is that you don't get access to any source code, or any schematics...you can only use the system through the various interfaces that have been provided to the user.
I'm not challenging your comment...I'm just genuinely interested to know if this question is answerable.
In the true black box example, with zero knowledge of what systems, and how they work, then no it would not be possible to tell what part of such a system was causing the error. All you could know is that you have good data going in, and bad data coming out. At which point you would replace the box. With detailed knowledge of what was in the box, and how exactly it worked, then yes you could make a very educated guess, and it would only be a guess, at what exactly caused the fault. That knowledge might mean that you were correct considerably more than half the time. Remember that the knowledge of the systems would also include the details of previous faults, and what caused them. The only way to be sure of the fault though would be to open it up and carry on fault finding within the box.
I spent 9 years in the RAF as a ground radar technician, working on complex air defence radar systems. Our basic 18 month trade training course meant that we could, given the manuals, probably fix most systems, down to the "box" level on any radar. The radar system that I mostly worked on though took a six month further course to be able to work down to the component level. This was a system that went into full service in 1966, so was mostly Valve technology, with the control logic systems using 50V post office relays (as used in old telephone exchanges). This meant that we could actually work down to the component level, modern PCB's and surface mount technology mostly makes that impossible these days. The transmitter hall was about 50m by 25m and the processing hall, upstairs was the same size, but our systems only filled just over half that area. Fortunately the system was multi channel, so we only really had to know around eight cabinets (7 foot tall, five bay 19" racks) worth of systems. Most of the system was duplication, as there were a total of 12 channels. Fortunately most of the control systems that we had were aimed at telling us technicians just where any particular system may have a fault. So as at least to be able to know which cabinet to go start looking in. Even out cameras have this sort of failure monitoring systems, along with the error codes, which tells the technician what sub systems to go look at.
As far as the alignment between the location within the image area of the actual phase detect system, and the indicators in the viewfinder, well that is not always going to be precise. Especially on cameras with interchangeable viewfinder screens. The viewfinder indications should really only be taken as an approximation, which should allow you to place the AF point reasonably close to the point you want to focus on in the image.