[aprssig] Local Repeater Displays on Mobiles

Thu Jan 25 17:46:19 EST 2007

> ...in thinking about using CALLSIGN-R I see an issue.
> Where I am, there are a number of repeaters that would 
> have the same callsign as they are controlled by the 
> me owner; not necessarily in the same location, so you 
> could easily have multiple objects with the same name 
> as you drive across East TN.

Yes, this is just one of the many reasons why using voice
repeater callsigns as an identifier on APRS makes no sense.
Besides, I don't know of anyone that knows various local
repeaters by their callsign, most everyone I know refers to
repeaters by their frequency.  About the only people who know
the repeater callsign are the locals, and this travelers
repeater frequency info is not intended for them.

Not counting the unworkable identification by repeater callsign,
there have been four recommendations on the proper format for
displaying these repeater frequencies on the front panel of
mobile radios:

1) OBJ-with PHG, 
2) OBJ-with RNG, 
3) 3rdPRTY-with PHG 
4) 3rdPRTY-with RNG 

and the only one that seems to work reliably on all versions of
the D7 and D700 and HAMHUD is the 3rdPARTY with PHG as shown
here:

BT }146.760->APOBJ:!DDMM.hhN/DDDMM.hhWrPHG5320 PL 107.3  Net Tu
9PM

So that seems to be the best all around.  If people want their
local object to be unique globally, then they may add a byte on
the end of the object (146.760-X) to make it one of 36 different
unique objects.

Bob, WB4APR

> On Thu, January 25, 2007 4:57 pm, AE5PL Lists wrote:
> >> -----Original Message-----
> >> From: Robert Bruninga
> >> Posted At: Thursday, January 25, 2007 8:56 AM
> >> Subject: RE: [aprssig] Local Repeater Displays on Mobiles
> >>
> >> >(Bob, if you are doing lookups while you are in motion
> >> > behind the wheel, you are spending way too much
> >> > time with your eyes off of the road).
> >>
> >> If the object name is the freq, as I propose, then one does
not
> >> have to do any "lookup".
> >
> > But you do have to do a lookup because you have no idea
where that
> > repeater is or what tone it uses without doing a lookup.  
> And if you are
> > staring at the display to see a momentary flash of the
information
> > (which is all you get around here), then yes you are 
> spending too much
> > time looking at the display.
> >
> >> Yes, what I am proposing now is completely consistent with
those
> >> receommendations.  That is, that the *info* needed by the
> >> travler (in this case the node number) shows up in the
OBJECT
> >> name, so that it shows on the front panel of the radio
> >> hands-free.  We recommended putting the ER or IP in front
of the
> >> object name so that when it was truncated on a 6 character
GPS
> >> map, then the more important node number would still show
on the
> >> map.  Thus we get ER-123456 for ECHOlink and IRLP-8080 for
IRLP
> >> and these show on the worst-case-6-byte GPS map as 123456
and
> >> P-8080.
> >
> > It is not consistent because there are frequencies being 
> displayed with
> > no concept as to what that frequency is (yes, people can 
> guess that it
> > is a voice repeater) especially if everyone plays with it 
> to make sure
> > they don't clobber somebody due to propagation.
> >
> >> But your email made two recommendations:
> >> 1) put in TCPIP* so the APRS-IS would ignore these packets
> >> 2) you wanted to be able to see recommended repeaters in an
area
> >> remotely via the APRS-IS.
> >
> > Now you are putting words in my mouth which I didn't say.  
> I made two
> > completely separate recommendations based on what was used
for the
> > object name and how the object was transmitted.  The #1 
> recommendation
> > is necessary if you stick with using frequencies and 
> third-party packet
> > formats because those objects are useless on APRS-IS.  #2 
> is if you use
> > repeater callsigns to identify the repeaters instead of the 
> frequencies
> > as those objects would be unique on APRS-IS and easily
displayed.
> >
> >> Why not?  They already do.  The APRS-IS and all clients are
> >
> > You do not understand APRS-IS and how it works.  You do not 
> know how the
> > servers or database clients work.  Please do not state 
> "Only a few lines
> > of code change" when you don't have a clue.  Suffice it to 
> say, APRS-IS
> > servers and database servers are not going to change for
this.
> >
> >> > pronouncements with a "I don't care if it doesn't work
> >> > for you 'cuz we don't have that problem here" attitude.
> >>
> >> Don't make a quote out of your own opinion and imply that I
said
> >> it.  I would never say that.  And besides it is unfounded
> >> anyway... for several reasons.
> >
> > That was a paraphrase of your first response to me.  If you 
> don't like
> > it, don't make those kind of statements when you respond.
> >
> > This is silly.  You aren't listening and aren't considering 
> anything I
> > have said (all you have done is attempt to justify your own 
> position).
> > Personally, I am not going to start using frequencies for 
> object names
> > just because you think it is a good idea with no 
> consideration of the
> > negatives.  So this discussion, IMO, is dead.  At least I 
> am done with
> > it.
> >
> > 73,
> >
> > Pete Loveall AE5PL
> > pete at ae5pl.net
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 