[aprssig] Satellite positions: Objects or Stations?

[Bob Bruninga]

> I have to say that I would greatly prefer to 
> see ISS as an object, not a station.

Then it is of no use to anyone on RF, which was the point of this whole exercise.  To have a means for APRS operators in the field with their APRS radio (not internet) to not only get a prediction, but then to actually see where the satellite is.  For this to work, the symbol has to be generated in station-format due to shortcomings in most IGates that will not send a courtesy position for an object, but will do it for stations.

> If it would be a station, I, as an user, would 
> be assuming the transmissions are actually
> transmitted by the real ISS instead of Lynn's software.

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.

> The "de KJ4ERJ" would be non-standard and non-
> parseable since it would be in the free-form 
> comment text field.

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.

> I also have to admit I'm also not a big fan of 
> transmitting satellite tracks on the APRS-IS,...
> and the satellites move very fast - the distance 
> between the transmitted positions is so large 
> that the APRS user will rarely see them in his 
> rather zoomed-in local view,

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.

> might make more sense to regularly transmit the 
> keplers instead and implement the position 
> calculation on the client side.

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.

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

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.

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!

Bob, Wb4APR