[aprssig] Satellite positions: Design Rationale

[Greg D]

Hi Lynn,

$.02 from a Sat operator...

I like Bob's suggestion. Well before a pass (longer than an hour is ok), 
knowing when the pass will be, and how high it will be, are the most 
useful pieces of information. Shortly before the pass, knowing how many 
minutes before it starts and how high it will be are most useful. I 
rarely stalk a satellite, so it's random chance whether it's more or 
less than an hour away, hence keeping the how high the pass will be is 
still useful. During a pass, knowing Az, El, and time to end of pass is 
best.

Being really clear which of the three cases you are transmitting is also 
important. Yesterday it was sheer luck that ISS happened to be up. It 
took me a few minutes to realize that I was in case #3, compared 
information with my PC in disbelief, and by that time the pass was 
almost over.

It occurs to me that the contents of the message you send to "ISS" is 
ignored. Could it be used as a command autoresponder, indicating what 
sort of information or format is desired? You could also use it to 
validate the request, in case there is a collision in the object 
namespace. You never know if AO51 is a satellite, or an ET visiting a 
certain place in New Mexico...

Greg KO6TH


Bob Bruninga wrote:
>> But, I believe I'm going to stick with
>> the objects, because I've got a better
>> way to deliver (most of, outside of
>> QSY tuning) Bob's ACTUAL desired information
>> instead of the station posit that he
>> was asking for.
>>      
> I think you are making the wrong decision.  It is inconsistent for you to generate a message from "ISS" and then be so stubborn about not originating the POSITION from "ISS" as well.  It violates the principle of least astonishment.
>
> Further there is NO BETTER way to deliver the info.  We have tens of thousands of radios that will compute AND DISPLAY the DIRECTION, DISTANCE to the symbol on the front panel of the radio in a universally consistent manner.  There is no reason to try a "better way" that ignores the receiver display system.  Do you even have an APRS Mobile radio?
>
> This feature you are writing is for the APRS RADIO user.  There is a well defined human inteface and therefor expectations.  Please do not ignore this display!
>
>    
>>> "%AOS:2:27m+8:53m"
>>> "AOS:2:27m+8:53m"
>>>        
> Both of those are gyberish, and meaningless without a priori knowledge of what it means.  A fundamental ANATHMA to APRS.
>
> The best format of the email should be along the lines of:
>
> AOS in XXm  MaxEL:YY
>
> AOS at HHMMz MaxEL:YY
>
> THe difference being whether it is less than one hour away or more.  And the format for the complementary POSITION of the satellite injected into the APRS-IS once a minute should be:
>
> SATNAME>APRERJ:=DDMM.mmN/DDDMM.mmW$CCC/999/FFF.FFFMHz de KJ4ERJ
>
> 1) It gives a delta reference if the pass is soon.
>
> 2) It captures the time if the  pass is later
>
> 3) It gives Max Elevation which is the single most important parameter for the mobile operator to visualize the value/quality of the pass.
>
> 4) It causes the POSITION to be passed via IGates back to the requester.  And this position SERVES everyone in range of that IGate, not just the requester.
>
> 5) It is a legal RF packet because the ham radio callsign of the source "de KJ4ERJ" is included in the standard format for tactical calls.
>
> It is a well designed combination of MESSAGE response and complementary POSITION providing exactly the intended user display on the front panels of all APRS mobile radios and APRS HT's.  And it takes advantage of all the known operational limitations of the APRS-IS and RF system.
>
> Bob, WB4APR.
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>