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 <patchvonbr...@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 <patchvonbr...@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 <patchvonbr...@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) <muel...@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 >>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >
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()
counts-conversion-test.grc
Description: application/gnuradio-grc
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
