Re: [sarex] ISS Unproto Destination Address

["Stan Vandiver" <stan@xxxxxxxxxxxx>]

On 25 Sep 2001 at 13:38, Bob Bruninga wrote:

> The TOCALL in APRS is just like any other destination address in any other
> comunication system.  If you want everyone to see your transmissions, then
> use an ALL-CALL address of which there are many (CQ, QST, ALL, etc...)...
> If you only want it seen by one person or a subset, then use another
> callsign, or group callsign..

I don't believe it is the sender's responsibility to make sure he is seen on the 
network, as you describe.  Not an "open" network anyway.  APRS is not an "open 
network" in my opinion... but the ISS is open to everyone.  I see everyone's 
transmissions, regardless of what they set as TOCALL.  APRS should have that 
same capability.  You need an "ANY" subset, or in other words, an OFF button, to 
turn off the filter.  You will let APRS configure any subset except this one.

APRS works exactly as planned... filtering me out for using my name, as I have 
been choosing to do, as the TOCALL.  Yet you are explaining to me how and why I 
should circumvent this "feature" of APRS?  I think if you want to hear "ANY" it 
should be selected by the receiving station, not the transmitting station... thats the 
way that my software works.  The pre-defined TOCALL's are nice, but they are not 
a network standard either.  

> The TOCALL filter that you suggest be abandoned is fundamental to the
> flexibility of APRS operations using the tremendous single frequency APRS
> infrastructure worldwide.

OK, for most folks the TOCALL address is not a big deal.  But it is very important 
to APRS.  You have made excellent use of the TOCALLs... for the APRS network, 
not an open network.  

<snip>

> Yes, it was by design.  And I hope you can now see that there is value in
> using the TOCALL of a packet as an address and why this is not really a
> "problem"...

If it were not a "problem" (for the Kenwood users)... then you would not be asking 
the world to change the way they configure their TNC's.  Asking the world to 
change so that a FEW users of your system can be accommodated.  Telling us 
how to "defeat" the very purpose of your APRS TOCALL programming.  And asking 
the whole world to transmit more characters to satisfy these FEW users.

And I think APRS already transmits more than its share of characters.  A quick 
look at the raw data on ariss.net immediately shows how "big" the packets are 
being transmitted by APRS stations through the ISS digipeater.  Sure, APRS 
makes effective use of those characters... but I'm not running APRS, so its all 
gibberish to me.  Yet you want us to accommodate the few people running 
Kenwood.  Why should we not ask all the APRS users to transmit "plain text" so 
that we might enjoy the content of their transmissions too?  There are a whole lot 
more of "us" (plain text users) that would benefit from seeing open communications 
on the ISS than the few people you are speaking for that will get to see our once-in-
awhile transmissions.

I'm sorry Bob... I still disagree.  I think you should fix this at the software level, not 
ask the world to fix it at the firmware level.  You need an OFF button... so your 
APRS users can bring their stations onto a open network.  If you can't fix those 
that have been sold already, then fine... but you can fix what happens in the future. 

I'm sure I will continue to see the gibberish from APRS... that no one will be too 
concerned that I am "left out" of their comms on the (ISS) network.  So I may not 
be too concerned if I "leave out" a few Kenwood users either.  Or maybe they will 
make a subset, "STAN".  But in the end, it really isn't *THAT* important, is it?  I 
don't care that I'm not included in the APRS'ers activities.  There's plenty of 
APRS'ers who still say hi to me, and I still say hi to them.  There is plenty of 
activity for the Kenwood users too, without asking the world (those without APRS) 
to accommodate them.  I think you're taking this way too seriously!  ;-)

Lastly, all of this has been concerning the TOCALL.  But this is also relevant to the 
VIA addresses in the unproto path.  Your recommendation to use grid square fixed 
in the #2 slot is also not a good idea, in my opinion.  Slot #1 must be NOCALL (or 
RS0ISS soon, I hope) so you can't really play with that.... because the path will 
"fail" when it runs into a callsign that don't digipeat it.  Maybe APRS works 
differently than what I have found here with my system.... but if your users set the 
path like U CQ V NOCALL,GG##GG,RELAY,WIDE --- then this will fail when they 
get back on the APRS network and not be digipeated.

Oops, APRS'ers won't set up that way, will they?  They transmit that big long LAT 
and LON position in the data part of the packet.  So this is your idea, again, to tell 
the rest of the world how to configure their TNC's.... right?

Don't change the spec Bob.  Save your energy.  Everything works fine just like it is. 
Don't rewrite the parsing function (unless its to create an ANY subset).  But please 
stop asking the world to be "APRS-friendly"... when it is APRS who is not playing 
well with others.  When I get on the APRS frequency, I will try to accommodate 
them... but if they come onto an open network, then it is they who should try to be 
accommodating.  The ISS is *NOT* an APRS network.... it is a SHARED network, 
and an open network.  We co-exist just fine as it is, in my opinion.

73 de Stan/W4SV

----
Via the sarex mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe sarex" to Majordomo@amsat.org