Re: [Hamlib-developer] rigctld telnet startup delay

[Black M. <mdb...@ya...>]

I had an idea that seems to work -- try the latest master.

If you provide -C autopower_on=0 on the rigctld line it will not try and open the rig at all during startup.

Mike W9MDB








On Wednesday, January 4, 2023 at 04:59:03 PM CST, Black Michael <mdb...@ya...> wrote: 





Any particular reason you can't let rigctld turn the power on and cqrlog can turn it off if it wants?


Trying to start rigctld without a powered-on rig would not be a trivial thing for Hamlib to do.  Lots of checking during startup.


Mike W9MDB








On Wednesday, January 4, 2023 at 10:59:36 AM CST, Saku <oh...@sr...> wrote: 






Saku kirjoitti 3.1.2023 klo 13.49:


>  
Hi !

I return to this subject that I have sent once to Mike  @ Jul-2022. 
There is a problem in rigctld start (delay telnet server to be ready) if rig is powered OFF.

-----------------------------------------------------------------------------




Blowing in the wind...


Updated and compiled to Hamlib version Jan 3 2023
Still rigctld telnet server opens delayed if rig (IC7300) is powered off.  
And that is what I did expect.

Because of fixed Cqrlog rigControl procedures now if connection to rigctld is refused, like it is when rig power is off, it will retry connection 10 times with one second waiting time.
That helps and Cqrlog gets connected after 7 tries.

Then another problem arises:

1) If rig is powered during startup everything goes very smoothly, like it has done also before my fix.


2) If rig is not powered, but parameter "-C autopower_on=1" is set at rigctld start, everything runs ok after connection to rigctld is first refused two (2) times. 3rd repeat try opens connection and all works.

3) if parameter "-C autopower_on=0" and I want Cqrlog to set rig power on with command "set_powerstat 1" it goes like follows:
Cqrlog sends :

Waiting for rigctld 7 @ 127.0.0.1:4532
Connected to rigctld
Sending: +\chk_vfo
Msg from rig:|CHKVFO: 0|
"--vfo" checked:0
Sending: +\dump_caps

Msg from rig:|DUMP_CAPS:
CAPS DUMP FOR MODEL: 3073

... text removed here ...

CAN GET MW2POWER: Y
OVERALL BACKEND WARNINGS: 0
RPRT 0|
Cqrlog can get VFO: FALSE
Cqrlog can switch power: TRUE
Cqrlog can send Morse: TRUE
Sending: +\set_powerstat

Then problems start. It takes several seconds before rig power is switched on.Several times longer than when it is done by "-C autopower_on=1"

Finally the response returns, how ever it is:

Msg from rig:|SET_POWERSTAT: 1
RPRT -5|
Power on, start polling
Poll Sending: +f +m +v
Msg from rig:|GET_FREQ:
RPRT -9|
Msg from rig:|GET_MODE:
MODE:
PASSBAND: 0
RPRT 0|
Msg from rig:|GET_VFO:
RPRT -11|

Poll Sending: +f +m +v
Msg from rig:|GET_FREQ:
RPRT -9|
Msg from rig:|GET_MODE:
MODE: LSB
PASSBAND: 2400
RPRT 0|
Msg from rig:|GET_VFO:
RPRT -11|




And because SET_POWERSTAT went to state RPRT -5 Then  GET_FREQ always reports RPRT -9 no matter how long I wait !




I have loaded to my Google drive two debug files that have combined Cqrlog and rigctld debugs (mixed). 
First with succeeded (rig was powered at start), and second failed (rig power was OFF at start) startups.

Start_with_rig_powered_mixed_debug_Cqrlog_and_rigctld.pdf
   https://drive.google.com/file/d/1Lh7YWQsmEPk0WvWaKpE51NDVbOrE5VCA/view?usp=sharing

Start_with_rig_NOT_powered_mixed_debug_Cqrlog_and_rigctld.pdf
   https://drive.google.com/file/d/1hlormcoPf8i8TIdmXCeu7mWRi3ZGvVid/view?usp=sharing




When Cqrlog sends +\set_powerstat it stops and waits until it gets response.
After that it waits a second and then starts polling rig ("Power on, start polling" show in debug)
So it can not fill rigctld's TCP receiving buffer before response to set_powerstat is received.


I do not know what I should send to rigctld to make it happy and stop sending RPRT -9 ! Possible bug?


P.S.

Adding rigctld start parameter "--vfo" changes rig polling to:


Poll Sending: +f currVFO +m currVFO +v

Msg from rig:|GET_FREQ: CURRVFO
RPRT -9|


But has no effect to this problem.


  --
Saku
OH1KH
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer