¿ªÔÆÌåÓý

APRS-IS data over KISS TCP port


 

I have Direwolf connected to 2 radios, and the APRS-IS server which I connect my client to through KISS over TCP/IP.
Anything received on either radio is sent over TCP/IP to my client as expected.
HOWEVER, I can seem to get anything received from the APRS-IS system to be sent to my client.

Layout description:
Both radios are 'listen only', so I am hoping to get data from 3 sources (2 radios and the internet).
We are trying to track a balloon with satellite antennas.? My client is just a TCP/IP monitor.?
?? When the correct Callsign and SSID are received, the Az-El angles are calculated and a command is given to an AlfaSpid rotor controller to point the antenna.
?? Future intent is to point a telescope at a night balloon flight to see if a blinking light can be spotted.

APRS-IS connect with a friend filter for the balloon Callsign-SSID, and wide area around my location.
?? Direwolf shows lots of stations coming through - even with no radios attached.
?? Client does not receive any stations.
?? Attach radio audio, and only those stations are available over TCP/IP.

I tried setting IGate Configure Transmit for each of the 2 radios with filters of only TX the balloon Callsign-SSID.
?? The stations heard are sent over RF (well, try to, but no TX audio is connect), but not over TCP/IP.

Rob KB8RCO


 

I'm currently collecting telemetry data from a number of remote APRS sites, but I'm using the LIBFAP library in Python to get the data from APRS-IS with a socket connection. I started by using? both a radio (and Direwolf) and my code, but discovered that anything I heard directly was also being heard elsewhere and makes its way to the APRS-IS server, so I eliminated the radio completely in the latest version. If your question does not get an answer to resolve your issue with doing it completely within Direwolf, I'll be happy to help you get going with LIBFAP. I'm a bit of a Python noob, but my code has been working just under a year.


 

Charlie,
Thanks for the response.
I started out in Python and only getting data from the IS servers, but the group wanted 3 separate sources: VHF, UHF, and IS.
I guess they relied on IS before, and had issues when the payload dropped in a noncoverage area.
I was using Python, then C++ code to receive KISS packets from 2 hardware TNCs and IS when I thought using Direwolf and collecting the data over TCP might be easier.
I thought I had it all working with the RF data, but now that even stopped being received (or maybe just printed) by my app.

The intent is to have several of these Pi receivers around with directional antennas to more directly point at the location to increase the probability of being heard.
Another objective (as stated earlier) is to have a telescope or other visual device point during a night launch.

I am pretty sure I can get the RF side back working, but I don't understand why there is nothing from Direwolf receiving data from APRS-IS out of TCP/IP KISS.?
I would have thought that the IS->RF would have solved that.

Rob KB8RCO


 

Direwolf _does_ do IS->RF, but your snooping client connected to DireWolf's AGWPE or KISS port is neither RF nor IS. Only RF-received traffic is sent to those ports, and traffic sent from your client over those ports only goes to RF, not to the Internet. If you want your client to receive (or send) Internet traffic as well as RF traffic, you'll have to connect the client directly to APRS-IS (not via DireWolf).

Andrew, KA2DDO
author of YAAC ("Yet Another APRS Client"), which frequently is used with DireWolf

-------------------------------------------------------------------------
From: [email protected] <[email protected]> on behalf of Rob Giuliano via groups.io <kb8rco@...>
Sent: Tuesday, November 30, 2021 10:33 AM
To: [email protected] <[email protected]>
Subject: Re: [direwolf] APRS-IS data over KISS TCP port
?
Charlie,
Thanks for the response.
I started out in Python and only getting data from the IS servers, but the group wanted 3 separate sources: VHF, UHF, and IS.
I guess they relied on IS before, and had issues when the payload dropped in a noncoverage area.
I was using Python, then C++ code to receive KISS packets from 2 hardware TNCs and IS when I thought using Direwolf and collecting the data over TCP might be easier.
I thought I had it all working with the RF data, but now that even stopped being received (or maybe just printed) by my app.

The intent is to have several of these Pi receivers around with directional antennas to more directly point at the location to increase the probability of being heard.
Another objective (as stated earlier) is to have a telescope or other visual device point during a night launch.

I am pretty sure I can get the RF side back working, but I don't understand why there is nothing from Direwolf receiving data from APRS-IS out of TCP/IP KISS.?
I would have thought that the IS->RF would have solved that.

Rob KB8RCO


 

A little more detail:
Direwolf reports are like this
?? [ig>tx] K8JTT-10>APX219,TCPIP*,qAC,EIGHTH:=4207.65N/08315.58WxPHG7228Jim - Brownstown, MI
?? [2.3] K8OEC-10>APN383,K8WNJ-1,CHLSEA,WIDE2*:!4303.41NS08614.47W# Grand Haven Digi
Note: channel zero is not currently connected to a radio.? If I swap connections, the decoded data becomes:
?? [0.2] K8OEC-10>APN383,K8WNJ-1,CHLSEA,WIDE2*:!4303.41NS08614.47W# Grand Haven Digi

I am back to getting RF reports showing on my client, but nothing from APRS-IS.

Rob KB8RCO


 

Thanks for the information.
I had 'kind of' come to that conclusion, but wanted confirmation.

Robert Giuliano
KB8RCO



On Tuesday, November 30, 2021, 10:46:14 AM EST, Andrew P. <andrewemt@...> wrote:


Direwolf _does_ do IS->RF, but your snooping client connected to DireWolf's AGWPE or KISS port is neither RF nor IS. Only RF-received traffic is sent to those ports, and traffic sent from your client over those ports only goes to RF, not to the Internet. If you want your client to receive (or send) Internet traffic as well as RF traffic, you'll have to connect the client directly to APRS-IS (not via DireWolf).

Andrew, KA2DDO
author of YAAC ("Yet Another APRS Client"), which frequently is used with DireWolf


 

If information you need is being printed (standard out) why not redirect it to your application, rather than trying to get it through the KISS port?


 

I was thinking similar thoughts.?
However, Direwolf puts out a lot of data, including decoding of some packets:

[ig>tx] N8QLT-S>APDG01,TCPIP*,qAC,N8QLT-GS:;N8QLT? A *011508z4228.57ND08352.39WaRNG0001 440 Voice 445.67000MHz +0.0000MHz

Digipeater CHLSEA audio level = 22(5/4)?? [NONE]?? ___||____
[2.3] NU3S-7>APK102,N3FB-2,K8UI-1,CHLSEA*,WIDE3-1:=4022.75N/08004.80W_201/002g009t040r?? p?? P000h93b10219KU2k<0x0d>

???? Weather Report, WEATHER Station (blue), Kenwood D710
???? N 40 22.7500, W 080 04.8000
???? wind 2.3 mph, direction 201, gust 9, temperature 40, rain 0.00 since midnight, humidity 93, barometer 30.18, "KU2k"

It is much easier to get it through a known format.
But it appears only a little more filtering would be required.? The good news is the already decoded packet is less to parse than going through Mic-E, Compressed, Text, all with and without timestamps, etc.

I will take a look at that next.

Robert Giuliano
KB8RCO



On Wednesday, December 1, 2021, 09:58:50 AM EST, charlie gale <charles@...> wrote:


If information you need is being printed (standard out) why not redirect it to your application, rather than trying to get it through the KISS port?