| |
ZL3AI > APRDIG 27.10.06 05:38l 223 Lines 9073 Bytes #999 (0) @ WW
BID : 8896-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 28 #12, 2/4
Path: DB0FHN<DB0MRW<DK0WUE<SP7MGD<CE8FGC<ZL2BAU
Sent: 061027/0421Z @:ZL2BAU.#87.NZL.OC #:11508 [Waimate] $:8896-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 11
Date: Thu, 12 Oct 2006 07:49:04 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] 9600b UHF APRS IS THE FUTURE OF APRS
>I see WAY too many like the following:
>
>Somebody>APRS,WIDE5*:Widen-n APRS Digipeater Someplace, Texas
>running UIDIGI 1.9B3
>
>This may make me sound like a curmudgeon, but I don't
>really care WHAT software a digi is using as long as it
>works, so why put it in the status?
Your sentiment is correct...
But unless we know what the digi is set up for, then we have no clue what
the network is doing or how to fix it. It is imperative that EVERY digi
contain all the information to tell us "what" it is doing. BUT! I do agree
that the above beacon is absolutely wasteful of bandwidth!
"WIDEn-N" should be abbreviated as "W3"
We already know it is an "APRS digipeater"
We can SEE where it is, and don't need "someplace, Texas"
And "running UIDIGI 1.9B3" should be in the TOCALL as "APNU19"
So in summary, the only thing needed in the above beacon other than the
LAT/LONG is the PHG, and then the abbreviation for "W2,TXn" if it supports
2 hops and TXn-N routing. Then any Additional text may be added if needed.
De WB4APR
------------------------------
Message: 12
Date: Thu, 12 Oct 2006 07:48:09 -0500
From: Ron Stordahl * <ron.stordahl_at_digikey.com>
Subject: [aprssig] More efficient use of channel capicity through
shorter packets
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
------------------------------
Message: 13
Date: Thu, 12 Oct 2006 08:03:31 -0500
From: Mark Earle <wa2mct_at_mearle.com>
Subject: Re: [aprssig] More efficient use of channel capicity through
shorter packets
Ron Stordahl * wrote:
>
>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
TXD is two things: Enough time for the transmitter to key up and make RF
(the time between asserting PTT, and having full, stable output). Part two
is, how long it takes the slowest, worst-case, RECEIVER in range, to open
it's squelch, and not "chop off" part of the packet on the way to the
attached TNC.
You can use crystal controlled, PIN DIODE switch transmitters for fast ptt
to rf out, but the slowest RECEIVER hampers you. Especially true where
folks use squelched audio, as they do at 1200 in many cases. Using
discriminator audio eliminates the squelch system delay. All receivers,
though, require SOME time to start acting on an incoming signal. It can be
close to zero, but there is some delay.
So TXD is a compromise for both transmitters (which you can control at your
site or station) and receivers, which you have no control over.
--
) ) de WA2MCT Mark
( ( Echolink 99190 Grid Square EL17HQ
) ) You will be assimilated... oooh, coffee!!
_|****| http://www.findu.com/cgi-bin/find.cgi?wa2mct-7 Home
( | | http://www.findu.com/cgi-bin/find.cgi?call=wa2mct-9 Mobile
`|____| wa2mct_at_mearle.com wa2mct_at_juno.com wa2mct_at_arrl.net
------------------------------
Message: 14
Date: Thu, 12 Oct 2006 09:31:01 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] More efficient use of channel capicity through
shorter packets
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.....
------------------------------
Message: 15
Date: Thu, 12 Oct 2006 06:38:52 -0700
From: <scott_at_opentrac.org>
Subject: RE: [aprssig] More efficient use of channel capicity through
shorter packets
And after TXD, you've got a minimum of 20 bytes of data - flag (1),
desination (7), source (7), control (1), pid (1), fcs (2), and flag (1).
Each byte is 8 bits, though bit stuffing can increase the number of bits
sent. Ignoring bit stuffing, 20 * 8 = 160. 160 / 1200 bps = 133.3 msec. I
think the tail is hardcoded as two extra flag characters on the OpenTracker.
Never had any trouble with that, at least not on VHF.
Also, I think you'll find that most ham rigs are slower to key up than
commercial mobiles. Some are really bad, at 200 msec or more. Though I
still have no idea what possessed Kenwood to hard-code the TXD at half a
second on the TM-D700 - I know of no radio that REQUIRES such a long TXD.
Unless maybe you're trying to catch a receiver in power save mode or
something...
Scott
N1VG
------------------------------
Message: 16
Date: Thu, 12 Oct 2006 10:46:15 -0400 (EDT)
From: Rick Green <rtg_at_aapsc.com>
Subject: RE: [aprssig] More efficient use of channel capicity through
shorter packets
On Thu, 12 Oct 2006, scott_at_opentrac.org wrote:
>And after TXD, you've got a minimum of 20 bytes of data - flag (1),
>desination (7), source (7), control (1), pid (1), fcs (2), and flag (1).
>Each byte is 8 bits, though bit stuffing can increase the number of bits
>sent. Ignoring bit stuffing, 20 * 8 = 160. 160 / 1200 bps = 133.3 msec. I
>think the tail is hardcoded as two extra flag characters on the OpenTracker.
>Never had any trouble with that, at least not on VHF.
So, to summarize what I'm reading here, TXDelay needs to be large enough
to span:
1) Transmitter synth lock-up delay
2) Transmitter PA Key-up delay
3) Receiver squelch open time
In addition, there may also be a delay for the Receiver's modem. At 1200
baud FSK, the detection of the tones is fairly quick, but does the modem
actually deliver good data immediately? Or does it need to see multiple
bits fly by before its local bitclock is sync'd, and it can reliably
deliver data to the PAD.
With 9600baud modems which use more complicated encoding schemes, I
suspect this modem clock recovery/bitclock sync time may be longer as
well.
Another short-packet data application, the ubiquitous credit card
authorization terminal, is still using 300 baud modems to this day, simply
because the handshake/lockup time on the faster codecs adds more time than
is saved during the data-transfer phase.
--
Rick Green, N8BJX
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
------------------------------
Read previous mail | Read next mail
| |
