Re: [Discuss-gnuradio] #include vector.hpp
Hi, Try dropping the .hpp portion of your include. This file does not have any extension and is usually included as follows: #include vector Hope this helps, Michael On Mon, Jun 22, 2015 at 9:16 AM, dcardona davidjcg2...@gmail.com wrote: Hello I'm trying to create a block which C++ code needs to use include vector.hpp. But I;m getting this error: fatal error: vector.hpp: No such file or directory. Is there a way to do this? Thank you very much. -- View this message in context: http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344.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
Re: [Discuss-gnuradio] #include vector.hpp
Hi! Um, there's no vector.hpp in GNU Radio; are you maybe referring to the header that contains std::vector? You would normally include that as #include vector and let your compiler figure out the file name suffix. Best regards, Marcus On 06/22/2015 06:16 PM, dcardona wrote: Hello I'm trying to create a block which C++ code needs to use include vector.hpp. But I;m getting this error: fatal error: vector.hpp: No such file or directory. Is there a way to do this? Thank you very much. -- View this message in context: http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344.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
[Discuss-gnuradio] Remove portion of tagged stream
Hello all, Question 1: I have another Does this exist already question. I'm using the correlate access code block to tag a stream of data. Is there a block that exists that will identify a tag and then remove the next X items, where X is user defined? I'm not looking to use the Header Payload/Demux for this, because the specification I'm designing to does not call out a header and I need to remain interoperable. Question 2: Assuming I have to write this block myself, I'd like some confirmation of my current thought process. Since the input/output relationship is not constant, as I will be removing samples (decimating) sometimes but other times copying input to output (sync), is the conclusion that I have to use a general block here correct? Question 3: When using a general block, it is my responsibility to consume and produce everything. With this said, if I call produce(X) to place samples in the output buffer, then what does the return statement do? If I return 8000, what does this mean? Thanks, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Remove portion of tagged stream
Thank you! Rich On Mon, Jun 22, 2015 at 4:16 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On Mon, Jun 22, 2015 at 4:09 PM, Richard Bell richard.be...@gmail.com wrote: Is there a block that exists that will identify a tag and then remove the next X items, where X is user defined? No. is the conclusion that I have to use a general block here correct? Yes if I call produce(X) to place samples in the output buffer, then what does the return statement do? If I return 8000, what does this mean? Use 'return WORK_CALLED_PRODUCE'. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] #include vector.hpp
On Mon, Jun 22, 2015 at 7:40 PM, Michael Berman mrberma...@gmail.com wrote: It looks like you are trying to create your own vector class named Vector (keeping notice of the capitalized 'V'). These Vector method definitions need a definition for the Vector class, which is presumably in your Vector.hpp. I would like to note that the .hpp extension indicates a template header library, and all of the method definitions should be inline in the template class definition, or in an include file; not in a compiled object file. It appears (at least from this lone file) that you are not using std::vector at all, and you may wish to remove the '#include vector' line to keep things clean in your code and not include not used pieces of code. Back to your example not working, your #include Vector.hpp must point to the file that presumably contains the class definition. for this include to work as stated, the Vector.hpp file will have to be in the same directory as the file that you posted; otherwise you will have to give a relative (or absolute) path to this file in the include statement. I hope this helps you some! Michael P.S. Why are you not using std::vector? David, While I'm kind of curious about you making your own vector class, too, this is not about GNU Radio but generally C++ coding issues. Please move this conversation to a more appropriate forum about programming. Thanks, Tom On Mon, Jun 22, 2015 at 3:35 PM, dcardona davidjcg2...@gmail.com wrote: Hi Yes, I tried to use only #include vector, but it gives me an error for each vector a I use. Vector f (at the beginning the following code) is one of the vectors which needs the #include vector.hpp. intentooptimizar.cpp http://gnuradio.4.n7.nabble.com/file/n54350/intentooptimizar.cpp Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] #include vector.hpp
It looks like you are trying to create your own vector class named Vector (keeping notice of the capitalized 'V'). These Vector method definitions need a definition for the Vector class, which is presumably in your Vector.hpp. I would like to note that the .hpp extension indicates a template header library, and all of the method definitions should be inline in the template class definition, or in an include file; not in a compiled object file. It appears (at least from this lone file) that you are not using std::vector at all, and you may wish to remove the '#include vector' line to keep things clean in your code and not include not used pieces of code. Back to your example not working, your #include Vector.hpp must point to the file that presumably contains the class definition. for this include to work as stated, the Vector.hpp file will have to be in the same directory as the file that you posted; otherwise you will have to give a relative (or absolute) path to this file in the include statement. I hope this helps you some! Michael P.S. Why are you not using std::vector? On Mon, Jun 22, 2015 at 3:35 PM, dcardona davidjcg2...@gmail.com wrote: Hi Yes, I tried to use only #include vector, but it gives me an error for each vector a I use. Vector f (at the beginning the following code) is one of the vectors which needs the #include vector.hpp. intentooptimizar.cpp http://gnuradio.4.n7.nabble.com/file/n54350/intentooptimizar.cpp Thank you. -- View this message in context: http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344p54350.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
Re: [Discuss-gnuradio] #include vector.hpp
Hi Yes, I tried to use only #include vector, but it gives me an error for each vector a I use. Vector f (at the beginning the following code) is one of the vectors which needs the #include vector.hpp. intentooptimizar.cpp http://gnuradio.4.n7.nabble.com/file/n54350/intentooptimizar.cpp Thank you. -- View this message in context: http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344p54350.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] Remove portion of tagged stream
On Mon, Jun 22, 2015 at 4:09 PM, Richard Bell richard.be...@gmail.com wrote: Is there a block that exists that will identify a tag and then remove the next X items, where X is user defined? No. is the conclusion that I have to use a general block here correct? Yes if I call produce(X) to place samples in the output buffer, then what does the return statement do? If I return 8000, what does this mean? Use 'return WORK_CALLED_PRODUCE'. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] #include vector.hpp
Yes Tom, you are absolutely right. I'm sorry and thank you. -- View this message in context: http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344p54356.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] Does a block always *have* to return something?
Hi Anil, Does a block always *have* to return something? What you mean is the work function. I know this is a bit nit-picky, but there has always been a lot of confusion caused by exactly that: The block is the whole instance of a class derived from gr.block, and the work() (or general_work()) is the method of that class which gets called repeatedly at runtime. You can have state as properties of the instance. I'm not quite sure what the effect of returning None (which is what happens when you don't return something in python) is, because that NoneObject would then be handled through SWIF to C++, and I have no idea whether SWIG has a uniform way of converting NoneObjects to integers. In essence: yes, general_work() must always return a number, but in most cases it's totally O.K. to return 0 if your block wasn't able to produce output. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fw: pybombs-gnuradio-install-missing files
On Sun, Jun 21, 2015 at 11:57 PM, Handy Kirk handy2...@yahoo.com.au wrote: Thank you for replying Tom, I seem to be struggling to get my replies to reach the discuss-gnuradio@gnu.org but this time I think and hope for the best. 1.. You guessed right about PCLinuxOS, I do want to use that, been a user for about 10 years, but as far as compiling I have very little experience. I understand the principle but when it comes down to details it is a struggle. I try to stay away unless I get really enthusiastic. Gnuradio too fascinating so by hook or by crook I will try something and experiment. 2.. I did not realise that Python 2.6 is outdated, but your mention made me check this laptos current version and it is (this just confirming that this PCLinuxOS version is also using later version than 2.6): [gert@KDE64-tecra-A11 ~]$ python -V Python 2.7.9 [gert@KDE64-tecra-A11 ~]$ Also I can confirm that by inspection in my sandbox I see Python 2.6.4 3.. I mentioned I had a record of my attempts to use pybombs, and it seems very early in my experience I have had no trouble with Python installing from source. The Python 2.6 is instatlled by pybombs install, here is the section: Installing from source: python --2015-06-11 18:43:40-- http://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2 Resolving www.python.org (www.python.org)... 103.245.222.223 Connecting to www.python.org (www.python.org)|103.245.222.223|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2 [following] --2015-06-11 18:43:41-- https://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2 Connecting to www.python.org (www.python.org)|103.245.222.223|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 11249486 (11M) [application/octet-stream] Saving to: ‘Python-2.6.4.tar.bz2’ Python-2.6.4.tar.bz2 100%[===] 10.73M 256KB/s in 43s 2015-06-11 18:44:24 (256 KB/s) - ‘Python-2.6.4.tar.bz2’ saved [11249486/11249486] Extract Python-2.6.4.tar.bz2 ./configure --prefix=/home/gert/gr-sandbox/target --enable-shared CC=gcc CXX=g++ Configuring: (100%) [==] Building: (100%) [==] make install Installing: (100%) [===] installation ok via: src - My understanding is that installing from source means that an acceptable version of a required program is located somewhere on the net and installed. Does that not mean in this case that pybombs want Python 2.6.4? Further my interpretation in above is that a version has been retrieved from www.python.org? Does this mean that my PCLinuxOS version somehow has a say in what Python version is acceptable to pybombs? I think I will see if I can set up a completely new partition with KDE64 and start all over again. Handy That's very strange behavior to install Python 2.6. The dependency tree must have identified that for some other package it was installing. This is, of course, the problem with trying to use a general build overlay system like PyBOMBS on top of the OS's package manager: there are so many of these distros out there and they all behave differently. Tom -- *From:* Tom Rondeau t...@trondeau.com *To:* Handy Kirk handy2...@yahoo.com.au *Cc:* discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org *Sent:* Friday, 19 June 2015, 23:22 *Subject:* Re: [Discuss-gnuradio] Fw: pybombs-gnuradio-install-missing files On Fri, Jun 19, 2015 at 1:58 AM, Handy Kirk handy2...@yahoo.com.au wrote: After a lot of work, I am a beginner concerning gnuradio, only an average linux user concentration on PCLinuxOS, now have an awfull lot of files installed in my sandbox. I have had many goes at installing 'pybombs' and I think I have an understanding of the concept of installing from source. What really knocked me about was a very precise position during the process the file 'boost' would terminate the process without any error message that I could find. The lack of finding the reason/errors probably because I know very little about compiling details. What came to my rescue was during one attempt the 'boost' download/install process became atrocciously slow but at the same time I could see it was trying to connect to my usual mirror (internode in Australia). I gave up but then a day of two later boots installed and the process could continue. (A resh install). Ufotunately I encounterd more files where the process simply was terminated with the command prompt but also reason quite clear, such as source not found.. Others it was not so clear to me, so I decided to continue anyway as some files by inspection in src seemed
[Discuss-gnuradio] Verifying Turbo encoder output (was: Re: (no subject))
Dear Salija, convolutional encoders are hard to check by hand. Typically, you'd try to decode to verify. PCCCs can be made systematic, I'm not sure that's the case for the GNU Radio implementation. Regarding the interleaver: turbocodes rely on adding redundancy calculated from the input data stream, and an permutated version of that. That permutation is done by the interleaver. Without the interleaver, you'd just have two times the same information added as redundancy, and that wouldn't really be an advantage over just using a simple convolutional code that adds twice the redundancy. Best regards, Marcus On 06/20/2015 07:34 AM, Salija P wrote: Hello all, I am working with turbo encoder and decoder. is there any method to check and verify the output of pccc encoder. I want to see the the output of pccc encoder for corresponding binary input. is there any way to do this? also any body can help me to explain interleaver operation in pccc encoder? Thanks in advance Salija.P With Regards, Salija.P ___ 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] FFT for FM Tx and Rx
Hi El,
this is a bit hard to tell -- are you using a direct cable or antennas
between TX and RX?
If you're using antennas, that might simply be something else
transmitting there.
Also, if you transmit at 560 MHz, but only observe
$\SI{562}{\mega\hertz}\pm\frac{\SI{0.2}{\mega\hertz}}{2}$, you can't see
your transmit signal, so I can't compare the strength of that and what
you see in your RX FFT plot.
Best regards,
Marcus
On 06/21/2015 03:47 PM, El El wrote:
Hi,
I implemented the FM transmitter and receiver from the tutorials
(http://files.ettus.com/tutorials/labs/Lab_1-5.pdf), the carrier
frequency is 560 MHz, audio rate = 48 kHz, and frequency deviation = 5
kHz. My question is why don't the FFT plots look similar? The FFT for
the transmitter is centered on 562 MHz, but for the receiver, the
highest amplitude component is centered on 561.97 MHz, also there is
one more component on 562.09 MHz. Screenshots of the FFT plots are
attached.
Thanks a lot,
El
___
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] Control Ports On/Off and Config file
Hi Rich, this might be more complicated than it sounds at first, but: 1. Build GNU Radio with debugging symbols (ie. cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo); install debugging symbols for your QT build (how to do this depends on your distribution) 2. run gdb --args python $(which gr-perf-monitorx) 3. run 4. Wait for crash 5. bt (for backtrace) will give you information on who called the function that tried to access a deleted QTableWidget. That might or might not be helpful. Assuming the QTableWidget shouldn't actually have been deleted: Running python inside gdb, you might be able to add a breakpoint at the destructor of QTableWidget; it's break functionname, but I'd have to look up whether that function would be QT::GUI::QTableWidget::~QTableWidget or something else. Then, gdb would interrupt the execution of gr-perf-monitorx the moment that table widget gets deleted. For a bit of background: https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB On 06/22/2015 08:38 PM, Richard Bell wrote: Is there a way I can give you feedback from my crash that will help you figure out the cause? If so, I'm happy to do it. Rich On Mon, Jun 22, 2015 at 5:21 AM, Tom Rondeau t...@trondeau.com mailto:t...@trondeau.com wrote: On Fri, Jun 19, 2015 at 1:42 PM, Richard Bell richard.be...@gmail.com mailto:richard.be...@gmail.com wrote: I just ran a new pull, I don't see any updates related to gr-perf-monitorx, so I think I already have that commit. Here is the pull details just in case: The patch that fixed it for me went in a while ago, just about when we put back ControlPort support in April. If I can duplicate the failure mode, then I might be able to fix it. Otherwise, there's no much I can do to debug the problem. Tom rbell@rbell:~/Documents/gnuradio$ git pull origin master remote: Counting objects: 32, done. remote: Total 32 (delta 22), reused 22 (delta 22), pack-reused 10 Unpacking objects: 100% (32/32), done. From https://github.com/gnuradio/gnuradio * branchmaster - FETCH_HEAD 7b684a2..28f69a5 master - origin/master Updating 7b684a2..28f69a5 Fast-forward CMakeLists.txt | 35 +++-- .../include/gnuradio/thrift_application_base.h | 4 +- gnuradio-runtime/lib/CMakeLists.txt| 7 ++- gr-digital/grc/digital_constellation.xml | 21 +--- gr-digital/grc/digital_constellation_rect.xml | 60 +- grc/python/Generator.py| 2 +- 6 files changed, 75 insertions(+), 54 deletions(-) rbell@rbell:~/Documents/gnuradio$ Is there anyway I can help you figure out the cause of the crash? Rich On Fri, Jun 19, 2015 at 10:37 AM, Tom Rondeau t...@trondeau.com mailto:t...@trondeau.com wrote: On Fri, Jun 19, 2015 at 12:58 PM, Richard Bell richard.be...@gmail.com mailto:richard.be...@gmail.com wrote: That was the first thing I checked. No I don't have any config file in there. I'm not sure where it's picking up these other settings. I added a local config file to ~/.gnuradio with the same settings and now they seem to be picked up correctly. Shrug. I had to install one last python module, python-graphviz, but it starts up and runs now! If I leave it on the default view, it seems to run stably. If I switch to the 'Buffer Table-Graph View' or 'Run Table-Graph View', then Performance Monitor crashes, sometimes instantly, sometimes after a few seconds, with the following error: ControlPort Monitor running. monitor::endpoints() = -h rbell -p 57991 running: ['gr-perf-monitorx', 'rbell', '57991'] Traceback (most recent call last): File /usr/local/bin/gr-perf-monitorx, line 370, in update if(self.perfTable.isVisible()): RuntimeError: wrapped C/C++ object of type QTableWidget has been deleted Have I overlooked something? Rich Darn, I thought that I fixed that bug here: https://github.com/gnuradio/gnuradio/commit/3b41bb4dec9b6ce89e4909d20fbc7ffd764a80f3 Tom On Fri, Jun 19, 2015 at 6:38 AM, Tom Rondeau t...@trondeau.com mailto:t...@trondeau.com wrote: On Thu, Jun 18, 2015 at 7:38 PM, Richard Bell richard.be...@gmail.com
Re: [Discuss-gnuradio] Control Ports On/Off and Config file
Is there a way I can give you feedback from my crash that will help you figure out the cause? If so, I'm happy to do it. Rich On Mon, Jun 22, 2015 at 5:21 AM, Tom Rondeau t...@trondeau.com wrote: On Fri, Jun 19, 2015 at 1:42 PM, Richard Bell richard.be...@gmail.com wrote: I just ran a new pull, I don't see any updates related to gr-perf-monitorx, so I think I already have that commit. Here is the pull details just in case: The patch that fixed it for me went in a while ago, just about when we put back ControlPort support in April. If I can duplicate the failure mode, then I might be able to fix it. Otherwise, there's no much I can do to debug the problem. Tom rbell@rbell:~/Documents/gnuradio$ git pull origin master remote: Counting objects: 32, done. remote: Total 32 (delta 22), reused 22 (delta 22), pack-reused 10 Unpacking objects: 100% (32/32), done. From https://github.com/gnuradio/gnuradio * branchmaster - FETCH_HEAD 7b684a2..28f69a5 master - origin/master Updating 7b684a2..28f69a5 Fast-forward CMakeLists.txt | 35 +++-- .../include/gnuradio/thrift_application_base.h | 4 +- gnuradio-runtime/lib/CMakeLists.txt| 7 ++- gr-digital/grc/digital_constellation.xml | 21 +--- gr-digital/grc/digital_constellation_rect.xml | 60 +- grc/python/Generator.py| 2 +- 6 files changed, 75 insertions(+), 54 deletions(-) rbell@rbell:~/Documents/gnuradio$ Is there anyway I can help you figure out the cause of the crash? Rich On Fri, Jun 19, 2015 at 10:37 AM, Tom Rondeau t...@trondeau.com wrote: On Fri, Jun 19, 2015 at 12:58 PM, Richard Bell richard.be...@gmail.com wrote: That was the first thing I checked. No I don't have any config file in there. I'm not sure where it's picking up these other settings. I added a local config file to ~/.gnuradio with the same settings and now they seem to be picked up correctly. Shrug. I had to install one last python module, python-graphviz, but it starts up and runs now! If I leave it on the default view, it seems to run stably. If I switch to the 'Buffer Table-Graph View' or 'Run Table-Graph View', then Performance Monitor crashes, sometimes instantly, sometimes after a few seconds, with the following error: ControlPort Monitor running. monitor::endpoints() = -h rbell -p 57991 running: ['gr-perf-monitorx', 'rbell', '57991'] Traceback (most recent call last): File /usr/local/bin/gr-perf-monitorx, line 370, in update if(self.perfTable.isVisible()): RuntimeError: wrapped C/C++ object of type QTableWidget has been deleted Have I overlooked something? Rich Darn, I thought that I fixed that bug here: https://github.com/gnuradio/gnuradio/commit/3b41bb4dec9b6ce89e4909d20fbc7ffd764a80f3 Tom On Fri, Jun 19, 2015 at 6:38 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jun 18, 2015 at 7:38 PM, Richard Bell richard.be...@gmail.com wrote: I set my gnuradio configuration file (located here: /usr/local/etc/gnuradio/conf.d/gnuradio-runtime.conf) to the following: [PerfCounters] on = True #False export = True #False clock = thread #clock = monotonic [ControlPort] on = True #False edges_list = True #False I continue to run into the following message when I include a 'ctrlport performance monitor' in my flowgraph: ControlPort Monitor running. monitor::endpoints() = -h rbell -p 49158 running: ['gr-perf-monitorx', 'rbell', '49158'] Configuration has not turned on all of the appropriate ControlPort features: [ControlPort] on = True [ControlPort] edges_list = False [PerfCounters] on = True [PerfCounters] export = False Is there another file overriding the config file I set above to cause this? v/r, Rich Do you have a local config file in ~/.gnuradio/config.conf? Entries in there will override the system installed settings. See the manual page here for details: http://gnuradio.org/doc/doxygen/page_prefs.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues using Correlata and Sync block, inside Hier_block2
On Fri, Jun 19, 2015 at 9:25 AM, Marius Cachelin marius.cache...@gmail.com wrote: Hi everybody, I am writing here because I am experiencing an issue (for some weeks now), and I can't fixed it! I did some research about this problem, but I found nothing! I want to develop a hierarchical block, (called RX_PATH). In this block, I want to use the Correlate and Sync block... And here is my problem! When I compile my module (using make), all work well. But, when I run my .grc model in GNURadio-Companion, it's like the Correlate and Sync block freeze. Actually, no samples are outputted (neither in out port nor in corr port). I don't understand why, because when I use the correlate and sync block outside my hier_block, it work fine! I think, this is a misunderstood of how to use these type of blocks, so if someone could explain to me where is my mistake, I would be very grateful! Thanks in advance! Marius That definitely sounds like unexpected behavior, and I can't think of much to say right now about what might be going on. However, we are deprecating that correlate_and_sync block in favor of the corr_est block. There are a number of improvements in corr_est, and something in the scheduling might work better for you because of that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio-companion-3.7.7.1 debian package
Hi Marcus, I used a new installation of 12.04. I got the sources for 3.7.7.1 instead of 3.7.7 this time. The generated debian package works fine. My previous environment could have been wrong or maybe it was something in 3.7.7. In any case, thanks a lot for your help. Cheers, Murray 2015-06-19 16:36 GMT+01:00 Marcus Müller marcus.muel...@ettus.com: Hi Murray, that's strange: ImportError: libboost_system.so.1.58.0: cannot open shared object file: No such file or directory contradicts libboost_system.so.1.48.0 = /usr/lib/libboost_system.so.1.48.0 (0xb71d8000) There's something seriously wrong about this situation. If not gnuradio-config-info was linked against boost 1.58 symbols, then one of the libraries it tries to use one your second PC is. That error comes from *somewhere*. Maybe you'd want to compare the ldd $(...) output of both systems, especially the individual paths of the libraries. Did you happen to build a custom boost on the second machine at some point? Best regards, Marcus On 06/19/2015 05:27 PM, Murray Thomson wrote: Hello again 2015-06-19 14:35 GMT+01:00 Marcus Müller marcus.muel...@ettus.com: Hi! user@pc:~$ gnuradio-config-info ImportError: libboost_system.so.1.58.0: cannot open shared object file: No such file or directory This means that the gnuradio-config-info was definitely built with another version of boost (1.58) than what is found at the moment you start it. This is what I thought too but sudo find / -name libboost* only finds libraries for boost 1.46 and 1.48. The point about distributions is that they strive to keep all their libraries coherent in one release. So, although the install script might have installed the modern boost version correctly and set up some paths so that on your first PC, linux knows where to look for boost 1.58, on the other, this won't work automatically. You can find out where the libboost_system.so.1.58.0 is on the system where it works by running ldd $(which gnuradio-config-info). The system works but win a Gnuradio installed from the build_gnuradio script, not the debian package that I built. user@pc:~$ ldd $(which gnuradio-config-info) linux-gate.so.1 = (0xb776) libgnuradio-runtime-3.7.8git.so.0.0.0 = /usr/local/lib/libgnuradio-runtime-3.7.8git.so.0.0.0 (0xb7671000) libboost_program_options.so.1.48.0 = /usr/lib/libboost_program_options.so.1.48.0 (0xb7612000) libpthread.so.0 = /lib/i386-linux-gnu/libpthread.so.0 (0xb75f6000) libstdc++.so.6 = /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7511000) libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74f3000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xb7349000) libgnuradio-pmt-3.7.8git.so.0.0.0 = /usr/local/lib/libgnuradio-pmt-3.7.8git.so.0.0.0 (0xb730b000) libvolk.so.1.0 = /usr/local/lib/libvolk.so.1.0 (0xb71fa000) libboost_filesystem.so.1.48.0 = /usr/lib/libboost_filesystem.so.1.48.0 (0xb71dc000) libboost_system.so.1.48.0 = /usr/lib/libboost_system.so.1.48.0 (0xb71d8000) libboost_thread.so.1.48.0 = /usr/lib/libboost_thread.so.1.48.0 (0xb71bf000) librt.so.1 = /lib/i386-linux-gnu/librt.so.1 (0xb71b6000) libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xb7189000) /lib/ld-linux.so.2 (0xb7761000) liborc-0.4.so.0 = /usr/lib/i386-linux-gnu/liborc-0.4.so.0 (0xb70f9000) So the question is: which tool did you exactly use to install GNU Radio? I used cmake with the following parameters: cmake -DCMAKE_INSTALL_PREFIX=/usr SYSCONFDIR=/etc -DENABLE_STATIC_LIBS=False \ -DENABLE_DOXYGEN=False -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF \ -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF .. If you use pyBOMBS, you get the ability to install everything, including updated versions of boost etc., into a specific private directory, and generate a script that sets up all paths accordingly. You can then just copy that prefix and script over to the other PC; that's pretty distribution agnostic, but to be honest: If you wanted to make packages for all the things that GNU Radio likes to have a bit more recent, you'd be basically producing packages for half the development libraries that GNU Radio needs -- 12.04 is 3 years old... I wish I could upgrade my Ubuntu but I'm stack with 12.04 for other reasons. I'll try the pybombs way and also the same method for gnuradio 3.7.5 to check that I get the same error Best regards, Marcus Thank you for your help Murray On 06/19/2015 02:52 PM, Murray Thomson wrote: Thanks for that Marcus, I got around that first step. My computer runs Ubuntu 12.04 with libboost 1.48 and it has a working gnuradio installation v3.7.7.1-120-g67463e74 from the script in the web. I used that computer to create the debian package based on https://github.com/gnuradio/gnuradio.git tag v3.7.7 and I installed it in another Ubuntu 12.04 with libboost 1.48. get the following error message when running this command or any
Re: [Discuss-gnuradio] Control Ports On/Off and Config file
On Fri, Jun 19, 2015 at 1:42 PM, Richard Bell richard.be...@gmail.com wrote: I just ran a new pull, I don't see any updates related to gr-perf-monitorx, so I think I already have that commit. Here is the pull details just in case: The patch that fixed it for me went in a while ago, just about when we put back ControlPort support in April. If I can duplicate the failure mode, then I might be able to fix it. Otherwise, there's no much I can do to debug the problem. Tom rbell@rbell:~/Documents/gnuradio$ git pull origin master remote: Counting objects: 32, done. remote: Total 32 (delta 22), reused 22 (delta 22), pack-reused 10 Unpacking objects: 100% (32/32), done. From https://github.com/gnuradio/gnuradio * branchmaster - FETCH_HEAD 7b684a2..28f69a5 master - origin/master Updating 7b684a2..28f69a5 Fast-forward CMakeLists.txt | 35 +++-- .../include/gnuradio/thrift_application_base.h | 4 +- gnuradio-runtime/lib/CMakeLists.txt| 7 ++- gr-digital/grc/digital_constellation.xml | 21 +--- gr-digital/grc/digital_constellation_rect.xml | 60 +- grc/python/Generator.py| 2 +- 6 files changed, 75 insertions(+), 54 deletions(-) rbell@rbell:~/Documents/gnuradio$ Is there anyway I can help you figure out the cause of the crash? Rich On Fri, Jun 19, 2015 at 10:37 AM, Tom Rondeau t...@trondeau.com wrote: On Fri, Jun 19, 2015 at 12:58 PM, Richard Bell richard.be...@gmail.com wrote: That was the first thing I checked. No I don't have any config file in there. I'm not sure where it's picking up these other settings. I added a local config file to ~/.gnuradio with the same settings and now they seem to be picked up correctly. Shrug. I had to install one last python module, python-graphviz, but it starts up and runs now! If I leave it on the default view, it seems to run stably. If I switch to the 'Buffer Table-Graph View' or 'Run Table-Graph View', then Performance Monitor crashes, sometimes instantly, sometimes after a few seconds, with the following error: ControlPort Monitor running. monitor::endpoints() = -h rbell -p 57991 running: ['gr-perf-monitorx', 'rbell', '57991'] Traceback (most recent call last): File /usr/local/bin/gr-perf-monitorx, line 370, in update if(self.perfTable.isVisible()): RuntimeError: wrapped C/C++ object of type QTableWidget has been deleted Have I overlooked something? Rich Darn, I thought that I fixed that bug here: https://github.com/gnuradio/gnuradio/commit/3b41bb4dec9b6ce89e4909d20fbc7ffd764a80f3 Tom On Fri, Jun 19, 2015 at 6:38 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jun 18, 2015 at 7:38 PM, Richard Bell richard.be...@gmail.com wrote: I set my gnuradio configuration file (located here: /usr/local/etc/gnuradio/conf.d/gnuradio-runtime.conf) to the following: [PerfCounters] on = True #False export = True #False clock = thread #clock = monotonic [ControlPort] on = True #False edges_list = True #False I continue to run into the following message when I include a 'ctrlport performance monitor' in my flowgraph: ControlPort Monitor running. monitor::endpoints() = -h rbell -p 49158 running: ['gr-perf-monitorx', 'rbell', '49158'] Configuration has not turned on all of the appropriate ControlPort features: [ControlPort] on = True [ControlPort] edges_list = False [PerfCounters] on = True [PerfCounters] export = False Is there another file overriding the config file I set above to cause this? v/r, Rich Do you have a local config file in ~/.gnuradio/config.conf? Entries in there will override the system installed settings. See the manual page here for details: http://gnuradio.org/doc/doxygen/page_prefs.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fw: pybombs-gnuradio-install-missing files
From: Tom Rondeau t...@trondeau.com To: Handy Kirk handy2...@yahoo.com.au Cc: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Monday, 22 June 2015, 22:10 Subject: Re: [Discuss-gnuradio] Fw: pybombs-gnuradio-install-missing files That's very strange behavior to install Python 2.6. The dependency tree must have identified that for some other package it was installing. This is, of course, the problem with trying to use a general build overlay system like PyBOMBS on top of the OS's package manager: there are so many of these distros out there and they all behave differently. Tom - PyBOMBS GNU Radio Build Quick Start¶You can opt to just use the source, 'src', install and build everything from source. I selected to install from src only, my interpretation of above is that this would bypass PCLinuxOS already installed files even if they were acceptable for use in PyBOMBS (of course taking extra time) is this correct? Or is that only part true? PCLinuxOS is rpm/Synaptic based, I have also tried install with options: rpm,src but that failed in grander style so I soon changed to src only as a safer starting point. In the next day or two I will have new partition installed with fresh KDE64 install and try again. I have the liveDVD part installed but need a bit 1 GB update to bring it to todays date should be done the coming day with PyBOMBS attempt 1 day later. h. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
