The knobs are now much earlier to turn and the scope more stable, even without the vibration suspension pads. This makes the polar alignment a lot easier. Setup and aligned accurately in 15 mins.
Having better polar alignment means that tracking and goto's are more accurate. Tracking was fine using a 9mm eyepiece visually, and gotos using the high precision and quiet slew settings were always within the field of a 20mm eyepiece. Unfortunately I was at home in Dublin doing this so many faint objects were invisible, no trace of the whirlpool galaxy for example which was over the city.
Plus the scope has a much better feel to it.
I now know however why crosshairs are called crosshairs. Because about an inch from the lens there are two strands that cross to, well make crosshairs! I had always thought they were etched or painted on somewhere. I discovered this when one strand broke tonight, so now I have to work out how to fix that, its only the 6x30 finderscope so I'm not too worried about taking it apart.
There is also however a very small bolt floating around in the tube of the scope. Looks like I have to remove the primary mirror to get it out. What's worrying is of course where it came from! I have never seen a bolt that size in the scope before, and I'm worried that it may be from part of the housing of the secondary mirror, and that's not a trivial piece of the scope to service!
Computingwise, I'm still writing a tool to display the status of patches in testing. This is complicated by the fact that there are several states that a patch can be in, submitted, passed initial testing, failed initial testing,passed main testing etc. However we also need to consider the state of the patch in other tools, for example I need to display the appropriate message if the patch we are testing has already been released to sunsolve etc. Etc. This type of thing can be practically solved by Karnaugh maps. They are those truth table type things that your computer architecture teacher went on about, but neglected to mention any other application for! Basically you work out what your inputs are, in my case its mainly of on/off flags which is handy, then highlight the `boxes` that trigger particular states, and you can then trivially write the logic to arrive at those cases. This is still on sheets of paper at my desk, and hasn't made it into the code yet since some variables can have several states and I need to see if they should be split into separate binary conditions or if there is a mechanism for dealing with that in regular maps (must have been asleep that day in college).
Why am I going to this trouble? Well two weeks after writing the initial code, I'm still getting emails from people pointing out patches that slip through the logic. Currently the code is the logic, rather than an implementation of the logic, which is what I'm trying to fix.
p.s. Today the 1000th US soldier died in Iraq. This does not seem to be a news event today so I thought I would do them the honour of mentioning them (not a news story at all on many US newssites). May they and the many thousands of Iraqi victims of this confilct rest in peace.
