[aprssig] Ambiguity due to GPS

[Bill Diaz]

Scott,
  See below:

>-----Original Message-----
>From: aprssig-bounces at lists.tapr.org 
>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Scott Miller
>Sent: Saturday, January 07, 2006 15:00
>To: 'TAPR APRS Mailing List'
>Subject: RE: [aprssig] Ambiguity due to GPS
>

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

Take a look for your self on the APRS-IS and come to your own conclusions.

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

144.39 is used exclusively for APRS compliant packets.  Other protocols
should use another frequency.

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

I have repeatedly said that I think most of your users are likely not aware
of the negative impact they can have on our network.  

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

Not true around Chicago.  Take a look at the samples I provided in a
previous post.  

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

Not quite.  The added TXD overhead is reduced on the original transmission,
and perhaps on the first digipeat.  After that, there is no advantage.
Listen to RF and judge for yourself.  Besides, the users I hear are
beaconing positions and telemetry packets far beyond the recommended minimum
of 1 per minute.
 
>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.

And I see it constantly.  Really bad during drive times during the morning
and evenings.

>But it doesn't even come close to doubling channel usage - 
>it's more like a
>20% increase.

Still should not be condoned or permitted.

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

Yes, but the examples I provided clearly show that is not the case.

Bill KC9XG

>Scott
>N1VG