[aprssig] Local Repeater Displays on Mobiles
mckeehan at mckeehan.homeip.net
Thu Jan 25 16:06:26 CST 2007
I don't really have an opinion about how this should work, but 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 same owner; not necessarily in the same
location, so you could easily have multiple objects with the same name as you
drive across East TN.
Would this not cause more (at least similar) problems than using the frequency
for the name of the object?
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
> 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
> Pete Loveall AE5PL
> pete at ae5pl.net
> aprssig mailing list
> aprssig at lists.tapr.org
More information about the aprssig