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 < address@hidden>
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 < address@hidden>
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) < address@hidden>
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|