开云体育

ctrl + shift + ? for shortcuts
© 2025 Groups.io

#flrig flrig not working with my FT-890 FTDI Programming Cable #flrig


 

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


 

开云体育

Have you experimented with these settings?



David


 

开云体育

Read through the FT-890 pdf manual, and it looks like flrig is expecting to receive the wrong number of bytes.? Please substitute the attached file for the one with the same name in src/rigs/yaesu/.? Report if this corrects the issue.

David

On 4/15/24 00:26, Steve, KB5AW wrote:

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


 

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.


 

The S meter reads lower than the rig's meter.


 

开云体育

Can you please annotate the trace log to indicate what the actual vfo A/B values were at the transceiver.? Thank you.

David

On 4/15/24 23:11, Steve, KB5AW wrote:

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.


 

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


 

开云体育

Thank you Steve.

On 4/16/24 01:13, Steve, KB5AW wrote:

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


 

开云体育

Steve,

Please repeat your testing using the attached file for FT890.cxx

David


 

FLRIG now displays the rig frequency for both VFOs.

Initially did not update frequency from the rig when changing bands. It won't when vfoA/B are out of sync.
FLRIG dies not change to the rig's VFO A/B selection when it is changed from the rig.

Display follows the rig when using the tuning knob, but was initially always one step behind, it displayed the tuning from the previous tuning step.
After using it a while, it started following the rig's frequency properly. It don't know if this happened after I clicked "Activate" or some other reason.

Still does not change the rig frequency when on vfoB and does not follow the rig when vfoB is changed from the rig.

It no longer displays the S meter values.

Mode menu no longer has the AM-narrow and CW-narrow mode selections.

In the FLRIG mode menu, when I change the mode to AM, it goes to CW, and FM selects AM. It does display the rig's selection. Most of the other sections work. It seems to be off after the missing "narrow" menu items.

PTT indicator does not light and meters do not change when I put the rig into transmit, only when the FLRIG PTT button is pressed.

------------------------------------
Rig vfoA frequency 14.300.10 (USB) and agrees with FLRIG
Rig vfoB frequency .580.00 (AM) and agrees with FLRIG

18:22:18.954 : read_vfo()
18:22:18.954 : WriteBuffer:? 00 00 00 03 10
18:22:19.009 : ReadBuffer [4.366000 msec]: 0D 15 D1 FA 00 00 01 04 05 01 00 E2 90 00 00 03 04 85
18:22:19.009 : vfoA active get vfo A
18:22:19.009 : read_mode vfoA active
18:22:19.010 : read: 1
18:22:19.511 : read_vfo()
18:22:19.511 : WriteBuffer:? 00 00 00 03 10
18:22:19.568 : ReadBuffer [6.542000 msec]: 0D 15 D1 FA 00 00 01 04 05 01 00 E2 90 00 00 03 04 85
18:22:19.569 : vfoA active get vfo A
18:22:20.089 : read_vfo()
18:22:20.090 : WriteBuffer:? 00 00 00 03 10
18:22:20.145 : ReadBuffer [4.349000 msec]: 0D 15 D1 FA 00 00 01 04 05 01 00 E2 90 00 00 03 04 85
18:22:20.145 : vfoA active get vfo A
18:22:20.146 : read_mode vfoA active
18:22:20.146 : read: 1
18:22:20.648 : read_vfo()
18:22:20.648 : WriteBuffer:? 00 00 00 03 10
18:22:20.704 : ReadBuffer [5.441000 msec]: 0D 15 D1 FA 00 00 01 04 05 01 00 E2 90 00 00 03 04 85
18:22:20.704 : vfoA active get vfo A


 

The S meter works. I forgot to enable it.


 

开云体育

Steve,

Substitute the attached two files for the ones of the same name in the flrig source tree.? Rebuild and then run from a command line terminal.

Test: Read/Set VFO A
????? Read/Set VFO B
????? Read/Set VFO A/B active
????? Read/Set Split
????? Read Smeter
????? Read power out

73, David


 

I ran FLRIG from the terminal. It initially followed the rig's tuning, but when I tuned the rig to exactly 14.200.00, it disagreed. This is repeatable At 14.200.00. It doesn't do that at frequencies above or below that.
Grig doesn't do that.
Starting FLRIG with the rig set to 14.200.00 causes the rig not found pop-up. The init button does the same. I can change the frequency slightly to fix this.
---
Using VFO A, the rig was tuned to 14.200.00 and FLRIG displayed 14200.02
The terminal displayed
Info: 0D 15 AA E2 00 00 02 04 05 09 0A CB 48 00 00 01 04 85
?? A: 14200020, AM
?? B: 7074000, CW
Flag Bytes??? 80 00 00 08 50
? Split:????? OFF? Active vfo: B? PTT:??????? OFF

