Tag Archives: investigation

Taking charge of the situation

Recently, my trusty steed (the VFR) has been anything but “trusty”. After a great ride through the Victorian hills it abruptly decided not to start. The all too familiar “chugging starter motor accompanied with the dash going dim followed by the clock resetting to 1:00am” of a flat battery greeted me. Given that the battery would be approaching the five year mark, I thought nothing of it and replaced it.

Five engine restarts with the new battery later and I was left staring in disbelief as the dash again went dim and the clock went back to 1:00am. Sidenote: Why is it that Honda insists on making the clock so impossible to set without uttering profanities? When pressing two buttons at the same time means AT EXACTLY THE SAME TIME!

After coaxing the battery back in to a reasonable state with a charger it was time to whip out the multimeter and perform some testing. The simplest test from the workshop manual consists of running the engine at 5000RPM with the lights on high beam and measuring the voltage across the battery terminals. The manual rather cryptically suggests that the charging voltage should be more than the battery voltage “at rest” and less than 15.5 volts. Given that it was slightly lower than before commencing the test, it seemed a fairly safe bet that the bike was no longer charging the battery.

Back in the day, “they” used to say that Hondas were notorious for cooking regulator/rectifiers. My first Honda (the mighty Super-blackbird – the bike that was ever so briefly the fastest production model motorcycle on the planet) certainly managed to break this component and overcharge the battery in the process. It appears that Honda beefed up this component as my next Honda (a 929 Fireblade) burnt out the stator coil. It was looking like the VFR had suffered a similar fate.

The workshop manual specifies various tests – measuring resistance and testing continuity of various connections to determine the faulty part in the charging circuit. On the right hand side of the motorbike is the connector from the stator into the charging circuit. It is described as being a “3P natural connector” although “white” seems to be an equally suitable term…


According to the manual, there should be no continuity between any of the three yellow wires (in the plug) and ground. The multimeter revealed that two of the three wires did indeed have continuity to ground and hence I had found the problem! As for what to do about it, well that is a story for another time.

How good is the black-box in your program?

I am a “big fan” of the television series “Air Crash Investigators“. I’m not what I consider “morbid” – the concept of making a TV series from actual plane crashes is slightly disturbing. It’s the methodical investigation that appeals to me. The thoroughness with which the investigations are conducted ensures that the airline industry is always striving to improve its safety record. That gives me comfort everytime I set foot on a plane. – However, I don’t recommend you watch one of the shows immediately before boarding an aircraft!

As you are no doubt aware, key to most aircraft crash investigations is the Black box. It contains vital details of the aircraft and along with the cockpit voice recordings help investigators unravel what happened during the final moments of the doomed flight.

Fortunately, the average software developer does not have to write software with the added pressure of it costing human life if it all goes pear-shaped. Of course, there are exceptions to this. Due to the lower cost of failure, most computer applications won’t be stringently controlled to protect against program failures. When a program fails, resources need to be devoted to resolve the problem for the customer. This costs your company money. “Resolving the problem” for the customer, is different to “fixing the bug that caused the error”. This may involve manipulating registry entries, files on disk or other methods. All’s fair in love and war… The more customers you need to fix this problem for, the more compelling finding the underlying problem becomes.

This is where decent error recording code comes into play. General exception handlers tend to include call-stacks these days. These are invaluable to locating the moment where something went wrong, but unfortunately, they don’t provide much context as to how the program came to this point. What do your support engineers ask for when investigating problems? A registry dump? A file listing? Configuration files? Why not package these up in an archive that can be sent through to your technical support people? Is your software capable of telling you the final moments before the crash? Can it report the features used that led to its demise? If it doesn’t, retrofitting this sort of code to your application can be considered a “long term investment”. It will cost your development now, it’s an unsellable feature for the customer, but you will reap the rewards for your effort down the track. Trust me, it will be worth it!
Add to Technorati Favorites