Loading ...
Sorry, an error occurred while loading the content.
 

Re: [tracker2] New feature for the OT2

Expand Messages
  • James Ewen
    ... Uh... ummm... errr... That s a MANLY kinda love, right? Not that there s anything wrong with the other kind/being
    Message 1 of 7 , May 4, 2007
      On 5/4/07, Jason Rausch <lists@...> wrote:

      > Joking with love 73's

      Uh... ummm... errr... That's a MANLY kinda love, right?
      <insert lots of Tool Time grunting here>

      Not that there's anything wrong with the other kind/being politically
      correct 73's

      James
      VE6SRV
    • Keri Morgret
      Is THIS what I paid good money to go to Dayton for? Scott didn t tell me about this type of love at the booth.. Keri N6TME
      Message 2 of 7 , May 4, 2007
        Is THIS what I paid good money to go to Dayton for? Scott didn't tell
        me about this type of love at the booth..

        Keri
        N6TME

        At 09:48 PM 5/4/2007, James Ewen wrote:
        >On 5/4/07, Jason Rausch <lists@...> wrote:
        >
        > > Joking with love 73's
        >
        >Uh... ummm... errr... That's a MANLY kinda love, right?
        ><insert lots of Tool Time grunting here>
        >
        >Not that there's anything wrong with the other kind/being politically
        >correct 73's
        >
        >James
        >VE6SRV
      • 'Scott Miller'
        It could certainly be done. It already keeps a total count of digi d packets. It d take a little more work to make it a 10-minute count, and to have it
        Message 3 of 7 , May 8, 2007
          It could certainly be done.  It already keeps a total count of digi'd packets. It'd take a little more work to make it a 10-minute count, and to have it announce the load automatically.
           
          Scott


          From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of James Ewen
          Sent: Friday, May 04, 2007 8:01 PM
          To: tracker2@yahoogroups.com
          Subject: [tracker2] New feature for the OT2

          I just answered a recurring question for the umpteenth time on the
          NWAPRS reflector... How come I see delayed packets.

          My theory that I am sticking with is channel overloading. I run
          UI-Traffic on my home station with UI-View. It allows me to graph the
          traffic that I see at my station. It also sends out an object beacon
          every 10 minutes with the latest channel loading, like this:

          VE6SRV-1>APU25N, TCPIP*,qAC, T2MONTANA: ;SRV
          *040259z5331. 31N\11317. 42W?28 In 10 Minutes

          I keep trying to convice people that even if it is quiet in the
          valley, the channel may be overloaded up at the digipeater. Packets
          that have the hops all used up still get heard at the digipeater, they
          just don't get acted upon. They still use up local air time.

          So I was thinking, maybe I could put a computer up at the digipeater,
          and have the OT2 send the packets to the computer which would be able
          to graph the activity. But then I thought, most people wouldn't want
          to have a computer at the digi, nor would they have internet access
          there. Hmm, what about having the digipeater keep track of the number
          of packets heard, and report that the same as UI-Traffic does. Even
          beyond that it could report packets heard, and packets digipeated.
          This would inform people of how many packets are being heard versus
          the number that get digipeated. It's quite possible to have 30 packets
          heard per minute, but only 10 of those digipeated because the other 20
          had used up paths. To users in the valley below, the channel load
          appears to only be 33% of what the digipeater is hearing.

          This would be a useful tool to teach people that putting digipeaters
          on the absolute highest point around is not such a good thing in high
          use areas. Highly congested areas need to pull the high digis down and
          create more smaller coverage area digis to allow for the higher user
          density.

          To implement something like this would only take a couple variables,
          one to keep a 10 minute timer, one to keep track of the number of
          packets heard, and a final one to keep track of the number of packets
          digipeated. You'd also need a command line switch to enable/disable
          sending the report out. Obviously some people would not want the
          report, and some would. The reporting could be turned on occasionally
          to assess traffic loading, and turned off again later.

          The report could be something along the lines of
          SRV *040259z5331. 31N\11317. 42W?34 of 56 in 10 minutes

          BTW Scott, I'll be at Dayton, and I have a whole sack full of whacky
          ideas I want to throw at you including multiple outgoing path
          settings, and geodigipeating.

          James
          VE6SRV

        • James Ewen
          ... I agree that keeping track of the total number of packets versus number of packets in the last 10 minutes is a bit more of a challenge. The annoucement
          Message 4 of 7 , May 8, 2007
            On 5/8/07, Scott Miller <scott@...> wrote:

            > It could certainly be done. It already keeps a total count of digi'd packets.
            > It'd take a little more work to make it a 10-minute count, and to have it
            > announce the load automatically.

            I agree that keeping track of the total number of packets versus
            number of packets in the last 10 minutes is a bit more of a challenge.
            The annoucement portion is similar to a status beacon, you just grab
            the appropriate values out of the variables and stuff them into the
            string.

            Another concept that I would like to see in the OT is the concept of
            multiple outgoing paths. This allows us to send position reports
            varying distances. Bob uses a concept that I developed a few years ago
            and showed him. He tossed it aside, but now he has reintroduced the
            concept, and calls it proportional pathing.

            In the APRS world, local objects are of more importance than distant
            objects. Things that are happening closer to us are of more interest
            than things happening far away. Also, things that are happening
            currently are of more importance than things that happened in the
            past. To implement these concepts we want to set up our trackers to
            report current information to those close to us at a reasonably rapid
            rate, while keeping those further away updated at a slower rate. We
            also want to update changing information as soon as it happens, but
            report static information at a slower rate.

            By using multiple length paths, you can send more packets out to those
            close by, while still sending packets out a couple hops as well. We
            use this concept with the 4 LTP settings in the Kantronics line to
            send packets out locally every 10 minutes, out a little further every
            30 minutes, and the longest distance packets every hour.

            In Byon's TinyTrak, you can make this happen using the alternate digi
            paths option. If you set one path to WIDE2-1, and the second to
            WIDE2-2, you can keep people nearby updated in a timely fashion, but
            effectively decrease the load you are creating on neighboring
            digipeaters by 1/2. Having 3 or 4 alternate digi paths can allow even
            better optimization of your channel load. With 4 paths, I can set up
            paths such as: local, WIDE2-1, local, WIDE2-2 (where local is no
            path). If I beacon every 60 seconds, those within simplex range see me
            every minute. Those within one hop see me every 2 minutes, and those
            within 2 hops see me every 4 minutes. This also works with
            SmartBeaconing (tm), just the timing is obviously different. Also,
            with 4 digi paths we can set up the OT2 in digipeater mode with a
            proportional pathing solution like the KPC-3 settings Bob suggests.

            You'll find that people are interested in letting others know where
            they are by beaconing quite often. They also want to tell people for
            miles around where they are. Lots of beacons going out over a long
            path causes network congestion. Alternate digi paths allow people to
            beacon at a rapid rate, and also get their position reports out over a
            long path. Close in the rate is rapid, but the further you go away,
            the slower the effective beacon rate. This type of operation keeps
            everyone happy.

            I told you I had some ideas I wanted to toss at you. There's still more!

            James
            VE6SRV
          Your message has been successfully submitted and would be delivered to recipients shortly.