Output type
iHD992 opened this issue · 4 comments
For the Output type the user can choose between complex int16 and complex float32. To my knowledge the maximum bit number of the ADC for sdrplay devices is 14. Is there any benefit using 32 bit?
The reason for the complex float32 option is that most DSP blocks in GNU Radio work with the type 'gr_complex', which is just just a pair of floats (i.e. float32).
In reality those complex float32 outputs are just computed by dividing the actual sample values from the SDRplay API (which are shorts/int16) by 32,768 thus returning a float value that is always between -1.0 and 1.0, as recommended by GNU Radio (https://github.com/fventuri/gr-sdrplay3/blob/main/lib/rsp_impl.cc#L622-L655).
As you can see, the two type of outputs don't really differ in resolution; they are just there as a convenience to the user.
Franco
Thanks for the fast reply. Is there way to save Complex int16 in a file sink directly? Is there a dedicated block to convert Complex int16 to Complex int32 as described by you above? This way 50 % disc space could be saved.
Isn't it computationally really inefficient to convert stuff form int8 or int16 to float32 and do a lot of calculations (e. g. FFTs) afterwards? Do you know why "everything" is just complex float32?
Yes, if your goal is to save the samples to disk by all means use the int16 format, and use a file sink of type short with a vector length of 2 to write them to file. As you wrote in your comment you'll save a lot of disk space.
You can then read your samples back into GNU Radio, and convert them to complex float32 by using a type converter block 'IShort To Complex'.
The main reason why DSP is typically done in floating point instead of small integers/fixed point is because of the overflow problem; most if not all of the DSP algorithm (FIR filters, IIR filters, FFT, etc) are designed to work with 'real' numbers that can vary over orders of magnitude up or down as needed. When you work with int16 (or even worse with int8) you have to be very careful never to go above +32,767 (and never below -32,768), otherwise the numbers will 'wrap-around' to the other end (for instance 32,767 + 1 -> -32,768), and you'll have a big problem!
Besides these days all modern CPUs (and many modern MCUs) can run single precision floating point addition and multiplication in one clock cycle, so there's really no advantage in not using it for DSP work.
Franco
Thanks for your kind and fast answers to the "issue".