hamlib-developer Mailing List for Ham Radio Control Libraries (Page 31)
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
|
Nov
|
Dec
|
|
From: George B. <geo...@gm...> - 2024-12-02 23:25:23
|
On 12/2/24 18:10, Black Michael wrote: > The depth is need to avoid deadlock on recursion. > > So anybody coming in at level 1 has to grab the lock. But that means it's useless for general thread safety. Another thread calling rig_<whatever> will have incremented depth (in ENTERFUNC) so it won't call rig_lock(). How about PTHREAD_MUTEX_RECURSIVE? > > Mike W9MDB > > > > > > > > > On Monday, December 2, 2024 at 04:00:35 PM CST, George Baltz <geo...@gm...> wrote: > > > > > > > On 12/2/24 16:12, Black Michael wrote: >> Mutexes do address general thread safety. > Yeah, but LOCK() is not (just) a mutex. Consulting an unprotected > variable(depth) to decide on locking leads to all sorts of races, > mismatches, and other random errors. > > No other facet of programming is so absolutely ruled by Murphy's Law. > >> They are just a pain when you don't have thread-safe code designed from scratch. > You can say that again. > >> Mike W9MDB |
|
From: Black M. <mdb...@ya...> - 2024-12-02 23:20:42
|
The depth is need to avoid deadlock on recursion. So anybody coming in at level 1 has to grab the lock. Mike W9MDB On Monday, December 2, 2024 at 04:00:35 PM CST, George Baltz <geo...@gm...> wrote: On 12/2/24 16:12, Black Michael wrote: > Mutexes do address general thread safety. Yeah, but LOCK() is not (just) a mutex. Consulting an unprotected variable(depth) to decide on locking leads to all sorts of races, mismatches, and other random errors. No other facet of programming is so absolutely ruled by Murphy's Law. > > They are just a pain when you don't have thread-safe code designed from scratch. You can say that again. > > Mike W9MDB > -- 73 n3gb |
|
From: George B. <geo...@gm...> - 2024-12-02 22:00:40
|
On 12/2/24 16:12, Black Michael wrote: > Mutexes do address general thread safety. Yeah, but LOCK() is not (just) a mutex. Consulting an unprotected variable(depth) to decide on locking leads to all sorts of races, mismatches, and other random errors. No other facet of programming is so absolutely ruled by Murphy's Law. > > They are just a pain when you don't have thread-safe code designed from scratch. You can say that again. > > Mike W9MDB > -- 73 n3gb |
|
From: George B. <geo...@gm...> - 2024-12-02 21:54:10
|
On 12/2/24 16:12, Black Michael via Hamlib-developer wrote: > Mutexes do address general thread safety. Yeah, but LOCK() is not (just) a mutex. Consulting an unprotected variable (depth) to decide on locking leads to all sorts of races, mismatches and other random errors. No other facet of programming is so absolutely ruled by Murphy's Law. > > They are just a pain when you don't have thread-safe code designed from scratch. You can say that again. > > Mike W9MDB -- 73 n3gb |
|
From: Black M. <mdb...@ya...> - 2024-12-02 21:13:02
|
Mutexes do address general thread safety. They are just a pain when you don't have thread-safe code designed from scratch. Mike W9MDB On Monday, December 2, 2024 at 12:43:29 PM CST, George Baltz <geo...@gm...> wrote: Played around with this using tlf into a dummy load for about 15 minutes - no problems encountered. Still doesn't address general thread safety, but makes CW better. On 12/2/24 8:24 AM, Michael Black via Hamlib-developer wrote: > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 890ed18c43132c3b0d1b96eff6a2b5d6a96d57ba > https://github.com/Hamlib/Hamlib/commit/890ed18c43132c3b0d1b96eff6a2b5d6a96d57ba > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-02 (Mon, 02 Dec 2024) > > Changed paths: > M src/rig.c > > Log Message: > ----------- > Change morse_data_handler from LOCK to rig_lock as it needs to always use it > > > Commit: 65832ecf53b3788ae3adc1eefe697b7e0112ac7c > https://github.com/Hamlib/Hamlib/commit/65832ecf53b3788ae3adc1eefe697b7e0112ac7c > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-02 (Mon, 02 Dec 2024) > > Changed paths: > M src/rig.c > > Log Message: > ----------- > Fix compile warnings > > > Compare: https://github.com/Hamlib/Hamlib/compare/711a35135326...65832ecf53b3 > > 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: iz8ewd <iz...@pi...> - 2024-12-02 18:43:22
|
Hi all, I confirm that there are some problems with the send_morse. Often my FT-991 gets stuck, for example it remains in TX when the CW code ended. 73 Johnny IZ8EWD Il 01/12/2024 21:24, George Baltz ha scritto: > I found one problem last weekend in the CQWW CW contest - CW sending > is very unreliable (random failures, timeouts, duplicate messages, > delays) and even lockups requiring restart of the logging > program(tlf), I've been looking at the code, and it looks to me like > a thread safety problem. Happens only when the app mixes CW sending > with polling for freq/mode. > > I've found ways to make it better, but not sure of a complete fix. > > > On 12/1/24 1:04 PM, Nate Bargmann wrote: >> Hi All. >> >> Mike has let me know that he is confident that Hamlib is very close to >> the 4.6 release. If anyone has any outstanding patches to include, now >> is the time to submit them! Anything such as spelling/grammar >> corrections and documentation improvements are welcome at this time as >> well. >> >> On my end I've updated my virtual machine to the latest Debian 11 (I >> like >> to run a release behind on builds just to be sure things work across at >> least a few years worth of build tooling) and will be doing some mock >> releases I can test on Debian 12 and Arch. Around the end of this week >> I plan to create the 4.6 branch and make an RC archive that I'll host at >> the daily snapshots page. >> >> Ordinarily I wouldn't be quite so cautious but since it has been some >> time since the last release, I'd like to "shake the bushes" so to speak >> before 4.6. >> >> 73, Nate >> >> >> >> _______________________________________________ >> 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-12-02 18:41:10
|
Played around with this using tlf into a dummy load for about 15 minutes - no problems encountered. Still doesn't address general thread safety, but makes CW better. On 12/2/24 8:24 AM, Michael Black via Hamlib-developer wrote: > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 890ed18c43132c3b0d1b96eff6a2b5d6a96d57ba > https://github.com/Hamlib/Hamlib/commit/890ed18c43132c3b0d1b96eff6a2b5d6a96d57ba > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-02 (Mon, 02 Dec 2024) > > Changed paths: > M src/rig.c > > Log Message: > ----------- > Change morse_data_handler from LOCK to rig_lock as it needs to always use it > > > Commit: 65832ecf53b3788ae3adc1eefe697b7e0112ac7c > https://github.com/Hamlib/Hamlib/commit/65832ecf53b3788ae3adc1eefe697b7e0112ac7c > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-02 (Mon, 02 Dec 2024) > > Changed paths: > M src/rig.c > > Log Message: > ----------- > Fix compile warnings > > > Compare: https://github.com/Hamlib/Hamlib/compare/711a35135326...65832ecf53b3 > > 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-12-02 13:24:38
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 890ed18c43132c3b0d1b96eff6a2b5d6a96d57ba https://github.com/Hamlib/Hamlib/commit/890ed18c43132c3b0d1b96eff6a2b5d6a96d57ba Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-02 (Mon, 02 Dec 2024) Changed paths: M src/rig.c Log Message: ----------- Change morse_data_handler from LOCK to rig_lock as it needs to always use it Commit: 65832ecf53b3788ae3adc1eefe697b7e0112ac7c https://github.com/Hamlib/Hamlib/commit/65832ecf53b3788ae3adc1eefe697b7e0112ac7c Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-02 (Mon, 02 Dec 2024) Changed paths: M src/rig.c Log Message: ----------- Fix compile warnings Compare: https://github.com/Hamlib/Hamlib/compare/711a35135326...65832ecf53b3 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Black M. <mdb...@ya...> - 2024-12-02 13:24:34
|
You're right -- I need to force the lock in this case -- the LOCK() macro was just for the top thread. Just put in a patch to do that. Mike W9MDB On Monday, December 2, 2024 at 03:44:36 AM CST, George Baltz <geo...@gm...> wrote: I'll give it a try, but I don't think it'll make a difference. LOCK() depends on rs->depth, which morse_data_handler() has no control over. Most times it will be a NOP(depth==0), but worse is if some other thread changes depth while it is running; then LOCK has different actions at beginning and end of loop. On 12/1/24 11:41 PM, Michael Black via Hamlib-developer wrote: > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 5219ef2b26fa657e9370fefbdfa6396ecda7faa3 > https://github.com/Hamlib/Hamlib/commit/5219ef2b26fa657e9370fefbdfa6396ecda7faa3 > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-01 (Sun, 01 Dec 2024) > > Changed paths: > M src/rig.c > > Log Message: > ----------- > Put a heavier LOCK around send_morse when clearing the buffer > > > Commit: 711a35135326af3f949bd69b227bd3e31d67c6ae > https://github.com/Hamlib/Hamlib/commit/711a35135326af3f949bd69b227bd3e31d67c6ae > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-01 (Sun, 01 Dec 2024) > > Changed paths: > M NEWS > M bindings/csharp/multicast/README.txt > M rigs/icom/ic821h.c > M rigs/kenwood/thf6a.c > M rigs/kenwood/ts590.c > M rigs/yaesu/README.ft920 > M rotators/easycomm/easycomm.txt > M simulators/simts890.c > M src/microham.c > M src/rig.c > M src/sleep.c > > Log Message: > ----------- > Merge branch 'master' of github.com:Hamlib/Hamlib > > > Compare: https://github.com/Hamlib/Hamlib/compare/7b679afa1d85...711a35135326 > > 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-12-02 09:43:15
|
I'll give it a try, but I don't think it'll make a difference. LOCK() depends on rs->depth, which morse_data_handler() has no control over. Most times it will be a NOP(depth==0), but worse is if some other thread changes depth while it is running; then LOCK has different actions at beginning and end of loop. On 12/1/24 11:41 PM, Michael Black via Hamlib-developer wrote: > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 5219ef2b26fa657e9370fefbdfa6396ecda7faa3 > https://github.com/Hamlib/Hamlib/commit/5219ef2b26fa657e9370fefbdfa6396ecda7faa3 > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-01 (Sun, 01 Dec 2024) > > Changed paths: > M src/rig.c > > Log Message: > ----------- > Put a heavier LOCK around send_morse when clearing the buffer > > > Commit: 711a35135326af3f949bd69b227bd3e31d67c6ae > https://github.com/Hamlib/Hamlib/commit/711a35135326af3f949bd69b227bd3e31d67c6ae > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-12-01 (Sun, 01 Dec 2024) > > Changed paths: > M NEWS > M bindings/csharp/multicast/README.txt > M rigs/icom/ic821h.c > M rigs/kenwood/thf6a.c > M rigs/kenwood/ts590.c > M rigs/yaesu/README.ft920 > M rotators/easycomm/easycomm.txt > M simulators/simts890.c > M src/microham.c > M src/rig.c > M src/sleep.c > > Log Message: > ----------- > Merge branch 'master' of github.com:Hamlib/Hamlib > > > Compare: https://github.com/Hamlib/Hamlib/compare/7b679afa1d85...711a35135326 > > 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: Sakari N. <sak...@ni...> - 2024-12-02 07:38:06
|
Hi! There is a problem with IC7300 mode/bandwidth/filter setting: When sending: M CW 1 Meaning to set CW mode with filter #1 Works setting the filter #1 but changes the bandwidth to 50Hz (ic7300 minimum value) If you then send: M CW 2 Meaning to set CW mode with filter #2 it also works, but same way putting bandwidth to 50Hz Same with: M CW 3 After you have run through all these three commands you have every filter's bandwidth set to 50Hz that was not the purpose. If mode CW is replaced with USB it happens in same way (I have not tested LSB but assume the same bug there, too). Using: M CW -1 Works as should leaving bandwidth and filter number untouched and affects only for mode. Higher numbers will set bandwidth by the number given (without touching the filter number): M CW 800 Will put mode CW and bandwidth 800Hz as expected. Instead sending: M CW 801 Will keep the filter untouched but change bandwidth to 900 Not 801 as requested as it does not fit IC7300 BW stepping. Sending : M CW 850 causes: RPRT -1 RPRT -1 And no change to bandwidth. While 850 could be more real request than 801, but does not either fit to IC7300's 100Hz step. Results are still different with values 801 and 850 All this tells something about the bandwidth value checking routine. It should round the bandwidth value to nearest 50Hz, if value is under 500Hz, or to nearest 100Hz if value is over 500Hz And also take account values -1, 1, 2 and 3 with their meanings. [saku@hamtpad ~]$ rigctld --version rigctld Hamlib 4.6~git 2024-11-25T04:29:44Z SHA=dcc7b3 64-bit -- Saku OH1KH Nate Bargmann kirjoitti 1.12.2024 klo 20.04: > Hi All. > > Mike has let me know that he is confident that Hamlib is very close to > the 4.6 release. If anyone has any outstanding patches to include, now > is the time to submit them! Anything such as spelling/grammar > corrections and documentation improvements are welcome at this time as > well. > > On my end I've updated my virtual machine to the latest Debian 11 (I like > to run a release behind on builds just to be sure things work across at > least a few years worth of build tooling) and will be doing some mock > releases I can test on Debian 12 and Arch. Around the end of this week > I plan to create the 4.6 branch and make an RC archive that I'll host at > the daily snapshots page. > > Ordinarily I wouldn't be quite so cautious but since it has been some > time since the last release, I'd like to "shake the bushes" so to speak > before 4.6. > > 73, Nate > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Michael B. <no...@gi...> - 2024-12-02 04:41:43
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5219ef2b26fa657e9370fefbdfa6396ecda7faa3 https://github.com/Hamlib/Hamlib/commit/5219ef2b26fa657e9370fefbdfa6396ecda7faa3 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-01 (Sun, 01 Dec 2024) Changed paths: M src/rig.c Log Message: ----------- Put a heavier LOCK around send_morse when clearing the buffer Commit: 711a35135326af3f949bd69b227bd3e31d67c6ae https://github.com/Hamlib/Hamlib/commit/711a35135326af3f949bd69b227bd3e31d67c6ae Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-01 (Sun, 01 Dec 2024) Changed paths: M NEWS M bindings/csharp/multicast/README.txt M rigs/icom/ic821h.c M rigs/kenwood/thf6a.c M rigs/kenwood/ts590.c M rigs/yaesu/README.ft920 M rotators/easycomm/easycomm.txt M simulators/simts890.c M src/microham.c M src/rig.c M src/sleep.c Log Message: ----------- Merge branch 'master' of github.com:Hamlib/Hamlib Compare: https://github.com/Hamlib/Hamlib/compare/7b679afa1d85...711a35135326 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: George B. <geo...@gm...> - 2024-12-01 23:55:44
|
Did you push it? I don't see anything in the repo. The problem with LOCK() is that it only tries the lock for a single caller(depth==1). Any other value(0,2,3,...) skips the locking call altogether. On 12/1/24 6:01 PM, Black Michael wrote: > I just put a heavier LOCK() around the send_morse loop. See if behaves better now. > > > > > > > > > On Sunday, December 1, 2024 at 02:27:03 PM CST, George Baltz <geo...@gm...> wrote: > > > > > > I found one problem last weekend in the CQWW CW contest - CW sending is > very unreliable (random failures, timeouts, duplicate messages, delays) > and even lockups requiring restart of the logging program(tlf), I've > been looking at the code, and it looks to me like a thread safety > problem. Happens only when the app mixes CW sending with polling for > freq/mode. > > I've found ways to make it better, but not sure of a complete fix. > > > On 12/1/24 1:04 PM, Nate Bargmann wrote: >> Hi All. >> >> Mike has let me know that he is confident that Hamlib is very close to >> the 4.6 release. If anyone has any outstanding patches to include, now >> is the time to submit them! Anything such as spelling/grammar >> corrections and documentation improvements are welcome at this time as >> well. >> >> On my end I've updated my virtual machine to the latest Debian 11 (I like >> to run a release behind on builds just to be sure things work across at >> least a few years worth of build tooling) and will be doing some mock >> releases I can test on Debian 12 and Arch. Around the end of this week >> I plan to create the 4.6 branch and make an RC archive that I'll host at >> the daily snapshots page. >> >> Ordinarily I wouldn't be quite so cautious but since it has been some >> time since the last release, I'd like to "shake the bushes" so to speak >> before 4.6. >> >> 73, Nate >> >> >> >> _______________________________________________ >> 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-12-01 23:02:03
|
I just put a heavier LOCK() around the send_morse loop. See if behaves better now. On Sunday, December 1, 2024 at 02:27:03 PM CST, George Baltz <geo...@gm...> wrote: I found one problem last weekend in the CQWW CW contest - CW sending is very unreliable (random failures, timeouts, duplicate messages, delays) and even lockups requiring restart of the logging program(tlf), I've been looking at the code, and it looks to me like a thread safety problem. Happens only when the app mixes CW sending with polling for freq/mode. I've found ways to make it better, but not sure of a complete fix. On 12/1/24 1:04 PM, Nate Bargmann wrote: > Hi All. > > Mike has let me know that he is confident that Hamlib is very close to > the 4.6 release. If anyone has any outstanding patches to include, now > is the time to submit them! Anything such as spelling/grammar > corrections and documentation improvements are welcome at this time as > well. > > On my end I've updated my virtual machine to the latest Debian 11 (I like > to run a release behind on builds just to be sure things work across at > least a few years worth of build tooling) and will be doing some mock > releases I can test on Debian 12 and Arch. Around the end of this week > I plan to create the 4.6 branch and make an RC archive that I'll host at > the daily snapshots page. > > Ordinarily I wouldn't be quite so cautious but since it has been some > time since the last release, I'd like to "shake the bushes" so to speak > before 4.6. > > 73, Nate > > > > _______________________________________________ > 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: Nate B. <no...@gi...> - 2024-12-01 22:06:44
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: e480bc74796ad6206ae882251db0575127663aad https://github.com/Hamlib/Hamlib/commit/e480bc74796ad6206ae882251db0575127663aad Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2024-12-01 (Sun, 01 Dec 2024) Changed paths: M NEWS M bindings/csharp/multicast/README.txt M rigs/icom/ic821h.c M rigs/kenwood/thf6a.c M rigs/kenwood/ts590.c M rigs/yaesu/README.ft920 M rotators/easycomm/easycomm.txt M simulators/simts890.c M src/microham.c M src/rig.c M src/sleep.c Log Message: ----------- Fix typos Commit: 7b679afa1d851a3d0962f5f3d18ad4ad4088d2b1 https://github.com/Hamlib/Hamlib/commit/7b679afa1d851a3d0962f5f3d18ad4ad4088d2b1 Author: Nate Bargmann <n0...@n0...> Date: 2024-12-01 (Sun, 01 Dec 2024) Changed paths: M NEWS M bindings/csharp/multicast/README.txt M rigs/icom/ic821h.c M rigs/kenwood/thf6a.c M rigs/kenwood/ts590.c M rigs/yaesu/README.ft920 M rotators/easycomm/easycomm.txt M simulators/simts890.c M src/microham.c M src/rig.c M src/sleep.c Log Message: ----------- Merge pull request #1635 from dforsi/fix/typos Fix typos Compare: https://github.com/Hamlib/Hamlib/compare/71698e44325c...7b679afa1d85 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: George B. <geo...@gm...> - 2024-12-01 20:24:53
|
I found one problem last weekend in the CQWW CW contest - CW sending is very unreliable (random failures, timeouts, duplicate messages, delays) and even lockups requiring restart of the logging program(tlf), I've been looking at the code, and it looks to me like a thread safety problem. Happens only when the app mixes CW sending with polling for freq/mode. I've found ways to make it better, but not sure of a complete fix. On 12/1/24 1:04 PM, Nate Bargmann wrote: > Hi All. > > Mike has let me know that he is confident that Hamlib is very close to > the 4.6 release. If anyone has any outstanding patches to include, now > is the time to submit them! Anything such as spelling/grammar > corrections and documentation improvements are welcome at this time as > well. > > On my end I've updated my virtual machine to the latest Debian 11 (I like > to run a release behind on builds just to be sure things work across at > least a few years worth of build tooling) and will be doing some mock > releases I can test on Debian 12 and Arch. Around the end of this week > I plan to create the 4.6 branch and make an RC archive that I'll host at > the daily snapshots page. > > Ordinarily I wouldn't be quite so cautious but since it has been some > time since the last release, I'd like to "shake the bushes" so to speak > before 4.6. > > 73, Nate > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Richard S. <hob...@gm...> - 2024-12-01 19:17:24
|
I took the opportunity to see how builds would go in the Fedora ecosystem from the current latest commit. https://copr.fedorainfracloud.org/coprs/hobbes1069/hamlib/build/8332080/ Everything built except for EPEL 7 which seems to lack the swig3 package. I'll see if the current version in EL 7 will work or not. Thanks, Richard KF5OIM |
|
From: Nate B. <n0...@n0...> - 2024-12-01 18:24:15
|
Hi All. Mike has let me know that he is confident that Hamlib is very close to the 4.6 release. If anyone has any outstanding patches to include, now is the time to submit them! Anything such as spelling/grammar corrections and documentation improvements are welcome at this time as well. On my end I've updated my virtual machine to the latest Debian 11 (I like to run a release behind on builds just to be sure things work across at least a few years worth of build tooling) and will be doing some mock releases I can test on Debian 12 and Arch. Around the end of this week I plan to create the 4.6 branch and make an RC archive that I'll host at the daily snapshots page. Ordinarily I wouldn't be quite so cautious but since it has been some time since the last release, I'd like to "shake the bushes" so to speak before 4.6. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 |
|
From: Michael B. <no...@gi...> - 2024-12-01 17:26:07
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 4a34d4c27f5ae9305e689fccbc3ca496223b5309 https://github.com/Hamlib/Hamlib/commit/4a34d4c27f5ae9305e689fccbc3ca496223b5309 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-01 (Sun, 01 Dec 2024) Changed paths: M NEWS M doc/man1/rigctl.1 M tests/rigctl_parse.c Log Message: ----------- Add new semi-colon separated hex values for send_raw icom https://github.com/Hamlib/Hamlib/issues/1632 Commit: 71698e44325c26c92efd09b027e54cf22f0f18a8 https://github.com/Hamlib/Hamlib/commit/71698e44325c26c92efd09b027e54cf22f0f18a8 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-01 (Sun, 01 Dec 2024) Changed paths: Log Message: ----------- Merge branch 'master' of github.com:Hamlib/Hamlib Compare: https://github.com/Hamlib/Hamlib/compare/5abc606e1390...71698e44325c To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-12-01 17:24:09
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5abc606e13903e821c0ac88a2768f6549c5b8704 https://github.com/Hamlib/Hamlib/commit/5abc606e13903e821c0ac88a2768f6549c5b8704 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-01 (Sun, 01 Dec 2024) Changed paths: M NEWS M doc/man1/rigctl.1 M tests/rigctl_parse.c Log Message: ----------- Add new semi-colon separated hex values for send_raw icom To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Tom S. <ny...@ny...> - 2024-11-27 18:44:29
|
According to the Icom manual, the default address for the 7760 is b2. But I checked the code in GitHub and the default is listed as b1. Is that a typo in the code or do you have info that it’s actually b1 meaning the book is wrong? Tom NY4I 813-205-6388 ny...@ny... > On Nov 27, 2024, at 11:53 AM, Michael Black via Hamlib-developer <ham...@li...> wrote: > > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 610581ca95686a9eb8e407c399816b421e720aa9 > https://github.com/Hamlib/Hamlib/commit/610581ca95686a9eb8e407c399816b421e720aa9 > Author: Michael Black W9MDB <mdb...@ya...> > Date: 2024-11-27 (Wed, 27 Nov 2024) > > Changed paths: > M rigs/icom/ic7760.c > > Log Message: > ----------- > Some updates to IC7760 > > > > 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-11-27 18:35:18
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: dc7bbeca34cd91bd021bcd60dfa936fbd1f242de https://github.com/Hamlib/Hamlib/commit/dc7bbeca34cd91bd021bcd60dfa936fbd1f242de Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-11-27 (Wed, 27 Nov 2024) Changed paths: M rigs/icom/ic7760.c Log Message: ----------- Fix civ address for IC7760 Commit: ab2b5fb9e9d9f8bcf48bac5190b8fa17ce33c04c https://github.com/Hamlib/Hamlib/commit/ab2b5fb9e9d9f8bcf48bac5190b8fa17ce33c04c Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-11-27 (Wed, 27 Nov 2024) Changed paths: M rigs/icom/icom.c Log Message: ----------- Fix IC7760 civ address Compare: https://github.com/Hamlib/Hamlib/compare/d86f0db383cd...ab2b5fb9e9d9 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-11-27 18:15:48
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: d86f0db383cd51c3640aab17de91168351744ec3 https://github.com/Hamlib/Hamlib/commit/d86f0db383cd51c3640aab17de91168351744ec3 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-11-27 (Wed, 27 Nov 2024) Changed paths: M rigs/icom/icom.c M rigs/icom/icom.h Log Message: ----------- Fix 10GHz power watts for IC9700 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-11-27 18:11:59
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 3f90a9323eb3b477fbc92308dee131221a7cac90 https://github.com/Hamlib/Hamlib/commit/3f90a9323eb3b477fbc92308dee131221a7cac90 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-11-27 (Wed, 27 Nov 2024) Changed paths: M rigs/icom/ic7700.c M rigs/icom/ic7760.c Log Message: ----------- Update POWER_METER values for IC7700 and IC7760 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-11-27 16:52:31
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 610581ca95686a9eb8e407c399816b421e720aa9 https://github.com/Hamlib/Hamlib/commit/610581ca95686a9eb8e407c399816b421e720aa9 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-11-27 (Wed, 27 Nov 2024) Changed paths: M rigs/icom/ic7760.c Log Message: ----------- Some updates to IC7760 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.
