Re: [Discuss-gnuradio] Gnuradio 3.7.2 adn WX GUI Waterfall Sink with only blue screen output

[Ben Z en de rest]

Hi,
Found no way to solve the problem, after trying to make openGL working and
disabling as described in Tom's message so I did a clean Ubuntu 12,04
install, then run the wonderfull gnuradio installation script and now I
have a nicely working waterfall with Gnuradio 3.7.2

Now, before playing time starts I have to re-install some other software ;-)

Thanks,

Ben


2013/11/25 Tom Rondeau 

> On Mon, Nov 25, 2013 at 3:11 PM, Ben Z en de rest
>  wrote:
> > Just to update what I did to try and solve this problem (with no luck
> yet)
> >
> > I did read that the problem could be related to the need for Python
> OpenGL
> > support. I did install Python OpenGL (and OpenGL accelerator) from
> > http://pyopengl.sourceforge.net  but that gave me a "X windows system
> error"
> > on all Gnuradio examples that I tried.
> >
> > Had to remove Python OpenGL to solve that "X windows system error" but
> the
> > waterfall sink still only shows blue lines.
> >
> >
> > Then I had Synaptic install the Python OpenGL but with the same "X
> windows
> > system error" as result. So I had it removed and now I am back at my
> first
> > problem.
> >
> > Kind regards,
> >
> > Ben
>
> Ben,
> Yes, it's probably related to OpenGL issues. Sounds like your system
> doesn't like OpenGL much at all.
>
> Try disabling it in the WXGUI plots by editing
> $prefix/etc/gnuradio/conf.d/gr-wxgui.conf and changing "style = auto"
> to "style = nongl".
>
> Tom
>
>
>
> > 2013/11/24 Ben Z en de rest 
> >>
> >> Hi,
> >>
> >> Installed Gnuradio 3.7.2 from source. Had some troubles loading files
> from
> >> earlier versions so I started from scratch with the FM receiver from
> author
> >> 2h20. Added a bandpass filter to filter the 19 kHz pilot tone (just for
> fun)
> >> but want to add the waterfall sink to see / show 57 kHz RDS carrier
> (also
> >> for fun / getting experience).
> >>
> >> The waterfall sink only shows a blue screen. Tried different range
> >> settings, different ref scale settings and FFT sizes. Stole the settings
> >> from this example
> >> http://www.kj6msg.com/2013/09/gnu-radio-rtl-sdr-and-mac-os-x.html but
> still
> >> no output. The waterfall also shows no scale information or labels.
> >>
> >> Found another problem about this on the list where the question was what
> >> happened if a signal source was connected to the waterfall sink without
> >> anything else, I tried that also but even there only a blue screen is
> filled
> >> but no signal and no labels and so on are showed.
> >>
> >> The output window is here:
> >> http://www.pe2bz.nl/hamradio/uploads/images/Selectie_001.png
> >>
> >> Thanks for any advice,
> >>
> >>
> >> Ben
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gauging interest for an SDR PA

[Wayne Roberts]

The latest GaN devices seem impressive, many rated at DC to 4GHz.
But the reality is whether impedance matching circuit can reach 50MHz to
3GHz bandwidth.
The problem is power efficiency and thermal dissipation.
Especially when you combine boost DC supply, you're not going to have a
heat sink fitting into a cigarette pack size.
Best power efficient of RF device is at saturated power, but often SDR
signals have high peak-to-average power ratio, and must be backed off so
only the power peaks reach saturation.


Seems alot of these challenges are addressed with whats known as "class E"
or drain modulation / polar modulation.


On Tue, Nov 26, 2013 at 6:37 PM, Louis Brown  wrote:

> Given the availability of SDR hardware (USRPs, BladeRF, HackRF, etc)
> covering VHF through S/C bands, is there any interest in a wide band power
> amp to complement this hardware?  GaN seems to be ubiquitous now, and there
> are medium power, 48 VDC parts available in low cost SMT packages.  So I
> think it's feasible for something like:
>
> 50 MHz - 3 GHz bandwidth
> Class AB
> 5 - 30 VDC supply (high efficiency, high frequency boost supply)
> 10 dBm drive
> 37 dBm Psat
> Robust to full mismatch (open/short)
> Logic level enable
> ALC with VSWR monitoring (serial, I2C, etc)
> Small (cigarette pack or smaller)
> Low cost
> Open source
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] git support in gr_modtool

