In the Blob Sink yaml here https://github.com/microsoft/azure-software-radio/blob/main/gr-azure-software-radio/grc/azure_software_radio_blob_sink.block.yml#L29 I'm not sure we are dealing with i-shorts correctly, it shows it as using int32 datatype, but i-shorts usually use int16 and then you just have to keep track separately that they are interleaved IQ instead of just reals. That's why when you read in a file that is i-shorts, you read it in as real shorts but then you have to use the i-short-to-complex block. No one really uses int32's themselves (and I don't know of any blocks that use them), so we just need to make sure we support complex float32, float32, int16, complex int16s, uint8's, and maybe complex uint8s. That will cover like 99.99% of use-cases. When you give the Blob Sink the data, there's no difference between complex and real for the int16s and uint8s (chars), you would save them to a binary file the same way, although now that we have SigMF support there is a reason to keep track, perhaps with a "is complex" block param, so that the datatype in the SigMF meta file is accurate.
I think we have to change it to use int16 for the "sc16" type, but then we also need to add a way to distinguish between sc16 and normal int16 other than just using dtype which will now be the same for both, so perhaps a boolean is_complex or something similar that the user can check if they have i-shorts being fed into the block, that way the SigMF side knows how to label it.
In the Blob Sink yaml here https://github.com/microsoft/azure-software-radio/blob/main/gr-azure-software-radio/grc/azure_software_radio_blob_sink.block.yml#L29 I'm not sure we are dealing with i-shorts correctly, it shows it as using int32 datatype, but i-shorts usually use int16 and then you just have to keep track separately that they are interleaved IQ instead of just reals. That's why when you read in a file that is i-shorts, you read it in as real shorts but then you have to use the i-short-to-complex block. No one really uses int32's themselves (and I don't know of any blocks that use them), so we just need to make sure we support complex float32, float32, int16, complex int16s, uint8's, and maybe complex uint8s. That will cover like 99.99% of use-cases. When you give the Blob Sink the data, there's no difference between complex and real for the int16s and uint8s (chars), you would save them to a binary file the same way, although now that we have SigMF support there is a reason to keep track, perhaps with a "is complex" block param, so that the datatype in the SigMF meta file is accurate.
I think we have to change it to use int16 for the "sc16" type, but then we also need to add a way to distinguish between sc16 and normal int16 other than just using dtype which will now be the same for both, so perhaps a boolean is_complex or something similar that the user can check if they have i-shorts being fed into the block, that way the SigMF side knows how to label it.
AB#11258