failed to read VFO status bytes (18)
failed to read VFO status bytes (18) ...repeating...
---

The yellow light in the PTT button lights when the rig is transmitting.

* Read/Set VFO A
I can set the frequency from FLRIG or the rig (except as noted above)

* Read/Set VFO B
When I click vfoB, FLRIG displays the vfoB frequency from the rig. FLRIG display follows the rig's VFO, but I cannot change the rig's frequency by changing vfoB on FLRIG. FLRIG just reverts back to the rig's frequency.
vfoB does not have the problem with 14.200.00 that vfoA has.

* Read/Set VFO A/B active
The FLRIG highlight follows the VFO A/B setting from the rig.
The rig switches to the VFO that FLRIG requests.

* Read/Set Split
The yellow light in FLRIG's Split button does not change when split mode is changed from the rig.
The rig and the split button light agree when set from FLRIG.

* Read Smeter
S meter follows the rig's meter relative to the signal, however FLRIG reads lower.

* Read power out
On the FLRIG 100 watt scale, with 100 watts on the rig, FLRIG showed 55 watts and changes with power output.
The FT-890 needs 50 watt and 150 watt scales.

The modulation mode menu puts the rig into the correct mode, but the menu changes to read something else:
LSB reads LSB
USB reads CW
CW reads AM
CW-N reads AM
AM reads FM
AM-N reads FM
FM reads LSB
FM-N reads LSB

Sometimes when FLRIG is started or quit, changes the rig to a frequency and mode other than it was set to.
It seems to eventually leave the frequency unchanged when I keep setting it back to the desired frequency.
Maybe mode problem could be from the mode menu issue.


 

I tried the new test release flrig-2.0.05.48.

It still works like my previous post. I guess it is still like the last patches you sent.
I know you have been busy with fldigi lately.


 

I wanted to see about fixing the Yaesu FT-890 rig in flrig, so I looked at the code and did some hacking.
I suggest that you look at the code for correctness.
I used flrig-2.0.05.75
I got the modes selection menu to basically work, but more changes are needed.
Here is what I did by modifying the attached src/rigs/yaesu/FT890.cxx
?
vfoA and vfoB worked differently.
- Line 341 for set_modeA is:
? ? cmd[3] = FT890_mode_val[val];
?
- Line 366 for set_modeB is different. I changed it to be like line 341.
? ? cmd[3] = FT890_mode_val[val] | 0x80;
Now: cmd[3] = FT890_mode_val[val];
?
Now both vfos work the same for mode.
-----
I worked with with the switch statement on line 249. Added case 4 for FM mode.
The changes I made work for the base modes, but the menu does not track wide/narrow. My rig does not seem to have FM narrow and I don't see it in the manual.
Note that only modes which have 2 bandwidths are incremented by 2.
A.iBW? on line 244 seems to be the filter bandwidth, but isn't used anywhere.
Note that for setting Mode, values are: LSB=0, USB=1, CW-wide=2, CW-nar=3, AM-wide=4, AM-nar=5, FM=6 or 7.
For reading Mode, the values are: 0=LSB, 1=USB, 2=CW, 3=AM, 4=FM. BPF selection is indicated by byte 0.
?


 

开云体育

Thank you Steve.? Please confirm that these are the changes you implemented:


diff src/rigs/yaesu/FT890.cxx FT890.cxx

251,253c251,254
< ??? ??? ??? case 1: A.imode = ((replystr[6] & 0x40) == 0x40) ? 3 : 2; break;
< ??? ??? ??? case 2: A.imode = ((replystr[6] & 0x80) == 0x80) ? 5 : 4; break;
< ??? ??? ??? case 3: A.imode = ((replystr[6] & 0x80) == 0x80) ? 7 : 6; break;
---
> ??? ??? ??? case 1: A.imode = ((replystr[6] & 0x40) == 0x40) ? 3 : 1; break;
> ??? ??? ??? case 2: A.imode = ((replystr[6] & 0x80) == 0x80) ? 5 : 2; break;
> ??? ??? ??? case 3: A.imode = ((replystr[6] & 0x80) == 0x80) ? 7 : 4; break;
> ??? ??? ??? case 4: A.imode = ((replystr[6] & 0x80) == 0x80) ? 9 : 6; break;
268,270c269,272
< ??? ??? ??? case 1: B.imode = ((replystr[15] & 0x40) == 0x40) ? 3 : 2; break;
< ??? ??? ??? case 2: B.imode = ((replystr[15] & 0x80) == 0x80) ? 5 : 4; break;
< ??? ??? ??? case 3: B.imode = ((replystr[15] & 0x80) == 0x80) ? 7 : 6; break;
---
> ??? ??? ??? case 1: B.imode = ((replystr[15] & 0x40) == 0x40) ? 3 : 1; break;
> ??? ??? ??? case 2: B.imode = ((replystr[15] & 0x80) == 0x80) ? 5 : 2; break;
> ??? ??? ??? case 3: B.imode = ((replystr[15] & 0x80) == 0x80) ? 7 : 4; break;
> ??? ??? ??? case 4: B.imode = ((replystr[15] & 0x80) == 0x80) ? 9 : 6; break;
364c366
< ??? cmd[3] = FT890_mode_val[val] | 0x80;
---
> ??? cmd[3] = FT890_mode_val[val];

