Add basic support for SigMF input

[kerel-fs]

IQ recordings can only be understood when having a minimum of metadata, namely the datatype of the stored samples and the sample rate. Currently this metadata can be passed to gr-satellites via CLI options (--rawfile or --rawint16, --iq and --samp_rate).

The SigMF specification describes how to store this metadata alongside a recording, enabling applications to understand compliant recordings without user-provided metadata.

💡 Proposed minimal solution

• Add new option --sigmf_in SIGMF_IN (update 2025-02-27: parameter renamed to --sigmf) that can be used to read a SigMF recording. The file is interpreted to be the SigMF Metadata file. Read the datatype and sample rate from this metadata file and set the input source accordingly.

🚀 Possible future enhancements

• SigMF Archives
  The latest SigMF specification describes SigMF Archive files, which are tar archives, that contain one or more SigMF Recording.

  An advantage of using a SigMF Archive file is the fact that it is a single file, whereas a SigMF recording always consist of at least two files: the SigMF Metadata file and the SigMF Dataset file.
  A current disadvantage of using a SigMG Archive file is the current lack of support by most tools.

---

Example usage:

gr_satellites "Reaktor Hello World" --sigmf /satnogs_data/rf/iq/pi9cam/iq_1452119.sigmf-meta

edit 2025-02-27: Updated example to match finalized syntax

[daniestevez]

Thanks for writing a proposal as an issue and also submitting a PR!

Some comments about the design.

1. Could we call the parameter --sigmf rather than --sigmf_in? This is a minor nit, but it feels more consistent with other parameters (e.g., --wavfile and --rawfile rather than --wavfile_in and --rawfile_in).

2. Could we allow that the value of the --sigmf parameter is either the .sigmf-data file or the .sigmf-meta file? This is reasonably easy to handle in code, and it saves the user from having to remember which of them should be passed. Other tools do it like so. For instance, you can either run inspectrum file.sigmf-data or inspectrum.sigmf-meta. Moreover, if/when SigMF archive support is implemented, this could also be done by detecting whether the extension of the value passed is .sigmf.

3. I agree that SigMF archive support is a heavier lift, and probably worth to leave it as a future goal. It is true that there is lack of support in many tools. In particular, there isn't a GNU Radio File Source that understands SigMF archives and is able to extract the raw samples. I think that it should be possible to parse the tar structure in Python (e.g., in gr_satellites) to determine what is the offset of the raw samples within the tar file, and then run a regular File Source with that offset, but that feels more of a workaround than the proper way to do it.

[kerel-fs]

1. ok, renamed the parameter to --sigmf.
2. Done. I had though about this as well, just didn't implement it until now.
3. The method you describe for parsing SigMF archives should work, yes. The related issue in inspectrum is inspectrum#182.

[daniestevez]

#721 is merged now, but perhaps we want to keep this issue open, as it indicates the path forward to eventually adding more datatypes and SigMF archives.