Order Tray | Contact Us | Home | SIG Lists

[aprssig] Satellite positions: FREQUENCY

Bob Bruninga bruninga at usna.edu
Tue Oct 18 16:49:54 UTC 2011

> I also agree that the satellite information 
> should be delivered via Objects vs messages.

Remember, this  service is for the MOBILE or HANDHELD operator outdoors.
These users have no maps and so conveying huge 3000 mile diameter satellite
footprint OBJECTS are of no value.  If the APRS station has a PC and MAPS
then he does not need APRS-IS to do predictions for him, he can do it on his
own PC!

The HUMAN interface to the HT/Mobile FM satellite operator is just to see
the "object" in his POSITION LIST and there it is displayed with a DISTANCE
and BEARING and ELEVATION and FREQUENCY.  All he possibly needs to visualize
and operate the satellite.  I use "object" in QUOTES because my preference
is for this "object" to use the STATION POSITION format so that it gets
passé d from the APRS-IS out to the HT/MOBILE operator via the 2-way
messaging IGate.   Apparently OBJECTS in many IGate software are not
implementd to pass through from IS to RF.


>However I see a growing problem, that of a growing number of CLASSES
or CLASSIFICATIONS of objects and no explicit information in the
objects for differentiation.

>For example, weather alert objects, have two things in common, the
station that injected them into APRS-IS and the format of the data.

>Both are sub-optimal for classification, on one hand if the
originating station is coded as a filter and the station changes, the
method fails, if the station injects other types of objects the
classification fails.

>The data format as well is sub optimal, for example I received a ISS
object that looked just like a weather alert down to the Multiline
Object Format superficially looking valid.

>Another example are Earthquake Objects, which suffer from the same
problem of hard coding an originating stations or relying on the
symbol information. The symbol information would seem like a good
idea, except any user can use an Earthquake symbol (and in many
applications a user may not even know it is an earthquake symbol,
because there is no text describing the symbol to the user)....there
is at least one user near Austin, TX who is using the earthquake
symbol as a station identifier.

>In summary, even though it adds another layer of management, a way to
classify objects of a certain type, i.e. Weather Alerts, Earthquakes,
or Satellite Positions, would be useful. It would allow applications
to simply filter objects that the user is interested in.

>The question is how to encode the classification information in an
unobtrusive way as possible. Unfortunately, considering the data
format for weather alert objects, I can't think of a way that is
backward compatible.

>Perhaps a way of using the symbol data in an overloaded way is
possible, a classified object could simply use a single bit set to one
to signify that the symbol data can be trusted for classification as
opposed to being a symbol just randomly selected by a user for some
other meaning.

>In any case, that's my 2 cents on the matter.

>Chris Walker

aprssig mailing list
aprssig at tapr.org

More information about the aprssig mailing list