Re: [Hamlib-developer] Bug: Yaesu FT-736r
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
Re: [Hamlib-developer] Bug: Yaesu FT-736r
|
From: Black M. <mdb...@ya...> - 2022-12-13 23:29:08
|
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...> 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 |
