[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Auto Tracking: How's it done?

At 02:35 PM 3/16/99 -0500, you wrote:
>I need a brief course on automated antenna tracking methods currently in
>use at OSCAR groundstations.  I'm developing some new satellite tracking
>software, and although I do not have any facilities for auto tracking
>my antennas at the present time, I'd like to implement the code needed
>to interface a PC to a control interface to track satellites so that
>others may use my program and make use of the feature if they are so
>My understanding is that azimuth and elevation data is sent by the PC's
>parallel port to a controller that steers the AZ/El rotator.

The parallel port is used in some designs.  Other designs use a
serial port, and others (including the popular Kansas City Tracker)
use a dedicated plug-in ISA bus card.  Various other combinations
of dedicated hardware and standard ports are used by different
interface devices.  No two are alike.

>How are
>azimuth and elevation headings fed to the controller electronics?

You didn't specify which OS platform.  Under DOS, the most common
arrangement has the application software make a software interrupt
call to a TSR driver, supplying the azimuth and elevation.  The TSR
driver then takes care of delivering it to the hardware.  This interface
was defined by the Kansas City Tracker, in which case the TSR
read from and wrote to special registers to accomplish control.
However, the interface is sufficiently general that any kind of rotor
control hardware could have a KCT-compatible TSR driver, and
several of them do.  If your platform is DOS, you should write to
this defined interface.

Under Windows the software interface is a function call into a DLL,
or else a DDE link to another application.  Both interfaces are
somewhat documented and standard across applications.

Under Linux ... oops, nobody has written (and published) a rotor
driver for Linux yet as far as I know.  (I know of a KCT driver for
Linux that is in work now.)

Under any OS, one of the standalone controllers can be commanded
by ASCII-readable commands via the serial port.  One such command
set is called EasyComm.  I recommend following this command set,
just for the sake of standardization, if you use any serializable data

At the physical level, once you're past all the software mumbo-jumbo,
there is no concept of feeding the headings to the electronics.  Instead,
the position-sense potentiometers on the rotors deliver a voltage for
azimuth and one for elevation to the controller.  The controller then
enables the azimuth motor for left or right or the elevation motor for
up or down, and watches the feedback voltage until it gets close
enough to the desired value.  This is usually done in software.  In a
standalone controller, a dedicated microcontroller runs the software.
Under DOS, the driver TSR does it.  Under Windows, the DLL.

There's one hardware solution where the bearings (converted to
hardware units) are actually latched: the WB5IPM controller,
described in May 1987 QEX.  In that design, the latched bearings
are directly compared to the feedback voltages by analog
comparators, and the result used to enable the motors with no
software involvement.  That controller hooks up directly to a
parallel port, and is controlled by strictly standard writes to the
parallel port data.

>How many bits are used for data?

Typically 7 or 8, some interfaces use 12.  However, I'm not aware
of any commercially available rotors that are positionable with a
mechanical accuracy that justifies more than 8 bits, at least not
in the amateur price range.

> Are azimuth and elevation data sent simultaneously? 

Depends on the hardware and software.

>Are any bits reserved to identify what is being sent
>to the controller if they are sent separately?

Again, it depends.  For example, the WB5IPM controller uses
one of the eight data bits on the parallel port to control whether
it is azimuth or elevation.  The EasyComm interface has an
ASCII command line that looks like this:
AZaaa.a ELeee.e UPuuuuuuuuu UUU DNddddddddd DDD
where "AZ", "EL", "UP", and "DN" are literal commands, and
the rest are data fields: azimuth, elevation, uplink frequency,
uplink mode, downlink frequency, downlink mode.  As you can
see, this standard encompasses radio tuning as well as rotor
control.  The superset EasyComm2 standard has lots more
two-letter commands, so you can send things separately and
get more control.

Examples of much of this are available at
http://www.amsat.org/amsat/ftpsoft.html, and the EasyComm
spec can be found at

73  -Paul

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org