hamlib-developer Mailing List for Ham Radio Control Libraries (Page 99)
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer — hamlib developers forum
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(24) |
Oct
(16) |
Nov
(8) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(49) |
Feb
(17) |
Mar
(3) |
Apr
(7) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(8) |
Sep
(18) |
Oct
(15) |
Nov
(15) |
Dec
(26) |
| 2002 |
Jan
(46) |
Feb
(14) |
Mar
(44) |
Apr
(3) |
May
(6) |
Jun
(47) |
Jul
(40) |
Aug
(14) |
Sep
(59) |
Oct
(39) |
Nov
(58) |
Dec
(76) |
| 2003 |
Jan
(82) |
Feb
(66) |
Mar
(37) |
Apr
(56) |
May
(34) |
Jun
(19) |
Jul
(23) |
Aug
(55) |
Sep
(31) |
Oct
(40) |
Nov
(21) |
Dec
(60) |
| 2004 |
Jan
(57) |
Feb
(110) |
Mar
(41) |
Apr
(17) |
May
(18) |
Jun
(19) |
Jul
(18) |
Aug
(5) |
Sep
(31) |
Oct
(16) |
Nov
(26) |
Dec
(36) |
| 2005 |
Jan
(69) |
Feb
(26) |
Mar
(62) |
Apr
(120) |
May
(31) |
Jun
(47) |
Jul
(7) |
Aug
(27) |
Sep
(4) |
Oct
(9) |
Nov
(26) |
Dec
(21) |
| 2006 |
Jan
(13) |
Feb
(26) |
Mar
(38) |
Apr
(31) |
May
(17) |
Jun
(6) |
Jul
(23) |
Aug
(6) |
Sep
(38) |
Oct
(87) |
Nov
(49) |
Dec
(49) |
| 2007 |
Jan
(52) |
Feb
(19) |
Mar
(20) |
Apr
(5) |
May
(25) |
Jun
(15) |
Jul
(49) |
Aug
(43) |
Sep
(21) |
Oct
(21) |
Nov
(27) |
Dec
(10) |
| 2008 |
Jan
(23) |
Feb
(20) |
Mar
(25) |
Apr
(39) |
May
(36) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(44) |
Oct
(88) |
Nov
(60) |
Dec
(65) |
| 2009 |
Jan
(99) |
Feb
(91) |
Mar
(49) |
Apr
(34) |
May
(52) |
Jun
(9) |
Jul
(11) |
Aug
(4) |
Sep
(41) |
Oct
(16) |
Nov
(51) |
Dec
(71) |
| 2010 |
Jan
(43) |
Feb
(79) |
Mar
(59) |
Apr
(55) |
May
(51) |
Jun
(38) |
Jul
(38) |
Aug
(61) |
Sep
(53) |
Oct
(46) |
Nov
(43) |
Dec
(41) |
| 2011 |
Jan
(74) |
Feb
(96) |
Mar
(41) |
Apr
(42) |
May
(61) |
Jun
(66) |
Jul
(50) |
Aug
(40) |
Sep
(11) |
Oct
(30) |
Nov
(21) |
Dec
(45) |
| 2012 |
Jan
(59) |
Feb
(4) |
Mar
(52) |
Apr
(19) |
May
(62) |
Jun
(46) |
Jul
(61) |
Aug
(18) |
Sep
(21) |
Oct
(25) |
Nov
(66) |
Dec
(41) |
| 2013 |
Jan
(36) |
Feb
(64) |
Mar
(37) |
Apr
(24) |
May
(74) |
Jun
(40) |
Jul
(43) |
Aug
(34) |
Sep
(65) |
Oct
(52) |
Nov
(23) |
Dec
(20) |
| 2014 |
Jan
(18) |
Feb
(29) |
Mar
(13) |
Apr
(41) |
May
(10) |
Jun
(12) |
Jul
(16) |
Aug
(25) |
Sep
(20) |
Oct
(56) |
Nov
(43) |
Dec
(61) |
| 2015 |
Jan
(36) |
Feb
(38) |
Mar
(92) |
Apr
(42) |
May
(13) |
Jun
(19) |
Jul
(18) |
Aug
(22) |
Sep
(21) |
Oct
(2) |
Nov
(49) |
Dec
(22) |
| 2016 |
Jan
(55) |
Feb
(144) |
Mar
(40) |
Apr
(98) |
May
(61) |
Jun
(36) |
Jul
(16) |
Aug
(33) |
Sep
(59) |
Oct
(16) |
Nov
(37) |
Dec
(32) |
| 2017 |
Jan
(70) |
Feb
(71) |
Mar
(14) |
Apr
(43) |
May
(31) |
Jun
(24) |
Jul
(38) |
Aug
(54) |
Sep
(24) |
Oct
(15) |
Nov
(26) |
Dec
(27) |
| 2018 |
Jan
(22) |
Feb
(24) |
Mar
(109) |
Apr
(12) |
May
(46) |
Jun
(23) |
Jul
(39) |
Aug
(34) |
Sep
(22) |
Oct
(43) |
Nov
(26) |
Dec
(157) |
| 2019 |
Jan
(102) |
Feb
(51) |
Mar
(63) |
Apr
(60) |
May
(91) |
Jun
(55) |
Jul
(27) |
Aug
(76) |
Sep
(52) |
Oct
(95) |
Nov
(67) |
Dec
(204) |
| 2020 |
Jan
(311) |
Feb
(148) |
Mar
(230) |
Apr
(122) |
May
(204) |
Jun
(204) |
Jul
(114) |
Aug
(36) |
Sep
(120) |
Oct
(186) |
Nov
(60) |
Dec
(151) |
| 2021 |
Jan
(182) |
Feb
(171) |
Mar
(202) |
Apr
(153) |
May
(110) |
Jun
(50) |
Jul
(58) |
Aug
(142) |
Sep
(112) |
Oct
(120) |
Nov
(97) |
Dec
(125) |
| 2022 |
Jan
(175) |
Feb
(147) |
Mar
(54) |
Apr
(73) |
May
(127) |
Jun
(95) |
Jul
(88) |
Aug
(85) |
Sep
(38) |
Oct
(40) |
Nov
(116) |
Dec
(159) |
| 2023 |
Jan
(175) |
Feb
(55) |
Mar
(83) |
Apr
(70) |
May
(165) |
Jun
(79) |
Jul
(123) |
Aug
(90) |
Sep
(40) |
Oct
(95) |
Nov
(84) |
Dec
(88) |
| 2024 |
Jan
(105) |
Feb
(60) |
Mar
(52) |
Apr
(43) |
May
(56) |
Jun
(59) |
Jul
(53) |
Aug
(47) |
Sep
(62) |
Oct
(36) |
Nov
(45) |
Dec
(100) |
| 2025 |
Jan
(52) |
Feb
(45) |
Mar
(30) |
Apr
(97) |
May
(72) |
Jun
(83) |
Jul
(124) |
Aug
(17) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael B. <no...@gi...> - 2022-12-15 17:43:16
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 7fc23e59a337e853e292e8e89d39d6a2179498ea https://github.com/Hamlib/Hamlib/commit/7fc23e59a337e853e292e8e89d39d6a2179498ea Author: PianetaRadio <789...@us...> Date: 2022-12-15 (Thu, 15 Dec 2022) Changed paths: M rotators/prosistel/prosistel.c Log Message: ----------- Update prosistel.c Add Elevation rotator with Control box responding to azimuth logic Commit: b1ac588667e74af74e7eb32be3badfc4ad1e77d8 https://github.com/Hamlib/Hamlib/commit/b1ac588667e74af74e7eb32be3badfc4ad1e77d8 Author: PianetaRadio <789...@us...> Date: 2022-12-15 (Thu, 15 Dec 2022) Changed paths: M rotators/prosistel/prosistel.h Log Message: ----------- Update prosistel.h Add Elevation rotator with Control box responding to azimuth logic Commit: 40066a6cfa0cc7d49d9e2a25edf5dcac46421e84 https://github.com/Hamlib/Hamlib/commit/40066a6cfa0cc7d49d9e2a25edf5dcac46421e84 Author: PianetaRadio <789...@us...> Date: 2022-12-15 (Thu, 15 Dec 2022) Changed paths: M rotators/prosistel/prosistel.c Log Message: ----------- Update prosistel.c Add Elevation rotator with Control box responding to azimuth logic Commit: 9eecfc3b2df1804f6ddccafea160fe6f9d80efc6 https://github.com/Hamlib/Hamlib/commit/9eecfc3b2df1804f6ddccafea160fe6f9d80efc6 Author: PianetaRadio <789...@us...> Date: 2022-12-15 (Thu, 15 Dec 2022) Changed paths: M include/hamlib/rotlist.h Log Message: ----------- Update rotlist.h Add Elevation rotator with Control box responding to azimuth logic Commit: 830bf5a94171847ff82ce9f22edcfd3a2a2fecf8 https://github.com/Hamlib/Hamlib/commit/830bf5a94171847ff82ce9f22edcfd3a2a2fecf8 Author: Michael Black <mdb...@ya...> Date: 2022-12-15 (Thu, 15 Dec 2022) Changed paths: M include/hamlib/rotlist.h M rotators/prosistel/prosistel.c M rotators/prosistel/prosistel.h Log Message: ----------- Merge pull request #1191 from PianetaRadio/master Rotator Prosistel elevation with azimuth logic Compare: https://github.com/Hamlib/Hamlib/compare/2a84386ae899...830bf5a94171 |
|
From: Michael B. <no...@gi...> - 2022-12-15 05:00:03
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 2a84386ae89989158d9bc628654188219138f9d5 https://github.com/Hamlib/Hamlib/commit/2a84386ae89989158d9bc628654188219138f9d5 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: A simulators/simft736.c M simulators/simft747gx.c M simulators/simft897.c M simulators/simft990.c M simulators/simjupiter.c Log Message: ----------- Add simft736.c and update others |
|
From: Black M. <mdb...@ya...> - 2022-12-14 17:21:32
|
I just added get_freq using cached values for the FT736R so your shim should no longer be needed with gpredict. It is in the master repo now and will be on https://n0nb.users.sourceforge.net/ overnight dated 20221215 Between that and my gpredict fork you should be working now hopefully. Mike W9MDB On Wednesday, December 14, 2022 at 05:29:25 AM CST, Dave B <g8k...@go...> wrote: 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...> 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: |
|
From: Michael B. <no...@gi...> - 2022-12-14 17:19:00
|
Branch: refs/heads/Hamlib-4.5.2 Home: https://github.com/Hamlib/Hamlib Commit: 80cdb9b953fcdf9b4b027aeed33df6758806492a https://github.com/Hamlib/Hamlib/commit/80cdb9b953fcdf9b4b027aeed33df6758806492a Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS Commit: 4e88d847b08cbff97de5c1a7b5ee5ad376d2cb0f https://github.com/Hamlib/Hamlib/commit/4e88d847b08cbff97de5c1a7b5ee5ad376d2cb0f Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS Compare: https://github.com/Hamlib/Hamlib/compare/f0636bc87590...4e88d847b08c |
|
From: Michael B. <no...@gi...> - 2022-12-14 17:17:32
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 57f2646daaeac87ee430ec485f0abc1c4c5f1d80 https://github.com/Hamlib/Hamlib/commit/57f2646daaeac87ee430ec485f0abc1c4c5f1d80 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS |
|
From: Michael B. <no...@gi...> - 2022-12-14 17:16:37
|
Branch: refs/heads/Hamlib-4.5.2 Home: https://github.com/Hamlib/Hamlib Commit: f0636bc87590d84ca9b205222854704286a0319c https://github.com/Hamlib/Hamlib/commit/f0636bc87590d84ca9b205222854704286a0319c Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M rigs/yaesu/ft736.c Log Message: ----------- Add get_freq cached for FT736R to allow working with gpredict https://github.com/Hamlib/Hamlib/issues/1187 |
|
From: Michael B. <no...@gi...> - 2022-12-14 17:15:38
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: a9497b295854d942b3605294622c9402b14c5245 https://github.com/Hamlib/Hamlib/commit/a9497b295854d942b3605294622c9402b14c5245 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS Commit: e9192f5a8b19a609960d76506c189141ab25fe31 https://github.com/Hamlib/Hamlib/commit/e9192f5a8b19a609960d76506c189141ab25fe31 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M rigs/yaesu/ft736.c Log Message: ----------- Add get_freq cached for FT736R to allow working with gpredict https://github.com/Hamlib/Hamlib/issues/1187 Compare: https://github.com/Hamlib/Hamlib/compare/eb03592d002a...e9192f5a8b19 |
|
From: Michael B. <no...@gi...> - 2022-12-14 17:07:23
|
Branch: refs/heads/Hamlib-4.5.2 Home: https://github.com/Hamlib/Hamlib Commit: bc45b17ae2d995e05d8bb8d10d4652a65b648d31 https://github.com/Hamlib/Hamlib/commit/bc45b17ae2d995e05d8bb8d10d4652a65b648d31 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: Log Message: ----------- If get_powerstat fails assume rig is powered on -- should fix sdr++ problem https://github.com/Hamlib/Hamlib/issues/1186 |
|
From: Michael B. <no...@gi...> - 2022-12-14 16:09:34
|
Branch: refs/heads/Hamlib-4.5.2 Home: https://github.com/Hamlib/Hamlib Commit: 9edbc9e4b0a231e835b9c4331821aa955366f272 https://github.com/Hamlib/Hamlib/commit/9edbc9e4b0a231e835b9c4331821aa955366f272 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS Commit: 2dd31355fc5fe3dd1a4afdd8843f53132bce7395 https://github.com/Hamlib/Hamlib/commit/2dd31355fc5fe3dd1a4afdd8843f53132bce7395 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M rigs/dummy/netrigctl.c Log Message: ----------- If get_powerstat fails in any way then always return RIG_POWER_ON https://github.com/Hamlib/Hamlib/issues/1189 Compare: https://github.com/Hamlib/Hamlib/compare/23d98c1e5628...2dd31355fc5f |
|
From: Michael B. <no...@gi...> - 2022-12-14 16:07:48
|
Branch: refs/heads/Hamlib-4.5.2 Home: https://github.com/Hamlib/Hamlib Commit: 859204026277a3f396a88b5e8f06415fe363cc22 https://github.com/Hamlib/Hamlib/commit/859204026277a3f396a88b5e8f06415fe363cc22 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-11 (Sun, 11 Dec 2022) Changed paths: A simulators/simftdx1200.c Log Message: ----------- Update simftdx1200.c Commit: 46f30345b9c57e85f08630fad9b1c3c2b0b98a7c https://github.com/Hamlib/Hamlib/commit/46f30345b9c57e85f08630fad9b1c3c2b0b98a7c Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-12 (Mon, 12 Dec 2022) Changed paths: M rigs/dummy/netrigctl.c Log Message: ----------- If get_powerstat fails assume rig is powered on -- should fix sdr++ problem https://github.com/Hamlib/Hamlib/issues/1186 Commit: 01799cb64f2afa8a8be06a46c0a6f0d4f8a38351 https://github.com/Hamlib/Hamlib/commit/01799cb64f2afa8a8be06a46c0a6f0d4f8a38351 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-12 (Mon, 12 Dec 2022) Changed paths: M tests/rigctld.c Log Message: ----------- Allow rigctld to close the rig with the -R option when client disconnects. This makes it close when any one client disconnects. Should only close when no clients are connected -- that will be the next patch This is for the FT736R and gpredict https://github.com/Hamlib/Hamlib/issues/1187 Commit: fd186abcaeb63506bff9c65b7332fb913f64569d https://github.com/Hamlib/Hamlib/commit/fd186abcaeb63506bff9c65b7332fb913f64569d Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-12 (Mon, 12 Dec 2022) Changed paths: M tests/rigctld.c Log Message: ----------- -R option will keep rig open as long as 1 or more clients are connected https://github.com/Hamlib/Hamlib/issues/1187 Commit: 23d98c1e5628597a37b68f9b53859ea1ba37e5b2 https://github.com/Hamlib/Hamlib/commit/23d98c1e5628597a37b68f9b53859ea1ba37e5b2 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-12 (Mon, 12 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS Compare: https://github.com/Hamlib/Hamlib/compare/0d4f647da3d0...23d98c1e5628 |
|
From: Michael B. <no...@gi...> - 2022-12-14 15:08:51
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: eb03592d002af78ff7755f463680ab75ac1bd972 https://github.com/Hamlib/Hamlib/commit/eb03592d002af78ff7755f463680ab75ac1bd972 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: M rigs/dummy/netrigctl.c Log Message: ----------- If get_powerstat fails in any way then always return RIG_POWER_ON https://github.com/Hamlib/Hamlib/issues/1189 |
|
From: Dave B <g8k...@go...> - 2022-12-14 11:29:30
|
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: |
|
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 |
|
From: Black M. <mdb...@ya...> - 2022-12-13 17:43:07
|
I could change the FT736R to use cached frequency and perhaps cached mode and split status too.
That would eliminate the need for a shim. I've done that on a couple of other rigs. Of course the frequency won't follow knob twiddling but it doesn't do that now anyways.
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: |
|
From: Dave B <g8k...@go...> - 2022-12-13 16:57:29
|
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: |
|
From: Black M. <mdb...@ya...> - 2022-12-13 14:46:52
|
For some debug run rigctld like this and duplicate the problem. Just duplicate the engage/disengage/engage one time.
~/Local/bin/rigctld -m1010 -R -T localhost -t 50736 -r /dev/ttyFT736 -s 4800 -vvvvv -Z >log.txt 2>&1&
Then send me the log.txt file.
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: _______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Black M. <mdb...@ya...> - 2022-12-13 14:40:29
|
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: |
|
From: Michael B. <no...@gi...> - 2022-12-13 14:02:42
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: d1fffb7c84c3d9e2ade81ef6baeff66fe421155d https://github.com/Hamlib/Hamlib/commit/d1fffb7c84c3d9e2ade81ef6baeff66fe421155d Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-13 (Tue, 13 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS |
|
From: Dave B <g8k...@go...> - 2022-12-13 13:54:46
|
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: |
|
From: Dave B <g8k...@go...> - 2022-12-13 13:52:20
|
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: |
|
From: Dave B <g8k...@go...> - 2022-12-13 10:41:11
|
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: |
|
From: Black M. <mdb...@ya...> - 2022-12-13 06:00:08
|
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
|
|
From: Michael B. <no...@gi...> - 2022-12-13 05:53:59
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 368a07ad78b46ea8ed010a9bc039b5ea4cafebd4 https://github.com/Hamlib/Hamlib/commit/368a07ad78b46ea8ed010a9bc039b5ea4cafebd4 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-12 (Mon, 12 Dec 2022) Changed paths: M NEWS Log Message: ----------- Update NEWS |
|
From: Michael B. <no...@gi...> - 2022-12-13 05:47:46
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: f224e71a5830eaabe1f751a5d172bdea3ce6f618 https://github.com/Hamlib/Hamlib/commit/f224e71a5830eaabe1f751a5d172bdea3ce6f618 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-12 (Mon, 12 Dec 2022) Changed paths: M tests/rigctld.c Log Message: ----------- -R option will keep rig open as long as 1 or more clients are connected https://github.com/Hamlib/Hamlib/issues/1187 |
|
From: Michael B. <no...@gi...> - 2022-12-13 05:30:10
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5b704d24fb4556be7e76603d7a3bcfdde76bee16 https://github.com/Hamlib/Hamlib/commit/5b704d24fb4556be7e76603d7a3bcfdde76bee16 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-12-12 (Mon, 12 Dec 2022) Changed paths: M tests/rigctld.c Log Message: ----------- Allow rigctld to close the rig with the -R option when client disconnects. This makes it close when any one client disconnects. Should only close when no clients are connected -- that will be the next patch This is for the FT736R and gpredict https://github.com/Hamlib/Hamlib/issues/1187 |
33 messages has been excluded from this view by a project administrator.
