APRSIS entries in aprx-rf.log

[Michael Pittaro]

I'm setting up an APRS digipeater to igate ISS traffic, and looking at
my aprx-rf.log, I'm wondering what the entries from 'APRSIS' mean.

This station is currently listening to traffic to / from the ISS on
145.825 MHz.
Most traffic has I hear has probably been digipeated by the ISS,
little or none is terrestrial traffic. There is pure packet data here
as well as APRS data,

There is a longer log at
https://gist.github.com/lhrc-mikeyp/5b8961438de53c034e0b#file-aprx-rf-log

Here's a typical example over a couple of ISS passes:

2015-04-13 00:10:22.662 KJ6VCP-2 R
KR6E>CQ,RS0ISS*:=3426.15N/11827.30Wr reports to: kr...@sbcglobal.net
{UISS53}
2015-04-13 00:10:28.010 KJ6VCP-2 R N7HQB>CQ,RS0ISS*,DN40AD:CONV
2015-04-13 00:10:37.938 KJ6VCP-2 R
KR6E>CQ,RS0ISS*:=3426.15N/11827.30Wr reports to: kr...@sbcglobal.net
{UISS53}
2015-04-13 00:10:42.618 KJ6VCP-2 R
KR6E>CQ,RS0ISS*:=3426.15N/11827.30Wr reports to: kr...@sbcglobal.net
{UISS53}
2015-04-13 00:10:57.163 APRSIS R
AI6GS-6>CQ,RS0ISS*,qAS,KG6HSQ-2::KR6E :Hello
2015-04-13 00:11:09.343 APRSIS R
AI6GS-6>CQ,RS0ISS*,qAR,WA7GJZ::KR6E :QSL?
2015-04-13 00:11:57.303 KJ6VCP-2 R KR6E>CQ,RS0ISS*:nice qso
2015-04-13 00:12:06.592 APRSIS R
N7HQB>APU25N,TCPIP*,qAC,T2HAM:>130001z/nano...@gmail.com
2015-04-13 00:12:16.729 APRSIS R
N7HQB>APU25N,TCPIP*,qAC,T2HAM:<IGATE,MSG_CNT=0,LOC_CNT=0
2015-04-14 00:53:15.388 KJ6VCP-2 R RS0ISS>CQ:>ARISS - International
Space Station
2015-04-14 00:53:47.604 KJ6VCP-2 R
K6VUG>CQ,RS0ISS*:=3733.45N\12157.30W-73' via ISS {UISS53}
2015-04-14 00:53:49.187 KJ6VCP-2 R K6PKL>CQ,RS0ISS*:>142322zUI-View32 V2.03

KJ6VCP-2 is my station, so those entries make sense. However, I don't
understand why I see entries from APRSIS - what does this mean ?

As best I can tell, those entries only appear when the ISS is overhead
(although I haven't verified that totally.) So, I _think_ they're
being received by the radio.

mike

[Kenneth Finnegan]

I-gates have two packet interfaces, your RF transceiver and a second
which is your uplink to the APRS-IS internet backbone. "APRSIS R"
packets came in via your Internet uplink, either due to APRSIS filters
requesting a specific pattern of packets, or due to the APRSIS
implicit rules, where the APRS-IS server you're connected to is trying
to guess what packets you're likely interested in.

The most common reason why you might be interested in packets from the
APRS-IS is if they are messages directed at stations which you have
recently heard on your local RF, which would explain why it happens
when the ISS is over-head. Your example implies that you recently
heard KR6E on your RF LAN, and so now the APRS-IS server is CCing you
on any APRS messages directed to KR6E, because it thinks you might
possibly be able to RF-gate those packets to KR6E (which isn't of much
value on the 145.825MHz channel, because satellites!)

I will often filter out the incoming APRS-IS traffic in my rf log
using a shell command akin to:
tail -F /var/log/aprx/aprx-rf.log | grep -v "APRSIS R"
--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/

> --
> You received this message because you are subscribed to the Google Groups "Aprx software" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aprx-softwar...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Lynn W Deffenbaugh (Mr)]

Also, the filtered or "IGate" port (typically 14580) on the APRS-IS
servers will deliver packets from stations that you've recently gated to
the APRS-IS. So if your IGate receives station X from RF and gates it
to the APRS-IS, then for some period of time after that (I believe it's
30 minutes, but don't quote me), the APRS-IS server will send you all
packets generated by station X. This is done so that IGates can be
aware of stations that are directly connected to the APRS-IS in order to
avoid gating messages addressed to them to the local RF unnecessarily.

And as mentioned by Kenneth, the APRS-IS server will also send you any
messages directed to stations that you've recently gated from RF to -IS
along with so-called "courtesy" posits for stations that generated those
directed messages.

So, even if an IGate is running no filter, it can expect to receive a)
messages directed to gated stations, b) posits for the stations sending
such messages and c) other packets generated by previously gated
stations. (c) is why IGate software cannot blindly gate everything
received from the APRS-IS to RF, but needs to implement some intelligence.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

[Michael Pittaro]

Thanks for the quick responses. This all makes sense now.

For now, my plan for APRX is to just IGate what I hear, since there
seems to be a coverage gap for ISS IGates in the SF Bay area. I'll
also be sending out an occasional beacon via RF when the ISS is range.

mike

[Curtis Scholl]

Is there any way to configure aprx to NOT direct any APRS-IS interface packets to the RF log?

I use a CAT on several area stations in a script to watchdog for stations failing to digi for any of many various reasons. I have to scrub the APRSIS records out of the 'CATed' file with 'sed' and substitute 'APRS' with null vales.

Thanks,
73s
Curtis
W8VFR

[Tom Hayward]

On Thu, Apr 30, 2015 at 12:51 PM, Curtis Scholl <cmsc...@gmail.com> wrote:
>
> Is there any way to configure aprx to NOT direct any APRS-IS interface packets to the RF log?
>
> I use a CAT on several area stations in a script to watchdog for stations failing to digi for any of many various reasons. I have to scrub the APRSIS records out of the 'CATed' file with 'sed' and substitute 'APRS' with null vales.

This is a pretty roundabout solution. How about something like this?

tail -f aprx-rf.log | grep -v APRSIS | ./yourdigicheck

Tom KD7LXL