[aprssig] Ambiguity due to GPS
william.diaz at comcast.net
Sat Jan 7 14:12:58 CST 2006
>From: aprssig-bounces at lists.tapr.org
>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Scott Miller
>Sent: Saturday, January 07, 2006 13:26
>To: 'TAPR APRS Mailing List'
>Subject: RE: [aprssig] Ambiguity due to GPS
>> I am talking about excessive packets generated by OpenTrac
>> units on 144.39
>> in a heavily congested area.
>Bill, maybe you can explain why you think this is only an issue for
>OpenTracker users. You think TinyTrak users don't do the same things?
>TinyTrak has the same option to transmit separate status text. The
>OpenTracker has an additional telemetry option, but it must be
>enabled. Same with HDOP/SATS output.
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
I have not seen any TinyTraks sending 8 or more packets a minute. If they
do send this volume of traffic, steps should be taken to reduce this volume
>If anything, I like to think that OpenTracker users are, as a group, a
>little more technical. That may be changing now that it's
>gained so much
>popularity, but historically those who have chosen my product
>have done so
>because they valued its technical merits above the popularity of the
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.
>I just fired up the TT3 config program and entered a setting
>of 900 msec
>TXD, 2 second transmit rate, with separate status text each
>know what? It didn't stop me from doing it either. Both the
>the OpenTracker come with reasonable defaults pre-programmed.
>I don't know
>about the TT3, but the OpenTracker even comes with a fairly
Then TT3 should be modified to prohibit this type of activity as well.
>Hunting down APOT02 users with inappropriate settings is not
>my job. If
>you've got users abusing the local network, through ignorance
>regardless of their hardware, it's time to break out the 'ol
>Wouff Hong and
>educate them a bit.
Not too long ago you asked developers to modify their code to eliminate
conflicts with your protocol. Now I am asking you to modify your code to
minimize the impact of ill-advised transmission rates and practices.
>I've got users in over 30 countries and on all 7 continents,
>and I'm not
>about to play global APRS cop and try to second guess what
>with their own hardware. If someone wants to provide some regional
>guidelines that I can include in the manual, fine. But the network
>conditions in Zagreb or Bialystok aren't quite the same as those in Los
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 the current OpenTracker manual is quite reasonable in
>"One transmission every two minutes is acceptable for most
>A fixed station (e.g., a solar powered site reporting battery
>temperature) might choose an interval in the range of 5 to 30
>you require transmissions more often than every two minutes or
>using the SmartBeaconingT options detailed below."
>If that's not suitable, let me know and I'll change it.
You need to provide clear warnings of the effects of some of your parameter
settings, including examples of how many packets would be generated and
potential adverse effects on local and nearby networks.
Apparently, your SmartBeaconing implementation also can causes a telemetry
packet to be sent (if telemetry is enabled) with each change in direction,
or distance. Therefore the volume of traffic appears to double when using
both SmartBeaconing and telemetry. I didn't see anything in your manual
explaining this, though I might have missed it. It seems a simple drive
around the block with SmartBeaconing and telemetry enabled could cause 8
packets to be sent if this is the case. 2 for each turn. That would amount
to at least 8 packets in a minute.
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 packet sent, or
for minutes of air time. Obviously, there are no cost concerns with APRS,
but we do have a shared channel and must be mindful of the impact such
activity has on other users.
>aprssig mailing list
>aprssig at lists.tapr.org
More information about the aprssig