Announce: experimental CAT/DAX clients for Linux

I put this together for my notes.

Alan. WA9WUD

=======================

GitHub. https://github.com/kc2g-flex-tools

**Make a new directory to hold nCAT and xCAT. I named mine “Flex” in the “Home” directory:**

>>> mkdir /home/pi/Flex

**Change to the new directory:**

>>> cd /home/pi/Flex

**Download nDAX:**

AMD 32 byte >>>. wget https://github.com/kc2g-flex-tools/nDAX/releases/download/v0.1-20210714.0/nDAX-linux-arm

AMD 64 byte >>> wget https://github.com/kc2g-flex-tools/nDAX/releases/download/v0.1-20210714.0/nDAX-linux-amd64

**Download nCAT:**

AMD32 byte>>> wget https://github.com/kc2g-flex-tools/nCAT/releases/download/v0.0-20210420.0/nCAT-linux-arm

AMD64 byte>>> wget https://github.com/kc2g-flex-tools/nCAT/releases/download/v0.0-20210420.0/nCAT-linux-amd64

**Rename Files:**

>>> mv nCAT-linux-arm nCAT

>>> mv nDAX-linux-arm nDAX

**Make Executable:**

>>> chmod +x nDAX

>>> chmod +x nCAT

**Test nDAX From The Terminal, enter Flex IP address and Client Name as shown:**

>>> ./nDAX -station >Client Name< -slice A -daxch 1 -source flex.sliceA.rx -sink flex.sliceA.tx -radio >Flex IP Address<

**>>>>>>Note: Open a new terminal session<<<<<**

**Test nCAT From The Terminal, enter Flex IP address and Client Name as shown:**

>>> ./nCAT -radio >Flex IP Address< -station >Client Name<

**>>>> Note: Close terminal sessions to **** nDAX and nCAT**

Thanks...I tried that... must be doing something wrong.

pi@raspberrypi:~/Downloads $ ls

 fldigi-4.1.18             fldigi-4.1.18.tar.gz  IC-7300.xml

'fldigi-4.1.18(1).tar.gz'  fldigi-4.1.19.tar.gz  nCAT-linux-arm

pi@raspberrypi:~/Downloads $ ./nCAT -Linux-arm -station N7JDI

bash: ./nCAT: No such file or directory

Ahh...I see thx

Now that it runs (thank you) what is done at this point? I guess I need some guidance on how this is actually implemented in Linux and other programs.

@PaulB emulating a tty is more difficult than it sounds, but it's not necessary. fldigi works 100% with IP (as does any decent hamlib app). Just select "Hamlib NET rigctl" for rig and type "localhost" (or whatever IP address) as "device" in the config dialog, ignore all of the serial port options, and make sure "PTT via hamlib command" is selected.

Actually, disregard my last. I had the frequency "Locked" in SmartSDR while trying to solve the problem of JS8 removing digital mode when transmitting.

Thank you sir. I was not aware you could change the "device" field to localhost. I have done that.

When I connect, it pulls the frequency from the radio (good) but then when I try to change a frequency within fldigi, I get the following in the nCAT terminal window....fldigi and nCAT are running on the same machine on the same network as the flex. Thx in advance.

pi@raspberrypi:~ $ ./nCAT-linux-arm -station FLEX

8:36AM INF Waiting for station station=FLEX

8:36AM INF Found client client_id=0x5C7BB1FD uuid=7FE86A15-A08F-4B8A-A531-66B11E91526E

8:36AM INF Looking for slice slice_id=A

8:36AM INF Found slice slice_idx=0

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

8:38AM WRN Handler returned error error="slice tune 50000068" cmd=["F","8110000.000000"]

Outstanding Sir! Thank your for your continued development!

Yes, I'm always testing with the latest radio firmware, usually before it comes out, or within a day or two of release at the latest. There are no 3.4-specific issues in nCAT or nDAX.

As for your time offset issue, nothing has changed that I would expect to cause that, and I haven't heard of any problems from anyone else (including me — I use it regularly). Previous versions are always available from the GitHub releases page, and you can always downgrade your radio, so debugging should be straightforward. You can also try adding the "-high-bw" flag to nDAX and see if that makes any difference.

after a week of experimenting, it appears my waterfall is getting washed out on wsjt only after i transmit, and takes a 15 minutes to recover

@Jim_K0QEI interesting. I'm running Ubuntu 22.10 here, and was running 22.04 before that, without problems, so all I can say is "probably something weird on your computer". There isn't anything in nDAX that should ever cause an issue like that.

It turns out that my last announcement was a bit premature. As of today, nDAX still has some issues with pipewire, which may show up as very high receive latency, or as receive audio that becomes corrupted after switching from RX to TX and back to RX.

While I work on resolving these issues, my recommendation is *use PulseAudio if possible*. But if PipeWire is unavoidable, try this workaround:

Before starting nDAX, open the "pavucontrol" (Volume Control) app to the "Input Devices" tab. Leave it open in the background for as long as you're using nDAX. Why does that make any difference? pavucontrol has a level meter for every device, which means it always has the device open for recording, which changes the way that buffering happens internally.

I'll be back with more info and possibly an nDAX update once we get to the bottom of the issue.

It might happen someday. In particular, I've been thinking about writing something that would replace multiple instances of nDAX and nCAT for people who like to run several slices, with automatic coordination between them. That would work just as well for the people who only want one. But the idea isn't fully-baked yet, so it's not going to happen too soon.

I am using your software on Ubuntu 22 and when i transmit i end up having bad decodes after. i was wondering if you had any ideas? it ends up being washed out between transmit cycles.