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:marcus.muel...@ettus.com]
> *Sent:* Friday, March 31, 2017 8:01 AM
> *To:* Ellie White <orionnebul...@outlook.com>; discuss-gnuradio@gnu.org
> *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
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to