| |
ZL3AI > APRDIG 07.12.03 11:55l 229 Lines 9919 Bytes #999 (0) @ WW
BID : 2432-ZL3AI
Read: GUEST
Subj: TAPR Digest, Dec 02, 2/5
Path: DB0FHN<DB0FOR<DB0MRW<OK0PPL<DB0RES<ON0AR<VK3TE<ZL2BAU<ZL2BAU<ZL3VML
Sent: 031207/0906Z @:ZL3VML.#80.NZL.OC #:14125 [Chch-NZ] FBB7.00i $:2432-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: aprssig ID vs NOID
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 2 Dec 2003 13:04:27 -0500 (EST)
X-Message-Number: 9
SInce this private email raissed some frequently asked questions, Ill
answer here:
On Tue, 2 Dec 2003, someone wrote:
>Hi Bob.
>I've just got to argue a bit and hope you can show me what I'm missing.
>
>>>SOMECALL>APTW01,DIGI1*,WIDE3-3:_11272313c060s000g000t...
>>>SOMECALL>APTW01,DIGI1*,WIDE3-2:_11272313c060s000g000t...
>>>SOMECALL>APTW01,DIGI1*,WIDE3-1:_11272313c060s000g000t...
>
>I agree that the ID function is wiping out any previous path info.
>However I'm not sure I agree it is USEFUL path info if it doesn't tell
>me who the other stations are. At least this way I know who I'm hearing
>when I'm sitting between 2 or 3 WIDEs.
Then I think you may not be understanding what these would look like if
the "DIGI1" was not improperly set to ID. If it was properly set to NOID
and the packet was initiated with the standard recommended initial hop of
WIDE,... then you would see:
>>>SOMECALL>APTW01,DIGIA*,WIDE3-3:_11272313c060s000g000t...
>>>SOMECALL>APTW01,DIGIB*,WIDE3-2:_11272313c060s000g000t...
>>>SOMECALL>APTW01,DIGIC*,WIDE3-1:_11272313c060s000g000t...
and it would be clear that the SENDER is hitting all three digis DIGIA,
DIGIB and DIGIC direct and that this is the reason for the multiple
packets.
>>The DIGI1 is incorrectly set to UIFLOOD WIDE,ID and this CAUSES this
>>DIGI1 then to overwrite or obliterate the path data that could have
>>told you what was the first digi for that packet to hit. Since this
>>digi is inocrrectly set to "ID" instead of the receommended APRS
>>standard of "NOID", it thus kills path data and traceability.
>
>When I setup my first local WIDE, I turned on ID because it eliminated the
>need for the WIDE to beacon. If it put its own call on every WIDEn-n
>packet, I'd never need to identify to meet FCC rules. I could send the WIDE
>location beacon every 30 minutes and still be legal.
But having ID on, obliterates PATH info on EVERY packet through that digi
and the penalty far outweighs any advantage of having ID on... Further,
with NOID on, EVERY packet that originates in the vicinity of yoru digi
will still not only be identified by your digi call as the first digi, but
that valuable information will carry through to ALL surrounding areas as
well.
FURTHER, your digi should be seinding out its Position every 10 minutes
anway (LOCAL, direct) so it is properly identified anyway...
>>If the packet had originated as WIDE,WIDE3-3, then it would have arrived
>>as above, BUT the first digi in the PATH would not be THIS digi, but would
>>be the three separate digis callsigns that first heard the packet. A much
>>more valuable piece of info.
>
>This is where I keep having trouble. You keep saying that the three
>separate call signs will show in the beacons so you can see three arrival
>paths. But if none of the WIDEs are doing call sign substitution, then the
>only thing they ever send is WIDE as the digi station call sign. I don't
>understand how that can be an improvement.
There shouldnt be hardly any "WIDE-ONLY" digis left anymore. Since 1996
all digis are capable of callsign substitution and if they aren't, then
its time for them to be upgraded...
>Now maybe the root cause of my problem is that I never gave NOID a chance
>to see what it does. I've been working with Kantronics KPC-3 v8.2 software.
>When I read the TNC command docs, I saw no indication that the TNC ever put
>its own call sign on a digi packet unless it was a TRACE command or the
>UIFLOOD ID parameter was enabled. The way I read the docs and what I saw
>when watching packets seemed to confirm that if the packet came in
>addressed to WIDE or WIDEn-n, it was repeated with an address of WIDE. I
>never found a digi list of WIDE,WIDE,WIDE,WIDE* to be very useful. At least
>with one real call sign in the stream I'd know who I was hearing.
This may have been true 8 years ago, but I hope that times have
changed...
>>Thus, this DIGI1 is either improperly set to "ID" or if the owner
>>insists on operating this way, then it SHOULD have an OVERLAY character
>>of "I" to show everyone that this digi is ID'ing itself in EVERY packet
>>and obliterating useful path data... Unless it has the overlay I, we
>>cannot tell what it is doing for certain... Bob
>
>Personally, when I was reading the docs, I looked at ID/NOID to be a
>feature and a method of shortening packets. I have recently gone back to
>NOID of two of my WIDEs but for now they are too far away to see any
>difference.
That may be because a local DIGI is still set with "ID" and thus is
obliterating the valuable path data from your properly configured NOID
digis...
>I will probably make the same change on the last WIDE soon, but
>I'm not happy about it. I want to know what paths and digi's are in use and
>active.
Setting NOID is the best way to do that, since EVERY packet transmitted
that begins the path with WIDE will then be identified for the life of the
packet by what digi first heard it...
>I want to be able to identify new home stations that come on the
>air as WIDE instead of RELAY.
They shouldnt. Home stations should never be WIDE unless they are
clearly in the ideal location to be a wide area DIGI, and then they
should use a TNC that does callsign substitution...
>If switching to NOID will show me complete
>paths that contain useful call signs, then I'll do it in a flash. But if
>all I'm ever going to see is RELAY,WIDE,WIDE,WIDE* then I don't see the
>point.
Your example has nothing to do with ID versus NOID. Your example of
R,W,W,W tells you that you have 4 old WIDE-ONLY digis, nothing more and
nothing less... and nothing to do with ID or NOID...
>As it is, all I can do is change my UNPROTO path to TRACE3-3 so I can see
>what paths my beacon packets are following.
Yes, tracing the path of packets is what TRACEn-N is designed for...
Bob
----------------------------------------------------------------------
Subject: Paths (again, gasp)
From: wes@johnston.net
Date: Tue, 02 Dec 2003 13:29:57 -0500 (EST)
X-Message-Number: 10
I don't remember where we left off last time but I've been giving this some
thought and realized how important it is to "advertise" local customary
paths. As a kenwood user, I have no way to see anyone else's path so I have
no reference when going into a new area. Yes, WIDE,WIDE will always work
but I think it's worth a little bit of network overhead to allow the local
digipeater to advertise the locally acceptable path either in it's beacon
text or as a message.
I sure wish the kenwoods would show path information rather than making us
run blind.
Wes
----------------------------------------------------------------------
Subject: Software TNC for palm ?
From: "adam berson" <list-aprs@dumbengineer.com>
Date: Tue, 2 Dec 2003 12:59:39
X-Message-Number: 11
My apologies if this has been mentioned previously, I've been away from the
SIG for a while and searches turned up nothing. If possible please reply
to my personal email and the sig.
Does anyone know of a Software TNC for palm? Specifically, I'm interested
in something similar to AGWPE, except for a palm pilot. Extend this a
little further and use it on the Garmin iQue3600 with pocketAPRS or
something else and the only piece you need outside of the PDA is the
radio.
Reading the AGWPE processor recommendations, it looks like you can get away
with 1200 baud on a 486 66MHz, so would the 200MHz chip in the iQue be
adequate?
http://www.qsl.net/soundcardpacket/moreagwpe.htm#processor
I've never done any sound IO on a PDA, so if anyone has, please speak up!
I'd be interested in working with people on a project like this. I think
initially just getting the thing to transmit data (like tinytrak) would be
great, and obviously packet decode would be even better. It looks like the
sound API for PalmOS5 is ready to go:
http://www.palmos.com/dev/support/docs/palmos50/#Sound
Some other ideas:
- pretty much all of your APRS packet, except for the position data, stays
the same between packets. These pieces could be pre-generated in the PDA
or on a PC to save processor power when you're actually trying to send
stuff
- if you hook up to an external speaker, then you could also make it so
that when the palm asserts PTT (RTS?), it mutes the external speaker (using
a relay?) and just sends data to the radio - so you can still use the iQue
for voice prompted navigation without hearing the data braaps.
- use another control line (CTS?) wired to PTT in your real mic, and you
can get mic-E functionality as well (this would even be a good feature for
pocketAPRS as it is)
- get the device to turn on automatically when your vehicle comes on
(perhaps using one of the control lines like the external hotsync button
does) for an automatic mobile APRS tracker
----------------------------------------------------------------------
Subject: Re: Paths (again, gasp)
From: "Sean \\The RIMBoy\\" <sean@rimboy.com>
Date: Tue, 2 Dec 2003 08:18:47 -0600 (CST)
X-Message-Number: 12
On Tue, 2 Dec 2003 wes@johnston.net wrote:
>I sure wish the kenwoods would show path information rather than making us run
>blind.
That has been a big complaint of mine about the D700. Granted, you can go
in and monitor the packets as they go by, but that's a little hard to do
at 70mph.
Nevermind the situation like we were seeing this morning. Either we had a
band opening or someone was gating NWS warnings way outside of our area.
Sean...
--
The punk rock will get you if the government don't get you first.
--Old 97's
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
