[Discuss-gnuradio] cannot import name GNURadio when launching perf-monitorx and ctrlport-monitor
I am trying to measure performance of my OOT module with performance counter and control port. When I execute a command line `gr-perf-monitorx` or `gr-ctrlport-monitor`, an error below occurred: File /usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py, line 26, in module from gnuradio.ctrlport import GNURadio ImportError: cannot import name GNURadio Could anyone give me a hint for this? For detail information, I've installed GNU Radio with `build-gnuradio` script. The last commit of cloned git repository in my PC is `d5cea6e4( https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68)` in Jun 22 2015. I can't remember exactly, but I think this commit was used to install the GNU Radio. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot import name GNURadio when launching perf-monitorx and ctrlport-monitor
The same error happens in the 3.7.8 release candidate. -- Volker I am trying to measure performance of my OOT module with performance counter and control port. When I execute a command line `gr-perf-monitorx` or `gr-ctrlport-monitor`, an error below occurred: File /usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py, line 26, in module from gnuradio.ctrlport import GNURadio ImportError: cannot import name GNURadio Could anyone give me a hint for this? For detail information, I've installed GNU Radio with `build-gnuradio` script. The last commit of cloned git repository in my PC is `d5cea6e4(https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68)` https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68%29%60 in Jun 22 2015. I can't remember exactly, but I think this commit was used to install the GNU Radio. Regards, Jeon. ___ 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] Communication problems between 2 USRP's
On Thu, Jul 30, 2015 at 6:30 PM, John Garrick li...@ruby-forum.com wrote: Hi all, I want to transmit the data between two USRP's and make them communicate with each other. But I guess the packets are not being received properly.. My USRP daughterboard model is XCVR2450. When I am running ./benchmark_tx.py -f 2.435G, it is starting to transmit the packets but a small error occured given below, linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.git-144-g407e3086 Using Volk machine: avx_64_mmx -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 7.50 (from [-20.00, 35.00]) UHD Warning: The hardware does not support the requested TX sample rate: Target sample rate: 0.05 MSps Actual sample rate: 0.25 MSps Symbol Rate: 25000.00 Requested sps: 2.00 Given sample rate: 25.00 Actual sps for rate: 10.00 Requested sample rate: 5.00 Actual sample rate: 25.00 ..U...terminate called after throwing an instance of 'uhd::runtime_error' what(): RuntimeError: usb tx2 transfer status: 1 Aborted (core dumped). But towards the receiver side, I gave the command ./benchmark_rx.py -f 2.435GG,it has shown the result given below with n_right=0. linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.git-144-g407e3086 Using Volk machine: avx_64_mmx -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 56.25 (from [0.00, 112.50]) UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.05 MSps Actual sample rate: 0.25 MSps Symbol Rate: 25000.00 Requested sps: 2.00 Given sample rate: 25.00 Actual sps for rate: 10.00 Requested sample rate: 5.00 Actual sample rate: 25.00 ok = False pktno = 53034 n_rcvd =1 n_right =0 ok = False pktno = 24 n_rcvd =2 n_right =0 ok = False pktno = 35 n_rcvd =3 n_right =0 ok = False pktno = 44 n_rcvd =4 n_right =0 ok = False pktno = 46 n_rcvd =5 n_right =0 ok = False pktno = 46 n_rcvd =6 n_right =0 ok = False pktno = 3872 n_rcvd =7 n_right =0 ok = False pktno = 12304 n_rcvd =8 n_right =0 ok = False pktno = 49 n_rcvd =9 n_right =0 ok = False pktno = 50 n_rcvd = 10 n_right =0 ok = False pktno = 54 n_rcvd = 11 n_right =0 ok = False pktno = 200 n_rcvd = 12 n_right =0 ok = False pktno = 63 n_rcvd = 13 n_right =0 My USRP can access in the range of 2.4GHZ to 5GHZ. Please advice as to what I can do. Thanks Regards, John John, There's lots of things that can go wrong here. You didn't set the gains or transmit amplitude. Do you know if you have a significant frequency offset between your two radios? You might need to adjust that. The fact that you are getting ok = False means that the receiver saw a packet, but there were too many errors and the CRC check failed. Note there is no FEC applied to the benchmark scripts. So this could be due to low SNR, a bad channel, or, frankly, many other possibilities. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] file source with gr-ieee802.11 tx
The wifi_tx example GRC comes with a Socket PDU source. Just send UDP packets to the port specified containing a IEEE 802.11 packet's amount of data per UDP packet; netcat/nc/ncat is sadly no good for this, because it doesn't allow specification of packet sizes. You can also use a file source, stream to tagged stream, tagged stream to PDU flow graph. To be honest, GNU Radio is kind of lacking a simple take n items from the input stream and generate a PMT pair (n, items), send that over your message port block, which would take roughly 10 lines of python to write (and not much more C++) -- so you might as well do that. This is something I have struggled with as well. A lot of examples I've seen are for streaming data (which is admittedly probably want most people are wanting). I have been more interested in sending a packet (or a series of packets) over the air (the end goal being letting someone connect to my UDP source block and handing me their data they want to send). I have played with the WiFi block a bit recently and unfortunately was always using netcat 1 - Are you saying that the data's packet being handed to the socket PDU has to be exactly as long as the pdu_length? That is something I think I must have glossed over. 2 - I don't believe there is a way to dump just the payload of the 802.11 packet, right? Basically, if I sent Hello World to the Socket PDU (which means my pdu_length would need to be set to 11, right?), is there a way to have those 11 characters be passed out a UDP sink on the receiver end? Right now the only thing I can see to do is to utilize the Wireshark Connector and dump the pcap output to file, then take info and extract the payload from there in post-processing. Is that right? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error during Install my_qpsk_demod in grc
On Fri, Jul 31, 2015 at 5:33 AM, Surjeet Rawat li...@ruby-forum.com wrote: please give some suggestion related to this error Attachments: http://www.ruby-forum.com/attachment/10928/Screenshot_from_2015-07-31_13_16_57.png -- Posted via http://www.ruby-forum.com/. Can you explain how you got there? Also, please just paste the text instead of sending a png. It's likely to live longer in the archives this way. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h à actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind when we see this is that you haven't added all of the public functions of your block to the public header file (file_sink.h), but you say that's identical. Still probably worth checking on that file to make sure. Have you looked at your swig directory's .i file? That needs to properly reference your block to export it into Python. It seems like this is ok since you're getting as far as to see the error on the method, not the block. Again, though, something to check. So this is just you replicating the file sink blocks completely? You aren't trying to inherit from them or use them internally, are you? That might cause other issues. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] file source with gr-ieee802.11 tx
Hi, On 31 Jul 2015, at 14:10, Jason Matusiak ja...@gardettoengineering.com wrote: The wifi_tx example GRC comes with a Socket PDU source. Just send UDP packets to the port specified containing a IEEE 802.11 packet's amount of data per UDP packet; netcat/nc/ncat is sadly no good for this, because it doesn't allow specification of packet sizes. You can also use a file source, stream to tagged stream, tagged stream to PDU flow graph. To be honest, GNU Radio is kind of lacking a simple take n items from the input stream and generate a PMT pair (n, items), send that over your message port block, which would take roughly 10 lines of python to write (and not much more C++) -- so you might as well do that. This is something I have struggled with as well. A lot of examples I've seen are for streaming data (which is admittedly probably want most people are wanting). I have been more interested in sending a packet (or a series of packets) over the air (the end goal being letting someone connect to my UDP source block and handing me their data they want to send). I have played with the WiFi block a bit recently and unfortunately was always using netcat 1 - Are you saying that the data's packet being handed to the socket PDU has to be exactly as long as the pdu_length? That is something I think I must have glossed over. You can pass data of any size of up to 1500 bytes (minus a bit for headers). 2 - I don't believe there is a way to dump just the payload of the 802.11 packet, right? Basically, if I sent Hello World to the Socket PDU (which means my pdu_length would need to be set to 11, right?), is there a way to have those 11 characters be passed out a UDP sink on the receiver end? Right now the only thing I can see to do is to utilize the Wireshark Connector and dump the pcap output to file, then take info and extract the payload from there in post-processing. Is that right? The transceiver wraps your payload in some headers that add stuff like MAC address, frame type, and CRC. These are the minimum fields that are required so that a WiFi card actually accepts the frame. There is currently no option to dump raw bytes, but its a trivial modification of the Wireshark block (dump without a PCAP header). If you want to printed bytes as hex-values on the console that should work with the parse block. Or you could use a Debug Message block and print the PDUs coming out of the PHY / MAC, depending on what you want to see. Best, Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
On Fri, Jul 31, 2015 at 10:50 AM, Valenta, Chris R. chris.vale...@gtri.gatech.edu wrote: So the function (set_unbuffered) that’s coming up as not being found is in file_sink_base.h which is included in the file_sink.h so I’m pretty sure I’m ok here. The swig file just includes file_sink.h….I tried adding file_sink_base.h to this as well, but it didn’t change anything. For the time being, I’m replicating the file_sink block exactly (except the name) to try and get it to compile OOT. However, since file_sink depends on file_sink_base, which I’m not copying, I think there are problems linking to it. Would it be better to also copy file_sink_base to my OOT module? You should be able to use file_sink_base from libgnuradio-blocks.so, so no, keep that one in tree so you're not carrying around extra stuff. First, do you have BLOCKS as one of the GNU Radio required components in your CMakeLists.txt file? Also, and I suspect this might be the real problem, do you #define BLOCKS_API in you .i file? There should be a #define for your module's name already; just add this line here along with that one. Tom *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf Of *Tom Rondeau *Sent:* Friday, July 31, 2015 10:27 AM *To:* Valenta, Chris R. *Cc:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h à actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind when we see this is that you haven't added all of the public functions of your block to the public header file (file_sink.h), but you say that's identical. Still probably worth checking on that file to make sure. Have you looked at your swig directory's .i file? That needs to properly reference your block to export it into Python. It seems like this is ok since you're getting as far as to see the error on the method, not the block. Again, though, something to check. So this is just you replicating the file sink blocks completely? You aren't trying to inherit from them or use them internally, are you? That might cause other issues. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About physcially acceptable, applicable signal input range for GNU Radio.
On 07/31/2015 11:29 AM, Jeon wrote: Dear all of you helping me, Marcus, Tom and Marcus Thanks for all of your answers. I've successfully receive frames and decode it. There are some physical and practical issues and glitches that I haven't thought about when writing source codes. But it's not what should be handled in this thread. I will let you know when I finish implementing GNU Radio OOT module and analog circuit front end, if there are someone interested in. :) One small question is, is there no way to guess a value of voltage, given that ADC sampled value? I think it's quite impossible to guess both values of DC component and AC component. It's because time sink figure in the original post,there's no DC component, but I fed a DC biased signal into the LFRX. At least for AC component, however, I think it is possible to guess... If we know ADC resolution, impedance (of course 50 ohms) and so... It's just curiosity. I'm not going to use such things right now. So if it is hard to tell in short time, YES or NO is sufficient. or you can just ignore this question. Thanks again. Regards, Jeon. You either calibrate, or you have a very precise model of effective gains and losses throughout the entire signal-processing chain from antenna to flow-graph, for every possible hardware combination, including variable parameters like frequency, gain settings, bandwidth, etc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] file source with gr-ieee802.11 tx
The transceiver wraps your payload in some headers that add stuff like MAC address, frame type, and CRC. These are the minimum fields that are required so that a WiFi card actually accepts the frame. Makes sense. I knew about the headers and CRC, but I wasn't even thinking about it being used with an actual WiFi device (as opposed to two USRPs). There is currently no option to dump raw bytes, but its a trivial modification of the Wireshark block (dump without a PCAP header). This sounds reasonable to me, but so far I have been unsuccesful. I am attempting to edit wireshark_connector_impl.cc, but none of my mods have worked so far. I am not looking for you to do the work, but I wanted to make sure I am looking at the right file. One of my concerns with it is that my C++ is really rusty and I haven't played with the low-level GR stuff before, so I am muddling through what is going on in that file. Near the end of the file is the following: int to_copy = std::min((d_msg_len - d_msg_offset), noutput); memcpy(out, d_msg + d_msg_offset, to_copy); I believe that that second line is where the information is put on the output buffer. So for a test, I changed the memcpy to be: memcpy(out, d_msg + d_msg_offset + 10, to_copy - 10); to basically cut off the first 10B (just a quick and dirty test). I then run: sudo make uninstall make clean make sudo make install sudo ldconfig from the gr-foo/build directory. It builds fine, but when I run my GRC script, the output to a file sink (for simplicity I am dumping to a file instead of UDP for now), doesn't change its length. I did reload blocks in GRC too. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues with OOT
Marius, hard to say from this info. However, did you go through http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials to learn how to write blocks? Those tutorials usually explain the most common pitfalls. Cheers, M On 31.07.2015 08:04, Marius Cachelin wrote: Hi everyone, I am writing here because I have some issues using an OOT module. Actually, I have gnuradio installed on my desktop. I want to install gnuradio on other laptop so that I can use 2 USRP. So, I followed the steps described here *http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource*;, where I used the *build-gnuradio* script. (I have already used this script to install gnuradio on my desktop). - I created a new folder, named gnuradio in /opt. - I then run *cd /opt/gnuradio *and*wget http://www.sbrac.org/files/build-gnuradio chmod a+x ./build-gnuradio ./build-gnuradio *. After a while, all the process is done. - I followed all steps presented in *http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig*, to create a new OOT module. But, In GRC, when I want to use my new OOT module, I get this error : *-- Traceback (most recent call last): File /home/sagem/Bureau/top_block.py, line 140, in module tb = top_block() File /home/sagem/Bureau/top_block.py, line 65, in __init__ self.test_block_test_0 = test.block_test() AttributeError: 'module' object has no attribute 'block_test' * My block, named block_test, do nothing. It just copy all inputs items into output buffer. I read some discusses about this error, but I can't understand why I get it. I checked all my *CMakelist.txt*, and all is good. I run *make test*, and all test passed. If someone could help me to figure this out, It would be very helpfull. Marius *CACHELIN Marius* /Ingénieur Systèmes, Réseaux et Télécommunications/ marius.cache...@gmail.com mailto:marius.cache...@gmail.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] file source with gr-ieee802.11 tx
It builds fine, but when I run my GRC script, the output to a file sink (for simplicity I am dumping to a file instead of UDP for now), doesn't change its length. I did reload blocks in GRC too. I need to do more testing, but I think I have my bug. I needed to decrement the return variable to_copy. I'll report in if I get something more complete working. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
Yes, blocks is included in the cmakelists.txt as set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS) as well as a link directory GNURADIO_BLOCKS_LIBRARY_DIRS. Its also in the /lib cmakelists.txt as a target_link_library GNURADIO_BLOCKS_LIBRARIES. BLOCKS_API was not in the swig .i file. I added this, ran make clean, make, and installed and still get the same error. From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 11:02 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Fri, Jul 31, 2015 at 10:50 AM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: So the function (set_unbuffered) that’s coming up as not being found is in file_sink_base.h which is included in the file_sink.h so I’m pretty sure I’m ok here. The swig file just includes file_sink.h….I tried adding file_sink_base.h to this as well, but it didn’t change anything. For the time being, I’m replicating the file_sink block exactly (except the name) to try and get it to compile OOT. However, since file_sink depends on file_sink_base, which I’m not copying, I think there are problems linking to it. Would it be better to also copy file_sink_base to my OOT module? You should be able to use file_sink_base from libgnuradio-blocks.so, so no, keep that one in tree so you're not carrying around extra stuff. First, do you have BLOCKS as one of the GNU Radio required components in your CMakeLists.txt file? Also, and I suspect this might be the real problem, do you #define BLOCKS_API in you .i file? There should be a #define for your module's name already; just add this line here along with that one. Tom From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.commailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 10:27 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h -- actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind when we see this is that you haven't added all of the public functions of your block to the public header file (file_sink.h), but you say that's identical. Still probably worth checking on that file to make sure. Have you looked at your swig directory's .i file? That needs to properly reference your block to export it into Python. It seems like this is ok since you're getting as far as to see the error on the method, not the block. Again, though, something to check. So this is just you replicating the file sink blocks completely? You aren't trying to inherit from them or use them internally, are you? That might cause other issues. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About physcially acceptable, applicable signal input range for GNU Radio.
Dear all of you helping me, Marcus, Tom and Marcus Thanks for all of your answers. I've successfully receive frames and decode it. There are some physical and practical issues and glitches that I haven't thought about when writing source codes. But it's not what should be handled in this thread. I will let you know when I finish implementing GNU Radio OOT module and analog circuit front end, if there are someone interested in. :) One small question is, is there no way to guess a value of voltage, given that ADC sampled value? I think it's quite impossible to guess both values of DC component and AC component. It's because time sink figure in the original post,there's no DC component, but I fed a DC biased signal into the LFRX. At least for AC component, however, I think it is possible to guess... If we know ADC resolution, impedance (of course 50 ohms) and so... It's just curiosity. I'm not going to use such things right now. So if it is hard to tell in short time, YES or NO is sufficient. or you can just ignore this question. Thanks again. Regards, Jeon. 2015-07-30 23:40 GMT+09:00 mle...@ripnet.com: Jeon: Gnu Radio, per se, knows nothing of voltage. It just sees digital samples as delivered by the hardware. What those samples mean in terms of voltage amplitude as delivered to the antenna port is completely opaque to Gnu Radio. The LFRX will easily tolerate an input signal with a voltage swing up to +/- 1V. You would have to see what amplitude, in terms of floating-point, is produced in your flow-graph. On 2015-07-30 01:37, Jeon wrote: I am building a communication system which uses light. For the system, I've buiult a custom analog circuit and connected it to LFRX with SMA-BNC-Alligator clip. A simple dry run gives the following: As you can see, data is transmitted with on off keying. (Please ignore some ripples and fluctuation, it's due to 60 Hz fluorscent light interference. I'll fix it later.) I wonder that such input range (+- 50 mV) is quite acceptable for GNU Radio to manipulate. Since it's my first time to physically implement a communication system, I only have mathematical and theoretical knowledge, but have little experience and sense about dBm, rx sensitivity and so. But as I can see the waveform not so bad, I think I can manipulate it by equalizing or something... PS: In addition, that 60 Hz interference, would it be better if I filter out that at the analog circuit with high pass filter? Or is it just ok to use high pass filter block in GNU Radio. I think the former is better to reduce the computational cost of GNU Radio. And it is more proper to filter out before it passes through the ADC... Regards, Jeon. ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] Issues with OOT
Hi everyone, I am writing here because I have some issues using an OOT module. Actually, I have gnuradio installed on my desktop. I want to install gnuradio on other laptop so that I can use 2 USRP. So, I followed the steps described here *http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource*, where I used the *build-gnuradio* script. (I have already used this script to install gnuradio on my desktop). - I created a new folder, named gnuradio in /opt. - I then run *cd /opt/gnuradio *and* wget http://www.sbrac.org/files/build-gnuradio http://www.sbrac.org/files/build-gnuradio chmod a+x ./build-gnuradio ./build-gnuradio *. After a while, all the process is done. - I followed all steps presented in *http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig*, to create a new OOT module. But, In GRC, when I want to use my new OOT module, I get this error : *-- Traceback (most recent call last): File /home/sagem/Bureau/top_block.py, line 140, in moduletb = top_block() File /home/sagem/Bureau/top_block.py, line 65, in __init__self.test_block_test_0 = test.block_test()AttributeError: 'module' object has no attribute 'block_test'* My block, named block_test, do nothing. It just copy all inputs items into output buffer. I read some discusses about this error, but I can't understand why I get it. I checked all my *CMakelist.txt*, and all is good. I run *make test*, and all test passed. If someone could help me to figure this out, It would be very helpfull. Marius *CACHELIN Marius* *Ingénieur Systèmes, Réseaux et Télécommunications* marius.cache...@gmail.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SOCIS project update 9
Johannes, you forgot to mention you will presenting your stuff at GRCon in Washington DC in a few weeks :) Cheers, Martin On 31.07.2015 02:50, Johannes Demel wrote: Hey community! Here we go again. Another project update. I'm working with VOLK and SIMD for two weeks now. I could fix some hiccups with last weeks pack and unpack kernels. They run just fine during test now. Also, I added a 'volk_8u_x3_encodepolar_8u_x2' kernel. It operates on the the assumption that there is one active bit in a byte and it is located in the LSB. A quick performance test with a 2^32 samples head block after the encoder shows that generic crunches ~160MSps. So far I had an encoder which operated on packed bytes and did ~300MSps. An unpack block was added to the flowgraph with the 'extended_encoder' in use. The vector optimized version does ~570MSps. So it is ~3.5x as fast as the generic version. Some more optimization might yield even better results. At first glance it is weird that the output signature of the encoder is '8u_x2'. The kernel internally needs a temporary buffer which has the same size as the output buffer. Instead of malloc'ing and free'ing it on every call, it can be created once and be used all the time. During the week I was struggling with VOLK tests. Finally I solved those issues. But I'd like to refer to the mail I sent out the other day. SIMD code tends to have quite a few lines of code. In order to make it easier to read and understand, it would be great if it was possible to implement multiple functions within one '#ifdef LV_HAVE_ARCH ... #endif' paragraph. But so far the compiler refuses to compile if I did this. It is possible to add functions in the general section but that's only appropriate for a generic kernel or common functions. All the intrinsics I used so far are available on SSSE3. Although, I created aligned and unaligned versions of those kernels only store[u] and load[u] might make a difference here. My benchmarks don't show any significant difference. All benchmarks are done on a Sandy Bridge i7. I suspect the encoder was easier to optimize than the decoder will be. So for the upcoming week and beyond I will focus on creating kernels for polar decoding. More info and current project progress can be found in [1], [2] and [3]. Cheers Johannes [1] https://github.com/jdemel/gnuradio [2] https://github.com/jdemel/socis-proposal [3] https://github.com/jdemel/volk ___ 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] Building an OOT modules with an In Tree Dependency
So the function (set_unbuffered) that’s coming up as not being found is in file_sink_base.h which is included in the file_sink.h so I’m pretty sure I’m ok here. The swig file just includes file_sink.h….I tried adding file_sink_base.h to this as well, but it didn’t change anything. For the time being, I’m replicating the file_sink block exactly (except the name) to try and get it to compile OOT. However, since file_sink depends on file_sink_base, which I’m not copying, I think there are problems linking to it. Would it be better to also copy file_sink_base to my OOT module? From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 10:27 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h -- actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind when we see this is that you haven't added all of the public functions of your block to the public header file (file_sink.h), but you say that's identical. Still probably worth checking on that file to make sure. Have you looked at your swig directory's .i file? That needs to properly reference your block to export it into Python. It seems like this is ok since you're getting as far as to see the error on the method, not the block. Again, though, something to check. So this is just you replicating the file sink blocks completely? You aren't trying to inherit from them or use them internally, are you? That might cause other issues. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Clock Recovery MM documentation
Hi Tom,
why do/I/ have to advertise the PFB approach? Arguing against Mueller
Müller feels strange. Anyway:
Mueller Müller in the classical, real valued approach [1, eq (49), p.
524] in its core is
eqn. (49) page 524
with $z_k$ being the timing estimate ,$x_k$ being the input samples, and
$a_k$ the decisions (in our case, -1/+1 [2], so $E\{a_k^2\}\equiv 1$).
Assume timing is correct, ie. $z_{k-1} = 0$, but we have fading so that
$|x_k| = \epsilon |x_{k-1}|,\quad 0\epsilon \ll 1$;
then regardless of $a_{k-1}$, the term $|x_k a_{k-1}| \ll|x_{k-1}a_k|$,
and hence
$z_k \approx -\frac12 {x_{k-1}a_k}$
Now, $a_k$ is exactly the decision we don't want to put much trust in,
because it's a symbol decision with especially bad $\frac{E_s}{N_0}$.
Effectively, you get the bit error probability increase as a factor to
your timing error probability density, as if things weren't bad enough!
PFB is cooler because
1. PFB!
2. the derivate is a linear operation, so amplitude changes in the
input signal at least have the same effect on the error correction
magnitude.
Cheers,
Marcus
[1] http://2n3904.net/library/MM_Clock_Recovery.pdf
[2]
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L83
On 31.07.2015 01:06, Tom Rondeau wrote:
On Thu, Jul 30, 2015 at 3:03 PM, Iluta V iluta2...@gmail.com
mailto:iluta2...@gmail.com wrote:
Hi, Tom,
Could you be more specific where exactly it is not the right
algorithm? We'd appreciate that and would correct that in own
work as well, if Security Research Assessment made a mistake here.
I will be looking forward to your response,
Iluta
Iluta,
I shouldn't be so hard on the MM block. In most situations, it's
tended to work fine, but it's suboptimal. It's based on hardware
techniques of clock recovery that approximate a derivative. The PFB
algorithm actually calculates the derivative to the numerical
approximation required by setting the number of filterbank arms. So
the results are much better. You also get to apply your own filter to
this block so you don't have to apply a separate matched filter.
Also, and I can't find any papers on this, but fred harris tells me
that the MM algorithm behaves particularly poorly in fading environments.
Tom
On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondeau t...@trondeau.com
mailto:t...@trondeau.com wrote:
On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com
mailto:iluta2...@gmail.com wrote:
Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS
(Examination of Using GNU Radio Companion for Security
Research and Assessment) deals with Clock Recovery MM, I
attached the paper, have a look at:
6.Section 6.Counting the Bits
7.Analyzing Demodulated Data
Both deal with Clock Recovery MM usage and has flowgraphs.
Best regards,
Iluta
That's great, and I'm glad they got it to work for their
application. Looks like they provide a good explanation of its
use, too. Still, it's not the right algorithm.
Tom
On Thu, Jul 30, 2015 at 9:23 PM, Tom Rondeau
t...@trondeau.com mailto:t...@trondeau.com wrote:
Another point to keep in mind is that the MM block
isn't great in fading environments. It's really
suboptimal in general. Look at the pfb_clock_recovery
block, instead.
Tom
On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara
danielcam...@gmail.com
mailto:danielcam...@gmail.com wrote:
Hi Klauss,
You could also take a look at
https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/
https://www.tablix.org/%7Eavian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
it helped me quite a bit!
Best regards...
Daniel
On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun
martin.br...@ettus.com
mailto:martin.br...@ettus.com wrote:
Klaus,
the manual page for this block has a paper
reference in it:
http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details
M
On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
Hello,
I would like to find a proper documentation
on MM algorithm block (paper
for example). Any ideas ?
Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
On Fri, Jul 31, 2015 at 1:52 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edu wrote: Ah, so I figured it out. Not only did I need to add #define BLOCKS_API to my swig .i file, but I also had to add %include “gnuradio/blocks/file_sink_base.h” as well. Ah, of course! Good catch. We should have this documented somewhere -- how to use GNU Radio classes and blocks in OOT projects. Tom *From:* Valenta, Chris R. *Sent:* Friday, July 31, 2015 11:30 AM *To:* 'Tom Rondeau' *Cc:* discuss-gnuradio@gnu.org *Subject:* RE: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency Yes, blocks is included in the cmakelists.txt as set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS) as well as a link directory GNURADIO_BLOCKS_LIBRARY_DIRS. Its also in the /lib cmakelists.txt as a target_link_library GNURADIO_BLOCKS_LIBRARIES. BLOCKS_API was not in the swig .i file. I added this, ran make clean, make, and installed and still get the same error. *From:* trond...@trondeau.com [mailto:trond...@trondeau.com trond...@trondeau.com] *On Behalf Of *Tom Rondeau *Sent:* Friday, July 31, 2015 11:02 AM *To:* Valenta, Chris R. *Cc:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Fri, Jul 31, 2015 at 10:50 AM, Valenta, Chris R. chris.vale...@gtri.gatech.edu wrote: So the function (set_unbuffered) that’s coming up as not being found is in file_sink_base.h which is included in the file_sink.h so I’m pretty sure I’m ok here. The swig file just includes file_sink.h….I tried adding file_sink_base.h to this as well, but it didn’t change anything. For the time being, I’m replicating the file_sink block exactly (except the name) to try and get it to compile OOT. However, since file_sink depends on file_sink_base, which I’m not copying, I think there are problems linking to it. Would it be better to also copy file_sink_base to my OOT module? You should be able to use file_sink_base from libgnuradio-blocks.so, so no, keep that one in tree so you're not carrying around extra stuff. First, do you have BLOCKS as one of the GNU Radio required components in your CMakeLists.txt file? Also, and I suspect this might be the real problem, do you #define BLOCKS_API in you .i file? There should be a #define for your module's name already; just add this line here along with that one. Tom *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf Of *Tom Rondeau *Sent:* Friday, July 31, 2015 10:27 AM *To:* Valenta, Chris R. *Cc:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h à actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind when we see this is that you haven't added all of the public functions of your block to the public header file (file_sink.h), but you say that's identical. Still probably worth checking on that file to make sure. Have you looked at your swig directory's .i file? That needs to properly reference your block to export it into Python. It seems like this is ok since you're getting as far as to see the error on the method, not the block. Again, though, something to check. So this is just you replicating the file sink blocks completely? You aren't trying to inherit from them or use them internally, are you? That might cause other issues. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
Ah, so I figured it out. Not only did I need to add #define BLOCKS_API to my swig .i file, but I also had to add %include “gnuradio/blocks/file_sink_base.h” as well. From: Valenta, Chris R. Sent: Friday, July 31, 2015 11:30 AM To: 'Tom Rondeau' Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency Yes, blocks is included in the cmakelists.txt as set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS) as well as a link directory GNURADIO_BLOCKS_LIBRARY_DIRS. Its also in the /lib cmakelists.txt as a target_link_library GNURADIO_BLOCKS_LIBRARIES. BLOCKS_API was not in the swig .i file. I added this, ran make clean, make, and installed and still get the same error. From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 11:02 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Fri, Jul 31, 2015 at 10:50 AM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: So the function (set_unbuffered) that’s coming up as not being found is in file_sink_base.h which is included in the file_sink.h so I’m pretty sure I’m ok here. The swig file just includes file_sink.h….I tried adding file_sink_base.h to this as well, but it didn’t change anything. For the time being, I’m replicating the file_sink block exactly (except the name) to try and get it to compile OOT. However, since file_sink depends on file_sink_base, which I’m not copying, I think there are problems linking to it. Would it be better to also copy file_sink_base to my OOT module? You should be able to use file_sink_base from libgnuradio-blocks.so, so no, keep that one in tree so you're not carrying around extra stuff. First, do you have BLOCKS as one of the GNU Radio required components in your CMakeLists.txt file? Also, and I suspect this might be the real problem, do you #define BLOCKS_API in you .i file? There should be a #define for your module's name already; just add this line here along with that one. Tom From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.commailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 10:27 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h -- actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind when we see this is that you haven't added all of the public functions of your block to the public header file (file_sink.h), but you say that's identical. Still probably worth checking on that file to make sure. Have you looked at your swig directory's .i file? That needs to properly reference your block to export it into Python. It seems like this is ok since you're getting as far as to see the error on the method, not the block. Again, though, something to check. So this is just you replicating the file sink blocks completely? You aren't trying to inherit from them or use them internally, are you? That might cause other issues. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] file source with gr-ieee802.11 tx
OK, great. If you don’t care about WiFi I would recommend to test the OFDM transceiver in gr-digital that ships with GNU Radio. Best, Bastian On 31 Jul 2015, at 18:55, Jason Matusiak ja...@gardettoengineering.com wrote: It builds fine, but when I run my GRC script, the output to a file sink (for simplicity I am dumping to a file instead of UDP for now), doesn't change its length. I did reload blocks in GRC too. I need to do more testing, but I think I have my bug. I needed to decrement the return variable to_copy. I'll report in if I get something more complete working. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error during Install my_qpsk_demod in grc
Hi Surjeet, I hate to become *that guy*, but could you please directly sign up to the mailing list with your email address, and send emails rather than going through ruby-forum? https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Signing up really takes a few seconds, and we have had it more than once that people asking interesting questions got good answers, but missed them, because ruby-forum didn't show them in the same thread. Best regards, Marcus On 31.07.2015 16:19, Tom Rondeau wrote: On Fri, Jul 31, 2015 at 5:33 AM, Surjeet Rawat li...@ruby-forum.com mailto:li...@ruby-forum.com wrote: please give some suggestion related to this error Attachments: http://www.ruby-forum.com/attachment/10928/Screenshot_from_2015-07-31_13_16_57.png -- Posted via http://www.ruby-forum.com/. Can you explain how you got there? Also, please just paste the text instead of sending a png. It's likely to live longer in the archives this way. Tom ___ 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] Clock Recovery MM documentation
Hi Klauss, is it new ? Not really, no. It's been around since ca April 2012. If there's no Polyphase Clock Sync: What version of GNU Radio are you using? Best regards, Marcus PS: I always recommend not using ruby-forum but directly signing up to the mailing list: https://lists.gnu.org/mailman/listinfo/discuss-gnuradio so much more comfortable! And with modern mail clients and webmail interfaces, much better searchable. On 31.07.2015 21:28, Klauss Wolfeinstein wrote: Wow ! Thank you all for your reply. Very interesting ! Tom, I didn't find the pfb_clock_recovery block in my GNU Radio Companion, is it new ? Best regards. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Clock Recovery MM documentation
Wow ! Thank you all for your reply. Very interesting ! Tom, I didn't find the pfb_clock_recovery block in my GNU Radio Companion, is it new ? Best regards. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Clock Recovery MM documentation
Hi Marcus, A it's the Polyphase Clock Sync, I didn't think about it ... :-D Thank you for the advice, I will use the mailing list next time. Best regards. Klauss. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Does any source block support Signalhound BB60C ?
Hi Patrick, This was just raised on the Signal Hound Facebook page. They were proposing to introduce support for the BB60C to HDSDR and I suggested GNU Radio in the comments. https://www.facebook.com/groups/148252868548830/ Regards, Derek ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
If we don’t just document with comments in the proper places in the OOT structure, I was thinking we could have the user list GR required components in the gr_modtool interactive configuration. It wouldn’t solve all problems like the file_sink_base issue, but it would be a good start. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 1:57 PM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Fri, Jul 31, 2015 at 1:52 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: Ah, so I figured it out. Not only did I need to add #define BLOCKS_API to my swig .i file, but I also had to add %include “gnuradio/blocks/file_sink_base.h” as well. Ah, of course! Good catch. We should have this documented somewhere -- how to use GNU Radio classes and blocks in OOT projects. Tom From: Valenta, Chris R. Sent: Friday, July 31, 2015 11:30 AM To: 'Tom Rondeau' Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency Yes, blocks is included in the cmakelists.txt as set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS) as well as a link directory GNURADIO_BLOCKS_LIBRARY_DIRS. Its also in the /lib cmakelists.txt as a target_link_library GNURADIO_BLOCKS_LIBRARIES. BLOCKS_API was not in the swig .i file. I added this, ran make clean, make, and installed and still get the same error. From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 11:02 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Fri, Jul 31, 2015 at 10:50 AM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: So the function (set_unbuffered) that’s coming up as not being found is in file_sink_base.h which is included in the file_sink.h so I’m pretty sure I’m ok here. The swig file just includes file_sink.h….I tried adding file_sink_base.h to this as well, but it didn’t change anything. For the time being, I’m replicating the file_sink block exactly (except the name) to try and get it to compile OOT. However, since file_sink depends on file_sink_base, which I’m not copying, I think there are problems linking to it. Would it be better to also copy file_sink_base to my OOT module? You should be able to use file_sink_base from libgnuradio-blocks.so, so no, keep that one in tree so you're not carrying around extra stuff. First, do you have BLOCKS as one of the GNU Radio required components in your CMakeLists.txt file? Also, and I suspect this might be the real problem, do you #define BLOCKS_API in you .i file? There should be a #define for your module's name already; just add this line here along with that one. Tom From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.commailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 10:27 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h -- actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind
Re: [Discuss-gnuradio] isolate channels from wideband
OK, I have a mostly working flowgraph and am now adding comment to all the blocks explaining why I'm doing this or that. Will publish tonight or tomorrow. On Tue, Jul 21, 2015 at 11:56 AM, Chris Kuethe chris.kue...@gmail.com wrote: Maybe I'll do up an illustrated example on this using NOAA weather radio, or the pager band On Tue, Jul 21, 2015 at 11:42 AM, mle...@ripnet.com wrote: I just use the built-in firdes stuff, rather than using an external designer. On 2015-07-21 14:38, Marcus Müller wrote: Hi Rich, hello Markus, On 21.07.2015 19:51, Richard Bell wrote: GNU Radio has channelizers built-in, but I've not used them yet, so I don't know how far they take you into this kind of task. the Polyphase channelizer is actually an implementation derived from that school of thought, and it works amazingly well. In fact, in preparation of a presentation at a certain ham conference, I tried using it to get 20 PMR/LPD channels out of a 1MS/s signal in real time, and then just shuffle them around, before feeding them back into the inverse synthesizer PFB. It's pretty easy: Design a single low pass filter, as if you just wanted to filter out the channel which is centered exactly at your RF center frequency, i.e. 0Hz, with the full sampling rate [2], using the gr_filter_design tool. Play around with the different window types[1], and bear in mind that the suppression outside your desired passband needs to be high enough so that the sum of the energy in all other channels don't hurt your channel too much, but don't overdo it (60dB suppression should be enough). Now you get a long filter. Copy and paste the filter coefficients from gr_filter_design to your PFB filter taps property. Set your channelizers number of channels according to your plans -- 40, if you want to get all the 40 25kHz channels in 2MHz. You get a block with 40 outputs! Explaining things like channel mapping is best done by pointing you at the official documentation: [3] Greetings! Marcus [1] Hamming is not always the best choice, I'd try that, Blackman-harris, and Kaiser. I personally like harris in this case -- we want to get a full channel, two adjacent channels are usually not occupied, and as soon as we pass the stopband frequency, we're basically at -100dB. [2] assuming you want to use 2MS/s for your 2MHz wide band, 2MHz sampling rate, and assuming 25kHz wide channels, 12.5kHz cut off frequency, 25kHz start of stoppband. I get something like 440 taps. [3] https://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1pfb__channelizer__ccf.html ___ 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 -- GDB has a 'break' feature; why doesn't it have 'fix' too? -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error during Install my_qpsk_demod in grc
please give some suggestion related to this error Attachments: http://www.ruby-forum.com/attachment/10928/Screenshot_from_2015-07-31_13_16_57.png -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SOCIS project update 9
Hey community! Here we go again. Another project update. I'm working with VOLK and SIMD for two weeks now. I could fix some hiccups with last weeks pack and unpack kernels. They run just fine during test now. Also, I added a 'volk_8u_x3_encodepolar_8u_x2' kernel. It operates on the the assumption that there is one active bit in a byte and it is located in the LSB. A quick performance test with a 2^32 samples head block after the encoder shows that generic crunches ~160MSps. So far I had an encoder which operated on packed bytes and did ~300MSps. An unpack block was added to the flowgraph with the 'extended_encoder' in use. The vector optimized version does ~570MSps. So it is ~3.5x as fast as the generic version. Some more optimization might yield even better results. At first glance it is weird that the output signature of the encoder is '8u_x2'. The kernel internally needs a temporary buffer which has the same size as the output buffer. Instead of malloc'ing and free'ing it on every call, it can be created once and be used all the time. During the week I was struggling with VOLK tests. Finally I solved those issues. But I'd like to refer to the mail I sent out the other day. SIMD code tends to have quite a few lines of code. In order to make it easier to read and understand, it would be great if it was possible to implement multiple functions within one '#ifdef LV_HAVE_ARCH ... #endif' paragraph. But so far the compiler refuses to compile if I did this. It is possible to add functions in the general section but that's only appropriate for a generic kernel or common functions. All the intrinsics I used so far are available on SSSE3. Although, I created aligned and unaligned versions of those kernels only store[u] and load[u] might make a difference here. My benchmarks don't show any significant difference. All benchmarks are done on a Sandy Bridge i7. I suspect the encoder was easier to optimize than the decoder will be. So for the upcoming week and beyond I will focus on creating kernels for polar decoding. More info and current project progress can be found in [1], [2] and [3]. Cheers Johannes [1] https://github.com/jdemel/gnuradio [2] https://github.com/jdemel/socis-proposal [3] https://github.com/jdemel/volk ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
