On Tue, Oct 27, 2009 at 11:37 PM, Tom Hayward <[email protected]> wrote: > 2009-10-27 22:25:24 UTC: > W7MCK-9>TWRPXU,BALDI*,WIDE2-2,qAR,KD7DVD:`2^Eo59k/]"5/}Maple Valley > ARES W7MCK Matt= > > That last one is properly handled.
Hmm, I would disagree... Upon handling a WIDE1-1 hop request, the digipeater should insert its call, and then place the used up hop request in the packet with the has-been-digipeated bit set. ie. BALDI,WIDE1* > That's an astute observation. I've already sent Casey an email about > the delayed packets and I believe he reset UI-View and restarted the > TNC remotely. He'll be at the site tomorrow if anything more needs to > be done. I'm not sure if a soft reset clears the delay, or if you have to do a hard reset... observation of packets i-gated through the station will rapidly tell you though. These delays can take a couple weeks to manifest themselves in the KPC-3 hardware. Not running KISS mode keeps the problem from cropping up. > The dupetime is 30 (default?). If you look at my message traffic > today, you'll see that I changed the digipeating rules. Before > 2009-10-27 20:20:10 UTC, the hoplimit was 3, so that's why it was > digipeating WIDE6-3. I changed the settings to quiet BALDI down a bit. > It sits very high above a dense APRS area and doesn't need to be > passing 3-hop packets (WA7-7 is a special case). Yup, abusive users can really show where the problems are... using the declared WIDE2 alias helps, as running WIDE as an alias with a hop limit of 2 would still digipeat WIDE7-2, WIDE6-2, WIDE5-2, WIDE4-2, WIDE3-2, WIDE2-2 and all lower SSIDs. Obviously before the change, you were running WIDE with a hop limit of 3, hence the WIDE6-3 activation. > Another BALDI out there? There's a back-story there. Yup, know the backstory... endured that on the NWAPRS sig. That other machine is supposed to be on another frequency. James VE6SRV
