Selective I/Q recording with SDR

[Dennis M]

I've had an idea rolling around in my head for a while, and I'd like to see if the community might be able to point me in the right direction.

Goal: Record I/Q data for parts (but not all) of a 10MHz swath with an RSP1A (or similar) - preferably using Linux. For example, sample 1.75-10.25 MHz, but only record the amateur bands within that swath of spectrum (plus a bit for band edges).

A few pieces of software support recording I/Q data, but all of them that I can find will only record the entire configured bandwidth. SDRUno has the concept of virtual sub-receivers (VRX) that can decode a selected portion of the bandwidth being sampled. But that VRX can't record the I/Q data.

The closest I've come to finding something that I think might be able to do it is ghpsdr3-alex (http://www.n8mdp.com/ghpsdr3-alex.php), as it is client-server based. But I haven't had any luck getting up with the author. If a monitor receiver could record I/Q data, this might work for my needs.

Any help or pointer in a certain direction would be greatly appreciated. 

73

KC4RAN

Dennis

[righthal...@gmail.com]

sdrTest is a utility that comes with SdrGlut

https://github.com/righthalfplane/SdrGlut

It would be relatively easy to add what you want as an option to sdrTest, but how much use would it get. Taken together 160M, 80M, and 40M is a 1MHZ bandwidth which comes to 8 MB/Second or 28.6 GB/hour. Compressing the streams down to the minimum size it is still 7.2 GB/hour.

[Dennis M]

If I use one RSP1A to record 1.75-2.05, 3.45-4.05, 5.25-5.45, 6.95-7.35 and 10.05-10.2, that would be about 1.65 MHz that I'm interested in... and I have to record 8.45 MHz to get it. About a 5X difference. 

There are lots of SDRs available remotely over the internet. If there was an unknown signal and an amateur (or group) was able to go back and look at that frequency and time period on multiple receivers, they might be able to better understand what's going on. It's adding a "DVR" function to these types of receivers. The lower we make the actual storage requirements, the more people might participate in such an effort. And the longer period of time they might be able to store.

[Roger David Powers]

RSP1A has an on-board FPGA ( https://afedri-sdr.com/images/AFEDRI_SDR-Net_Block_diagram_rev.4.1_800px.jpg ) to create the VRXes.  I have looked at KiwiSDR ( which is a device commonly used for web SDRs ) and it also uses a FPGA to capture just the data of interest, mostly to reduce the data handling needs of the down-stream devices.  KiwiSDR's general purpose CPU is a 1GHz single core 32b ARM chip, almost all the 'heavy lifting' is done in the FPGA on the daughter card.  It's a very cool device, but it is really designed around that single task, capturing receive streams and presenting the resulting spectrograph/waterfall along with demodulated audio inside a web browser.  Therefore it's not as general-purpose as you need, in particular it does not export IQ streams at all.

The closest approach I know of to do what you want is to use a Hermes-Lite 2 device ( https://github.com/softerhardware/Hermes-Lite2/wiki ) which by default supports four receiver slices with up to 384 kHz per slice.  This device is a part of the same family tree as the rest of the openhpsdr stuff. Then, the gnuradio support for it ( https://github.com/softerhardware/Hermes-Lite2/wiki/Software ) will let you make a simple flow to tune each of the four receiver slices and send the IQ samples to a file of your choosing.   It's not a perfect fit for your needs, but it's the closest fit to your needs that I know of using off-the-shelf stuff.

For instance, here's a little flowgraph that took four 48k slices and displayed the resulting spectra:

I was using 48k since I was using a RPi CPU and it didn't really have the horsepower to do more work.  A modestly powered laptop or desktop would have been a better choice.

As they say, some assembly is required.  I have used this stuff and it worked for me, your results may vary.  In particular you must use the gnuradio 3.8 stream since the HL2 support hasn't been adapted to the new 3.9 and later pybind tools.  Also the HL2 devices are only built in batches and right now they are in between batches, and the next batch will either be delayed or see a price increase due to chip shortages, so you either need to wait to buy one or find a used device if you choose to go down this path.  Look at the wiki link above and subscribe to the email list if you want to follow developments in this space.

Feel free to ping me here or via direct email with any questions.

Regards,

RDP

--
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 on the web visit

https://groups.google.com/d/msgid/gqrx/a847fb78-a6d5-4b8c-80dc-dc89bdd9876bn%40googlegroups.com

.

[Dennis M]

I guess I was confused then, because I thought that SDRUno could record I/Q data from an RSP1A...

[Roger David Powers]

> I guess I was confused then, because I thought that SDRUno could record I/Q data from an RSP1A...

I don't know anything about that software.  Is there an email list or some other way to connect with users of that software?

Regards,

RDP

[Dennis McGough]

I've spoken with one of the developers and it sounded like the way their software is architected, the I/Q data isn't being passed to the VRXs. It sounds like what is being selected is the audio decode bandwidth, not a slice of the I/Q data.

I'm not sure how it's formatted as it comes out of the source, which means I'm not sure how hard it would be to split the I/Q data itself on the fly. Is it even theoretically possible to take a single I/Q stream that is from 10.0 MHz to 20.0 MHz and split it into two streams - one that is 10.0 - 15.99 and another that is 16.0 - 20.0 MHz? Does the I/Q format lend itself to being 'stream-split' like that?

--
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 on the web visit https://groups.google.com/d/msgid/gqrx/1204226659.2249771.1632145876456%40mail.yahoo.com.

[Charlie Hotel]

Hi,

If you are only concerned by the amount of storage, you could easily stream the full band to a gnuradio flowchart and implement the band filtering there (using xlating fir filtre blocks Wilhem adequate decimation ) and store the N IQ streams using N gnuradio file sinks giving you N separate files (one per xlating-filter / ham band).
Cheers 

Bernard F1EVY

Le 20 sept. 2021 à 15:51, 'Roger David Powers' via Gqrx SDR <gq...@googlegroups.com> a écrit :



[Dennis M]

Thank you! This gives me a direction to head for experimentation. It'll be interesting to see the CPU / RAM requirements of such a setup. I'd love to do this with an RSP1A attached to a Pi4, writing over the network to an NFS file share.