Closed bhilburn closed 5 years ago
Thoughts:
I believe there are not any already-existant vocabularies for describing all of these layers. You will have to invent some of them, and some of them need to be fairly freely extensible (e.g. "DJI drone signal link" as you said is just one company's invention and there will be many, many more like that).
Arguably, you should not have a fixed number of layers. There is always the possibility of someone adding another protocol on top of an existing one (though they may become more and more irrelevant to RF signal analysis), or at the other end sending a perfectly good signal into a FM modulator.
This is an extremely difficult problem. There's such a large number of combinations. Professional taxonomers are there for a reason... Based on, in particular, SIGINT efforts I've seen here, I would expect that whatever we do here will fail at some point. We could also just not try, and make the modulation / signal type a free text field.
My problem with making it a free-text field is that we will end up creating many "standards within the standard". I really think we need a canonical way of representing this, but it needs to be flexible, per @kpreid's comments.
I wonder if there are other efforts that have solved similar problems from which we could draw?
So, what are people's thoughts on defining a canonical listing for "common" modulations / PHYs, a way of specifying a hierarchy, and allowing free-form definition of everything else?
It's a compromise, and is open to misuse, but also provides some degree of portability. Thoughts?
Thought: If it is important that readers be able to recognize specific values, and you allow freeform input as well as a canonical list, then writers should be able to specify multiple names for the same thing. Otherwise, the de-facto standard will be whichever "freeform" values get there first, because nobody can change to more uniform ones without breaking compatibility with existing reader software that hasn't been updated.
This same feature also allows writers to provide a general value and a more specific value and the reader does not need to recognize every possible specific value in order to interpret the general one.
(An alternative would be to publish a standard list of synonyms, and have reader software expected to keep up to date with that list, but I dislike this out of vague principle.)
I started to draft modulation annotation type for common digital modulations:
modulation = single_carrier_modulation | multi_carrier_modulation
Modulation type is composed of various subfields:
single_carrier_modulation_type = "QAM" | "PSK" | "ASK" | "FSK" | new_single_carrier_modulation_type
single_carrier_modulation_symbols = "2" | "B" | "4" | "Q" | "8" | "16" | new_single_carrier_modulation_symbols
single_carrier_modulation = single_carrier_modulation_symbols ["-"] single_carrier_modulation_type
subcarrier_modulations = single_carrier_modulation [ "/" single_carrier_modulation [...]]
multiplexing_type = "OFDM" | "GFDM" | "FBMC" | new_multiplexing_type
multi_carrier_modulation = multiplexing_type "-" subcarrier_modulations
The modulation types is extensible with three optional free fields:
new_multiplexing_type
alphanumeric stringnew_single_carrier_modulation_type
alphanumeric stringnew_single_carrier_modulation_symbols
alphanumeric stringThey shall be not equal to any already specified single_carrier_modulation_type
, single_carrier_modulation_symbols
, multiplexing_type
Valid examples are
modulation = "BPSK"
which is equal to "B-PSK"
, "2PSK"
, "2-PSK"
"2PSK"
modulation = "OFDM-64QAM"
modulation = "OFDM-64QAM/BPSK"
in case subcarrier modulation types varymodulation = "OFDM-2FSK"
(doesn't make sense, but possible)Definition of a new modulation type
new_single_carrier_modulation_type = "OOK"
modulation = "OFDM-OOK"
Modulation parameters should be specified separately
freq_subcarrier_spacing
double-valued frequency (HZ) of subcarrier spacing valid only for multi_carrier_modulation
@kpreid - Good point.
@dimitriblock - Whoa, nice work! It's really helpful to see sketch of what this might look like. I like the direction you are taking this, too.
To enable the addition of arbitrary new layers to further describe things, we could append something like (trying to mimic your meta-language, here):
new_type_descriptor = [new_descriptor "-" [...]] multi_carrier_modulation
One question: should we organize this going the opposite direction? So, for example, should it be:
Wireless Webcam - 802.11ac - OFDM - 64QAM
Or:
64QAM - OFDM - 802.11ac - Wireless Webcam
@bhilburn From signal-point of view the modulation type is more important than its application. Therefore, a modulation/signal type should focus on modulation and not on higher-layer coding, PDUs, ...
In my opinion the spec extension shall limit to:
Higher-layer processing like framing, coding, spectrum spreading techniques have limited impact on signal characteristics and should not be considered in the spec extension.
@dimitriblock - You have a good point, but at the same time, I don't want to prevent people from creating a deeper / more precise description of signals and links. That said, I think what you described is a great justification for where to describe the boundary of what we define canonically and what we leave "open".
So, going back to your original list, what analog or digital modulations should we add to the list? =)
Mainly adapted from wikipedia:
modulation = analog_modulation | digital_single_carrier_modulation | digital_multi_carrier_modulation
analog_modulation = "AM" | "DSB" ["-" analog_am_carrier_variants] | "SSB" [ "-" analog_am_carrier_variants] | "VSB" ["-" analog_am_carrier_variants] | "QAM" | "FM" | "PM" | new_analog_modulation_type
analog_am_carrier_variants = "WC" | "SC" | "RC"
digital_single_carrier_modulation_type = "QAM" | "PSK" | "ASK" | "FSK" | "OOK" | "CPM" | "MSK" | "CPFSK" | "WDM" | new_digital_single_carrier_modulation_type
digital_single_carrier_modulation_symbols = "2" | "B" | "4" | "Q" | "8" | "16" | new_digital_single_carrier_modulation_symbols
digital_single_carrier_modulation = digital_single_carrier_modulation_symbols ["-"] digital_single_carrier_modulation_type | "OQPSK"
digital_multiplexing_type = "OFDM" | "GFDM" | "FBMC" | "TDM" | "FDM" | "PDM" | "SM" | "SMX" | new_digital_multiplexing_type
digital_subcarrier_modulations = digital_single_carrier_modulation [ "/" digital_single_carrier_modulation [...]]
digital_multi_carrier_modulation = digital_multiplexing_type "-" digital_subcarrier_modulations
The modulation types is extensible with four free fields:
new_analog_modulation_type
alphanumeric stringnew_digital_multiplexing_type
alphanumeric stringnew_digital_single_carrier_modulation_type
alphanumeric stringnew_digital_single_carrier_modulation_symbols
alphanumeric stringThe list is still not complete but contains the common modulations.
Actually, IMO the modulation
field should be parsable. So, in case a free field is nonempty, its content must be used in modulation
. So, while remaining extensible, it has to follow specific form.
@bhilburn The same parseble concept could be applied for more detailed descriptions eg WLAN
. But I didn't consider it yet.
I removed the modulation parameters eg freq_subcarrier_spacing
because they maybe very specific and also nonstatic.
Comment: Maybe the terms digital_subcarrier_modulations
and digital_multi_carrier_modulation
are misleading for non-FDM multiplexing.
Closing this to follow conversation in #87
One of the most popular annotation types is going to be signal / modulation type. Per #13, for anything that we know is going to be used heavily, we are going to create canonical extension namespaces so that we don't end up with a bunch of competing sub-standards for describing annotations in SigMF.
(Recall, supporting canonical extension namespaces are not required to be SigMF
compliant
, but simply provide a common namespace for those that want it).Thus, I would like to start hammering down how this namespace works. In my mind, there is a taxonomy of signal types that people will want to use. For example:
So, a few questions based on this: