Re: [Hamlib-developer] Bug: Yaesu FT-736r

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

Try the latest github master.
Should be fixed now and rigctld will release the rig when the last client disconnects.
If you're getting two rigctld's then you must be running them on different ports otherwise the 2nd one would not start.
Mike W9MDB 

    On Monday, December 12, 2022 at 07:01:44 PM CST, Dave B via Hamlib-developer <ham...@li...> wrote:  
 
  Hi Daniele.   Thanks for the quick reply...
 
 Ohh..  How did I miss that!...  "Eyes painted on", again...
 
 Anyway, invoking it thus...  (From a bash script)
 ~/Local/bin/rigctld -m1010 -R -T localhost -t 50736 -r /dev/ttyFT736 -s 4800 &
 
 (Running in the test build folder)
 
 I still get control of the radio OK when "Engaging" it in Gpredict, but when "Disengaging" the radio still does not get released from CAT control.  :-(   That then needs a power cycle of the radio to regain front panel control.
 
 With Htop running in an independent terminal, I can see one instance of rigctld when it is first loaded, before my Python script is started, and later Gpredict also started.
 
 When the Gpredict user later "Engages" the radio, a second instance/job of rigctld starts, & the radio becomes controlled by the PC and runs fine.  (But the user is locked out of the radio's front panel for many functions other than level controls.  These older Yaesu's were a bit weird...)
 
 When Gpredict's user "Disengages" the radio (to change to a different satellite for example) that second instance of rigctld vanishes, but the radio stays locked as it has not been released from CAT control, when using the 4.x Hamlib code.  Using Bills 3.3 version rigctld code, the radio is released just fine.
 
 Of note though, is that when rigctld is first invoked with BOTH versions, the rig is briefly placed under CAT control, and then released, before Gpredict is started, and the radio later "Engaged."   So, the 4.x code can do it, but that releasing of control is not being triggered by the sole client disconnecting after first use.
 
 Running with the Hamlib 3.3 version of rigctld.  Then the above happens the same, but when the Gpredict user disengages the radio (or Gpredict is closed) the CAT release command is sent by rigctld and the FT-736 backend, and the rig is returned to local control.
 
 I also found that placing the '-R' elsewhere in the 4.x command line invocation in the script, results in errors relating to '-- R needing more parameters' !   As well as printing the entire -h text to stdio!
 
 I have attached the bash gprun.sh startup script, and the python rigsrv.py code.  (All my code, good or bad.)
 The version of Gpredict I have, is V2.2.1, as it is stable, and works well.
 
 There are some comments in my Python code that may be of interest relating to this issue, sending a command to the radio, that will NOT return a reply of any sort, causing Hamlib to stall for some seconds.  (And often not work reliably after that) before Bill's modification.
 
 If I have done something "Wrong", or could do it "Better", I would like to know what, why it is bad, and how to correct it.
 But it remains that with the old 3.3 version of Hamlib with Bill's modification, it all worked very reliably. 
 
 It's well past the Witching hour now, so 73 from me.
 
 Dave G8KBV
 
 
 On 12/12/2022 20:52, Daniele Forsi wrote:
  
 Hi Dave,

 
  I can't see any significant > difference between the 3.3 and 4.1.5 instances
of the FT736 sources, so it must be elsewhere.
 
 I think that the difference is in rigctld.c

Have you tried this command line option?
  -R, --rigctld-idle            make rigctld close the rig when no
clients are connected

 
 
 -- 
Created on and sent from a Unix like PC running and using free and open source software: _______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer