[aprssig] ISS Tracking & Pass Information UPDATE

[Bob Bruninga]

Well, we disagree then I guess...

> 1) If the pass is less than 59 minutes away then indicate:
>
>> ISS message: AOS in 17m MaxEL:10
>>
>> 2) If the AOS is more than 1 hour, then indicate:
>> ISS message: AOS at 1014z MaxEL:10

> Elapsed time, IMHO, is a universal solution.

True for the next hour or so.  But not user friendly beyond an hour or so...

> If you want to know what time the next pass is, 
> just ask again when you want to know.

Poor network design with respect to loading and QRM.  If I ask once, I get
the answer once, and the answer is automatically stored in my message list
and so I can use it now (if it is a few minutes away) or refer to it later
if it is much later.  No need to QRM the channel by sending queries all day
long when one query gives me everything I need to know.

> but designed for convenience.

I guess we disagree.  One answer that lasts for hours is more convenient to
me.

> I really don't foresee a use case where someone 
> sends a query now, sees that the pass is coming up in 
> 4:23h and stores that message in anticipation of the pass.  

Huh?  I'd say that EVERY query falls into that category.  You seem to
presume that the sender already expects a pass and so he only asks a few
minutes in advance of  this prior knowledge?  No,  I disagree.  The person
has no clue as to whether the pass is in a few minutes or if it is not for
another 4 or 9 hours.  Your system can give him the answer either way.  That
answer is good from now until it happens whether it is minutes or hours. And
the Radio automatically stores that response, it is not something he has to
make any effort to store.  Its there, its done, its available for hours.
But if you only respond with a delta, it is useless, because the reference
time is not remembered.

> More likely use is to query when you've got
> some time on your hands (or will have shortly) 
> to see if there's a pass in progress or shortly.  

But the response no matter whether it is soon or later is still an accurate
response.  Why not let it be valid both soon or later.  If soon, then reply
with the number of minutes to LOS.  If it is more than an hour, then respond
with the actual time.  Done.

> If there is, you glance at your watch and
> figure out when to start trying to work it.  
> If there isn't, you send a new query when 
> you've got time again.

I guess we have different understandings of what "convenient means"...  Both
to estimating time in our heads and in channel load and QRM on repetitive
queries when one well designed response would do.

> If a response arrives out of the blue, 
> then you just ignore it unless you know 
> you just sent the query.

I do not understand this scenario.  Either one gets a response to his query
within a minute or two, or he doesn't.  I assume your response engine will
use the Decay Algorithm.  That is, send immediately, then 8 seconds later,
then 16, then 32, then 64, and then 128.  Then quit.

> I hope it's ok with you, but I'm going to stick 
> with delta times for everything.  Only one thing to know.  
> And if you're trying to plan for passes more than an 
> hour out, you can just query again when the time is
> getting closer.

Its your program but delta's are useless beyond the moment received, since
one does not have the reference time and it is unrealistic to expect the
user to remember when he made the query and then do mental math to estimate
and then Remember a future time.  It is also unrealistic to expect the user
to keep making delta estimates when the deltas are longer than an hour.  

By definition, any random QUERY will more than likely always return a time
that is HOURS from now.  Why do we need to design a system that then
encourages people to be living only in the moment and to keep querying all
day long when the first response could provide the full answer.  Either a
delta if within an hour, or the exact time if more than an hour.

It is not good for the network to design a system around constant re-queries
when one well designed response could work both now and later.
 
> And that's why I made the query capability.  
> For those that just want to "see if there's 
> a satellite nearby" when they're mobile with 
> not much else to do.

But having made the query, and KNOWING that MOST of the time there is NOT a
satellite nearby, then why design a system that expects multiple queries
when one answer can do whether it is now or later....

Again, I'm glad to hear the message is ORIGINATED by the Satellite Callsgin,
This is GREAT!  It means that the nearby IGate will not only relay the
response back to the queryer, but if the IGate is doing its job, it will
also send out a local courtesy copy of the ISS actual APRS-IS POSIT.  SO my
modified proposal is something like this:

* ISS message: AOS in 17m MaxEL:10   (if within an hour)
* ISS message: AOS at 1014z MaxEL:10 (if more than an hour away)

It just does not seem to get much simpler than that.  And the "courtesy
posit" is icing on the cake!