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

[Dave B <g8k...@go...>]

Thanks Mike.

I'll test shortly.  Currently about to be tasked with domestic duties!

I'll be back!

73.

Dave G8KBV


On 13/12/2022 05:59, Black Michael wrote:
> 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

-- 
Created on and sent from a Unix like PC running and using free and open source software: