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

Re: [tracker2] Proposed feature

Expand Messages
  • James Ewen
    One thing that Scott s ASSIST will do that the YIELD digi won t do though is to grab packets for your HT, and resend it to the local area. The main digi will
    Message 1 of 4 , Dec 13, 2006
    • 0 Attachment
       
      One thing that Scott's ASSIST will do that the YIELD digi won't do though is to grab packets for your HT, and resend it to the local area. The main digi will obviously handle the packet, making the YIELD digi ignore the packet, but you are still wanting the packet handled locally to get it from the mobile to the HT.
       
      The YIELD digi is a good idea, I've done the mental exercise of running through the concepts as well. Probably the ideal concept is a combination of the two. YIELD would work for outgoing packets, and creating an ad-hoc network. ASSIST would be best to extend a network into an area of desired coverage.
       
      As far as stopping packets from too far afield, I went through the concept a number of years ago. It was a concept called geographic digipeating. My proposal was to have the digipeater keep a list of the closest stations. The number of stations allowed would be user selectable, or calculated by the digipeater based on channel capacity. The list would need to keep track of callsign, distance and age for each station in the list. Any stations asking for a digipeat beyond the range of the last station in the list would be ignored. This concept allows for full digipeating as requested by the user, until the maximum channel capacity is approached. At that point, the digipeater starts ignoring the stations that are further afield in favour of those that are closer.
       
      In an area with little activity, you may be able to see stations that are far out of your local area if they are using long paths. In an area of high activity, the local stations get priority access simply due to proximity to the digipeater.
       
      This sticks to the basic concepts of APRS, being that it is a local area tactical tool, and that items that are closer to the user are of more importance.
       
      I flew the concept past Bob at one of our face to face meetings a few years ago. Bob was not receptive to the concept. He felt that it would hinder the ability of a user to send a packet to the desired destination. However, channel congestion would be doing that anyway, and also killing the ability of the local users to be able to access the network.
       
      I find Bob takes a while to pick up on concepts, as he has an idea of how he'd like things done, and there's not much outside that concept. The beacon timing that Bob is now promoting was a concept I pitched to him many years ago, that fell on the floor. I designed the timing and distance for the Bogus Basin digi near Boise, and that has been in place for a long time now. It's nice to see the concept being used. It sure helps relieve congestion, while still letting people see what's out there for infrastructure.
       
      James
      VE6SRV
    Your message has been successfully submitted and would be delivered to recipients shortly.