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

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

Resent without attached screen scrapes....

On 13/12/2022 13:52, Dave B wrote:
> Morning...
>
> Pulled the updated master, bootstrapped, configured, and built without 
> error.
>
> Editing my gpredict start-up script to point at the new /bin folder 
> with this new build, and then invoking it from a terminal letting it 
> bring up rigctld and then Gpredict, and it all seems to work as 
> intended now.
>
> So...   Yay...  The non-releasing of the radio when the sole/last 
> client disconnects is Fixed!   (Happy dance commences!)
>
> But...  I've now found that this new version does something else odd.
>
> It successfully puts the rig into "Satellite" Mode just fine when 
> FIRST Engaged.
>
> But after a Disengage, it seems unable to put the rig back into 
> "Satellite" for subsequent "Engagements."
> (Happy dance cancelled!)
>
>
> Reverting back to the old Hamlib 3.3 (with Bill's mod'.)  That can 
> engage the rig in Satellite mode, and disengage/release, re-engage etc 
> multiple times without problems.
>
>
> So, one bug (not releasing when the last/sole client disconnects from 
> rigctld)  fixed.
>
> But another found, not commanding into Satellite mode for a subsequent 
> "Engagements" after the first successful "Engage" / "Disengage" 
> session.  :-(
>
>
> I went back and checked the earlier 4.5.1 that would not correctly 
> release the rig.   That "appears" to re-engage Satellite mode, but I 
> think in truth, that not dis-engaging/releasing the radio, is keeping 
> the radio in Satellite mode for subsequent "engagements" regardless...
>
> I currently do not have a way to monitor the actual serial I/O traffic 
> between computer and radio.
> I know some "magic" can be done with the likes of socat, but I 
> personally have never managed to make that work successfully... (I 
> find lots of conflicting advice/methods when searching for examples of 
> such things, and no, the man-pages are not a user manual, good as 
> aid-memiour tools, but not detailed enough for this idiot to figure 
> out such detail from scratch...)
>
> Anyway...  Thanks for everyone's time, but sadly, still a bug to squash...
>
> I can test more if wished.
>
> 73.
> Dave G8KBV (or G0WBX) both valid, I can talk to myself, but still no 
> "intelligence" found!  ;-)
>
>
> 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
>>
>
> -- 
> Created on and sent from a Unix like PC running and using free and open source software:

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