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

Re: GTO-Track




Thank you for your comments, Paul. I enjoyed reading your write-up on "the
One True Rule". I notice that your stated goals were my original goals,
until I really started to listen to how people used the satellites. 

I'm not trying to start a trend or do anything "the right way" because if I
did, it would make it harder for other stations to maintain a QSO with me. I
want to take the methods used by people today, and simplify it for myself,
and anybody else who would like to use my app. 

You were a little hasty to shoot down the basis of the idea. If we think
about it for a moment, how many people do you know with dual-band radios in
their vehicle? Then think about how many people can full duplex between
those bands. There are a few but most can't. My 706 can't, and that is what
is driving me to write this application. 

People with a shack that includes a computer and all the doo-dads won't
benefit from this application. They probably can't understand why I would go
to so much trouble to write such an application. They already have what they
need all in one place. It's the mobile guys like me, that don't have a shack
back at home with a computer interfaced radio connected to prediction
software. 

I have a java enabled phone, an interface cable, a 706, and it's all in my
car with me when I'm operating. That's everything I need to operate a
transponder sat, just like the guys at home with a PC, except my method will
be a lot more lightweight. The application could use OTR, or any other
method. The math is all quite simple with the assistance of Predict's
GET_DOPPLER command. 

I just don't see any other practical way to drive down the highway and work
a Transponder satellite. You must see by now that this is the very essence
of what GTO-Track will do. Only one radio is needed, with a CI-V interface
and a java-enabled phone, you're in business. 

As a side note, phase-2 of the project will let the user plug in key
attributes (probably about 5 numbers) of an upcoming orbit, so they can work
the sat without network connectivity. Even these calculations can be
simplified enough to allow for a small phone to continuously tune the TX and
RX freqs on the radio, or tune the TX after the user adjusts the RX. 


-----Original Message-----
From: Paul Williamson [mailto:kb5mu@amsat.org] 
Sent: Thursday, October 19, 2006 6:11 PM
To: Brad, K1GTo
Subject: Re: [amsat-bb] GTO-Track

>In the first Phase, the application will use an internet connection to
>connect to a running Predict server (that's the Linux satellite tracker
>program). The application that runs on the phone will interface to predict
>to obtain Doppler shift information about the satellite currently selected,
>based on the QTH coordinates programmed into Predict.

That's very cute, but not really all that practical in my opinion. It 
would probably require less code space and a lot less battery power 
to just do the calculations locally, and that would work even without 
network coverage. The days when orbital prediction calculations could 
be considered CPU-intensive are long gone. The phone can still use 
its network connectivity to get current elements and perhaps accurate 
date/time if it doesn't already have that.

>That was sort of question 1 there, is that how it ought to work?

Pretty much, yes.

>Then the next part of the question would be: Should the application leave
>the RX frequency constant, not adjusting it whatsoever for any Doppler,
etc,
>and only adjust the input frequency?

The long version of my thoughts on this can be found at 
http://www.amsat.org/amsat/features/one_true_rule.html

73  -Paul
kb5mu@amsat.org


_______________________________________________
Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author.
Not an AMSAT-NA member? Join now to support the amateur satellite program!
Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb



AMSAT Top AMSAT Home