[aprssig] Satellite positions: Objects or Stations?

[Lynn W. Deffenbaugh (Mr)]

On 10/15/2011 4:20 PM, Bob Bruninga wrote:
> But the real ISS has the callsign "RS0ISS" and it does not transmit 
> its position... However, the "ISS" symbol can be generated in any way 
> we want. In the past we generated it by my APRSdata engine, and also 
> by DIGI_NED but these had to be implemented in every local region. But 
> now Lynn's application sounds like the ideal source, since it then 
> offers the query capability and is a centralized resource.

And from what I've seen, the other satellites that I've seen in APRS 
were objects, I don't know what software was generating them, but they 
were objects being transmitted with AOS time as part of their name to 
provide some level of uniqueness when/if they ended up gated back to 
APRS-IS.  So, if objects were good enough then, then they're good enough 
now, IMHO.
> There is no need to parse it.  The human that wants to see the source reads with his own eyes "de KJ4ERJ".  And there is nothing non-standard about that format.  It is the international standard for indicating the source callsign.  Has been for over a century.

There IS a need to parse it.  Paths are parsed all the time but lots of 
software that you may not ever see or notice the results of.  I don't 
need/want the source of the information to be in-your-face all the time, 
just to have it available for those that might have a curiosity.

The "de" prefix may be a ham standard, but it sure hasn't been an APRS 
practice let alone standard.  The path has been the method of 
determining who handled a packet, and the path is composed of 
callsign-SSIDs which is what I propose to continue putting there.  
There's no need nor benefit to introducing spaces into the header of a 
humanly-readable APRS-IS packet when KJ4ERJ-15* will communicate the 
necessary information just as well.  A variation on "use the minimum 
power necessary for the communications".  We don't need a new way of 
indicating who handled a packet.

> Think outside of the shack-and-internet-and-maps Box.  These objects are not intended at all for the shack-potato or the internet junkie playing with maps.  These objects contain a position so that when they are received on an APRS radio FRONT PANEL, that the radio can then calculate and display the Direction, Distance and Elevation angle so that the in-the-field APRS operator can visualize where the satellite is relative to his location.

And if that's the only reason for an additional packet, I've got a 
better way already existing to communicate that information.  No mobile 
operator is going to want to navigate to the ISS, just know the bearing 
and distance, so I can provide that via a different method that may or 
may not require an entirely separate packet occupying valuable RF 
channel time.  No details yet, but THAT information has multiple ways of 
being delivered, a station/posit in this case may not be required.
> I dont want to wait two decades for Kenwood, and Yaesu and Byonics, and Argent Data systems and Yagtrracker to implement it.  No, it is better to generate it in the indicated format, centrally, and accurately for use by any of 40,000 APRS users in the field with their existing radio *now* today.

Agreed, I'm patiently waiting for Item-In-Message support, but I'm 
certainly NOT going to expect the radio to take TLEs and do their own 
orbital math.  I'm attempting to provide a service and am gathering 
information on making that service better.  Slowly.  Tell me what you 
would like to see and leave the delivery of that what up to further 
discussion.  If you throw out "we need courtesy posits after the 
message", it's not obvious why.  Ask for the pass query to provide an 
indication of the current position of the satellite relative to the 
mobile operator, and it might be done differently/more efficiently.  
Remember, the query server KNOWS where the mobile operator IS, or it 
wouldn't have been able to provide the pass prediction to start with.

