Re: [tracker2] Re: Configuring Tracker 2 to drop packets that have had 2 or more hops
- On Tue, September 14, 2010 11:17 pm, James Ewen wrote:
> On Tue, Sep 14, 2010 at 7:01 AM, William <yahoo-mail@...>Not at all. What I am saying is that the terrain in East Tennessee makes
>> The digi's in East Tennessee typically have a HUGE coverage area
>> because of our mountainous terrain. Without restricting what they digi
>> on, we frequently see packets from hundreds of miles away
> So you are basically telling us that the East Tennessee digipeaters
> are positioned poorly, and the operation of the network is being
> misconfigured in order to make up for poor digipeater placement.
things a little different and we have modified our network infrastructure to
deal with these differences as best we can.
> IfAgain, the terrain in our area makes this difficult. If we lower the digi's,
> the digipeaters are hearing traffic from too far afield, then they
> need to be relocated lower down where they support the local users,
> and not be overwhelmed by long distance packets.
then we end up with huge coverage gaps. To lower the digi's, as you suggest,
while maintaining reasonable coverage would require a huge number of digi to
be added to the system.
> By ignoring packetsTrue - partially. The out of area packets are weaker than the local packets
> from far away, you don't add to the problem by forwarding the packets
> again, and for the users in the valleys, it MIGHT appear that things
> are quieter. In reality your digipeaters are still being pelted by the
> same packets from far away, and your local users still have to fight
> to get the attention of the mountaintop digipeater over the cacophony
> of noise heard up there.
(most of the time). By dropping the out of area packets, we eliminate their
clutter on our network.
> Bring them down lower where they don't getWe have looked at this extensively. You can see what is seen at my home
> inundated by packets from remote areas, and provide quality support
> for your local users.
> Obviously easier said than done, but if you want to truly fix the
> problem and not just mask the symptoms, it needs to be done.
>> The other TNCs in the area are Kantronics KPC3+; we have them configured
>> with something like this:
>> UIDIGI ON TN,WIDE1-1,WIDE2-2
>> UITRACE TN,30
>> UIFLOOD TEMP,30,ID
> Have you looked to see how this works? UIDIGI does a simple callsign
> replacement, so it would be difficult to inspect the packets as they
> traverse the network. Your settings will work, but far differently
> than any other part of the APRS network.
The "Packets this hour" and "Packets Today" show you data from my home
station, so you can begin to get an idea there.
>It does, in fact, work well for us and is the only practical option available.
>> We did extensive testing to arrive at this configuration; we have
>> found that for day-to-day operations, it works very well and has
>> dramatically reduced the number of out-of-state packets hear in
>> our area and has greatly improved the reliability of our local network.
> Masking systemic problems by misconfiguring the digipeaters... if it
> works for you.
>We currently have it working almost as we want it to, but have not managed to
>> Can this configuration be achieved with the OT2?
> Yes, the OT2 is flexible enough to even be bent into this type of operation.
set it up to digi on WIDE2-2 but not WIDE2-1.