Consider a simple hardware focused extension namespace

[storborg]

This ticket is a followup to a verbal discussion about GNU Radio based SigMF tools on July 21, as requested by @bhilburn.

The Problem

During that discussion, we observed that the current core spec and available extension namespace are insufficient for capturing the range of metadata that is exposed by common hardware interfaces. As a simple example, a "debug record" feature added to an existing modem flowgraph would probably want to capture the RF daughterboard serial number(s) for the sake of tracking possible impairments or calibration side effects. We don't want users to develop their own different ways of recording this metadata.

For the most part I think this issue is relevant on the receive side, and thus to a SigMF writer or an offline analysis tool, but there may be a limited set of metadata which is also important to transmit functionality. At the momemnt this is motivated by work on gr-sigmf, but I think it's applicable outside of GNU Radio as well.

Here's an initial scattershot enumeration of such fields, all of which are theoretically available inside GNU Radio either directly (via API access) or indirectly (inferred via lookup of the hardware config). Obviously, specific GR block support for these varies widely.

• Radio model number / name
• Radio hardware revision
• Radio serial number(s)
• Additional signal chain serial number(s): RF daughterboards, block downconverters, LO synthesizers
• Signal chain component names, hardware revision
• Impairment calibration status, filename, or even just coefficients
• Power calibration status, offsets
• Calibration dates
• Clock source
• Time source
• Hardware temperature(s)
• RF port / channel selection
• Oscillator serial number
• GPS locked vs holdover
• Oscillator type
• List of gain settings, or a single scalar gain setting: also related to things ike preamp bypass
• AGC mode
• Power management modes: e.g. USRP RF daughterboard performance vs. powersave
• Analog filter and preamp path state: often just a single named path selection, but increases in complexity on e.g. Rhodium or ZBX
• Digital filter configuration: a possible dramatic simplification of this could just be to record the native ADC rate
• FPGA processing stages present: maybe names, GUIDs
• User EEPROM data
• List of LO frequencies, or a single "effective RF center frequency"
• Type of LO: could be specific like synthesizer part numbers, or broad like DDS vs PLL
• List of DDC frequencies / types: maybe something like CORDIC / LUT / Taylor-corrected LUT
• LO identity information: shared LOs, known phase offsets, or boolean coherent flag
• LO lock bits: e.g. when continuously recording during retunes

Possible Solution

I propose a new extension namespace which includes some set of these fields and others that are exposed by commerically available hardware interfaces.

It likely doesn't make sense to include all of the above fields in a generalized extension namespace. For lack of any better strategy, I would suggest focusing on fields that are easy to reconcile across all of the currently-supported hardware interface blocks in GR core, and punting everything else.

This could also help to serve as an encouragement to hardware vendors to implement their own extension namespaces, since they can choose to reduce the scope of that task and focus on their unique features.

Alternatives

There are some other possible paths to solving this, but I don't think any are wise:

• Add more fields to the core spec
• Make hardware interface tooling emit additional non-compliant fields
• Write new extension namespaces on behalf of hardware vendors

Next Steps

If there's consensus that a new common extension namespace is desirable, I volunteer to work up a list of proposed fields with specific types/definitions, and a brief explanation of how that field could be populated from the current published hardware APIs that are able to provide it.

We'll also need an appropriate name.

[storborg]

Related work which could cleanly cover many of the fields above:
https://github.com/NTIA/sigmf-ns-ntia/blob/master/ntia-sensor.sigmf-ext.md

I'm not sure how this might factor in: perhaps gr-sigmf should just consider ntia-sensor a well-known namespace and implement it.