Question about possible interfacing with a Soundmodem

[N6RFM]

As an alternative to a hardwired modem, trying to interface to a software based sound modem, called DireWolf. In the main.c source code, changing line 55 from conf.device = argc == 2 ? argv[1] : "/dev/ttyUSB0"; to conf.device = argc == 2 ? argv[1] : "/tmp/kisstnc"; allows for the ping command output to be seen when Direwolf is started with the -p switch.

Virtual KISS TNC is available on /dev/pts/5 Created symlink /tmp/kisstnc -> /dev/pts/5 Invalid transmit channel 1 from KISS client app. <<< Data frame from KISS client application, port 1, total length = 45 000: 10 96 92 9e 9e 6e b2 60 96 92 9e 9e 6e b2 61 03 .....n.`....n.a. 010: f0 94 20 61 01 00 01 02 03 04 05 06 07 08 09 0a .. a............ 020: 0b 0c 0d 0e 0f 10 11 12 13 cc 79 eb e6 ..........y.. Unfortunately, the transmit channel error seems to preclude being able to actuate PTT on the radio (9k6 data capable Icom IC-910H in this case). Feedback from the DireWolf user group - "Fix your app to request TNC#0 instead of TNC#1." "Sounds like your application is demanding to use the second sound card configured in DireWolf (except you don't have one). Looks like the hardware TNC formerly used completely ignored the TNC number in the KISS header byte (which allows up to 16 uniquely numbered TNCs to theoretically share a serial line), but DireWolf properly handles it, and is telling you that your application is asking for a non-configured sound card." This supposes that in the stock software, TNC#1 is being called for. Is there a way for me to locally modify the software to request TNC#0 instead, if in fact TNC#1 is being asked for? Thanks, Bob

[N6RFM]

Based on a suggestion from K4KDR, I was able to get rid of the error by changing to Device 1 in Direwolf. But, maybe you can give some insight how PTT is being actuated, as this is problem remains. Thanks.

[sarahsrogers]

Hi, Bob,

While our ground station setup is purely hardware, our code doesn't include any commands for our TNC or ICOM radio. It just handles creating the command and sending it to the appropriate USB port that connects to our TNC. From there, the TNC just sends this to the ICOM radio to transmit to our spacecraft. We don't have any additional scripts that control the PTT function on the ICOM. I can publish the settings for our TNC and ICOM if that would be helpful in any way, however.

We would test this out further, but we unfortunately don't have a SDR that can both transmit and receive signals. The best option might be to keep speaking with Direwolf to see how it manages the PTT function.

If we can be of any additional help in the meantime, please let us know!

~Sarah

[N6RFM]

Thanks Sarah. We will continue to investigate. PTT should be asserted when TX data comes across from the app into DireWolf, and we can see the data in the console.
Best, Bob

[N6RFM]

Making progress interfacing the GS software to DireWolf inder Mint 19/Ubuntu 18, by further modifying the DireWolf config file.

Question - is there a way for the end user to modify the code so that the destination is WJ2XOY and the source is the user amateur callsign?

Adaptations so far -

In addition to the main.c phxsat source code, as described above.

By changing ACHANNELS from 1 to 2 in the DireWolf config file, the "Invalid transmit channel 1 from KISS client app." error resolved.

However, PTT was still not working. But a PTT solution for users with Icom rigs such as mine is described below.

Turns out that for the Icom IC-910H, adding PTT RIG 344 /dev/ttyUSB0 to the Direwolf config file was insufficient. Further troubleshooting using rigctl from hamlib revealed that (for my setup) rigctl -m 344 -r /dev/ttyUSB0 needed the radio CI-V address -c 0x60 to be added to give rigctl -m 344 -r /dev/ttyUSB0 -c 0x60. Absent the CI-V address, commands sent to the radio do not work.

The required CI-V code is not supported directly in the DireWolf config file. But, there is an easy workaround.

First start the hamlib rig control daemon in a new terminal using rigctld -m 344 -r /dev/ttyUSB0 -c 0x60. The 344 is for the IC-910, and ttyUSB0 is the serial port being used in this specific installation. The rigctld daemon also listens on localhost:4532 by default. Adding PTT RIG 2 localhost:4532 under channel 1 in the config file got things working. The 2 after RIG means listen for commands on localhost.

This is a workaround for those using Icom radios which require a CI-V address for communication, since this address does not seem to be allowed as part of the PTT line. For example, PTT RIG 344 /dev/ttyUSB0 -c 0x60 as a line in the config file does not work.

Using the rigctld PTT approach now works when sending the ping command, and the output of the ping command in the DireWolf console is shown below.

[1L] KIOO7Y>KIOO7Y:� f<0x01><0x00><0x01><0x02><0x03><0x04><0x05><0x06><0x07><0x08><0x09><0x0a><0x0b><0x0c><0x0d><0x0e><0x0f><0x10><0x11><0x12><0x13>�y��

Here is a comparison of the before and after DireWolf output -

for setting ACHANNELS 1 <<< Data frame from KISS client application, port 1, total length = 45 000: 10 96 92 9e 9e 6e b2 60 96 92 9e 9e 6e b2 61 03 .....n.`....n.a. 010: f0 94 20 61 01 00 01 02 03 04 05 06 07 08 09 0a .. a............ 020: 0b 0c 0d 0e 0f 10 11 12 13 cc 79 eb e6 ..........y..

for setting ACHANNELS 2 [1L] KIOO7Y>KIOO7Y:� f<0x01><0x00><0x01><0x02><0x03><0x04><0x05><0x06><0x07><0x08><0x09><0x0a><0x0b><0x0c><0x0d><0x0e><0x0f><0x10><0x11><0x12><0x13>�y��

Thanks,

Bob N6RFM

[sarahsrogers]

Sorry for the late response here. I can add your workaround solution to our troubleshooting document on compiling our ground station code with direwolf and gqrx. That seems like an appropriate place to put this information for now, and we can add to it as more information is discovered about PTT. Does that sound alright for now?

[N6RFM]

For sure. Please also see some new suggestions about document content in Thread #7 . Thanks.