Data Streams to the Operating System and to User Processes

[RichardKCollins]

Dear QuickSDR Developer Group:

This is my first time writing here, so I though I would introduce myself. I am a retired Senior Mathematical Statistician. My training is in gravitational physics, and I have a current project to calibrate and improve gravimeter networks world wide. I have gotten the superconducting gravimeters and seismometer networks in fairly good shape, and starting on the MEMS and atom interferometer-based gravimeter networks that are rapidly developing. The ADC communities on the Internet are very active, but not talking together, so I am taking a short diversion. The SDR community seems to be looking for low cost solutions with broad applicability. But with 40 years of experience with statistical method development, and over 50 years using computers, I think you all need to focus a little more and try to look out at the world to see where you can make a difference. :)

I was under the impression that QuickSDR could export raw data, either as buffers arriving at the sensor, or in IQ format. I want to write statistical signal processing tools, but I do not want to have to develop the data collection and data sharing framework (Sensors and Streams).

Can "save raw data to a file" be added? That should be a piece of cake.

Also, you could offer the FFT data stream to the operating system as data streams like you did with the sound card. For that matter, the "sound card" should not care if you send it 48000 samples per second stereo, or 2.56 Msps (mega samples per second) four channel {time, raw amplitude, I, Q} record streams.

I am sure everyone is busy and has their own lives and priorities. Can someone who knows the guts of QuickSDR add a "save raw to file" or forward raw or FFT coefficients or MaximumValues, or other intermediate data "as data streams" so they can be picked up by listeners and workers in the respective operating systems. Letting the sensor data streams pretend to be sound cards is OK, but I think there are efforts to improve handing of arbitrary datastreams from processes and sensors anywhere on the globe. I will check to see what Windows, Linux, Android are doing with datastream standards.

I am looking at Analog Devices RF ADC's. The low cost ones (under $100) are in this table http://www.analog.com/en/parametricsearch/10785#/p1746=1000000|3000000000&ps3=0.98|100

Their low end is next after the low cost dongles, and much less expensive and with more future than the on purpose built software radios. For general sensor use, not just RF listening, these general purpose ADC's are useful. I think QuickSDR could be improved for the current hardware, but might grow signicantly if it tackled these Gsps (giga sample per second) devices.

Sending the data to a file helps me with immediate investigations, but sending the full data to other processes will have the longer term benefit of exposing the data.

I use getUserMedia in Javascript in the browser to capture and process data streams from "sound cards" and "video sources". A webcam at 640x480x4x30 (4 bytes per pixel, 30 frames per second) is 368,64 Mbps (mega per second at 10 bits per byte error corrected). So a datastream at 2.56 or 10 or 100 MSps should be fine.

I have a Javascript compiler to more time sensitive problems, and it can compile to hardware description languages for FPGAs and special purpose devices if needed.

Sincere regards, Richard Collins, The Internet Foundation

[cjcliffe]

Hi @RichardKCollins -- Your usage sounds very interesting and I'm assuming you've found the right spot and just misplaced the name 'CubicSDR' with 'QuickSDR' as I can't find anything about the latter online :)

I'm not up to speed on your specific use case but I think there might be options..

• Issue #207 may eventually provide what you need; the hope is to allow you to configure I/O block devices on unix/linux systems which would let you choose them as outputs for any demodulated (or I/Q) output to a file / network destination of your choice.

• If you'd like a simple shell-based solution that's available now it might be worth looking into something like https://github.com/rxseger/rx_tools which provides I/Q input stream tools for SoapySDR supported devices

• Alternatively something like LuaRadio can be used to leverage the Lua language to create simple or complex interfaces, and also takes advantage of the same liquid-dsp DSP tools and SoapySDR interface that CubicSDR uses: https://github.com/vsergeev/luaradio

[RichardKCollins]

Charles,

A bit of time and a lot of research has come between. I did mix up the names; and, at that time, I did not know much about software defined radio. I was able to get the audio stream from CubicSDR and do some basic statistics. I understand better what people mean by IQ streams and how they are used.

I am most interested in the radio frequencies from DC to about 1 MHz. I thouht that I would be able quickly to use one of the SDR dongles, which are supposed to be collecting data at 2.56 million samples per second. That turned out to be very difficult. Not because it was hard to know what to do with the signals, but in getting any documentation on hardware and software. If I was going to invest time in studying signals and writing algorithms, I wanted to be able to share what I found with others.

I since have found that Analog Devices and Texas Instruments and others make 2 Msps (megasamples per second) 8, 16, 24, 32 bit ADCs, and it is only necessary to amplify the signals to fit their input requirements. That is yet another tedious documentation hurdle. And the devices get quite expensive in a number of respects.

They actually go into the Gsps (giga) range for various markets and applications. And they and others are inching toward terasamples per second. I am trying to design a time of flight gravimeter network to help some people with earthquake early warning, and I wanted to use it to measure the speed of gravity and some other basic calibrations. I think I waited too long. My health is failing so I might not be able to continue much longer. A nice piece of work. Just waited too late in life to complete it. I think I found detectors to operate at those sampling rates and someone to make them.

I am basically a mathematical statistician. I develop new methods of solving problems. I learned a lot of engineering and computers, but I just don’t have the patience or endurance to build hardware any more. And plowing through yet more byzantine software packages just gives me a bigger headache than I already have. I recognize what you suggested. I just can’t force my tired body to do it.

I did look at the lightning detection networks. They would be wise to move into the Gsps region, but they are more concerned with making money than sharing. That put me off more than anything. There are many new technologies bursting out all over. I will have to let the future generations do it. Forty years to figure it out and then die before when I see the promised land. God has a great sense of humor.

Thanks for your reply. Best wishes.

Richard Collins