[aprssig] ISS Tracking & Pass Information

[Bob Bruninga]

> Pardon the tone of the following response.

I'll ignore the tongue lashing...;-)  but feedback including knee jerk feedback is often good to a developer because it gives feedback on first impressions.  That is usually quite insightful because everyone new to something will always be starting at state-zero and may also be tripped up by the same first impressions.

> 1:25h - Means 1 hour 25 minutes (hourly presentation)
> 45:24m - Means 45 minutes 24 seconds (minutes presentation)
> 30s - Means 30 seconds (obvious)
>
> As for these messages needing to include the 
> satellite name because they'll be "sitting 
> in the inbox", c'mon.

OK, I'll try to show why this is important... I send a message to ISS.  I get a response (more than half the time) of something like this... "its coming up in 9 hours and 45 minutes."  OK, so I send a message to AO51 and get the response "its coming up in 3 hours and 20 minutes"..  I keep trying a few more satellites.

BINGO, Now I have a bunch of messages, with times in them and have -no idea- which one refers to which satellite.  I have the infomation (delta times) and they are all sitting their for future use in my INBOX, but the information is practicallly useless as time goes by, because:

1) I have no reference to which satellite they refer to.
2) I have no clue to the reference time (in most radios)
3) Therefore the information is useless unless I am a mental genius and keep track of all this trivia in my head.

(or, did I miss that the message is actually originated by the satelltie object name callsign?  If so, ignore the need for the name).

Whereas, if the response is of the form:

> ISS  at 1745z MaxEL:10
> AO51 at 1425z MaxEL:45

Then later that day, I can check these old messages and see exactlly when to expect the pass and  how good it will be.

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

> I went with a pass duration rather than max 
> elevation so novices can better plan their 
> time investment.  They both basically 
> communicate pass "quality" and "ease of 
> working", but everyone understands time, while
> the experts have a handle on elevation.

Sorry, but time is of little value since it can be a longer low pass that one has no prayer of working from a mobile because it is so low.  So elevation tells it all.  A low max elevation is not worth bothering with no matter how long it is.  A high elevation pass will have a nearly 10 dB advantage to the mobile operator and is very important information.  And also, by definition it is longer.

And satellite operators know the approsimate lenght of a pass.  For a mobile, the shortest is the ISS with about 5 minutes useable.  For PCSAT1, about 10 minutes max.  All other satellties are somewhere in between or are not usually workable from an FM mobile rig with omni antenna.  So the few minutes difference is of little value.

I dont think people are going to arrange their daily schedules around whether a satellite is going to be useable fo 5 minutes or 8 minutes.  But they certainly will change plans for a 60 degree pass compared to a 10 degree pass.

Hope that fills in the background behind my comments.

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

Bob, Wb4APR

>On 10/14/2011 12:05 AM, Bob Bruninga wrote:
>> Great project!
>>
>> But the format for zulu time is HHMMz.  there is no colon.  And it saves bandwidth too.
>>
>>> send an APRS message to ISS... The response will be:
>>> Az: aaa El: lll LOS:xx:yyz - If you are in a pass
>>> AOS: xx:yyz+aa:bbc - If you are not in a pass
>>> AOS: NONE - If... no passes... in... two days.
>> I wonder if we could tweak the format to not be so choppy or to better match some radios small 12x12x12x10 display windows... (D7).   I'd suggest:
>>
>> AZ/EL aaa/LL LOS: X min
>>
>> AOS ISS in HH:MM MaxEL yy deg
>>
>> Duration is always going to be in minutes and I'd rather see a relative time, rather than try to think in zulu and not be sure.  This tells you how long till the next pass and what its max elevation will be.  Anyone who operates the satellites can infer how long it will last from the maximum elevation angle and whethter it is a pass worth listening to or not...
>>
>>> You can send an APRS message to "AO-51"
>>> to find out when that satellite will pass within
>>> range.
>> You might consider dropping the requirment for the HYPHEN.  In all my earlier APRS/space applications I truncated the names to 4 bytes and eliminated hyphens... mostly because they are wasted characters and take a lot of button pushing to get the "-" character...
>>
>>> Give the service a try...
>> It is a great concept!!!
>>
>> One disadvantage of the time-to-go approach is that the message sits in your message buffer and for use later,  you haev to mremmebr when it came in.  Maybe it is better your way.  In that case, I'd suggest:
>>
>> AOS ISS_ at HHMMz MaxEL yy deg
>>
>> Notice that you need the satellite name (typically truncated to 4 bytes) so that these messages make sense later.
>>
>> Great work!
>> Bob, WB4APR
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig