[aprssig] Ambiguity due to GPS

[Scott Miller]

> The excessive rates I see locally are caused solely by 
> OpenTrac users.  I
> see occasionaly TinyTrak packets, but do not see the high 
> repitition rates
> from them.  

Keep in mind that the OpenTracker came on the scene a couple of years after
the TinyTrak - it may be that there are a higher proportion of new users
with OpenTrackers than TinyTraks these days.  But I've never heard anyone
else claim that OpenTracker users are more abusive of the network than
TinyTrak users.

> I question the merits of ANY product that can easily overwhelm a local
> network.  I also believe that many of your users are not 
> aware of the impact
> they are having on local networks.

And what product on the market now WON'T let you misuse it?  You think a
KPC-3 can't be made to overload 144.39?  For that matter, what if you sit on
your mobile rig's mic?  I've at least made an attempt to educate users.  I
don't think the TT3 manual provides any guidelines at all on proper TX
rates.
 
> Not too long ago you asked developers to modify their code to 
> eliminate
> conflicts with your protocol.  Now I am asking you to modify 

I suggested that it's a bad idea to configure your TNC to pass non-text
packets in converse mode.  That's not just for OpenTRAC traffic (which, to
my knowledge, no one is using on 144.39), but for TCP/IP or any other
non-text mode that might wind up on the channel.  I'm not aware of any TNC
that doesn't filter properly by default.

> It was interesting to see some of your international users 
> with paths of
> Trace7-7 sending 8-10 packets per minute with your product.  
> I can just
> imagine what that does to some affected networks.

I think we've already established that APRS isn't used the same way
everywhere.  Is Trace7-7 an acceptable path in New Zealand?  Maybe, I don't
know.  Probably not enough users there for it to cause much harm.

I still don't understand why you feel that OpenTracker users are somehow
worse as a group than users of any other product.  Do you complain to Honda
that their customers are worse drivers than those who drive Fords?

> You need to provide clear warnings of the effects of some of 
> your parameter
> settings, including examples of how many packets would be 

Fine, but I'm already providing more information than the TinyTrak3's
manual, and you don't seem to have a problem with TT3 users despite there
being a lot more of them.

> Apparently, your SmartBeaconing implementation also can 
> causes a telemetry
> packet to be sent (if telemetry is enabled) with each change 
> in direction,

Most telemetry users aren't moving.  If they have a need for telemetry when
moving, then it makes sense to send the packets together.  Remember, there
is no added TXD overhead for the second packet.  The telemetry packet adds
around 50 bytes - say 45 msec airtime.  Let's say you've got a typical TXD
of 150 msec, and a position packet of around 50 bytes.  That's less than 250
msec.  With one digipeat, 500 msec total channel utilization.  I understand
a Kenwood TM-D700 (of which there are many more on the air) uses that much
airtime for a single Mic-E packet, WITHOUT a digipeat!

> or distance.  Therefore the volume of traffic appears to 
> double when using
> both SmartBeaconing and telemetry.  I didn't see anything in 

'Appears' is the operative word here.  See above.  Real airtime increases
are modest.  Sure, running telemetry when it's not needed is a bad idea.
But it doesn't even come close to doubling channel usage - it's more like a
20% increase.

> Most commercial AVL applications who use "Corner Pegging" or
> "SmartBeaconing" limit the number of packets actually sent due to cost
> concerns.  Not unusual for commercial users to pay for each 

And you can set the minimum time interval between packets.  If you don't
want it to transmit more than once every 60 seconds, regardless of the
number of corners, you can do that.

Scott
N1VG