[aprssig] Local Repeater Displays on Mobiles

[Robert Bruninga]

>>> (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.  

No, my proposal does not require any lookup most of the time.
When I am driving through an area and am wondering what the
local voice repeater frequency is, I don't need to know the PL
nor do I need to know where it is in order to listen to it.  And
the object only shows up on my radio front panel (direct) when I
am in range.  If I am in range, I don't care where it is.  Now,
after seeing the frequency show up on my radio front panel LIST
and listening to it for a while, then, if I want to talk, I will
have to hit the OK button to see its PL tone if any.  But most
of the time I just want to monitor first.  And if it does not
need a PL, then I never have to do 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, that is exactly the problem with the CALLSIGN-ID method in
your area (around there).  You cannot see the frequency unless
you happen to watch the screen when it first flashes up.  This
diverts the driver's attention and is not safe.  That is why we
don't recommend that method.

The FREQ-ID method I propose, displays the frequency on the
front panel station LIST all the time. If the driver has pressed
his LIST button once, from then on, for the rest of the trip,
the 5 most recent objects/stations will always be on his front
panel LIST.  If one of them is a voice repeater frequency, then
that user can see it at any time hand's free.  Without being
interrupted by the flash and without having to push any buttons
to read it.

>> We recommended putting the ER or IP in front of the 
>> [ECHOlink and IRLP object names so that when 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.

Yes, that is exactly why we are proposing this standard for
voice repeater frequency display on APRS.  If all voice repeater
frequenceis are transmitted in this manner, then we won't have
any ambiguity.

> [regarding object-permanence:]
> You do not understand APRS-IS and how it works.  You do 
> not know how the servers or database clients work.  

But I know how they -are-supposed-to-work-.  I know that the
APRS spec specifically states that the originating callsign of
an OBJECT should be retained along with the object itself so
that ownership of an object is unambiguous.  This is required
for data integrity of the APRS system.  If clients have not
properly implemented OBJECTS according to the spec, then they
need to be fixed.

> 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.

That's too bad.  Here we have an opportunity to provide for
object permanence in APRS, and I think we should consider it.
 
> 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).

I am surprised to see you say that.  I have considered all of
your inputs, and have openly discussed their merits and have
used them to better refine my proposal over the last week.  

1) I took your input that you want to see these things on the
APRS-IS, so I came up with three backwrd compatible methods to
make the objects unique.  a) Permanent object format. b)
Permanent 3rd party format, c) FFF.FFF-X format.

2) I took your input about the RNGxxxx as the better way to
display repeater range on these objects and added it to the
recommendation.  That is, until it was tested and found not to
work on the D7 and D700.

3) I took your input about using TCPIP* to prevent these objects
from entering the APRS-IS.  But then it was incompatible with
recommendation number 1, so it was not used.

So I value your input and used all of it that could work.

> 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.  

I haven't seen any negatives, that have not been solved with the
current recommendation and with inputs from others as to what
works and what doesn't.

> So this discussion, IMO, is dead.  At least I am done with it.

That is too bad.  It is really a great concept and makes the
APRS mobile travler enjoy his trip by seeing the operating
frequency of the locally recommended repeater show up on this
radio front panel hands-free.  And this only shows up when he is
in range.  Thus it is useful, pertinent, timely, real-time
information, which is exactly what APRS is all about.  I think
it is a great feature for APRS mobiles.  And is trivial to
implement by any local sysop in his digipeater.

Bottom line, this is the best recommendation that has evolved
through inputs on the APRSSIG.  This is easily implemented in
the BText of APRS digipeaters (using KPC-3 type command sets) to
send out these local direct voice repeater objects.  It is the
most workable of all considered and tested:

BT }146.760->APOBJ:!DDMM.hhN/DDDMM.hhWrPHG5320 PL 107.3  Net Tu
9PM AARC W3VPR
B E 10
UNPROTO APNxxx  <== where XXX is the version ID for your
digipeater.

Its in my digi and looks pretty good on the mobile D7 and D700
displays.  I'm sorry that the RNGxxxx didn't work.  It seems not
to be parsed into the D7/D700 display field set aside for that
purpose. I agree that it was better for the mobile operator, but
since it is not showing up in the PHG field like it is supposed
to, it therefore consumes 7 bytes out of the available 20 which
are better used for other things...

Bob, WB4APR