| |
ZL3AI > APRDIG 03.10.03 09:48l 377 Lines 15368 Bytes #999 (0) @ WW
BID : 2070-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 13/16
Path: DB0FHN<DB0RGB<DB0IGL<DB0FSG<DB0MAK<DB0MRW<OK0PKL<OK0PCC<OK0PRG<OK0PPR<
OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1452Z @:ZL3VML.#80.NZL.OC #:9567 [Chch-NZ] FBB7.00i $:2070-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Alinco DR610, using it for voice and tracker
From: WA8LMF2@aol.com
Date: Tue, 30 Sep 2003 18:30:27 EDT
X-Message-Number: 62
In a message dated 9/30/2003 12:45:47 PM Pacific Daylight Time,
wd9eka@evinger.com writes:
>but has anybody set one up to use one
>side for tracking using the "packet" connectors on the back to feed audio,
>or are those connectors strictly for 9600 baud. Would be nice if I could
>just leave the one side on 144.39 and use the other half for voice.
Repeating yet again my post about the MiniDIN6 "packet" connector...
The 6-Pin MiniDIN "DATA" or "PACKET" connector is an industry standard
adopted by all the Japanese ham mfrs. The contacts on this connector
provide access to:
TWO kinds of receive audio:
Raw non-deemphasized discriminator output sometimes labeled "9600 Baud
Receive".
De-emphasized squelched audio similar to what come out the speaker, but
at a fixed level unaffected by the volume control. It is sometimes labled "1200
Baud Receive".
On multi-mode radios (Yaesu FT-817, FT-100, etc), only the 1200 baud output
will be live on AM, SSB or CW since the 9600 baud output is associated only
with the discriminator of FM receivers.
Receiver Squelch status line (normally no sig-squelch-closed = 0V, signal
active-squelch open = 5V). Sometimes labled "COR", "COS", "RX" or "Activity".
TX audio input (sometimes misleadingly labeled "TX Data Input") In many
radios, this input can go either into the same channel as the mic input
(but at a higher audio level) for 1200 baud packet, SSTV, EchoLink, etc, or
DC-coupled directly into the TX modulator (for 9600 baud packet) depending
on the setting of an item in the radio's configuration menu.
TX PTT (confusingly labeled "Standby" by Kenwood) -- normal
ground-to-transmit line just like most mic inputs.
Common/Ground.
Note that despite the misleading labels referring to data input and output,
the jack only carries AUDIO, AUDIO, AUDIO! THERE IS NO ACTUAL DATA in
the sense of RS-232 or TTL-level streams of 1s and 0s anywhere on this
connector!!!
This connector is the perfect point to connect packet TNCs, soundcard
interfaces, phone patches, IRLP/EchoLink controllers, paging encoders, or
any other device that needs access to the transmit and receive audio of a
radio.
These audio inputs and outputs are high-level 100-300mV, similar to home
stereo "LINE" input level seen at RCA jacks on tuners, amps, tape decks,
etc, rather the the 5-10mV level seen at most mic input jacks.
On most radios with this port, grounding the DIN-6 PTT line mutes the front
panel mic input to prevent extraneous shack noises from getting mixed with
whatever you feed into the transmit audio input.
You can connect a TinyTrak here very effectively if you:
1) Change R5 (220K resistor) on the TT to about 27-33K to boost the TX audio
level from mic level to line level.
2) Connect the direct DC-coupled "CARRIER DET" line of the TT to the
MiniDIN "SQUELCH" or "COR" line.
An annotated pinout diagram of this connector is on my website at:
http://members.aol.com/wa8lmf/miscinfo
Click through the link on this page which will take you to a directory of
assorted downloadable files, not a web page. Look for the file
MiniDIN6-Packet.pdf
Note that this connector is exactly the same one used on PS/2 keyboard and
mouse cables. A dead mouse, or a PS/2 extension cable, is an excellent
source of a plug and cable assembly to mate with the jack on the radio.
Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.com
Ham Radio/Mobile SSTV page: http://members.aol.com/wa8lmf/ham
APRS Stuff
http://members.aol.com/wa8lmf/aprs
----------------------------------------------------------------------
Subject: Re: ***New*** TRACEn-N (LANn-N) Paradigm
From: WA8LMF2@aol.com
Date: Tue, 30 Sep 2003 18:36:27 EDT
X-Message-Number: 63
In a message dated 9/30/2003 12:47:59 PM Pacific Daylight Time,
scott@opentrac.org writes:
>fall of Central California
>does this, how do we get packets from Southern California to Northern
>California?
The 1200 baud 144.39 channel IS ALREADY SATURATED in both Southern and
Northern CAL. It is unrealistic to expect to propagate data reliably from
one overloaded network to another overloaded network 300 miles away! The
last thing each end of the state needs is more QRM from the other end!
Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.com
Ham Radio/Mobile SSTV page: http://members.aol.com/wa8lmf/ham
APRS Stuff
http://members.aol.com/wa8lmf/aprs
----------------------------------------------------------------------
Subject: Re: ***New*** TRACEn-N (LANn-N) Paradigm
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 30 Sep 2003 18:57:51 -0400
X-Message-Number: 64
Bob Bruninga wrote:
>With the UITRACE implementing of your LANn-N, (instead of UIFLOOD) now you
>do NOT have to MIX an initial WIDE,LANn-N which does propagate some dupes.
>But you can use just the basic LAN3-3 path which will arrive at EVERY
>digipeater in your X digi LANn-N with NO dupes and with full traceablity.
>and injection point identificaiton. Yes, the path arrives as
>
>DIGI1,DIGI2,DIGI3, but that is a very SMALL price to pay for all the
>advantages!!!
And people laughed at me when I proposed this 4 years ago for HF PropNET
where the world is your collision domain when the band opens.
By the way...it's still how it works on 28.128 USB @ 1200 baud and 50.620
FM @ 1200 baud...unfortunately, 10 and 6 meters doesn't open like it used
to. :)
Ev, W2EV
PS: we use HOPn-N, but it's just TRACEn-N in disguise
----------------------------------------------------------------------
Subject: The bottom line, simply [was:***New*** TRACEn-N...]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 30 Sep 2003 19:08:01 -0400
X-Message-Number: 65
Bob Bruninga wrote:
>Nationwide traveler: RELAY,WIDE2-2
Isn't this really the issue? The APRS world would work if e-v-e-r-y-o-n-e
simply launched RELAY,WIDE2-2. Remember the chant from last year?
"RELAY,WIDE2-2 in 2002!"
I believe that the best path is actually RELAY,TRACE2-2 but who am I? :)
Is it possibly just this easy? Those that don't play nice get some nudging
from their APRS community. Just give people good instructions and a gentle
nudge, they'll play nice.
Nothing to buy and plenty is fixed.
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: David and Ann Fraser <zl3ai@nzart.org.nz>
Date: Wed, 01 Oct 2003 11:38:56 +1200
X-Message-Number: 66
Bob B. said:
>Nope, what you and everyone else seems to be missing, is that it is NOT the
>fault of callsign substition per se, it is many faults compounded:
>
>1) SYSOPS who dink with the Dwait parameter. All DIGIS in an APRS system
>MUST have the default D-WAIT of 0!!! Some well meaning, but not
>thoroughly understanding SYSOPS have dinked with the D-Wait parameter to
>try to make sure that the same packet from two digipeaters DONT collide.
>DUH! The are SUPPOSED to collide. It is called fratricide and is part of
>the dupe elimination foundation of APRS.
>
>2) WIDEn-N propogation of hundreds of copies of every packet. THus if
>there are two original digis, then there are hundreds of copies of both
>and they are GUARANTEED if the sysops have changed Dwait from 0!
It seems to me that the traditional packet parameters of Slottime and
Persistence (designed to enhance connected-mode channel sharing) would work
against the desired APRS fratricide mechanism and cause extra congestion
instead by encouraging multiple digis in an area to politely take turn
digipeating the same packet from one station instead of all simultaneously
transmitting it and using fratricide to minimise/eliminate dupes and
congestion.
At least two widely used and popular APRS digipeater implementations that I
know of use Slottime and Persistence, so what values should these be set
to?
Should Slottime and Persistence reaork. You've got two
>digis equidistant from a fixed station. Both digis have zero DWAIT. A
>mobile somewhere between them is picked up by both digis, and digipeated at
>the same time, give or take a 200 msec in TXD difference. The fixed station
>has a pretty constant multipath situation. How does it ever see ANYTHING
>from EITHER digipeater?
You are correct it is physically impossible, because they will trash each
others packets. If they make it to another WIDE digipeater outside your
range, then you will never decode it. I think physics rules here and that
is a problem with the old DWAIT parameter and one of the reasons Persist
and Slot were implemented. That is, to avoid the packet collision.
Using DWAIT to avoid dupes does not seem rational when the dupe checking
algorithms are suppose to do that function.
----------------------------------------------------------------------
Subject: Re: aprsnews digest: September 29, 2003 = overblown math
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Tue, 30 Sep 2003 17:36:36 -0500
X-Message-Number: 69
>>A protocol even better than WIDEn-n would be a great start.
>
>I know Im the new guy around here but why dont we do something that the
>physical wire guys have been doing for years on 'shared' ethernet media.
>CSMACD
>
>Each digi does a random 'back off' before retransmission of a packet. If
>it hears another digi send the message they were going to send out it
>incriments the 'number' and transmits as scheduled. If it has come to the
>end of the requested path (WIDE3-3 for example) the packet gets thrown in
>the trash.
>
>Sorry if Im not using the write APRS protocol terms..like I said..Im new
>to APRS...not new to network technology.
>
>-Tyler
We call a similar implementation of that Persistence and Slot Time in the
packet world. It does exist, but it is not being advocated from what I am
reading in the APRS world..
Persistence is a number from 0 to 255 where 127 represents a 50%
probability that channel access will be attempted. This is derived from
a random number generator. The higher the number the greater the
probability.
Slot time is typically a number between 0 to 255 specifying time in
100ms increments that specifies the delay between attempts to access
the channel.
Back in the 80's DWAIT was an acceptable method for digipeaters
because that is all we had to seize the channel. It caused problems in
some areas. Hence, the Persist and Slot method was implemented in
these cases to solve the packet collision between digipeaters.
It helps if adjacent digipeaters use the same numbers for the Slot Time
method.
Tim - N8DEU
----------------------------------------------------------------------
Subject: Re: The bottom line, simply [was:***New*** TRACEn-N...]
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 20:00:40 -0400 (EDT)
X-Message-Number: 70
On Tue, 30 Sep 2003, Ev Tupis (W2EV) wrote:
>Bob Bruninga wrote:
>>Nationwide traveler: RELAY,WIDE2-2
>
>Isn't this really the issue? The APRS world would work if e-v-e-r-y-o-n-e
>simply launched RELAY,WIDE2-2. Remember the chant from last year?
>"RELAY,WIDE2-2 in 2002!"
>
>I believe that the best path is actually RELAY,TRACE2-2 but who am I? :)
But we dont even want 3 hops in many cases, so RELAY,WIDE is the same as
RELAY,WIDE1-1 anyway. but your TRACE idea is exactly why I am so excited
about my NEW LANn-N using UITRACE...
Because TRACE3-3 is really a GREAT universal path... but there yourself and get to
it.
There are always exceptions and 'what-if's but I would stick to this rule.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Bill Vodall WA7NWP" <wa7nwp@jnos.org>
Date: Tue, 30 Sep 2003 17:42:06 -0700
X-Message-Number: 74
>Henk, what are DIGI_NED's requirements for RAM and program space? Is there
>any chance that it could be squeezed into an embedded platform, like maybe a
>KPC-3? How much OS-dependent stuff has it got?
>
>Scott
>N1VG
The comments a day or so ago about using a Palm device triggered an
interesting thought. It would be a good project to get Digi_ned running
on an older Palm device.
Bill, WA7NWP
----------------------------------------------------------------------
Subject: RE: Random backoff
From: "Scott Miller" <scott@home.miller.org>
Date: Tue, 30 Sep 2003 17:56:02 -0700
X-Message-Number: 75
>Just further disintigration of the 144.39 APRS network that COULD work
>reliably everywhere at ANY time if people would just understand that it is
>a LOCAL network for LOCAL use. Yes, you can spin off all kinds of ways to
We're seeing a constantly increasing number of stations. It's really not
hard to reach the 50-station limit with a single big event.
>split the traffic and split the load. But HOW WILL YOU USE THIS at a
>local event which is COME-AS-YOU-ARE...
Everyone knows about APRS channels A, B, and C. Pick one. Only the digi
sites have to invest in multiple receivers.
>Now you ae also giving up real-time...
Ok, so if 'real-time' is that critical, and APRS is only ever near real-time
anyway, hold on to the packet for a few seconds and see if you've got
something else to piggyback it on.
>Bingo. But if your intent is to get it to the IGatge, whats wrong with
>having the IGate get it from 144.39. Bingo! Thats what we have now.
Because what portion of the time can you get to the IGATE with a single hop?
Less than 100%, I'm certain. Even here in CA, it's been proven that 2 hops
doesn't get you in from everywhere. If it can get in locally, great. If
not, keep it from flooding the network all the way down the line and just
inject it into your backbone stream.
>and it works well. Put an IGate where ever it is needed and get users to
>stop trying to FLOOD the 144.39 network with DX packets..
Someday we'll have broadband at every hilltop, but it's not there yet. I'm
not sure they can even spell DSL in parts of West Virginia. =]
>Now that will have completey broken the user network by making DIGIS only
>let APRS be used for what a few SYSOPS define is impmortant. THAT NEVER
>WORKS IN HAM RADIO...
Nope, I'm just saying you stop making the users figure out how to make the
network do what they want, and just let them tell it what they're trying to
accomplish. Leave in source routing if you must, but don't make it the
default. You can still source-route IP packets, though it's rarely done for
a legitimate reason these days.
>But yes, the only way to insure more traffic on RF is to bundleit all to
>UHF at 9600 baud as I have been proposing since 1997 or so... but back to
>reality. Lets fix 144.39 now.
How about we do what we can with what we've got, and start accepting the
fact that it's still not going to cut it in the long term. Stop thinking
about deploying KPC-3+ digis, and start thinking about embedded PCs that can
be reprogrammed and upgraded remotely.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
