In general, you are right - you have to do *something* with all these data :) For example, after you got I/Q from receiver (2M smps/sec) you can do frequency shift, filtering, demodulate, then filtering demod'd data with decimating (your 45 smps into one output sample).
To be even more clear, mentioned .wav with I/Q data in this thread (which sdr# stores) is RAW I/Q data but just with wav header. This is NOT demodulated/audio data. It contains sample_rate=2000000 bytes/sec in header. On 11.10.2014 1:55, Skip Tavakkolian wrote: > i'm here to learn; it would be great if someone could clear up some confusion > for me: > > if i understand my i/q for dummies[1] correctly, rtlsdr's output is > 2,000,000/sec I/Q readings, each representing a single measurement of the > signal at (5E-7)th of a second (i.e. 1/2E6). i've understood the .wav file > to be a linear PCM sampling of audio at 44100 samples/second (one sample per > 1/44100 th of a second). if i did my math correctly you would have to do > *something* with around 45 I/Q samples to convert them to one .wav sample and > this assumes that I/Q represents sampling of an audio signal. is this right? > > [1] http://whiteboard.ping.se/SDR/IQ > > thanks, > -Skip > > On Fri, Oct 10, 2014 at 11:01 AM, Andreas Hornig > <[email protected] > <mailto:[email protected]>> wrote: > > Hi Peter, > > On Fri, Oct 10, 2014 at 7:03 AM, Peter Stuge <[email protected] > <mailto:[email protected]>> wrote: > > The samples are bytes in the file. It's a lot easier to operate on a > .raw file than to deal with a .wav, if you're just writing a small > program yourself. > > > For the .raw file, I couldn't find if there is a header or where the adc > bytes start. And we already started with .wav, because these were produced by > sdr# and we can already process the samples in .wav. And we can use numpy and > other standard features without building our own stuff. > > > Did you look at the sox man page? Maybe this works: > > sox -r 2000k -e unsigned -b 8 -c 2 input.raw output.wav > > > As said I can convert it, but I was unsure about the -e parameter. So if > it is unsigned, it is great to know this. The offset calculation is rather > easy to do. I just wanted to be sure not to change the inputs by accident by > selecting the wrong -e :). > > > > But I think you should send a patch to output .wav directly instead. > > > If you mean me to add this, I am sorry that it is out of my scope and I > would prefer someone else to add this nice feature :). > > So I will test what you all had said to me so far and I hope it will work > as intended. > > Best regards, > > > Andreas > >
