[aprssig] 9600 APRS
Stephen H. Smith
wa8lmf2 at aol.com
Thu Apr 2 14:26:48 EDT 2009
Wayne Sanderson wrote:
> As far as a burst update not being really helpful in a realtime
> tactical environment, consider these points: The individual units only
> beacon every few minutes anyway unless set up for more frequent
Not neccessarily. With the obsession of many users to abuse "smart
beaconing" to transmit every change of heading, every turn around a
corner, every stop at a traffic light, etc to draw track lines perfectly
aligned with the underlying map in APRS displays, many people are
transmitting FAR more frequently than just "every few minutes".
> and they have a tendency to all transmit in a clump on 144.39 anyway,
> with the exception of some with shorter or longer duty cycles. They
> may all start out with different starting times, but after they get
> delayed when the DCD Sense makes them wait for the next bit of free
> air time, the transmit clock starts up at that point and they move
> into that slot, creating a freight train effect.
1) The DCD Sense may be handled this way on traditional TNCs. DCD
*does not* reset the 3 minute (or whatever) beacon interval timer in
most simple trackers. It just inhibits TX until the channel is
clear. It the TX is inhibited for 1.5 mins of a 3 minute timer
interval, all that happens is that the subsequent transmission will be
attempted 1.5 mins (rather than 3 mins) later.
2) Even this is assuming that the simple tracker has some sort of
DCD at all. Many effectively don't because the user doesn't connect RX
audio or the COR/SQ line of the mini-DIN data connector to the tracker.
Typically the tracker is connected to the MIC jack (PTT and TX audio) only.
3) If, somehow, the user has enabled time-slotting tx (based on the
GPS time), the tracker is DEFINITELY not going to sync up with the burst
intervals of a store-and-forward digipeater.
4) The APRS network is being populated with an ever-increasing
number of transmit-only appliances with no receiver at all -- hence
absolutely guaranteed no DCD. The original low power PocketTrackers and
MicroTraks were this way but probably of no consequence because of their
low power -- often the digi wouldn't even hear them. Now that dumb (or
rather deaf) transmit-only trackers at the 45-50 watt power level are
about to be marketed wide, you can make even fewer assumptions about DCD
"training" mobiles to transmit in an orderly fashion.
> Why not formalize that as a scheduled update burst from the digipeater
> and leave the rest of the airtime open for the individual units to
> report positions, message, etc. Messages can be throughput immediately
> instead of waiting in the update que.
It's not the messages, it's the (far more numerous) posits that are the
problem! If a mobile variously:
o Hits an igate directly (rather than waiting in your digi queue for a
minute or more) part of the time,
o Gets to an igate via the queued digi part of the time,
o Gets to an igate via a non-queuing digi (i.e. immediate retransmit)
part of the time,
you will massively create the infamous "hyper-jump" problem where a
mobile appears to move forward, then suddenly jump backwards as the
delayed posit reaches the Internet system AFTER more recent direct or
non-delayed-digi posits arrive at the IS.
This problem of long-delayed posits reaching the IS minutes (or tens of
minutes) AFTER more recent updates has been discussed on this list many
times over the last several years. Often it is due to a wide-area digi
at a high location prevented from transmitting by having it's
Squelch/DCD held open by distant QRM or intermod, while other (usually
lower-level ones that can't hear distant garbage) in the coverage area
transmit immediately. The issue (long-delayed old posits) has also
inconclusively been blamed on bugs in TNC firmware or UIview in the
Unless you can:
1) Totally control ALL digipeaters in your coverage area to ensure
they queue by the same rules
2) Totally control ALL igates in your coverage area to have them
respond ONLY to transmissions from your queued digis; i.e. reject direct
3) Order that all mobiles have positive DCD operation
you are going to create a MASSIVE "hyper-jump" ping-pong effect for
posits on the APRS-IS !!!
Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: WA8LMF or 14400 [Think bottom of the 2M band]
Home Page: http://wa8lmf.com --OR-- http://wa8lmf.net
World Digipeater Map
JavAPRS Filter Port 14580 Guide
"APRS 101" Explanation of APRS Path Selection & Digipeating
Updated "Rev H" APRS http://wa8lmf.net/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:
More information about the aprssig