Re: [Discuss-gnuradio] Multiple Versions of Libraries / Virtualenv (was: Re: PYBOMBs Testing)
Thanks, Marcus. It seemed too good to be true ;) Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 1:20 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dan, no, Virtualenv is virtualenv is a tool to create isolated Python environments. only. For unix systems, having multiple versions of the same library is not a problem by itself, especially since there are several environment variables that control the behaviour of the dynamic run time linker. A nice method to employ this is described in http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Experts-only-How-can-I-deliberately-install-GNU-Radio-multiple-times-different-versions ; just install your application specific libraries, headers etc into ~/.usrlocal. Also, if you need to capsulate your system more thoroughly, consider using chroot; although this has become less popular over the last few years due to the fact that virtualization has become so easy. Hope that was a little insightful. If someone comes up with something interesting on this topic, a new thread should be started; although I consider this problem to be of a typical linux distribution concern, and not very much specific to GR. Greetings, Marcus On 10.01.2014 16:45, Dan CaJacob wrote: Thanks, Tom! Digression warning: While we're on the topic, I've always wondered if virtualenv would help with build dependency problems and multiple installed versions (e.g. for devs). I have never immersed myself into the tool, but I know that it is intended for things like this where you want to install specific package versions for a specific application without affecting other things on your system. It's a sandbox, I guess. What I've never been clear on is whether it works for C/C++ applications, since it seems to be a python tool. Do you have any thoughts on that? Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 10:14 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Thanks. I didn't know how or what to search for, so that was useful. Here's the result: i libzeroc-ice34 - Ice for C++ runtime library That there confirms that the Ice 3.4.2 library is installed on your system, which is what I was expecting. Here's what I found in the gnuradio CMakeCache.txt file: ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so //Path to a library. ICE_ICE:FILEPATH=/usr/lib/libIce.so //Path to a library. ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so //Path to a library. ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so //Path to a library. ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so //Path to a file. ICE_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so //Path to a program. ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp //Path to a program. ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py //Details about finding ICE FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()] Very Respectfully, Dan CaJacob And that tells us that GNU Radio is trying to build using the Ice libs in /usr/lib, which is where apt-get would have installed ICE, so yeah, it's trying to build off Ice 3.4.2. You could solve this pretty easily by doing an aptitude remove libzeroc-ice to get rid of Ice 3.4.2 altogether on your system. But I'm more interested in solving this issue in general. I've brought up a VM that has this behavior. Let me see about working out a solution. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0Dn7AAoJEAFxB7BbsDrLEOwH/RTC+kW1/vgQ6NQxaoTDYFTv vxz9B5PbOxocH9/dnINdqtctJw63f/gfIqwUzZK2uuZOJKR1HYbbeIm6diheOexU B+KVgGDyMbcCIw2Xioo+B/Gr8b7sQPZjOnJNztg1Se1wpOLPtCcwP6fTv9j6xZog olcyQ1cxezRikja/DX/E52DxJ/fVgDawMoR+KoMQOQ4SvL98KiTuD/X6vRuc2TOz xt81GwAs6LJh8HVr+kMBXFq1UaN3WxrMPHXtg/db0uxWZXgvKoQYLv6fpCMb+9BZ eAXgzDkh1SXyaB9K6G6Q6qTO95el6W/VRDgbRyUC8SvP4IN72i4R+jhG6cwwCKg= =M0JC -END PGP SIGNATURE- ___ 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] make test failure at qa_constellation_receiver
On Mon, Jan 6, 2014 at 4:23 PM, ibmsorcerer bruce...@yahoo.com wrote: Tom, I believe that I'm running the version that comes with SuSE 11 and updated to SP3. v 1.36.0-12.3.1. I'm using it, because I thought that the easy installation of many of the necessary libraries/tools might make it convenient and easier to build gnu-radio. All of the others worked fine, after I exclude the test for qa_constellation_receiver. 100% tests passed, 0 tests failed out of 175 After the test failure, I've not done anything further, because I didn't think I could. Bruce That seems strange that you're using Boost 1.36; that version is quite old. But I think that's correct. It looks like OpenSuse is using boost 1.53. We build against Boost 1.35; that's the minimum version we support. On the other hand, it's probably been a while since anyone's tried to run against a version that old. I know most people who use distros with older packages, like CentOS/Redhat, tend to hand-install a version of Boost that's much newer. Having said that, we say we build and run against Boost 1.35, so until we produce a new version, we should still. I'll have to see if I can install and test against that and verify that that's the problem. Tom *From:* Tom Rondeau-2 [via GnuRadio] [hidden email]http://user/SendEmail.jtp?type=nodenode=45611i=0 *To:* ibmsorcerer [hidden email]http://user/SendEmail.jtp?type=nodenode=45611i=1 *Sent:* Monday, January 6, 2014 9:49 AM *Subject:* Re: make test failure at qa_constellation_receiver On Sat, Jan 4, 2014 at 9:27 PM, ibmsorcerer [hidden email] wrote: I built gnuradio 3.7.2.1 from scratch on a SuSE Linux Enterprise Server 11 with SP3 running as a VM. I ran into this problem with the constellation_receiver test. bruce@gnuradio:~/gnuradio-3.7.2.1/build ctest -V -R constellation_receiver142 UpdateCTestConfiguration from :/home/bruce/gnuradio-3.7.2.1/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/bruce/gnuradio-3.7.2.1/build/DartConfiguration.tcl Test project /home/bruce/gnuradio-3.7.2.1/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 142 Start 142: qa_constellation_receiver 142: Test command: /usr/bin/sh /home/bruce/gnuradio-3.7.2.1/build/gr-digital/python/digital/qa_constellation_receiver_test.sh 142: Test timeout computed to be: 9.99988e+06 142: Using Volk machine: sse4_a_64 142: thread[thread-per-block[1]: block constellation_receiver_cb (477)]: boost::bad_any_cast: failed conversion using boost::any_cast If I try to run the complete test set, it never finishes. I've left it running for more than an hour.. Bruce Bruce, what version of Boost are you using? Do any other tests throw out that boost::bad_any_cast failure but complete anyways? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Successful installation of GNURadio 3.6.4.1 on Window XP and Windows 8
On 01/10/2014 09:49 AM, Bhaskar11 wrote: Hi Tom, Thanks for the suggestion! I have updated the wiki by adding a link to the email thread. :) But I wonder if it it appropriate to include the instructions directly in the wiki? I will be happy to do it and update it as and when I have anything to add. I just need to know if there is are guidelines for this sort of thing, or whether I can ask someone who oversees the overall wiki content. Bhaskar, just go ahead. There's no real rules, and after all, you're the one who's putting in the content, so you get some creative freedom. We always are happy about new people contributing to the wiki! Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Successful installation of GNURadio 3.6.4.1 on Window XP and Windows 8
On Fri, Jan 10, 2014 at 3:49 AM, Bhaskar11 niceguy...@gmail.com wrote: Hi Tom, Thanks for the suggestion! I have updated the wiki by adding a link to the email thread. :) Great, thanks! But I wonder if it it appropriate to include the instructions directly in the wiki? I will be happy to do it and update it as and when I have anything to add. I just need to know if there is are guidelines for this sort of thing, or whether I can ask someone who oversees the overall wiki content. B Yes, I think having the build instructions as part of the wiki is a good idea. I was thinking of doing so with your email, but because of my lack of Windows foo, I thought it safer just to point to the email thread. The only guidelines we have with the wiki is to keep is clean and clear. That might mean making a new page with your set of instructions. That would also help because your new page could be specifically tied to a version of Windows and GNU Radio that successfully worked as opposed to claiming complete generic compatibility. Thanks! Tom On Thu, Jan 9, 2014 at 10:10 PM, Tom Rondeau t...@trondeau.com wrote: On Mon, Jan 6, 2014 at 9:19 AM, Bhaskar11 niceguy...@gmail.com wrote: Hi Tom, 1. Thanks for adding the link in the WindowsInstall wiki. I note that the link has been added in the section on Building on Windows with Native Tools where it is surely relevant for the dependencies that I discovered. But my instructions are intended for installing with pre-built binaries, and are mainly aimed at users who are *not* able to build natively, and so would never look under that section. For such users it will be very useful if you can add a link in the Pre-built Binaries section right where the link to the Ettus Research site is made. It can be added as an update or a caveat to the Ettus instructions link. 2. As an addendum to my main post, I have found that only one UHD driver works correctly with GRC 3.6.4.1. under Windows XP and Windows 8. And that is version 3.5.0 (file name uhd_003.005.000-release_Win32) available from here. I will share a more detailed update on the UHD driver compatibility and error messages in a separate post. But I have included this info here for completeness of this thread. B Bhaskar, Once again, thanks for your help. With the gnuradio.org wiki, you know, anyone can get an account and edit the wiki, so with someone like you who's actually been through this process, it'd be great if you could make these changes yourself to help keep us all honest and up to date! Thanks! Tom On Mon, Dec 30, 2013 at 9:29 PM, Tom Rondeau t...@trondeau.com wrote: Bhaskar, Thanks for your effort on not only getting GNU Radio working on Windows but also providing us with the steps you took to get there. That could be really helpful to a lot of people. I have made a link on our WindowsInstall wiki to point to your email for other people looking for help. Please note, though, that we've tried to make it very clear that Windows is not a fully supported OS. None of the core developers can really test and build on Windows, and we rely on patches and feedback like you've provided from the community. We do our best to keep things working cross-platform, but as you've experienced, as versions change (both GNU Radio and it's dependencies), this is a serious project. Tom On Thu, Dec 26, 2013 at 11:10 AM, Bhaskar11 niceguy...@gmail.com wrote: After much experimentation I have finally found a way to successfully install and fully run GRC 3.6.4.1 both under Windows XP and Windows 8. I presume it should therefore work equally well under Vista and 7. First a few comments on the common causes of problems that most people have had: a. It is critical to have the correct *matching* and *complete* versions of the various required libraries. Most installations instructions online fail because of this reason. The Ettus installation instructions officially recommended on GNURadio website and provided here fail now because many of the original binary versions referred to are no longer available. Hence those instructions are now outdated and should be replaced by the instructions provided in this email. b. Although it is possible to successfully install GNURadio binaries for versions 3.7.x, none of them include runtime DLLs for WX GUI blocks. Hence these blocks are not displayed, and so most of the example files available cannot be used as they need WX GUI blocks. Moreover, some of the QT GUI blocks do not work in certain versions. Since I do not know how to make these binaries, I request those who have created these version 3.7.x Windows binaries to repack them so that we can run the latest versions of GNURadio in Windows. Until that is done, there is no point trying to
Re: [Discuss-gnuradio] Half-Duplex Relay
On 01/10/2014 03:06 PM, David Halls wrote: Hi all, Hopefully a very easy question! How do I implement a relay such that it will not begin transmitting until it has received a whole ‘burst’ of data. As there will be a direct path from source to destination, I don’t want the relay to start transmitting until the source has finished transmitting. Thus I want to implement a TDMA restriction where source transmits in time slot 1, then transmits nothing during time slot 2 (easy), then I want the relay to listen only in time slot 1 and then not begin transmitting until time slot 2. I was wondering if I should use some kind of tagging? Most likely, yes. Although I know one student at CEL wrote a relay before tags were around (I doubt the code is still available...). Not transmitting is not as trivial as it sounds :) I'm assuming you're using UHD devices (USRPs). In this case, have a look at the tx_sob and tx_eob tags and what they do in the UHD sink (they shut down the transmitter and fire it up again, so your USRP doesn't expect samples when you're in an idle slot). There's a couple of things to consider. If you're doing some relay-specific experiment, you probably have dedicated code for source, relay and destination. The source will only send out a burst (use the mentioned tags to mark that) and wait. Alternatively, you can also send out zeros between tags. The destination node is even simpler -- you rx all the time and pass packets to an upper layer for combining. Nothing special here. Same with the relay, although you'll need the tags again for retransmission. Also, you should keep timing in mind, which can sometimes be a bit random in GNU Radio. If you're expecting decoding within a certain time after decoding (or just reception if you do AaF). Have a look at the manual page for tagged streams and PDUs as well as the examples for packet-based transceivers (e.g. the OFDM code). If you need anything more specific, just ask here! MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Passing a USRP pointer
Hey Tom, We've been working on this, but we ran into a snag. We couldn't seem to look up the usrp sink block's key. Other blocks could be looked up with the keys we expected, just not the uhd sink. I just un-commented a print statement in block_registry.cc so that we could see how each block actually gets registered, built it and ran a simple flowgraph. The flowgraph is just a signal source - throttle - uhd sink. Here's the output: register_symbolic_name: top_block0 register_symbolic_name: gr uhd usrp sink0 register_symbolic_name: throttle0 register_symbolic_name: sig_source_c0 The UHD sink block gets an unexpected gr pre-pended and the underscores are replaced with spaces. We are going to attempt our OOT blocks with this in mind, but I thought I'd give you a heads up on this behavior. Thanks! Very Respectfully, Dan CaJacob On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Here's some more detail into our problem. When running the flowgraph, we get the following error: File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in make return _sq_swig.usrp_pa_control_make(*args, **kwargs) TypeError: in method 'usrp_pa_control_make', argument 1 of type 'gr::uhd::usrp_sink::sptr' When setting up a FG, the pa-control block accepts a reference to the downstream UHD sink. I have attached the specific block source. Thanks! Very Respectfully, Dan CaJacob It's probably the difference between a gr::uhd::usrp_sink and a gr::uhd::usrp_sink_impl. A safer way to handle this might be to use the new(ish) block_registry that we implemented to handle the message passing infrastructure. You can get a basic_block_sptr from global_block_registry.block_lookup; you should then be able to cast this to a usrp_sink_sptr. You'll pass it a PMT symbol containing the alias name of the UHD sink itself. Take a look at basic_block.cc for a look at how the global_block_registry is used. I've not done exactly this before, so it might not go completely smoothly, and I'd be interested in your experience. In general, this sounds like something more appropriately implemented as a message, though, but that would mean changing the gr-uhd code. Having a message handler for the GPIO stuff would probably be useful if done generically enough. Tom On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com wrote: Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably require changes to the actual UHD sinks. I'm not sure our use case is generic enough to warrant that. Very Respectfully, Dan CaJacob On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com wrote: We are upgrading some of our custom blocks for 3.7 and have run into a snag. Our 3.6 era blocks included one that PTTed an external amplifier based on stream tags. The IO was generated from the extra GPIO available on the WBX. One of the inputs to the block was a reference to the USRP sink downstream in the FG. The block then calls the necessary methods to enable and disable the GPIO. Everything worked nicely, but when we ported our blocks to 3.87, there seemed to be a problem with this. I did not personally do the testing, so I don't have the exact error, but I can probably re-create it given some time. I started the porting of the blocks myself and did notice that getting the pointer to a USRP object had changed. But the blocks built without error when updated appropriately. Is there anything in principle that would prevent this from working in 3.7? Or, is there a better approach to controlling the WBX GPIO based on stream tags that we should consider? I apologize for the vagueness on the actual error. I'll try to reproduce it myself in the meantime. I can probably post the code for the PTT-controlling block if that would be any help. Very Respectfully, Dan CaJacob Hi Dan, Sorry for the silence. Partly due to the holidays, partly due to me not having a good answer for you. Most likely, your problem is related in some way to the public/private implementations that we are enforcing in 3.7 now. If you have more information or have figured this out, let us know and we can see where we need to go from here. Tom ___
Re: [Discuss-gnuradio] Where can I get gr-air-modes for GNUradio 3.6.5
Hi, I just pushed a tag called 3.6 representing the last commit of gr-air-modes which was 3.6-compatible. Please note that a lot of the newer features of gr-air-modes are unavailable in this version. To use this version, do a git remote update from the gr-air-modes folder, then git checkout 3.6. Best, Nick On Thu, Jan 9, 2014 at 7:34 PM, Cheng Chi ch000...@e.ntu.edu.sg wrote: Hi, I try to install gr-air-modes from the git source, but it seems the code only works with GNUradio 3.7. May I know where can I find the old version which is compatible with GNUradio 3.6.5? Thanks. Best regards, Cheng Chi ___ 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] Time
I am looking for a block that will give me a time while I am playing back my data in GNURadio Companion. By this, I mean something that will pop up when I start my flow and show me the time since the flow was started. I do not care if it does not stop, I just want to be able to have a reference point for how long my FFT Sink has been playing. Is there such a thing? I have looked through all of the blocks in GRC, and I am probably just missing it or not recognizing it. Thank you. Paul B. Huter ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time
On 01/10/2014 06:19 PM, Paul B. Huter wrote: I am looking for a block that will give me a time while I am playing back my data in GNURadio Companion. By this, I mean something that will pop up when I start my flow and show me the time since the flow was started. I do not care if it does not stop, I just want to be able to have a reference point for how long my FFT Sink has been playing. Is there such a thing? I have looked through all of the blocks in GRC, and I am probably just missing it or not recognizing it. Thank you. Paul B. Huter ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio That doesn't really belong as a signal-processing block. Consider probes/function-probes in GRC, and the ability to call imported Python code. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About DPSK mod and demod
Hi all, I managed to find out the reason why error rate module cannot work. Just want to share my thoughts and hopefully it can help other guys when they want to do similar simulation. As cited in my previous post below, I tried to evaluate the BER performance using GRC for DPSK modulation and demodulation. I made a mistake in this flowgraph since there is no synchronization module. So, we have to add some training sequence to the stream sent and do a correlation after the demodulation. In this way, the streams can be synchronized and the bit error rate can be correctly calculated. Of course, since we have to add some customized modules, the best way is to directly work on the python script. Best Henry On Tue, Dec 3, 2013 at 10:00 PM, Henry Jin henry.ji...@gmail.com wrote: Hi, I tried to build a simple flow graph of DPSK modulation and demodulation. The result is verified using the Error Rate module. The link shows the flow I'm using. https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png I know that the output of demod module is unpacked bytes, so an unpacked to packed module is attached after demodulation. However, the BER is close to 50%, which surely indicates something wrong. I further analyzed the two inputs of the Error Rate module by writing info to the file sink. It clearly shows the discrepancy. So I just wonder what is wrong with this flow graph. Could someone please help me? Also, as I noticed, in the output file generated after unpacked to packed module, there are many consecutive 0s at the start of the file. Does that indicate something? Suggestions are greatly appreciated! On Sat, Dec 14, 2013 at 5:50 PM, Wayne Roberts wroberts92...@gmail.comwrote: There isnt any QA code for QAM modulator or demodulator. They do not work for me. I think if they worked, then their would be QA code. On Sat, Dec 14, 2013 at 12:08 PM, Henry Jin henry.ji...@gmail.com wrote: Hi Wayne I agree with every point you mentioned in your reply. For the variable Bits per symbol, that was a mistake since I previously used it to test QAM. So, have you tested QAM? In my test, the two files didn't match as discussed in my previous post. Just curious about why this mismatch can happen. Thanks. Have a good weekend Henry On Sat, Dec 14, 2013 at 11:19 AM, Wayne Roberts wroberts92...@gmail.comwrote: I i try that DQPSK schema myself, but i notice that in your image you have Bits per symbol in packet encoder set to 4, but the help of packet encoder says 2 for DQPSK. I try 2, and i get no errors until the end, probably because of file buffering. --- sent.hex2013-12-14 10:11:41.308775941 -0800 +++ got.hex 2013-12-14 10:11:52.269776677 -0800 @@ -62206,259 +62206,3 @@ 00f2fd0: 4db3 ace4 e63f eb53 3fb3 e20a 6cdf 85ab M?.S?...l... 00f2fe0: 1a29 0ae6 3816 2e64 bd37 dc08 6982 379b .)..8..d.7..i.7. 00f2ff0: fd0d 6dc5 0d68 53e9 0384 8234 3af2 9861 ..m..hS4:..a -00f3000: 1625 7ce9 c0aa 64e6 9272 6ce2 9dce d524 .%|...d..rl$ -00f3010: 1d0f 748e bcfb 88a8 f9ee 3504 1dd4 7204 ..t...5...r. bytes_sent file has 999424 bytes and bytes_received has 995328 bytes. The difference is probably that 1 million samples from random source isnt even to the payload length of packet encoder. On Sun, Dec 8, 2013 at 8:57 PM, Henry Jin henry.ji...@gmail.com wrote: Hi all, As per previous discussions, I have changed my design as shown in the link https://www.dropbox.com/s/8pw27f29qf5unuq/Screenshot%20from%202013-12-08%2021%3A39%3A05.png This time, QPSK and BPSK both works as I compared the files generated. However, I found two more problems: 1. When Error Rate module is enabled, the simulation can only be run for one or two seconds, then it gets stuck. This was observed by attaching a scope in the flowgraph. The display of the scope is never able to be updated. Just wonder why this happens? 2. When DPSK Mod and Demod blocks are replaced by QAM Mod and Demod, I find that many packets are missing in the receiver's decoded file compared to the file on the sender side. Except the missing packets, all other packets in the receiver's decoded file can perfectly match with the ones sent. So what has caused this issue? To make it better understood, I attached a screenshot comparing the two files from file sinks. https://www.dropbox.com/s/9203fvigi3wohmh/Screenshot%20from%202013-12-08%2021%3A52%3A48.png Please give me some suggestions if you have any thoughts. Thanks. Henry On Thu, Dec 5, 2013 at 2:39 PM, Henry Jin henry.ji...@gmail.comwrote: Thanks for your effort in trying to help, Michael. I will continue to study and if I managed to get it working, I will keep you updated. Henry On Thu, Dec 5, 2013 at 2:23 PM, Michael Berman mrberma...@gmail.comwrote: Henry, I looked at this and some of the underlying code, and tried to run your example with some modifications, but all to no avail as to
Re: [Discuss-gnuradio] Where can I get gr-air-modes for GNUradio 3.6.5
At the moment I am looking at DME signals, still considering if it may be possible to get smth. useful out of them.are you already through these considerations? J Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Nick Foster Sent: Friday, 10 January, 2014 22:33 To: Cheng Chi Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Where can I get gr-air-modes for GNUradio 3.6.5 Hi, I just pushed a tag called 3.6 representing the last commit of gr-air-modes which was 3.6-compatible. Please note that a lot of the newer features of gr-air-modes are unavailable in this version. To use this version, do a git remote update from the gr-air-modes folder, then git checkout 3.6. Best, Nick On Thu, Jan 9, 2014 at 7:34 PM, Cheng Chi ch000...@e.ntu.edu.sg wrote: Hi, I try to install gr-air-modes from the git source, but it seems the code only works with GNUradio 3.7. May I know where can I find the old version which is compatible with GNUradio 3.6.5? Thanks. Best regards, Cheng Chi ___ 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] Successful installation of GNURadio 3.6.4.1 on Window XP and Windows 8
Hi Tom, Thanks for the suggestion! I have updated the wiki by adding a link to the email thread. :) But I wonder if it it appropriate to include the instructions directly in the wiki? I will be happy to do it and update it as and when I have anything to add. I just need to know if there is are guidelines for this sort of thing, or whether I can ask someone who oversees the overall wiki content. B On Thu, Jan 9, 2014 at 10:10 PM, Tom Rondeau t...@trondeau.com wrote: On Mon, Jan 6, 2014 at 9:19 AM, Bhaskar11 niceguy...@gmail.com wrote: Hi Tom, 1. Thanks for adding the link in the WindowsInstall wiki. I note that the link has been added in the section on Building on Windows with Native Tools where it is surely relevant for the dependencies that I discovered. But my instructions are intended for installing with pre-built binaries, and are mainly aimed at users who are *not* able to build natively, and so would never look under that section. For such users it will be very useful if you can add a link in the Pre-built Binaries section right where the link to the Ettus Research site is made. It can be added as an update or a caveat to the Ettus instructions link. 2. As an addendum to my main post, I have found that only one UHD driver works correctly with GRC 3.6.4.1. under Windows XP and Windows 8. And that is version 3.5.0 (file name uhd_003.005.000-release_Win32) available from here. I will share a more detailed update on the UHD driver compatibility and error messages in a separate post. But I have included this info here for completeness of this thread. B Bhaskar, Once again, thanks for your help. With the gnuradio.org wiki, you know, anyone can get an account and edit the wiki, so with someone like you who's actually been through this process, it'd be great if you could make these changes yourself to help keep us all honest and up to date! Thanks! Tom On Mon, Dec 30, 2013 at 9:29 PM, Tom Rondeau t...@trondeau.com wrote: Bhaskar, Thanks for your effort on not only getting GNU Radio working on Windows but also providing us with the steps you took to get there. That could be really helpful to a lot of people. I have made a link on our WindowsInstall wiki to point to your email for other people looking for help. Please note, though, that we've tried to make it very clear that Windows is not a fully supported OS. None of the core developers can really test and build on Windows, and we rely on patches and feedback like you've provided from the community. We do our best to keep things working cross-platform, but as you've experienced, as versions change (both GNU Radio and it's dependencies), this is a serious project. Tom On Thu, Dec 26, 2013 at 11:10 AM, Bhaskar11 niceguy...@gmail.com wrote: After much experimentation I have finally found a way to successfully install and fully run GRC 3.6.4.1 both under Windows XP and Windows 8. I presume it should therefore work equally well under Vista and 7. First a few comments on the common causes of problems that most people have had: a. It is critical to have the correct *matching* and *complete* versions of the various required libraries. Most installations instructions online fail because of this reason. The Ettus installation instructions officially recommended on GNURadio website and provided here fail now because many of the original binary versions referred to are no longer available. Hence those instructions are now outdated and should be replaced by the instructions provided in this email. b. Although it is possible to successfully install GNURadio binaries for versions 3.7.x, none of them include runtime DLLs for WX GUI blocks. Hence these blocks are not displayed, and so most of the example files available cannot be used as they need WX GUI blocks. Moreover, some of the QT GUI blocks do not work in certain versions. Since I do not know how to make these binaries, I request those who have created these version 3.7.x Windows binaries to repack them so that we can run the latest versions of GNURadio in Windows. Until that is done, there is no point trying to install those versions. c. Only GNURadio version 3.6.x binaries have WX GUI blocks. But versions 3.6.2 does not allow moving the blocks. Only 3.6.4.1 is usable, and works perfectly well for all available examples tested so far including all QT GUI and WX GUI blocks. d. The required Python libraries versions are available only for Python version 2.7.3 and are NOT all available for versions 2.7.6 or above, or at least I could not find them online. Hence we have to use libraries compatible only with Python 2.7.3. e. Some library versions have their quirks or bugs. For example PyGTK 2.24.0 does not allow you to add blocks in GRC.
[Discuss-gnuradio] Half-Duplex Relay
Hi all, Hopefully a very easy question! How do I implement a relay such that it will not begin transmitting until it has received a whole 'burst' of data. As there will be a direct path from source to destination, I don't want the relay to start transmitting until the source has finished transmitting. Thus I want to implement a TDMA restriction where source transmits in time slot 1, then transmits nothing during time slot 2 (easy), then I want the relay to listen only in time slot 1 and then not begin transmitting until time slot 2. I was wondering if I should use some kind of tagging? Many thanks! David --- David Halls Ph.D. Research Engineer Toshiba Research Europe Limited 32 Queen Square, Bristol, BS1 4ND, UK Tel: +44 (0) 117 906 0790 NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PYBOMBs Testing
All it DOES see if ice3.4. On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Thanks. I didn't know how or what to search for, so that was useful. Here's the result: p kde-zeroconf - zeroconf plugins and kio slaves for KDE p kde-zeroconf:i386 - zeroconf plugins and kio slaves for KDE p kde-zeroconf-dbg - debug symbols for kde-zeroconf p kde-zeroconf-dbg:i386 - debug symbols for kde-zeroconf p libmono-zeroconf-cil-dev - CLI library for multicast DNS service discovery p libmono-zeroconf1.0-cil- CLI library for multicast DNS service discovery p libqxt-zeroconf0 - library to use multicast DNS service discovery in Qt p libqxt-zeroconf0:i386 - library to use multicast DNS service discovery in Qt v libzeroc-ice-dev - v libzeroc-ice-dev:i386 - p libzeroc-ice-ruby1.8 - Ice for Ruby modules p libzeroc-ice-ruby1.8:i386 - Ice for Ruby modules p libzeroc-ice3.4-cil- Ice for C# libraries p libzeroc-ice3.4-java - Ice for Java libraries i libzeroc-ice34 - Ice for C++ runtime library p libzeroc-ice34:i386- Ice for C++ runtime library i A libzeroc-ice34-dbg - Ice for C++ debugging symbols p libzeroc-ice34-dbg:i386- Ice for C++ debugging symbols i libzeroc-ice34-dev - Ice for C++ development libraries p libzeroc-ice34-dev:i386- Ice for C++ development libraries p monodoc-mono-zeroconf-manual - compiled XML documentation for mono-zeroconf p php-zeroc-ice - Ice for PHP extension p php-zeroc-ice:i386 - Ice for PHP extension p pulseaudio-module-zeroconf - Zeroconf module for PulseAudio sound server p pulseaudio-module-zeroconf:i386- Zeroconf module for PulseAudio sound server p pulseaudio-module-zeroconf-dbg - Zeroconf module for PulseAudio sound server (debuggin p pulseaudio-module-zeroconf-dbg:i386- Zeroconf module for PulseAudio sound server (debuggin i python-zeroc-ice - Ice for Python libraries p python-zeroc-ice:i386 - Ice for Python libraries v python2.7-zeroc-ice- v python2.7-zeroc-ice:i386 - v zeroc-ice - p zeroc-ice-manual - Ice documentation in pdf p zeroc-ice34- Internet Communications Engine p zeroc-icee - Embedded edition of the ZeroC Ice Here's what I found in the gnuradio CMakeCache.txt file: ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so //Path to a library. ICE_ICE:FILEPATH=/usr/lib/libIce.so //Path to a library. ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so //Path to a library. ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so //Path to a library. ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so //Path to a file. ICE_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so //Path to a program. ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp //Path to a program. ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py //Details about finding ICE FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()] //ADVANCED property for variable: ICE_INCLUDE_DIR ICE_INCLUDE_DIR-ADVANCED:INTERNAL=1 PC_ICE_CFLAGS:INTERNAL= PC_ICE_CFLAGS_I:INTERNAL= PC_ICE_CFLAGS_OTHER:INTERNAL= PC_ICE_FOUND:INTERNAL= PC_ICE_INCLUDEDIR:INTERNAL= PC_ICE_Ice-3.5_INCLUDEDIR:INTERNAL= PC_ICE_Ice-3.5_LIBDIR:INTERNAL= PC_ICE_Ice-3.5_PREFIX:INTERNAL= PC_ICE_Ice-3.5_VERSION:INTERNAL= PC_ICE_LIBDIR:INTERNAL= PC_ICE_LIBS:INTERNAL= PC_ICE_LIBS_L:INTERNAL= PC_ICE_LIBS_OTHER:INTERNAL= PC_ICE_LIBS_PATHS:INTERNAL= PC_ICE_PREFIX:INTERNAL= PC_ICE_STATIC_CFLAGS:INTERNAL= PC_ICE_STATIC_CFLAGS_I:INTERNAL= PC_ICE_STATIC_CFLAGS_OTHER:INTERNAL= PC_ICE_STATIC_LIBDIR:INTERNAL= PC_ICE_STATIC_LIBS:INTERNAL= PC_ICE_STATIC_LIBS_L:INTERNAL= PC_ICE_STATIC_LIBS_OTHER:INTERNAL= PC_ICE_STATIC_LIBS_PATHS:INTERNAL= PC_ICE_VERSION:INTERNAL= __pkg_config_checked_PC_ICE:INTERNAL=1 Very Respectfully, Dan CaJacob On Thu, Jan 9, 2014 at 11:22 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jan 9, 2014 at 10:44 AM, Dan CaJacob dan.caja...@gmail.com wrote: Hey guys, thanks for the responses! I'm running Ubuntu 13.10 x64 and ICE version
Re: [Discuss-gnuradio] PYBOMBs Testing
On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Thanks. I didn't know how or what to search for, so that was useful. Here's the result: i libzeroc-ice34 - Ice for C++ runtime library That there confirms that the Ice 3.4.2 library is installed on your system, which is what I was expecting. Here's what I found in the gnuradio CMakeCache.txt file: ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so //Path to a library. ICE_ICE:FILEPATH=/usr/lib/libIce.so //Path to a library. ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so //Path to a library. ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so //Path to a library. ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so //Path to a file. ICE_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so //Path to a program. ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp //Path to a program. ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py //Details about finding ICE FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()] Very Respectfully, Dan CaJacob And that tells us that GNU Radio is trying to build using the Ice libs in /usr/lib, which is where apt-get would have installed ICE, so yeah, it's trying to build off Ice 3.4.2. You could solve this pretty easily by doing an aptitude remove libzeroc-ice to get rid of Ice 3.4.2 altogether on your system. But I'm more interested in solving this issue in general. I've brought up a VM that has this behavior. Let me see about working out a solution. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PYBOMBs Testing
Thanks, Tom! Digression warning: While we're on the topic, I've always wondered if virtualenv would help with build dependency problems and multiple installed versions (e.g. for devs). I have never immersed myself into the tool, but I know that it is intended for things like this where you want to install specific package versions for a specific application without affecting other things on your system. It's a sandbox, I guess. What I've never been clear on is whether it works for C/C++ applications, since it seems to be a python tool. Do you have any thoughts on that? Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 10:14 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Thanks. I didn't know how or what to search for, so that was useful. Here's the result: i libzeroc-ice34 - Ice for C++ runtime library That there confirms that the Ice 3.4.2 library is installed on your system, which is what I was expecting. Here's what I found in the gnuradio CMakeCache.txt file: ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so //Path to a library. ICE_ICE:FILEPATH=/usr/lib/libIce.so //Path to a library. ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so //Path to a library. ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so //Path to a library. ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so //Path to a file. ICE_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so //Path to a program. ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp //Path to a program. ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py //Details about finding ICE FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()] Very Respectfully, Dan CaJacob And that tells us that GNU Radio is trying to build using the Ice libs in /usr/lib, which is where apt-get would have installed ICE, so yeah, it's trying to build off Ice 3.4.2. You could solve this pretty easily by doing an aptitude remove libzeroc-ice to get rid of Ice 3.4.2 altogether on your system. But I'm more interested in solving this issue in general. I've brought up a VM that has this behavior. Let me see about working out a solution. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multiple Versions of Libraries / Virtualenv (was: Re: PYBOMBs Testing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dan, no, Virtualenv is virtualenv is a tool to create isolated Python environments. only. For unix systems, having multiple versions of the same library is not a problem by itself, especially since there are several environment variables that control the behaviour of the dynamic run time linker. A nice method to employ this is described in http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Experts-only-How-can-I-deliberately-install-GNU-Radio-multiple-times-different-versions ; just install your application specific libraries, headers etc into ~/.usrlocal. Also, if you need to capsulate your system more thoroughly, consider using chroot; although this has become less popular over the last few years due to the fact that virtualization has become so easy. Hope that was a little insightful. If someone comes up with something interesting on this topic, a new thread should be started; although I consider this problem to be of a typical linux distribution concern, and not very much specific to GR. Greetings, Marcus On 10.01.2014 16:45, Dan CaJacob wrote: Thanks, Tom! Digression warning: While we're on the topic, I've always wondered if virtualenv would help with build dependency problems and multiple installed versions (e.g. for devs). I have never immersed myself into the tool, but I know that it is intended for things like this where you want to install specific package versions for a specific application without affecting other things on your system. It's a sandbox, I guess. What I've never been clear on is whether it works for C/C++ applications, since it seems to be a python tool. Do you have any thoughts on that? Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 10:14 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Thanks. I didn't know how or what to search for, so that was useful. Here's the result: i libzeroc-ice34 - Ice for C++ runtime library That there confirms that the Ice 3.4.2 library is installed on your system, which is what I was expecting. Here's what I found in the gnuradio CMakeCache.txt file: ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so //Path to a library. ICE_ICE:FILEPATH=/usr/lib/libIce.so //Path to a library. ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so //Path to a library. ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so //Path to a library. ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so //Path to a file. ICE_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so //Path to a program. ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp //Path to a program. ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py //Details about finding ICE FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()] Very Respectfully, Dan CaJacob And that tells us that GNU Radio is trying to build using the Ice libs in /usr/lib, which is where apt-get would have installed ICE, so yeah, it's trying to build off Ice 3.4.2. You could solve this pretty easily by doing an aptitude remove libzeroc-ice to get rid of Ice 3.4.2 altogether on your system. But I'm more interested in solving this issue in general. I've brought up a VM that has this behavior. Let me see about working out a solution. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0Dn7AAoJEAFxB7BbsDrLEOwH/RTC+kW1/vgQ6NQxaoTDYFTv vxz9B5PbOxocH9/dnINdqtctJw63f/gfIqwUzZK2uuZOJKR1HYbbeIm6diheOexU B+KVgGDyMbcCIw2Xioo+B/Gr8b7sQPZjOnJNztg1Se1wpOLPtCcwP6fTv9j6xZog olcyQ1cxezRikja/DX/E52DxJ/fVgDawMoR+KoMQOQ4SvL98KiTuD/X6vRuc2TOz xt81GwAs6LJh8HVr+kMBXFq1UaN3WxrMPHXtg/db0uxWZXgvKoQYLv6fpCMb+9BZ eAXgzDkh1SXyaB9K6G6Q6qTO95el6W/VRDgbRyUC8SvP4IN72i4R+jhG6cwwCKg= =M0JC -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Half-Duplex Relay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, this is not an easy question by itself -- what you're describing is the implementation of slotted medium access. This implies synchronization and some considerations regarding arbitration etc. There have been several attempts at MAC with GNU Radio, with differing results. What kind of MAC you actually want depends on a multitude of factors - -- a priori knowledge of involved transceivers, knowledge of geometry, acceptable interference power, acceptable length of preamble, acceptable latencies and so on. As soon as all your transceivers know when to start and stop transmitting/listening, you can use the USRPs' timed_commands to time your frames. Please refer to the GNU Radio doxygen - UHD source/sinks - - set_command_time. Greetings, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0DqVAAoJEAFxB7BbsDrLZasH+wSS8ARSCrnD+VSUKEfTLzEU OXIXrjWACiKjw60duFDoYMlyaRFjKWVWTfEN5P6LdLqPO4PyKm/qt5Fj77A07/1v Yqt/e9xhjvY04WDB6QvrNV+ig0rQuGHR/Z+k76SyasDvWwjg3KpXRc6MH+5UzBxi 004YwFyuW7pqvuFo4jZWEqg+TN0qnjFtKwHSJfgn39z6MnaEQxvk1YrBpwdtAQ/g fbxlD00lN8oQ5xF1CDp9VKHxJ9236NazcMSE8dfnVfI27ekPBiB89BuVcJBkOBMo 6at8kt1bY+aWkR0eUMK+f446N8/MOGUk2AWMjvIpLSe+Hs6octi0iy4p8djtPJk= =8J8F -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
