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

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

Hi.

I'm going to have to pause work on this, as other stuff to do today & 
tomorrow.  Though I might get some time to play again in the evening(UK 
time.)   I'll certainly  try your debug run outputting to a file.

Not sure about gpredict "not" setting up the rig.  The only things it 
does (with the 736 at least) is set Full Duplex (Satellite) mode, then 
the uplink and downlink frequencies, then tries to read back the 
frequencies to determine if the radio is still connected.  By default, 
that fails with the 736 as it has no ability to be polled for such info.

AFIK, there are no functions in gpredict to set operating mode (SSB/FM) 
etc.   I do know some later Yaesu rigs had some "special" code baked 
into gpredict, but (a) I'm not sure which radios, and (b) what the issue 
was that needed that.

Anyway, as above, other stuff to do today, but I will be back with that 
debug info as soon as I get "enough contiguous time" to do so.

73.

Dave G8KBV



On 13/12/2022 23:28, Black Michael wrote:
> If you can compile my fork it ought to work now.  gpredict was not 
> setting up the rig again after a restart.
>
> https://github.com/mdblack98/gpredict
>
> Next I can patch Hamlib to return the frequencies to make gpredict 
> happy...but they will be cached and only update when updated by 
> gpredict or another program connected to rigctld that sets frequency.
>
> Mike W9MDB
>
>
> On Tuesday, December 13, 2022 at 10:57:22 AM CST, Dave B 
> <g8k...@go...> wrote:
>
>
> Hi Mike.
>
> Generally yes, because the Satellite switch on the front is set for "Off".
>
> Manual control is needed for users with rigs that have only the two 
> basic bands (2m & 70cms) to manually re-configure the rig if changing 
> from u/v to v/u transponders, else the rig "throws a wobbly" when it 
> tries to setup Satellite/duplex mode on one band only!
>
>
> Playing some more with rigctld (ver 3.3) and Telnet, after enabling 
> printing to the console of the commands coming from Gpredict in my bit 
> of python, I find that:-
>
> Gpredict establishes a TCP connection with rigctld and when the 
> "Engage" button is hit, then sends:-
> 'S 1 Sub'    That seems to invoke CAT ON, and Sat/duplex mode all in 
> one hit.
>
> It then sends the two working frequencies using the F and I commands.
> It also periodically reads them back using f and i, to determine if 
> the radio is still connected.
> If it doesn't see one or both, it automatically "Disengages" the radio 
> after a second or two.
>
> *That* is why I had to put my python shim in the middle, to fake those 
> read-backs because the rig doesn't do any.
>
>
> When the "Disengage" is used, it stops sending frequency updates, and 
> then sends a 'q' command.
> That causes rigctld (3.3) to kill the CAT session with the radio, that 
> in turn causes the radio to cancel the Satellite/split/full duplex mode.
>
> My guess is, that Hamlib (4.5.1) is not closing the CAT session with 
> the rig, when a 'q' command is received from the client by rigctld.
>
> However unless my eyes are painted on (again) I can't find a 'q' 
> command listed for rigctld.
>
> I've been staring at this screen most of the day, I need a break.
>
> Regards to All.  I'll check back later.
>
>     Dave G8KBV/G0WBX
>
>
>
>
> On 13/12/2022 14:40, Black Michael wrote:
>> Does the rig go out of satellite mode when disengaged?
>>
>> Mike W9MDB
>>
>>
>>
>>
>> On Tuesday, December 13, 2022 at 07:54:37 AM CST, Dave B 
>> <g8k...@go...> <mailto:g8k...@go...> wrote:
>>
>>
>> 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:
>
> -- 
> 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: