Multiple streams on KISS over TCP


Rob Giuliano
 

I am running Nexus DR-X on a Raspberry Pi and Fe-Pi audio card with 2 audio channels.
This feeds into Direwolf the 2 audio channels decoded and sent using KISS over TCP/IP to APRSIS32.

I only connected a radio to the second audio channel, knowing that APRSIS32 will only TX on the first TCP/IP channel.
I was surprised to find that the radio PTT was triggered, but nothing was actually sent (no audio).

Since I had an issue before, where my configuration cause the PTT to activate, I am unsure if this is related to THAT issue, or if APRSIS32 will cause the PTT to go active, even if the request is on the non-TX capable TCP/IP channel.

Has anyone else tried a multi-channel KISS configuration?
   If so, have you seen the the PTT activate on the second channel?

Robert Giuliano
KB8RCO

FYI: Nexus is a version of RaspberryPi OS for HAM radio and specifically the Nexus DR-X multi-radio interface board for the Raspberry Pi and Fe-Pi sound card.  I believe they took over the Fe-Pi board designs and manufacturing.


Lynn Deffenbaugh
 

APRSIS32 cannot directly activate any PTT under any condition.   It only sends KISS (or other format) packets to TNC hardware or software.  PTT is always handled by the TNCs.

And for multi-channel KISS interfaces, APRSIS32 will always and only address the "0" port, but will receive and interpret packets from any port.  What the TNC considers as "port 0" inside a KISS packet is up to the TNC and it doesn't always necessarily match what the TNC calls the ports in their documentation.

You can always try enabling the trace log on the specific port and see if the binary data is shown on transmits.  If so, you can decode the bytes and find out exactly what is being sent.  Then look at the DireWolf code and see what it would do with that particular binary packet.  Note:  I'm not at all sure what detail is logged on the various port types in APRSIS32.  It may or may not contain a hexified binary dump of the packet contents.

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


On 11/3/2021 10:01 AM, Rob Giuliano via groups.io wrote:
I am running Nexus DR-X on a Raspberry Pi and Fe-Pi audio card with 2 audio channels.
This feeds into Direwolf the 2 audio channels decoded and sent using KISS over TCP/IP to APRSIS32.

I only connected a radio to the second audio channel, knowing that APRSIS32 will only TX on the first TCP/IP channel.
I was surprised to find that the radio PTT was triggered, but nothing was actually sent (no audio).

Since I had an issue before, where my configuration cause the PTT to activate, I am unsure if this is related to THAT issue, or if APRSIS32 will cause the PTT to go active, even if the request is on the non-TX capable TCP/IP channel.

Has anyone else tried a multi-channel KISS configuration?
   If so, have you seen the the PTT activate on the second channel?

Robert Giuliano
KB8RCO

FYI: Nexus is a version of RaspberryPi OS for HAM radio and specifically the Nexus DR-X multi-radio interface board for the Raspberry Pi and Fe-Pi sound card.  I believe they took over the Fe-Pi board designs and manufacturing.


Rob Giuliano
 

Thanks for the detailed response.

I think found the issue. 
When I disabled the DIGI function, the issue went away.

So, it appears that it has to do with the path, DIGI settings, and maybe the stream info not necessarily being used in the DIGI.  I don't think I am going to investigate this any further though.  I solved my TX problem.

Robert Giuliano
KB8RCO



On Wednesday, November 3, 2021, 11:39:12 AM EDT, Lynn Deffenbaugh <kj4erj@...> wrote:


APRSIS32 cannot directly activate any PTT under any condition.   It only sends KISS (or other format) packets to TNC hardware or software.  PTT is always handled by the TNCs.

And for multi-channel KISS interfaces, APRSIS32 will always and only address the "0" port, but will receive and interpret packets from any port.  What the TNC considers as "port 0" inside a KISS packet is up to the TNC and it doesn't always necessarily match what the TNC calls the ports in their documentation.

You can always try enabling the trace log on the specific port and see if the binary data is shown on transmits.  If so, you can decode the bytes and find out exactly what is being sent.  Then look at the DireWolf code and see what it would do with that particular binary packet.  Note:  I'm not at all sure what detail is logged on the various port types in APRSIS32.  It may or may not contain a hexified binary dump of the packet contents.

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


On 11/3/2021 10:01 AM, Rob Giuliano via groups.io wrote:
I am running Nexus DR-X on a Raspberry Pi and Fe-Pi audio card with 2 audio channels.
This feeds into Direwolf the 2 audio channels decoded and sent using KISS over TCP/IP to APRSIS32.

I only connected a radio to the second audio channel, knowing that APRSIS32 will only TX on the first TCP/IP channel.
I was surprised to find that the radio PTT was triggered, but nothing was actually sent (no audio).

Since I had an issue before, where my configuration cause the PTT to activate, I am unsure if this is related to THAT issue, or if APRSIS32 will cause the PTT to go active, even if the request is on the non-TX capable TCP/IP channel.

Has anyone else tried a multi-channel KISS configuration?
   If so, have you seen the the PTT activate on the second channel?

Robert Giuliano
KB8RCO

FYI: Nexus is a version of RaspberryPi OS for HAM radio and specifically the Nexus DR-X multi-radio interface board for the Raspberry Pi and Fe-Pi sound card.  I believe they took over the Fe-Pi board designs and manufacturing.