73, David, W1HKJ

On 9/24/24 18:38, Steve, KB5AW wrote:

I wanted to see about fixing the Yaesu FT-890 rig in flrig, so I looked at the code and did some hacking.
I suggest that you look at the code for correctness.
I used flrig-2.0.05.75
I got the modes selection menu to basically work, but more changes are needed.
Here is what I did by modifying the attached src/rigs/yaesu/FT890.cxx
?
vfoA and vfoB worked differently.
- Line 341 for set_modeA is:
? ? cmd[3] = FT890_mode_val[val];
?
- Line 366 for set_modeB is different. I changed it to be like line 341.
? ? cmd[3] = FT890_mode_val[val] | 0x80;
Now: cmd[3] = FT890_mode_val[val];
?
Now both vfos work the same for mode.
-----
I worked with with the switch statement on line 249. Added case 4 for FM mode.
The changes I made work for the base modes, but the menu does not track wide/narrow. My rig does not seem to have FM narrow and I don't see it in the manual.
Note that only modes which have 2 bandwidths are incremented by 2.
A.iBW? on line 244 seems to be the filter bandwidth, but isn't used anywhere.
Note that for setting Mode, values are: LSB=0, USB=1, CW-wide=2, CW-nar=3, AM-wide=4, AM-nar=5, FM=6 or 7.
For reading Mode, the values are: 0=LSB, 1=USB, 2=CW, 3=AM, 4=FM. BPF selection is indicated by byte 0.
?


 

Thanks for looking at this.
?
Yes, those are the changes that I made.
I don't understand your menu system and all that are in these statements, so you should review approve them.
The changes do not take into consideration the filter bandwidth, so something needs to be done about that. There should be something for CW-N and AM-N. I don't think that FM-N exists.
It all comes from the mode information is different between the reading and writing of it.
?


 

开云体育

Steve,

I read through the CAT pages for the FT-890 and I think this is what you want for the mode/width code:

enum {FT_LSB, FT_USB, FT_CWW, FT_CWN, FT_AMW, FT_AMN, FT_FM};

static std::vector<std::string>FT890modes_;
static const char *vFT890modes_[] = {
?? ???? "LSB", "USB", "CW-W", "CW-N", "AM-W", "AM-N", "FM" };
static const int FT890_mode_val[] =? { 0, 1, 2, 3, 4, 5, 6 };

...

?? ???? switch (replystr[6] & 0x07) {
?? ???? ??? case 0: A.imode = FT_LSB; break;
?? ???? ??? case 1: A.imode = FT_USB; break;
?? ???? ??? case 2: case 3: A.imode = ((replystr[8] & 0x80) == 0x80) ? FT_CWN : FT_CWW; break;
?? ???? ??? case 4: case 5: A.imode = ((replystr[8] & 0x40) == 0x40) ? FT_AMN : FT_AMW; break;
?? ???? ??? case 6: case 7: A.imode = FT_FM;
?? ???? }

?? ???? B.iBW = (replystr[9] & 1);
?? ???? B.freq = 10 * ((((replystr[10] & 0xFF) * 256 +
?? ???? ??? ??? ?? (replystr[11] & 0xFF) ) * 256 +
?? ???? ??? ??? ?? (replystr[12] & 0xFF) ) );

?? ???? switch (replystr[15] & 0x07) {
?? ???? ??? default:
?? ???? ??? case 0: B.imode = FT_LSB; break;
?? ???? ??? case 1: B.imode = FT_USB; break;
?? ???? ??? case 2: case 3: B.imode = ((replystr[17] & 0x80) == 0x80) ? FT_CWN : FT_CWW; break;
?? ???? ??? case 4: case 5: B.imode = ((replystr[17] & 0x40) == 0x40) ? FT_AMN : FT_AMW; break;
?? ???? ??? case 6: case 7: B.imode = FT_FM;
?? ???? }





see attached.

David, W1HKJ

