here's the right link to the gist file: https://gist.github.com/9nut/3195a2e68b412ca40927
On Fri, Oct 10, 2014 at 4:04 PM, Skip Tavakkolian < [email protected]> wrote: > 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 >>> >> >> >> >
