hamlib-developer Mailing List for Ham Radio Control Libraries (Page 24)
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-21 20:59:42
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 27c4eb19ee32b46e4740f781d9f2470638e9f459 https://github.com/Hamlib/Hamlib/commit/27c4eb19ee32b46e4740f781d9f2470638e9f459 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-13 (Fri, 13 Dec 2024) Changed paths: M rigs/kenwood/ts590.c Log Message: ----------- Remove TARGETABLE_MODE from TS590.c as mode command needs VFO swap Commit: a2af87068ea6771dc6e298b21e56ec769d6b31b0 https://github.com/Hamlib/Hamlib/commit/a2af87068ea6771dc6e298b21e56ec769d6b31b0 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rotctld.c Log Message: ----------- Fix buffer overflow in rotctld.c Commit: a72aa0cb4171f0039f51c2112b1f523310b66ca7 https://github.com/Hamlib/Hamlib/commit/a72aa0cb4171f0039f51c2112b1f523310b66ca7 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rotctl.c Log Message: ----------- Fix buffer overflow in rotctl.c https://github.com/Hamlib/Hamlib/security/code-scanning/3221 Commit: a81c7d90c41ba6911b75d1806343b318141e6e0b https://github.com/Hamlib/Hamlib/commit/a81c7d90c41ba6911b75d1806343b318141e6e0b Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigswr.c Log Message: ----------- Fix bufferoverflow in rigswr.c Commit: 5f621c9f5327be25432d0d761204faa434afaee2 https://github.com/Hamlib/Hamlib/commit/5f621c9f5327be25432d0d761204faa434afaee2 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigsmtr.c Log Message: ----------- Fix bufferoverflow in rigsmtr.c https://github.com/Hamlib/Hamlib/security/code-scanning/3219 https://github.com/Hamlib/Hamlib/security/code-scanning/3217 Commit: 3d8dbbcc1ada57a8660ccc919c98f40674df4b02 https://github.com/Hamlib/Hamlib/commit/3d8dbbcc1ada57a8660ccc919c98f40674df4b02 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigmem.c Log Message: ----------- Fix bufferoverflow in rigmem.c https://github.com/Hamlib/Hamlib/security/code-scanning/3217 Commit: 0690fbc0c532f71d02ed74106191686d31cf13ea https://github.com/Hamlib/Hamlib/commit/0690fbc0c532f71d02ed74106191686d31cf13ea Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigctltcp.c Log Message: ----------- Fix buffer overflow in rigctltcp.c Commit: 9624f06be96bafaafaf12fe8188d7390cf5821a2 https://github.com/Hamlib/Hamlib/commit/9624f06be96bafaafaf12fe8188d7390cf5821a2 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigctlsync.c Log Message: ----------- Fix buffer overflow in rigctlsync.c https://github.com/Hamlib/Hamlib/security/code-scanning/3215 Commit: 6cf93934a71a2ed143125a9f3b005ad38a542423 https://github.com/Hamlib/Hamlib/commit/6cf93934a71a2ed143125a9f3b005ad38a542423 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigctld.c Log Message: ----------- Fix buffer overflow in rigctld.c https://github.com/Hamlib/Hamlib/security/code-scanning/3214 Commit: 12c453ccd3cbf4455d346f7d4f42fa7061bee0cb https://github.com/Hamlib/Hamlib/commit/12c453ccd3cbf4455d346f7d4f42fa7061bee0cb Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigctlcom.c Log Message: ----------- Fix buffer overflow in rigctlcom.c https://github.com/Hamlib/Hamlib/security/code-scanning/3213 Commit: 72424ac144904dc9c70161fe70c64f8657e89758 https://github.com/Hamlib/Hamlib/commit/72424ac144904dc9c70161fe70c64f8657e89758 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/rigctl.c Log Message: ----------- Fix buffer overflow in rigctl.c https://github.com/Hamlib/Hamlib/security/code-scanning/3212 Commit: e6be427c519ae3228787c728a1bdc5cc5dc31d0c https://github.com/Hamlib/Hamlib/commit/e6be427c519ae3228787c728a1bdc5cc5dc31d0c Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M tests/ampctld.c Log Message: ----------- Fix buffer overflow in ampctld.c Commit: 4b4b1b0d517403f0f460f1a255358b4f1b426e0b https://github.com/Hamlib/Hamlib/commit/4b4b1b0d517403f0f460f1a255358b4f1b426e0b Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M rigs/yaesu/ft991.c Log Message: ----------- Fix buffer overflow in ft991.c https://github.com/Hamlib/Hamlib/security/code-scanning/3209 Commit: 8842ae7c2920799442bfda812fa56c241dfdeebd https://github.com/Hamlib/Hamlib/commit/8842ae7c2920799442bfda812fa56c241dfdeebd Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M rigs/flexradio/smartsdr.c Log Message: ----------- Fix sscanf check in smartsdr.c https://github.com/Hamlib/Hamlib/security/code-scanning/3208 Commit: ec7103582297545948602bc833cf1883fd94e8d8 https://github.com/Hamlib/Hamlib/commit/ec7103582297545948602bc833cf1883fd94e8d8 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M rigs/dummy/aclog.c Log Message: ----------- Fix sscanf check in aclog.c https://github.com/Hamlib/Hamlib/security/code-scanning/3206 Commit: 33293112744fc08f70811af4add9c7dd6f6533fa https://github.com/Hamlib/Hamlib/commit/33293112744fc08f70811af4add9c7dd6f6533fa Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M configure.ac M docker-build/Dockerfile A docker-build/README.Docker.md R docker-build/README.docker Log Message: ----------- Merge branch 'master' of github.com:Hamlib/Hamlib Compare: https://github.com/Hamlib/Hamlib/compare/6bb5c4049943...33293112744f To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-12-21 20:50:46
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 74876c73ae45ed02b4f0ff45f317e59abb6212a1 https://github.com/Hamlib/Hamlib/commit/74876c73ae45ed02b4f0ff45f317e59abb6212a1 Author: Brandon Durepo <no-...@ex...> Date: 2024-12-20 (Fri, 20 Dec 2024) Changed paths: M docker-build/Dockerfile M docker-build/README.docker Log Message: ----------- Added multi-stage Docker build and hamlib-runtime image Commit: 5028a0c440e7643c25ae459f6150c8313b223a7d https://github.com/Hamlib/Hamlib/commit/5028a0c440e7643c25ae459f6150c8313b223a7d Author: Brandon Durepo <no-...@ex...> Date: 2024-12-20 (Fri, 20 Dec 2024) Changed paths: M docker-build/README.docker Log Message: ----------- Added multi-platform support for linux/arm64 and linux/amd64 Commit: 50e10f758223e456e1304e7b8ae8d2092d89a914 https://github.com/Hamlib/Hamlib/commit/50e10f758223e456e1304e7b8ae8d2092d89a914 Author: Brandon Durepo <no-...@ex...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M docker-build/Dockerfile A docker-build/README.Docker.md R docker-build/README.docker Log Message: ----------- Add support for the hamlib-base-image and hamlib-runtime targets - support the arm64 and amd64 platforms on both a base-image and runtime Commit: bef2d13e4a8443ce32bba28116398a3edf156a45 https://github.com/Hamlib/Hamlib/commit/bef2d13e4a8443ce32bba28116398a3edf156a45 Author: Brandon Durepo <no-...@ex...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M docker-build/Dockerfile Log Message: ----------- Added git and vim to the hamlib-base-image Commit: db00197e6adcddd18a810f619d38ac04c87fbd69 https://github.com/Hamlib/Hamlib/commit/db00197e6adcddd18a810f619d38ac04c87fbd69 Author: Brandon Durepo <no-...@ex...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M docker-build/Dockerfile Log Message: ----------- Added Python support Commit: 6bb5c404994308c06bdfd853642b60adb662b78f https://github.com/Hamlib/Hamlib/commit/6bb5c404994308c06bdfd853642b60adb662b78f Author: Michael Black <mdb...@ya...> Date: 2024-12-21 (Sat, 21 Dec 2024) Changed paths: M docker-build/Dockerfile A docker-build/README.Docker.md R docker-build/README.docker Log Message: ----------- Merge pull request #1639 from 8r4n/feature/multi-stage-docker-build Added multi-stage Docker build and hamlib-runtime image Compare: https://github.com/Hamlib/Hamlib/compare/1364996bd298...6bb5c4049943 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Brian M. <bd...@fe...> - 2024-12-20 14:12:06
|
On Thu, 19 Dec 2024 20:40:20 -0600 Nate Bargmann <n0...@n0...> wrote: > As promised, here are the RC builds and tarball: > > https://n0nb.users.sourceforge.net/rc/ > > I still have more to do for a proper release but wanted to make these > available for the testing of package builds on various systems. I've > tested the source build on Debian 11, 12, and 13 (Testing) but as I > don't do any packaging, someone should test it. Likewise for RPM and > other package formats. Test of the Windows installers is also > welcome. > > Please don't update any distribution packages from this tarball! FYI I have created my own hamlib-4.6~rc1 rpm packages on Fedora 41 using the bootstrap script and then building the rpms using the distro tools and tweaked .spec files. They have built OK and I will test them once installed. I can also build hamlib-4.7~git packages in the same way that I built almost 600 4.6~git rpms during the last couple of years. I'd say all good here. -- Brian G8SEZ |
|
From: <gm...@bt...> - 2024-12-20 09:47:44
|
I've tried again and it now can't find (NULL).dll. I can never remember how I resolve these. I've changed the include path, library path and now the environment variable %PATH%. It's a black art that I always seem to have to stumble through. I'll try again later today. I'm using MSVC 2022 (17.11.4). 73 Phil GM3ZZA ________________________________ From: gm...@bt... <gm...@bt...> Sent: 20 December 2024 9:17 AM To: Nate Bargmann <n0...@n0...>; ham...@li... <ham...@li...> Subject: Re: [Hamlib-developer] On toward 4.6 Hi Nate, I've just tried W11 x64. It fails to find a system DLL (COMCTL32). Looks like there's a hard-coded path in there. 73 Phil GM3ZZA ________________________________ From: Nate Bargmann <n0...@n0...> Sent: 20 December 2024 2:40 AM To: ham...@li... <ham...@li...> Subject: Re: [Hamlib-developer] On toward 4.6 As promised, here are the RC builds and tarball: https://n0nb.users.sourceforge.net/rc/ I still have more to do for a proper release but wanted to make these available for the testing of package builds on various systems. I've tested the source build on Debian 11, 12, and 13 (Testing) but as I don't do any packaging, someone should test it. Likewise for RPM and other package formats. Test of the Windows installers is also welcome. Please don't update any distribution packages from this tarball! 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: <gm...@bt...> - 2024-12-20 09:17:22
|
Hi Nate, I've just tried W11 x64. It fails to find a system DLL (COMCTL32). Looks like there's a hard-coded path in there. 73 Phil GM3ZZA ________________________________ From: Nate Bargmann <n0...@n0...> Sent: 20 December 2024 2:40 AM To: ham...@li... <ham...@li...> Subject: Re: [Hamlib-developer] On toward 4.6 As promised, here are the RC builds and tarball: https://n0nb.users.sourceforge.net/rc/ I still have more to do for a proper release but wanted to make these available for the testing of package builds on various systems. I've tested the source build on Debian 11, 12, and 13 (Testing) but as I don't do any packaging, someone should test it. Likewise for RPM and other package formats. Test of the Windows installers is also welcome. Please don't update any distribution packages from this tarball! 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: Nate B. <n0...@n0...> - 2024-12-20 02:40:32
|
As promised, here are the RC builds and tarball: https://n0nb.users.sourceforge.net/rc/ I still have more to do for a proper release but wanted to make these available for the testing of package builds on various systems. I've tested the source build on Debian 11, 12, and 13 (Testing) but as I don't do any packaging, someone should test it. Likewise for RPM and other package formats. Test of the Windows installers is also welcome. Please don't update any distribution packages from this tarball! 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: Nate B. <no...@gi...> - 2024-12-20 00:07:22
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 1364996bd298643a288d79edde45f7fd53cf0816 https://github.com/Hamlib/Hamlib/commit/1364996bd298643a288d79edde45f7fd53cf0816 Author: Nate Bargmann <n0...@n0...> Date: 2024-12-19 (Thu, 19 Dec 2024) Changed paths: M configure.ac Log Message: ----------- Advance to 4.7~git To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2024-12-20 00:04:38
|
Branch: refs/heads/Hamlib-4.6 Home: https://github.com/Hamlib/Hamlib Commit: c0542ae864ce6f9cc4b29b0c30b44e273261d114 https://github.com/Hamlib/Hamlib/commit/c0542ae864ce6f9cc4b29b0c30b44e273261d114 Author: Nate Bargmann <n0...@n0...> Date: 2024-12-19 (Thu, 19 Dec 2024) Changed paths: M configure.ac Log Message: ----------- Advance to 4.6~rc1 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Black M. <mdb...@ya...> - 2024-12-19 18:33:21
|
Nobody has reported success on those bugs being fixed or given more information as requested.Can't wait for this any longer....
Mike W9MDB
On Thursday, December 19, 2024 at 12:14:38 PM CST, Brian Morrison via Hamlib-developer <ham...@li...> wrote:
On Thu, 19 Dec 2024 15:25:55 +0000 (UTC)
Black Michael via Hamlib-developer
<ham...@li...> wrote:
> I don't think we've ever done an "RC" version before....I doubt it
> will get much testing.
A reasonable number of people seem to update to the latest daily build
for Windows when you suggest it Mike. Is that enough?
I see that there are 8 open bugs for 4.6, are these still untested or
inadequately tested?
Personally I am on my 570th local build of 4.6~git but testing that only
covers the IC-7300, TS-890 and common code that they use.
--
Brian G8SEZ
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Brian M. <bd...@fe...> - 2024-12-19 18:13:23
|
On Thu, 19 Dec 2024 15:25:55 +0000 (UTC) Black Michael via Hamlib-developer <ham...@li...> wrote: > I don't think we've ever done an "RC" version before....I doubt it > will get much testing. A reasonable number of people seem to update to the latest daily build for Windows when you suggest it Mike. Is that enough? I see that there are 8 open bugs for 4.6, are these still untested or inadequately tested? Personally I am on my 570th local build of 4.6~git but testing that only covers the IC-7300, TS-890 and common code that they use. -- Brian G8SEZ |
|
From: Nate B. <n0...@n0...> - 2024-12-19 17:12:11
|
* On 2024 19 Dec 09:26 -0600, Black Michael via Hamlib-developer wrote: > I don't think we've ever done an "RC" version before....I doubt it will get much testing. Way back when I did. As it has been quite some time I want to at least be sure the tarball is correct and hopefully some of the packagers will test it. 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: Black M. <mdb...@ya...> - 2024-12-19 15:26:12
|
I don't think we've ever done an "RC" version before....I doubt it will get much testing.
On Thursday, December 19, 2024 at 06:04:38 AM CST, Nate Bargmann <n0...@n0...> wrote:
Well, the flurry of patches and the aftermath of discussion have settled
down so this should be a good time for me to create the 4.6 branch and
rill an RC.
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
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Nate B. <n0...@n0...> - 2024-12-19 12:03:10
|
Well, the flurry of patches and the aftermath of discussion have settled down so this should be a good time for me to create the 4.6 branch and rill an RC. 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: Black M. <mdb...@ya...> - 2024-12-08 04:24:21
|
Hamlib does not have the capability to stop scanning based on carrier detect. Your rig manual says it stops on it's own: (4) AFSCAN This two-position gray push button selects the scan-stop condition. In the undepressed (out) position the scanner will stop whenever any signal is detected (whether or not it is modulated by voice). When this switch is depressed, the scanner will stop only on those signals that have audio modulation, skipping over unmodulated carriers. Mike W9MDB On Saturday, December 7, 2024 at 05:25:14 PM CST, Stephen P via Hamlib-developer <ham...@li...> wrote: Hello I hope my newbie question is permitted, that this is the right place to ask, and my ignorance will be forgiven. I've set out my thought process below, flawed as it may be, and some of the terminology may be off.. I'm experimenting with an old Yaesu FRG-9600 under Windows. I can set mode and frequency using rigctl and also the JRX software (which uses Hamlib), but scanning doesn't work properly as it doesn't stop on an active frequency; I believe this is because there is no squelch detection. The Yaesu does output a 'busy' signal which is wired to the DCD line of my USB to serial interface (CP2102 chip) but I assume that the software isn't looking for it because the file frg9600.c on github contains the statement ".dcd_type = RIG_DCD_NONE" so Hamlib says it's not there. I thought I could edit this setting to change it to ".dcd_type = RIG_DCD_SERIAL_CAR" (assuming that's the correct option) so that the software will look out for the busy signal and stop the scan. However, I can't find where the frg9600.c file settings are stored in the Hamlib windows folders. I'm guessing that they are rolled up into one of the DLL files when compiled. My first plan was to inspect them with a decompiler/viewer so that I could try to edit and recompile them, but I couldn't find the a DLL that contains any mention of FRG-9600 (given the huge number of rig files, I'm puzzled where all these settings end up in the windows installation as the DLL's don't seem very big). Plan B was then to download/clone Hamlib from github, edit frg9600.c (which I have done) and then recompile it for windows using Git Bash or similar so that my edited frg9600.c file ends up wherever it is supposed to be. I'm working with version 1.2.15.2 of Hamlib, as that's what JRX installed. I've got a lot to learn if I'm going to make this work, but I'm willing to persevere. However, am I on the right lines? Will this approach work? Also, is RIG_DCD_SERIAL_CAR the correct option? There is also RIG_DCD_RIG which means " has DCD status support, i.e. rig has get_dcd cap" but that sounds very generic - isn't the specific type of DCD required for it to be handled correctly? Any advice will be very welcome. Many thanks Stephen _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Stephen P <ste...@go...> - 2024-12-07 20:50:13
|
Hello I hope my newbie question is permitted, that this is the right place to ask, and my ignorance will be forgiven. I've set out my thought process below, flawed as it may be, and some of the terminology may be off.. I'm experimenting with an old Yaesu FRG-9600 under Windows. I can set mode and frequency using rigctl and also the JRX software (which uses Hamlib), but scanning doesn't work properly as it doesn't stop on an active frequency; I believe this is because there is no squelch detection. The Yaesu does output a 'busy' signal which is wired to the DCD line of my USB to serial interface (CP2102 chip) but I assume that the software isn't looking for it because the file frg9600.c on github contains the statement ".dcd_type = RIG_DCD_NONE" so Hamlib says it's not there. I thought I could edit this setting to change it to ".dcd_type = RIG_DCD_SERIAL_CAR" (assuming that's the correct option) so that the software will look out for the busy signal and stop the scan. However, I can't find where the frg9600.c file settings are stored in the Hamlib windows folders. I'm guessing that they are rolled up into one of the DLL files when compiled. My first plan was to inspect them with a decompiler/viewer so that I could try to edit and recompile them, but I couldn't find the a DLL that contains any mention of FRG-9600 (given the huge number of rig files, I'm puzzled where all these settings end up in the windows installation as the DLL's don't seem very big). Plan B was then to download/clone Hamlib from github, edit frg9600.c (which I have done) and then recompile it for windows using Git Bash or similar so that my edited frg9600.c file ends up wherever it is supposed to be. I'm working with version 1.2.15.2 of Hamlib, as that's what JRX installed. I've got a lot to learn if I'm going to make this work, but I'm willing to persevere. However, am I on the right lines? Will this approach work? Also, is RIG_DCD_SERIAL_CAR the correct option? There is also RIG_DCD_RIG which means " has DCD status support, i.e. rig has get_dcd cap" but that sounds very generic - isn't the specific type of DCD required for it to be handled correctly? Any advice will be very welcome. Many thanks Stephen |
|
From: Michael B. <no...@gi...> - 2024-12-04 23:16:20
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: be045da06b661234feb6b1258ca58e8c028b9b56 https://github.com/Hamlib/Hamlib/commit/be045da06b661234feb6b1258ca58e8c028b9b56 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-04 (Wed, 04 Dec 2024) Changed paths: M tests/rigctlcom.c Log Message: ----------- Fix set_mode on rigctlcom To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-12-04 21:44:36
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 58924b7bec47a73ee4665030be78b83a530b45c0 https://github.com/Hamlib/Hamlib/commit/58924b7bec47a73ee4665030be78b83a530b45c0 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-04 (Wed, 04 Dec 2024) Changed paths: M rigs/dummy/flrig.c Log Message: ----------- Add DATA_FMN mode to flrig To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-12-04 20:48:33
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 671a3b8562d71f28cb75874d30c90f969a129902 https://github.com/Hamlib/Hamlib/commit/671a3b8562d71f28cb75874d30c90f969a129902 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-04 (Wed, 04 Dec 2024) Changed paths: M rigs/dummy/flrig.c Log Message: ----------- Fix rig_get_DBM in flrig To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Black M. <mdb...@ya...> - 2024-12-04 20:48:30
|
Thanks...I put that in. Mike W9MDB On Wednesday, December 4, 2024 at 02:36:42 PM CST, Philip Rose <gm...@bt...> wrote: Hi Mike, rig.get_DBM returns the value in dB relative to 1mW. S9 is -73 dBm. I've patched flrig.c and this now works with the attached patch. Phil GM3ZZA On 04/12/2024 19:32, gm3zza via Hamlib-developer wrote: > Thanks, Mike. > > I saw the check-in and planned to git pull and recompile when I get the chance. > > Phil GM3ZZA > > On 4 December 2024, at 19:05, Black Michael <mdb...@ya...> wrote: > > > Just tested that and I was using rig.get_smeter -- changed it just now to rig_get_DBM and it matches much better now. > > If you aren't compiling from the git repo here's a new 64-bit DLL with the fix. > > https://www.dropbox.com/scl/fi/q0s2ykjhaz19j7sv84rf6/libhamlib-4.dll?rlkey=m02sjo5hqyfqgquhasdpptals&dl=0 > > Mike W9MDB > > > > > > > > On Wednesday, December 4, 2024 at 08:47:35 AM CST, Philip Rose via Hamlib-developer <ham...@li...> wrote: > > > > > > > > I have noticed a discrepancy when displaying the S-meter reading read from IC-7300 using flrig and hamlib. > > > > > I have looked at the code at each stage. > > The Icom CI-V has: > > Read S-meter level > *(0000=S0, 0120=S9, 0241=S9+60dB) > > Flrig converts this into percentage full-scale deflection (S9+60) (IC7300.cxx l. 1670): > > mtr = (int)ceil(mtr / 2.41); > > > > > and the display on flrig and the actual IC-7300, as far as I can tell, look pretty much the same. > > Hamlib seems to interpret this (flrig.c ll.2388+) as dB above S0. > > > > > case RIG_LEVEL_STRENGTH: > val->i = atoi(value) - 54; > //if (val->i > 0) val->i /= 10; > rig_debug(RIG_DEBUG_TRACE, "%s: val.i='%s'(%d)\n", __func__, value, val->i); > break; > > and converts this to dB above S9 per the comment in rig.h L. 1080. > > #define RIG_LEVEL_STRENGTH CONSTANT_64BIT_FLAG(30) /*!< \c STRENGTH -- Effective (calibrated) signal strength relative to S9, arg int (dB) */ > > > > > However its not - it's out by about 10%. > > > My app then interprets this per the hamlib definition, which seems to the only specified value and I display a version which is several dB lower then that displayed on the rig or on flrig. I couldn't find in the flrig documentation what rig.get_smeter should return. Looking at rig.get_Sunits and rig.get_DBM it looks like a value of 50 is S9, 100 is S9+60 and linearly interpolated over 0-50 and 50-100. > > > > > > I don't know if this is a general problem across all rigs. Is FSD on the flrig S-meter always S9+60? Or will it vary by rig? > > > > > It's not a major issue in the grand scheme of things. I was just curious why I seemed to be displaying a lower value than flrig was. It's not an accurate value anyway, just wondered why it was different. > > > > > 73 Phil GM3ZZA > > > > > > > > > > > > > > > > _______________________________________________ > 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: Philip R. <gm...@bt...> - 2024-12-04 20:36:55
|
Hi Mike, rig.get_DBM returns the value in dB relative to 1mW. S9 is -73 dBm. I've patched flrig.c and this now works with the attached patch. Phil GM3ZZA On 04/12/2024 19:32, gm3zza via Hamlib-developer wrote: > Thanks, Mike. > > I saw the check-in and planned to git pull and recompile when I get the chance. > > Phil GM3ZZA > > On 4 December 2024, at 19:05, Black Michael <mdb...@ya...> wrote: > > > Just tested that and I was using rig.get_smeter -- changed it just now to rig_get_DBM and it matches much better now. > > If you aren't compiling from the git repo here's a new 64-bit DLL with the fix. > > https://www.dropbox.com/scl/fi/q0s2ykjhaz19j7sv84rf6/libhamlib-4.dll?rlkey=m02sjo5hqyfqgquhasdpptals&dl=0 > > Mike W9MDB > > > > > > > > On Wednesday, December 4, 2024 at 08:47:35 AM CST, Philip Rose via Hamlib-developer <ham...@li...> wrote: > > > > > > > > I have noticed a discrepancy when displaying the S-meter reading read from IC-7300 using flrig and hamlib. > > > > > I have looked at the code at each stage. > > The Icom CI-V has: > > Read S-meter level > *(0000=S0, 0120=S9, 0241=S9+60dB) > > Flrig converts this into percentage full-scale deflection (S9+60) (IC7300.cxx l. 1670): > > mtr = (int)ceil(mtr / 2.41); > > > > > and the display on flrig and the actual IC-7300, as far as I can tell, look pretty much the same. > > Hamlib seems to interpret this (flrig.c ll.2388+) as dB above S0. > > > > > case RIG_LEVEL_STRENGTH: > val->i = atoi(value) - 54; > //if (val->i > 0) val->i /= 10; > rig_debug(RIG_DEBUG_TRACE, "%s: val.i='%s'(%d)\n", __func__, value, val->i); > break; > > and converts this to dB above S9 per the comment in rig.h L. 1080. > > #define RIG_LEVEL_STRENGTH CONSTANT_64BIT_FLAG(30) /*!< \c STRENGTH -- Effective (calibrated) signal strength relative to S9, arg int (dB) */ > > > > > However its not - it's out by about 10%. > > > My app then interprets this per the hamlib definition, which seems to the only specified value and I display a version which is several dB lower then that displayed on the rig or on flrig. I couldn't find in the flrig documentation what rig.get_smeter should return. Looking at rig.get_Sunits and rig.get_DBM it looks like a value of 50 is S9, 100 is S9+60 and linearly interpolated over 0-50 and 50-100. > > > > > > I don't know if this is a general problem across all rigs. Is FSD on the flrig S-meter always S9+60? Or will it vary by rig? > > > > > It's not a major issue in the grand scheme of things. I was just curious why I seemed to be displaying a lower value than flrig was. It's not an accurate value anyway, just wondered why it was different. > > > > > 73 Phil GM3ZZA > > > > > > > > > > > > > > > > _______________________________________________ > 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: gm3zza <gm...@bt...> - 2024-12-04 19:32:51
|
Thanks, Mike. I saw the check-in and planned to git pull and recompile when I get the chance. Phil GM3ZZA On 4 December 2024, at 19:05, Black Michael <mdb...@ya...> wrote: Just tested that and I was using rig.get_smeter -- changed it just now to rig_get_DBM and it matches much better now. If you aren't compiling from the git repo here's a new 64-bit DLL with the fix. https://www.dropbox.com/scl/fi/q0s2ykjhaz19j7sv84rf6/libhamlib-4.dll?rlkey=m02sjo5hqyfqgquhasdpptals&dl=0 Mike W9MDB On Wednesday, December 4, 2024 at 08:47:35 AM CST, Philip Rose via Hamlib-developer <ham...@li...> wrote: I have noticed a discrepancy when displaying the S-meter reading read from IC-7300 using flrig and hamlib. I have looked at the code at each stage. The Icom CI-V has: Read S-meter level *(0000=S0, 0120=S9, 0241=S9+60dB) Flrig converts this into percentage full-scale deflection (S9+60) (IC7300.cxx l. 1670): mtr = (int)ceil(mtr / 2.41); and the display on flrig and the actual IC-7300, as far as I can tell, look pretty much the same. Hamlib seems to interpret this (flrig.c ll.2388+) as dB above S0. case RIG_LEVEL_STRENGTH: val->i = atoi(value) - 54; //if (val->i > 0) val->i /= 10; rig_debug(RIG_DEBUG_TRACE, "%s: val.i='%s'(%d)\n", __func__, value, val->i); break; and converts this to dB above S9 per the comment in rig.h L. 1080. #define RIG_LEVEL_STRENGTH CONSTANT_64BIT_FLAG(30) /*!< \c STRENGTH -- Effective (calibrated) signal strength relative to S9, arg int (dB) */ However its not - it's out by about 10%. My app then interprets this per the hamlib definition, which seems to the only specified value and I display a version which is several dB lower then that displayed on the rig or on flrig. I couldn't find in the flrig documentation what rig.get_smeter should return. Looking at rig.get_Sunits and rig.get_DBM it looks like a value of 50 is S9, 100 is S9+60 and linearly interpolated over 0-50 and 50-100. I don't know if this is a general problem across all rigs. Is FSD on the flrig S-meter always S9+60? Or will it vary by rig? It's not a major issue in the grand scheme of things. I was just curious why I seemed to be displaying a lower value than flrig was. It's not an accurate value anyway, just wondered why it was different. 73 Phil GM3ZZA _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Black M. <mdb...@ya...> - 2024-12-04 19:05:20
|
Just tested that and I was using rig.get_smeter -- changed it just now to rig_get_DBM and it matches much better now. If you aren't compiling from the git repo here's a new 64-bit DLL with the fix. https://www.dropbox.com/scl/fi/q0s2ykjhaz19j7sv84rf6/libhamlib-4.dll?rlkey=m02sjo5hqyfqgquhasdpptals&dl=0 Mike W9MDB On Wednesday, December 4, 2024 at 08:47:35 AM CST, Philip Rose via Hamlib-developer <ham...@li...> wrote: I have noticed a discrepancy when displaying the S-meter reading read from IC-7300 using flrig and hamlib. I have looked at the code at each stage. The Icom CI-V has: Read S-meter level *(0000=S0, 0120=S9, 0241=S9+60dB) Flrig converts this into percentage full-scale deflection (S9+60) (IC7300.cxx l. 1670): mtr = (int)ceil(mtr / 2.41); and the display on flrig and the actual IC-7300, as far as I can tell, look pretty much the same. Hamlib seems to interpret this (flrig.c ll.2388+) as dB above S0. case RIG_LEVEL_STRENGTH: val->i = atoi(value) - 54; //if (val->i > 0) val->i /= 10; rig_debug(RIG_DEBUG_TRACE, "%s: val.i='%s'(%d)\n", __func__, value, val->i); break; and converts this to dB above S9 per the comment in rig.h L. 1080. #define RIG_LEVEL_STRENGTH CONSTANT_64BIT_FLAG(30) /*!< \c STRENGTH -- Effective (calibrated) signal strength relative to S9, arg int (dB) */ However its not - it's out by about 10%. My app then interprets this per the hamlib definition, which seems to the only specified value and I display a version which is several dB lower then that displayed on the rig or on flrig. I couldn't find in the flrig documentation what rig.get_smeter should return. Looking at rig.get_Sunits and rig.get_DBM it looks like a value of 50 is S9, 100 is S9+60 and linearly interpolated over 0-50 and 50-100. I don't know if this is a general problem across all rigs. Is FSD on the flrig S-meter always S9+60? Or will it vary by rig? It's not a major issue in the grand scheme of things. I was just curious why I seemed to be displaying a lower value than flrig was. It's not an accurate value anyway, just wondered why it was different. 73 Phil GM3ZZA _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Michael B. <no...@gi...> - 2024-12-04 16:02:05
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 46711b1db4b4f737964f700941c1184db81d5bf1 https://github.com/Hamlib/Hamlib/commit/46711b1db4b4f737964f700941c1184db81d5bf1 Author: Michael Black W9MDB <mdb...@ya...> Date: 2024-12-04 (Wed, 04 Dec 2024) Changed paths: M rigs/dummy/flrig.c Log Message: ----------- Fix FLRig STRENGTH reading to use rig.get_DBM instead of rig.get_smeter -- much better representation To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Philip R. <gm...@bt...> - 2024-12-04 14:45:16
|
I have noticed a discrepancy when displaying the S-meter reading read from IC-7300 using flrig and hamlib. I have looked at the code at each stage. The Icom CI-V has: Read S-meter level *(0000=S0, 0120=S9, 0241=S9+60dB) Flrig converts this into percentage full-scale deflection (S9+60) (IC7300.cxx l. 1670): mtr =(int)ceil(mtr /2.41); and the display on flrig and the actual IC-7300, as far as I can tell, look pretty much the same. Hamlib seems to interpret this (flrig.c ll.2388+) as dB above S0. case RIG_LEVEL_STRENGTH: val->i = atoi(value) - 54; //if (val->i > 0) val->i /= 10; rig_debug(RIG_DEBUG_TRACE, "%s: val.i='%s'(%d)\n", __func__, value, val->i); break; and converts this to dB above S9 per the comment in rig.h L. 1080. #define RIG_LEVEL_STRENGTH CONSTANT_64BIT_FLAG(30) /*!< \c STRENGTH -- Effective (calibrated) signal strength relative to S9, arg int (dB) */ However its not - it's out by about 10%. My app then interprets this per the hamlib definition, which seems to the only specified value and I display a version which is several dB lower then that displayed on the rig or on flrig. I couldn't find in the flrig documentation what rig.get_smeter should return. Looking at rig.get_Sunits and rig.get_DBM it looks like a value of 50 is S9, 100 is S9+60 and linearly interpolated over 0-50 and 50-100. I don't know if this is a general problem across all rigs. Is FSD on the flrig S-meter always S9+60? Or will it vary by rig? It's not a major issue in the grand scheme of things. I was just curious why I seemed to be displaying a lower value than flrig was. It's not an accurate value anyway, just wondered why it was different. 73 Phil GM3ZZA |
|
From: Sakari N. <sak...@ni...> - 2024-12-04 05:59:34
|
Hi! By quick testing all seems to be ok now with IC7300 mode/bandwidth settings. rigctld Hamlib 4.6~git 2024-12-04T05:19:16Z SHA=941e69 64-bit Many thanks ! -- Saku OH1KH Michael Black via Hamlib-developer kirjoitti 3.12.2024 klo 23.32: > 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 > > |
33 messages has been excluded from this view by a project administrator.
