Re: [Hamlib-developer] Strange problem with response from IC-7300

[Sakari N. <sak...@ni...>]

Hi Steve!

I have seen similar, but very seldom.
When I was rewriting CqrlogAlpha rigcontrol that uses simple text based 
TCP connections to Hamlib (no direct library access).
I start rigctld always via script before any other ham program and then 
use rig model #2 "Net Hamlib rigctld" for all my program settings.
That way there is only one USB serial user; rigctld started by script 
and running on background. No collisions in serial line usage.

So my goal was to create one TCP connection for FMV polling (frequency, 
mode, vfo) as timer based and another TCP connection for direct
user commands like change band, tune, rit, split etc.
Third TCP connection is made for hamlib CW keying.

It did not succeed by the way I was planing. The main problem was not 
with Hamlib, but my code that mixed receive events between those two TCP 
connections.
But while testing I found few times similar RPRT -11 responses. Thought 
then it was just caused by my code.
Returned back to one TCP connection for rig control and mixed poll + 
user command stack with timer spooling that seems to be more stable, but 
has slower response.

Do you start rigctld with "--vfo" or without? That changes the command 
structure. It can be checked with \chk_vfo at the beginning of program.
Depending on answer you need to use "f" or "f currVFO" for frequency query.
And then comes the nasty part. If you need "f currVFO" but issue only 
"f" you may expect very weird responses for following other commands
until rigctld gets back to right track again (may take few commands).
And there are many commands, but not all (that are not listed), 
requiring "currVFO" addition if the startup parameter --vfo is used.

What really is needed is a "flush" byte that could be sent before any 
new command to ensure that last issued command, succeeded or not, is 
completely forgotten.

Or better error handling for command interpreter in case where wrong 
formatted command is issued and ended with linefeed that should trigger 
the command format checking.

I.E. if you send "f" when "f currVFO" is needed the response should be 
RPRT -8. Now there is no response at all and next command will be added 
to already sent "f" causing a weird combined command and also unexpected 
response and RPRT.

These are just my thoughts...

-- 
Saku
OH1KH

Stephen Pattinson via Hamlib-developer kirjoitti 16.5.2025 klo 9.32:
> Hi,
>
> I have a python program that starts rigctld in the background and then 
> interrogates my IC-7300 by using the TCP access to rigctld. This works 
> 100% reliably and retrieves the frequency, tx state and mode of the 
> radio every second.
>
> Whilst experimenting with the "wfview" program which connects to the 
> IC-7300 and allows the radio to be controlled by a PC, I have come 
> across an odd problem. If I run the run the wfview program (which 
> works just fine) and then exit the program and then execute by Python 
> program as described above, my program intermittently malfunctions. 
> Note I'm not trying to do these things at the same time. They both 
> require access to the IC-7300 USB port.
>
> To be specific, the response to the "get_freq" command using the 
> extended protocol is for example as follows (in a python byte array)
>
>     b'get_freq:|Frequency: 14243000|RPRT 0\n'
>
> However, if I had previously run (and terminated) the wfview program, 
> the response to the "get_freq" command is occasionally as follows
>
>     b'get_freq:|RPRT -11\n'
>
> Ie the actual frequency message is missing and back end code -11 is 
> returned.
>
> The analogous thing happens for "get_ptt" and "get_mode" commands 
> every once in a while, although the error code is different.
>
> If I cycle the power on the radio, the problem goes away, so clearly 
> the wfview has changed something in the radio, but I have been unable 
> so far to see any config that  it has changed that might have a 
> bearing on this issue. I'm hoping that either the "-11" error code 
> might convey a clue to the problem, or that someone might have come 
> across this as well.
>
> I get the same malfunction if I use the "simple" protocol instead.
>
> I don't believe this is a hamlib error, but I'm hoping that someone 
> here might have a suggestion for me to try.
>
> Thanks de VK3SPX (Steve)
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer