Re: [aprsisce] Re: APRSIS32 I-gate questions
- On Sat, Jun 4, 2011 at 9:26 PM, Richard Johnson <rjjohn60@...> wrote:
>> Here's what has been posted as working.Okay, you have indicated that you are running a Kantronics KPC-9612,
>> <OpenCmd>XFLOW OFF!!0</OpenCmd>
>> <OpenCmd>FULLDUP ON!!0</OpenCmd>
>> <OpenCmd>INT KISS!!0</OpenCmd>
> That is not exactly what I have. Here is a cut and paste from the actual xml file that I'm using:
> <OpenCmd>XFLOW OFF</OpenCmd>
> <OpenCmd>FULLDUP OFF</OpenCmd>
> <OpenCmd>KISS ON</OpenCmd>
> <CloseCmd>TC 1!TS 1</CloseCmd>
> <CloseCmd>TN 2,0!TN 2,0</CloseCmd>
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 incrementingThat's kind of a subjective statement. What if I want to accumulate
>> > 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.
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 rangeThere is no difference, when you use one, you're using the other. The
>> > 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:
> I still do not understand.
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
>> You're not flying, so height above sea level isn't all that important.We're not flying the digipeater... we are talking about radio propagation.
>> 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.
> Years ago I put up a digi-peater on and Indiana Toll Road tower.But if you did a HAAT calculation, you would have probably noted the
> 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.
higher terrain south of you.
> In the end we could not establish communications south to the restDetermining the HAAT and setting directivity to the north would give
> of the state. Comm north was great except that direction was Lake
> Michigan and we did not have any users out there.
an approximation of the coverage of the digipeater by showing better
range to the north, and shorter range to the south where the hill
> What is wrong is the ambiguity or "average terrain". Average TerrainActually, the average height of the terrain is a fixed number. That's
> is not a fixed number as you move from station to station across
> multiple counties.
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 sameYou're going to have to dig a hole and bury the digipeater.
>> > 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.
> W9AZ-2>BEACON,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.
- Thank you for the great explanation. I have been double clicking on the right vertical bar and watching the numbers.
Ken - N9KB
--- In firstname.lastname@example.org, "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.