Initial commit of notes as I start the process of 'modernizing' this code,

moving from CVS to GIT in the process.

diff --git a/Notebook b/Notebook
new file mode 100644 (file)
index 0000000..9b54383
--- /dev/null
+++ b/Notebook
@@ -0,0 +1,53 @@
+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?
+
+- 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.
+
+