discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] File sink question


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] File sink question
Date: Sat, 1 Apr 2017 22:33:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

Hi Ellie,

absolutely was a pleasure, and not at all requiring any patience!

I don't know if I already did that, but maybe Michael Ossmann's DSP/SDR tutorials are something for you! You can find links to those and other resources on our wiki, https://wiki.gnuradio.org/index.php/SuggestedReading (shamelessly advertising our wiki here, hoping you contribute to it when you find something that you think you can explain well).

We don't really address these theoretical issues very much in those, but if you haven't, do check out our Guided Tutorials on http://tutorials.gnuradio.org/

And, most importantly: GNU Radio really exists only due to a lively community, so please don't stop asking questions, and if you find something you feel like answering, do answer :) I found I've learnt most I can apply today by trying to help others and myself understand questions that arise from usage, so this is definitely a mutually beneficial thing!

Best wishes!

Marcus


On 01.04.2017 21:33, Ellie White wrote:

Aha! It took me more than long enough to put two and two together… I had actually tried at first using the very same equation you described (if you remember I think I said something along those lines in my first email), but I did two things wrong. First, since I had been using such a high sample rate the SDR block probably defaulted to a different sample rate (based on a suggestion from Kyeong Su Shin in another thread), so I would have plugged the wrong sample rate into the equation. Second, I was just dividing the number of frequency domain vectors by the sample rate, instead of multiplying the number of vectors by 1024 and dividing that by the sampling rate. I corrected these issues and did a test, and it all works out perfectly now. Thank you very much for all your patience on this and for pointing me in the right direction!

 

Best wishes,

 

Ellie

 

 

From: Marcus Müller [mailto:address@hidden]
Sent: Saturday, April 1, 2017 11:04 AM
To: Ellie White <address@hidden>; address@hidden
Subject: Re: [Discuss-gnuradio] File sink question

 

No, f_sample is the sampling rate. Remember: every "frequency domain" 1024-vector you've stored corresponds to 1024 time samples (hence my longish explanation of what happens to samples). 1024 time-domain samples take exactly 1024 sampling periods T_sample to capture, and T = 1/f.

Best regards,

Marcus

 

On 01.04.2017 15:47, Ellie White wrote:

Hello Marcus –

 

Thank you for the very helpful suggestions and clarifications – that makes much more sense now!

 

I just want to double check on one last thing, regarding your statement that:

 

               t = N_samples / f_sample

 

I think you indicated that N_samples is the number of samples read from the file. I wanted to clarify what the value of f_sample is – is that the size of the FFT (in my case 1024)?  I apologize if I’m missing something obvious here.

 

Thanks again!

 

Ellie

 

From: Marcus Müller [mailto:address@hidden]
Sent: Friday, March 31, 2017 8:01 AM
To: Ellie White <address@hidden>; address@hidden
Subject: Re: [Discuss-gnuradio] File sink question

 

Hi Ellie,

 

On 31.03.2017 02:52, Ellie White wrote:

Thank you for the quick response. I guess I had been confused and had set the sampling rate far too high! I think the right sampling rate should be 2 MHz for the RTL-SDR dongle, based on what I’ve seen online – does that sound more appropriate to you?

Well, *you* are the one designing your signal processing application, so you tell me what's appropriate for your purpose. But yes, the SDR dongles can typically operate at such sampling rates.


 

Regarding the rest of my question, if I am understanding this correctly, the file sink stores data read in from the source (in my case, the SDR dongle) as a 2d array, containing frequency and time information.

No, not at all!
The file sink just stores data. Just as it comes. Every stream connection in GNU Radio really just transports numbers – and you're storing only these numbers, in raw binary format, and nothing more!


So, if I would run my flowgraph for some amount of time, I am accumulating time samples in the destination file via the file sink (each time sample containing 1024 values representing the power of each frequency channel produced by the FFT block) – is that correct? #

So, what your flow graph does is it takes 1024-element vectors of the complex input signal coming from your RTL-SDR (which then really are just 1024 complex values in memory, each of which is a float32 real, and a float32 imaginary part, directly after each other, in machine format), subjects them to an FFT, which does something "logically" to these vectors, but doesn't change the fact that they're still 1024-vectors of complexes, then subjects these to a transformation from complex values to magnitude squares, which changes them to 1024-vectors of floats, and then just writes them to a file.

That file will just contain floats. There's absolutely no indication of time or frequency in these – just numbers. The fact that they're 1024-vectors, of float32, with a special meaning, generated from a  signal with a specific sampling rate, is something that is not stored in the file. Again: the file really just contains the raw numbers, one after the other, with no dimensionality or annotations.


 

To clarify a bit further, my aim is to make a plot of power vs. time for one particular frequency channel using python. So I want to be able to tell how many seconds of data I am looking at, rather than how many time samples I am looking at.

But that's trivial, because t = N_samples / f_sample !!


I attached a plot to illustrate what I mean: right now, the x-axis is labeled based on time samples (I think),

Well, it's labeled with the index of the number numpy read.


and I would like to label it with the corresponding time stamp instead.

So, generate an index vector with numpy, for example

idx = numpy.linspace(0,len(samples_read_from_file)/f_sample, len(samples_read_from_file))
pyplot.plot(idx, samples_read_from_file)

No magic involved! :)


So the question is, how do I convert number of time samples into an indication of time intervals?

 

Hopefully this makes sense and isn’t too convoluted…let me know if I need to clarify anything further or provide any other information.

 

No, everything's fine so far. You're clearly entering the field of DSP in a very cool way, and I'd say: go for it!

Best regards,
Marcus

 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]