It is not a good idea for a digipeater to delay a packet by 15 seconds. This topic has been deeply discussed for many years. We have enough delays imposed by digipeater/IGate owners who are unaware of their own mis-configurations. A WIDE1-1 does not hear everything and a mobile station may hit a WIDEN-n that the WIDE1-1 does not hear. Delaying a packet can cause a ping pong effect on the APRS-IS as well as rob RF network bandwidth. This problem is bigger than you may realize.
Currently, there are several issues we are trying to educate users in our outlaying area. Some packets are delayed by 2-3 minutes at some digipeaters and I-Gates. What happens on the APRS-IS stream is the initial packet is heard and then 15 seconds, 30 seconds, or even 2-3 minutes later that same packet finally makes it through another path to the same IGate that initially passed it or another distance IGate. In a busy APRS network the problem is compounded. What you see happen on a map is a stations position bouncing back and forth. It also takes up addition RF and Internet bandwidth. The APRS Paradigm changes from 2005 stopped a lot of ping pong effect by eliminating RELAY an WIDE support because some TNC's could not substitute their own callsign to know they had already digipeated the packet. Adding a packet delay because a station does not think a signal was digipeated can in effect produce some of the same ping pong problems. If 2 digipeaters impose a 15 second delay the cumulative delay can then become a little over 30 seconds depending on the amount of traffic in an area and defeat the dupe timer in many digipeater settings. We see this type of ping pong packet activity every day, so please do not do this. If the station sending the signal wanted a WIDE1-1 to handle their packet they would have put it in their path. It is the sending stations decision on how they choose to route their packet. The first way I notice the problem is when I see a distance IGate constantly IGating a packet from our local network instead of our local IGate according to FINDU. When we query the FINDU server to pull a history of time stamped data, the problem can almost always be attributed to delays at digipeaters and/or IGates. When we alert the digipeater/IGate owner about the issue and they are usually unaware of it. In some cases the IGate operators actually think their IGate system is faster at moving the traffic to the APRS-IS because the basic FINDU screen shows their IGate posting the traffic. When you query FINDU to review the data, the answer becomes very clear. It is not faster, but it is much slower due to delays. 73's, Tim - N8DEU ----- Original Message ----- From: "Scott Miller" <[email protected]> To: <[email protected]> Sent: Wednesday, June 09, 2010 10:06 PM Subject: Re: [tracker2] "Smart" Fill-in Digipeter > This is on my to-do list, and it's been debated on the APRSSIG a bit. > Some people think it's a bad idea, I think it could certainly work in > some circumstances and I'm inclined to implement it and let people try > it out. > > Scott > > Jonathan Scott Weirmeir wrote: >> >> >> Is it possible to create a "smart" fill-in digipeter that will pass >> any WIDEn-n packets, but only if a high-profile local digipeter >> doesn't digi it, regardless of being set up as alias WIDE1? >> >> It'd work something like this: >> >> 1) A mobile user sends out something WIDE2-2 >> 2) The Tracker2 hears this packet >> 3) The Tracker2 doesn't hear anyone else digi the packet within, say, 15 >> seconds >> 4) The Tracker2 assumes the packet wasn't digipeted, so it repeats it, >> even though the Tracker2 is alias WIDE1. >> >> Can this be done? >> >> 73 DE KC8RYW >> >> > > > > ------------------------------------ > > Yahoo! Groups Links > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/tracker2/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/tracker2/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
