Hi Phil

Enumeration depends on the polling order of the PC and whether the rig(s) are on at the time. If both rigs are on every time you reset the PC's USB bus and the plugs remain in the same sockets they will get the same "number" "order". In most cases then cycling a single rig's power off/on will bring back the same "number", but it kind of depends on how it dies. Sometimes you'll get an entirely new "number".

I hope I made that clear hihi. I think being aware of the reason is important.

If one wanted full automation and perfect response every time the next step IMO would be to interrogate each of the USB serial ports created using the CI-V. ie to differentiate between Icom rig models. Then use that info to name the relevant hardware. My USB serial port on the Icom is /dev/icom9100a for example, but I do that through udev, not manual naming.

I'd suggest though that it is simpler to just leave both rigs on, or hot unplug/plug them in the same order if things get messed up. That will also enumerate the same audio/codec port number. Additionally I'd suggest only adjust pavucontrol as a last resort.

At some stage with both rigs connected issue the terminal command "pactl list" to verify the sound port names I have used below.

The fldigi start commands (which can be entered in a terminal window) might then be;

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 /usr/local/bin/fldigi --home-dir /home/<user>/.fldigi.ic705

and

PULSE_SINK=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-01.analog-stereo PULSE_SOURCE=alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-01.analog-stereo /usr/local/bin/fldigi --home-dir /home/<user>/.fldigi.ic7300

Somewhere before there you might also need to create a device link for the serial ports so that fldigi "sees" a name like /dev/ic7300a and /dev/ic705a. Not a problem though if both rigs always powered and plugged in at the same ports.

Sorry its getting kind of complex, but happy to elaborate or take off list.

Cheers Bob VK2YQA

On 18/4/24 04:48, Philip Rose, GM3ZZA via groups.io wrote:

Thanks Bob,

The two icoms get enumerated ok, but the enumeration changed after a reboot. Probably as a result of adding the IC705 after the previous reboot. It seems to be stable since.

The two FLdigi instances identify themselves to pulseaudio as the same.

It's the understanding how to enscript this that I lack.

Phil GM3ZZA

Thanks Bob,

The two icoms get enumerated ok, but the enumeration changed after a reboot. Probably as a result of adding the IC705 after the previous reboot. It seems to be stable since.

The two FLdigi instances identify themselves to pulseaudio as the same.

It's the understanding how to enscript this that I lack.

Phil GM3ZZA

Hi Phil

Some info for your situation - I use a pulseaudio environment startup to distinguish between between an Icom and QDX. (The Exec command in a desktop file) eg

/bin/sh -c "PULSE_PROP_APPLICATION_NAME=FLDIG 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 /usr/local/bin/fldigi"

/bin/sh -c "PULSE_PROP_APPLICATION_NAME=FLQDX PULSE_SINK=alsa_output.usb-QRP_Labs_QDX_Transceiver-02.analog-stereo PULSE_SOURCE=alsa_input.usb-QRP_Labs_QDX_Transceiver-02.analog-stereo /usr/local/bin/fldigiqdx --home-dir /home/bcameron/.fldigi.qdx"

One would assume that for two Icom radios with the same codec hardware would be numbered CODEC-00 and CODEC-01. The above then removes the need to use pactl or pavucontrol to link app<>port

Pulseaudio is suppose to remember each applications volume etc settings based on (I think) an application name provided by the application itself. I haven't delved into why but that doesn't seem to happen with fldigi. I don't think the PULSE_PROP_APPLICATION_NAME=FLDIG works either.

load-module module-device-manager probably has to be done in /etc/pulse/system.pa or the equivalent user location

Cheers Bob VK2YQA

Making some progress. I'm now in the maze of twisty little passages all alike.

I reverted to selecting PortAudio->pulse in fl;digi.

I found where I can connect a specific instance of fldigi to the specific audio codecs. Obvious really. Under the playback and recording tabs of pavucontrol, I can attach each app to a different code. Two problems:

1. The two apps are both called "ALSA  plug-in [fldigi]" and the two codecs are called "PCM2901 Audio Codec Analog Stereo". 
2. When I make the connections they don't survive restarting fldigi.

Yesterday I managed to rename the codecs (at least for displaying in pavucontrol). The names had reverted today. But just typing: 
pactl load-module module-device-manager 
in the terminal caused the names to reappear. Just need to be able to identify which instance of fldigi is which. But as I will usually only be using one at a time, it's no longer a big deal.

Making some progress. I'm now in the maze of twisty little passages all alike.

I reverted to selecting PortAudio->pulse in fl;digi.

I found where I can connect a specific instance of fldigi to the specific audio codecs. Obvious really. Under the playback and recording tabs of pavucontrol, I can attach each app to a different code. Two problems:

1. The two apps are both called "ALSA  plug-in [fldigi]" and the two codecs are called "PCM2901 Audio Codec Analog Stereo". 
2. When I make the connections they don't survive restarting fldigi.

