From a9fbe1fcc0651924cfd4ba4b3f88837bf12f74aa Mon Sep 17 00:00:00 2001 From: Bdale Garbee Date: Thu, 23 Sep 2010 12:16:28 -0600 Subject: [PATCH] Initial commit of notes as I start the process of 'modernizing' this code, moving from CVS to GIT in the process. --- Notebook | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Notebook diff --git a/Notebook b/Notebook new file mode 100644 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. + + -- 2.47.2