I'm not sure where your 40,000 APRS users in the field came from, but 
there've only been 18,461 unique callsign-SSIDs active in the past two 
hours.  4,831 of those were objects (yes, there's a benefit to being 
able to tell the difference, a repeater or net notification is NOT an 
APRS user in the field).   Only 8,531 of those stations appear to be on 
RF only (never showed a TCPIP* in their path), 1,629 were seen both with 
RF-looking and -IS-looking paths, and 8,289 were ONLY on APRS-IS.   
(Total of 18,449 with the difference being the time between grabbing the 
various numbers from my APRSIS32's full feed View menu summaries).

Just for interest, in the past two hours there's been 3,101 digipeaters 
active (meaning they showed in a packet's path before the last used 
component, not just based on symbols, but by actual usage), and 2,460 
IGates (again, showing after the q-construct in a non-TCPIP* packet).  
Note that these Digi/IGate statistics were calculated from APRS-IS 
packets which means they are EFFECTIVE digi/IGates meaning that they 
handled the FIRST packet to arrive in the APRS-IS.  From what I've seen, 
the odds are that over a fairly long period of time, every active 
Digi/Igate will show up in at least one packet, so I believe these 
numbers to be reflective of the APRS infrastructure composition.

>> The message server replying with the next pass
>> information, on the other hand, is very useful
>> indeed! Thank you!
> Amen.  And the courtesy posit that then accompanies the message to give the mobile radio the POSITION of the satellite then is the icing on the cake.  And this is enabled automatically by simply originating the POSIION from the same callsign as the message.  That is, the satellite NAME.  Done.

The  POSITION of the satellite isn't what the requester really wants, is 
it?  It's just that you believe that with a position packet, the 
receiver can calculate and display the bearing and distance of the 
satellite at that instant.  As I said above, there's other, 
shorter-than-posit-packet ways of doing that that won't require 
transmitting posits and/or objects for every satellite that is ever 
queried.  If the query operator can benefit from seeing the 
instantaneous, relative position of the satellite when a pass position 
is requested, then that's the information that needs to be sent, not the 
ACTUAL position of the satellite for the whole world to see.  "Least 
power necessary for the communication".

> As we have hammered it out here, it really is a great service.  It does what we did back in 1996 with APRSdata,and DIGI_NED, but does not require 1000 different people to implemente it locally, but originates it at one cental location.

And it doesn't keep throwing the posits into the ether until someone has 
a desire to know.  That's why I had some internal heart-burn over your 
comments about QRM and wasted bandwidth for a second query an hour or 
more later.  That's still a LOT less bandwidth than continuously 
transmitting every single pass in the localities where you got one of 
those 1,000 people to implement it.  I'm all about information on 
demand, and easy access to information, not information spew hoping that 
someone is actually interested in one of the multiple-thousands of 
packets that were transmitted in the past.

> As we did it in APRSdata Lynn can even format packet so that the voice synthesizer in the Kenwoods will SPEAK the presence of the satellite and even its elevation AND its frequency!

You really don't want the Kenwoods trying to read a Multiline 
description of a circle, do you?  And THAT's the REAL new value to the 
ISS object that is currently flying.

Oh wait, you're talking about the message response, let me think about 
that.  If you have a spare D700 speech synthesizer for semi-permanent 
loan, I could install it in my D710 (KJ4ERJ-11, but often in KISS mode 
as the RF interface for my KJ4ERJ-12 cellphone) for "testing" 
purposes...  I just wish Kenwood would differentiate the stations that 
have a voice synthesizer from those that don't so I could customize the 
content for the platform of the requester.  Now THERE's the power of my 
object generator residing inside the information-rich APRSISCE/32 
environment!

We're getting closer to an understanding of what information would be 
beneficial to the remote user instead of how we can leverage existing 
"features" to hopefully be able to glean that information.   Not sure 
when I'll have a chance to implement this, but unless the actual test 
queries of the satellite servers picks up....

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

PS.  In the past 11 hours of the satellite pass server's current 
runtime, GO-32 was queried twice, ISS 11 times, and AO-51 3 times.  
C'mon, we're discussing it, have you all actually QUERIED it?  Just send 
any text to the satellite name of your choice (like ISS or even 
2011-058A, B, C, D, or E for the newest nano-satellite launched from 
?India was it?) from any APRS messaging capable station.  It can be 
mobile (if a message-gating IGate is present) or UI-View or any other of 
the message-capable cell-phone clients.