hamlib-developer Mailing List for Ham Radio Control Libraries (Page 62)
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
(20) |
Nov
(49) |
Dec
(53) |
| 2026 |
Jan
(53) |
Feb
(62) |
Mar
(48) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: George B. <geo...@gm...> - 2024-02-20 18:23:30
|
Trying again, without the attachment... All I have is one more with -vvvv, NOT attached(10MB). It's not the front end(FIFO), it's the call to rig->caps->send_morse from morse_data_handler that is the problem. AFAIK tlf just calls the hamlib api; once it gets to rigctld everything is hamlib code. On 2/20/24 12:02, Black Michael wrote: > I need more logs with -vvvvv and -Z to see timing. > I thought we had it thread safe but maybe tlf is doing something > different. > > I'll have to take a look at tlf. > > > Mike W9MDB > > > > > On Tuesday, February 20, 2024 at 10:50:46 AM CST, George Baltz > <geo...@gm...> wrote: > > > ...but that may just be a symptom. > > > Last weekend I operated a bit in the ARRL DX CW test - first CW contest > since last February. Setup was my TS-890S barefoot into a Buddipole and > a 10M dipole, driven by a laptop running tlf with Hamlib 4.6-git. > > Worked fine for a while, then started getting no response to keyboard, > followed by multiple copies of text being sent. Saw some hamlib errors > displayed in the tlf bottom line, but they vanished too quickly to > remember. Then changed over to running rigctld and configuring tlf to > use hamlib_dummy(#2) as rig. Still getting flaky response and keying. > > So I added -vvv and captured the logs - some are attached. > > Looking at these, then at the code, it looks to me like the problem is > much deeper than rig_send_morse - AFAICT none of the backend code is > thread-safe, nor is the rig protocol itself. Having the main app thread, > morse_data_handler, and other threads all calling the rig backends at > the same time means they are stomping all over each other, and the rig > responses may be consumed by the wrong requestor. > > In the short term, bypassing(reverting) the morse_data_handler would fix > keying. For the long term we need a real plan to make hamlib > thread-safe. This means defining the scope of the threads, what code > needs protection, what are the effects on the application, how to do > error recovery/logging, etc. Making legacy code thread-safe is not easy. > > Comments, please, to the list. > > 73 > > n3gb > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Black M. <mdb...@ya...> - 2024-02-20 17:02:55
|
I need more logs with -vvvvv and -Z to see timing.I thought we had it thread safe but maybe tlf is doing something different.
I'll have to take a look at tlf.
Mike W9MDB
On Tuesday, February 20, 2024 at 10:50:46 AM CST, George Baltz <geo...@gm...> wrote:
...but that may just be a symptom.
Last weekend I operated a bit in the ARRL DX CW test - first CW contest
since last February. Setup was my TS-890S barefoot into a Buddipole and
a 10M dipole, driven by a laptop running tlf with Hamlib 4.6-git.
Worked fine for a while, then started getting no response to keyboard,
followed by multiple copies of text being sent. Saw some hamlib errors
displayed in the tlf bottom line, but they vanished too quickly to
remember. Then changed over to running rigctld and configuring tlf to
use hamlib_dummy(#2) as rig. Still getting flaky response and keying.
So I added -vvv and captured the logs - some are attached.
Looking at these, then at the code, it looks to me like the problem is
much deeper than rig_send_morse - AFAICT none of the backend code is
thread-safe, nor is the rig protocol itself. Having the main app thread,
morse_data_handler, and other threads all calling the rig backends at
the same time means they are stomping all over each other, and the rig
responses may be consumed by the wrong requestor.
In the short term, bypassing(reverting) the morse_data_handler would fix
keying. For the long term we need a real plan to make hamlib
thread-safe. This means defining the scope of the threads, what code
needs protection, what are the effects on the application, how to do
error recovery/logging, etc. Making legacy code thread-safe is not easy.
Comments, please, to the list.
73
n3gb
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: George B. <geo...@gm...> - 2024-02-20 16:50:29
|
...but that may just be a symptom. Last weekend I operated a bit in the ARRL DX CW test - first CW contest since last February. Setup was my TS-890S barefoot into a Buddipole and a 10M dipole, driven by a laptop running tlf with Hamlib 4.6-git. Worked fine for a while, then started getting no response to keyboard, followed by multiple copies of text being sent. Saw some hamlib errors displayed in the tlf bottom line, but they vanished too quickly to remember. Then changed over to running rigctld and configuring tlf to use hamlib_dummy(#2) as rig. Still getting flaky response and keying. So I added -vvv and captured the logs - some are attached. Looking at these, then at the code, it looks to me like the problem is much deeper than rig_send_morse - AFAICT none of the backend code is thread-safe, nor is the rig protocol itself. Having the main app thread, morse_data_handler, and other threads all calling the rig backends at the same time means they are stomping all over each other, and the rig responses may be consumed by the wrong requestor. In the short term, bypassing(reverting) the morse_data_handler would fix keying. For the long term we need a real plan to make hamlib thread-safe. This means defining the scope of the threads, what code needs protection, what are the effects on the application, how to do error recovery/logging, etc. Making legacy code thread-safe is not easy. Comments, please, to the list. 73 n3gb |
|
From: Michael B. <no...@gi...> - 2024-02-19 17:46:59
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 8cc6ce131926b49a2a6bd5e1b1268f98fa00fc78 https://github.com/Hamlib/Hamlib/commit/8cc6ce131926b49a2a6bd5e1b1268f98fa00fc78 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M tests/rigctlcom.c Log Message: ----------- Fix rigctlcom.c for Icom rigs and those that don't have get_vfo To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-02-19 16:42:57
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 91ec3afcda5769d3d39f6684fa205e8a24130fc0 https://github.com/Hamlib/Hamlib/commit/91ec3afcda5769d3d39f6684fa205e8a24130fc0 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M tests/rigctlcom.c Log Message: ----------- Fix get_vfo for Icom rigs in rigctlcom.c To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-02-19 16:34:43
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 1657a0e673e37dc5c32b613b4f51d260998a1575 https://github.com/Hamlib/Hamlib/commit/1657a0e673e37dc5c32b613b4f51d260998a1575 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M tests/rigctlcom.c Log Message: ----------- Fix rigctlcom.c To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Michael B. <no...@gi...> - 2024-02-19 04:26:52
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 34d8b0eec3714a34fa466abbfd2c8fff374784f2 https://github.com/Hamlib/Hamlib/commit/34d8b0eec3714a34fa466abbfd2c8fff374784f2 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-16 (Fri, 16 Feb 2024) Changed paths: M simulators/simts590.c Log Message: ----------- Update simts590.c Commit: 0902b32c457b9e6a2a879e6ecd550891a0560357 https://github.com/Hamlib/Hamlib/commit/0902b32c457b9e6a2a879e6ecd550891a0560357 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-16 (Fri, 16 Feb 2024) Changed paths: M rigs/icom/icom.c Log Message: ----------- Remove debug statement causing warning on mingw64 Commit: 81dae00ea00be7c3976b564a320453c801e9fdd1 https://github.com/Hamlib/Hamlib/commit/81dae00ea00be7c3976b564a320453c801e9fdd1 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-18 (Sun, 18 Feb 2024) Changed paths: M rigs/icom/xiegu.c Log Message: ----------- Fix ID read for Xiegu rigs and add x25x26 possible https://github.com/Hamlib/Hamlib/issues/1499 Compare: https://github.com/Hamlib/Hamlib/compare/1ea597b6e133...81dae00ea00b To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: sramp <sra...@gm...> - 2024-02-18 10:44:35
|
Hello, the latest version of SWList (1.4) can connect to the radio receiver via hamlib. The tuned frequency can be obtained on request, by tapping on a button, or automatically. Vice-versa the receiver can be tuned just with a tap on the frequencies list. More info here https://sramp.com/swlist Stefano |
|
From: sramp <sra...@gm...> - 2024-02-18 09:13:27
|
Hello Georgina,
I currently use SDRuno and hamlib and it works well.
SDRUno, being a software application, doesn’t directly connect to physical
serial ports. To enable communication between SDRUno and other software
that uses serial communication (like hamlib), a virtual COM port is used as
an intermediary.
A null-modem emulator is a software tool that emulates the behavior of a
null-modem cable, which is traditionally used to connect two serial devices
(like computers or devices with serial ports) for communication.
To create a virtual COM pairs it is possible to use a null-modem emulator
called com0com.
Instead of using physical serial ports and cables, com0com creates virtual
COM port pairs. These are pairs of virtual serial ports that are connected
to each other as if they were physical ports with a null-modem cable in
between.
For example, if you create a pair COM4 <-> COM5, data sent to COM4 will be
received by COM5, and vice versa.
In the example of COM4 <-> COM5:
– SDRUno communicates with the virtual COM port COM4.
– COM4 is part of the virtual COM port pair created by com0com.
– COM5, the other end of the pair, is connected to hamlib.
– Therefore, SDRUno <-> COM4 <-> COM5 <-> hamlib forms a complete
communication chain.
In summary, the null-modem emulator (com0com) is used to create virtual COM
port pairs, allowing SDRUno to connect to a virtual COM port, which is then
linked to hamlib through another virtual COM port, establishing a
communication path for controlling amateur radio equipment.
You can find more step by step instructions to connect SDRuno in my web
site at this link https://sramp.com/?p=556
|
|
From: Michael B. <no...@gi...> - 2024-02-15 15:28:23
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 7caef5398e7bda1460cf21e8a8ccc5a40856f9bb https://github.com/Hamlib/Hamlib/commit/7caef5398e7bda1460cf21e8a8ccc5a40856f9bb Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-15 (Thu, 15 Feb 2024) Changed paths: M src/cal.c Log Message: ----------- Return exact value for rig_raw2val when appropriate Commit: 4cadea95f8aa5e8c4ab23a6a393d38b96b8a1af6 https://github.com/Hamlib/Hamlib/commit/4cadea95f8aa5e8c4ab23a6a393d38b96b8a1af6 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-15 (Thu, 15 Feb 2024) Changed paths: M src/cal.c Log Message: ----------- Astyle cal.c Commit: 1ea597b6e133aa96c68d76e0bf0b229059ec22d3 https://github.com/Hamlib/Hamlib/commit/1ea597b6e133aa96c68d76e0bf0b229059ec22d3 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-15 (Thu, 15 Feb 2024) Changed paths: M src/misc.c Log Message: ----------- Move time_t test later so 32-bit check of 64-bit functions can work https://github.com/Hamlib/Hamlib/issues/1478 Compare: https://github.com/Hamlib/Hamlib/compare/5d83ac767b02...1ea597b6e133 |
|
From: Michael B. <no...@gi...> - 2024-02-15 15:09:20
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5d83ac767b0288498608134648b7802c6946116d https://github.com/Hamlib/Hamlib/commit/5d83ac767b0288498608134648b7802c6946116d Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-15 (Thu, 15 Feb 2024) Changed paths: M rigs/kenwood/ts480.c Log Message: ----------- Update SDRUno information |
|
From: Michael B. <no...@gi...> - 2024-02-14 22:36:25
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: c471884122de94fa69fd76671eb8cb6ce9b932a8 https://github.com/Hamlib/Hamlib/commit/c471884122de94fa69fd76671eb8cb6ce9b932a8 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-14 (Wed, 14 Feb 2024) Changed paths: M rigs/kenwood/ts590.c M rigs/kenwood/ts890s.c Log Message: ----------- Fix TS590 and TS890 RIG_LEVEL_RFPOWER_METER_WATTS |
|
From: Georgina J. <ge...@m0...> - 2024-02-14 18:49:40
|
Hello, I was delighted to see that SDR Play supported hamlib. However, I was confused over the capabilities as it states Port type: RS-232 and mentions TX. I understand that to interface with one of the SDR units it requires an API. Because of this structure does this mean I cannot control a SDRPlay RSP1A via rigctl? Although SDRUno is a graphical application, it is not accessible with a screen reader and I like to use rigctl to control my transceivers and hoped I could at least select frequency, band and mode of this SDR. Thanks, Georgina Author of Efficient Brief Podcasts, designed to Empower Blind People to enjoy their hobby! For radio accessible stuff for people living with sight loss visit: http://www.spencerweb.net/Downloads/downloads.html Don't forget the most valuable resource in the radio world! www.blindhams.com Why not Join us via AllStar Active Elements Bridge 56870 Blind Hams 506313 or via phone app 50617 Personal Radio Contact info: Call: M0EBP DMR ID: 2346259 Allstar: 521780 52340 Locater: IO83PS |
|
From: Michael B. <no...@gi...> - 2024-02-14 15:00:28
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 47fcf999f063214027be7bbf9ac2115ba759cf2e https://github.com/Hamlib/Hamlib/commit/47fcf999f063214027be7bbf9ac2115ba759cf2e Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-14 (Wed, 14 Feb 2024) Changed paths: M src/misc.c Log Message: ----------- Reduce debug error level for rig_test_2038 |
|
From: Michael B. <no...@gi...> - 2024-02-14 13:56:40
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: f12d653f6ceaa4dadeb17278239a73092d8a9802 https://github.com/Hamlib/Hamlib/commit/f12d653f6ceaa4dadeb17278239a73092d8a9802 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-14 (Wed, 14 Feb 2024) Changed paths: M src/misc.c Log Message: ----------- Try to fix MINGW time_t https://github.com/Hamlib/Hamlib/issues/1478 |
|
From: Michael B. <no...@gi...> - 2024-02-14 13:12:02
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: e1f23429821777b938a69b11f7589e5c0c191e51 https://github.com/Hamlib/Hamlib/commit/e1f23429821777b938a69b11f7589e5c0c191e51 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-14 (Wed, 14 Feb 2024) Changed paths: M amplifiers/elecraft/kpa1500.c M amplifiers/expert/expert.c M amplifiers/gemini/dx1200.c M rigs/anytone/d578.c M rigs/aor/ar2700.c M rigs/aor/ar5000.c M rigs/aor/ar8200.c M rigs/barrett/4100.c M rigs/dorji/dra818.c M rigs/drake/r8b.c M rigs/dummy/tci1x.c M rigs/flexradio/dttsp.c M rigs/flexradio/sdr1k.c M rigs/gomspace/gs100.c M rigs/icmarine/icm700pro.c M rigs/icom/delta2.c M rigs/icom/ic271.c M rigs/icom/ic2730.c M rigs/icom/ic471.c M rigs/icom/ic707.c M rigs/icom/ic728.c M rigs/icom/ic736.c M rigs/icom/ic737.c M rigs/icom/ic738.c M rigs/icom/ic7410.c M rigs/icom/ic775.c M rigs/icom/ic78.c M rigs/icom/ic820h.c M rigs/icom/ic92d.c M rigs/icom/ic970.c M rigs/icom/icr30.c M rigs/icom/icr7000.c M rigs/icom/icr71.c M rigs/icom/icr72.c M rigs/icom/icr8600.c M rigs/icom/icr9000.c M rigs/icom/icrx7.c M rigs/icom/id1.c M rigs/icom/id31.c M rigs/icom/id4100.c M rigs/icom/id51.c M rigs/icom/id5100.c M rigs/icom/perseus.c M rigs/jrc/nrd525.c M rigs/kachina/505dsp.c M rigs/kenwood/ts480.c M rigs/kenwood/ts711.c M rigs/kenwood/ts811.c M rigs/kenwood/ts930.c M rigs/kit/dds60.c M rigs/kit/dwt.c M rigs/kit/hiqsdr.c M rigs/kit/miniVNA.c M rigs/kit/pcrotor.c M rigs/kit/si570avrusb.c M rigs/kit/usrp.c M rigs/lowe/hf235.c M rigs/mds/4710.c M rigs/mds/9710.c M rigs/racal/ra3702.c M rigs/racal/ra6790.c M rigs/rft/ekd500.c M rigs/rs/eb200.c M rigs/rs/ek89x.c M rigs/rs/esmc.c M rigs/skanti/trp8000.c M rigs/skanti/trp8255.c M rigs/tapr/dsp10.c M rigs/tentec/rx340.c M rigs/tentec/rx350.c M rigs/tuner/v4l2.c M rigs/uniden/bc245.c M rigs/uniden/bc250.c M rigs/uniden/bc895.c M rigs/uniden/bc898.c M rigs/uniden/bcd396t.c M rigs/uniden/bcd996t.c M rigs/uniden/pro2052.c M rigs/winradio/g305.c M rigs/winradio/g313-posix.c M rigs/winradio/wr1000.c M rigs/winradio/wr1500.c M rigs/winradio/wr1550.c M rigs/winradio/wr3100.c M rigs/winradio/wr3150.c M rigs/winradio/wr3500.c M rigs/winradio/wr3700.c M rigs/wj/wj8888.c M rigs/yaesu/frg8800.c M rigs/yaesu/frg9600.c M rigs/yaesu/ft1000d.c M rotators/amsat/if100.c M rotators/flir/flir.c M rotators/grbltrk/grbltrk.c M rotators/rotorez/rotorez.c M rotators/saebrtrack/saebrtrack.c M rotators/sartek/sartek.c Log Message: ----------- Promote all BETA to STABLE Promot all ALPHA to BETA |
|
From: George B. <geo...@gm...> - 2024-02-14 06:07:46
|
It should be noted that the code added to rigs/kenwood/ts890.c does ABSOLUTELY NOTHING to achieve the purpose of this commit that the old code doesn't. Aside from the broken test (undefined behavior), the results don't change. Why is that? Because the cal_table said so. All values less than 11 returned from the SM command map to integer watts; 1=1 watt, 2=2 watts, etc, so there are no fractions involved. Values above 10 do map to fractions and are rounded to whole numbers, and that's probably more precision than the data has. On 2/13/24 17:40, Michael Black via Hamlib-developer wrote: > Branch: refs/heads/master > Home: https://github.com/Hamlib/Hamlib > Commit: 972d792a4f82f010c9f8ef77e86ddc364dba7be1 > https://github.com/Hamlib/Hamlib/commit/972d792a4f82f010c9f8ef77e86ddc364dba7be1 > Author: Mike Black W9MDB <mdb...@ya...> > Date: 2024-02-13 (Tue, 13 Feb 2024) > > Changed paths: > M rigs/kenwood/ts590.c > M rigs/kenwood/ts890s.c > > Log Message: > ----------- > Round watt values to whole number >= 10 and 1 decimal place < 10 > > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Michael B. <no...@gi...> - 2024-02-13 22:40:54
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 972d792a4f82f010c9f8ef77e86ddc364dba7be1 https://github.com/Hamlib/Hamlib/commit/972d792a4f82f010c9f8ef77e86ddc364dba7be1 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-13 (Tue, 13 Feb 2024) Changed paths: M rigs/kenwood/ts590.c M rigs/kenwood/ts890s.c Log Message: ----------- Round watt values to whole number >= 10 and 1 decimal place < 10 |
|
From: Michael B. <no...@gi...> - 2024-02-13 22:15:47
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 59aaf1f4c30e9efa729e9b3b5048c8d2e86a4225 https://github.com/Hamlib/Hamlib/commit/59aaf1f4c30e9efa729e9b3b5048c8d2e86a4225 Author: George Baltz N3GB <Geo...@gm...> Date: 2024-02-13 (Tue, 13 Feb 2024) Changed paths: M rigs/kenwood/ts890s.c Log Message: ----------- Minor cleanup of ts890.c Simplify out-of-range check Mute possible cppcheck squawk Round power to whole watts Commit: 45e097d3a46e305bb3bf8c2ca46a1b8dbd7cd40f https://github.com/Hamlib/Hamlib/commit/45e097d3a46e305bb3bf8c2ca46a1b8dbd7cd40f Author: George Baltz N3GB <Geo...@gm...> Date: 2024-02-13 (Tue, 13 Feb 2024) Changed paths: M simulators/simts890.c Log Message: ----------- Update simts890.c Make IF return RX/TX status Document IF data, reformat IF & SF commands Commit: 2b22a42e732b586e64013fc1f88626adcec315d1 https://github.com/Hamlib/Hamlib/commit/2b22a42e732b586e64013fc1f88626adcec315d1 Author: Michael Black <mdb...@ya...> Date: 2024-02-13 (Tue, 13 Feb 2024) Changed paths: M rigs/kenwood/ts890s.c M simulators/simts890.c Log Message: ----------- Merge pull request #1511 from GeoBaltz/fix11 Clean up ts890.c & simts890.c Compare: https://github.com/Hamlib/Hamlib/compare/59217b560ac1...2b22a42e732b |
|
From: Michael B. <no...@gi...> - 2024-02-13 17:19:06
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 59217b560ac1f65e642243f1e0196672c2d5d0de https://github.com/Hamlib/Hamlib/commit/59217b560ac1f65e642243f1e0196672c2d5d0de Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-13 (Tue, 13 Feb 2024) Changed paths: M src/misc.c Log Message: ----------- Add 2038 test for MINGW __time64_t |
|
From: Michael B. <no...@gi...> - 2024-02-12 16:49:15
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 8d33869ca275e8445beb9a93fc51183d0296ac1e https://github.com/Hamlib/Hamlib/commit/8d33869ca275e8445beb9a93fc51183d0296ac1e Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-12 (Mon, 12 Feb 2024) Changed paths: M src/misc.c Log Message: ----------- Show glibs version if available for 2038 test https://github.com/Hamlib/Hamlib/issues/1478 |
|
From: Michael B. <no...@gi...> - 2024-02-11 21:58:25
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: a8cfff8bd34c1f3fb531bafae27f026760b740c1 https://github.com/Hamlib/Hamlib/commit/a8cfff8bd34c1f3fb531bafae27f026760b740c1 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-11 (Sun, 11 Feb 2024) Changed paths: M configure.ac Log Message: ----------- Try adding _TIME_BITS=64 to see if 32-bit build works with it https://github.com/Hamlib/Hamlib/issues/1478 |
|
From: Michael B. <no...@gi...> - 2024-02-11 18:25:21
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 916049b0a5fe790b1a292c75c44f7f31a9eb6385 https://github.com/Hamlib/Hamlib/commit/916049b0a5fe790b1a292c75c44f7f31a9eb6385 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-11 (Sun, 11 Feb 2024) Changed paths: M rigs/icom/icom.c M rigs/icom/icom.h Log Message: ----------- Icom rigs can now use filter_usbd, filter_cw, and filter_usb set-conf options to set filter for USBD/LSBD, USB/LSB, and CW/CWR modes e.g. --set-conf=filter_usbd=2,filter_cw=1,filter_usb=3 https://github.com/Hamlib/Hamlib/issues/1507 |
|
From: Michael B. <no...@gi...> - 2024-02-11 14:03:11
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 6844722faab84e4cca03f405e91c5d6501ca9f6c https://github.com/Hamlib/Hamlib/commit/6844722faab84e4cca03f405e91c5d6501ca9f6c Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-11 (Sun, 11 Feb 2024) Changed paths: M src/usb_port.c Log Message: ----------- Add libusb version info to find_and_open_device |
|
From: Michael B. <no...@gi...> - 2024-02-08 16:00:28
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: f5d6be3b3efe9781763df903d0c062e24b52e143 https://github.com/Hamlib/Hamlib/commit/f5d6be3b3efe9781763df903d0c062e24b52e143 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-02-08 (Thu, 08 Feb 2024) Changed paths: M bindings/Makefile.am Log Message: ----------- Fix a dependency check for bindings |
33 messages has been excluded from this view by a project administrator.
