Continously Variable Sample Rate

[bhilburn]

From GRCon17 discussions:

We already have an effort in-motion to allow for continuously variable fields in #55. Early on in SigMF, though, we wrote into the spec that sample rate was immutable for a recording, and cannot change (see #28 for that discussion).

A couple of people said that this precluded the use of SigMF for them, because they had continuously variable sample rates in their systems (I believe for Doppler compensation). Using what we are doing in #55, applied to sample_rate would solve that problem easily.

I think a major question is "can we do this without making reader applications extremely complicated", and I'm not sure what the answer is. If the answer is "no", then perhaps the better solution is to allow this via an extension namespace but not put it in core (and thus it wouldn't be required for compliance, but is possible within the standard).

Thoughts and opinions on this?

[mbr0wn]

If we come up with a good, generic way to make fields either constant (and then they're easy to modify, and human-readable in the JSON file), or alternatively to be specified separately as another dataset (for continuously changing data), then I don't see why this won't also work in the same way.

Does this make things complicated? That depends. Some applications, where sampling rate really matters, might have trouble with this. But they can always choose to not accept data in this format (after all, even people are already clamouring for this feature, I doubt there'll be more than a few % who will actually use it).
Many applications won't actually care all that much about the sampling rate.

[bhilburn]

@mbr0wn - So, I think the main question, here, is whether or not this is something we want to put in core. By putting it into core. we say that in order for a Reader application (for example) to be compliant, it must be able to parse, interpret, and make use of that field. A continuously variable sample rate, I think, clearly adds complexity to applications that might not want to deal with it; I'm concerned it will unnecessarily raise the burden of writing SigMF-compliant applications.

I do want to support this, because it is a legitimate use-case and our work in #55 will make it possible, anyway, but I also want to keep things sane. I think the most obvious solution is to put this in a canonical extension namespace. Thoughts?

[bhilburn]

Focusing work & discussion in #99