[Discuss-gnuradio] 8.2 GHz Terra MODIS dish feed test using DBSRX
For the interested, Jerry Martes tested his ideas at the San Bernardino Microwave lab this weekend. We attempt at 8.2 GHz Terra MODIS polar orbiting satellite reception. It looks very promising. Got our proto rotor working last weekend. The USRP1 FFT plot show when injecting a -120 dBm signal into the DBSRX daughterboard. The signal is about 15 dB above the noise. The LNB is adjusted to use 1.4 GHz into the USRP. Shots at http://www.poes-weather.com/~patrik/8.2GHz/ Patrik___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 11.10
Il 17/10/2011 04:17, Tom Rondeau ha scritto: The maint, master, and next branches in git have all been fixed to work under Ubuntu 11.10 (new autotools and Qwt 6 were the main culprits). A bit more information can be found here: http://gnuradio.squarespace.com/home/2011/10/16/ubuntu-1110-troubles.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Do I need to install /swig/ or /swig2.0/ from the repos as dependencies to build from source ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] I hate Unity
http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I hate Unity
Install gnome-tweak-tools to get advanced settings for gnome to be able to get your favorite settings after you install gnome-shell. On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier wrote: > > http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ > > -- > Bob McGwier > Facebook: N4HYBob > ARS: N4HY > > > -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ben's docstring work
Ahhh much better. I added generation for a few of the components in core
(general, gengen, filter, io)
http://gnuradio.org/cgit/jblum.git/commit/?h=swig_docs&id=d65572359a74e97ee6a01d89dcc44fd77ce54fef
Basically, its pretty nice. The xml only regenerates when header files
change, and the swig docs.i only regenerate when the xml is changed, and
so on. No checked-in generated files. XML generation is very quick. Your
python script actually takes a bit longer (but im not complaining). :-)
I would like to get the grc docs parser looking for __doc__ strings soon.
A few comments on your doc generator. Im not sure we agree on a standard
here for documenting headers... but useful doc blocks may be in several
places in the header:
1) docs for the factor/make function
2) docs for class definition
3) docs just in the header, think \file
It looks like the generated docstrings only gets one of these. I suggest
concatenating all forms of docs into the one class docstring so the full
amount of docs is available at runtime to python.
-Josh
>
> It was the position of the %include "swig_doc.i" in the digital_swig.i file.
> It needs to be at the top rather than at the bottom.
> Here's a diff.
>
> diff --git a/gr-digital/swig/digital_swig.i b/gr-digital/swig/digital_swig.i
> index c804b5c..f6372b1 100644
> --- a/gr-digital/swig/digital_swig.i
> +++ b/gr-digital/swig/digital_swig.i
> @@ -23,6 +23,8 @@
>
> %include
>
> +%include "swig_doc.i"
> +
> %{
> #include "digital_binary_slicer_fb.h"
> #include "digital_clock_recovery_mm_cc.h"
> @@ -59,8 +61,6 @@
> %include "digital_cpmmod_bc.i"
> %include "digital_gmskmod_bc.i"
>
> -%include "swig_doc.i"
> -
> #if SWIGGUILE
> %scheme %{
> (load-extension-global "libguile-gnuradio-digital_swig"
> "scm_init_gnuradio_digital_swig_module")
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 11.10
On Mon, Oct 17, 2011 at 8:05 AM, Arturo Rinaldi wrote: > Il 17/10/2011 04:17, Tom Rondeau ha scritto: > > The maint, master, and next branches in git have all been fixed to work > under Ubuntu 11.10 (new autotools and Qwt 6 were the main culprits). A bit > more information can be found here: > http://gnuradio.squarespace.com/home/2011/10/16/ubuntu-1110-troubles.html > > Tom > > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > Do I need to install *swig* or *swig2.0* from the repos as dependencies > to build from source ? > > Regards, Arturo > You want the "swig" package, which looks like it is version 1.3.40. You do NOT want swig2.0 (although hopefully they can coincide). We have not made the change to 2.0 and don't plan to in the near future. It looks like it will be a good move when we do, but I would like to basically build a lot of things from the ground up as opposed to trying to patch what we have into working with 2.0 since a lot of hacks we have in our system look like they have been officially fixed/supported in the new version. The move to using 2.0 will be a pretty big announcement when it happens, but it won't likely happen until we're either forced to do it or all of our supported OSes support it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I hate Unity
On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier wrote: > Install gnome-tweak-tools to get advanced settings for gnome to be able to > get your favorite settings after you install gnome-shell. > > > On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier wrote: > >> >> http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ >> >> -- >> Bob McGwier >> Facebook: N4HYBob >> ARS: N4HY >> > Or do what I did: apt-get install gnome-session-fallback and switch to Gnome Classic Mode at the login screen. Removes Unity. I haven't heard anyone say a good thing about Unity. It's an awful environment to develop under. The first thing I do in Ubuntu now is stop using it. I'm now shopping around for another Linux distro if they keep going this way. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] build-gnuradio under Ubuntu 11.10
Could somebody try build-gnuradio under Ubuntu 11.10 and give me feedback about work/not-work. There's currently a pre-reqs paragraph for "11.*", which may or may not work under 11.10. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ben's docstring work
On Mon, Oct 17, 2011 at 12:36 PM, Josh Blum wrote:
> Ahhh much better. I added generation for a few of the components in core
> (general, gengen, filter, io)
>
> http://gnuradio.org/cgit/jblum.git/commit/?h=swig_docs&id=d65572359a74e97ee6a01d89dcc44fd77ce54fef
>
> Basically, its pretty nice. The xml only regenerates when header files
> change, and the swig docs.i only regenerate when the xml is changed, and
> so on. No checked-in generated files. XML generation is very quick. Your
> python script actually takes a bit longer (but im not complaining). :-)
>
That's great, Josh, thanks! I'll look at it soon, but sounds like a good,
sane way of doing this.
One question: what if the user's don't have doxygen installed? Right now
it's only an optional dependency. My guess is that it's not too hard to turn
this on or off depending on if you have doxygen. I just want to make sure
this is handled.
Since we're all hoping that we get to move to cmake completely, I'm going to
abandon any work on getting this to work in autotools.
> I would like to get the grc docs parser looking for __doc__ strings soon.
>
> A few comments on your doc generator. Im not sure we agree on a standard
> here for documenting headers... but useful doc blocks may be in several
> places in the header:
>
> 1) docs for the factor/make function
> 2) docs for class definition
> 3) docs just in the header, think \file
>
> It looks like the generated docstrings only gets one of these. I suggest
> concatenating all forms of docs into the one class docstring so the full
> amount of docs is available at runtime to python.
>
> -Josh
I agree. It would be nice to have all the documentation for every function,
not just the class docs.
Thanks!
Tom
> >
> > It was the position of the %include "swig_doc.i" in the digital_swig.i
> file.
> > It needs to be at the top rather than at the bottom.
> > Here's a diff.
> >
> > diff --git a/gr-digital/swig/digital_swig.i
> b/gr-digital/swig/digital_swig.i
> > index c804b5c..f6372b1 100644
> > --- a/gr-digital/swig/digital_swig.i
> > +++ b/gr-digital/swig/digital_swig.i
> > @@ -23,6 +23,8 @@
> >
> > %include
> >
> > +%include "swig_doc.i"
> > +
> > %{
> > #include "digital_binary_slicer_fb.h"
> > #include "digital_clock_recovery_mm_cc.h"
> > @@ -59,8 +61,6 @@
> > %include "digital_cpmmod_bc.i"
> > %include "digital_gmskmod_bc.i"
> >
> > -%include "swig_doc.i"
> > -
> > #if SWIGGUILE
> > %scheme %{
> > (load-extension-global "libguile-gnuradio-digital_swig"
> > "scm_init_gnuradio_digital_swig_module")
>
> ___
> 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] I hate Unity
On Mon, Oct 17, 2011 at 7:28 PM, Tom Rondeau wrote: > On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier > wrote: >> >> Install gnome-tweak-tools to get advanced settings for gnome to be able to >> get your favorite settings after you install gnome-shell. >> >> On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier >> wrote: >>> >>> >>> http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ >>> >>> -- >>> Bob McGwier >>> Facebook: N4HYBob >>> ARS: N4HY > > Or do what I did: apt-get install gnome-session-fallback and switch to Gnome > Classic Mode at the login screen. Removes Unity. > I haven't heard anyone say a good thing about Unity. It's an awful > environment to develop under. The first thing I do in Ubuntu now is stop > using it. > I'm now shopping around for another Linux distro if they keep going this > way. > Tom On Ubuntu 11.04 I have installed Xfce desktop ( http://www.xfce.org/ ) - it is available via the package manager (or by installing xubuntu instead of regular ubuntu). It is similar to Gnome 2 and is very lightweight. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I hate Unity
Just a couple of lines to cast my ballot in favor of Bob's complaint. I had the same reaction in response to Fedora 15 reception of the Gnome3 thing. That stuff does move too far away from the power-user-desktop concept I've been enjoying for several years as a developer. Also I'm a bit frustrated to have to go after that load of "tweaks" in order to get a freshly installed system usable. my best regards to everybody there vince 2011/10/17 Alexandru Csete > On Mon, Oct 17, 2011 at 7:28 PM, Tom Rondeau > wrote: > > On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier > > wrote: > >> > >> Install gnome-tweak-tools to get advanced settings for gnome to be able > to > >> get your favorite settings after you install gnome-shell. > >> > >> On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier > >> wrote: > >>> > >>> > >>> > http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ > >>> > >>> -- > >>> Bob McGwier > >>> Facebook: N4HYBob > >>> ARS: N4HY > > > > Or do what I did: apt-get install gnome-session-fallback and switch to > Gnome > > Classic Mode at the login screen. Removes Unity. > > I haven't heard anyone say a good thing about Unity. It's an awful > > environment to develop under. The first thing I do in Ubuntu now is stop > > using it. > > I'm now shopping around for another Linux distro if they keep going this > > way. > > Tom > > On Ubuntu 11.04 I have installed Xfce desktop ( http://www.xfce.org/ ) > - it is available via the package manager (or by installing xubuntu > instead of regular ubuntu). It is similar to Gnome 2 and is very > lightweight. > > Alex > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ben's docstring work
On 10/17/2011 10:46 AM, Tom Rondeau wrote:
> On Mon, Oct 17, 2011 at 12:36 PM, Josh Blum wrote:
>
>> Ahhh much better. I added generation for a few of the components in core
>> (general, gengen, filter, io)
>>
>> http://gnuradio.org/cgit/jblum.git/commit/?h=swig_docs&id=d65572359a74e97ee6a01d89dcc44fd77ce54fef
>>
>> Basically, its pretty nice. The xml only regenerates when header files
>> change, and the swig docs.i only regenerate when the xml is changed, and
>> so on. No checked-in generated files. XML generation is very quick. Your
>> python script actually takes a bit longer (but im not complaining). :-)
>>
>
> That's great, Josh, thanks! I'll look at it soon, but sounds like a good,
> sane way of doing this.
>
> One question: what if the user's don't have doxygen installed? Right now
> it's only an optional dependency. My guess is that it's not too hard to turn
> this on or off depending on if you have doxygen. I just want to make sure
> this is handled.
>
Right now its generating an empty swig docs file if doxygen was not
found. In other words, everything will still build.
Also, as long as cmake can find the doxygen executable, it will perform
the generation. The way to turn this off right now is to tell cmake that
the doxygen executable is undefined/not-found. I would like to add a
more official option: either it gets its own option, or its part of the
existing ENABLE_DOXYGEN option.
Now having said that, the time taken to compile the swig generated cc
file >> than the time taken to generate the docs. So its really just
fine to always build the docs as far as I am concerned.
> Since we're all hoping that we get to move to cmake completely, I'm going to
> abandon any work on getting this to work in autotools.
>
If we want to keep autotools working along-side cmake w/ this doc work,
autotools would need to generate an empty swig_docs.i file to keep the
compile happy.
-josh
>
>> I would like to get the grc docs parser looking for __doc__ strings soon.
>>
>> A few comments on your doc generator. Im not sure we agree on a standard
>> here for documenting headers... but useful doc blocks may be in several
>> places in the header:
>>
>> 1) docs for the factor/make function
>> 2) docs for class definition
>> 3) docs just in the header, think \file
>>
>> It looks like the generated docstrings only gets one of these. I suggest
>> concatenating all forms of docs into the one class docstring so the full
>> amount of docs is available at runtime to python.
>>
>> -Josh
>
>
> I agree. It would be nice to have all the documentation for every function,
> not just the class docs.
>
> Thanks!
> Tom
>
>
>
>>>
>>> It was the position of the %include "swig_doc.i" in the digital_swig.i
>> file.
>>> It needs to be at the top rather than at the bottom.
>>> Here's a diff.
>>>
>>> diff --git a/gr-digital/swig/digital_swig.i
>> b/gr-digital/swig/digital_swig.i
>>> index c804b5c..f6372b1 100644
>>> --- a/gr-digital/swig/digital_swig.i
>>> +++ b/gr-digital/swig/digital_swig.i
>>> @@ -23,6 +23,8 @@
>>>
>>> %include
>>>
>>> +%include "swig_doc.i"
>>> +
>>> %{
>>> #include "digital_binary_slicer_fb.h"
>>> #include "digital_clock_recovery_mm_cc.h"
>>> @@ -59,8 +61,6 @@
>>> %include "digital_cpmmod_bc.i"
>>> %include "digital_gmskmod_bc.i"
>>>
>>> -%include "swig_doc.i"
>>> -
>>> #if SWIGGUILE
>>> %scheme %{
>>> (load-extension-global "libguile-gnuradio-digital_swig"
>>> "scm_init_gnuradio_digital_swig_module")
>>
>> ___
>> 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] Ben's docstring work
On Mon, Oct 17, 2011 at 11:31 AM, Josh Blum wrote:
>
>
> On 10/17/2011 10:46 AM, Tom Rondeau wrote:
> > On Mon, Oct 17, 2011 at 12:36 PM, Josh Blum wrote:
> >
> >> Ahhh much better. I added generation for a few of the components in core
> >> (general, gengen, filter, io)
> >>
> >>
> http://gnuradio.org/cgit/jblum.git/commit/?h=swig_docs&id=d65572359a74e97ee6a01d89dcc44fd77ce54fef
> >>
> >> Basically, its pretty nice. The xml only regenerates when header files
> >> change, and the swig docs.i only regenerate when the xml is changed, and
> >> so on. No checked-in generated files. XML generation is very quick. Your
> >> python script actually takes a bit longer (but im not complaining). :-)
> >>
> >
> > That's great, Josh, thanks! I'll look at it soon, but sounds like a good,
> > sane way of doing this.
> >
> > One question: what if the user's don't have doxygen installed? Right now
> > it's only an optional dependency. My guess is that it's not too hard to
> turn
> > this on or off depending on if you have doxygen. I just want to make sure
> > this is handled.
> >
>
> Right now its generating an empty swig docs file if doxygen was not
> found. In other words, everything will still build.
>
Perfect!
> Also, as long as cmake can find the doxygen executable, it will perform
> the generation. The way to turn this off right now is to tell cmake that
> the doxygen executable is undefined/not-found. I would like to add a
> more official option: either it gets its own option, or its part of the
> existing ENABLE_DOXYGEN option.
>
I think we just wrap it into the ENABLE_DOXYGEN that's also contingent on
Python being enabled. Doesn't really make sense to build the docs and the
Python swig and not put the two together now that we can do it.
> Now having said that, the time taken to compile the swig generated cc
> file >> than the time taken to generate the docs. So its really just
> fine to always build the docs as far as I am concerned.
Yeah, sounds fine to me, too.
> > Since we're all hoping that we get to move to cmake completely, I'm
> going to
> > abandon any work on getting this to work in autotools.
> >
>
> If we want to keep autotools working along-side cmake w/ this doc work,
> autotools would need to generate an empty swig_docs.i file to keep the
> compile happy.
>
> -josh
That's easily done. A tad bit hackish, but if we end up keeping the
autotools stuff, I can go in and do it right. This is just to keep us going
in parallel until we can move over to cmake completely.
Thanks,
Tom
>
> >> I would like to get the grc docs parser looking for __doc__ strings
> soon.
> >>
> >> A few comments on your doc generator. Im not sure we agree on a standard
> >> here for documenting headers... but useful doc blocks may be in several
> >> places in the header:
> >>
> >> 1) docs for the factor/make function
> >> 2) docs for class definition
> >> 3) docs just in the header, think \file
> >>
> >> It looks like the generated docstrings only gets one of these. I suggest
> >> concatenating all forms of docs into the one class docstring so the full
> >> amount of docs is available at runtime to python.
> >>
> >> -Josh
> >
> >
> > I agree. It would be nice to have all the documentation for every
> function,
> > not just the class docs.
> >
> > Thanks!
> > Tom
> >
> >
> >
> >>>
> >>> It was the position of the %include "swig_doc.i" in the digital_swig.i
> >> file.
> >>> It needs to be at the top rather than at the bottom.
> >>> Here's a diff.
> >>>
> >>> diff --git a/gr-digital/swig/digital_swig.i
> >> b/gr-digital/swig/digital_swig.i
> >>> index c804b5c..f6372b1 100644
> >>> --- a/gr-digital/swig/digital_swig.i
> >>> +++ b/gr-digital/swig/digital_swig.i
> >>> @@ -23,6 +23,8 @@
> >>>
> >>> %include
> >>>
> >>> +%include "swig_doc.i"
> >>> +
> >>> %{
> >>> #include "digital_binary_slicer_fb.h"
> >>> #include "digital_clock_recovery_mm_cc.h"
> >>> @@ -59,8 +61,6 @@
> >>> %include "digital_cpmmod_bc.i"
> >>> %include "digital_gmskmod_bc.i"
> >>>
> >>> -%include "swig_doc.i"
> >>> -
> >>> #if SWIGGUILE
> >>> %scheme %{
> >>> (load-extension-global "libguile-gnuradio-digital_swig"
> >>> "scm_init_gnuradio_digital_swig_module")
> >>
> >> ___
> >> 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] GrBlock
On 10/17/2011 12:34 PM, Jason Bonior wrote: > Today we installed the git versions of grblock, grc, gnuradio, and uhd on a > system with Debian 6.0.3, 64-bit (also installed this morning). When trying > to run the demo files we receive the following errors: > > local@ch400l-laptop:~$ /usr/local/share/grblock/ > examples/adder_demo.py > handler caught exception: Unknown exception > Traceback (most recent call last): > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line 52, > in handle >try: self._callback() > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line 120, > in __grblock_handle >[self.__message.work_args.ninput_items]*len(self.__in_sig), > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line 41, > in pointers_to_ndarrays >return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes, nitems)] > File > "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py", > line 118, in next >return _gnuradio_core_hier.SwigPyIterator_next(self) > RuntimeError: Unknown exception > thread[thread-per-block[2]: ]: caught unrecognized > exception > ^Cexcepted (1, 5, 9, 13, 17) > actual () > handler caught exception: Unknown exception > Traceback (most recent call last): > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line 52, > in handle >try: self._callback() > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line 120, > in __grblock_handle >[self.__message.work_args.ninput_items]*len(self.__in_sig), > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line 41, > in pointers_to_ndarrays >return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes, nitems)] > File > "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py", > line 118, in next >return _gnuradio_core_hier.SwigPyIterator_next(self) > RuntimeError: Unknown exception > thread[thread-per-block[2]: ]: caught unrecognized > exception > ^Cexcepted (1, 5j, 9, 13j, 17) > actual () > local@ch400l-laptop:~$ > The traceback is a bit unclear. I think the problem is happening in pointer_to_ndarray. Can you put some prints in gateway.py and find out what line is dying? pointer_to_ndarray is the darkest magic used in grblock. Perhaps something differers between numpy versions. I have only tested on ubuntu 11.04 and 11.10 https://github.com/guruofquality/grblock/blob/master/python/gateway.py#L24 grblock certainly needs to be tested across wider audience. I am glad you are giving it a try. I am ccing gr discuss. More eyes and testers cant hurt. So if someone is bored or has 5 mins, can you compile this on your system and let me know if the examples work for you? https://github.com/guruofquality/grblock _josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GrBlock
On Mon, Oct 17, 2011 at 12:54 PM, Josh Blum wrote: > > > On 10/17/2011 12:34 PM, Jason Bonior wrote: > > Today we installed the git versions of grblock, grc, gnuradio, and uhd on > a > > system with Debian 6.0.3, 64-bit (also installed this morning). When > trying > > to run the demo files we receive the following errors: > > > > local@ch400l-laptop:~$ /usr/local/share/grblock/ > > examples/adder_demo.py > > handler caught exception: Unknown exception > > Traceback (most recent call last): > > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line > 52, > > in handle > >try: self._callback() > > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line > 120, > > in __grblock_handle > >[self.__message.work_args.ninput_items]*len(self.__in_sig), > > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line > 41, > > in pointers_to_ndarrays > >return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes, > nitems)] > > File > > > "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py", > > line 118, in next > >return _gnuradio_core_hier.SwigPyIterator_next(self) > > RuntimeError: Unknown exception > > thread[thread-per-block[2]: ]: caught > unrecognized > > exception > > ^Cexcepted (1, 5, 9, 13, 17) > > actual () > > handler caught exception: Unknown exception > > Traceback (most recent call last): > > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line > 52, > > in handle > >try: self._callback() > > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line > 120, > > in __grblock_handle > >[self.__message.work_args.ninput_items]*len(self.__in_sig), > > File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line > 41, > > in pointers_to_ndarrays > >return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes, > nitems)] > > File > > > "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py", > > line 118, in next > >return _gnuradio_core_hier.SwigPyIterator_next(self) > > RuntimeError: Unknown exception > > thread[thread-per-block[2]: ]: caught > unrecognized > > exception > > ^Cexcepted (1, 5j, 9, 13j, 17) > > actual () > > local@ch400l-laptop:~$ > > > > The traceback is a bit unclear. I think the problem is happening in > pointer_to_ndarray. Can you put some prints in gateway.py and find out > what line is dying? > > pointer_to_ndarray is the darkest magic used in grblock. Perhaps > something differers between numpy versions. I have only tested on ubuntu > 11.04 and 11.10 > https://github.com/guruofquality/grblock/blob/master/python/gateway.py#L24 > > grblock certainly needs to be tested across wider audience. I am glad > you are giving it a try. I am ccing gr discuss. More eyes and testers > cant hurt. > > So if someone is bored or has 5 mins, can you compile this on your > system and let me know if the examples work for you? > https://github.com/guruofquality/grblock > > _josh > We don't normally pass numpy arrays through Swig to GNU Radio, which could be your problem. Try passing it as you_ndarray.tolist() and see if that works. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GrBlock
On 10/17/2011 01:01 PM, Tom Rondeau wrote: > On Mon, Oct 17, 2011 at 12:54 PM, Josh Blum wrote: > >> >> >> On 10/17/2011 12:34 PM, Jason Bonior wrote: >>> Today we installed the git versions of grblock, grc, gnuradio, and uhd on >> a >>> system with Debian 6.0.3, 64-bit (also installed this morning). When >> trying >>> to run the demo files we receive the following errors: >>> >>> local@ch400l-laptop:~$ /usr/local/share/grblock/ >>> examples/adder_demo.py >>> handler caught exception: Unknown exception >>> Traceback (most recent call last): >>> File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line >> 52, >>> in handle >>>try: self._callback() >>> File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line >> 120, >>> in __grblock_handle >>>[self.__message.work_args.ninput_items]*len(self.__in_sig), >>> File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line >> 41, >>> in pointers_to_ndarrays >>>return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes, >> nitems)] >>> File >>> >> "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py", >>> line 118, in next >>>return _gnuradio_core_hier.SwigPyIterator_next(self) >>> RuntimeError: Unknown exception >>> thread[thread-per-block[2]: ]: caught >> unrecognized >>> exception >>> ^Cexcepted (1, 5, 9, 13, 17) >>> actual () >>> handler caught exception: Unknown exception >>> Traceback (most recent call last): >>> File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line >> 52, >>> in handle >>>try: self._callback() >>> File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line >> 120, >>> in __grblock_handle >>>[self.__message.work_args.ninput_items]*len(self.__in_sig), >>> File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line >> 41, >>> in pointers_to_ndarrays >>>return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes, >> nitems)] >>> File >>> >> "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py", >>> line 118, in next >>>return _gnuradio_core_hier.SwigPyIterator_next(self) >>> RuntimeError: Unknown exception >>> thread[thread-per-block[2]: ]: caught >> unrecognized >>> exception >>> ^Cexcepted (1, 5j, 9, 13j, 17) >>> actual () >>> local@ch400l-laptop:~$ >>> >> >> The traceback is a bit unclear. I think the problem is happening in >> pointer_to_ndarray. Can you put some prints in gateway.py and find out >> what line is dying? >> >> pointer_to_ndarray is the darkest magic used in grblock. Perhaps >> something differers between numpy versions. I have only tested on ubuntu >> 11.04 and 11.10 >> https://github.com/guruofquality/grblock/blob/master/python/gateway.py#L24 >> >> grblock certainly needs to be tested across wider audience. I am glad >> you are giving it a try. I am ccing gr discuss. More eyes and testers >> cant hurt. >> >> So if someone is bored or has 5 mins, can you compile this on your >> system and let me know if the examples work for you? >> https://github.com/guruofquality/grblock >> >> _josh >> > > > We don't normally pass numpy arrays through Swig to GNU Radio, which could > be your problem. Try passing it as you_ndarray.tolist() and see if that > works. > So, its actually only passing an integer (representing a memory address) into python. The routine described above is using numpy's array interface to turn that address into a numpy array. https://github.com/guruofquality/grblock/blob/master/python/gateway.py#L24 http://docs.scipy.org/doc/numpy/reference/arrays.interface.html -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I hate Unity
N.B.: What follows is obviously all opinion: I can't stand Unity, and the default settings for Gnome 3 drove me nuts. If you are willing to put the effort in, you can install a bunch of extensions that will make it at least approach the usability of Gnome 2. I recommend: http://intgat.tigress.co.uk/rmy/extensions/gnome32.html http://www.webupd8.org/2011/10/official-gnome-shell-extensions.html After installing, restart Gnome, and then use the 'Advanced Settings' menu (which is actually a shortcut to the tool Bob mentioned, gnome-tweak-tool) to enable the extensions you want. I was able to almost achieve what I had in Gnome 2 by doing this - although there are still some annoyances. I really don't understand why Gnome3 took this giant step backwards, and Canonical took Ubuntu even further backwards with Unity. Cheers, Ben On Mon, Oct 17, 2011 at 11:10 AM, Vincenzo Pellegrini wrote: > Just a couple of lines to cast my ballot in favor of Bob's complaint. > > I had the same reaction in response to Fedora 15 reception of the Gnome3 > thing. > That stuff does move too far away from the power-user-desktop concept I've > been enjoying for several years as a developer. > > Also I'm a bit frustrated to have to go after that load of "tweaks" in > order to get a freshly installed system usable. > > my best regards to everybody there > > vince > > > 2011/10/17 Alexandru Csete > >> On Mon, Oct 17, 2011 at 7:28 PM, Tom Rondeau >> wrote: >> > On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier >> > wrote: >> >> >> >> Install gnome-tweak-tools to get advanced settings for gnome to be able >> to >> >> get your favorite settings after you install gnome-shell. >> >> >> >> On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier >> >> wrote: >> >>> >> >>> >> >>> >> http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ >> >>> >> >>> -- >> >>> Bob McGwier >> >>> Facebook: N4HYBob >> >>> ARS: N4HY >> > >> > Or do what I did: apt-get install gnome-session-fallback and switch to >> Gnome >> > Classic Mode at the login screen. Removes Unity. >> > I haven't heard anyone say a good thing about Unity. It's an awful >> > environment to develop under. The first thing I do in Ubuntu now is stop >> > using it. >> > I'm now shopping around for another Linux distro if they keep going this >> > way. >> > Tom >> >> On Ubuntu 11.04 I have installed Xfce desktop ( http://www.xfce.org/ ) >> - it is available via the package manager (or by installing xubuntu >> instead of regular ubuntu). It is similar to Gnome 2 and is very >> lightweight. >> >> Alex >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > -- > Vincenzo Pellegrini > http://www.youtube.com/user/wwvince1 > > ___ > 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] Ben's docstring work
I've made a few changes to doxyxml so that the DoxyFile objects should
be exposing their descriptions and have changed swig_doc.py so that
it's grabbing documentation from the file if it is present. It
doesn't appear to be picking any file descriptions up and I'm not sure
if that's because it's not working or because there aren't any. If
you know of some good blocks to test it on let me know.
commit is
https://github.com/benreynwar/gnuradio/commit/d6e36498174dcb20f92369cc6097514a5d102ded
At the moment the layout for a docstring for a python creator function:
"""
brief description from class
detailed description from class
brief description from make func
detailed description from make func
brief description from file
detailed description from file
Params: (list of input parameters)
"""
The docstring for the class itself is the same without the parameter
list at the end.
Cheers,
Ben
On Mon, Oct 17, 2011 at 9:36 AM, Josh Blum wrote:
> Ahhh much better. I added generation for a few of the components in core
> (general, gengen, filter, io)
> http://gnuradio.org/cgit/jblum.git/commit/?h=swig_docs&id=d65572359a74e97ee6a01d89dcc44fd77ce54fef
>
> Basically, its pretty nice. The xml only regenerates when header files
> change, and the swig docs.i only regenerate when the xml is changed, and
> so on. No checked-in generated files. XML generation is very quick. Your
> python script actually takes a bit longer (but im not complaining). :-)
>
> I would like to get the grc docs parser looking for __doc__ strings soon.
>
> A few comments on your doc generator. Im not sure we agree on a standard
> here for documenting headers... but useful doc blocks may be in several
> places in the header:
>
> 1) docs for the factor/make function
> 2) docs for class definition
> 3) docs just in the header, think \file
>
> It looks like the generated docstrings only gets one of these. I suggest
> concatenating all forms of docs into the one class docstring so the full
> amount of docs is available at runtime to python.
>
> -Josh
>
>>
>> It was the position of the %include "swig_doc.i" in the digital_swig.i file.
>> It needs to be at the top rather than at the bottom.
>> Here's a diff.
>>
>> diff --git a/gr-digital/swig/digital_swig.i b/gr-digital/swig/digital_swig.i
>> index c804b5c..f6372b1 100644
>> --- a/gr-digital/swig/digital_swig.i
>> +++ b/gr-digital/swig/digital_swig.i
>> @@ -23,6 +23,8 @@
>>
>> %include
>>
>> +%include "swig_doc.i"
>> +
>> %{
>> #include "digital_binary_slicer_fb.h"
>> #include "digital_clock_recovery_mm_cc.h"
>> @@ -59,8 +61,6 @@
>> %include "digital_cpmmod_bc.i"
>> %include "digital_gmskmod_bc.i"
>>
>> -%include "swig_doc.i"
>> -
>> #if SWIGGUILE
>> %scheme %{
>> (load-extension-global "libguile-gnuradio-digital_swig"
>> "scm_init_gnuradio_digital_swig_module")
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 11.10
On 10/16/2011 07:17 PM, Tom Rondeau wrote: > The maint, master, and next branches in git have all been fixed to work > under Ubuntu 11.10 (new autotools and Qwt 6 were the main culprits). A bit > more information can be found here: > http://gnuradio.squarespace.com/home/2011/10/16/ubuntu-1110-troubles.html > I tried to switch to qwt6. So, I cant find python-qwt6 in the repos (this is for some of the grc qt widgets). So I guess that is a minor disappointment. And I got this compilation error. Any idea? > /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc: In constructor > ‘WaterfallDisplayPlot::WaterfallDisplayPlot(QWidget*)’: > /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc:321:33: error: > no matching function for call to ‘QwtPlotSpectrogram::setData(WaterfallData&)’ > /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc:321:33: note: > candidate is: > /usr/include/qwt/qwt_plot_spectrogram.h:63:10: note: void > QwtPlotSpectrogram::setData(QwtRasterData*) > /usr/include/qwt/qwt_plot_spectrogram.h:63:10: note: no known conversion > for argument 1 from ‘WaterfallData’ to ‘QwtRasterData*’ -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 11.10
On 10/17/2011 10:03 PM, Josh Blum wrote: > > > On 10/16/2011 07:17 PM, Tom Rondeau wrote: >> The maint, master, and next branches in git have all been fixed to work >> under Ubuntu 11.10 (new autotools and Qwt 6 were the main culprits). A bit >> more information can be found here: >> http://gnuradio.squarespace.com/home/2011/10/16/ubuntu-1110-troubles.html >> > > I tried to switch to qwt6. So, I cant find python-qwt6 in the repos > (this is for some of the grc qt widgets). So I guess that is a minor > disappointment. > python-qwt5-qt4 seems to work ok > And I got this compilation error. Any idea? > >> /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc: In >> constructor ‘WaterfallDisplayPlot::WaterfallDisplayPlot(QWidget*)’: >> /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc:321:33: error: >> no matching function for call to >> ‘QwtPlotSpectrogram::setData(WaterfallData&)’ >> /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc:321:33: note: >> candidate is: >> /usr/include/qwt/qwt_plot_spectrogram.h:63:10: note: void >> QwtPlotSpectrogram::setData(QwtRasterData*) >> /usr/include/qwt/qwt_plot_spectrogram.h:63:10: note: no known conversion >> for argument 1 from ‘WaterfallData’ to ‘QwtRasterData*’ > Here is my attempt to get it working. It compiled for me and ran. I didnt quite know what to do with rasterHint though... http://pastebin.com/Dn6HeXUt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 11.10
On Mon, Oct 17, 2011 at 10:03 PM, Josh Blum wrote: > > > On 10/16/2011 07:17 PM, Tom Rondeau wrote: > > The maint, master, and next branches in git have all been fixed to work > > under Ubuntu 11.10 (new autotools and Qwt 6 were the main culprits). A > bit > > more information can be found here: > > > http://gnuradio.squarespace.com/home/2011/10/16/ubuntu-1110-troubles.html > > > > I tried to switch to qwt6. So, I cant find python-qwt6 in the repos > (this is for some of the grc qt widgets). So I guess that is a minor > disappointment. > > And I got this compilation error. Any idea? > > > /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc: In > constructor ‘WaterfallDisplayPlot::WaterfallDisplayPlot(QWidget*)’: > > /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc:321:33: > error: no matching function for call to > ‘QwtPlotSpectrogram::setData(WaterfallData&)’ > > /home/jblum/src/gnuradio/gr-qtgui/lib/WaterfallDisplayPlot.cc:321:33: > note: candidate is: > > /usr/include/qwt/qwt_plot_spectrogram.h:63:10: note: void > QwtPlotSpectrogram::setData(QwtRasterData*) > > /usr/include/qwt/qwt_plot_spectrogram.h:63:10: note: no known > conversion for argument 1 from ‘WaterfallData’ to ‘QwtRasterData*’ > > -Josh Yeah, I know exactly what the problem is. I just found it myself. It arose after I fixed some edits to be compatible with 5.2, but didn't do it right to keep it working with qwt 6. I must not have properly updated my 11.10 box afterwards to check it. I just pushed what I believe are fixes to maint/master/next. Let me know if anyone has problems with either Qwt versions 5.2 or 6.0. The push to next also includes a bunch of updates to gr-digital where I've moved all of the OFDM work into gr-digital and reworked all of the examples to use UHD. Again, let me know if people experience more than the usual issues :) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
