| |
ZL3AI > APRDIG 27.10.06 05:40l 303 Lines 11887 Bytes #999 (0) @ WW
BID : 8897-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 28 #12, 3/4
Path: DB0FHN<DB0MRW<DK0WUE<SP7MGD<CE8FGC<ZL2BAU
Sent: 061027/0421Z @:ZL2BAU.#87.NZL.OC #:11509 [Waimate] $:8897-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 17
Date: Thu, 12 Oct 2006 08:20:18 -0700
From: dick_at_kb7zva.com
Subject: [aprssig] Tier 2 Server List Update 10/11/06
We've added a few more Tier 2 servers to our network. The latest addition
is florida.aprs2.net in Ft. Lauderdale. There are now 34 Tier 2 APRS
servers world-wide. The recommended port is 14580 where you can define your
custom filter needs. Download the 'How to':
http://f5vag.eu/php/file_download_filter_txt.php
To view the Tier 2 server list:
http://serverlist.aprswest.com
http://france.aprs2.net/APRServe2.txt
Option for Ui-View32 users:
To download the list just insert the following in the Ui-View's 'DOWNLOAD
APRS Server List' text box. Afterwards check-box the servers you plan to
use:
serverlist.aprswest.com
or
france.aprs2.net/APRServe2.txt
73,
Dick, KB7ZVA
APRSWest - APRS Tier 2 network
------------------------------
Message: 18
Date: Thu, 12 Oct 2006 08:46:33 -0700
From: wa7nwp <wa7nwp_at_jnos.org>
Subject: Re: [aprssig] Bandwidth IS THE FUTURE OF APRS
>>I do agree that the above beacon is absolutely wasteful of bandwidth!
We have to change the way we look at things.
YouTube feeds 100 MILLION!!! Videos a day. Those Videos are in
Megabytes. (You all saw the dramatic 4th episode of Chad Vader - right?)
It's 2006. We're still running 1200 baud (nope - didn't forget the K
at the end of that -- hard to believe.) We panic if somebody actually
adds an extra hop to their path. Here we're counting fraking bytes in a
status packet.
We have incredible technology just waiting to be put to use. We have
dozens of vastly underused channels. We probably have Megabytes in the
Microwave spectrum that's dead dead dead.
Lets work on moving on - not digging a deeper hole then what we already
have.
Quiet air is wasted air - make packets!
73
Bill - WA7NWP
------------------------------
Message: 19
Date: Thu, 12 Oct 2006 16:00:05 -0000
From: "Alan P. Biddle" <APBIDDLE_at_MAILAPS.ORG>
Subject: RE: [aprssig] Who had the Garmin or Deluo Serial GPS OT
Hi,
I received several messages in this thread with the actual subject of: RE:
[SPAM] [aprssig] Who had the Garmin or Deluo Serial GPS Only this thread,
beginning with a post from: aprssig-bounces_at_lists.tapr.org; on behalf of;
Jason Winningham [jdw_at_eng.uah.edu] I am guessing that the subsequent posts
just picked up the subject line.
I had to rescue them from my SPAM folder, and wonder how they got so tagged?
Alan
WA4SCA
------------------------------
Message: 20
Date: Thu, 12 Oct 2006 11:01:42 -0500
From: Gregg Wonderly <gregg_at_wonderly.org>
Subject: Re: [aprssig] Bandwidth IS THE FUTURE OF APRS
wa7nwp wrote:
>It's 2006. We're still running 1200 baud (nope - didn't forget the K
>at the end of that -- hard to believe.) We panic if somebody actually
>adds an extra hop to their path. Here we're counting fraking bytes in a
>status packet.
>
>We have incredible technology just waiting to be put to use. We have
>dozens of vastly underused channels. We probably have Megabytes in the
>Microwave spectrum that's dead dead dead.
This is the biggest issue. There's only so much RF spectrum that can be
used. Most of the wide spectrum is in the EHF/microwave and up part of our
allocations. So, in order to go "fast", we're going to have to move up in
spectrum. As Bob said about VHF->UHF, that implies path loss issues, which
mean that there will have to be a lot more "digis", or very, very focused
coverage areas. This is not as trivial as it feels.
Gregg Wonderly
------------------------------
Message: 21
Date: Thu, 12 Oct 2006 12:09:29 -0400
From: Art <KY1K_at_verizon.net>
Subject: Re: [aprssig] Bandwidth IS THE FUTURE OF APRS
x-avg-checked=avg-ok-2061536A
At 11:46 AM 10/12/2006, you wrote:
>>>I do agree that the above beacon is
>>absolutely wasteful of bandwidth!
>
>We have to change the way we look at things.
>
>YouTube feeds 100 MILLION!!! Videos a day. Those Videos are in
>Megabytes. (You all saw the dramatic 4th episode of Chad Vader - right?)
>
>It's 2006. We're still running 1200 baud (nope - didn't forget the
>K at the end of that -- hard to believe.) We panic if somebody
>actually adds an extra hop to their path. Here we're counting
>fraking bytes in a status packet.
>
>We have incredible technology just waiting to be put to use. We
>have dozens of vastly underused channels. We probably have
>Megabytes in the Microwave spectrum that's dead dead dead.
While we have the technology, we DO NOT have the bandwidth. We also don't
have fiber optic links and/or hardwired transmission lines that are
relatively low attenuation links between nodes. We also don't have millions
of dollars in high speed computers just to route individual packets. We
also don't have 100 million users to distribute the operating costs
between.
Comparing dedicated hardwired network throughput to our modest wireless
data speeds in an unfair comparison.
>Lets work on moving on - not digging a deeper hole then what we already have.
>
>Quiet air is wasted air - make packets!
Bill,
Years ago, we had a node operator here in Maine who systematically drove
users away from his node anytime HE deemed the traffic levels as
inappropriately high. Not to mention any names here, but any local will
probably remember him, he was a statewide known micromanager.
He did his job so well that eventually there was no traffic on his node,
and he closed up shop and took his node down::>
It took us years to get rid of him, but in the end he did himself in.
Making packets for the sake of having more packets is not the answer. In
fact, it sounds a little dangerous to me::>
GL to all.
Art
------------------------------
Message: 22
Date: Thu, 12 Oct 2006 09:24:54 -0700
From: <scott_at_opentrac.org>
Subject: RE: [aprssig] More efficient use of channel capicity
throughshorter packets
>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
Depends on the clock recovery used in the receiver. Normally that's a DPLL
that has to be synced to the incoming bit rate, and loop bandwidth affects
how fast it can be synced. Sending a bunch of zeros (alternating high/low
in NRZI) gives the greatest number of transitions and makes it easier to
lock on to the signal. I think most receivers should be able to lock on in
0-10 bit times. My Tracker2 prototypes do pretty well in that respect -
I've implemented a kind of fuzzy clock recovery scheme that at least
outperforms the KPC-3. Hook up the output of a KPC-3's demodulator to a T2
and (at least with my test corpus) it'll decode 1-3% more packets than the
KPC-3 itself. Of course, generally speaking you've got to set your TXD high
enough to work with the slowest TNC around.
>With 9600baud modems which use more complicated encoding schemes, I
>suspect this modem clock recovery/bitclock sync time may be longer as well.
I think it depends a lot on implementation, and the specific scheme used. I
haven't worked with higher baud rates much myself, but I'd expect that an
old hardware-based linear feedback shift register is going to take a lot
longer to sync up to a scrambled signal than a properly written software
equivalent would.
>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.
Excellent example. You can force faster modems into shorter negotiation
sequences if they're configured right, though I haven't tried that since my
days of exchanging BBS message bundles at 14.4k and trying to shave as much
as possible from the long distance bill.
For something like credit card authorization, you only have to exchange tens
of bytes. A 300 baud modem can get the job done before a 28.8 is halfway
through its negotiation.
Scott
N1VG
------------------------------
Message: 23
Date: Thu, 12 Oct 2006 09:25:23 -0700
From: "Stephen H. Smith" <wa8lmf2_at_aol.com>
Subject: Re: [aprssig] More efficient use of channel capicity through
shorter packets
ron.stordahl_at_digikey.com wrote:
>
>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.
It depends entirely on the synthesizer scheme in a particular radio. In
some radios, the synthesizer shifts from being the RX local oscillator
(i.e. offset from the operating frequency by the IF frequency) to being
on-channel when you transmit. This is the classic version of a synthesized
design. It has the minimum parts count and complexity and is the slowest
settling.
In other designs, the synthesizer always remains on the RX local osc
frequency. On TX, a crystal oscillator on the IF frequency is turned on
and mixed with the LO to generate the TX frequency. In this scheme, the
synthesizer doesn't have to un-lock and re-lock on a new freq each time
you TX. The TX settling becomes just the startup time of the crystal osc
-- just as fast as the classic crystal-controlled radios. [Note that this
approach is a "true" transceiver just like an HF SSB rig where the TX uses
the RX IF, local osc and mixer chain backwards on TX. ]
And then there are the newest designs that use DDS (direct digital
synthesis). These designs don't use a PLL system at all; basically they
clock a D-to-A converter with a waveform derived from a crystal osc and
variable divide-by-N counter. They can effectively slew instantly from one
frequency to another, limited only by how fast a controller can load the
divider with a new divide-by value.
In the early 1980s, I was involved in one of the first public safety mobile
data projects. We had a "fast draw" competition between the
crystal-controlled radios of the day (the Motorola Micor and the GE Mastr
II) to determine which could key up in the fewest number of milliseconds.
Out of the box the Micor keyed up much faster. We determined that the GE
"ICOMs" (Integrated Compensated Osc Modules - a crystal combined with a
temp-compensated dedicated oscillator in a can, for each channel) were slow
on the startup when powered up on TX.
These radios used crystals operating at 1/12th or 1/18th of the operating
frequency with a chain of frequency multipliers to get to the operating
freq. We wired the TX ICOMs (oscillators) to be powered ALL the time to
avoid the startup and settling time. This of course would have produced a
continuous dead carrier in the receiver. We got around this by modifying
the radio to turn the power to the multiplier chain on and off while
leaving the (1/18th TX freq) osc running all the time. We were able to get
the time from keyup to full TX down to 7 milliseconds with this expedient.
The moral of all this is that crystal-controlled radios aren't neccesarily
fast on the draw and not all synthesized ones are slow.
--
Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: 14400 [Think bottom of the 2M band]
Home Page: http://wa8lmf.com
NEW! JavAPRS Filter Port 14580 Guide
http://webs.lanset.com/wa8lmf/aprs/JAVaprsFilters.htm
UI-View Misc Notes and FAQ
http://webs.lanset.com/wa8lmf/aprs/UIview_Notes.htm
"APRS 101" Explanation of APRS Path Selection & Digipeating
http://webs.lanset.com/wa8lmf/DigiPaths
Updated "Rev G" APRS http://webs.lanset.com/wa8lmf/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:
------------------------------
Read previous mail | Read next mail
| |
