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,

If you look at lines 34 and 39, I think you will see that I did consider the values for y. I've reattached the program here in case I originally attached an older / incorrect version. Let me know if you still see a problem. Thanks!

E.

On Mon, Jul 29, 2019 at 12:19 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

On 07/29/2019 08:22 AM, Ellie White wrote:
> 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
>
Looks like your python program isn't squaring the real and imaginary
components -- the values for "y" are never considered in your program :)