Issue with JRC-535D

[markjfine]

Good to see this is being maintained again. Gave me a reason to rebuild from the git repo and test out with my JRC-535D on some new computers I just got.

Noticed some quirkiness in some of the tuning and some controls not being active (namely the mode). It's been ages since I worked on the JRC section of Hamlib so the problem could be in there as well.

Given time I'll investigate and report back.

[mattmelling]

Do you get any output from the \get_modes command using rigctl?

[markjfine]

At first blush it looks like it could be multiple issues in Hamlib, the least of which being that it may not like the bluetooth serial device I'm using (2021 Mac M1 running Ventura 13.1). Making things harder is they've apparently removed the Power on/off function that was there in v4.5 (used in the picture above). What a mess. ---------8<------------- rigctl.c(445) Startup: rigctl -vvvv -m 6006 -r /dev/tty.SerialAdapter -s 4800 m rigctl Hamlib 4.6~git Jan 07 05:31:18Z 2023 SHA=eb9041 Report bugs to hamlib-developer@lists.sourceforge.net

initrigs4_jrc: _init called rig_init: rig_model=JRC NRD-535D rig_init: rig does not have tx_range!! rig_init: rig has VFO_MEM 1:rig.c(814):rig_open entered rig_settings_load_all: settings_file (/Users/mark/.config/hamlib_settings): No such file or directory rig_open: cwd=/Users/mark rig_open: /Users/mark/hamlib_settings does not exist serial_open: /dev/tty.SerialAdapter 2:rig.c(7433):async_data_handler_start entered 2:rig.c(7440):async_data_handler_start returning(0) rig.c(254):add_opened_rig returning2(0) rig_open: 0x11f80bc1c rs->comm_state==1?=1 rig_get_freq(1987) called vfo=VFOA rig.c(1996) vfo=VFOA, curr_vfo=currVFO rig_get_freq(2083): vfo_opt=0, model=6006 jrc_set_vfo: unsupported VFO VFOA rig.c(2132):rig_get_freq returning2(-1) Invalid parameter

1:rig.c(1372):rig_open returning(0) Opened rig model 6006, 'NRD-535D' Backend version: 20200320.0, Status: Stable 1:rig.c(6039):rig_get_powerstat entered read_string_generic(): Timed out 0.205 seconds after 0 chars, direct=1 1:rig.c(6061):rig_get_powerstat returning(-5) Communication timed out

rigctl_parse: rig_powerstat is not on = 0 1:rigctl_parse.c(2260):rigctl_get_mode entered 2:rig.c(2406):rig_get_mode entered read_string_generic(): Timed out 0.202 seconds after 0 chars, direct=1 3:cache.c(35):rig_set_cache_mode entered 3:cache.c(108):rig_set_cache_mode returning(0) 2:rig.c(2539):rig_get_mode returning(-5) Communication timed out

1:rigctl_parse.c(2266):rigctl_get_mode returning(-5) Communication timed out

get_mode: error = write_block(): TX 6 bytes, method=2 read_string_generic called, rxmax=32 direct=1, expected_len=1 read_string_generic(): Timed out 0.202 seconds after 0 chars, direct=1 rig_get_mode: retcode after get_mode=-5 rig_get_mode(2481): freqMainA=0, modeMainA=, widthMainA=0 rig_get_mode(2481): freqMainB=0, modeMainB=, widthMainB=0 3:cache.c(35):rig_set_cache_mode entered rig_set_cache_mode(37): freqMainA=0, modeMainA=, widthMainA=0 rig_set_cache_mode(37): freqMainB=0, modeMainB=, widthMainB=0 rig_set_cache_mode(107): freqMainA=0, modeMainA=, widthMainA=0 rig_set_cache_mode(107): freqMainB=0, modeMainB=, widthMainB=0 3:cache.c(108):rig_set_cache_mode returning(0) rig_get_mode(2536): freqMainA=0, modeMainA=, widthMainA=0 rig_get_mode(2536): freqMainB=0, modeMainB=, widthMainB=0 2:rig_get_mode: elapsed=225ms 2:rig.c(2539):rig_get_mode returning(-5) Communication timed out

1:rigctl_parse.c(2266):rigctl_get_mode returning(-5) Communication timed out

Communication timed out

main: i/o error 1:rig.c(1394):rig_close entered 2:rig.c(7477):async_data_handler_stop entered 2:rig.c(7507):async_data_handler_stop returning(0) ser_close: restoring options rig_close(1530): 0x11f80bc1c rs->comm_state==0?=0 1:rig.c(1532):rig_close returning(0) main: rig_close retcode=0 1:rig.c(814):rig_open entered rig_settings_load_all: settings_file (/Users/mark/.config/hamlib_settings): No such file or directory rig_open: cwd=/Users/mark rig_open: /Users/mark/hamlib_settings does not exist serial_open: /dev/tty.SerialAdapter 2:rig.c(7433):async_data_handler_start entered 2:rig.c(7440):async_data_handler_start returning(0) rig.c(254):add_opened_rig returning2(0) rig_open: 0x11f80bc1c rs->comm_state==1?=1 rig_get_freq(1987) called vfo=VFOA rig.c(1996) vfo=VFOA, curr_vfo=currVFO rig_get_freq(2083): vfo_opt=0, model=6006 jrc_set_vfo: unsupported VFO VFOA rig.c(2132):rig_get_freq returning2(-1) Invalid parameter

