SigMF Generator Extension

[Teque5]

Potentially have a .sigmf-generator type (or similar) that created sigmf compliant files.

Think of it as an svg but for signals :D

Originally discussed at GNU Radio Conference 2021.

[jacobagilbert]

I've thought about this a bit since we discussed it, and I think that the best way to support this is to implement this as an extension with a separate generator application (possibly "part of" SigMF) as opposed to a new native SigMF type. This will require support for "sigmf-meta only" files of course, but i think we established the value in that shortly after this came up.

[Teque5]

In my group we have discussed something like this for years, but anytime we sit down to brainstorm a nice way to parameterize signals in a parse-able fashion we can always think of signals that break our implementation. A realistic implementation of something like this would need to have the objective of describing many but not nearly all types of packets, modulations, scrambling, and spreading techniques.

If you had something like protocol.grc and renamed it to protocol.sigmf-gen we could be halfway home with no work. Let that definition live somewhere else.

Parameterizing RF could be many times more complex than the whole SigMF spec.

[bhilburn]

I think I'm in agreement with @Teque5's thinking, here (with a small difference in execution). I think we should keep all actual definition of the generator outside of SigMF, and rather just make it possible for a Metadata file to point to that generator (which becomes tremendously more valuable with Metadata-only distributions, as @jacobagilbert points out).

Where I differ with the suggestion as written by @Teque5 is that I had really just imagined it as another field - core:generator_app that points to a file (which is very likely to be a GRC file, honestly). @Teque5 - what are your thoughts on the pros/cons of a new filetype versus a field in Core?

@jacobagilbert - Thoughts on 👆👆?

[bhilburn]

Note: This feels simple to me, so marking it for v1.0.0. If it becomes gating, though, because we can't figure it out, I'd boot it.

[jacobagilbert]

@bhilburn if I understand this correctly, the way this would be used is that a metadata only SigMF file (which will be permitted by #183), say generator-test.sigmf-meta would contain a reference to an application, which ostensibly be capable of using the generator-test.sigmf-meta file and generating generator-test.sigmf-data.

If so, I think that makes a lot of sense to me.

[Teque5]

I think that the implementation suggested by @jacobagilbert can be achieved with the existing core:generator field. We would simply have to modify the spec to suggest that that field would point to a path/program/module that generated that sigmf-data (with parameters?).

[bhilburn]

@Teque5 - The core:generator field is in Annotations right now - do you think that's the right place? I suppose one advantage of that is that you could tag many generators within a single Recording. It would make it a little clunky for specifying a single generator for an entire Dataset though, I'd think?

[jacobagilbert]

@bhilburn The existing annotation scope core:generator field is intended to identify whatever generated that annotation, so i don't think its appropriate for this use personally. Unless I am misunderstanding something, this seems like the reverse (a way to generate data from sigmf global/annotation metadata).

198 will hopefully make this more straightforward, and after that I think it can be implemented as generator.sigmf-ext.md which will let most users not care about this. Generators could be defined at a global, capture, or annotation level. If done at the annotation level, the extension should also define what non-annotated samples should look like at the 'capture' or 'global' level (e.g.: awgn, shaped noise, etc...).

[jacobagilbert]

Also, i'd like to pull this out of the v1.0 critical path; thumbs up this or do it if you agree!