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

Re: [aprsisce] Re: APRSIS32 I-gate questions

Expand Messages
  • James Ewen
    ... Okay, you have indicated that you are running a Kantronics KPC-9612, but the commands you are using are for a Kenwood radio. XFLOW OFF turns off software
    Message 1 of 34 , Jun 4, 2011
      On Sat, Jun 4, 2011 at 9:26 PM, Richard Johnson <rjjohn60@...> wrote:

      >> Here's what has been posted as working.
      >>
      >> <OpenCmd>^M~</OpenCmd>
      >> <OpenCmd>^M~</OpenCmd>
      >> <OpenCmd>XFLOW OFF!!0</OpenCmd>
      >> <OpenCmd>FULLDUP ON!!0</OpenCmd>
      >> <OpenCmd>INT KISS!!0</OpenCmd>
      >> <OpenCmd>RESET!!0</OpenCmd>
      >> <CloseCmd>^192^255^192~!!0</CloseCmd>
      >> <CloseCmd>^C^C^C~!!0</CloseCmd>
      >
      >
      > That is not exactly what I have.  Here is a cut and paste from the actual xml file that I'm using:
      >
      >  <OpenCmd>^M~</OpenCmd>
      >  <OpenCmd>^M~</OpenCmd>
      >  <OpenCmd>XFLOW OFF</OpenCmd>
      >  <OpenCmd>FULLDUP OFF</OpenCmd>
      >  <OpenCmd>KISS ON</OpenCmd>
      >  <OpenCmd>RESTART!!0</OpenCmd>
      >  <CloseCmd>^192^255^192~!!0</CloseCmd>
      >  <CloseCmd>^C^C^C~!!0</CloseCmd>
      >  <CloseCmd>TC 1!TS 1</CloseCmd>
      >  <CloseCmd>TN 2,0!TN 2,0</CloseCmd>

      Okay, you have indicated that you are running a Kantronics KPC-9612,
      but the commands you are using are for a Kenwood radio.

      XFLOW OFF turns off software flow control... you won't need flow control.
      FULLDUP ON will make the unit ignore carrier detect, which is wanted
      for a digipeater.
      INT KISS is the command that the KPC-9612 understands to enable KISS mode.
      RESET resets the TNC, and starts KISS mode.

      KISS ON is the command the Kenwood units understand to enable KISS mode.
      RESTART is also a Kenwood command.
      TC 1!TS 1 and TN 2,0!TN2,0 are very much Kenwood commands, a dead
      giveaway that the open and close commands are not right for a KPC.


      >> > What bothers me most is the first number MSG_CNT appears to be incrementing
      >> > from hour to hour while the rest of the numbers seem to be  hourly totals that
      >> > reset to 0 at the start of the next 60 minutes after the beacon is sent.
      >>
      >> Well, get used to being bothered I guess... just wondering, what's so
      >> upsetting about this?
      >
      > If this number does not reset to Zero every hour and the others do,
      > then the number does not reflect anything usable.  This thing will sit
      > up there for months accumulating something has no useful meaning.

      That's kind of a subjective statement. What if I want to accumulate
      the total number of packets heard for a period longer than an hour?
      The hourly reset means that my desired numbers are lost, so that has
      no useful meaning to me. The numbers are what you get from Lynn. That
      doesn't mean that they will never change though. We just need to
      explain to Lynn what we want, and if we do a good enough job, Lynn
      might make a change.

      >> > 4.  I do not understand the difference between setting the range
      >> > and using a filter of like m/50.  When do I use one or the other?
      >>
      >> Range, as in the Configure | General setting in the UI versus m/50 in
      >> an APRS-IS filter?
      >>
      >> Setting a range value in the Configure | General dialog will set the
      >> value that APRSISCE/32 configures automatically for you. See:
      >> http://aprsisce.wikidot.com/automatic-filters
      >
      > I still do not understand.

      There is no difference, when you use one, you're using the other. The
      UI value that you set in Configure | General IS the value that is in
      the m/xxx APRS-IS filter. You're looking at the fancy user value, as
      well as the nitty gritty behind the scenes stored value for the same
      thing.


      >> You're not flying, so height above sea level isn't all that important.
      >> Height above ground is more relevant, and as far as APRS is concerned
      >> the more relevant height is height above average terrain. This allows
      >> for calculation of an approximate radio range. Use the PHG button on
      >> the Configure | General page to set your PowerHeightGain values. Set
      >> them to the closest values available (9 watts, 320 feet plus the gain
      >> and directivity) for your station.
      >
      > I disagree on this and I'm also a pilot.  Height above average terrain is also
      > a meaningless number.  Because the terrain is constantly changing.

      We're not flying the digipeater... we are talking about radio propagation.

      > Years ago I put up a digi-peater on and Indiana Toll Road tower.
      > We went up 180 feet.  What we failed to realize was we had terrain just
      > 5 miles south of there that was 200 feet higher.

      But if you did a HAAT calculation, you would have probably noted the
      higher terrain south of you.

      > In the end we could not establish communications south to the rest
      > of the state.   Comm north was great except that direction was Lake
      > Michigan and we did not have any users out there.

      Determining the HAAT and setting directivity to the north would give
      an approximation of the coverage of the digipeater by showing better
      range to the north, and shorter range to the south where the hill
      blocks propagation.

      > What is wrong is the ambiguity or "average terrain".   Average Terrain
      > is not a fixed number as you move from station to station across
      > multiple counties.

      Actually, the average height of the terrain is a fixed number. That's
      what average means. Take all the measured heights, and average them to
      find the average height of the terrain over the area. Does it give the
      exact height of the terrain at every single point in the area? No...
      it is the average, not the actual height.

      For APRS and the generalized propagation reporting available, HAAT is
      quite fine for the concept. There is no facility for reporting every
      square inch of radio coverage in the APRS protocol.


      >> > 8.  Another strange thing I'm seeing is my I-gate is sending the same
      >> > packet from RF to IS more than once.  This happens when the packet
      >> > is seen coming from two different digipeaters.  How do I set this so
      >> > only one of the packets is forwarded?
      >>
      >> Can you provided copies of the packets being gated multiple times?
      >> I've had a quick look at the stations heard and gated but don't see
      >> multiple copies gated by your station. Now if you are talking about
      >> seeing packets being heard multiple times at your station via
      >> different routes, that is normal operation. You will hear multiple
      >> copies via different routes if your digipeater is part of an APRS
      >> network where you can hear neighboring digipeaters. Duplicate
      >> filtering will cause only the first copy to be forwarded to the
      >> APRS-IS stream.
      >
      > Here is some recent I-gate traffic on this station in test at my home:
      >
      > Note that some traffic get's I-gated 2 or 3 time for the same packet.
      > This is at 65 feet AGL (my test site).  What happens when I to to 350 feet AGL on the tower.

      You're going to have to dig a hole and bury the digipeater.

      > W9AZ-2>BEACON,WIDE2-1,qAR,KB9KRI:
      > W9AZ-2>BEACON,W9AZ-1*,WIDE2*,qAR,KB9KRI:

      > WD9EPF>APRS,WIDE2-2,qAR,KB9KRI:
      > WD9EPF>APRS,W9AZ-2*,WIDE2-1,qAR,KB9KRI:

      I've removed the payload as it is not germane to the discussion.

      An APRS network consists of digipeaters that are arranged such that
      they can hear their neighbors. They are situated such that a packet
      sent by a user gets picked up by a digipeater, and passed on to the
      next digipeater(s) in the network. Digipeater overlap means that some
      user stations can be heard by one or more digipeaters.

      What you are seeing above is the initial packet in each case being
      heard directly by your station. The second copy is after the packet
      has been handled by another digipeater.

      The only way that you can ensure that you only see a single copy of
      any packet is to place your digipeater/i-gate in a location where
      there are no other digipeaters around. When you are part of a network,
      you ARE going to see copies of the packets.

      I see in your next email that you are running only an i-gate, with no
      digipeating... Putting it up as a digipeater and i-gating at home
      isn't an option then...

      If you lose communication to the TNC and it is in KISS mode, I guess
      the only option with this hardware is to pay the climber.

      How about using different hardware?

      The Argent Data Systems OT2M is an option. It will run in KISS mode,
      and you can also send APRS messages to it with commands embedded to
      control it should it go wonky on you.

      https://www.argentdata.com/products/tracker2.html

      James
      VE6SRV
    • Richard Johnson
      Thank you for the great explanation. I have been double clicking on the right vertical bar and watching the numbers. Ken - N9KB
      Message 34 of 34 , Jun 17, 2011
        Thank you for the great explanation. I have been double clicking on the right vertical bar and watching the numbers.

        Ken - N9KB

        --- In aprsisce@yahoogroups.com, "Lynn W Deffenbaugh (Mr)" <kj4erj@...> wrote:
        >
        > On 6/4/2011 5:37 AM, Richard Johnson wrote:
        > > 3. When I look the contents of the beacon APRSIS32 sent out once an hour I see:
        > >
        > > <IGATE,MSG_CNT=62,LOC_CNT=32,DIR_CNT=11,RF_CNT=57,DX=1*KA9SCF-15(64mi@308<
        > >
        > > Would someone please explain the fields above? What bothers me most is the first number MSG_CNT appears to be incrementing from hour to hour while the rest of the numbers seem to be an hourly totals that reset to 0 at the start of the next 60 minutes after the beacon is sent. If you want to see this live go to KB9KRI on aprs.fi and display the packets.
        >
        > You are correct in your observation that the MSG_CNT increases over
        > time. This is the count of messages that have been gated from IS to RF
        > by the IGate function of APRSISCE/32. This only resets when the client
        > is restarted.
        >
        > LOC_CNT is the count of stations currently considered "recently" "local"
        > for the purposes of gating messages from IS to RF. This is currently 2
        > used hops and 30 minutes which parameters can be seen by double-clicking
        > the vertical bar just to the right of the map (see below for an
        > example). DIR_CNT is the count of stations recently heard direct on RF
        > (no hops used). RF_CNT is new to APRSISCE/32 and is the count of
        > stations recently heard on RF, regardless of the hop count. The
        > DX=n*callsign(dist@deg) is the furtherest station heard via RF in the
        > most recent clock hour (currently, this may change). N is how many
        > packets were heard from callsign which is distance at degrees. If the
        > station is mobile, the count will probably be just one. In fact, most of
        > my DX stats are just one packet from the distant station.
        >
        > So, where you thought they seem to be hourly totals, they are in fact,
        > instantaneous counters where stations will be counted if they've been
        > "recently" heard (like in the past 30 minutes).
        >
        > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
        >
        > PS. Here's my Close Stations popup information when I was writing this
        > e-mail. It'd be LOC_CNT of 50, DIR_CNT of 14, and RF_CNT of 76.
        > "Recent" is 30 minutes and "local" is 2 used hops.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.