hamlib-developer Mailing List for Ham Radio Control Libraries (Page 43)
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
(83) |
Sep
(84) |
Oct
(14) |
Nov
|
Dec
|
|
From: Michael B. <no...@gi...> - 2024-06-13 12:19:32
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 661efce725a61431d031e47682ac348674615ce7 https://github.com/Hamlib/Hamlib/commit/661efce725a61431d031e47682ac348674615ce7 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-13 (Thu, 13 Jun 2024) Changed paths: M rigs/dummy/rot_pstrotator.c Log Message: ----------- Allow pstrotator to return az/el on 1st call to get_pos and add status values To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-12 20:33:11
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: d160c620642125c66526beaf8d0d1c96d52886c3 https://github.com/Hamlib/Hamlib/commit/d160c620642125c66526beaf8d0d1c96d52886c3 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-12 (Wed, 12 Jun 2024) Changed paths: M rigs/tentec/orion.c M rigs/tentec/orion.h Log Message: ----------- Make Origin width timeout behave better To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: George B. <geo...@gm...> - 2024-06-11 18:29:28
|
That's certainly one solution that covers this case. But I was thinking of something more general - more than just conf entries. I still like queuing only the actual rig command, as that means the parsing and error checking/reporting is out of the way, but maybe there are other uses. Add a type field and you can get a generic deferred work queue. Might be useful in other cases, like some of the thread-safety issues. Let's actually design this, not just hack something that's not as useful or as foolproof as it could be. On 6/11/24 11:45 AM, Black Michael wrote: > OK...so here's what I think the "best" solution is. > > A generic function in rig.c that can save parameter setting (both conf item and value) > A generic function in rig.c that can process that list given a port. > > Backends that need to wait for _open then determine in the set_conf if the device is open and, if not, queue the conf=XXX string. > Backends then look for the queue in the _open call and process it. > > Then this is just a few lines in each backend that needs it -- and actually the same few lines in them. > > Mike W9MDB > > > > > > > > > > > On Tuesday, June 11, 2024 at 10:33:33 AM CDT, George Baltz <geo...@gm...> wrote: > > > > > > > > > > On 6/11/24 8:20 AM, Michael Black wrote: > > >> > Turns our rotorez is not the only one that does this and it is much simpler to handle this in rotctl/rotctld with a 1-line change to add a rotor then to put this code in every backend. Plus you missed saving the value which is used for the command selection in the set_conf function. This does seem to be unique to rotor backends. > > This is so wrong on so many levels I hardly know where to begin. But lets go through them. > > "Plus you missed saving the value which is used for the command selection in the set_conf function." > > This gets me the most - I save the command that would be sent to the rotator, not anything from the set_conf call. It's already been encoded with the value - upper case for set, lower case for clear. I just send the same command to the rotator a little bit later. > > "Turns our rotorez is not the only one that does this and it is much simpler to handle this in rotctl/rotctld with a 1-line change to add a rotor then to put this code in every backend." > > Yes, it might be simpler - but wrong. It doesn't fix the root cause, that rotorez_set_conf() doesn't agree with the (unwritten) Hamlib specifications. That means an application(not just rotctl[d]) will call rot_set_conf() before rot_open(), expecting the value will be set for future use, whenever it is referenced. Moreover, it could mix frontend and backend parameters in the same set of calls. They have to be handled similarly. > > > ISTM that this is the very basic reason that Hamlib exists - to provide a completely consistent sequence of calls to handle any parameter of any device. > > If there are others, I'll fix those too. Why? Because I don't like incomplete fixes. It only took half an hour to write the code once I figured out where things were, so lets fix it right. > > > > > >> >> >> Reply to this email directly, view it on GitHub, or unsubscribe. >> You are receiving this because you authored the thread.Message ID: <Hamlib/Hamlib/pull/1565/c21...@gi...> >> > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer > |
|
From: Black M. <mdb...@ya...> - 2024-06-11 15:46:13
|
OK...so here's what I think the "best" solution is. A generic function in rig.c that can save parameter setting (both conf item and value) A generic function in rig.c that can process that list given a port. Backends that need to wait for _open then determine in the set_conf if the device is open and, if not, queue the conf=XXX string. Backends then look for the queue in the _open call and process it. Then this is just a few lines in each backend that needs it -- and actually the same few lines in them. Mike W9MDB On Tuesday, June 11, 2024 at 10:33:33 AM CDT, George Baltz <geo...@gm...> wrote: On 6/11/24 8:20 AM, Michael Black wrote: > Turns our rotorez is not the only one that does this and it is much simpler to handle this in rotctl/rotctld with a 1-line change to add a rotor then to put this code in every backend. Plus you missed saving the value which is used for the command selection in the set_conf function. This does seem to be unique to rotor backends. This is so wrong on so many levels I hardly know where to begin. But lets go through them. "Plus you missed saving the value which is used for the command selection in the set_conf function." This gets me the most - I save the command that would be sent to the rotator, not anything from the set_conf call. It's already been encoded with the value - upper case for set, lower case for clear. I just send the same command to the rotator a little bit later. "Turns our rotorez is not the only one that does this and it is much simpler to handle this in rotctl/rotctld with a 1-line change to add a rotor then to put this code in every backend." Yes, it might be simpler - but wrong. It doesn't fix the root cause, that rotorez_set_conf() doesn't agree with the (unwritten) Hamlib specifications. That means an application(not just rotctl[d]) will call rot_set_conf() before rot_open(), expecting the value will be set for future use, whenever it is referenced. Moreover, it could mix frontend and backend parameters in the same set of calls. They have to be handled similarly. ISTM that this is the very basic reason that Hamlib exists - to provide a completely consistent sequence of calls to handle any parameter of any device. If there are others, I'll fix those too. Why? Because I don't like incomplete fixes. It only took half an hour to write the code once I figured out where things were, so lets fix it right. > > > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you authored the thread.Message ID: <Hamlib/Hamlib/pull/1565/c21...@gi...> > _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: George B. <geo...@gm...> - 2024-06-11 15:32:04
|
On 6/11/24 8:20 AM, Michael Black wrote: > > Turns our rotorez is not the only one that does this and it is much > simpler to handle this in rotctl/rotctld with a 1-line change to add a > rotor then to put this code in every backend. Plus you missed saving > the value which is used for the command selection in the set_conf > function. This does seem to be unique to rotor backends. > This is so wrong on so many levels I hardly know where to begin. But lets go through them. "Plus you missed saving the value which is used for the command selection in the set_conf function." This gets me the most - I save the command that would be sent to the rotator, not anything from the set_conf call. It's already been encoded with the value - upper case for set, lower case for clear. I just send the same command to the rotator a little bit later. "Turns our rotorez is not the only one that does this and it is much simpler to handle this in rotctl/rotctld with a 1-line change to add a rotor then to put this code in every backend." Yes, it might be simpler - but wrong. It doesn't fix the root cause, that rotorez_set_conf() doesn't agree with the (unwritten) Hamlib specifications. That means an application(not just rotctl[d]) will call rot_set_conf() before rot_open(), expecting the value will be set for future use, whenever it is referenced. Moreover, it could mix frontend and backend parameters in the same set of calls. They have to be handled similarly. ISTM that this is the very basic reason that Hamlib exists - to provide a completely consistent sequence of calls to handle any parameter of any device. If there are others, I'll fix those too. Why? Because I don't like incomplete fixes. It only took half an hour to write the code once I figured out where things were, so lets fix it right. > > Reply to this email directly, view it on GitHub > <https://github.com/Hamlib/Hamlib/pull/1565#issuecomment-2160620224>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AC36NNGNBPQFDA333ZYX7NTZG3TQBAVCNFSM6AAAAABJBF2DHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRQGYZDAMRSGQ>. > You are receiving this because you authored the thread.Message ID: > <Hamlib/Hamlib/pull/1565/c21...@gi...> > |
|
From: Michael B. <no...@gi...> - 2024-06-11 03:27:21
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: db73ef20e50907f017c26008098674f9d7467372 https://github.com/Hamlib/Hamlib/commit/db73ef20e50907f017c26008098674f9d7467372 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-10 (Mon, 10 Jun 2024) Changed paths: M NEWS M include/hamlib/rotlist.h M rigs/dummy/netrotctl.c M rigs/dummy/rot_dummy.c M rigs/dummy/rot_dummy.h Log Message: ----------- Add csntechnologies.net S.A.T. satellite rotor Thanks to Randy KB0NAV To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-10 22:30:55
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: b19c179ce7d455e6b2f294145e9614623d91dcf2 https://github.com/Hamlib/Hamlib/commit/b19c179ce7d455e6b2f294145e9614623d91dcf2 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-10 (Mon, 10 Jun 2024) Changed paths: M include/hamlib/rotator.h M rigs/dummy/rot_pstrotator.c M rigs/dummy/rot_pstrotator.h Log Message: ----------- Move pstrotator read to a separate thread so that get_pos can see real-time movement To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-10 04:41:45
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 305e20948e1ada3b0a8db2e5a92dd2f27b4c3208 https://github.com/Hamlib/Hamlib/commit/305e20948e1ada3b0a8db2e5a92dd2f27b4c3208 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-09 (Sun, 09 Jun 2024) Changed paths: M rigs/flexradio/smartsdr.c M rigs/flexradio/smartsdr_caps.h Log Message: ----------- Fix ptt for smartsdr slice so only the active slice gets positive ptt To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Black M. <mdb...@ya...> - 2024-06-08 20:52:53
|
I've got better things to do than spend time making a complex interface for one rotor. It's only used in rotctl/rotctld and is not a generic API. On Saturday, June 8, 2024 at 03:42:53 PM CDT, George Baltz <geo...@gm...> wrote: But that is EXACTLY what Hamlib is for - to present the same API for every piece of gear we support - no fiddling in the app to special-case quirks. To make one model require a different sequence defeats the whole purpose. Other gear uses set_conf() to prepare for various message to send in ..._open(). Let's see what rotorez.c can do. On 6/8/24 4:26 PM, Black Michael wrote: > That is a much more complicated solution. > > I generally agree with you but putting in some sort of delayed queue for just one rotor seemed like overkill. > > Better yet would be to modularize that section of code when I feel like it...then it's a much shorter solution. > > Mike W9MDB > > > > > > > > > On Saturday, June 8, 2024 at 01:37:18 PM CDT, George Baltz <geo...@gm...> wrote: > > > > > > This is a really bad way to attack the problem - it doesn't fix it for > the general application interface, as it changes the wrong side of the > API. Every other device Hamlib supports allows config changes between > 'my_<whatever> = <whatever>_init(model)' and > '<whatever>_open(my_<whatever>,...)'. So the error is not in rotctl or > rotctld, but in rotorez.c. It needs to be fixed to save the state of > any config changes and make sure they are in effect before the device is > declared usable, i.e., when rot_open() returns. > > On 6/7/24 5:08 PM, Michael Black via Hamlib-developer wrote: >> Branch: refs/heads/master >> Home: https://github.com/Hamlib/Hamlib >> Commit: 1557ad70f752f7217c1eff963af1a1f3c4f96026 >> https://github.com/Hamlib/Hamlib/commit/1557ad70f752f7217c1eff963af1a1f3c4f96026 >> Author: Mike Black W9MDB <mdb...@ya...> >> Date: 2024-06-07 (Fri, 07 Jun 2024) >> >> Changed paths: >> M tests/rotctl.c >> M tests/rotctld.c >> >> Log Message: >> ----------- >> Fix rotorez set_conf in both rotctl and rotctld -- since it needs to be done after rot_open >> >> >> >> To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications >> >> >> _______________________________________________ >> Hamlib-developer mailing list >> Ham...@li... >> https://lists.sourceforge.net/lists/listinfo/hamlib-developer > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: George B. <geo...@gm...> - 2024-06-08 20:42:58
|
But that is EXACTLY what Hamlib is for - to present the same API for every piece of gear we support - no fiddling in the app to special-case quirks. To make one model require a different sequence defeats the whole purpose. Other gear uses set_conf() to prepare for various message to send in ..._open(). Let's see what rotorez.c can do. On 6/8/24 4:26 PM, Black Michael wrote: > That is a much more complicated solution. > > I generally agree with you but putting in some sort of delayed queue for just one rotor seemed like overkill. > > Better yet would be to modularize that section of code when I feel like it...then it's a much shorter solution. > > Mike W9MDB > > > > > > > > > On Saturday, June 8, 2024 at 01:37:18 PM CDT, George Baltz <geo...@gm...> wrote: > > > > > > This is a really bad way to attack the problem - it doesn't fix it for > the general application interface, as it changes the wrong side of the > API. Every other device Hamlib supports allows config changes between > 'my_<whatever> = <whatever>_init(model)' and > '<whatever>_open(my_<whatever>,...)'. So the error is not in rotctl or > rotctld, but in rotorez.c. It needs to be fixed to save the state of > any config changes and make sure they are in effect before the device is > declared usable, i.e., when rot_open() returns. > > On 6/7/24 5:08 PM, Michael Black via Hamlib-developer wrote: >> Branch: refs/heads/master >> Home: https://github.com/Hamlib/Hamlib >> Commit: 1557ad70f752f7217c1eff963af1a1f3c4f96026 >> https://github.com/Hamlib/Hamlib/commit/1557ad70f752f7217c1eff963af1a1f3c4f96026 >> Author: Mike Black W9MDB <mdb...@ya...> >> Date: 2024-06-07 (Fri, 07 Jun 2024) >> >> Changed paths: >> M tests/rotctl.c >> M tests/rotctld.c >> >> Log Message: >> ----------- >> Fix rotorez set_conf in both rotctl and rotctld -- since it needs to be done after rot_open >> >> >> >> To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications >> >> >> _______________________________________________ >> Hamlib-developer mailing list >> Ham...@li... >> https://lists.sourceforge.net/lists/listinfo/hamlib-developer > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Black M. <mdb...@ya...> - 2024-06-08 20:26:20
|
That is a much more complicated solution. I generally agree with you but putting in some sort of delayed queue for just one rotor seemed like overkill. Better yet would be to modularize that section of code when I feel like it...then it's a much shorter solution. Mike W9MDB On Saturday, June 8, 2024 at 01:37:18 PM CDT, George Baltz <geo...@gm...> wrote: This is a really bad way to attack the problem - it doesn't fix it for the general application interface, as it changes the wrong side of the API. Every other device Hamlib supports allows config changes between 'my_<whatever> = <whatever>_init(model)' and '<whatever>_open(my_<whatever>,...)'. So the error is not in rotctl or rotctld, but in rotorez.c. It needs to be fixed to save the state of any config changes and make sure they are in effect before the device is declared usable, i.e., when rot_open() returns. On 6/7/24 5:08 PM, Michael Black via Hamlib-developer wrote: > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 1557ad70f752f7217c1eff963af1a1f3c4f96026 > https://github.com/Hamlib/Hamlib/commit/1557ad70f752f7217c1eff963af1a1f3c4f96026 > Author: Mike Black W9MDB <mdb...@ya...> > Date: 2024-06-07 (Fri, 07 Jun 2024) > > Changed paths: > M tests/rotctl.c > M tests/rotctld.c > > Log Message: > ----------- > Fix rotorez set_conf in both rotctl and rotctld -- since it needs to be done after rot_open > > > > To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: George B. <geo...@gm...> - 2024-06-08 18:35:50
|
This is a really bad way to attack the problem - it doesn't fix it for the general application interface, as it changes the wrong side of the API. Every other device Hamlib supports allows config changes between 'my_<whatever> = <whatever>_init(model)' and '<whatever>_open(my_<whatever>,...)'. So the error is not in rotctl or rotctld, but in rotorez.c. It needs to be fixed to save the state of any config changes and make sure they are in effect before the device is declared usable, i.e., when rot_open() returns. On 6/7/24 5:08 PM, Michael Black via Hamlib-developer wrote: > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 1557ad70f752f7217c1eff963af1a1f3c4f96026 > https://github.com/Hamlib/Hamlib/commit/1557ad70f752f7217c1eff963af1a1f3c4f96026 > Author: Mike Black W9MDB <mdb...@ya...> > Date: 2024-06-07 (Fri, 07 Jun 2024) > > Changed paths: > M tests/rotctl.c > M tests/rotctld.c > > Log Message: > ----------- > Fix rotorez set_conf in both rotctl and rotctld -- since it needs to be done after rot_open > > > > To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Michael B. <no...@gi...> - 2024-06-08 16:09:40
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: f5870c84ef844aa60be0d710e8b6401214621141 https://github.com/Hamlib/Hamlib/commit/f5870c84ef844aa60be0d710e8b6401214621141 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-08 (Sat, 08 Jun 2024) Changed paths: M rigs/icom/frame.c M rigs/icom/ic746.c M rigs/icom/ic756.c M rigs/icom/ic7700.c M rigs/icom/ic7800.c M rigs/icom/ic821h.c M rigs/icom/ic92d.c M rigs/icom/icf8101.c M rigs/icom/icr75.c M rigs/icom/id5100.c M rigs/icom/omni.c M rigs/icom/optoscan.c M rigs/icom/xiegu.c Log Message: ----------- First set of rigs/icom/* state pointer macros. Commit: aa94298a098535a841ded77cd22899ad40e5cb6b https://github.com/Hamlib/Hamlib/commit/aa94298a098535a841ded77cd22899ad40e5cb6b Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-08 (Sat, 08 Jun 2024) Changed paths: M rigs/icom/icom.c M rigs/icom/icom.h Log Message: ----------- Convert rigs/icom/icom.[ch] sed -i plus manual tuning in icom.c Commit: 494787cb3c53686e9974f61a5fff6f7a77e7feb4 https://github.com/Hamlib/Hamlib/commit/494787cb3c53686e9974f61a5fff6f7a77e7feb4 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-08 (Sat, 08 Jun 2024) Changed paths: M rigs/yaesu/ft100.c M rigs/yaesu/ft1000d.c M rigs/yaesu/ft1000mp.c M rigs/yaesu/ft3000.c M rigs/yaesu/ft600.c M rigs/yaesu/ft767gx.c M rigs/yaesu/ft857.c M rigs/yaesu/ft897.c M rigs/yaesu/ft990.c M rigs/yaesu/ft990v12.c M rigs/yaesu/ft991.c M rigs/yaesu/vr5000.c M rigs/yaesu/vx1700.c Log Message: ----------- First batch of state pointers in rigs/yaesu/ Almost all by sed -i Commit: eeba884c7ef55eb8e5e4a052d7a5c74c3d8c39ff https://github.com/Hamlib/Hamlib/commit/eeba884c7ef55eb8e5e4a052d7a5c74c3d8c39ff Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-08 (Sat, 08 Jun 2024) Changed paths: M rigs/yaesu/ft736.c M rigs/yaesu/ft747.c M rigs/yaesu/ft757gx.c M rigs/yaesu/ft817.c M rigs/yaesu/ft840.c M rigs/yaesu/ft847.c M rigs/yaesu/ft890.c M rigs/yaesu/ft891.c M rigs/yaesu/ft900.c M rigs/yaesu/ft920.c M rigs/yaesu/ft980.c Log Message: ----------- Next batch of state pointers Commit: 5790af8cc662ed9ceab69740d43813ccf5522b41 https://github.com/Hamlib/Hamlib/commit/5790af8cc662ed9ceab69740d43813ccf5522b41 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-08 (Sat, 08 Jun 2024) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Convert newcat.c Commit: c4e5f54bbfbd7c28f55234bc589f2e953dd7b51f https://github.com/Hamlib/Hamlib/commit/c4e5f54bbfbd7c28f55234bc589f2e953dd7b51f Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-08 (Sat, 08 Jun 2024) Changed paths: M rigs/dummy/rot_pstrotator.c M rigs/tentec/orion.c M rigs/yaesu/ft1000d.c M rigs/yaesu/ft847.c Log Message: ----------- FIx the stragglers Comments/false postitives New code Commit: ff0ed58edf3955596892ed5082ee44da89d94cf9 https://github.com/Hamlib/Hamlib/commit/ff0ed58edf3955596892ed5082ee44da89d94cf9 Author: Michael Black <mdb...@ya...> Date: 2024-06-08 (Sat, 08 Jun 2024) Changed paths: M rigs/dummy/rot_pstrotator.c M rigs/icom/frame.c M rigs/icom/ic746.c M rigs/icom/ic756.c M rigs/icom/ic7700.c M rigs/icom/ic7800.c M rigs/icom/ic821h.c M rigs/icom/ic92d.c M rigs/icom/icf8101.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/icom/icr75.c M rigs/icom/id5100.c M rigs/icom/omni.c M rigs/icom/optoscan.c M rigs/icom/xiegu.c M rigs/tentec/orion.c M rigs/yaesu/ft100.c M rigs/yaesu/ft1000d.c M rigs/yaesu/ft1000mp.c M rigs/yaesu/ft3000.c M rigs/yaesu/ft600.c M rigs/yaesu/ft736.c M rigs/yaesu/ft747.c M rigs/yaesu/ft757gx.c M rigs/yaesu/ft767gx.c M rigs/yaesu/ft817.c M rigs/yaesu/ft840.c M rigs/yaesu/ft847.c M rigs/yaesu/ft857.c M rigs/yaesu/ft890.c M rigs/yaesu/ft891.c M rigs/yaesu/ft897.c M rigs/yaesu/ft900.c M rigs/yaesu/ft920.c M rigs/yaesu/ft980.c M rigs/yaesu/ft990.c M rigs/yaesu/ft990v12.c M rigs/yaesu/ft991.c M rigs/yaesu/newcat.c M rigs/yaesu/vr5000.c M rigs/yaesu/vx1700.c Log Message: ----------- Merge pull request #1563 from GeoBaltz/rp11 Convert all rig->state references in rigs/*/* to macro calls Compare: https://github.com/Hamlib/Hamlib/compare/1557ad70f752...ff0ed58edf39 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Black M. <mdb...@ya...> - 2024-06-07 21:12:01
|
It looks like you may be compiling Hamlib yourself? I just fixed this problem. You can get from the current github repo and build -- but you may need a couple more packages to do the build this way. You can wait for the tar file tonight from here: https://n0nb.users.sourceforge.net/ git clone https://github.com/Hamlib/Hamlib.git cd Hamlib ./bootstrap ./configure make -j 4 install Mike W9MDB On Friday, June 7, 2024 at 11:57:09 AM CDT, Randy Ralphs <ran...@gm...> wrote: Hi, Have attempted to disable rotorsz unstick option. It seems to fail due to attempting to set the option before the port is opened that would send the command to change the option. Am I doing something wrong? Randy KB0NAV /usr/local/bin/rotctl -r /dev/ttyS5 -m 401 -s 4800 -C unstick=0 -vvvvv rotctl Hamlib 4.6~git 2023-12-22T15:15:22Z SHA=c3d489 64-bit Report bugs to <ham...@li...> rot_init called initrots4_rotorez called rot_register (401) rot_register (402) rot_register (403) rot_register (404) rot_register (405) rot_register (406) rotorez_rot_init called rot_token_lookup called lookup unstick rot_token_lookup called lookup unstick rot_set_conf called rot_set_conf: unstick='0' rotorez_rot_set_conf called rotorez_rot_set_conf: token = 4, *val = 0 rotorez_rot_set_conf: c = s, *val = 0 rotorez_rot_set_conf: cmdstr = s, *val = 0 rotorez_send_priv_cmd called write_block: port not open Config parameter error: rot_init called initrots4_rotorez called rot_register (401) rot_register (402) rot_register (403) rot_register (404) rot_register (405) rot_register (406) rotorez_rot_init called rot_token_lookup called lookup unstick rot_token_lookup called lookup unstick rot_set_conf called rot_set_conf: unstick='0' rotorez_rot_set_conf called rotorez_rot_set_conf: token = 4, *val = 0 rotorez_rot_set_conf: c = s, *val = 0 rotorez_rot_set_conf: cmdstr = s, *val = 0 rotorez_send_priv_cmd called write_block: port not open IO error _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Michael B. <no...@gi...> - 2024-06-07 21:09:01
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 1557ad70f752f7217c1eff963af1a1f3c4f96026 https://github.com/Hamlib/Hamlib/commit/1557ad70f752f7217c1eff963af1a1f3c4f96026 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-07 (Fri, 07 Jun 2024) Changed paths: M tests/rotctl.c M tests/rotctld.c Log Message: ----------- Fix rotorez set_conf in both rotctl and rotctld -- since it needs to be done after rot_open To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-07 20:29:14
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: c112a5f6a94703f59a9d74d421a25b1b4e606e22 https://github.com/Hamlib/Hamlib/commit/c112a5f6a94703f59a9d74d421a25b1b4e606e22 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-07 (Fri, 07 Jun 2024) Changed paths: M NEWS M include/hamlib/rotlist.h M rigs/dummy/Makefile.am M rigs/dummy/rot_dummy.c M rigs/dummy/rot_dummy.h A rigs/dummy/rot_pstrotator.c A rigs/dummy/rot_pstrotator.h Log Message: ----------- Add PSTRotator to rotctl To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Randy R. <ran...@gm...> - 2024-06-07 16:55:47
|
Hi, Have attempted to disable rotorsz unstick option. It seems to fail due to attempting to set the option before the port is opened that would send the command to change the option. Am I doing something wrong? Randy KB0NAV /usr/local/bin/rotctl -r /dev/ttyS5 -m 401 -s 4800 -C unstick=0 -vvvvv rotctl Hamlib 4.6~git 2023-12-22T15:15:22Z SHA=c3d489 64-bit Report bugs to <ham...@li...> rot_init called initrots4_rotorez called rot_register (401) rot_register (402) rot_register (403) rot_register (404) rot_register (405) rot_register (406) rotorez_rot_init called rot_token_lookup called lookup unstick rot_token_lookup called lookup unstick rot_set_conf called rot_set_conf: unstick='0' rotorez_rot_set_conf called rotorez_rot_set_conf: token = 4, *val = 0 rotorez_rot_set_conf: c = s, *val = 0 rotorez_rot_set_conf: cmdstr = s, *val = 0 rotorez_send_priv_cmd called write_block: port not open Config parameter error: rot_init called initrots4_rotorez called rot_register (401) rot_register (402) rot_register (403) rot_register (404) rot_register (405) rot_register (406) rotorez_rot_init called rot_token_lookup called lookup unstick rot_token_lookup called lookup unstick rot_set_conf called rot_set_conf: unstick='0' rotorez_rot_set_conf called rotorez_rot_set_conf: token = 4, *val = 0 rotorez_rot_set_conf: c = s, *val = 0 rotorez_rot_set_conf: cmdstr = s, *val = 0 rotorez_send_priv_cmd called write_block: port not open IO error |
|
From: Michael B. <no...@gi...> - 2024-06-06 22:40:28
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: efcea5ddcdf28bbef703a37968e6cfd815208292 https://github.com/Hamlib/Hamlib/commit/efcea5ddcdf28bbef703a37968e6cfd815208292 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-06 (Thu, 06 Jun 2024) Changed paths: M src/rotator.c Log Message: ----------- Add UDP/TCP info to debug To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-06 22:27:41
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 967efefabef228ad44de7f8a9bc898c9c82ad05f https://github.com/Hamlib/Hamlib/commit/967efefabef228ad44de7f8a9bc898c9c82ad05f Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-06 (Thu, 06 Jun 2024) Changed paths: M rigs/tentec/orion.h Log Message: ----------- Update orion version Commit: 83583b6c0ae25d10c51991358c0ff7555a743688 https://github.com/Hamlib/Hamlib/commit/83583b6c0ae25d10c51991358c0ff7555a743688 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-06 (Thu, 06 Jun 2024) Changed paths: M src/network.c Log Message: ----------- Add some debug to network.c Compare: https://github.com/Hamlib/Hamlib/compare/07e508544861...83583b6c0ae2 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-06 12:40:14
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 07e50854486178270e286b1bbd81fe4c087adbce https://github.com/Hamlib/Hamlib/commit/07e50854486178270e286b1bbd81fe4c087adbce Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-06 (Thu, 06 Jun 2024) Changed paths: M rigs/tentec/orion.c Log Message: ----------- Try to improve orion filter bandwidth -- still not behaving at 80ms so reduce timeout and no retries To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-06 12:22:33
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 0884532e97a37af7227dcf6392ce85a5b46dec1e https://github.com/Hamlib/Hamlib/commit/0884532e97a37af7227dcf6392ce85a5b46dec1e Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-06 (Thu, 06 Jun 2024) Changed paths: M rigs/flexradio/smartsdr.c M rigs/flexradio/smartsdr_caps.h Log Message: ----------- Flex SmartSDR seems stable now with WSJT-X. To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-06 03:12:48
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 9eda0628f6a68191a816706cb829afcc0c47af43 https://github.com/Hamlib/Hamlib/commit/9eda0628f6a68191a816706cb829afcc0c47af43 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/tuner/v4l.c M rigs/tuner/v4l2.c M rigs/uniden/uniden.c M rigs/uniden/uniden_digital.c M rigs/winradio/g303.c M rigs/winradio/g305.c M rigs/winradio/g313-posix.c M rigs/winradio/g313-win.c M rigs/winradio/winradio.c M tests/README Log Message: ----------- More state pointers - mostly sed i Fix bad comment in tests/README Commit: 9e4bacbec92d7f9e68b26b87a9736873df05baae https://github.com/Hamlib/Hamlib/commit/9e4bacbec92d7f9e68b26b87a9736873df05baae Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/tentec/jupiter.c M rigs/tentec/omnivii.c M rigs/tentec/orion.c M rigs/tentec/paragon.c M rigs/tentec/rx331.c M rigs/tentec/rx340.c M rigs/tentec/tentec.c M rigs/tentec/tentec2.c M rigs/tentec/tt550.c Log Message: ----------- Pointerize state references in Tentec rigs. Commit: d6dcd4aad43a791d34ecedac024fd00b32d270d6 https://github.com/Hamlib/Hamlib/commit/d6dcd4aad43a791d34ecedac024fd00b32d270d6 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/pcr/pcr.c M rigs/prm80/prm80.c M rigs/racal/ra37xx.c M rigs/racal/racal.c M rigs/rft/rft.c M rigs/rs/ek89x.c M rigs/rs/gp2000.c M rigs/rs/rs.c M rigs/skanti/skanti.c M rigs/skanti/trp8255.c M rigs/tapr/tapr.c Log Message: ----------- And another batch... All sed -i with some manual fixups. Less than 2000 to go. Commit: d17290b835c502b98936a107e11ef1fc261b3894 https://github.com/Hamlib/Hamlib/commit/d17290b835c502b98936a107e11ef1fc261b3894 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/kit/dds60.c M rigs/kit/drt1.c M rigs/kit/dwt.c M rigs/kit/elektor304.c M rigs/kit/elektor507.c M rigs/kit/fifisdr.c M rigs/kit/funcube.c M rigs/kit/hiqsdr.c M rigs/kit/si570avrusb.c M rigs/kit/usrp_impl.cc M rigs/lowe/lowe.c M rigs/mds/mds.c Log Message: ----------- Use sed -i on all in rigs/kit/ Under 1800 to go. Commit: 5b84c02b807babd12406826e0af75fed5576b7e1 https://github.com/Hamlib/Hamlib/commit/5b84c02b807babd12406826e0af75fed5576b7e1 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/dummy/quisk.c M rigs/dummy/sdrsharp.c M rigs/dummy/trxmanager.c M rigs/gomspace/gs100.c M rigs/icmarine/icm710.c M rigs/icmarine/icmarine.c M rigs/jrc/jrc.c M rigs/jrc/jst145.c M rigs/kachina/kachina.c Log Message: ----------- More sed -i with manual fixups. This leaves rigs/dummy/ to finish, then the biggies - rigs/icom & rigs/yaesu Commit: 53287de4878e0bc53199dc9ce9aefbf7b2cf973f https://github.com/Hamlib/Hamlib/commit/53287de4878e0bc53199dc9ce9aefbf7b2cf973f Author: George Baltz N3GB <Geo...@gm...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/alinco/dx77.c M rigs/alinco/dxsr8.c M rigs/aor/ar3000.c M rigs/aor/ar3030.c M rigs/aor/sr2200.c M rigs/barrett/barrett.c M rigs/drake/drake.c M rigs/dummy/aclog.c M rigs/dummy/amp_dummy.c M rigs/dummy/netampctl.c M rigs/dummy/netrigctl.c M rigs/dummy/netrotctl.c M rigs/dummy/rot_dummy.c M rigs/dummy/tci1x.c M rigs/tentec/orion.c Log Message: ----------- Convert all of rigs/* except rigs/icom and rigs/yaesu Also do some comments(false positives) Commit: 2c863c732298a46b97a9f3d48b0df26a327dc690 https://github.com/Hamlib/Hamlib/commit/2c863c732298a46b97a9f3d48b0df26a327dc690 Author: Michael Black <mdb...@ya...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/alinco/dx77.c M rigs/alinco/dxsr8.c M rigs/aor/ar3000.c M rigs/aor/ar3030.c M rigs/aor/sr2200.c M rigs/barrett/barrett.c M rigs/drake/drake.c M rigs/dummy/aclog.c M rigs/dummy/amp_dummy.c M rigs/dummy/netampctl.c M rigs/dummy/netrigctl.c M rigs/dummy/netrotctl.c M rigs/dummy/quisk.c M rigs/dummy/rot_dummy.c M rigs/dummy/sdrsharp.c M rigs/dummy/tci1x.c M rigs/dummy/trxmanager.c M rigs/gomspace/gs100.c M rigs/icmarine/icm710.c M rigs/icmarine/icmarine.c M rigs/jrc/jrc.c M rigs/jrc/jst145.c M rigs/kachina/kachina.c M rigs/kit/dds60.c M rigs/kit/drt1.c M rigs/kit/dwt.c M rigs/kit/elektor304.c M rigs/kit/elektor507.c M rigs/kit/fifisdr.c M rigs/kit/funcube.c M rigs/kit/hiqsdr.c M rigs/kit/si570avrusb.c M rigs/kit/usrp_impl.cc M rigs/lowe/lowe.c M rigs/mds/mds.c M rigs/pcr/pcr.c M rigs/prm80/prm80.c M rigs/racal/ra37xx.c M rigs/racal/racal.c M rigs/rft/rft.c M rigs/rs/ek89x.c M rigs/rs/gp2000.c M rigs/rs/rs.c M rigs/skanti/skanti.c M rigs/skanti/trp8255.c M rigs/tapr/tapr.c M rigs/tentec/jupiter.c M rigs/tentec/omnivii.c M rigs/tentec/orion.c M rigs/tentec/paragon.c M rigs/tentec/rx331.c M rigs/tentec/rx340.c M rigs/tentec/tentec.c M rigs/tentec/tentec2.c M rigs/tentec/tt550.c M rigs/tuner/v4l.c M rigs/tuner/v4l2.c M rigs/uniden/uniden.c M rigs/uniden/uniden_digital.c M rigs/winradio/g303.c M rigs/winradio/g305.c M rigs/winradio/g313-posix.c M rigs/winradio/g313-win.c M rigs/winradio/winradio.c M tests/README Log Message: ----------- Merge pull request #1562 from GeoBaltz/rp10 Replace state references with macro calls Compare: https://github.com/Hamlib/Hamlib/compare/a42d408094d8...2c863c732298 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-05 16:55:54
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: a42d408094d89599529abae3be84c5b6415a3792 https://github.com/Hamlib/Hamlib/commit/a42d408094d89599529abae3be84c5b6415a3792 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/flexradio/smartsdr.c M rigs/flexradio/smartsdr_caps.h Log Message: ----------- Update smartsdr To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-05 16:55:00
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 95cfde24f4582e38eac9a81c46e19220d23fc4c4 https://github.com/Hamlib/Hamlib/commit/95cfde24f4582e38eac9a81c46e19220d23fc4c4 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M rigs/flexradio/smartsdr.c Log Message: ----------- Better WSJT-X behavior now.... To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-06-05 04:39:42
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: b0df007d6b33d46f01bfb03d7c1c92f9f713f035 https://github.com/Hamlib/Hamlib/commit/b0df007d6b33d46f01bfb03d7c1c92f9f713f035 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-06-04 (Tue, 04 Jun 2024) Changed paths: M rigs/flexradio/smartsdr_caps.h Log Message: ----------- Change SmartSDR to TARGETALB_FREQ Still need to figure out how to set VFOB To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
33 messages has been excluded from this view by a project administrator.
