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

1063Re: [tracker2] NSR support?

Expand Messages
  • Wes Johnston, AI4PX
    Sep 28, 2006
    • 0 Attachment
      On 9/28/06, Curt, WE7U <archer@...> wrote:
      > This digi-on-distance thing is more general than the earlier idea,
      > so I like this even better! Less maintenance would be required over
      > time for the digi settings.
      >
      > If this could be implemented we'd probably set up our SAR units with
      > a digi range of 5 miles. The only thing required to do this would
      > be a callsign-SSID and perhaps a timestamp, right? Timing-out or
      > driving out of range removes a callsign from the list.

      This is an interesting idea... one of the problems I've encountered
      with my mobile is that there's too much DX to compete with. If the
      folks in my neighboring towns would enforce either path hop limits
      (which seem all too easy to spoof and work around with kpc3 digi's),
      or distance limits, then the noise floor would go down here. The
      newN-N has really done a good job, but there are still stragglers that
      squeak thru with stupid paths.

      The problem with limiting by distance is that some packets are
      positionless.... messages and some weather reports. So yep, the trick
      is to cache a station's position so that their positionless packets
      are whitelisted as Curt aluded to. This may cause some problems with
      internet messaging since (I think??) the message comes out the IGATE
      first, then the position report. Worst case is that the next retry of
      the message gets thru... but in the end, the message from my friend in
      germany doesn't get digipeated even when we know his position b/c he's
      4,000 miles away. Or do we digipeat all packets that are in 3rd party
      format based on the IGATE callsign? Just me brainstorming aloud.

      What about stations (errr idiots) that set their position to 0°N x
      0°W? They don't get digipeated until they fix it.... there'd be a
      learning curve for them.

      The thing I really liked about NSR was that you could present a packet
      to the network with no path and the digi would fill in the path for
      you (that's not quite how NSR worked - I'm paraphrasing a bit). I
      think path substituion for blank paths would be great. We're doing
      that here in my town with javaaprs as a digi. For example, stupid
      paths like W7-7 are "converted" to W2-1. I call a WIDE7-7 path
      stupid, but frankly, I like the idea of sending all you can and the
      digipeater being smart enough to figure out what a reasonable limit
      is. This can be done with hops or with distance....

      In the german packet system, if you run too long of a TXdelay you are
      not permitted to connect. We could do the same for APRS with either
      TXd or paths- send them a message that their path was too long, but
      they'd have to have a tracker that could accept messages. Hmm...
      probably better to just fix the path on the fly if the digi is the
      first to hear it.... no need to fix paths that are 3 hops old.

      What would be neat would be if I could somehow send a message to a
      digi and have it message me back to tell me how many mS I could/should
      trim off my txdelay. Anyone remember the x1j nodes that told you
      TXdeviation?

      if we are to have a reliable network, we have to have the tools to
      control it and limit access, lest it be overwhelmed.

      Wes
    • Show all 10 messages in this topic