Yesterday I managed to rename the codecs (at least for displaying in pavucontrol). The names had reverted today. But just typing: 
pactl load-module module-device-manager 
in the terminal caused the names to reappear. Just need to be able to identify which instance of fldigi is which. But as I will usually only be using one at a time, it's no longer a big deal.

Yip,

That is already in the TS-570/S code.

transmit: TX;
receive : RX;

David

On 4/16/24 00:21, VR2VRC via groups.io wrote:

Hi David

Can you help add TRX On/ Off Function for?Kenwood TS-570 in Flrig??

73
Yip
VR2VRC?

Hi David

Can you help add TRX On/ Off Function for?Kenwood TS-570 in Flrig??

73
Yip
VR2VRC?

I don't remember the frequency values of the first log, so I repeated some of the tests.
Taking bytes 1-3 (counting from 0) of the VFO/Memory Data Record (9 Bytes), and converting the hexadecimal number to decimal, I get the rig's actual VFO frequency in 10s of Hz. That means that you are getting the correct frequencies from the rig.
------------------------------------
VFO A is 5000.00 MHz on FLRIG
VFO B is .740.00 MHz on the rig
Radio is set to 5.000.00 MHz, the same as FLRIG.

05:37:41.733 : read_smeter()
05:37:41.733 : WriteBuffer:? 00 00 00 00 F7
05:37:41.783 : ReadBuffer [0.032000 msec]: 36 36 36 36 F7
05:37:42.203 : read_vfo()
05:37:42.203 : WriteBuffer:? 00 00 00 03 10
05:37:42.260 : ReadBuffer [6.529000 msec]: 08 07 A1 20 00 00 03 04 04 01 01 21 10 00 00 03 04 85
05:37:42.260 : vfoA active get vfo A
05:37:42.260 : read_mode vfoA active
05:37:42.260 : read: 0
05:37:42.661 : read_smeter()
05:37:42.661 : WriteBuffer:? 00 00 00 00 F7
05:37:42.711 : ReadBuffer [0.033000 msec]: 3C 3C 3C 3C F7
05:37:43.131 : read_vfo()
05:37:43.131 : WriteBuffer:? 00 00 00 03 10
05:37:43.188 : ReadBuffer [6.500000 msec]: 08 07 A1 20 00 00 03 04 04 01 01 21 10 00 00 03 04 85
05:37:43.188 : vfoA active get vfo A
05:37:43.189 : read_mode vfoA active
05:37:43.189 : read: 0
05:37:43.589 : read_smeter()
05:37:43.589 : WriteBuffer:? 00 00 00 00 F7
05:37:43.640 : ReadBuffer [0.019000 msec]: 3C 3C 3C 3C F7
------------------------------------
VFO A is 5000.00 MHz on FLRIG
VFO B is 2961.92 on FLRIG, .740.00 MHz on the rig.
Radio is set to 5.001.00 MHz, different from FLRIG.

05:50:47.284 : read_vfo()
05:50:47.285 : WriteBuffer:? 00 00 00 03 10
05:50:47.340 : ReadBuffer [5.437000 msec]: 08 07 A1 84 00 00 03 04 04 01 01 21 10 00 00 03 04 85
05:50:47.340 : vfoA active get vfo A
05:50:47.341 : read_mode vfoA active
05:50:47.341 : read: 0
05:50:47.741 : read_smeter()
05:50:47.741 : WriteBuffer:? 00 00 00 00 F7
05:50:47.791 : ReadBuffer [0.067000 msec]: 42 42 42 42 F7
05:50:48.211 : read_vfo()
05:50:48.211 : WriteBuffer:? 00 00 00 03 10
05:50:48.268 : ReadBuffer [6.509000 msec]: 08 07 A1 84 00 00 03 04 04 01 01 21 10 00 00 03 04 85
05:50:48.268 : vfoA active get vfo A
05:50:48.268 : read_mode vfoA active
05:50:48.268 : read: 0
05:50:48.669 : read_smeter()
05:50:48.669 : WriteBuffer:? 00 00 00 00 F7
05:50:48.719 : ReadBuffer [0.035000 msec]: 3F 3F 3F 3F F7
05:50:49.139 : read_vfo()
05:50:49.139 : WriteBuffer:? 00 00 00 03 10
05:50:49.196 : ReadBuffer [6.537000 msec]: 08 07 A1 84 00 00 03 04 04 01 01 21 10 00 00 03 04 85
05:50:49.196 : vfoA active get vfo A
05:50:49.197 : read_mode vfoA active
05:50:49.197 : read: 0
05:50:49.597 : read_smeter()
05:50:49.597 : WriteBuffer:? 00 00 00 00 F7
05:50:49.648 : ReadBuffer [0.037000 msec]: 3E 3E 3E 3E F7

After recompiling with the updated FT890.cxx
Init works now. The rig is recognized. Both the red and green receive/send lights flash periodically.
Modulation mode works, where it was disabled before, but does not read the rig's mode.
Still does not read the rig's VFO freq, but it still writes to the rig.
In Operating Controls: Freq and Mode are checked.

