[aprssig] Satellite positions: FREQUENCY
Bob Bruninga bruninga at usna.eduTue Oct 18 16:49:54 UTC 2011
- Previous message: [aprssig] Satellite positions: FREQUENCY
- Next message: [aprssig] Satellite positions: FREQUENCY
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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. Bob, WB4APR >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 >KD7YAQ _______________________________________________ aprssig mailing list aprssig at tapr.org https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
- Previous message: [aprssig] Satellite positions: FREQUENCY
- Next message: [aprssig] Satellite positions: FREQUENCY
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
