cool! that's very informative. one possible solution to Andreas' problem might be to copy the raw samples from the sdr# .wav file to stdout -- which is then theoretically comparable to a .raw output. if so, here's a Go program that can be used:
https://gist.github.com/3195a2e68b412ca40927.git i just modified an example that comes with this WAV file handling package https://github.com/cryptix/wav -Skip On Fri, Oct 10, 2014 at 2:06 PM, psb hlw <[email protected]> wrote: > 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]> wrote: > >> Hi Peter, >> >> On Fri, Oct 10, 2014 at 7:03 AM, Peter Stuge <[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 >> > > >
