| |
ZL3AI > APRDIG 23.12.03 19:30l 275 Lines 9592 Bytes #999 (0) @ WW
BID : 2540-ZL3AI
Read: GUEST
Subj: TAPR Digest, Dec 20, 2/3
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<WB0TAX<SP7MGD<VK3TE<ZL2BAU<
ZL2BAU<ZL3VML
Sent: 031223/1035Z @:ZL3VML.#80.NZL.OC #:15171 [Chch-NZ] FBB7.00i $:2540-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Holiday Traveling = 144.39 CTCSS 100
From: "Kim Aiken" <dianneaiken@aikenco.com>
Date: Sat, 20 Dec 2003 10:43:36 -0800
X-Message-Number: 10
Bill caught me and it works just fine.
Kim (AC7YY)
-----Original Message-----
From: nwaprssig-request@nwaprs.org [mailto:nwaprssig-request@nwaprs.org] On
Behalf Of Bill Vodall - WA7NWP
Sent: Friday, December 19, 2003 9:03 AM
To: SIG, nwaprssig
Cc: TAPR APRS Special Interest Group
Subject: Re: Holiday Traveling = 144.39 CTCSS 100
On Fri, 19 Dec 2003, Bob Bruninga wrote:
>You can only use Voice Alert on a rig that has the TNC connected to the
>discriminator or audio prior to the CTCSS Squelch circuit... otherwise
>your TNC wont hear anything except another local voice alert station.
Key here is when talking about a rig that "has the TNC." There's
no special hookup requirement for regular radios or scanners.
I have a memory programmed in the main rig for 144.39 with 100HZ
enabled for receiving and transmitting. Theory is, that as I'm
scanning through the memories, it'll break the squelch if I hear
a packet or transmission on 144.39 with the tone. It ignores
all the other packets with no tone.
That memory also allows me to call stations using Voice Alert. I
have a neighbor running Voice Alert on his mobile D700 but have
yet to catch him on the road when I'm by my radio.
73,
Bill - WA7NWP
----------------------------------------------------------------------
Subject: Re: IGATE indication
From: "Dick Stanich" <dick@kb7zva.com>
Date: Sat, 20 Dec 2003 13:0:35
X-Message-Number: 11
>What turns on the indication that a particular station is an IGATE? Is it
>aposition report from an IGATE, or something else?
Igates send out status/information... IGATE,MSG_CNT=91,LOC_CNT=76
In UI-VIEW32, there are 2 options. You can 'highlight Igates', which puts a
blue square around Igates. Makes them easier to spot. Then, the program has
a function to 'transmit IGATE status', located in APRS server setup.
Mileage can vary depending on program type.
Dick, KB7ZVA
APRSWest.net (Tier 2)
http://webserver.kb7zva.com
----------------------------------------------------------------------
Subject: RE: Digi behavior questions
From: "Cap Pennell" <cap@cruzio.com>
Date: Sat, 20 Dec 2003 11:42:14 -0800
X-Message-Number: 12
Supposed to, yes. hi They might be set with the less than optimal setting
of UIDWait ON.
----------------------------------------------------------------------
Subject: WOW never seen this for APRS!!!
From: "Jacob Tennant" <k8jwt@adelphia.net>
Date: Sat, 20 Dec 2003 14:47:24 -0500
X-Message-Number: 13
Was poking around on the internet and found this little gem this afternoon!
Looks like we are advancing into the 21st century...
http://www.elcom.gr/sv2agw/tnc.htm
A true USB TNC with a built in GPS port! ! !
Jacob Tennant-K8JWT
My laptop is already drooling ;-)
----------------------------------------------------------------------
Subject: new KPC-3Plus version 9.0
From: "Cap Pennell" <cap@cruzio.com>
Date: Sat, 20 Dec 2003 12:10:42 -0800
X-Message-Number: 14
I forgot about the Help command in my new Kantronics KPC-3Plus version 9.0
TNC, KPC3PMX-D62703122-9.0N. So I emailed service@kantronics.com about a
couple of commands that were new to me, UIDUPE and UISSID.
Thanks to Ken for replying (and reminding me).
The TNC has quite a bit of internal help for its commands. Just enter the
command HELP and a command name.
For example:
cmd: HELP UIDUP
UIDUPE Timer for UI duplicate checking (0-255 seconds)
cmd:
(helps cut down the number of repeated digipeats of the same packet)
or
cmd: HELP UISSID
UISSID If on, UI frames use SSID routing
(this is normally used for directional (north,south,east,west) routing of
digipeated packets)
73, Cap KE6AFE
----------------------------------------------------------------------
Subject: Re: Digi behavior questions
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 20 Dec 2003 16:00:27 -0500 (EST)
X-Message-Number: 15
Could be due to incorrectly configured DIGIS. If these digis are
**incorrectly** set as UIFLOOD ID ON, then the ID setting is causing the
failure of callsign-subtstitution dupe checking...
On Fri, 19 Dec 2003, Scott Miller wrote:
>I keep seeing this on 144.39:
>
>aprs: fm N6ZV-8 to ST5UPP via RELAY WIDE3-3 ctl UI pid=F0(Text) len 9
>0000 `05dl .k/
>aprs: fm N6ZV-8 to ST5UPP via K6SYV-10* WIDE3-3 ctl UI pid=F0(Text) len 9
>0000 `05dl .k/
>aprs: fm N6ZV-8 to ST5UPP via KD6DSI-5* WIDE3-3 ctl UI pid=F0(Text) len 9
>0000 `05dl .k/
>aprs: fm N6ZV-8 to ST5UPP via K6SYV-10* WIDE3-2 ctl UI pid=F0(Text) len 9
>0000 `05dl .k/
>aprs: fm N6ZV-8 to ST5UPP via KD6DSI-5* WIDE3-2 ctl UI pid=F0(Text) len 9
>0000 `05dl .k/
>
>As I read it, that's a failure both in digipeater fratricide and dupe
>checking. Now, I'm guessing that if both digis are picking up the RELAY
>alias, that would account for the lack of dupe checking in the first hop.
>But why the immediate dupe after that?
If one digi digis it by callsign substitution, and then the other ID digi
digipeats it as WIDEn-N, but then OBLITERATES the first digi's path data,
then the first digi does not see its own call, and so it digis again.
WE MUST GET ALL THESE IMPROPER "ID" DIGIS SET PROPERLY TO NOID!!!!!
Setting UIFLOOD to ID, is JUST PLAIN WRONG for the APRS net on 144.39.
Im not saying that these in particular, they may not even be ID digis, but
this example just shows another reason why we cannot have ID digis that
are obliterating network path data!!!
Argh...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: PCsat usage
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 20 Dec 2003 16:34:05 -0500 (EST)
X-Message-Number: 16
PCsat activity peaks:
I noticed a peak in activity on PCsat today on http://pcsat.aprs.org
Normally the list-of-last-60 is about 24 hours in depth. Today (saturday)
it was only 5 hours to fill it. Seven of them were mobiles.
As long as it holds up, it is just another digi on 145.825 via RELAY or
WIDE or its own calls. It should last till New years eve at least (if we
are lucky)...
de WB4APR@amsat.org, Bob
PCsat WEB page http://www.ew.usna.edu/~bruninga/pcsat.html
----------------------------------------------------------------------
Subject: Re: aprssig digest: December 19, 2003
From: Dale Seaburg <kg5lt@earthlink.net>
Date: Sat, 20 Dec 2003 16:57:17 -0600
X-Message-Number: 17
>Subject: Re: SmartBeaconing and corner pegging
>From: "Scott Miller" <scott@opentrac.org>
>Date: Fri, 19 Dec 2003 08:55:59 -0800
>X-Message-Number: 17
>
>Right... I've been giving it some more thought and basically what I'm
>thinking of is a dead reckoning calculation that runs from the last beaconed
>fix. Once the error between the dead reckoned fix and actual fix exceeds a
>certain threshold (dependent on speed, I suppose) another beacon is
>transmitted. It's just going to be a little tricky to do this without trig.
>Ithink I might try treating the coordinates as rectangular and just
>watching the slope. Might not work well at higher latitudes though.
>
>Do other smartbeaconing trackers enforce a minimum time between beacons?
>From a quick glance at the HamHUD code I can't see that it does.
No, the HamHUD II code does not have a minimum time between transmissions.
Further, to answer a concern of Wes' about jogs in the road causing too
frequent transmissions, that is a matter of the user-selectable settings in
SB. You can make it as tight as you want - hence, beaconing with little
angular movement, or loose, to where you have to make practically, a 90
degree or more turn before a beacon would happen.
73 - Dale KG5LT
----------------------------------------------------------------------
Subject: Re: aprssig digest: December 19, 2003
From: Jeff King <jeff@aerodata.net>
Date: Sat, 20 Dec 2003 18:05:30 -0500
X-Message-Number: 18
One fix for this would be to "store the pegs" and only send them at a
predetermined time, reporting the current position of the object as well as
significant vector changes that occured in the past. If they where all
queued together, this would also save on transmission time.
BTW, thanks for the steak dinner Dale! (you must have told AP circuits I
referred you to them)
--
Jeff King, jeff@aerodata.net on 12/20/2003
----------------------------------------------------------------------
Subject: APRS Tip of the day (Radar)
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 20 Dec 2003 18:56:08 -0500 (EST)
X-Message-Number: 19
Tip of the day.
If you want an alarm when someone you expect arrives in the area, here's
how: (Your client progarm may be somewhat different)
1) Set UPLINKING of objects to off.
2) Put the expected visitor's call on your map somewhere as an object
3) Set an alarm on it.
Now when he arrives in the area, his live posit will overtake the object
with the same call and it will have "moved". The ALARM in APRS will then
sound that that station has moved and you are alerted...
If he was on your map in the first place, but a great distance away, but
you wanted to be alerted when he came into your area, then simply reduce
your RANGE filter to exclude where he is now, but include the area where
you want to be alerted to his arrival.
If he is actually coming right to your door, then you could also turn on
your "radar" alert which will trigger when ANYONE new enters your radar
zone.
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
