IGate won't TX my APRS-IS traffic

[Christopher Snell]

Hi,

I have an IGate (NW5W-1) running on aprx and I'm trying to get APRS-IS to RF IGating to work.  I have a weather station (NW5W-10) at the same location that uses APRS-IS exclusively and I'd like to get it on RF so that I can receive the reports in my truck.   

My iGate will send its own beacons but will never TX any packets from the weather station.   I can log into APRS-IS manually and verify that my filter is working:

$ telnet noam.aprs2.net 14580

Trying 66.109.111.18...

Connected to noam.aprs2.net.

Escape character is '^]'.

# aprsc 2.0.14-g28c5a6a

user NW5W pass NNNN vers mytest 0.1 filter b/NW5W*

# logresp NW5W verified, server T2IAD

NW5W-10>APRS,TCPIP*,qAC,T2SJC:@081721z4715.66N/12228.20W_199/001g002t057r000p000P000b10231h86 http://fifestreet.com weewx-VantagePro

# aprsc 2.0.14-g28c5a6a 8 Jun 2014 17:21:28 GMT T2IAD 66.109.111.18:14580

 ...

I've checked my aprx-rf log and never see any weather station transmits.

I've also done a tcpdump to watch aprx log into APRS-IS and it looks like it's not applying the filter.

    https://gist.github.com/chrissnell/4147ae2be931a6125509

Here's my aprx config:

mycall  NW5W-1

myloc lat 4715.68N lon 12228.20W

<aprsis>

   passcode NNNN

   server oregon.aprs2.net

</aprsis>

<logging>

   pidfile /var/run/aprx.pid

   rflog /var/log/aprx/aprx-rf.log

   aprxlog /var/log/aprx/aprx.log

</logging>

<interface>

   serial-device /dev/ttyUSB0 4800 8n1    KISS

   tx-ok  TRUE

</interface>

<beacon>

   beaconmode radio

   cycle-size 20m

   beacon symbol "/-" lat "4715.68N" lon "12228.20W" comment "aprx iGate http://nw5w.com " via WIDE2-2

</beacon>

<digipeater>

 transmitter $mycall

 <source>

     source APRSIS

     relay-type third-party

     filter b/NW5W-10

     via-path WIDE1-1

 </source>

</digipeater>

Any ideas?

Chris

NW5W

[kg4pid]

One thing I see is that you don't have a filter in the <aprsis> section so the aprsis doesn't know to send you your weather station packets. Make it look like this.

<aprsis>
   passcode NNNN
   server oregon.aprs2.net

   filter b/NW5W-10
</aprsis>

I also had to add "heartbeat-timeout   0    # Disabler of heartbeat timeout" in there also because the server I was using would drop the connection. That's not your problem now, but it could happen if you connect to a different server at some point. After you change your configuration, stop and restart aprx and then look at the status page of the server and see if it took the filter. http://oregon.aprs2.net:14501/  Then look at the rf log and see if the aprsis is sending you your weather packets. Once you get it all working please slow down your weather reports because once per minute is way too fast and that is going to be a very long packet to transmit.

Hope this helps, Max KG4PID

[Christopher Snell]

Hi Max,

Thanks for the tip on adding the filter to the <aprsis> section.   That did indeed cause the proper filter to be set upon APRS-IS login.   However, aprx is still not transmitting the NW5W-10 packets that come in from APRS-IS.   Here's a snippet from my aprx-rf log:

 

    https://gist.github.com/chrissnell/abcb17d57ed0673bbc01

Here's my new config file:

    https://gist.github.com/chrissnell/e0124c73f425eb01ad79

Any ideas?

Chris

NW5W

--
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.

[kg4pid]

It looks like it should be working. I don't know if the filters work the same within aprx as they do in the aprsis. From the manual......

3.9.4.2 Filter B – Budlist
Syntax:
b/callsign1/callsign2/...
Match messages with given source addresses.
Wild-cards (*) are supported.

Notice it says "Match messages" I don't know if this means any packet from the given callsign or not. Some of the other filters say "packets" not "messages".  I would try a different filter in the <digipeater> section. Maybe a "t/3" since this a third party packet. I also would change the via path to wide2-1 if there are other digis around. No need for any home stations to digipeat this packet. You can also try using debug.

"DEBUGGING SYSTEM Use parameter set −ddv (or −dddv) to test new configuration by running it synchronously to console."

I would send this to a file so you can look at it later because if you don't the screen maybe scrolling info faster than you can read. I'm all out of ideas for you to try. Good luck and let us know what you find.

Max KG4PID

[Christopher Snell]

OK, I haven't tried a "t/3" filter....is that a valid filter?   Don't see it in the javAPRSFilter spec.

So I ran aprx with debugging enabled and I'm seeing this:

  https://gist.github.com/chrissnell/1da56844b200d20207cf

It looks like aprx gets an ax25 frame ready for transmit but then discards the packet somehow.   I'm not sure why.   

Maybe someone is more familiar with aprx internals than me.

Chris

[kg4pid]

The "t/3" filter is an aprx filter not an aprsis filter. Go to this link http://ham.zmailer.org/oh2mqk/aprx/ and find aprx-manual.pdf. Start reading on page 39.

The "t/3" may not work but one of the others might.

Max KG4PID 

[Christopher Snell]

So I've applied the aprx t/3 filter and I'm still seeing that discarded message (see gist above). I'm out of ideas at this point. What could be causing aprx to reject the packets?

Thanks,

Chris
NW5W

[Christopher Snell]

It looks like I'm not the first person to run into this problem:

https://groups.google.com/forum/#!msg/aprx-software/mEpw1BgGrxU/wrIx7YqzdL4J

Chris

NW5W