[aprssig] 9600 APRS

[Stephen H. Smith]

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 
> transmissions, 

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 
digipeater/igate mode.


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 
transmissions

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]
Skype:     WA8LMF
Home Page:          http://wa8lmf.com  --OR--   http://wa8lmf.net

World Digipeater Map
  http://wa8lmf.net/APRSmaps

JavAPRS Filter Port 14580 Guide
  http://wa8lmf.net/aprs/JAVaprsFilters.htm

"APRS 101"  Explanation of APRS Path Selection & Digipeating
  http://wa8lmf.net/DigiPaths

Updated "Rev H" APRS            http://wa8lmf.net/aprs
Symbols Set for UI-View,
UIpoint and APRSplus: