[aprssig] Satellite positions: (SUMMARY)

[Bob Bruninga]

>> So, the format for... courtesy posit reports should be:
>>
>> SATNAME>APRSAT:=DDMM.mmN/DDDMM.mmWSCCC/999/FFF.FFFMHz EL %LOW  de KJ4ERJ
>>
>> This will cause the radio to display the DIRECTION and DISTANCE 
>> to the satellite, and its frequency which can be instantly tuned 
>> with one button.  And the Kenwoods with voice synthesizer can 
>> speak the elevation angle of HIGH , LOW or MEDIUM if spelled out (I
think).

Actually, I wouldn't worry about the speech.  I had it in the original
APRSdata, just to show off, but probably not worth it because so few people
have the speech module.

> Ok, I just had an aha moment and still need a better explanation....
>
> Isn't the Direction to the current satellite location 
> the Azimuth that's already in the query response? 

Yes, and it is on the front panel of the radio exactly where you expect to
see the azimuth just like all other stations in the list.  AND it is
displayed in COMPASS-ROSE format for instant VISUALIZATION.  AND it is
showing its direction of movement.  So it is to the NW and moving East then
you know it is an Northeeastern pass and can know where to best position
yourself to see that part of the sky.  This is an ORDER OF MAGNITUDE better
visualization of the geometry of the pass compared to to some characters in
a message somewhere that the eye-brain-combo has to find and read and
interpret while driving and being otherwise distracted.

> And it's really only needed if you're using a 
> directional antenna like a Yagi,

Whoa, not at all!  Operating satellites is a HORIZON thing.  The satellites
spend 70% of ALL of their in-view time BELOW 22 degrees!  Except for the
big-sky states, what I see out my window while driving back east here, is
usually WALLS of trees up to 45 degrees or higher.  SO knowing the direction
to the satellite makes all the difference in the world in deciding where to
PARK the car to operate the pass even with an omni antenna..  Just being on
the wrong side of a building and you will miss the entire pass.


> in which case you need the Elevation from the 
> query message response as well. 

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.   On the other hand, we do not need an live ELEVATION data,
because there is NO NEED FOR ANY ELEVATION ANGLE on antennas, even BEAMS for
all of the current Amateur Satellite in LEO oprbit.  They are either 70% of
the time below 22 degrees , or as they get higher in elevation, then they
are 6 to 10dB stronger and one does not even need to point the beam when
they are that close.

> And the course/speed component, I still question 
> the usefulness of as the radios.. don't dead-reckoning?

It is not dead reckoning at all.

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

But rather than trying to visualize the starting and ending points from the
"center" it is more pleasing to the mind to visualize the STARTING AZIMUTH,
then the MaxEl and the direction of movement.  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.

Example  The satlilte is NW of me an dmoving south.  Then I know it will be
a WESTERN pass and will make sure I can see the best horizon in that
direction.  If it is to the NW and moving east, then I know it is a NORTHERN
pass.  Very important with mountains and trees to be able to know where to
maximize the SKY that your omni antenna can see.  You cannot afford even one
tree in the way.

> Elevation low, medium, high is kind of redundant and non-
> specific with the actual elevation that was received in the message.

Yes, those were just showing off the Voice Syntehsize that could actually
VOICE those words, but I agree, we were just showing off, and that is not of
much value.  But as I noted before, showing live elevation is also of little
to no value to the mobile operator.  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.

Besides, the AZIMUTH and DISTANCE to the satellite and DIRECTION of movement
is calculated BY THE RADIO, and so it serves ALL viewers within THOUSANDS Of
miles at the same time from the ONE packet.  The RADIO calculates and
displays the correct SOLUTION to each separate viewr.  An ISS pass over
Kansas will be seen to the NE and moving south to a California Observer and
will be seen to the North west and moving south to a Virgnina viewer.

> 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".
This is just common practice for TACTICAL calls in APRS and packet in
general.  And remember, we have to use a TACTICAL CALL for the satellite in
order for it to use a STATION positon format and we need that so that it
passes thorugh the IGates back to the requester!


> 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 am not certain if the "/" will work between the SPEED of 999 and the
FFF.FFFMHz field.  It was always intended, but I think Kenwood screwed it
up, by not assuming it was there, and so the FFF.FFFMHz field might not be
found if the "/" separator is included.  Their fault, but we have to live
with it.  In that case, the format would be:

AO51>APSATS:=DDMM.mmN/DDDMM.mmWSCCC/999FFF.FFFMHzUUU.UUU 27 MaxEL de KJ4ERJ

> I'm still trying to understand the justification for 
> two independant packets on the precious RF channel 
> when it seems like the required information is all 
> in (or can be added to) the original query response.

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.

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

> PS.  Yes, I skipped the QSY frequncy because I'm not 
> familiar with how many of the birds are single frequency 
> VHF/UHF frequencies.

ALL OF THEM that are FM.  They are all singl feuqneyc and it is the FM
mobvile operator that your service supports.  Hence FFF.FFFMHz is perfect.
Notice I added the UPLINK FREUENCY UUU.UUU as well to best serve the user.
ALSO, the format above is PERFECT fo thte D7 and D700.

On the D7, only 20 characters are displayed, so he will see

>FFF.FFFMHz
>UUU.UUU 27

And on the D700 he will see

>FFF.FFFMHz
>UUU.UUU 27
>MaxEL de

Though the KJ4ERJ is lost, but it is not needed by the HT/Mobile operator,
though required for consistency on the APRS system to identify source.

Bob, WB4APR



_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig