The last three days have been miserable. I’ve been finding stupid, stupid little mistakes everywhere. Here’s an example:
double errorX=(zCoord.ldx-deltaX)*(zCoord.ldx-deltaX);
double errorY=(zCoord.ldy-deltaY)*(zCoord.ldx-deltaY);
These are a couple of lines of code from the program. They look pretty mundane, don’t they? But there’s a bug hiding in there: in the second line, the second term uses zCoord.ldx when it should have zCoord.ldy. That little tiny difference between ldx and ldy wrought all sorts of insidious havoc on the results. It was havoc that didn’t always show up -- in many cases the difference between ldx and ldy was small enough that the error didn’t do any harm. But there were just enough cases where that difference denied recognition of a Leonid.
I have been auditing the results very carefully. Even with this bug, the program successfully and correctly identified all 28 of the test Leonids in my sample. However, although it correctly identified the 25th Leonid, it showed it has comprising only 9 flares where there were actually 16 flares. This difference may seem small to you, but from my point of view, it was a catastrophic failure -- and it was due solely to the above-mentioned bug (which only kicks in after a Leonid has been correctly identified).
I also ran into a terribly embarrassing problem involving trigonometric calculations. As you probably know, when you’re dealing with a 360º circle, and carrying out trigonometric calculations, you always get literally ambiguous results. For example, the sin of 60º is 0.866. And if you take the arcsine of 0.866, you’ll get 60º. BUT the sine of 120º is also 0.866. So, if you take the arcsine of 0.866, and you get 60º, is the answer really 60º, or is it 120º? The same thing happens with every single trigonometric calculation you can do. The arccos of 78.46º is 0.20 -- but so is the arccos of 281.54º. Thus, every time you carry out a trig calculation, you must also figure out which quadrant the angle actually lies in. That usually requires some examination of the relative positions of the angles. It is always possible to figure out, but it’s a rat’s nest of pluses and minuses adding to each other and canceling each other out. In one of my calculations, I got the trig backwards and ended up with angles that were incorrect. This in turn screwed up the calculations in a subtle way that took a long time to track down. But eventually I nailed the damn thing.
That’s the way the last three days have gone: just one damn thing after another. I’m getting closer to a working system, but it’s frustrating because I had the system operating very smoothly a month ago. Then I switched from the data on the south side of the airplane to the data on the north side of the airplane, and everything went to hell. I can’t just custom-code for the north side data -- to be useful, the data taken from both sides must be obtained by exactly the same calculations.
Did I mention that each of the four cameras has a slightly different focal length? That in turn means that the scale of the images for each camera are different. Moreover, the horizontal scale is not the same as the vertical scale: the image intensifier distorts the image horizontally. So I have to figure out the scales for each camera. Also, the center of the field of view of the camera is not the same as the center of the image. I had to write least-squares fit algorithms to determine the precise center of each field of view as well as determine the appropriate scaling factors for each camera.