[aprssig] 9600 APRS

[Wayne Sanderson]

>> record all the received packets over a three minute period of monitoring
>> 144.39 1200 operations, compile them into one long data stream and at the
>> end of that 3rd minute transmit that three minute take from 144.39 1200
onto
>> the 440 UHF band 9600 channel in one long burst.

>Sorry, but I think this is a very bad idea.  If we're talking about a
>very small "network" where there is only one digi and everyone on that
>network can live with a 3 minute latency, it may be OK.  for a general
>APRS network, it's a disaster.  Mobile stations may ping-pong every
>three minutes if two such digis were out of sync on their 3 minute
>window.

>Improving bandwidth and throughput is great, but if such latency is
>the cost, it's not really helpful to a "real time tactical network."

>-Jason
>kg4wsv

I'm not married to any particular power output or specific time between
burst transmissions- The digi can run the same power as all the rest of them
around here and can transmit an update burst at the top of every minute or
every second- That can be worked out. The main idea is the 9600 APRS
application and using the store and burst technique as a means of managing
the channel to increase throughput and cut down on packet collisions. If the
mobiles call in separately but the position updates go out in a scheduled
block all at once there is more usable time for the mobiles and individual
stations. Also, with a timed duty cycle, each mobile in theory can expect
update bursts at a scheduled time every minute and can conceivably be set
for a power saver mode where the unit cycles it's power down until receive
and/or transmit time. Could extend battery life in the field during tactical
ops...

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, 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. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090402/9ad58e5a/attachment.html>