[Martin Braun (CEL)]

Hi,

the master branch has a new feature for modtool: git support.

If enabled, 'gr_modtool create' will automatically turn the newly
created directory into a git repository and add all the new files.

The modtool subcommands add, rm, disable and makexml can then update
the git index when operating.

To enable git support, either use the switch --scm-mode, which is
globally available for all subcommands, or add scm_mode=auto (or
scm_mode=yes) to the [modtool] section of your .gnuradio/config.conf.
The default behaviour is to *not* use git support.
Available options for scm_mode are: yes, no and auto. The latter
autodetects the presence of a repository and does nothing if no repo is
detected.

Note that 'commit' is not called by gr_modtool. This is because most of
the time, a git commit is not done after calling gr_modtool add.

Some background: gr_modtool actually calls the 'git' executable to do
this. Support for GitPython is there, but GitPython has proven a bit
shaky when mixed with the command line client, so it's currently
deactivated. There are safeguards to make sure that nothing happens if
no git is detected, but if someone finds some bug with with, please
contact me.

Finally, if there is real demand for other source control management
systems, that can be added quite easily. For now, only git is supported.

Enjoy!

Martin

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpMzCdE7IuKv.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] WX GUI Constellation sink plot freez ?

[Naceur]

Thank you for the reply :)



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/WX-GUI-Constellation-sink-plot-freez-tp44967p45017.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] trouble with gr_multiply_const_ff

[atools_cook]

Hi all,

I'm working on the gen2_reader project and got some trouble with the amp
block. We use the gr_multiply_const_ff to amplify the power of signal.

amp = gr.multiply_const_ff(amplitude)
tx = uhd.usrp_sink(options.args,uhd.io_type.COMPLEX_FLOAT32,
num_channels=1,)
self.connect(self.reader, amp, to_complex)
self.connect(to_complex, tx)

I found an threshold of amplitude, when amplitude < 40, the signal tx block
transmited looks like the amp20,png (that what we want) and when amplitude
>= 40, the signal is just the same to amp5000.png which get several peaks in
the signal we want to eliminate.

As the amplitude reflect the power of signal we transmit and need to be set
at least 5000 to power the tag, so we have to eliminate the peaks.

Is there some methods to deal with the amplitude, or just replace the
multiply_const_ff block with any other blocks?

Thanks for any advice

Lee

 

 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/trouble-with-gr-multiply-const-ff-tp45018.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] trouble with gr_multiply_const_ff

[Marcus Müller]

Hi Lee,
I don't quite understand what these images show, and they're too small 
to read the axes.

Could you elaborate on where you take them from? Is the input data the same?

Whitout guarantee, I'd assume that multiply_const_ff works quite well, 
and that the problem is somewhere else.

What does your to_complex do?

Greetings,
Marcus

On 29.11.2013 03:56, atools_cook wrote:

Hi all,

I'm working on the gen2_reader project and got some trouble with the amp
block. We use the gr_multiply_const_ff to amplify the power of signal.

amp = gr.multiply_const_ff(amplitude)
tx = uhd.usrp_sink(options.args,uhd.io_type.COMPLEX_FLOAT32,
num_channels=1,)
self.connect(self.reader, amp, to_complex)
self.connect(to_complex, tx)

I found an threshold of amplitude, when amplitude < 40, the signal tx block
transmited looks like the amp20,png (that what we want) and when amplitude

= 40, the signal is just the same to amp5000.png which get several peaks in

the signal we want to eliminate.

As the amplitude reflect the power of signal we transmit and need to be set
at least 5000 to power the tag, so we have to eliminate the peaks.

Is there some methods to deal with the amplitude, or just replace the
multiply_const_ff block with any other blocks?

Thanks for any advice

Lee







--
View this message in context: 
http://gnuradio.4.n7.nabble.com/trouble-with-gr-multiply-const-ff-tp45018.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio