[aprssig] Satellite positions: Objects or Stations?
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Sat Oct 15 18:30:41 EDT 2011
On 10/15/2011 12:31 PM, Bob Bruninga wrote:
>> Would it be sufficient to include a ,KJ4ERJ-15*,
>> in the path? Or is the qaC,KJ4ERJ-5 that is
>> added by the APRS-IS server sufficient?
> Probably not... BUT, I think y ou are synthesizing these on the APRS-IS only, and so you can put anything you want in the digi field? Could you put in "de KJ4ERJ" in the first digi field? I dont think anything parses the actual digi fields... But come to think about it, when an IGte puts it back to RF, I think it truncates all of the early part of the path, so that part of info woiuld be lost?
There are LOTS of things out there doing path analysis on all packets,
RF and otherwise, that come through the APRS-IS. Have you seen my own
coverage maps at http://tinyurl.com/APRSAct24 and
http://tinyurl.com/APRSAct00? They only work by having paths that
contain stations and embedded blanks in the path would be particularly
bad. Besides, what's the difference between putting KJ4ERJ-15* in the
path indicating that I've handled the packet and putting "de KJ4ERJ" in
the path which could/would break a bunch of stuff?
When an APRS-IS packet is gated to RF, the transmission becomes the
IGate operator's responsibility. But they can always point back to the
APRS-IS archival databases like aprs.fi which is why I want there to be
some evidence of the source. I still personally think they should be
objects generated by me and we're setting a dangerous precedent by
having software generating "pseudo-stations" no matter how much you say
they're the same. Too much of the rest of the world wants to DISPLAY
them the same, but the TRANSPORT and PROCESSING may be different in
order to get them onto the display.
> BUT!!! The IGate is adding its own header in 3rd party format, and so at that point the IGate is taking origination responsiblity. And before that, while it is on the APRS-IS, then the pseudo "de KJ4ERJ" is fully visible.
I'd still have severe concerns over something as non-standard as "de
KJ4ERJ" in the path of an APRS packet.
> BUT I still prefer putting it on the end of the packet. Its there to be legal, but may not be visibile on many radios. If it is beyond he 20th position, it wont show on the D7, if it is beyond the 28th position, it wont show on the D700. If it is beyone the 64th position it wont show on the D710 etc...
>
> ANyway, put it on the end so it does not mess up the format sof the real data...
There's no "legal" on the APRS-IS, but I still want the source to be
readily visible in the ways that packet sources are normally
determined. If it ever gates to RF, then it's the IGate operator's
responsibility for "legality" which is why some IGate operators don't
transmit. They don't want the liability against their license, or so
I've read.
There's no room in the packet. Remember I mentioned the Multiline
description of the coverage area? And the fact that a posit or object
comment is restricted to 43 characters? And the overhead and two bytes
per point in a Multiline only gives me 10 points to describe the circle
already. The Path of a packet shows how it was handled and the source
call (usually) shows where it originated. I'd like to keep that bit
still standard at this point. Obviously the D7*s won't display the
Multiline, but the "Msg4Pass" part at the start will still be visible.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
More information about the aprssig
mailing list