April 9, 1992

	As luck would have it, KCT510 contained a potentially
disastrous bug.  If, during an active pass, the mode was switched
from real time to tabled and an attempt was make to load the
table, a math error occurred that caused the program to crash. 
Unfortunately, if the rotors were moving when the program
crashed, nothing short of turning off the rotors would prevent
them from continuing to the mechanical stops (whatever they may
be).  Brooks points out in his KCT/T manual that if the rotors
are activated and the program is killed (such as a "warm restart"
would do), the rotors will continue to turn since the controlling
program has died.  The safest approach is to make sure your
antenna system can handle full excursions of the rotors to their
mechanical stops.  Short of that, if the KCT/T (i.e., your
couputer) dies for any reason, TURN OFF THE POWER TO THE ROTORS
IMMEDIATELY.

	I believe this version (KCT511) has all the bugs out, but
checking all the various combinations of functions and
transitions between modes for all possible conditions is
difficult and time consuming, to say the least.  Incorporating
functions that were never intended has resulted in some pretty
complicated and convoluted code.  I've taken it about as far as
it will go without a major rewrite, and I think I'll save that
energy for other projects.

	I am very active on UO-22 and Internet, so those are the
two best ways to contact me.  I check CI$ occasionally, and after
being spoiled by 9600 baud, rarely get on AO-16 and LU-19
anymore.



March 6, 1992


	This package contains all the contents of the original
(KCT500) plus the new AMSAT Journal Article describing the new
features (KCT510.TXT).

	The software interrupt used by OrbitDRV to pass the
range rate is INT 64H.  If you use other software that also
attempts to use INT 64H, you may have a conflict and strange
operation may result.  Try to isolate the offending program
by removing one program at a time.  I have my KCT/T and 
Quiktrak/InstantTrack running on a separate IBM PC (with
coprocessor) to avoid the problems associated with trying
to run TSRs and CPU intensive applications and handle PB
and PG (or NET) with 9600 baud traffic at the same time.





November 1, 1991
                                 
                                 
	This package should contain the following:

	KCT500.TXT (AMSAT Journal Article) 
	TUNER.COM
	DRV.COM
	OSC.COM
	MOVENOW.COM
	BBSROTOR.COM
	DEPH.COM
	README.TXT


HARDWARE MODIFICATIONS

	Read the instructions in the AMSAT Journal article
thoroughly and make sure you have the tools to make the necessary
mods.  You can easily mangle your KCT card if the mods are not
done carefully.  I tried to make them as simple as possible and
still maintain the original functionality of the card, so the
original software can be run with no problems.  The only change
that should be necessary is replacing the "modified" 74LS126 (U7)
with a new 74LS126, which is easy if a socket is installed.


SOFTWARE INSTALLATION

	First, BE SURE TO SAVE A COPY of your original,
unmodified KCT files so that when the inevitable happens, you can
at least get back to square one.  I have modified the DRV, OSC
and TUNER "COM" files, and the others check for the correct
version, so you must use ALL of the files in this package. 
Simply replace your current COM files with the COM files I have
supplied, make sure your time and keps are as accurate as
possible and reboot your system.

	The changes in the DRV and OSC files are minimal and the
RAM requirements are about the same as the original versions. 
The TUNER file is much larger to accommodate the new code and a
large buffer for the tabled pass functions.  At least 80K of free
RAM is required for this version to run.

	Anytime mods are made to a product as complicated as the
KCT (especially by someone other than the original author), the
chance for bugs is great.  I have used the modified KCT for about
a month without any problems, but who knows what lurks during the
next pass!  I would appreciate bug reports, but depending on 
(professional) work load, family activities, etc. I cannot
guarantee fast (if any) response.  Caveat emptor, and what do you
want for free?  I would also appreciate positive feedback so I
know other people are using these mods.

	Make sure the RIO switch is set properly in the DRV
command line!  You MUST specify it in the command line and it
should be "0" for all cards except the LLG02 rev. "B", which
should be "1".  Weird things will happen to your rotors if it
isn't correct.  If the rotors don't work properly try switching
to the opposite RIO switch (i.e., if 1, try 0....if 0, try 1).  

BUGS

	Occasionally (very rare on fast machines, more often on
slower machines) the time will freeze on the Tuner Pop-Up when it
is invoked using the selected hot key.  Most function keys from
the active window still seem to work, but since (apparently) the
clock interrupt has been masked for some reason, KCT doesn't do
much tracking or tuning.  This problem exists in the original
2.34 version of the software and it still exists in my modified
version.  The only solution at this point (since this is a very
tough bug to track down) is to check the time and verify it is
changing each second whenever the Tuner Pop-Up is invoked.  If
the time is frozen, simply press <ESC> and invoke the Tuner
Pop-Up with the hot key sequence again and everything should be
fine.  Leaving the Pop-Up with the time frozen causes some real
strange things to happen after a few minutes, so exit the window
with the <ESC> key when the frozen time condition exists.



HINTS ON USING THE PK232 AND THE MICROSAT SOFTWARE

     I have found several idiosyncrasies involving the PK232 and
the Microsat software.  I had problems getting the PK232 into a
"clean" KISS mode after using other software (particularly after
using Pakratt).  The solution that seems to work every time is to
turn off the PK232 for a few seconds, turn the PK232 on, issue
the required number of "*"s for the autobaud routine to work,
issue the reset command and the same number of "*"s again
followed by the restart command (using a dumb terminal program
such as YAPP that doesn't cause the PK232 to enter host mode),
and then run PB or PG.  Also, turn the PSK modem off when
starting PG or PB or when switching between PG and PB. 
Apparently the stream of data from the modem during program
initialization corrupts something and makes connecting to the
Microsats very difficult and sporadic.  Also checkout David
Medley's article on the PK232 and Microsat software in the May
1991 AMSAT Journal.  He has more detailed information on making
the PK232 work correctly.  In my own installation, I seem to have
no problem starting either PB or PG after the above
initialization and I also have no problem switching directly
between PB and PG if the PSK modem is turned off.  I am using the
901221m version of PB, the 910207r version of PG and the 31OCT89
release of PK232 firmware. 


FINAL COMMENTS

I encourage experimentation with the parameters that the user has
some control over (such as the radio tuning step size). 
Different combinations of parameters may work better for other
combinations of modems, tncs, etc.  Let me know what works best
for you.


HAVE FUN and see you on the birds!

                                
                         JOE BARGER  N6KK
                        2009 Harkness St.
                    Manhattan Beach, CA 90266:

               internet: barger@aerospace.aero.org
                  satellite: AO-16, LU-19, FO-20
                        bbs: N6KK @ WB6YMH
          compuserve: 71560,2514 (checked occasionally)
                                 
                                 
                                 
