@KajWiik: That seems to make sense to me.
Just for fun, I decided to check out what I (currently) get from Wikipedia’s “Telecommunications” page:
“Telecommunication is the transmission of signs, signals, messages, words, writings, images and sounds or information of any nature by wire, radio, optical or other electromagnetic systems”
From this definition, I could definitely see having “Julia Group” for “Telecommuncations” that would encompass pretty much everything that has been brought to light in this thread.
For example, it would probably place the SDR-related stuff in one of (possibly many) analog “telecommunications” modules. And yes, despite SDR being implemented with discrete-time-based machines (that introduce quantization noise due to the finite resolution of its internal registers), I consider the SDR radio itself as an analog component.
I am not certain yet how the functionality for such a Julia group should be split into different modules, but I do think it reasonable to have all that is discussed here under the same umbrella. So, I don’t necessarily think that “SDR” has to be moved to its own “Group”.
Then again, I am willing to change my vote if another practical solution is presented. I don’t mind @mbaz’ suggestion of creating a group called “communication systems” or “communication engineering” myself. As long as it isn’t too ambiguous, and that people can find the tools they need.
Personally, I am much more interested in the structure of the modules within. I don’t particularly like interdependencies between modules, and much prefer when dependencies follow a nice, clean (non-cyclical) tree structure. I also prefer a structure where you only have to pull in the elements you actually need. That makes it much less likely that changes in the included modules are going to break your code (even if the broken code isn’t really used by your solution).