[aprssig] Satellite positions: (SUMMARY)

[Lynn W. Deffenbaugh (Mr)]

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 
packet alone.

> 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
> mobile.

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 
available).

Lynn (D) - KJ4ERJ - Still striving to understand, really not just being 
recalcitrant