digital: fix yaml and bindings for constellation

[mormj]

Adds implicit conversion to the enum type
Cleans up the binding code a bit (remove some dead code)
Change the dropdown from int to enum (as in other places)

Fixes #4007

[drmpeg]

Still getting an error here.

Value "digital.constellation_calcdist(const_points, sym_map, rot_sym, dims, normalization) if (str(type) == "calcdist") else getattr(digital,'constellation_'+str(type))()" cannot be evaluated:
__init__(): incompatible constructor arguments. The following argument types are supported:
    1. gnuradio.digital.digital_python.constellation_calcdist(constell: List[complex], pre_diff_code: List[int], rotational_symmetry: int, dimensionality: int, normalization: gnuradio.digital.digital_python.constellation.normalization = normalization.AMPLITUDE_NORMALIZATION)

Invoked with: [(-1-1j), (-1+1j), (1+1j), (1-1j)], [0, 1, 3, 2], 4, 1, 'digital.constellation.AMPLITUDE_NORMALIZATION'

[mbr0wn]

@mormj Also, you forgot to sign-off your commit.

[mormj]

Still getting an error here.

Value "digital.constellation_calcdist(const_points, sym_map, rot_sym, dims, normalization) if (str(type) == "calcdist") else getattr(digital,'constellation_'+str(type))()" cannot be evaluated:
__init__(): incompatible constructor arguments. The following argument types are supported:
    1. gnuradio.digital.digital_python.constellation_calcdist(constell: List[complex], pre_diff_code: List[int], rotational_symmetry: int, dimensionality: int, normalization: gnuradio.digital.digital_python.constellation.normalization = normalization.AMPLITUDE_NORMALIZATION)

Invoked with: [(-1-1j), (-1+1j), (1+1j), (1-1j)], [0, 1, 3, 2], 4, 1, 'digital.constellation.AMPLITUDE_NORMALIZATION'

@drmpeg - the value template in the yaml was taking in the normalization parameter as a string. It doesn't seem that value is used entirely consistently and just used to give grc a temporary object to work with and check parameters against? Removing the parameter from the value part of the yaml (still used in the make template) and relying on the default normalization there makes the issue go away.

[drmpeg]

Still getting an error here.

Value "digital.constellation_calcdist(const_points, sym_map, rot_sym, dims, normalization) if (str(type) == "calcdist") else getattr(digital,'constellation_'+str(type))()" cannot be evaluated:
__init__(): incompatible constructor arguments. The following argument types are supported:
    1. gnuradio.digital.digital_python.constellation_calcdist(constell: List[complex], pre_diff_code: List[int], rotational_symmetry: int, dimensionality: int, normalization: gnuradio.digital.digital_python.constellation.normalization = normalization.AMPLITUDE_NORMALIZATION)

Invoked with: [(-1-1j), (-1+1j), (1+1j), (1-1j)], [0, 1, 3, 2], 4, 1, 'digital.constellation.AMPLITUDE_NORMALIZATION'

@drmpeg - the value template in the yaml was taking in the normalization parameter as a string. It doesn't seem that value is used entirely consistently and just used to give grc a temporary object to work with and check parameters against? Removing the parameter from the value part of the yaml (still used in the make template) and relying on the default normalization there makes the issue go away.

That fixes the error, but makes the Normalization Type selection do nothing. You can test it by bypassing the rrc filter in generic_mod.py. Change this line:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/generic_mod_demod.py#L147

to:

self._blocks += [self.chunks2symbols]

And then look at the output of the constellation modulator block with a QT GUI Constellation Sink or use a File Sink and look at the file with a hex editor (ghex shows floating point values).

[mormj]

@drmpeg - this should be fixed now - and changed the type to raw so that the stringifying is not done in the value field (and put normalization back on there).

Question though that may warrant a separate PR - the standard constellation types - QPSK, 16-QAM, etc. don't expose the normalization options - should they pass through the normalization as well?

[drmpeg]

Looks good now.

[drmpeg]

Question though that may warrant a separate PR - the standard constellation types - QPSK, 16-QAM, etc. don't expose the normalization options - should they pass through the normalization as well?

From reading the original PR #2771, I don't think so.