1:rig.c(1372):rig_open returning(0) main: rig_open retcode=0 1:rig.c(1394):rig_close entered 2:rig.c(7477):async_data_handler_stop entered 2:rig.c(7507):async_data_handler_stop returning(0) ser_close: restoring options rig_close(1530): 0x11f80bc1c rs->comm_state==0?=0 1:rig.c(1532):rig_close returning(0) ---------8<------------- I should point out that rigctl gives me something similar when trying to /get_freq even though grig gets the frequency. So make of that what you will. So unless I'm not setting rigctl correctly, I don't think it will be much help.

[markjfine]

In interactive mode, I'm now getting mixed results from rigctl, so it could also be the delay timing in the rig module: -------------8<----------------- rigctl -m 6006 -r /dev/tty.SerialAdapter -s 4800

Rig command: \get_freq Frequency: 15000000

Rig command: \get_mode Mode: AM Passband: 6000

Rig command: \get_freq Frequency: 15000000

Rig command: \get_mode get_mode: error = write_block(): TX 6 bytes, method=2 read_string_generic called, rxmax=32 direct=1, expected_len=1 read_string_generic(): Timed out 0.205 seconds after 0 chars, direct=1 rig_get_mode: retcode after get_mode=-5 rig_get_mode(2481): freqMainA=15000000, modeMainA=AM, widthMainA=6000 rig_get_mode(2481): freqMainB=0, modeMainB=, widthMainB=0 3:cache.c(35):rig_set_cache_mode entered rig_set_cache_mode(37): freqMainA=15000000, modeMainA=AM, widthMainA=6000 rig_set_cache_mode(37): freqMainB=0, modeMainB=, widthMainB=0 rig_set_cache_mode(107): freqMainA=15000000, modeMainA=AM, widthMainA=6000 rig_set_cache_mode(107): freqMainB=0, modeMainB=, widthMainB=0 3:cache.c(108):rig_set_cache_mode returning(0) rig_get_mode(2536): freqMainA=15000000, modeMainA=AM, widthMainA=6000 rig_get_mode(2536): freqMainB=0, modeMainB=, widthMainB=0 2:rig_get_mode: elapsed=232ms 2:rig.c(2539):rig_get_mode returning(-5) Communication timed out

1:rigctl_parse.c(2266):rigctl_get_mode returning(-5) Communication timed out

Communication timed out

Rig command: \get_mode Mode: AM Passband: 6000

Rig command: \get_freq get_freq: error = rig_get_freq(2017): freqMainA=15000000, modeMainA=AM, widthMainA=6000 rig_get_freq(2017): freqMainB=0, modeMainB=, widthMainB=0 rig_get_cache(258): vfo=currVFO, current_vfo=currVFO rig_get_cache(434): vfo=VFOA, freq=15000000, mode=AM, width=6000 rig_get_freq(2053): freqMainA=15000000, modeMainA=AM, widthMainA=6000 rig_get_freq(2053): freqMainB=0, modeMainB=, widthMainB=0 rig_get_freq: cache miss age=29638ms, cached_vfo=currVFO, asked_vfo=currVFO, use_cached_freq=0 rig_get_freq(2083): vfo_opt=0, model=6006 rig_flush: called for serial device read_string_generic called, rxmax=4095 direct=1, expected_len=1 write_block(): TX 6 bytes, method=2 read_string_generic called, rxmax=32 direct=1, expected_len=1 read_string_generic(): Timed out 0.204 seconds after 0 chars, direct=1 rig_get_freq(2100): freqMainA=15000000, modeMainA=AM, widthMainA=6000 rig_get_freq(2100): freqMainB=0, modeMainB=, widthMainB=0 rig_set_cache_freq(121): vfo=currVFO, current_vfo=currVFO 1:rig_get_freq: elapsed=228ms 1:rigctl_parse.c(2124):rigctl_get_freq returning(-5) Communication timed out

Communication timed out

Rig command: \get_freq Frequency: 15000000

[fillods]

Looking at the debug messages, most of the time failures are because of a timeout. Could it be the Bluetooth serial device that delays the IO ? If this is not the device by itself, could it the driver/OS that delays the IO (energy saving possibly getting in the way, ..) ? As a test, can you do without the Bluetooth serial device, and instead use a real serial cable (well through USB computer side) ?

Have you tried increasing the Hamlib backend timeout ? Something like passing option -C timeout=1000

[markjfine]

Ok. Managed to get rid of the timeouts in rigctl by increasing the .post_write_delay to 21 and .timeout to 250 (was 20 and 200) in Hamlib.

Despite this, grig is still exhibiting the same behaviour wrt the mode control. Per above, mode and bandwidth are a ganged response for JRC so this may be part of the problem). A new issue that just cropped up with Hamlib 4.6 on git is now the power button appears to be disabled, although it will show power status (e.g., depressed for on). I'll look at the code to see what I can come up with on that front.

[markjfine]

@fillods

The timeouts have never been a problem before, even when using it in Frequency Browser. Based on the math, 20 and 200 was too short for a 10-character string at 4800bps anyway.

But your point is taken. TBH, the whole bluetooth thing is a disaster when it comes to macOS Ventura. There was probably a very good reason why I bought it some time ago but macOS has a lot of problems recognising it from power-up, then having to pair it every time. It works pretty good once it gets going, it's just the "getting going" part that is driving me absolutely bonkers.

I'm putting in an order for a couple of cheap PL2303 USB-232 devices off of Amazon which hopefully does better.

[markjfine]

One other clue: I put some debug code in rig_gui_ctrl2_create_mode_selector(), once in the beginning to see what rig_data_get_all_modes() returns, then in the loop to see what gets added to the widget.

Turns out rig_data_get_all_modes() returns 0. This is strange, since the modes are listed with the step sizes in the Info dialog (and \get_modes returns a correct listing in rigctl). So something isn't filling the bitfield in get.allmodes properly.