Separate CMP values per input mode

[mathisschmieder]

In my opinion, compression should automatically be set to 0 or disabled when selecting the Digital Input mode. I am not aware of any digital mode that benefits from compression of the signal.

[db4ple]

Hi,
DIG means input is digital audio (via USB), it is not "Digital Mode". You can also transmit voice via USB digital audio, in this case you may want to use CMP/ALC. So I propose to leave this to the operator to decide.

73
Danilo

[phaethon]

I can see the pain of OP :) If I use USB for voice and then switch to DIG to use digital mode on the computer, and then back, I have to each time set CMP on/off. And then there are all those cases when I forget.
Another option would be to make it remember separate level of CMP for separate input sources. For MIC it would most often be different level than for DIG, even if you use both for voice. And the operator can still decide. This is of course a broader topic - what is remembered for what dimensions. E.g. I would love display zoom level to be remembered separately for different modes - more zoom for CW, less zoom for USB/LSB.

[mathisschmieder]

Okay, I don't really see the use case but accept the argument. How about a unique CMP value per input mode?

73s, Mathis

[db4ple]

Each input has its own CMP values: well, following my argument, this would be a solution. And would probably make more sense than the "always off" proposal, because I can already see the complaint from the small group of OPs how use the USB audio exactly they way I argued it could be used. And I don't like solutions which potentially immediately create an opposite change request.

[mathisschmieder]

Yes, I think that would be a very good solution!

[mathisschmieder]

The title of this issue has been changed. I will try to read into the code and see if I can implement it myself, although I'm sure Danilo could do it much faster. :)

[db4ple]

Hi Mathis,
the idea is that more people are able to work with the code, not that a few can do things faster. It is not a race, it is collaboration.
BTW, there is already a data structure with some input channel specific settings (gain).
The most interesting question if and how we save the additional set of values to the permanent configuration storage (and read them back). But here I would say, what the heck, use a new EEPROM parameter for each of the inputs.

[mathisschmieder]

Alright, I will go ahead and set up a build environment for the firmware, was looking for an excuse for that either way.

Do you know if SW4STM32 works as IDE/build environment?

[db4ple]

Hi,
we strongly recommend (read don't support anything else) to use either

GNU MCU Eclipse (formerly GNU ARM Eclipse)
Make under Linux
embitz under Windows

With any of these you will have not much trouble to setup the build environment. Since we don't maintain project files for other Eclipse based tools, it would be probably a mess to use the SW4STM32 environment since it also Eclipse based. Only for the very, very determined this would be an option.

We have instructions how to setup the environment in the Wiki. Regarding Eclipse it might be a bit outdated, since the GNU ARM Eclipse is now GNU MCU Eclipse but in general should work if you setup the enviroment as described on the GNU MCU Eclipse projects pages. Feel free to update the instructions in the Wiki if necessary.

[db4ple]

The missing link: https://github.com/df8oe/UHSDR/wiki#contributing

[mathisschmieder]

Okay, I always was under the impression that SW4STM32 was nothing more than a "pre set-up" Eclipse with built-in toolchain. But I will go ahead and set up another "vanilla" Eclipse and toolchain on my Mac and document the process in the wiki!

[db4ple]

SW4STM32 is the STM offer and includes a number of specific changes/differences when it comes to the ARM support. It is a commercial tool (not open source) and tied to just the STM32 whereas GNU MCU Eclipse is open source and supports all ARM processors (NXP,STM, ... ) and now also MIPS.