<br>
>> record all the received packets over a three minute period of monitoring<br>
>> 144.39 1200 operations, compile them into one long data stream and at the<br>
>> end of that 3rd minute transmit that three minute take from 144.39 1200 onto<br>
>> the 440 UHF band 9600 channel in one long burst.<br>
<br>
>Sorry, but I think this is a very bad idea.  If we're talking about a<br>
>very small "network" where there is only one digi and everyone on that<br>
>network can live with a 3 minute latency, it may be OK.  for a general<br>
>APRS network, it's a disaster.  Mobile stations may ping-pong every<br>
>three minutes if two such digis were out of sync on their 3 minute<br>
>window.<br>
<br>
>Improving bandwidth and throughput is great, but if such latency is<br>
>the cost, it's not really helpful to a "real time tactical network."<br>
<br>
>-Jason<br>
>kg4wsv<br><br>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...<br>
<br>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. <br>