hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] On toward 4.6

[Black M. <mdb...@ya...>]

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
  

Re: [Hamlib-developer] On toward 4.6

[Brian M. <bd...@fe...>]

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

Re: [Hamlib-developer] On toward 4.6

[Nate B. <n0...@n0...>]

* 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

Re: [Hamlib-developer] On toward 4.6

[Black M. <mdb...@ya...>]

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
  

Re: [Hamlib-developer] On toward 4.6

[Nate B. <n0...@n0...>]

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

Re: [Hamlib-developer] Modifying a rig file

[Black M. <mdb...@ya...>]

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

[Hamlib-developer] Modifying a rig file

[Stephen P <ste...@go...>]

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] [Hamlib/Hamlib] be045d: Fix set_mode on rigctlcom

[Michael B. <no...@gi...>]

  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

[Hamlib-developer] [Hamlib/Hamlib] 58924b: Add DATA_FMN mode to flrig

[Michael B. <no...@gi...>]

  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

[Hamlib-developer] [Hamlib/Hamlib] 671a3b: Fix rig_get_DBM in flrig

[Michael B. <no...@gi...>]

  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

Re: [Hamlib-developer] S-meter reading - flrig/IC-7300

[Black M. <mdb...@ya...>]

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

Re: [Hamlib-developer] S-meter reading - flrig/IC-7300

[Philip R. <gm...@bt...>]

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

Re: [Hamlib-developer] S-meter reading - flrig/IC-7300

[gm3zza <gm...@bt...>]

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

Re: [Hamlib-developer] S-meter reading - flrig/IC-7300

[Black M. <mdb...@ya...>]

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] [Hamlib/Hamlib] 46711b: Fix FLRig STRENGTH reading to use rig.get_DBM inst...

[Michael B. <no...@gi...>]

  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

[Hamlib-developer] S-meter reading - flrig/IC-7300

[Philip R. <gm...@bt...>]

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

Re: [Hamlib-developer] Fix icom filter selection and bandwidth limits

[Sakari N. <sak...@ni...>]

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
>
>

[Hamlib-developer] [Hamlib/Hamlib] dd15ff: Add KY command to simts590

[Michael B. <no...@gi...>]

  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

Re: [Hamlib-developer] On toward 4.6

[Black M. <mdb...@ya...>]

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

Re: [Hamlib-developer] On toward 4.6

[Black M. <mdb...@ya...>]

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

[Hamlib-developer] [Hamlib/Hamlib] 8f0e99: astyle icom.h and update icom date

[Michael B. <no...@gi...>]

  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

[Hamlib-developer] [Hamlib/Hamlib] 3e0a9e: Fix icom filter selection and bandwidth limits

[Michael B. <no...@gi...>]

  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

[Hamlib-developer] [Hamlib/Hamlib] 8bd74a: Minimal support for KY commands in simts890.c

[Michael B. <no...@gi...>]

  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

[Hamlib-developer] [Hamlib/Hamlib] 558234: Drop addional unwanted space after message

[Michael B. <no...@gi...>]

  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

Re: [Hamlib-developer] [Hamlib/Hamlib] 890ed1: Change morse_data_handler from LOCK to rig_lock as...

[Black M. <mdb...@ya...>]

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