[aprssig] More efficient use of channel capicity through shorterpackets

[Robert Bruninga]

The D700 that I use for PCSAT downlink decodes just fine at
100ms TXD.
We set the PCSAT TXD that short to save power. The D7 model (g)
Can set any TXD from the user menu, and it also can transmit as
short
As 100 ms.  But then how many DIGIS can hear one that short?
Who knows.....

> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org 
> [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Ron
Stordahl *
> Sent: Thursday, October 12, 2006 8:48 AM
> To: TAPR APRS Mailing List
> Subject: [aprssig] More efficient use of channel capicity 
> through shorterpackets
> 
> There has been recent discussion concerning the use of higher
baud 
> rates, shortening packets through shorter TXDelay and a 
> shorter payload 
> through the use of Mic-E and eliminating extraneous added
text.
> 
> I would be very much interested in knowing exactly how long 
> (time) APRS 
> packets are and with that information I could better 
> understand exactly 
> what could be gained from this approach.
> 
> I realize there is both a TXD (at the head of the
transmission) and a 
> TXTail (at the end).  Between these is data as required by the

> specification.  Part of that data is of fixed length and 
> other variable 
> length.  For example as a packet is repeated the path 
> information builds 
> up (and it does not appear to be insignificant in size).  If I

> understand the ax.25 spec the path is part of a variable 
> length field.  
> Then there is the 'payload', which can be large, but could be 
> small if 
> everyone used Mic-E without extraneous extra text.
> 
> Experimentally I have determined that for MFJ1270C's and
Motorola 
> Micor's that between them packets can be reliably decoded 
> with a TXD as 
> small as 90 milliseconds.  This is for relatively strong 
> signals.  Below 
> 90 milliseconds reliability drops off rapidly.  Since 
> relaying by high 
> digi's does constitute a major share of the traffic, reducing 
> their TXD 
> (and TXTail if possible) would seem worthwhile.
> 
> With UIDIGI firmware there is no user option to set TXTail, 
> and I do not 
> actually know what it is hard coded as.  Ill take a guess that
it's 
> around 100 milliseconds, but could easily be wrong.  Without a
way to 
> control this I have no way to tell experimentally how it's
length 
> effects reliable decoding.
> 
> The Motorola Micor's are crystal controlled and work very
well.  I do 
> not know if one could run a modern synthesized mobile radio 
> with TDX as 
> low as 100 milliseconds...my recollection..and it is from many
years 
> ago..was that such radios required a longer TXD for their 
> frequency to 
> settle down after key down.  This may no longer be true.
> 
> Or it could be that the TNC itself requires a certain minimum
TXD and 
> TXTail. 
> 
> I expect someone here who is more current in the technology 
> can explain 
> the limiting factors in TXD and TXTail and offer numbers 
> which could be 
> used reliably with current hardware.
> 
> Ideally I would like to have a formula into which I could plug
TXD, 
> TXTail as well as the variable length elements in the packet 
> and get the 
> total channel time for 1200 baud packets.  I may be asking for
the 
> nearly impossible here..looking at the AX.25 spec makes my 
> head spin.  
> But with that it would be possible at least estimate what
improvement 
> could be anticipated by minimizing the elements over which we 
> have some 
> control.
> 
> Ron, N5IN
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>