DavidLutton
commented
3 years ago ETSI sometimes provides interferers or reference signals for compliance testing to European standards
Being able to handle these with a SDR, would be more flexible. Given that we have only 1 matching generator.
An example is with the standard for EN 303 340 Digital Terrestrial TV Broadcast Receivers and the corresponding zip file in the same directory. Which contains Anritsu (p7), Keysight, or preceding generation Keysight files and Rohde & Schwarz (p15) vector signal generator waveform files. (Links to manufactures give some detail of the data packing used)
I tried to run the current SigMF write example, which got stuck on a JSONDecodeError.
I will try again when the release makes it to pypi #165
bhilburn
jsallay
This comes out of a working group discussion at GRCon21.
Many users have use cases where they need to interact with a variety of data formats - many of which are not supported SigMF formats. SigMF can still provide value in these cases because it can provide a uniform and consistent way of describing metadata for all of these data files.
What users are presently doing is hacking a SigMF reader to allow for processing these files. This is not a sustainable approach. It is easy to imagine every company or group having their own modified SigMF reader that adds in special support for the non-compliant types that they have to deal with.
I believe that support for processing of non-compliant files can be added with minimal changes to the spec and readers. I would propose the following:
1) For a non-compliant type, a user defines an extension namespace that defines relevant SigMF fields and values. 2) A SigMF reader would need to provide a function to get the items in the global section of the metadata file. 3) A user would call that function, and then could take any desired actions based upon it. This could include launching a flowgraph, calling an executable on disk, downloading a file, etc.
What would this look like in a few different cases? GNURadio - I could write a hier block, that starts by instantiating a SigMF reader block. After construction, I call the function to get the global section. Based upon the contents on the global section, I may add in conversion blocks. I.e. if the global section tells me that this is VITA49 data, then I could instantiate a VITA49 block after the SigMF reader. C++ code - If we have the SigMF reader as an object that I instantiate, then I can know to call the SigMF reader read function, followed by my own processing function based upon the values in the global section.
Generally useful hier blocks could be included in out of tree modules. For example, a gr-vita49 could include a hier blocks for reading and writing VITA49 files. The hier block is still using a standard, spec-compliant reader without any modification.