Forum: GNU Radio window sizing issue

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
7de99ba7a8144e8f34524dc0ca683bd7?d=identicon&s=25 unknown (Guest)
on 2007-03-15 22:15
(Received via mailing list)
Hi-

I've got an application with 3 plot windows and a control area in the
bottom.
Depending on the screen resolution, the control area on the bottom is
"covered"
by the lowest of the 3 plot windows.  The applicatoin works fine at
1600x1200
but less well at 1440x900, and certainly at lower resolutions the
control boxes
are getting covered.

What can I do so that even at lower resolutions I can see the entire
application?  I've tried adjusting the middle numeric field
(vbox.add(self.scope.win, 4, wx.EXPAND)) in the vbox.add entry from 4 to
0, which helps for 1440x900 but this doesn't work for all resolutions
and
I don't know what this value represents anyway.  Is there a
recommendation
for making my application resolution-independent?  I've attached the
python-code.  Any advice is appreciated!

thanks,
eric

************************************
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2007-03-16 03:23
(Received via mailing list)
On Mar 15, 2007, at 5:15 PM, ematlis@nd.edu wrote:
> resolutions and I don't know what this value represents anyway.  Is
> there a recommendation for making my application resolution-
> independent?  I've attached the python-code.  Any advice is
> appreciated!

I've been studying GUI design recently, and I can tell you that it's
not simple learning WX or wxPython as documentation really isn't very
good (IMHO).  Does folks have particular references (online tutorial,
book, PDF) that they really like?  I could use some pointers ... I've
seen those provided by the WX and wxPython projects, and Google'd
various others, but none really do justice to all the methods and
variables for even such "simple" things as a BoxSizer.

I think this is correct: The "0" or "4" you're referring to is a
"weight" of the particular added object.  The "weight" is taking into
account when the BoxSizer [0] determines how big an object should be;
"0" weight (I think) means to not consider this object in the sizing
but rather instead to just allocate its actual size (in pixels).
Tweaking this value helps only so much, as objects can get only so
small and screens only so large.  Each object has a property,
something like "minimum size"; some of these are straight forward to
set while others seem to be less so if not impossible.

In the case of the "fftsink" GUI, the default frame size is (X,Y) =
(640, 240), as found in gr-wxgui/src/python/fftsink.py , and you can
change this in the call to "fftsink.fft_sink_c" with "size=(50,50)"
or whatever you want.  Ditto for fftsink2.py.  Then you'll want to
change the "weight" in the "vbox.Add" call to 1 for each of these.

That for "scopesink" is also (640, 240) [gr-wxgui/src/python/
scopesink.py], except that this value doesn't actually get used for
anything (oops, bug alert).  The "scopesink" also has some extra GUI
stuff below it that doesn't seem to be set to EXPAND; nor is "size"
passed around to any of the classes that actually create the GUI
objects.  Thus some work needs to be done on the scopesink classes
stuff in order to get "size" to work.

Once the scopesink is corrected (as appended [1]), then you'll
probably want (in your am_rcv_plasma.py) to vbox.Add them with a
weight of 1, and everything else with a weight of 0.  At least for
me, this looks OK at down to around (X,Y) = (750,525) ... nothing
special that small, but it does work.

[0] The BoxSizer 'vbox' to which you refer is a means for placing
objects into a GUI with minimal user defined parameters; this
particular one is a "vertical box" only, which means that items are
added from the top of a window towards the bottom, in rows.  Each row
can have a different number of columns, each of which is generally a
BoxSizer in its own right (a "horizontal" one).

[1] I've appended updated files, with corrections for these issues.
Place them in the same directory before trying to execute your
"am_.." script since it now depends on the fftsink_mod script being
in that same directory.  I'll think about what should really be done
to scopesink to get it working properly, since this is just a quick
fix for an obvious problem but it's not "ideal" I don't believe.
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2007-03-16 15:08
(Received via mailing list)
In gr-wxgui/src/python/scopesink.py  (and ...2.py), is it a bug or
feature that the "size" isn't passed through to the actual objects
being created (like it is in fftsink.py)?  If a bug, I can fix it
quickly; if a feature, then can someone offer an explanation?
Thanks! - MLD
7de99ba7a8144e8f34524dc0ca683bd7?d=identicon&s=25 unknown (Guest)
on 2007-03-16 17:01
(Received via mailing list)
Michael-

thanks very much for your help!  Your changes have fixed the "control
buttons covered" issue.  I'll have to study what you did; I don't know
any
wxPython at all and as you've mentioned it's not easy to wade through
existing documentation.

Two other questions-

1) do you happen to know where the default values for the control
buttons
are set?  I'd like to change the time scale from 100us/div to 1ms/div
and
to set the Autorange to "on" by default.

2) do you know how to convert the integer values on the third window
(time-series) to actual voltage values as measured by the adc?  It must
be
a function of the internal gain and offset.  I need to know these
eventually; this application is supposed to measure physical voltages,
not
just produce sounds.

thanks again,
eric

************************************
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2007-03-16 17:43
(Received via mailing list)
On Mar 16, 2007, at 12:01 PM, ematlis@nd.edu wrote:
> 1) do you happen to know where the default values for the control
> buttons are set?  I'd like to change the time scale from 100us/div
> to 1ms/div and to set the Autorange to "on" by default.

In your "am_..." file, change the "scope_sink_f" call to inside
"_build_gui", "if plot3:":

             self.scope = scopesink.scope_sink_f(self, self.panel,
title="AM Demodulated Time Series", sample_rate=demod_rate, size=
(50,100), t_scale=1.0e-3, v_scale=None)

the last 2 items set the time scale and autorange as you want.

