Help in processing 32 bit I2S IQ data

[Richard Ranson]

I have a home brew SDR radio working with a raspberry pi.  It generates 32 bit IQ data  at 48kHz via the I2S interface (actually 24 bits left justified in a 32 bit word).  GQRX does show the device in the input selection box and seems to work, but unfortunately not quite.  I can tune to a test input signal and hear the tone, but the spectrum display shows it as a double sided spectrum.  The analog IQ is correctly orthogonal on an oscilloscope and the digital data can be captured using python and shown to be orthogonal as well. If I save the IQ data from GQRX, it is 32 bit int real part and all zero imag part.  So all this consistent with GQRX only using one channel of the I2S data stream.  

GQRX detects the sound card with the device~default_input=True,default_output=True,device_id=0,driver=audio,soapy=0

I have found various other answers to get this far, but am now stuck.  I wonder whether something extra is needed in the device string, or a whether the data format needs to be changed to be recognised by GQRX.  For example there is a plughw:my_sdr_name device that has software conversions but that is not listed in the GQRX input selection box.

It seems so close, but not quite right and I don't even know what to search for to make any progress, so any help will be appreciated. TIA Richard

[righthal...@gmail.com]

As far as I know that is no way to get the data directly to GQRX in real time.

You could have your python program write a GQRX I/Q file and

read the data from the file. File Format - 32 floating point binary (real,imag,real,imag,...)

On the other hand, you could pipe the data (32 bit unsigned) into iqSQR in real time from the python program -

pythonProgram | iqSDR.x  -fc 100 -samplerate 48000 -pipe -unsigned 

[Charlie Hotel]

 Maybe you could try and use a FIFO instead of a standard file (named pipe), the script writing the file, GQRX reading it.

I used that trick for frequency shifting the Spectrum of an sdr device for beacon tracking and it worked. Some lag but functional.

Cheers

F1EVY Bernard 

Le 3 avr. 2025 à 23:22, righthal...@gmail.com <righthal...@gmail.com> a écrit :

As far as I know that is no way to get the data directly to GQRX in real time.

--
You received this message because you are subscribed to the Google Groups "Gqrx SDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gqrx+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gqrx/72dc5d67-2a1a-4538-891d-b2caba3e281dn%40googlegroups.com.

[Richard Ranson]

Dear Bernard,

Thank you for your reply. though I am not sure that I have communicated the problem properly, the reference to I2S was unnecessary.  I am using a raspberry pi, GQRX is running on the RPi  and the SDR is a HAT, that interfaces via I2S to the linux audio system (ALSA or pulse I don't understand the difference). So the SDR appears to be a sound card to GQRX, and that is detected as "device ID=0,device=audio,soapy=0".  The ID=0 is the default card which ALSA says is hw:0 having "no software conversions", so the data is always 32 bit int.  I think that this is in principle no different to other radios that are supported by GQRX.

The data is getting into GQRX in real time because I can see a spectrum for the signal from the SRD.  It is just that somewhere the Q data is getting lost.  This is evident from the double sided spectrum view and saving an IQ recording from GQRP showing 32bit integer I and 32 integer zero Q. I doubt that the 32 bit int data is being interpreted as 32 bit float because the audio is a pure sin wave.

If I start GQRP from the command line:

pi@xxxx:~/ $ gqrx
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
gr::log :WARN: file_source0 - file size is not a multiple of item size
Resampling audio 96000 -> 48000
BandPlanFile is /home/pi/.config/gqrx/bandplan.csv
BookmarksFile is /home/pi/.config/gqrx/bookmarks.csv
[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400; UHD_3.15.0.0-4+b1
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
[INFO] Using format CF32.
qt.qpa.xcb: QXcbConnection: XCB error: 148 (Unknown), sequence: 192, resource id: 0, major code: 140 (Unknown), minor code: 20
RtAudio pulse: _NOT_ running realtime scheduling

Which indicated that it is expecting CF32 data (complex float, either 32 bit IQ total or 32 bit I plus 32bit Q, that is not clear to me).  So some software conversion is needed as you suggest. On the other hand it does "half work" in that least one channel is being correctly interpreted!!

Maybe if I could tell GQRX to use the ALSA plughw:0 device that claims to also be the SDR device and have "software conversions available", that might do int to float conversion that you are recommending, but I have not succeeded with that. ALSA seems to do clever things and when it works it is great, but it is also quite opaque and very difficult to debug when it does not do as you expect.

Or using a device string with device=<type> for one of the supported device types that has the appropriate data format would work.  But I am not familar with those devices.

Any other thoughs are appreciated.

73 Richard G3ZTB

[Charlie.Hotel]

Hi Richard,

Sorry, I was more referring to @righthalfplane441: if you made the file a FIFO instead of a normal file, you might achieve the same goal in real time.

If you can't solve the format issue by using your SDR as a direct input device to GQRX you might pipe your SDR data to a FIFO, eventually using a Python script in between to adapt the format and use the playback option of GQRX to read the data from that file/FIFO. You would lose the ability of GQRX to control your device by doing so. I agree it seems odd to use that process, being so close of getting your device directly read and controlled by GQRX...

There might be some hope with: https://codeberg.org/glv/convert-samples

Could there simply be a stereo issue like your device outputing I and Q sequentially on a single channel and GQRX expecting I on Left and Q on right?

Cheers,

Bernard

To view this discussion visit https://groups.google.com/d/msgid/gqrx/862aa45b-a437-4db9-8dcb-38008683158cn%40googlegroups.com.

[Richard Ranson]

Dear All,

Thanks for the help and various pointers.  I was not aware of SdrGlut, iqSDR and will look into that.

As to whether it is actually stereo, that is an interesting point.  I have assumed yes, but maybe not.  Only the audio device works, all the others are expecting to have an appropriate driver installed and so fail.  What little I can understand from the osmocom and saopy code, it may well be that it defaults to mono_l which is what I observe.  Somewhere I saw adding chan=stereo_iq to the device string, but that does not work.  I was hoping for a similarly simple solution, but it seems not.  So I will have to implement the conversion via a pipe or something.

As an alternative, the radio does work nicely with QUISK and there I can see that the data is int32,  alternating I/Q which I think is pretty standard.

Thanks again, 73 Richard