[aprssig] ISS Tracking & Pass Information

[Lynn W. Deffenbaugh (Mr)]

(Snipping out sections without comment from me)

On 10/14/2011 9:42 AM, Bob Bruninga wrote:
>
> (or, did I miss that the message is actually originated by the satelltie object name callsign?  If so, ignore the need for the name).

Yes, the response comes from the "station" to which the message was 
addressed, hence the need to not put the satellite name in the 
response.  I'm hoping that all APRS message platforms keep track of and 
display the other party in the message.

> How about this compromise.
>
> 1) If the pass is less than 59 minutes away then indicate:
>
>> ISS  in 17m MaxEL:10
>> AO51 in 48m MaxEL:45
> If the delta time is more than 1 hour, then indicate:
>> ISS  at 1014z MaxEL:10
>> AO51 at 0725z MaxEL:45

I know that many people are zulu-familiar, but I find myself thinking 
about the conversion every single time I have to do it.  Elapsed time, 
IMHO, is a universal solution.  If you send a query and don't get an 
answer, you ignore the answer when you see it later.  If you want to 
know what time the next pass is, just ask again when you want to know.  
Not rocket science (well, maybe it is), but designed for convenience.

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.  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.  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.  If a response arrives out of the 
blue, then you just ignore it unless you know you just sent the query.

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.

>> I'm not trying to support the serious satellite
>> users.  They've already got their own schedules
>> and pass prediction software running.
> But most of them do not bother mobile, beause it is just too much hassle to do all of that in advance or have a laptop always running in the car.  They would all love to be able to get htis info via APRS.

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.

> Again, Great idea!

Thanks.  There's more capability on my mind, but I wanted to get this 
out there to see how much (or little) it might get used and what kind of 
reception it might receive (no pun intended).

> Later when we get the radios o implement ITEM-IN-MSG, then your engine can send out satellite objects to subscribed users!

I'll be first in line to use that capability!  I've already got the QRU 
server running and sending Item-In-Message to those platforms that are 
known to be capable of handling it (namely APRSISCE/32).  Messages are 
the only thing that can be (semi-)reliably pushed out remote IGates to 
stations that are known to be asking for information.  If a QRU item 
tries to go to a non-capable station, the object range and bearing are 
sent as text to requester instead of a much more complete Object.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32