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
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 ga
On Fri, Mar 16, 2007 at 06:29:42PM -0400, [EMAIL PROTECTED] 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
> consideration
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
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
On Fri, 16 Mar 2007, Michael Dickens wrote:
On Mar 16, 2007, at 12:01 PM, [EMAIL PROTECTED
On Fri, Mar 16, 2007 at 05:30:44PM -0400, [EMAIL PROTECTED] wrote:
> 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
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
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 eve
On Mar 16, 2007, at 12:01 PM, [EMAIL PROTECTED] 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"
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 kn
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
___
On Mar 15, 2007, at 5:15 PM, [EMAIL PROTECTED] wrote:
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 bu
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 reso
13 matches
Mail list logo
