Re: APRSIS32 I-gate questions
- Ok, More stuff to digest.
I'll change the xml file tomorrow to what you suggest.. Thanks for finding this problem.
I've got two OT+USB units here. I'll consider trying one of them. I do not have an OT2. I have a total of three 9612s given to me by the tower owner. I plan to make one of them into a digi-peater for a location out in our black hole no coverage area. I will not start on that for at least a month due to other non-ham projects or trips waiting to be done first. The third one is up on the tower now and maybe scrap. I'll find out when it comes down to the ground again.
One other thing I noticed tonight. When I see the same packet multiple times in the RF to IS trace, One showed up three times but the scrolling window that shows all stations showed it as one entry with SSID*3. I can watch it increment in the scrolling window from SSID* to SSID*2 and then SSID*3. This has me thinking that he has already handled the multiple packet issue. I'm just seeing it in the trace log but the duplicate packets may not be actually going out on the Internet. I'd have to fire up my Ethernet packet sniffer on the Ethernet side to prove this one way or the other.
I've got enough to figure out here so I need to separate the important stuff from the not so important stuff.
I looked up definition of "average terrain" for APRS they stated it was an average within 10 mile radius of the station. It not much help since we are covering much greater distances. Heck it is an 11 mile trip just for me to get to town. This whole issue is not really important so why not just forget it for now.
On the message count, I was mostly trying to understand what I am seeing. I'm not looking for any program changes.
I think I understand the range vs. m/xx filter.
Thanks for all the help. We got power back and now my garage door decided to go up on it's own and stick there in the middle of the night. That is the first thing on my list to go fix in the AM. I'm thinking it is the motor starting capacitor. Tomorrow is Sunday so I'll have to wait a day to find another capacitor if that is what I need. I also need to replace a front tire on one of my motorcycles tomorrow.
Thanks again for all of the help.
Ken - N9KB
--- In email@example.com, James Ewen <ve6srv@...> wrote:
> 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
> >> 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.
- 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.