hamlib-developer Mailing List for Ham Radio Control Libraries (Page 25)
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
(25) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael B. <no...@gi...> - 2024-12-04 05:20:02
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: dd15ffc7bd47a6ba481e42d6211a0f50c908d6c7 https://github.com/Hamlib/Hamlib/commit/dd15ffc7bd47a6ba481e42d6211a0f50c908d6c7 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M simulators/simts590.c Log Message: ----------- Add KY command to simts590 Commit: 941e69eda5b5516e5614f1b69b23fbd69ca74430 https://github.com/Hamlib/Hamlib/commit/941e69eda5b5516e5614f1b69b23fbd69ca74430 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M tests/rigctlcom.c Log Message: ----------- Fix set_mode on rigctlcom Compare: https://github.com/Hamlib/Hamlib/compare/8f0e9909da7c...941e69eda5b5 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Black M. <mdb...@ya...> - 2024-12-03 21:35:40
|
Try this dll -- should behave better. https://www.dropbox.com/scl/fi/q0s2ykjhaz19j7sv84rf6/libhamlib-4.dll?rlkey=m02sjo5hqyfqgquhasdpptals&dl=1 Mike W9MDB On Monday, December 2, 2024 at 01:40:34 AM CST, Sakari Nylund <sak...@ni...> wrote: 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 _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Black M. <mdb...@ya...> - 2024-12-03 21:34:33
|
Try this dll https://www.dropbox.com/scl/fi/q0s2ykjhaz19j7sv84rf6/libhamlib-4.dll?rlkey=m02sjo5hqyfqgquhasdpptals&dl=1 Mike W9MDB On Monday, December 2, 2024 at 12:45:35 PM CST, iz8ewd <iz...@pi...> wrote: 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 _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Michael B. <no...@gi...> - 2024-12-03 21:32:53
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 8f0e9909da7c3f93cc68515b58ce6f199cc61425 https://github.com/Hamlib/Hamlib/commit/8f0e9909da7c3f93cc68515b58ce6f199cc61425 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M rigs/icom/icom.c M rigs/icom/icom.h Log Message: ----------- astyle icom.h and update icom date To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-12-03 21:32:22
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 3e0a9eeae703765f932ffa3dc95e8ed65ec9540d https://github.com/Hamlib/Hamlib/commit/3e0a9eeae703765f932ffa3dc95e8ed65ec9540d Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M rigs/icom/icom.c Log Message: ----------- Fix icom filter selection and bandwidth limits To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-12-03 13:05:55
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 8bd74aa3bcdfec900955c15ef1cc754bfb93d6df https://github.com/Hamlib/Hamlib/commit/8bd74aa3bcdfec900955c15ef1cc754bfb93d6df Author: George Baltz N3GB <Geo...@gm...> Date: 2024-12-02 (Mon, 02 Dec 2024) Changed paths: M simulators/simts890.c Log Message: ----------- Minimal support for KY commands in simts890.c Commit: bdbe66dfa06114974331e42f1072fef78bfa2f1e https://github.com/Hamlib/Hamlib/commit/bdbe66dfa06114974331e42f1072fef78bfa2f1e Author: George Baltz N3GB <Geo...@gm...> Date: 2024-12-02 (Mon, 02 Dec 2024) Changed paths: M rigs/kenwood/kenwood.c Log Message: ----------- Use short (i.e., variable length) messages in kenwood_send_morse() Enabled for TS-890S & TS-990S(if firmware capable) Kludge the kludges in kenwood_transaction() for KY->KY2 change. Commit: 806b08729356d1515b7c2994b032fb79e187f772 https://github.com/Hamlib/Hamlib/commit/806b08729356d1515b7c2994b032fb79e187f772 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M rigs/kenwood/kenwood.c Log Message: ----------- Fix porting unneeded code Commit: cf61b9a178b2ce48eeeaba01b677a31d8ef92e0a https://github.com/Hamlib/Hamlib/commit/cf61b9a178b2ce48eeeaba01b677a31d8ef92e0a Author: Michael Black <mdb...@ya...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M rigs/kenwood/kenwood.c Log Message: ----------- Merge branch 'master' into fix24 Commit: d1d4964a193217da42f57ef7bdeb59796ea7acc2 https://github.com/Hamlib/Hamlib/commit/d1d4964a193217da42f57ef7bdeb59796ea7acc2 Author: Michael Black <mdb...@ya...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M rigs/kenwood/kenwood.c M simulators/simts890.c Log Message: ----------- Merge pull request #1636 from GeoBaltz/fix24 Change Kenwood _send_morse() for TS-890/990 Compare: https://github.com/Hamlib/Hamlib/compare/abe40e6e8b63...d1d4964a1932 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-12-03 12:45:35
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 558234897807c793baa2874e351007a6c827ab37 https://github.com/Hamlib/Hamlib/commit/558234897807c793baa2874e351007a6c827ab37 Author: Thomas Beierlein <to...@ge...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M rigs/kenwood/kenwood.c Log Message: ----------- Drop addional unwanted space after message Kenwood_send_morse adds an unwanted space after each transmission on TS-590S model (see issue 1634). Tests showed that all space before any message gets ignored and all trailing spaces (if any) were compressed to exactly one space. The patch changes the alignment to the right. Commit: abe40e6e8b6322b7811a4466d2a9c4f29440a249 https://github.com/Hamlib/Hamlib/commit/abe40e6e8b6322b7811a4466d2a9c4f29440a249 Author: Michael Black <mdb...@ya...> Date: 2024-12-03 (Tue, 03 Dec 2024) Changed paths: M rigs/kenwood/kenwood.c Log Message: ----------- Merge pull request #1637 from dl1jbe/ts590_fix_kenwood_send_morse Drop addional unwanted space after message Compare: https://github.com/Hamlib/Hamlib/compare/65832ecf53b3...abe40e6e8b63 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 23:30:15
|
The LOCK macro is not for general thread safety. It's just there for the main Hamlib thread. I updated the comment about it to show that. Morse is using rig_lock directly so always asks for level 1. On Monday, December 2, 2024 at 05:25:18 PM CST, George Baltz <geo...@gm...> wrote: 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: 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 |
33 messages has been excluded from this view by a project administrator.
