No RX capability?

[iqw1345]

I don't have another person to test with at this time, so instead, I have freedvtnc2 configured to TX through my radio and that works just fine, but I am unable to receive those transmissions using the websdr. I have redirected the audio output from the websdr into another freedvtnc2 instance and I can see the Input level changing, but there's no indication that anything is actually being received.

I then configured two instances of freedvtnc2 to be connected to each other directly using qjackctl and I can see the input level fluctuating when something is being transmitted to the other instance, but no indication of anything being decoded. I have tried using TNCs to communicate and sending messages to each other using this method.

I have tested all of the TX Modes and with the same results.

Am I doing something wrong here or is this expected behavior?

[xssfox]

Try saving your config with the save command then running --no-cli --log-level DEBUG and provide the logs here. I haven't checked running this through jack. You could try running the tune command and a recording or listening to it to make sure it's generating a nice clean signal.

[iqw1345]

For additional context, the main audio server that I am using is pipewire, but I am using JACK's capabilities to manually run audio to where I want in this case. I have configured freedvtnc2 to use "pulse" as the input and output audio. That way, when I run the radio, I can start freedvtnc2 with the following:

PULSE_SINK=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo PULSE_SOURCE=alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo freedvtnc2 --input-device pulse --output-device pulse --kiss-tcp-port 8001 --mode DATAC1 --log-level DEBUG

This is out of habit from dealing with fldigi and direwolf.

As requested, I have attached logs of both instances trying to communicate with each other, but to no avail. I tried pinging freedvtnc2-2 from freedvtnc2-1.

freedvtnc2-2.txt
freedvtnc2-1.txt

I've also attached what the audio configuration looks like in this case using qjackctl with each tnc communicating with the other.

It's not shown in the above picture, but I didn't see a tune command, but I assume you meant to run the test_ptt command. I played test_ptt into my headphones and the audio output sounded clear.

Please let me know if there's any additional information needed from me.

[xssfox]

I'm not entirely sure what the problem is. I know i've had issues in the past with dynamically changing the inputs and outputs on pyaudio apps before using qjackctl before. I think this might be due to a clock change occurring that pyaudio/portaudio can't handle? I'm really not too sure tbh. I was certainly able to replicate your issue using my pipewire test box. For testing you can work around the issue by creating a sink device first and telling freedvtnc to talk directly to that.

pactl load-module module-null-sink sink_name=freedv_testing
freedvtnc2 --output-device "freedv_testing Audio/Sink sink" --input-device "freedv_testing Audio/Sink sink Monitor"

This worked for me, you can either run two of these or just one (the modem will happily RX it's self which is handy for testing as you don't need two instances running)

There's probably not a lot more I can do though.

[iqw1345]

Interesting, that works for me too. I appreciate the help and thanks for the project!

[xssfox]

No worries. I'll close this for the moment. If I can find out the exact cause I'll try to figure out which upstream project to raise the problem with.