Support 4FSK on CC1101 module

[MrTalon63]

Is your feature request related to a problem? Please describe. Lately I was pondering at CC1101 documentation and read that indeed support hardware 4FSK (on top of other) modulations, due to the nature of how the modulation works it would be handy for projects that require a little bit more bandwidth, as from what I understand the module currently works in standard FSK mode with ability to switch to OOK modulation.

Describe the solution you'd like Ability to switch mode modulation type to 4FSK (or even others like MSK or ASK) just like we can do right now with OOK. I believe there would need to be an additional check as it only allows for 300kBaud maximum throughput compared to 500kBuad when using FSK.

Describe alternatives you've considered It seems like Elechouse CC1101 driver already supports changing modulations to all available, but also seems much more complex than RadioLib.

Additional context None

[jgromes]

There is already support for "slow"/ham-radio-friendly 4-FSK (https://github.com/jgromes/RadioLib/blob/master/examples/FSK4/FSK4_Transmit/FSK4_Transmit.ino), which was intended to support high-altitude ballons. It works on all transceivers supported by RadioLib, including CC1101.

However, from your description, I guess your goal is the opposite, a high datarate transmission. So the question is - what is the advantage of using 4-FSK as opposed to faster FSK? You pointed out yourself that the maximum supported data for 2-FSK is 500 kbps, whereas for 4-FSK the maximum is 300 kBaud, so 600 kbps. Is that difference really crucial to your use case, or are there some other advantages?

Overall, I'm not opposed to adding this, but I would like to see some advantages (other than 20% higher maximum raw data rate), or real-word use cases.

[MrTalon63]

I am aware of the 4-FSK "Horus" transmitter. As for advantages, from what I know and read specifically from CC1101 datasheet, it provides a better spectral efficiency and a tiny uplift in receiving performance. Other than that, I don't really see any other compelling advantages when looking at it with fresh of eyes other than giving an option to use it. I'm also not 100% sure how much work such implementation would require, but from looking at the datasheet it only requires to change the register byte to a different setting as deviation and such should be already handled by the current setting.

[jgromes]

I think I'll keep this open for now with a low priority - if anyone comes up with a good use case/reason to implement this (that cannot be achieved by existing modes), then I will add this faster. Otherwise, it will be further down my todo list.