Re: [Discuss-gnuradio] Units of data saved by filesink

import pylab as plt
import os
import numpy as np

def main():

srate = 4000000.0
fftsize = 8192
infiler = 'counts-check.dat' #real samples
infilei = 'counts-checki.dat' #imag samples

rsize = os.path.getsize(infiler) / 4
rshape = (fftsize, rsize/fftsize)

isize = os.path.getsize(infilei) / 4
ishape = (fftsize, isize/fftsize)

x = np.memmap(infiler, dtype='float32', mode = 'r', shape=rshape)
y = np.memmap(infilei, dtype='float32', mode = 'r', shape=ishape)

sum_counts = 0
i = 0

for count1 in range(rsize/fftsize):
for count2 in range(fftsize):
sum_counts += (x[count2, count1])#/100.0
i += 1

avg = float(sum_counts) / float(i)
#conversion = 0.0196 / avg
print avg #conversion

freqPlotx = np.mean(x, axis=0)
freqPloty = np.mean(y, axis=0)

plotvals = []

for f in range(freqPlotx.size):
val = pow(freqPlotx[f],2) + pow(freqPloty[f],2)
plotvals.append(val)

#print freqPlot
'''fmin = (169010000-(srate/2))/1000000
fmax = (169010000+(srate/2))/1000000
fidx = np.linspace(fmin, fmax, freqPlot.size)'''

plt.plot(plotvals) #fidx, freqPlot
plt.show()

if __name__ == "__main__":
main()

Hi Marcus,

Thanks for the interesting tidbit -- and yes, I'll be following your advice on using the integrated block for sure. And by the way -- I've got one more question on a similar theme as the previous one. I modified my flowgraph again (attached), and am now saving two data streams -- real and imaginary -- to two separate data files and processing them using the attached python program. In the python program, I am performing the same conversion as the Complex to Mag^2 Block, but yet again I am getting different answers from what I expect (on the order of 10^-5 instead of ~0.01). Do you have any suggestions as to what could be causing the difference I am seeing? I am wondering if it has something to do with Python's handling of the different IO types, but could definitely be wrong on that. Any advice is much appreciated!

Thanks Marcus! Take care,

Ellie

On Sun, Jul 28, 2019 at 6:17 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

On 07/28/2019 06:14 PM, Ellie White wrote:

Hi Marcus --

Excellent! I tried this and am now getting identical results from the Complex to Mag^2 block as I am from my imitation of it. Thank you so much for your help! Much appreciated; nice to know I understand exactly what is going on inside that block now. 

Have a great evening! 

Ellie

In the very-early days of Gnu Radio, there wasn't a separate Complex-to-Mag2 block, so I would "imitate" it just like you are doing in your
  "understanding it" exercise.

I'd recommend using the integrated block for "production" because it's likely faster than stringing a bunch of blocks together to imitate it--
  it has, AFAIR, SIMD speedups built-in.

Cheers

On Sun, Jul 28, 2019 at 6:05 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

On 07/28/2019 05:45 PM, Ellie White wrote:

Hi Marcus,

Thanks for your reply. Actually, that's not what I was asking -- I do understand what the difference is between storing values corresponding to voltage vs. storing values corresponding to mag^2 -- I am just curious why the two different methods of obtaining the mag^2 values (using the Complex to Mag^2 block vs. using a collection of blocks intended to perform the same function in the counts-conversion flowgraph I sent you) produce different values. According to the documentation, the mag^2 value is calculated by taking: mag^2 = (real^2) + (imag^2), which I tried to reproduce using a Complex to Real block, then squaring and adding the real and imaginary outputs from that block to produce an output stream. 

If you look at the counts output by the Complex to Mag^2 block, this produces a different result from my pieced-together "equivalent" of the Complex to Mag^2 block I assembled using the Complex-to-Real block, Stream to Streams blocks, Multiply and Add blocks in the counts-conversion flowgraph in my last email (which I created to ensure I understand what is going on inside the Complex to Mag^2 block). My question is simply -- why are the outputs different? If I need to clarify anything about my question here I would be happy to. 

Thanks,

Ellie

Ah!  Now I see.


Your counts-conversion-test.grc is not *quite* what you think it is.

A stream-to-streams block takes a stream and turns it into two other streams at half the rate.

So, you're not actually computing power: = (Real*Real + Imag*Imag). It's more like you're computing:

(Real*Real[-1] + Imag*Imag[-1])

Just run them into a multiply block with two inputs, without stream splitting.  GR lets you do that.

On Sun, Jul 28, 2019 at 5:27 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

On 07/28/2019 04:55 PM, Ellie White wrote:

Hi Marcus L. and Marcus M., 

Thanks for the tips, really appreciate the advice / help from both of you. Marcus L., thanks so much for the practical calibration advice, that will come in handy. Marcus M., thanks also for your tips. Not sure what I was thinking with the "watts squared" thing -- duh! Also, to respond to a point in your previous email, I realize that WX GUI is deprecated, but as a result of the fact that my project requires I work on an old RedHat computer on National Radio Astronomy Observatory servers, according to the system administrator I am limited to working from GNU Radio version 3.7.11 -- which doesn't have all the QT GUI functionality I need. Thus the outdated WX GUI choice, and my inability to use the ZeroMQ blocks.

So, I've got another question for you all. I've reattached my original flowgraph (ettus-filesink.grc, modified slightly). I have been stepping through each stage and recording data samples (i.e., I first attached the lower channel from the De-Interleave block straight to a filesink, saved the file and read it out using a python program, such as the one attached, then connected the FFT block, saved the data, etc.). The point of this exercise being to determine how the counts (which are, presumably, proportional to voltage) change after each processing step. After the samples are run through the FFT block, the counts values are smaller than the input by about 1/fftsize (8192 in this case), which makes sense to me, but then, after the stream is passed through the Complex to Mag^2 block, the count values go from around 10^-9 to roughly 0.01 (the values are slightly different, but the order of magnitude is what I'm asking about here). Why is this the case? When I use a system as in counts-conversion-test.grc, the output is completely different (~10^-5) than that for Complex to Mag^2, even though to my understanding they should be doing the same thing, though maybe this is not the case. I would appreciate hearing any insights you all have to share about this.

Thanks very much for your time and help -- have a good evening!

Best,

Ellie

So, the RAW FFT output is giving you estimates of the spectral components essentially as complex *voltage* values, which is why you
  convert to *power* values by squaring (because of Ohms law).

I *THINK* what you're asking is about the difference between logging voltage values vs power values (via Complex-to-Mag2).

On Thu, Jul 25, 2019 at 1:36 PM Müller, Marcus (CEL) <mueller@kit.edu> wrote:

On Thu, 2019-07-25 at 13:24 -0400, Ellie White wrote:
> Hi Marcus,
>
> Good to know. So how would you recommend I should convert these values to, say, watts?

I described exactly that in my other email.

> (I guess perhaps it would be watts squared due to the mag to mag squared block).

No. Amplitudes are proportional to voltage, squared amplitudes to
power. Physics!

>  I assume I would first have to determine what the SDR considers full scale -- do you have any suggestions on how to do that?
>

Calibration with a known power source.

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

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