[Discuss-gnuradio] Data types

[Tellrell White]

Hello All
I have a question concerning data types. I'm creating a sink block in python 
that takes float values from a "divide" block that has a vector length of 1024. 
The output port on the divide block is red. How can set the input of my block 
to have a red input port?

Regards
Tellrell

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

Re: [Discuss-gnuradio] CRC32 discrepancy

[Andrej Rode]

Hi Eric & Marcus, 

I just submitted a fix for this issue [0].
This should new have the correct behaviour.

Cheers
Andrej

[0] https://github.com/gnuradio/gnuradio/pull/1504
On Fri, Aug 04, 2017 at 11:32:13AM +0200, Marcus Müller wrote:
> Hi Eric!
> 
> Thanks for the bug report! Tracking that as an issue on github [1] now.
> 
> You don't happen to have a fix that you've tested already?
> 
> Best regards,
> 
> Marcus
> 
> 
> [1] https://github.com/gnuradio/gnuradio/issues/1407
> 
> 
> On 08/03/2017 04:54 PM, ERIC BANWART wrote:
> >
> > I am using the Stream CRC32 block and was having trouble getting the 
> > CRCs to pass. After some debugging I discovered that the 
> > calculated CRC is different depending on whether or not the source 
> > data is packed. This can be observed using the attached flow graph. 
> > The result of the packed stream appears to be correct. I looked at the 
> > code for the block (crc32_impl_bb.cc) and that see that regardless of 
> > the Packed setting in the block the CRC calculated with: 
> > d_crc_impl.process_bytes(in, packet_length);
> >
> >
> > I believe that for the unpacked case, either the bits need be repacked 
> > before the calculation or repeated calls to process_bits should be 
> > used in place of the the call to process_bytes.
> >
> >
> > My version of gnuradio is:  3.7.12git-126-g37d373ac
> >
> >
> > Thanks!
> >
> > Eric
> >
> >
> >
> > ___
> > 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


-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

[Discuss-gnuradio] qtgui waterfall_sink_f in an OOT

[Kleine, Kaleb]

Hello,

I am trying to create an OOT named myqt that contains a duplicate of the qtgui 
waterfall_sink_f but I am having what appears to be some linking issues. I 
created a new OOT with the gr_modtool then added a module named 
waterfall_sink_f. I then replace the files generated in the lib and include 
folders with those in gnuradio/qtgui. I changed the namespace from qtgui to 
myqt and changed the  and 
 includes to  and . 
I also replace QTGUI_API with MYQT_API. I then modified the following cmake 
files

./CMakeLists.txt
+ find_package(Qt4 4.2.0 COMPONENTS QtCore QtGui)
+ find_package(Qwt 6.0.0)
+ include(GrSetupQt4)   (I added FindQwt.cmake from gnuradio source to my OOT 
cmake/Modules)
+ added QWT and QT DIRS to library and incude

./lib/CMakeLists.txt
+ added ${QWT_LIBRARIES} ${QT_LIBRARIES} gnuradio-qtgui to the target link 
libraries

With these changes the code compiles however when I run python myqt_swig.py I 
get the following

:gr-myqt/build/swig$ python myqt_swig.py
Traceback (most recent call last):
  File "myqt_swig.py", line 28, in 
_myqt_swig = swig_import_helper()
  File "myqt_swig.py", line 24, in swig_import_helper
_mod = imp.load_module('_myqt_swig', fp, pathname, description)
ImportError: gr-myqt/build/lib/libgnuradio-myqt-1.0.0git.so.0.0.0: undefined 
symbol: _ZN20WaterfallDisplayForm13setUpdateTimeEd
:gr-myqt/build/swig$ c++filt _ZN20WaterfallDisplayForm13setUpdateTimeEd
WaterfallDisplayForm::setUpdateTime(double)

I then run nm -gC on the shared library and get the following

:gr-myqt/build/lib$ nm -gC libgnuradio-myqt-1.0.0git.so.0.0.0 | grep 
setUpdateTime
 U WaterfallDisplayForm::setUpdateTime(double)

So it is undefined but I can't seem to figure out how to fix that... any help 
would be greatly appreciated.

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

Re: [Discuss-gnuradio] Best Way to revert to old releases with PyBombs.

[Richard Mcallister]

Hi all,

This is exactly what I wanted. Thank you! Also Nicolas-I want to downgrade
to check and make sure its not an issue with UHD, or a specific UHD
release. The flowgraph was made and used last spring, where it worked. The
only changes over the summer were a new computer and a new installation of
UHD. I want to check and verify its not one. There is a thread on the
usrp-users mailing list, that I made awhile ago and one I made on Monday
about this.

-Rich

On Mon, Oct 30, 2017 at 9:28 PM, Martin Braun 
wrote:

> You can even specify a git revision, by doing something like
>
> $ pybombs -p  config --package uhd gitrev release_003_009_006
>
> Then, if you do pybombs rebuild (without the -k), it'll update your git
> source. (At least it should -- typing this out from memory).
>
> -- M
>
> On 10/30/2017 03:34 PM, Nicolas Cuervo wrote:
> > Hello Richard,
> >
> > I believe the best way (so far) would be to actually go to the
> > repository that you want to rebuild and checkout to the different
> > specific branch/tag and then trigger the rebuild with
> >
> > $ pybombs -p /your_prefix/ rebuild /uhd/
> >
> > You can rebuild faster by adding the '-k' flag at the end of the
> > command, so it won't delete the build directory and start over (depends
> > on the number of API changes this might be a good or a bad idea).
> >
> > If you are using GNURadio, don't forget to rebuild is as well so it
> > picks up the right version. And, if you identify any issues with UHD,
> > please also start a thread on the USRP-users mailing list in order to
> > discuss them further.
> >
> > Regards,
> > - Nicolas
> >
> >
> >
> > On Mon, Oct 30, 2017 at 3:05 PM, Richard Mcallister  > > wrote:
> >
> > Hi all,
> >
> > I think the question is all in the subject, but basically, I'm
> > having trouble with using several USRPs. I think it may be an issue
> > with UHD, or at least I need to verify it isn't. Does pybombs have a
> > command to install older releases or specific branch tags from git?
> >
> > Thanks,
> > Rich McAllister
> >
> > ___
> > 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 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] Fwd: Random test failures when compiling GNURadio from source

[Andrej Rode]

Hi, 

On Mon, Oct 30, 2017 at 10:27:06PM +0100, Sebastian Müller wrote:
> I’ve noticed the same on our buildbot setup (and wanted to address this for
> a while). `qa_packet_format` is another candidate which seems to randomly
> fail. Also compiling on buildbot seems to fail sometimes randomly because
> of `M_SQRT2` or `M_LOG2E` undeclared errors.
Those are new, can you pinpoint to a specific failed build?

> 
> So, Kevin, without having a deeper look I assume the tests need to be
> revised. I’m also glad to have a look as soon as I find some time. Maybe we
> can accumulate faulty tests within this thread and start working from there.

I already started accumulating flaky/broken unittests some time ago in this 
issue:
https://github.com/gnuradio/gnuradio/issues/1261

Some of them are only triggered with `make -j N test` for great N.

Cheers
Andrej


-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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