On 9/24/24 19:55, Steve, KB5AW wrote:

Thanks for looking at this.
?
Yes, those are the changes that I made.
I don't understand your menu system and all that are in these statements, so you should review approve them.
The changes do not take into consideration the filter bandwidth, so something needs to be done about that. There should be something for CW-N and AM-N. I don't think that FM-N exists.
It all comes from the mode information is different between the reading and writing of it.
?


 

I tried your changes.
It seems to revert to the incorrect operation before the changes I submitted.
I don't see how your case statement can work for the modes. The only valid numbers in byte 6 are 0, 1, 2, 3, 4.
You use case numbers based on byte 6 ranging from 0 to 7 which correspond to the menu, but doesn't correspond to the data from the rig on byte 6.
For example, CW is 2 whether or not it is wide or narrow. In the menu, the numbers are 2 and 3 respectively.
?
So, I reverted to my version of FT890.cxx which worked for all of the non-narrow modes and added if statements to fix the narrow modes.
vfo-a now works correctly on all modes. Maybe you can do it in a better way or make any corrections.
I did not make the changes for vfo-b.
------------------------
? ? ? ? switch (replystr[6] & 0x07) {
? ? ? ? ? ? case 0: A.imode = ((replystr[6] & 0x40) == 0x40) ? 1 : 0; break; // LSB
? ? ? ? ? ? case 1: A.imode = ((replystr[6] & 0x40) == 0x40) ? 3 : 1; break; // USB
? ? ? ? ? ? case 2: A.imode = ((replystr[6] & 0x80) == 0x80) ? 5 : 2; break; // CW
? ? ? ? ? ? case 3: A.imode = ((replystr[6] & 0x80) == 0x80) ? 7 : 4; break; // AM
? ? ? ? ? ? case 4: A.imode = ((replystr[6] & 0x80) == 0x80) ? 9 : 6; break; // FM
? ? ? ? ? ? default: A.imode = 0;
? ? ? ? }
?
// After the base mode has been determined, we need to check for the narrow filters.
// We need to verify the base mode, as the narrow mode bits remain on until changed.
?
? ? ? ? if (((replystr[8] & 0x80) == 0x80) && (A.imode == 2)) {
? ? ? ? ? ? A.imode = 3; // CW-N
? ? ? ? }
? ? ? ? if (((replystr[8] & 0x40) == 0x40) && (A.imode == 4)) {
? ? ? ? ? ? A.imode = 5; // AM-N
? ? ? ? }
------------------------


 

开云体育

Thanks Steve.? Very confusing CAT commands.

David

On 10/3/24 03:07, Steve, KB5AW wrote:

I tried your changes.
It seems to revert to the incorrect operation before the changes I submitted.
I don't see how your case statement can work for the modes. The only valid numbers in byte 6 are 0, 1, 2, 3, 4.
You use case numbers based on byte 6 ranging from 0 to 7 which correspond to the menu, but doesn't correspond to the data from the rig on byte 6.
For example, CW is 2 whether or not it is wide or narrow. In the menu, the numbers are 2 and 3 respectively.
?
So, I reverted to my version of FT890.cxx which worked for all of the non-narrow modes and added if statements to fix the narrow modes.
vfo-a now works correctly on all modes. Maybe you can do it in a better way or make any corrections.
I did not make the changes for vfo-b.
------------------------
? ? ? ? switch (replystr[6] & 0x07) {
? ? ? ? ? ? case 0: A.imode = ((replystr[6] & 0x40) == 0x40) ? 1 : 0; break; // LSB
? ? ? ? ? ? case 1: A.imode = ((replystr[6] & 0x40) == 0x40) ? 3 : 1; break; // USB
? ? ? ? ? ? case 2: A.imode = ((replystr[6] & 0x80) == 0x80) ? 5 : 2; break; // CW
? ? ? ? ? ? case 3: A.imode = ((replystr[6] & 0x80) == 0x80) ? 7 : 4; break; // AM
? ? ? ? ? ? case 4: A.imode = ((replystr[6] & 0x80) == 0x80) ? 9 : 6; break; // FM
? ? ? ? ? ? default: A.imode = 0;
? ? ? ? }
?
// After the base mode has been determined, we need to check for the narrow filters.
// We need to verify the base mode, as the narrow mode bits remain on until changed.
?
? ? ? ? if (((replystr[8] & 0x80) == 0x80) && (A.imode == 2)) {
? ? ? ? ? ? A.imode = 3; // CW-N
? ? ? ? }
? ? ? ? if (((replystr[8] & 0x40) == 0x40) && (A.imode == 4)) {
? ? ? ? ? ? A.imode = 5; // AM-N
? ? ? ? }
------------------------