[aprssig] Satellite positions: Objects or Stations?
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Sat Oct 15 18:02:45 CDT 2011
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
> 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
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.
More information about the aprssig