Re: [amsat-bb] AO-40 current ALON/ALAT

[hasan schiers <schiers@xxxxxxxxxx>]

=20?= <023123C26EBE2025*/c=FR/admd=ATLAS/prmd=SG/o=INFI/s=NAYLOR/g=JONATHAN/@MHS>
MIME-Version: 1.0
Message-Id: <01122406225505.01108@localhost.localdomain>
Content-Transfer-Encoding: 8bit

On Monday 24 December 2001 02:48 am, Jonathan NAYLOR wrote:
> Hi Joe
>
> I did that with mtrack and sure enough the squint values it gave me were
> much more reasonable.
>
> My next question is this: Why did I need to make this input data change
> for mtrack, does it indicate a bug in the squint angle calculation, or
> is it because AO-40 is somehow different from AO-13 ? I originally wrote
> the program in AO-13 days and the squint angles then seemed accurate.
>
> The fact that QuikTrack gets it wrong makes me feel slightly better.
>
> I would be interested to know as I would like to get mtrack accurate in
> this respect without asking users to have to modify the input data before
> entering it.
>
> Happy Christmas from a white Zurich.
>
> Jonathan
> ----
> Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
> To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org

Jonathan,

There may be two distinct problems. 

First of all, the latest version of InstaTrak has it right, the author wrote 
the correction. The correction is required because the antennas on AO-40 are 
on the opposite side of the spacecraft that was used for AO-13. This requires 
the addition of 180 deg to ALON and change in sign of ALAT.

Several satellite programs require this "manual conversion" so it's no big 
deal. What some of the authors have done, inlcuding InstaTrak, is publish a 
fix, so that we can tell the program to use -Z axis entry for a specific 
satellite, for those that are built like AO-40. For example, the latest 
version of InstaTrak 1.51 for dos from AMSAT, when you enter the attitude for 
AO-40 in the keps, you enter it like this:

341/-10 -Z <enter>

from that point on, the program remembers that AO-40 is a -Z bird, and you 
can put future values in without the addition of the -Z.


Second, if it becomes necessary to enter a true negative value for ALAT, Doug 
Cole has said the program doesn't "act right" if you try to enter a negative 
vlaue for ALAT. That is definitely a bug in mtrack.

Additionally, in your message to me you indicated you thought that mtrack 
might be ok....I don't think it is. 

Indeed, squint to the tenth of a degree should not be required...BUT, mtrack 
is off by way more than that. I'm showing a typical error of at least 3 
degrees...and that isn't right. It also makes us doubt the accuracy period 
and I find myself having to constantly check mtrack against my copy of 
InstaTrak. In fact, right now, with the bird at ma 58 and below the horizon 
in the usa 12:12 UTC, IT shows 15.2, and mtrack shows 12 deg...again, about 3 
deg off....not horrible, but something isn't right. I would expect no more 
than a 1 degree difference...

If you look at the az/el of the two programs:

mtrack: 70/-25 Range 53588 km
IT:     69.9/24.36 Range 53570 km

VERY GOOD AGREEMENT

With the position of the bird so close between them, there shouldn't be an 
error of 3 deg in squint, so something is wrong with the squint calculation 
in mtrack.

Now...if we could be absolutely sure that the error between mtrack and IT was 
never more than 3 deg, I guess we could live with it, assuming there are no 
other problems with mtrack and entering a negative value for ALAT, should it 
be necessary.

Hopefully, this will help resolve the current and potential future problems 
with squint and mtrack. Thanks so much for all your efforts with this fine 
little tracking program. Whenever my 3rd machine is in Linux (which is most 
of the time), I always have mtrack running. 

73


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