Right now here are the modes that we are tracking on DB:
GFSK, PSK31, FFSK, MSK, PSK, BPSK, SSB, MSK, FMN, CW, SSTV, APRS, BFSK, AFSK, FM
The problem with this list is that it includes both Modes and Modulations and also Names.
APRS is the name, while NFM is the mode and FSK is the modulation.
APT is the name, while NFM is the mode and AM is the modulation.
I propose we start tracking those much more clearly in the DB. Amend the current transmitter model we have to accommodate that. This would be tremendously helpful on making sure rigs (radios or SDRs) would be setup perfectly for RX or TX.
I believe it is of great value to clean up the database at this point in time.
We can separate the enties into name, mode, modulation, TX|RX
It should be straightforward and a good “investment” for the future
I think the current approach is the best. Each name refers to a mode with very specific characteristics which cannot be easily analysed to the required detail using only the two additional fields you propose.
In your example, APT is not exactly NFM mode and AM modulation. It’s 85% AM modulation on top of a 34kHz FM modulation. Neither is standard AM or NFM mode. For instance, NFM refers to ±2.5kHz FM which, if used, would probably not produce a usable image.
true @Acinonyx but how would we know the rig settings from the mode name currently? We need to track this to know what settings we are sending through rigctl, right?
The mappings from modes to exact demodulation and decoding settings should be done on the client where all possible cases would anyway be handled for bringing up the appropriate demodulation and decoding utilities.