| |
ZL3AI > APRDIG 29.09.03 18:10l 274 Lines 10907 Bytes #999 (0) @ WW
BID : 2019-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 26, 4/7
Path: DB0FHN<DB0RGB<OE5XBL<OE2XOM<DB0PV<DB0MRW<DB0ERF<DB0FBB<DB0GOS<ON0AR<
ON0AR<ZL2BAU<ZL3VML
Sent: 030928/1952Z @:ZL3VML.#80.NZL.OC #:9241 [Chch-NZ] FBB7.00i $:2019-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: "Spider" <spider@rivcom.net>
Date: Fri, 26 Sep 2003 11:12:59 -0700
X-Message-Number: 18
From: "Dave VanHorn" <dvanhorn@cedar.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Friday, September 26, 2003 10:48 AM
Subject: [aprssig] Re: Part 2/2 -Re: Take Control - oh let's just go
backwards
>>Dupe, dupe, dupe. The same packet repeated by the same digi multiple times
>>is a dupe. If the content hasn't changed then why repeat it?
Because it's suppose to be 'real-time'? A packet that is transmitted at
00:15 hrs that is re-transmitted at 00:20 hrs is NOT a dupe and was
transmitted with the design of being seen. The fact that it has the same
exact content means nothing!
I am not sold on the 29 minute filter as being a good thing at all.
Jim
WA6OFT
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 26 Sep 2003 11:16:07 -0700
X-Message-Number: 19
I can do that sometimes, but only wearing a ghille suit. The effect would
be a lot more useful if paintball guns had an effective range of more than
about 40 feet. It's a bit like trying to be a sniper with a snub-nosed .38.
=]
I still think we need to look at making digis the keepers of the local
network state - have them transmit a burst periodically of all stationary
stations they know about. As long as the stations hear themselves, they'd
hold off transmitting except for a much longer keep-alive interval that'd
let the digi know they're still there. You could reduce network cycle times
down to 3 or 5 minutes for fixed assets while reducing collisions, since the
digi's less prone to hidden transmitter problems and you're only wasting one
TXD interval. 1200 baud actually gets you a fair amount of data if you can
get it out in big enough bursts.
Scott
N!VG
----- Original Message -----
From: "Dave VanHorn" <dvanhorn@cedar.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Friday, September 26, 2003 10:48 AM
Subject: [aprssig] Re: Part 2/2 -Re: Take Control - oh let's just go
backwards
>So if I'm sitting still, I disappear?
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: Steve Jones <s.jones@rogers.com>
Date: Fri, 26 Sep 2003 14:31:56 -0400
X-Message-Number: 20
on 9/26/03 2:12 PM, Spider at spider@rivcom.net wrote:
>Because it's suppose to be 'real-time'? A packet that is transmitted at
>00:15 hrs that is re-transmitted at 00:20 hrs is NOT a dupe and was
>transmitted with the design of being seen. The fact that it has the same
>exact content means nothing!
>I am not sold on the 29 minute filter as being a good thing at all.
Guys, you've missed the point of my message.
I did not say I'm using a 29 minute filter. That was somebody else. I
believe mine is set to 30 seconds.
If digi A sends the packet out as "relay,wide3-3", and digi B sends it out
as "relay, wide3-2", then why should digi A repeat it as "relay,wide3-1"?
The content hasn't changed and the originator hasn't sent another packet.
Why were we all told to avoid WIDE,WIDE,WIDE? To avoid dupes generated when
the first digi hears the second digi repeat the packet. This is all the 30
second filter is doing. It avoids unnecessarily repeating the same packet
it has already digi'd.
If you are beaconing while sitting still at a rate less then 30 seconds,
then I question why.
--
Steve <s.jones@rogers.com>
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Fri, 26 Sep 2003 13:39:52 -0500
X-Message-Number: 21
>If dupe checking is set to 30 seconds, it takes care of most dupes generated
>by the digi's as the WIDEN-N decrements down. If you are standing still and
>beaconing any faster then 30 seconds then yes, the digi will ignore you.
>Not sure how many people have their beacon rate set as low as 30 seconds
>when standing still?
That's fine by me.. Someone was talking 30 minutes..
Maybe that was a typo?
>Of course, some digi owners could set their dupe checking even higher to
>knock out people who continuously beacon while standing still. Nothing's
>worse then a mobile parked for the weekend beaconing every 30 seconds.
Every 15 seconds? :)
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: wes@johnston.net
Date: Fri, 26 Sep 2003 15:21:52 -0400 (EDT)
X-Message-Number: 22
I liked Henk's suggestion of setting the dupe timer to a long time.... he
suggested 30 minutes, but our network time is 10 minutes, so set the timer
for 9 and 1/2 minutes. That would certainly slow down repeatative beacons.
Wes
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: wes@johnston.net
Date: Fri, 26 Sep 2003 15:26:06 -0400 (EDT)
X-Message-Number: 23
We could kinda do that with a 555 timer on teh XCD pin. Hold it low for 15
seconds, the drop it for 1 second to let the TNC TX it's buffered packets.
I know what you are saying though.... buffer the stationary posits while
letting the mobiles' posits get thru right away. Will have to think about
how to accomplish this....
Wes
----------------------------------------------------------------------
Subject: Next generation APRS mapping idea
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 27 Sep 2003 06:57:33 +1000
X-Message-Number: 24
Why not include an aprs packet that contains a little slice of your map
area.
Idea being - the longer you leave your aprs on, the more of maps you
collect.
You pc would build up the maps and keep them
I am thinking vector maps.
Maybe you could configure it that you only want to get bits that are x
kms/miles from you.
start,stop,color,width, pixel ?
VK4TEC>APRS,RELAY,WIDE*:<MAP SYMBOL> 27.3444S/152.5206E,27.4444S/152.6206E,2
id draw a line from 27.3444S/152.5206E to 27.4444S/152.6206E width =2
thinking out aloud
Andrew VK4TEC
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: Roger Grady <k9opo@comteck.com>
Date: Fri, 26 Sep 2003 16:26:59 -0500
X-Message-Number: 25
At 01:39 PM 9/26/03 -0500, Dave VanHorn wrote:
>>If dupe checking is set to 30 seconds, it takes care of most dupes generated
>>by the digi's as the WIDEN-N decrements down. If you are standing still and
>>beaconing any faster then 30 seconds then yes, the digi will ignore you.
>>Not sure how many people have their beacon rate set as low as 30 seconds
>>when standing still?
>
>That's fine by me.. Someone was talking 30 minutes..
>Maybe that was a typo?
That was Henk and I think he meant 30 minutes. The context was for home
stations whose data doesn't change. Why should they be allowed to generate
as much data on the network as a moving station when every packet is the
same? By using a 30 minute dupe period, a fixed station will not get digi'd
more than once every 30 minutes. A moving station, whose packet changes
every time, will not be seen as a dupe and will get digi'd.
Roger Grady K9OPO
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Fri, 26 Sep 2003 16:46:56 -0500
X-Message-Number: 26
>That was Henk and I think he meant 30 minutes. The context was for home
>stations whose data doesn't change. Why should they be allowed to generate
>as much data on the network as a moving station when every packet is the
>same? By using a 30 minute dupe period, a fixed station will not get digi'd
>more than once every 30 minutes. A moving station, whose packet changes
>every time, will not be seen as a dupe and will get digi'd.
I seem to remember someone saying that you should see everyone in your area
within 15 minutes.
Bob somebody, I think..
Not a good solution.
The uneducated user will think he needs to beacon more, or is doing
something else wrong, when he doesn't get digi'd.
You're failing him, without any indication what's wrong.
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Fri, 26 Sep 2003 22:37:57 +0200
X-Message-Number: 27
Hello Spider,
At 06:00 26-9-03 -0700, Spider wrote:
>Please explain this more! How does setting a 29 minute dupe check fix a
>problem that occurs within 30 seconds over xx% of time?
>If you log packets, you see bursts of packets from stations that have
>reasonable settings.from the various digi's that are local. I have three
>digi's that are very close
>and for 1 packet someone sends, I might see 6 (not really counting). They
>occur within 30 seconds of each other! So please explain how a 29 minute
>dupe checker is going to solve this, please!
Of course the first time the data is aired you will get copies of the data
from each digipeater. With dupe checking you should however see only one
copy from each digipeater. The first time the packet is send it is new to
all the digis and the load will be the same. So it doesn't solve anything
the first time. But it will save you the next time!
Assume all digis whould have this 29 minute dupe check. If the station
sends the same data once again then this time the data will be ignored by
all of them and this pile up of packets will not occur. So if this is a
parked car sending the same position over and over with a 1 minute rate you
will only see it once every 30 minutes. So it should stay pritty silent on
packets that have been send before - i.e. if they are from the same station
and carry the same data.
As noted any reasonable dupe checking by W8MWO would have saved a number of
copies, it looks like this digi doesn't do any dupe checking at all on the
WIDE call. I don't know how Kantronics implemented their TNC solution but
DIGI_NED does dupe checking on all packets, regardless if RELAY, WIDE or
TRACE or the "intelligent" WIDEn-N or TRACEn-N calls are used in the path
(or any other call you may have configured using the rules file). DIGI_NED
just checks reception if the packet has been handled already and if yes it
just doesn't digipeat it.
So it doesn't save you the first time but it saves a lot of load if the
packet is repeated.
Kind regards,
Henk.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
