2010.09.22
- replaced the RS-485 transceivers in the two optical encoders, and on the
  US Digital RS-232 to SEI interface board.  The two encoders are now working
  happily with the RS-232 to SEI interface board that I built, but the US
  Digital interface board is still unhappy.  Could be my prior substitution
  of an ACT32 for one of the other parts... just don't know, and since we
  have a working interface with LEDs and such, won't bother doing more now.

2010.09.23
- got the Omnibook 5700 running again as ob5700.gag.com, needed to replace
  the PCMCIA network card which was physically damaged, then updated the
  machine to lenny, and stripped out all the packages I don't need (like
  anything related to X!)

- the hard drive bearings are just loud enough to make me think putting a CF
  adapter and card in the 2.5" pata drive bay might be a smart idea?

	ordered an 8gb CF card and 2.5" adapter with DMA support from newegg

- thoughts about software structure

	Using 'predict' in server mode seems adequate for generating az/el
	data for the sun and moon, so let's just use it for now.  Ideally,
	refactoring that code to have a no-ui daemon we can launch without
	consuming a virtual console might be nice.

	Re-factor my current Python code to actually have an 'azeld' that
	sits on a socket taking desired az and el as input and reporting
	current az and el as output.

	Craft a simple text ui that allows me to select a target (park, work,
	sun, and moon for now?), uses predict's socket interface to get the
	az-el info for the non-static targets, and uses azeld's socket to
	get the work done.

  This would allow me to have azeld's implementation change if I move to some
  other motion control system, without having to re-factor any other code.

  Once this is working, there are other features I'd like to implement:

	Get some sort of computer-readable noise measuring system together,
	and either glue it in to azeld or present it as yet another daemon.

	Using the noise measuring interface, add code to "dither" around 
	the sun looking for where the noise peak is.  This might allow for 
	more robust calibration of az and el offsets for the positioning 
	system, *and* might allow me to measure things like the mechanical 
	"droop" in the elevation system at different elevations?

	Using the noise measuring interface, automate taking sun and moon
	noise measurements (pointing on the object, then at 'cold sky', then
	do the calculations).  This could be really handy for determining if
	various changes actually make improvements.