[aprssig] Satellite positions: (SUMMARY)
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Tue Oct 18 18:29:37 CDT 2011
On 10/18/2011 1:32 PM, Bob Bruninga wrote:
> By all means we want to see the MaxEL of the pass in the POSITION packet,
> because it tells the satellite operateor the overall Geometry and QUALITY,
> of the pass.
I maintain that the position packet is globally visible and cannot
contain ANY observer-position-dependent data like MaxEl of a pass. That
is specific to the OBSERVER, not only the Satellite.
adios.. don't dead-reckoning?
> The entire geometry of a LEO satellite pass (to a mobile operator with a
> omni antenna) only really needs TWO tidbits of information to completely
> describe its path across the sky. That is simply the AZIMUTH and MaxEL and
> which direction it is moving, north or south (or east or west).
TWO? I count three in that statement: 1) Azimuth, 2) MaxEl, 3)
Direction (is NEWS sufficient?) The first two are now in the query
response, and the third can certainly be added there (as a single
character? Or 2 for 8 compass points). I still see no justification
for the QRM of a position packet that is OBSOLETE by MILES a few seconds
after it is generated.
> That is why all we need to
> see is a normal APRS satellite POSIT and the radio front panel will then
> display all of that to the operator, Direction to the satellite, DIRECTION
> it is moving, and MaxEL.
You're assuming a specific display device again. I'm going for broadest
reach with minimum training. Any APRS message capable platform, IMHO,
should be able to see all of the available information for his/her
query. This includes HamHUDs, TT4s with textual displays, the new
YagTracker (or whatever it is), as well as all of the APRS messaging
radios, and APRS-IS-based messaging clients, be they PC or mobile
platform based. I do NOT want to rely on a the position packet
interpretation and (possible) display/capture in a "station list" to
force the query operator to check both the response message AND the
(possibly not delivered or decoded) position packet.
> But MaxEL IS important since it defines
> the arc across the sky. And it does NOT change. It is a parameter of the
> geometery, not instantaneous pointing.
MaxEl is now in the response. You've sold me on that bit at least!
>> de KJ4ERJ is just visual fluff that will be in the
>> path of the (original, possibly not 3rd party) packet
>> for those that are trying to track down the origin.
> No. It is required. The SATNAME POSITION is being generated as if it were
> in the AX.25 SOURCE field, and so it is an FCC requirement that such a
> TACTICAL CALL be identified somewhere else in the packet with "de CALLSIGN".
The FCC requirement does not apply to the APRS-IS, only the IGate that
transmits the packet onto RF as I understand it. And that station's
call is included in the third party packet header. Otherwise, WHO-IS,
EMAIL-2, and CQSRVR APRS-IS-based servers would also be illegal in
responding to APRS message-based queries.
And I'm still not sold on the QRM of a satellite position packet. I can
be swayed, but so far the only thing the radio interpreted position
packet MIGHT be providing beyond the current query response message is
the direction of motion.
>> So, can you tell me again just what information you
>> expect to find helpful in this courtesy position packet?
> Format is
> AO51>APSATS:=DDMM.mmN/DDDMM.mmWSCCC/999/FFF.FFFMHzUUU.UUU 27 MaxEL de KJ4ERJ
I didn't ask for the packet format (yet). I asked what INFORMATION you
expect to be useful that isn't already in the message response.
MaxEl CANNOT be in the Position packet because it may be heard by people
all over the place from directly under the satellite to right out at the
fringe. Anything observer/querier-specific MUST be in the message
> Because one of those packets, the POSITION packet above, can serve everyone
> within thousands of miles across the whole country instantly because each
> user's radio computes the AZIMUTH and DIATANCE on its own. And it is only
> one packet injected into the APRS-IS every minute. No worse than any other
Certainly can't inject it once every minute if it contains MaxEl, can we?
> The MESSAGE packet is the one that does two things:
> 1) It responds to the users query with the TIME of the next pass. (and)
> 2) It ENABLES the local IGate to recognize the satellite POSITION (on the
> IS) as being one that should be gated from the IS to RF in this area. (or
> anywhere else where someone has queried).
Not "the local", but ALL IGates that have "recently" heard the querying
station "locally". The message and the proposed position packet might
go out any number of IGates and in all possible digipeater directions
from there. It's by no means "localized" like your old
locally-generated pass information may or may not have been (based on
whatever path and digi coverage the generating station may have had
Lynn (D) - KJ4ERJ - Still striving to understand, really not just being
More information about the aprssig