[aprssig] ISS Tracking & Pass Information

[Lynn W. Deffenbaugh (Mr)]

The satellite tracking pass response system will now respond to messages 
addressed to the alphanumeric version (sans special characters) of the 
satellite's common names from the TLEs.  This means you can use AO-51 or 
AO51 which is easier to type on many radios and should work on Yaesu 
radios for satellites with 6 or fewer alphanumeric characters in their 
name.  Other platforms should be able to query a satellite with up to 9 
alphanumeric characters as that is the limit of the message field in the 
APRS spec.

I almost added a "free" position beacon when responding to a query, but 
then realized that these satellites are APRS objects, and not stations.  
I suspect that the APRS-IS servers will not forward an object packet 
behind a message packet and I don't think it would be wise to transmit a 
position update as if the satellite was actually a station.  So, unless 
you're querying the ISS, the actual current position of the satellite 
won't be transmitted.

Now, when Item-In-Message gets more broadly implemented (beyond 
APRSISCE/32, that is), I could followup the pass information query with 
one of those so you can actually see the satellite along with the 
MultiLine-described coverage area as the ISS object does that I'm 
currently injecting into APRS-IS every two minutes.

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

On 10/14/2011 1:54 PM, Lynn W. Deffenbaugh (Mr) wrote:
> Wait a minute here.  Let me bring this back into context.
>
> a) I will be allowing, but not requiring the dash in the satellite 
> name.  As was pointed out, Yaesu radios can only send messages to 
> AX.25-compliant station IDs, regardless of the fact that an 
> APRS-IS-resident station is not constrained by this restriction and 
> the APRS spec never puts such station's callsigns in the AX.25 header, 
> but only in the payload for messaging.
>
> b) I've got a program that's listening to EVERY message passing on the 
> APRS-IS stream and monitoring that stream for actual satellite 
> callsigns.  If I start doing "lazy matches" on that stream, I'll end 
> up responding to lots of things that weren't directed to me.  "SAG" 
> comes to mind as I'm sure I could think that is some sort of satellite 
> name.
>
> No, if the messages were directed to "SATSRV" or something else that 
> is specific (and hard to remember), I could be loose and flexible in 
> the interpretation of the content.  But I want to keep this simple by 
> having the messages sent to the satellite name as if it were the 
> station being addressed.  It works, but I really can't be loose in the 
> interpretation.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> On 10/14/2011 9:01 AM, Patrick Strasser wrote:
>> Am 2011-10-14 12:14, schrieb Lynn W. Deffenbaugh (Mr):
>>
>>> I will look at not requiring the dash in the satellite name.  That was
>>> in my plans, but I haven't gotten it implemented yet.
>> I' suggest to make it rather flexible: a dash should be ignored, so if
>> someone knows the exact name, it still matches. Would make it more
>> complicated to _require_ the absence of a dash.
>>
>> For shortening names something like a lazy match would be nice: If the
>> sent prefix is enough to identify a single satellite, resolve the
>> request, otherwise answer with a message saying that the name ambiguous,
>> with possibly a list of matching satellite names. I would expect it to
>> work like tab completion in various Unix shells.
>>
>> 73 de Patrick
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>