> 2) do you know how to convert the integer values on the third
> window (time-series) to actual voltage values as measured by the
> adc?  It must be a function of the internal gain and offset.  I
> need to know these eventually; this application is supposed to
> measure physical voltages, not just produce sounds.

Not sure of this.  Maybe whoever wrote the script knows? - MLD
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-03-16 22:13
(Received via mailing list)
On Fri, Mar 16, 2007 at 12:43:01PM -0400, Michael Dickens wrote:
>
> >2) do you know how to convert the integer values on the third
> >window (time-series) to actual voltage values as measured by the
> >adc?  It must be a function of the internal gain and offset.  I
> >need to know these eventually; this application is supposed to
> >measure physical voltages, not just produce sounds.
>
> Not sure of this.  Maybe whoever wrote the script knows? - MLD
>

You would need to calibrate the complete signal path.  Of course this
is highly dependent on the particular daugtherboard in use as well as
any gain setting in effect.

Eric
7de99ba7a8144e8f34524dc0ca683bd7?d=identicon&s=25 unknown (Guest)
on 2007-03-16 22:31
(Received via mailing list)
Thanks-

I'm using the DC-30 MHz basic RX board.  So by recording the input
signal,
recording the value displayed on my "time series" window, and knowing
the
gain (0-20db if memory serves) I can calibrate the hardware so that I
can
back out the original voltage levels at the input?  What impact does the
signal processing have on the absolute magnitudes?  If there is some
magnitude attenuation caused by the FIR filters, is it frequency
independent?

thanks,
eric
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-03-16 23:09
(Received via mailing list)
On Fri, Mar 16, 2007 at 05:30:44PM -0400, ematlis@nd.edu wrote:
> thanks,
> eric

Not to discourage you, but the USRP was designed as a software radio
peripheral, not a precision calibrated measurement device.

You will have to calibrate _everything_ in the path, and of course
that includes the signal processing in the FPGA as well as anything in
the host-based signal processing path.  And yes, pretty much all of
this varies depending on a large variety of settings.  E.g., you'd
want to calibrate for each possible FPGA decimation rate that you're
interested in.

Also, any calibration you make is going to be temperature dependent.

Eric
7de99ba7a8144e8f34524dc0ca683bd7?d=identicon&s=25 unknown (Guest)
on 2007-03-16 23:19
(Received via mailing list)
Thanks again!  That worked great.

As for who wrote the script, well, I adapted it (with much help from
people on the discussion list) from a pre-existing wfm-based script, if
I
recall correctly.

eric
7de99ba7a8144e8f34524dc0ca683bd7?d=identicon&s=25 unknown (Guest)
on 2007-03-16 23:30
(Received via mailing list)
Ok, I can accept that this device was not intended to be used as a
calibrated measurement device, but maybe I can give it a shot.  If I
keep
the decimation constant, and stabilize the temperature, what other
considerations do I need to take into account (other than the obvious
one,
ie gain) for the basic am-demodulation routine I am using?  Can I
consider
the FPGA as a "black box" and just calibrate the output vs the input at
the physical connector?

thanks,
eric
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-03-16 23:37
(Received via mailing list)
On Fri, Mar 16, 2007 at 06:29:42PM -0400, ematlis@nd.edu wrote:
> Ok, I can accept that this device was not intended to be used as a
> calibrated measurement device, but maybe I can give it a shot.  If I keep
> the decimation constant, and stabilize the temperature, what other
> considerations do I need to take into account (other than the obvious one,
> ie gain) for the basic am-demodulation routine I am using?  Can I consider
> the FPGA as a "black box" and just calibrate the output vs the input at
> the physical connector?
>
> thanks,
> eric

Yes, you should be able to make this work.

You'll want to apply a known stimulus at several frequencies and
amplitudes, measure what you get for each of those, then determine
your calibration coefficients.

If you haven't already, I suggest reading up on "two-point calibration".

Eric
7de99ba7a8144e8f34524dc0ca683bd7?d=identicon&s=25 unknown (Guest)
on 2007-03-19 17:40
(Received via mailing list)
Michael-

I'm trying to "calibrate" the flow-graph of the am_rcv_plasma_mod.py so
that the values displayed in the final window represent actual input
amplitudes.

The first step to do this would be to account for the internal gain; so
I
need to divide through by a factor of 10^(gain) where gain is in db.  To
implement this I define:

self.gain_correction = gr.divide_ff(math.log10(self.gain))

and later I implement it as follows:

self.connect (self.magblock, self.gain_correction)

and

         if plot3:
             self.scope = scopesink.scope_sink_f(self, self.panel,
title="AM Demodulated Time Series", sample_rate=demod_rate,
size=(50,100),
t_scale=1.0e-3, v_scale=None, vbox=vbox)
             self.connect(self.gain_correction, self.scope)


but I get the error:

File "am_rcv_plasma_mod.py", line 95, in __init__
     self.gain_correction = gr.divide_ff(math.log10(self.gain))
AttributeError: 'am_plasma_rx_graph' object has no attribute 'gain'

How do I "grab" whatever the current value of the gain is and use it to
divide through?  The gain will be set by either the mouse or the
powermate
device.

Any thoughts?
thanks,
eric

************************************
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2007-03-19 22:50
(Received via mailing list)
>
> You will have to calibrate _everything_ in the path, and of course
> that includes the signal processing in the FPGA as well as anything in
> the host-based signal processing path.  And yes, pretty much all of
> this varies depending on a large variety of settings.  E.g., you'd
> want to calibrate for each possible FPGA decimation rate that you're
> interested in.
>

As long as you stick to power of 2 decimation, you don't need to
calibrate for different settings.

Matt
This topic is locked and can not be replied to.