Buttons for vfoA vfoB and A/B work, but changing vfoB in FLRIG does not change the rig's (vfo b) freq.
S-meter works when enabled.
PTT puts the rig in transmit.

Changing the timing parameters had no effect.
Changing the comm parameters did not help.

I have attached a trace log that starts with the init.

Using a Raspberry Pi 4 on DietPi Debian Bookworm OS.
In the FLRIG configuration, I selected the Yaesu FT-890 rig and for the port I used /dev/ttyUSB0 for a USB to serial converter.
Port /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ABSCDZTJ-if00-port0 works the same.

Both the red and green lights on the USB to serial converter flash when Init is pressed, which means that FLRIG sent data and the rig replied.
However, FLRIG says "Transceiver not responding!".
Changing the frequency in FLRIG changes the frequency on the rig. The green light on the USB converter flashes. PTT puts the rig in transmit.
Changing the frequency on the rig does not update FLRIG.

It's like FLRIG is sending the correct data, but it does not receive anything from the rig even though it is sending data back when Init is pressed.

CAT works perfectly with applications that use hamlib like FLDIGI, WSJT-X and grig.

I am using this cable:


Trace with all items checked

05:16:57.893 : closeRig()
05:16:57.893 : close serial port
05:16:57.893 : ClosePort(): fd = 10
05:16:57.896 : serial port closed
05:16:57.897 : clear frequency list
05:16:57.897 : initialize title bar
05:16:57.897 : start tranceiver serial port
05:16:57.900 : /dev/ttyUSB0 opened: fd = 10
05:16:57.908 : D: startXcvrSerial:
Serial port:
??? Port???? : /dev/ttyUSB0
??? Baud???? : 4
??? Stopbits : 2
??? Retries? : 2
??? Timeout? : 50
??? Loop???? : 500
??? RTSCTS?? : 0
??? CATptt?? : 1
??? RTSptt?? : 0
??? DTRptt?? : 0
??? RTS+???? : 0
??? DTR+???? : 1


05:16:57.908 : initialize transceiver
05:16:57.910 : selrig->initialize()
05:16:57.910 : init_rig()
05:16:57.910 : selrig->check()
05:16:57.910 : WriteBuffer:? 00 00 00 03 10
05:16:58.011 : ReadBuffer [50.660000 msec]: 01 01 21 10 00 00 03 04 05 09 0A AE 60 00 00 00 04 00
05:16:58.011 : E: ReadBuffer: ReadBuffer FAILED [50.941000 msec] wanted 28 chars, read 18 chars

05:16:58.012 : ReadBuffer FAILED [50.941000 msec] wanted 28 chars, read 18 chars
05:16:58.063 : ReadBuffer [50.610000 msec]:
05:16:58.063 : E: ReadBuffer: ReadBuffer FAILED [50.743000 msec] wanted 10 chars, read 0 chars

05:16:58.064 : ReadBuffer FAILED [50.743000 msec] wanted 10 chars, read 0 chars
05:16:58.065 : FAILED
05:18:23.361 : WriteBuffer:? 00 41 07 00 0A
05:18:25.073 : WriteBuffer:? 00 40 07 00 0A
05:18:26.130 : WriteBuffer:? 00 41 07 00 0A
05:18:26.961 : WriteBuffer:? 00 42 07 00 0A
05:18:27.073 : WriteBuffer:? 00 43 07 00 0A
05:18:27.233 : WriteBuffer:? 00 44 07 00 0A
05:18:29.313 : WriteBuffer:? 00 43 07 00 0A
05:18:29.377 : WriteBuffer:? 00 42 07 00 0A
05:18:29.441 : WriteBuffer:? 00 41 07 00 0A
05:18:29.521 : WriteBuffer:? 00 40 07 00 0A
05:18:36.466 : WriteBuffer:? 00 40 07 00 0A
05:18:38.723 : WriteBuffer:? 00 40 07 00 0A
05:18:40.659 : WriteBuffer:? 01 40 07 00 0A
05:18:43.043 : WriteBuffer:? 00 40 07 00 0A
05:18:44.451 : WriteBuffer:? 00 40 07 00 0A
05:18:45.059 : WriteBuffer:? 00 40 07 00 0A
05:18:45.539 : WriteBuffer:? 00 40 07 00 0A
05:18:45.603 : WriteBuffer:? 00 40 07 00 0A
05:18:45.653 : WriteBuffer:? 00 40 07 00 0A
05:18:45.704 : WriteBuffer:? 00 40 07 00 0A
05:18:45.763 : WriteBuffer:? 00 40 07 00 0A
05:18:46.323 : WriteBuffer:? 00 40 07 00 0A
05:18:46.387 : WriteBuffer:? 00 40 07 00 0A
05:18:46.772 : WriteBuffer:? 01 40 07 00 0A
05:18:48.692 : WriteBuffer:? 00 40 07 00 0A