RIG_LEVEL_NR

[PianetaRadio]

RIG_LEVEL_NR is defined as float in the range 0.0 - 1.0 converting the original value from radio to this scale.
The problem is that the NR range changes with radio model, for example Yaesu FT-450 NR is 1 - 11, FT-991 is 1 -15, but at the moment there is no way to know this range from the backend.

Extract from newcat.c

LEVEL_NR:
        if (!newcat_valid_command(rig, "RL"))
        {
            RETURNFUNC(-RIG_ENAVAIL);
        }

        if (newcat_is_rig(rig, RIG_MODEL_FT450))
        {
            fpf = newcat_scale_float(11, val.f);

            if (fpf < 1)
            {
                fpf = 1;
            }

            if (fpf > 11)
            {
                fpf = 11;
            }

            SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), "RL0%02d%c", fpf, cat_term);
        }
        else
        {
            if (is_ft991)
            {
                fpf = newcat_scale_float(15, val.f);

                if (fpf > 15) { fpf = 15; }

                if (fpf < 1) { fpf = 1; }
            }
            else
            {
                fpf = newcat_scale_float(15, val.f);

                if (fpf > 15) { fpf = 10; }
            }

            if (fpf < 0)
            {
                fpf = 0;
            }

            SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), "RL0%02d%c", fpf, cat_term);

            if (rig->caps->targetable_vfo & RIG_TARGETABLE_LEVEL && !is_ft2000
                    && !is_ftdx10 && !is_ft710)
            {
                priv->cmd_str[2] = main_sub_vfo;
            }
        }

        break;

[mdblack98]

That is why all values are scaled 0-1 both on set and get. We don't expose the "real" values the rig returns as they are meaningless.  Hamlib has been this way since it was created. Mike W9MDB On Tuesday, May 30, 2023 at 02:43:41 PM CDT, PianetaRadio ***@***.***> wrote: RIG_LEVEL_NR is defined as float in the range 0.0 - 1.0 converting the original value from radio to this scale. The problem is that the NR range changes with radio model, for example Yaesu FT-450 NR is 1 - 11, FT-991 is 1 -15, but at the moment there is no way to know this range from the backend. Extract from newcat.c LEVEL_NR:         if (!newcat_valid_command(rig, "RL"))         {             RETURNFUNC(-RIG_ENAVAIL);         }         if (newcat_is_rig(rig, RIG_MODEL_FT450))         {             fpf = newcat_scale_float(11, val.f);             if (fpf < 1)             {                 fpf = 1;             }             if (fpf > 11)             {                 fpf = 11;             }             SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), "RL0%02d%c", fpf, cat_term);         }         else         {             if (is_ft991)             {                 fpf = newcat_scale_float(15, val.f);                 if (fpf > 15) { fpf = 15; }                 if (fpf < 1) { fpf = 1; }             }             else             {                 fpf = newcat_scale_float(15, val.f);                 if (fpf > 15) { fpf = 10; }             }             if (fpf < 0)             {                 fpf = 0;             }             SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), "RL0%02d%c", fpf, cat_term);             if (rig->caps->targetable_vfo & RIG_TARGETABLE_LEVEL && !is_ft2000                     && !is_ftdx10 && !is_ft710)             {                 priv->cmd_str[2] = main_sub_vfo;             }         }         break; — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mdblack98]

If for some reason you want the raw value from the rig you can it yourself with "W RL0; ;" but that appears to work OK in rigctl but not rigctld. So I've opened another issue for that.
#1306

[mdblack98]

This is now fixed in rigctld if you want raw values and you know the rig command to get it.
rigctl -m 2

Rig command: W RL0; ;
Reply: RL001;

[PianetaRadio]

@mdblack98 you are right concerning the discretization of the raw values into a standard range.
The problem is that noise reduction level is not like for example AF gain or Squelch, every NR level step corresponds to a different NR algorithm (in Yaesu radios), so the user want to exactly now which is actual level referred to the real radio value. It should be like the attenuators, a list of possible values.

However in my GUI I can solve by using the raw command, as you suggested or by a custom list for each rig that supports the NR level.

[PianetaRadio]

PS. There is also issue related to the conversion from float to integer, that need some tricks in the code for obtain the right values.

[mdblack98]

Fixed the Yaesu rigs RIG_LEVEL_NR to default to 1-15 and set FT450 to 1-11.
Should work properly now.

[PianetaRadio]

Ok, so I could retrive from level_gran the LVL_NR range used for the specific rig and convert it into the 0.0 - 1.0 range when I use set or get level function.

[GeoBaltz]

This will fail if issue #1144 is implemented. The generic testing for levels only checks based on RIG_LEVEL_IS_FLOAT, where RIG_LEVEL_NR is included. Should still use the float values, and the affected rigs can convert.

[mdblack98]

Not the intent -- RIG_LEVEL is meant for values that have a range and are not enumerated.
I'm checking all the values to see what the rigs actually have for this as it may have been confused in the past.
May be just the matter of making it RIG_FUNC_NR instead of RIG_LEVEL_NR.

[PianetaRadio]

There is another problem, rigctld does not reflect the real backend level_gran list

[PianetaRadio]

I will test asap.
If I'm right, you change back the LVL_NR in the range 0-1 float. Ok I will take into account this into my GUI.

[GeoBaltz]

When I first read this issue, I was mystified by the comment about problems with the conversion from float to int, and needing some tricks in the code.

Then I came across newcat_scale_float(). Gaaack!! Please tell me we can replace this kludge with a proper rounding to nearest integer. It would at least make the final values deterministic from the user end.

[mdblack98]

Do you have some examples where it doesn't work?

[PianetaRadio]

Tested with the following code:

        for (i = 0; i < RIG_SETTING_MAX; i++)
        {
            if (RIG_LEVEL_NR & rig_idx2setting(i)) break;
        }

        if (RIG_LEVEL_IS_FLOAT(rig_idx2setting(i))) qDebug()<<"float "<<my_rig->caps->level_gran[i].max.f;
        else qDebug()<<"int "<<my_rig->caps->level_gran[i].max.i;

The routine finds index of RIG_LEVEL_NR = 8.
With direct serial port connection the level_gran is corrected reported as float and max = 1.
With NET connection level_gran max is float but = 0.

[mdblack98]

Try my_rig->state->level_gran instead. The caps structure is not the  "current" rig in rigctld.  And rig->state should work both rigctl and rigctld. But I did update level_gran and parm_gran now from netrigctl so your code should work as-is.  Would still recommend you use rig->state instead though. Mike W9MDB On Saturday, June 17, 2023 at 02:08:54 PM CDT, PianetaRadio ***@***.***> wrote: Tested with the following code: for (i = 0; i < RIG_SETTING_MAX; i++) { if (RIG_LEVEL_NR & rig_idx2setting(i)) break; } if (RIG_LEVEL_IS_FLOAT(rig_idx2setting(i))) qDebug()<<"float "<<my_rig->caps->level_gran[i].max.f; else qDebug()<<"int "<<my_rig->caps->level_gran[i].max.i; The routine finds index of RIG_LEVEL_NR = 8. With direct serial port connection the level_gran is corrected reported as float and max = 1. With NET connection level_gran max is float but = 0. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[PianetaRadio]

Tnx, I will check using your suggestion before to update to the last commit.
Anyway I will update my code to use rig->state instead of caps for better compatibility.

Test results will follow...

[PianetaRadio]

Sorry for late reply.
I modified my code before update to your commit 5281361, to use rig->state.level_gran instead of rig->caps->level_gran and the rigctld reports the right format for RIG_LEVEL_NR.