[Discuss-gnuradio] How to uninstall an OUT-OF-TREE module?
Hi all, I have made an OUT-OF-TREE module, but now I want to remove it from gnuradio. I am using GNUradio 3.7.3. Can anyone tell me how to that? Thanks a lot Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronizing N210 TX and RX channels
Hello Marcus, I'm aware of that, what I want to achieve at the moment is simply to have a predictable phase delay between the tx and rx channels. This is prerequisite to measure the round-trip time and account for it. Cheers, Daniele On 22/07/2014 22:14, Marcus Müller wrote: Hi Daniele, your problem is actually harder: The latency of digital signal processing depends on your desired decimation, and analog signal latency depends on a ton of factors like target RF frequency, adjustable filters (if your daughterboard has something like this), antenna and cabling delay, and so on. The only real way to know is to *measure* the roundtrip for each configuration, and that's exactly what echotimer is for. With best regards, Marcus On 22.07.2014 19:25, Daniele Nicolodi wrote: Hello Stephan, thank for your reply. What I would like to do is more simple than that: I need to synchronize tx and rx of the same USRP, not of two different devices. But I need continuous streaming and not burst. Any help in this direction is much appreciated. Thanks. Best, Daniele On 22/07/2014 19:14, Stefan Wunsch wrote: Hey Daniele, I have done the radar toolbox and implemented a synced USRP interface (USRP Echotimer). You are right, the USRP Echotimer does align the timestamps of the TX/RX commands on both USRPs. But if you connect them by MIMO, the time and clock are pretty good in sync. Therefore I think the Echotimer can provide a sync with an accuracy of at least +- 1 sample. Check out [0] for a video of the sync. There is also a sync setup for testing (gr-radar/examples/usrp). Unfortunately the documentation is not finished yet. But care: The Echotimer bursts only a packet in sync, it does not stream the whole time! The packet is defined by a tagged stream. Greetings, Stefan [0] https://grradar.wordpress.com/2014/06/17/synchronisation-echotimer-usrp-interface/ Am 22.07.2014 18:40, schrieb Daniele Nicolodi: On 22/07/2014 18:18, Martin Braun wrote: On top of what Marcus' has said, the gr-radar toolbox might be helpful. It has a block that takes a tagged stream, and outputs a signal it acquired synchronously to the transmitted one. Thanks Martin. This seems to imply that there is no way to actually synchronize the hardware, and that the synchronization can only be done in software aligning the timestamps of the two streams. Is that the case? Thanks. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronizing N210 TX and RX channels
Hey, If you use the Echotimer you can use the same IP vor TX and RX, this should work. Probably you can do your own USRP Sink/Source with UHD. You dont need much code to implement this (Echotimer ~300 lines in the *impl.cc). Main change should be an other stream command (most likely STREAM_MODE_START_CONTINUOUS [0]). Good code examples are UHD Sink/Source in gr-uhd and especially the examples from UHD itself (uhd repo/host/examples). And the Echotimer of course! My approach: Read the system time on the USRP, set the stream command on actual_time+some_offset and spawn two threads with a tx_streamer and a rx_streamer. You can use both of them on the sampe USRP without any problems (just dont use two of the same type on one USRP). This should also work with streaming if you can push your data in the work function continuously. Greetings, Stefan [0] http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html#a4df1f2e22148b7e09ace0eca0dfbf904 Am 22.07.2014 19:25, schrieb Daniele Nicolodi: Hello Stephan, thank for your reply. What I would like to do is more simple than that: I need to synchronize tx and rx of the same USRP, not of two different devices. But I need continuous streaming and not burst. Any help in this direction is much appreciated. Thanks. Best, Daniele On 22/07/2014 19:14, Stefan Wunsch wrote: Hey Daniele, I have done the radar toolbox and implemented a synced USRP interface (USRP Echotimer). You are right, the USRP Echotimer does align the timestamps of the TX/RX commands on both USRPs. But if you connect them by MIMO, the time and clock are pretty good in sync. Therefore I think the Echotimer can provide a sync with an accuracy of at least +- 1 sample. Check out [0] for a video of the sync. There is also a sync setup for testing (gr-radar/examples/usrp). Unfortunately the documentation is not finished yet. But care: The Echotimer bursts only a packet in sync, it does not stream the whole time! The packet is defined by a tagged stream. Greetings, Stefan [0] https://grradar.wordpress.com/2014/06/17/synchronisation-echotimer-usrp-interface/ Am 22.07.2014 18:40, schrieb Daniele Nicolodi: On 22/07/2014 18:18, Martin Braun wrote: On top of what Marcus' has said, the gr-radar toolbox might be helpful. It has a block that takes a tagged stream, and outputs a signal it acquired synchronously to the transmitted one. Thanks Martin. This seems to imply that there is no way to actually synchronize the hardware, and that the synchronization can only be done in software aligning the timestamps of the two streams. Is that the case? Thanks. Cheers, Daniele ___ 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] Synchronizing N210 TX and RX channels
On 07/23/2014 10:43 AM, Stefan Wunsch wrote: If you use the Echotimer you can use the same IP vor TX and RX, this should work. Probably you can do your own USRP Sink/Source with UHD. You dont need much code to implement this (Echotimer ~300 lines in the *impl.cc). Main change should be an other stream command (most likely STREAM_MODE_START_CONTINUOUS [0]). Good code examples are UHD Sink/Source in gr-uhd and especially the examples from UHD itself (uhd repo/host/examples). And the Echotimer of course! My approach: Read the system time on the USRP, set the stream command on actual_time+some_offset and spawn two threads with a tx_streamer and a rx_streamer. You can use both of them on the sampe USRP without any problems (just dont use two of the same type on one USRP). This should also work with streaming if you can push your data in the work function continuously. You could also do this inside your app, without having to write new sources and sinks. If your N210s are connected via MIMO cable, synchronizing them in time and frequency is pretty straightforward. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to uninstall an OUT-OF-TREE module?
On 07/23/2014 08:57 AM, Nguyễn Văn Lý wrote: Hi all, I have made an OUT-OF-TREE module, but now I want to remove it from gnuradio. I am using GNUradio 3.7.3. Can anyone tell me how to that? Nope, not without you telling us how you installed it. If you still have the install manifest, a 'make uninstall' will do the trick. Otherwise, just manually purge everything from whereever you installed this stuff. M Thanks a lot Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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] PyBombs install maint branch from fresh
On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com wrote: On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M Thanks. yes, I am trying to install GNU Radio maintenance branch. I will change the gitbranch of gnuradio.lwr recipe to 'maint'. Does this means the uhd.lwr also need to be 'maint', or can just be 'master' as default? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
Martin, You are probably right we should track maint by default at this point.I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote: On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com wrote: On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M Thanks. yes, I am trying to install GNU Radio maintenance branch. I will change the gitbranch of gnuradio.lwr recipe to 'maint'. Does this means the uhd.lwr also need to be 'maint', or can just be 'master' as default? ___ 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] PyBombs install maint branch from fresh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, idea: pybombs install package gets the default branch as in the recipe, pybombs install package%awesomefeatures gets the awesomefeatures branch. That would allow people to specify they want UHD maint, GNU Radio v3.7.4, and gqrx master, if they really want to. Greetings, Marcus On 23.07.2014 13:18, Tim O'Shea wrote: Martin, You are probably right we should track maint by default at this point.I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote: On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com wrote: On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M Thanks. yes, I am trying to install GNU Radio maintenance branch. I will change the gitbranch of gnuradio.lwr recipe to 'maint'. Does this means the uhd.lwr also need to be 'maint', or can just be 'master' as default? ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTz5xzAAoJEBQ6EdjyzlHt2oYIAJYYair2p3bJqiYwIMVhtX21 O5DUUVV06LQpEXUbxs99JBeGtA4KoY1KddVW2OPx26yUhP49xBAYO8dbNHth4ft8 PHNjS2vWroGK/8otLM8kkdzr+2+YmCw9zMKW/q/nl/afxsdUmu8N+gY9hZYsBkv8 jF8A4UPk7b8d4r79WxHmiiYHN6FLnW9glfGXDbigJMXyERzNaKJVPoy/o9Z7o5Q7 MLjsWBOkikn6mlNFjXD2VrHRBOJwQrp6gRLtirDhMqaeKepD1QBZddWYv5I5vYB0 5U/DFTN7j3Ar/BXWYiFIGFeUPqFunIw4YO6m/e9z4Le5VuJ0H36d3OptieuS/dE= =twiT -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ImportError: No module named ...
Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named ...
Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, Marcus On 23.07.2014 13:35, Nguye^~n Va(n Lý wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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] Filter design
Hello, GNURadio offers three different interfaces to design filters from Python code: gnuradio.filter.firdes.xxx, gnuradio.filter.firdes.xxx_2, and gnuradio.filter.optfir.xxx. The three interfaces use different parameters to specify the filter properties, but the only obvious difference is that the optfir is coded in python and thus not available to be used elsewhere. Which one is recommended to use? Can anyone suggest a reference that explains how the filter taps are computed? In my data analysis code I usually use Butterworth filters. If there is any analogy, how do those map to the filters designed with the above tools? Thanks. Best, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Beamforming with GNU Radio and USRPs
Hi everyone, I am currently trying to get 2 N210 to transmit coherently to a third N210. All devices have GPSDO kits and the gps_locked status is on locked, there is no MIMO cable in the setup. I am currently doing some preliminary tests where I feed both sinks with the same signal i.e a complex sine wave using the signal source from GNU Radio and I observe the signal received by the third USRP. I made sure that both transmitted signals are received with the same amplitude when taken independently. My understanding is that if both transmitters are locked to the GPS there should be no frequency offset between them and there should only be a constant phase offset between them which would give me a somewhat constant amplitude signal at the receiver. On the receiver, I observe the signal with both a time sink and a frequency sink. My problem is that the received signal seems to be varying a lot in amplitude, it looks like a slow AM modulation which is something I would get if both transmitters weren't perfectly aligned in frequency. Changing the frequency of one of the transmitters makes the problem worse. Does anyone have prior experience with this kind of setup and experienced the same issues? Thanks in advance, Jawad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Beamforming with GNU Radio and USRPs
I am not aware of the details of the GPSDO implementation but your sources must be phase locked, not only synchronized through the GPS signal. The GPS control loop on the LO only has a finite bandwidth above which each oscillator is free to drift at will. Under such conditions, the interference pattern will be fluctuating because the PLL bandwidth is necessarily much lower than the carrier frequency. JM I am currently trying to get 2 N210 to transmit coherently to a third N210. All devices have GPSDO kits and the gps_locked status is on locked, there is no MIMO cable in the setup. I am currently doing some preliminary tests where I feed both sinks with the same signal i.e a complex sine wave using the signal source from GNU Radio and I observe the signal received by the third USRP. I made sure that both transmitted signals are received with the same amplitude when taken independently. My understanding is that if both transmitters are locked to the GPS there should be no frequency offset between them and there should only be a constant phase offset between them which would give me a somewhat constant amplitude signal at the receiver. On the receiver, I observe the signal with both a time sink and a frequency sink. My problem is that the received signal seems to be varying a lot in amplitude, it looks like a slow AM modulation which is something I would get if both transmitters weren't perfectly aligned in frequency. Changing the frequency of one of the transmitters makes the problem worse. Does anyone have prior experience with this kind of setup and experienced the same issues? Thanks in advance, Jawad -- JM Friedt, FEMTO-ST Time Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
On Wed, Jul 23, 2014 at 7:18 PM, Tim O'Shea tim.oshea...@gmail.com wrote: Martin, You are probably right we should track maint by default at this point. I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim I agree with you. It is quite strange that the build-gnuradio script installs 'maint' branch by default, whereas pybombs installs 'master' branch by default. This is lack of consistency. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Filter design
On 23/07/2014 14:01, Daniele Nicolodi wrote: Hello, GNURadio offers three different interfaces to design filters from Python code: gnuradio.filter.firdes.xxx, gnuradio.filter.firdes.xxx_2, and gnuradio.filter.optfir.xxx. The three interfaces use different parameters to specify the filter properties, but the only obvious difference is that the optfir is coded in python and thus not available to be used elsewhere. Which one is recommended to use? Can anyone suggest a reference that explains how the filter taps are computed? In my data analysis code I usually use Butterworth filters. If there is any analogy, how do those map to the filters designed with the above tools? Partially answering my own questions: http://gnuradio.squarespace.com/examples/2010/9/12/basic-filtering.html Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
On Wed, Jul 23, 2014 at 7:15 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As UHD and GNU Radio are widely independent, you can use whatever combination you want in almost any situation (aside from severe API breakage). Thanks. Just curious, does below statement still apply ..? We provide UHD and GNU Radio binary installers for Ubuntu and Fedora users. There are two choices: - *Unstable*: Built off of GNU Radio's *master* branch and an *unstable* UHD install, which includes bugfixes and new features. - *Stable*: Built off of GNU Radio's *maint* branch and a *stable* UHD install, which only includes bugfixes since the last major release. *These GNU Radio installers will only work with their corresponding UHD binary*. If you use an unstable UHD binary with a stable GNU Radio binary (or vice versa), you will not be able to use *any* gr-uhd features. http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Linux ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Beamforming with GNU Radio and USRPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jawad, I think you might want to post follow-ups to this discussion to usrp-us...@lists.ettus.com, since so far this has not much to do with GNU Radio. On 23.07.2014 14:11, Jawad Seddar wrote: Hi everyone, I am currently trying to get 2 N210 to transmit coherently to a third N210. All devices have GPSDO kits and the gps_locked status is on locked, there is no MIMO cable in the setup. I am currently doing some preliminary tests where I feed both sinks with the same signal i.e a complex sine wave using the signal source from GNU Radio and I observe the signal received by the third USRP. I made sure that both transmitted signals are received with the same amplitude when taken independently. So you put your N210s in an anechoic chamber and calibrated the system, and where able to exclude any changing fading effects? That sounds like a lot of work, so kudos! A few parameters would be nice to know, though: What's the tuning frequency, and did you actually generate sines in software (so your over-the-air signal would have $f_carrier = f_tune + f_sine$) or did you just send a constant value at a specific frequency ($f_carrier=f_tune$)? Range, antenna and amplification used would be nice to know, too, and daughterboard model of course. My understanding is that if both transmitters are locked to the GPS there should be no frequency offset between them and there should only be a constant phase offset between them which would give me a somewhat constant amplitude signal at the receiver. Clever measurement setup! On the receiver, I observe the signal with both a time sink and a frequency sink. My problem is that the received signal seems to be varying a lot in amplitude, it looks like a slow AM modulation which is something I would get if both transmitters weren't perfectly aligned in frequency. Slow AM modulation does sound *a lot* like fading. Also, your receivers are not perfectly synced, they're synced within the specification of your GPSDO, which is quite good, but still 2ppb (if I remember correctly). Since you add up sines, you get a resulting sine with a phase that is the result of adding up all the multipath signals of your two transmitters. The slightest variation in environment might shift a lot of not-direct signals, which then might be cancelling or constructively overlay with other paths, thus shifting the overall phase and amplitude quite a bit. Also notice that heat will change the the characteristics of the transceiver's analog chain, so over time the signal of both TX USRPs might differ due to amplifiers etc reacting differently at different temperature. A few numbers would be nice here, too: What's the received amplitude in the single-TX cases, what's the range for a two-RX case? How fast is slow AM modulation? Do you tune to the same frequency or do you avoid DC-component problems by intentionally receive at a slightly offset frequency? Changing the frequency of one of the transmitters makes the problem worse. Does anyone have prior experience with this kind of setup and experienced the same issues? Usually, the frequency stability of the USRPs with GPSDOs is quite good, and I really can't tell if the slow amplitude variation you're seeing (but not quantifying) isn't even covered by the spec of the GPSDO. I think you should actually measure the phase and phase derivative of your received signal. Thanks in advance, Jawad Greetings, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTz6w1AAoJEBQ6EdjyzlHtChEH/AxmZSpRFyGI04q76dRSqJEb Nii9WhIlKDxxza5lU6qOiVfO9ovSnGwfNZraWSOVsEz7GRNv6v9JPkmq0rlEXzaC 00fT1E8fGTKy6Eaq5QAHqb1gfhMtuhi0S4lVDtckQXaeGykoTmWNiIwKPmFoUkrH knJg8d8jyzE8R1WWdY/sAOBmhR0/C3EEz9gvuYOeY2rOx9znYHXXZK5wR10oiPos onoAZIl+gnZIaRGxf1yVJQhbhlO8lthtXt6tBZKi/0wwAKvZ3JzpNLEnyddzLmHM NBNw4pjLoar7vA1kZg2ClzpAoXhVPBFDSiWNV5WwG3C5y0wkWvsCfYO6coLOgB0= =Stii -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
One of the problems with allowing this kind of customization is that a single set of pybombs recipes is generally intended to represent a fixed set of versions / branches as far as configuration management. Supporting additional branch combinations is kind of explosive in terms of new combinations of supported packages/versions.That said, master is kind of a moving target. The hope was to have a set of recipes that tracks master everywhere for the most part (for developers that want this), and then have numbered known good sets of recipes that track for instance 3.7.3 or 3.7.4 with known good OOT modules at the time (for more stable OOT development or pure users). However this is a lot of time/work to set up and constantly test / release so thus far we haven't really been doing that half - The versioned releases are to some extent already covered by binary packages - That said, we can always throw this feature in with a *danger untested version combination* caveat ... -Tim On 07/23/2014 07:28 AM, Marcus Müller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, idea: pybombs install package gets the default branch as in the recipe, pybombs install package%awesomefeatures gets the awesomefeatures branch. That would allow people to specify they want UHD maint, GNU Radio v3.7.4, and gqrx master, if they really want to. Greetings, Marcus On 23.07.2014 13:18, Tim O'Shea wrote: Martin, You are probably right we should track maint by default at this point.I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote: On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com wrote: On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M Thanks. yes, I am trying to install GNU Radio maintenance branch. I will change the gitbranch of gnuradio.lwr recipe to 'maint'. Does this means the uhd.lwr also need to be 'maint', or can just be 'master' as default? ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTz5xzAAoJEBQ6EdjyzlHt2oYIAJYYair2p3bJqiYwIMVhtX21 O5DUUVV06LQpEXUbxs99JBeGtA4KoY1KddVW2OPx26yUhP49xBAYO8dbNHth4ft8 PHNjS2vWroGK/8otLM8kkdzr+2+YmCw9zMKW/q/nl/afxsdUmu8N+gY9hZYsBkv8 jF8A4UPk7b8d4r79WxHmiiYHN6FLnW9glfGXDbigJMXyERzNaKJVPoy/o9Z7o5Q7 MLjsWBOkikn6mlNFjXD2VrHRBOJwQrp6gRLtirDhMqaeKepD1QBZddWYv5I5vYB0 5U/DFTN7j3Ar/BXWYiFIGFeUPqFunIw4YO6m/e9z4Le5VuJ0H36d3OptieuS/dE= =twiT -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] PyBombs install maint branch from fresh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ah well, consistency with the slowly aging build-gnuradio was not the intended purpose of having pyBOMBS. build-gnuradio is the result of an ongoing effort to bring a stable GNU Radio to a lot of platforms without having people worry too much about getting all the dependencies and the build process right. PyBOMBS had this in mind too, but also was meant to provide a comfortable framework to get OOTs and dependencies installed in a flexible manner; thus, using master made a lot of sense, so the latest and greatest OOTs could run. However, since maint is so close to master, and PyBOMBS has hit the mass market, switching to maint does sound very clever. On 23.07.2014 14:25, Activecat wrote: On Wed, Jul 23, 2014 at 7:18 PM, Tim O'Shea tim.oshea...@gmail.com wrote: Martin, You are probably right we should track maint by default at this point. I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim I agree with you. It is quite strange that the build-gnuradio script installs 'maint' branch by default, whereas pybombs installs 'master' branch by default. This is lack of consistency. ___ 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/ iQEcBAEBAgAGBQJTz60qAAoJEBQ6EdjyzlHtM7oH/jl3o7vD+jWFr74fS7w5yZ9e QM1VgJgrrzECMKGvn0NeirttLHJtSoi/Mj0+GasPqMj//yBdbH+OswePEMdhjVnw DVIssZDLrkR2s4fp8GXw+/qeC+xUU2IFOGPs7MMBkfGDiOcw5fQNsdFK4Vhcvm7M yb1/bKHu5QGpRmys+JdyfhVALbBcGtTDudb5uyJ/07ablGrQWGx31rq41DBVA66O sNyj6Yscdo6jhrZImQiDUALL2gnwZrmg5e1jlWHCtAaADS8CGnRPpf446OWu37ae FYC0q3ZzJVj6sXkF2aB3o/O6dccL+jVRIFMJkZgvyJj0iUkGX/ZZPrupFzxSFag= =W3+3 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Agreed, that's why I like the idea of GR being maint by default (so that dependencies might not change that easily [hoping that maint is always tested with the minimum required versions]) and letting users who might want to risk the breakage just choose their version to their liking -- obviously, if you take a different version than the recipe maintainer thought would be right for you, you're leaving the safe path, and no one can really help you there if you have funky version problems. Greetings, Marcus On 23.07.2014 14:36, Tim wrote: One of the problems with allowing this kind of customization is that a single set of pybombs recipes is generally intended to represent a fixed set of versions / branches as far as configuration management. Supporting additional branch combinations is kind of explosive in terms of new combinations of supported packages/versions.That said, master is kind of a moving target. The hope was to have a set of recipes that tracks master everywhere for the most part (for developers that want this), and then have numbered known good sets of recipes that track for instance 3.7.3 or 3.7.4 with known good OOT modules at the time (for more stable OOT development or pure users). However this is a lot of time/work to set up and constantly test / release so thus far we haven't really been doing that half - The versioned releases are to some extent already covered by binary packages - That said, we can always throw this feature in with a *danger untested version combination* caveat ... -Tim On 07/23/2014 07:28 AM, Marcus Müller wrote: Tim, idea: pybombs install package gets the default branch as in the recipe, pybombs install package%awesomefeatures gets the awesomefeatures branch. That would allow people to specify they want UHD maint, GNU Radio v3.7.4, and gqrx master, if they really want to. Greetings, Marcus On 23.07.2014 13:18, Tim O'Shea wrote: Martin, You are probably right we should track maint by default at this point.I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote: On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com wrote: On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M Thanks. yes, I am trying to install GNU Radio maintenance branch. I will change the gitbranch of gnuradio.lwr recipe to 'maint'. Does this means the uhd.lwr also need to be 'maint', or can just be 'master' as default? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTz65pAAoJEBQ6EdjyzlHtFoYH/1cmvi9j4BBKlV1NeypGtsQv XukSmNQJ2gqFSrQvBt3xjVB/5BZYTj4VOkj86hSTr2hn0IucaG81JYt1v/FyN5rM 1rRblVUtyaWuGnN2gREuoGT8jn6GsSFmztHlp6LUj2ZxkCbWAO27fzurT35Bd3Fy koTQxxF5vxxgtMuoL0/KV2M1znqT84OrHB3V8fuKudKjmp4r3QzgaLtOYLRxlm7b g7DHLZ4us+8hFaXzUb6rgS+BHDJlic47JsinUCYMIX1QVV//qSg89lZM/n5YqG67 ODdzcs7CGA7c1aWXgFVnfJT5kpJ2oA65X4TglC24OEfnyffKyxkJln56mQ+Jsvk= =ALg0 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
On Wed, Jul 23, 2014 at 8:40 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ah well, consistency with the slowly aging build-gnuradio was not the intended purpose of having pyBOMBS. build-gnuradio is the result of an ongoing effort to bring a stable GNU Radio to a lot of platforms without having people worry too much about getting all the dependencies and the build process right. PyBOMBS had this in mind too, but also was meant to provide a comfortable framework to get OOTs and dependencies installed in a flexible manner; thus, using master made a lot of sense, so the latest and greatest OOTs could run. However, since maint is so close to master, and PyBOMBS has hit the mass market, switching to maint does sound very clever. Thanks for clarification. This makes a very good sense. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Beamforming with GNU Radio and USRPs
On 07/23/2014 08:11 AM, Jawad Seddar wrote: Hi everyone, I am currently trying to get 2 N210 to transmit coherently to a third N210. All devices have GPSDO kits and the gps_locked status is on locked, there is no MIMO cable in the setup. I am currently doing some preliminary tests where I feed both sinks with the same signal i.e a complex sine wave using the signal source from GNU Radio and I observe the signal received by the third USRP. I made sure that both transmitted signals are received with the same amplitude when taken independently. My understanding is that if both transmitters are locked to the GPS there should be no frequency offset between them and there should only be a constant phase offset between them which would give me a somewhat constant amplitude signal at the receiver. On the receiver, I observe the signal with both a time sink and a frequency sink. My problem is that the received signal seems to be varying a lot in amplitude, it looks like a slow AM modulation which is something I would get if both transmitters weren't perfectly aligned in frequency. Changing the frequency of one of the transmitters makes the problem worse. Does anyone have prior experience with this kind of setup and experienced the same issues? Thanks in advance, Jawad To clarify, your transmitters are both locked to *different* GPSDO units? If so, they won't be at exactly the same frequency. -- 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] QAM Mod / Demod blocks
On Wed, Jul 23, 2014 at 8:42 AM, Activecat active...@gmail.com wrote: Dear Sir, I am learning to use the built-in QAM Mod and QAM Demod blocks. Refer below flowgraph. The problem is, at the output of the QAM Demod block, I can't get what I fed into the QAM Mod block. What is missing ..? All modulators take in packed bits and all demodulators output unpacked bits. First, remember that there are filters involved, so there's going to be a delay. You'd need to synchronize the output of the demodulator to some known word to understand which output bit is the correct start of the data stream. Easier would be to unpack the source data. Out of the 'head' block, make another connection to a 'unpack_k_bits' block with an unpacking value of 8. Use this to compare to the demodulated bits. Also, the vector source should generate values from 0 to 255 to create the packed bits needed as input to the modulator. Otherwise, you'll just be heavily biasing the constellation to just a few points. You can stick a constellation display block on the output of the modulator to see. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Filter design
On Wed, Jul 23, 2014 at 8:29 AM, Daniele Nicolodi dani...@grinta.net wrote: On 23/07/2014 14:01, Daniele Nicolodi wrote: Hello, GNURadio offers three different interfaces to design filters from Python code: gnuradio.filter.firdes.xxx, gnuradio.filter.firdes.xxx_2, and gnuradio.filter.optfir.xxx. The three interfaces use different parameters to specify the filter properties, but the only obvious difference is that the optfir is coded in python and thus not available to be used elsewhere. Which one is recommended to use? Can anyone suggest a reference that explains how the filter taps are computed? In my data analysis code I usually use Butterworth filters. If there is any analogy, how do those map to the filters designed with the above tools? Partially answering my own questions: http://gnuradio.squarespace.com/examples/2010/9/12/basic-filtering.html Cheers, Daniele There's also the manual page on filtering in GR: http://gnuradio.org/doc/doxygen/page_filter.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Message passing - issue with messages left in queues after running top block
On Tue, Jul 22, 2014 at 8:44 AM, Perper per...@o2.pl wrote: Hi all, I've noticed that Run to completion works now in situation when message passing is used, which is great! I have a related question. I'm creating a block which uses message passing, and run it once: tb = some_block(fname=file1) tb.start() tb.wait() #at this moment tb has still some unprocessed messages in message queues #so if I run the block again on another file ... tb.set_fname(file2) tb.start() tb.wait() I can see messages that were result of processing of file1. Do you know how to avoid this? One of acceptable solutions can be flushing msg queues after processing of file1, but I don't know how to achieve this. Best Regards, Piotr Krysik There are still a couple of issues with the message passing, obviously. The proper shutdown of graphs is definitely on our list of things to deal with. We hope to have improvements that cover issues like this by the release of 3.7.5. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named ...
Hi Marcus, I've gotten a surprising thing and I couldn't explain why. First, I type: sudo gnuradio-companion to open the GNUradio and test my own module. It turned out an error message as I described in the previous mail. (ImportError: No module named Tool_NetworkCoding) However, when I just type: gnuradio-companion and also run the same grc file, the error message disappeared, and everything then seems to go well. So, is there any difference between *sudo gnuradio-companion* and *gnuradio-companion* ? Thank you very much Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, Marcus On 23.07.2014 13:35, Nguyễn Văn Lý wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named ...
On Wed, Jul 23, 2014 at 10:32 AM, Nguyễn Văn Lý lynguyenvan@gmail.com wrote: Hi Marcus, I've gotten a surprising thing and I couldn't explain why. First, I type: sudo gnuradio-companion to open the GNUradio and test my own module. It turned out an error message as I described in the previous mail. (ImportError: No module named Tool_NetworkCoding) However, when I just type: gnuradio-companion and also run the same grc file, the error message disappeared, and everything then seems to go well. So, is there any difference between *sudo gnuradio-companion* and *gnuradio-companion* ? Thank you very much Van-Ly Yes. Using sudo, you're running as root with root's environment that usually doesn't know about things in /usr/local (PATH, PYTHONPATH, LD_LIBRARY_PATH, etc.). You should not be running gnuradio-companion as root, anyways. No need to sudo everything! Tom On Wed, Jul 23, 2014 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, Marcus On 23.07.2014 13:35, Nguyễn Văn Lý wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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 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] ImportError: No module named ...
Hi Van-Ly, So, is there any difference between *sudo gnuradio-companion* and *gnuradio-companion* ? Yes, the sudo part ;) sudo is used to make a program run under a different user, and in a different environment. For example, sudo gnuradio-companion runs gnuradio-companion as root. Why did you do that? But that doesn't set the PYTHONPATH environment, so python can't find the modules you installed to your local python package prefix. Greetings, Marcus On 23.07.2014 16:32, Nguyễn Văn Lý wrote: Hi Marcus, I've gotten a surprising thing and I couldn't explain why. First, I type: sudo gnuradio-companion to open the GNUradio and test my own module. It turned out an error message as I described in the previous mail. (ImportError: No module named Tool_NetworkCoding) However, when I just type: gnuradio-companion and also run the same grc file, the error message disappeared, and everything then seems to go well. Thank you very much Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, Marcus On 23.07.2014 13:35, Nguyễn Văn Lý wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named ...
Thanks Tom and Marcus, So it's not necessary to run sudo gnuradio-companion at all :-) Van-Ly p/s: I am new to almost everything that I'm working with, from ubuntu to gnuradio :-) just glad to talk to you :-) Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 9:43 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, So, is there any difference between *sudo gnuradio-companion* and *gnuradio-companion* ? Yes, the sudo part ;) sudo is used to make a program run under a different user, and in a different environment. For example, sudo gnuradio-companion runs gnuradio-companion as root. Why did you do that? But that doesn't set the PYTHONPATH environment, so python can't find the modules you installed to your local python package prefix. Greetings, Marcus On 23.07.2014 16:32, Nguyễn Văn Lý wrote: Hi Marcus, I've gotten a surprising thing and I couldn't explain why. First, I type: sudo gnuradio-companion to open the GNUradio and test my own module. It turned out an error message as I described in the previous mail. (ImportError: No module named Tool_NetworkCoding) However, when I just type: gnuradio-companion and also run the same grc file, the error message disappeared, and everything then seems to go well. Thank you very much Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, Marcus On 23.07.2014 13:35, Nguyễn Văn Lý wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named ...
Glad to have you here, too! Just a word of advice: this is not a linux support channel. We really like being helpful, so it's ok to ask things related to GNU Radio and the system it runs on, but if you want linux help, you might want to go online in IRC and join the #ubuntu channel on irc.freenode.org , using either a desktop client of your choice (e.g. Pidgin) or the web client at http://webchat.freenode.net/ Greetings, Marcus On 23.07.2014 16:51, Nguyễn Văn Lý wrote: Thanks Tom and Marcus, So it's not necessary to run sudo gnuradio-companion at all :-) Van-Ly p/s: I am new to almost everything that I'm working with, from ubuntu to gnuradio :-) just glad to talk to you :-) Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 9:43 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, So, is there any difference between *sudo gnuradio-companion* and *gnuradio-companion* ? Yes, the sudo part ;) sudo is used to make a program run under a different user, and in a different environment. For example, sudo gnuradio-companion runs gnuradio-companion as root. Why did you do that? But that doesn't set the PYTHONPATH environment, so python can't find the modules you installed to your local python package prefix. Greetings, Marcus On 23.07.2014 16:32, Nguyễn Văn Lý wrote: Hi Marcus, I've gotten a surprising thing and I couldn't explain why. First, I type: sudo gnuradio-companion to open the GNUradio and test my own module. It turned out an error message as I described in the previous mail. (ImportError: No module named Tool_NetworkCoding) However, when I just type: gnuradio-companion and also run the same grc file, the error message disappeared, and everything then seems to go well. Thank you very much Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, Marcus On 23.07.2014 13:35, Nguyễn Văn Lý wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named ...
Thanks a lot Marcus :-) Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 9:58 PM, Marcus Müller marcus.muel...@ettus.com wrote: Glad to have you here, too! Just a word of advice: this is not a linux support channel. We really like being helpful, so it's ok to ask things related to GNU Radio and the system it runs on, but if you want linux help, you might want to go online in IRC and join the #ubuntu channel on irc.freenode.org , using either a desktop client of your choice (e.g. Pidgin) or the web client at http://webchat.freenode.net/ Greetings, Marcus On 23.07.2014 16:51, Nguyễn Văn Lý wrote: Thanks Tom and Marcus, So it's not necessary to run sudo gnuradio-companion at all :-) Van-Ly p/s: I am new to almost everything that I'm working with, from ubuntu to gnuradio :-) just glad to talk to you :-) Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 9:43 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, So, is there any difference between *sudo gnuradio-companion* and *gnuradio-companion* ? Yes, the sudo part ;) sudo is used to make a program run under a different user, and in a different environment. For example, sudo gnuradio-companion runs gnuradio-companion as root. Why did you do that? But that doesn't set the PYTHONPATH environment, so python can't find the modules you installed to your local python package prefix. Greetings, Marcus On 23.07.2014 16:32, Nguyễn Văn Lý wrote: Hi Marcus, I've gotten a surprising thing and I couldn't explain why. First, I type: sudo gnuradio-companion to open the GNUradio and test my own module. It turned out an error message as I described in the previous mail. (ImportError: No module named Tool_NetworkCoding) However, when I just type: gnuradio-companion and also run the same grc file, the error message disappeared, and everything then seems to go well. Thank you very much Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, Marcus On 23.07.2014 13:35, Nguyễn Văn Lý wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File /home/van-ly/Downloads/top_block.py, line 16, in moduleimport Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named ...
Indeed, the only reason to run things under "sudo" is when you're doing something that needs root privilege, like updating system files (such as when you do a sudo make install), or you're trying ot get access to some resource that an ordinary user doesn't have access to. Ordinary applications (which is 99% of everything you'll ever use) just require your ordinary userid. That was a time *very* long ago when a fully-installed Gnu Radio installation required apps that accessed USB devices (like USRP1) to run as root, just because there was no udev rules installed. That was fixed years and years ago. on Jul 23, 2014, Nguyễn Văn L lynguyenvan@gmail.com wrote: Thanks Tom and Marcus, So it's not necessary to run sudo gnuradio-companion at all :-) Van-Ly p/s: I am new to almost everything that I'm working with, from ubuntu to gnuradio :-) just glad to talk to you :-) Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 9:43 PM, Marcus Mller marcus.muel...@ettus.com wrote: Hi Van-Ly, So, is there any difference between *sudo gnuradio-companion* and *gnuradio-companion* ? Yes, the "sudo" part ;) sudo is used to make a program run under a different user, and in a different environment. For example, sudo gnuradio-companion runs gnuradio-companion as root. Why did you do that? But that doesn't set the PYTHONPATH environment, so python can't find the modules you installed to your local python package prefix. Greetings, Marcus On 23.07.2014 16:32, Nguyễn Văn L wrote: Hi Marcus, I've gotten a surprising thing and I couldn't explain why. First, I type: sudo gnuradio-companion to open the GNUradio and test my own module. It turned out an error message as I described in the previous mail. (ImportError: No module named Tool_NetworkCoding) However, when I just type: gnuradio-companion and also run the same grc file, the error message disappeared, and everything then seems to go well. Thank you very much Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 On Wed, Jul 23, 2014 at 6:47 PM, Marcus Mller marcus.muel...@ettus.com wrote: Hi Van-Ly, if you installed everything correctly, Python should be able to find the module. You can verify this by looking at the install_manifest.txt in your OOT's build/ directory, in which there should be an entry for every file it copied. Find your python files (there always should be an __init__.py) and check if the target location is part of your $PYTHONPATH. Greetings, MarcusOn 23.07.2014 13:35, Nguyễn Văn L wrote: Hi all, I have created a new module called Tool_NetworkCoding. During the installation, I did not get any error message, everything went well. But when I run a grc file to test some blocks inside this new module, it turned out an error message: *Traceback (most recent call last): File "/home/van-ly/Downloads/top_block.py", line 16, in module import Tool_NetworkCodingImportError: No module named Tool_NetworkCoding* Please help me with this. Thank you in advance Van-Ly Nguyen Van-Ly, Vietnam National University, Hanoi - VNU University of Engineering and Technology - UET Faculty of Electronics and Telecommunications - FET Tel: +84 978 819 406 Standing on my own two feet !!! ___ 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 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
Re: [Discuss-gnuradio] gnuradio dataflow, buffering and scheduling
Thank Vanush, I have read this presentation already; unfortunately, I found it rather hard to draw an overall picture of gnuradio scheduler to some extent of details. Perhaps, as Tom said on his webpage ( http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html) the scheduler is the most mysterious and complicated part of gnuradio - not easy to digest it Could you please provide me with some relevant or supplement readings to that presentation? I would grateful for it. My first intuitive question is that since each signal processing block does require both input and output buffers, then it may cause the source-sink latency to be significantly large. Is this true and is there any design analysis on this? With best regards, Nguyen Anh Duc On Wed, Jul 23, 2014 at 10:08 AM, Vanush Vaswani van...@gmail.com wrote: http://www.trondeau.com/storage/tutorial/gr_scheduler_overview.pdf On Wed, Jul 23, 2014 at 2:32 AM, Anh Duc Nguyen ducn...@gmail.com wrote: Dear all, I wish to study how gnuradio handles the dataflow,e.g., buffering, scheduling, synchronization, optimization as well as resultant latency in detail. However, I can not find any material that explain such things clearly. Could you please point me to direct or indirect resources e.g., in literature which present I need. I would appreciate it much, With best regards, Nguyen Anh Duc ___ 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] gnuradio dataflow, buffering and scheduling
On Wed, Jul 23, 2014 at 12:37 PM, Anh Duc Nguyen ducn...@gmail.com wrote: Thank Vanush, I have read this presentation already; unfortunately, I found it rather hard to draw an overall picture of gnuradio scheduler to some extent of details. Perhaps, as Tom said on his webpage (http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html) the scheduler is the most mysterious and complicated part of gnuradio - not easy to digest it Could you please provide me with some relevant or supplement readings to that presentation? I would grateful for it. My first intuitive question is that since each signal processing block does require both input and output buffers, then it may cause the source-sink latency to be significantly large. Is this true and is there any design analysis on this? With best regards, Nguyen Anh Duc Anh, There's a very small number of papers that are specifically about the GNU Radio scheduler. Depending on the level of detail you require the source code may be the best place (and it helps to be looking at the flowcharts in the previously mentioned slides). Second, I'm not sure what your last question is getting at. Each block has an input and an output buffer, but that buffer is shared with either the output or the input of a neighboring block. If you believe that alone is causing a high latency between source and sink then I'm curious what alternatives you have in mind. Are you looking only at GNU Radio's scheduler or schedulers in general? Almohanad Fayez's dissertation, Design Space Decomposition for Cognitive and Software Defined Radios might have some things of interest in it. He uses KPN to analyze buffer sizes (among other things). Michael Dickens' dissertation (not about GNU Radio) also has a pretty good overview of what SDR frameworks are out there and a high level design approach some notable frameworks take. Between those two dissertations there's quite a bit of reading and a great way to speed up on what's out there, especially since they're both fairly recent. Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Clock generation
HI Anusha, this is the wrong mailing list for this -- for your replies, I think it's best to join usrp-us...@lists.ettus.com [1] and continue this discussion there; I will crosspost my answer. On 23.07.2014 18:56, Yarlagadda, Anusha (337G) wrote: Hi, I am using URSPN210 series, have few questions regarding the clocking schemes for this USRP N210. In the website, its mentioned USRP2 and N200/N210 have fixed 100MHz clock which can't be tuned and do not have option to use external clock. You *can* use an external clock, but it should be a 10MHz one. We would like to use a different clock rate (49.2MHz) instead of the fixed 100MHz that is generated from the Reference and system clock generation circuit( I think all these clocks i.e fpga clock, TX/RX clock for the RF boaord ADC/DAC clock are generated by the AD9510 that has on chip PLL core and multi ouput clock distribution function). I'm afraid that doesn't fit the N210 design. You can't use an arbitrary clock rate -- the idea is to decimate your signal to a integer fraction of the master clock rate, and transport the signal at that sampling rate to the host pc for further processing, e.g. resampling. Furthermore, I'm a little curious what kind of system would preferably have a sampling rate of $49.2MHz/n, n \in [2,3,4,...]$ -- please be aware that you can't fit 49.2 MS/s of 16bit I+Q data through 1 Gigabit of ethernet! An external oscillator (U27 or external reference clock) is phase locked to a reference input reference frequency clock of the AD9510. In the USRP N210 FPGA Code can we program the divider values of AD9510 over the SPI interface so that the output clock are not fixed? As being said, the N210 design doesn't really leave much room for this. We would like to be compatible with our internal Radio waveform rates and frequencies. In this case, I recommend using a rational resampler on your host. GNU Radio comes with some -- you can try if you can match your desired sampling rate with that. With best regards, Marcus Müller [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP Network?
Do you have different ports for your different UDP streams? Greetings, Marcus On 23.07.2014 19:42, Ward, Marcus D. wrote: Hey everyone, I'm currently trying to send the same generated signal from two usrp's to a third usrp/host. On the transmitting side, I can clearly see both signals going out, but on the receiving side, I am getting a runtime error. On the UDP connection on the transmitting side, I have both destination addresses being the third usrp/host, and on the receiving end side, I incorporated two UDP source blocks (since one block can only take in one input) and have both of their addresses being the the same destination address as the transmitting side (seeing that when dealing with UDP, both sides have to have the same address in order to know where they will send and pick up the signal). Would my problem be that on my receiving side, I have both UDP sources with the same address (as I would not know which UDP source is receiving which signal)? Thanks in advance, Marcus ___ 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] UDP Network?
Hey Marcus, Yes, I checked that and on the first UDP stream, I am using port 1234 while on the second UDP stream I am using port 1240 and I am still getting: Runtime Error:bind: Cannot Assign requested address From: discuss-gnuradio-bounces+marcus.ward=jhuapl@gnu.org [mailto:discuss-gnuradio-bounces+marcus.ward=jhuapl@gnu.org] On Behalf Of Marcus Müller Sent: Wednesday, July 23, 2014 2:08 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] UDP Network? Do you have different ports for your different UDP streams? Greetings, Marcus On 23.07.2014 19:42, Ward, Marcus D. wrote: Hey everyone, I'm currently trying to send the same generated signal from two usrp's to a third usrp/host. On the transmitting side, I can clearly see both signals going out, but on the receiving side, I am getting a runtime error. On the UDP connection on the transmitting side, I have both destination addresses being the third usrp/host, and on the receiving end side, I incorporated two UDP source blocks (since one block can only take in one input) and have both of their addresses being the the same destination address as the transmitting side (seeing that when dealing with UDP, both sides have to have the same address in order to know where they will send and pick up the signal). Would my problem be that on my receiving side, I have both UDP sources with the same address (as I would not know which UDP source is receiving which signal)? Thanks in advance, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] UDP Network?
Hm, strange. Can you do ncat --listen --udp address port for both, 1234 and 1240? (If it works, kill it with ctrl-c). If it doesn't allow you to bind to that address, run ip addr to make sure you have actually assigned that address to your network interface. The error indicates that the host you're running on doesn't actually have the IP address you set in the UDP sources; are you doing NAT somewhere in between? Greetings, Marcus On 23.07.2014 20:18, Ward, Marcus D. wrote: Hey Marcus, Yes, I checked that and on the first UDP stream, I am using port 1234 while on the second UDP stream I am using port 1240 and I am still getting: Runtime Error:bind: Cannot Assign requested address From: discuss-gnuradio-bounces+marcus.ward=jhuapl@gnu.org [mailto:discuss-gnuradio-bounces+marcus.ward=jhuapl@gnu.org] On Behalf Of Marcus Müller Sent: Wednesday, July 23, 2014 2:08 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] UDP Network? Do you have different ports for your different UDP streams? Greetings, Marcus On 23.07.2014 19:42, Ward, Marcus D. wrote: Hey everyone, I'm currently trying to send the same generated signal from two usrp's to a third usrp/host. On the transmitting side, I can clearly see both signals going out, but on the receiving side, I am getting a runtime error. On the UDP connection on the transmitting side, I have both destination addresses being the third usrp/host, and on the receiving end side, I incorporated two UDP source blocks (since one block can only take in one input) and have both of their addresses being the the same destination address as the transmitting side (seeing that when dealing with UDP, both sides have to have the same address in order to know where they will send and pick up the signal). Would my problem be that on my receiving side, I have both UDP sources with the same address (as I would not know which UDP source is receiving which signal)? Thanks in advance, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Out of Tree linker error... libgnuradio-MYMOD.so: undefined reference to `gr::fft::fft_complex::execute()'
I am getting a link error when making my Out-of-Tree module. I apologize in advance for the length of this, my first post to this list. I get the daily 'digest' version. This Out of Tree module was done with gr_modtool and cmake following the outline given in http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules which, after some figuring out how my setup was missing some things, worked (make and install and runs in GRC) on another simpler block in this same module. This is a re-run of the make spew that fails to link: [jmurphy@localhost build]$ make Scanning dependencies of target gnuradio-comso [ 7%] Building CXX object lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o Linking CXX shared library libgnuradio-comso.so [ 14%] Built target gnuradio-comso Linking CXX executable test-comso libgnuradio-comso.so: undefined reference to `gr::fft::fft_complex::execute()' collect2: error: ld returned 1 exit status make[2]: *** [lib/test-comso] Error 1 make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2 make: *** [all] Error 2 [jmurphy@localhost build]$ Note - it seems to me this is saying it linked my custom code to the fft but failed to link the test code? Or am I mis-reading this? I get the same error when I throw a #define switch in my block implementation header to directly use fft_impl_fft_complex instead of gr::fft::fft_complex. To make this work, such as it is, I had download the fft_impl_fft.h header file and edit as follows. //#include fft/api.h //#include gr_complex.h #include gnuradio/fft/api.h #include gnuradio/gr_complex.h There may be a clue there, but I do not understand enough to know. Then here is the make error for this version, essentially identical. [jmurphy@localhost build]$ make Scanning dependencies of target gnuradio-comso [ 7%] Building CXX object lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o Linking CXX shared library libgnuradio-comso.so [ 14%] Built target gnuradio-comso Linking CXX executable test-comso libgnuradio-comso.so: undefined reference to `fft_impl_fft_complex::execute()' collect2: error: ld returned 1 exit status make[2]: *** [lib/test-comso] Error 1 make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2 make: *** [all] Error 2 [jmurphy@localhost build]$ I run GNU Radio Comapnion with FFT GUI's and they work fine, so clearly something is executing FFT's although that may be unrelated. I do not have any problems, for now, with any In-Tree heir blocks or with any Out-Of-Tree blocks that do not link to the FFT libraries. Also, this block uses the get_inbuf() and get_outbuf() functions for the gnuradio fft classes, under either header mentioned above, with no linker issues reported. Module name is comso, block name is ofdm_rx, block is a C++ general-type block I am running Fedora 20 with the LXDE desktop environment GNU Radio is version 3.7.3 installed using yum from the default Fedora repositories linux kernel: 3.15.6-200.fc20.x86_64 Some possibly-relevant Fedora packages already installed and latest version: gnuradio-3.7.3-1.fc20.x86_64 gnuradio-devel-3.7.3-1.fc20.x86_64 fftw-3.3.4-3.fc20.x86_64 fftw-devel-3.3.4-3.fc20.x86_64 fftw-libs-3.3.4-3.fc20.x86_64 fftw-libs-single-3.3.4-3.fc20.x86_64 fftw-libs-double-3.3.4-3.fc20.x86_64 fftw-libs-quad-3.3.4-3.fc20.x86_64 fftw-libs-long-3.3.4-3.fc20.x86_64 Anyone know what I need to do from here to make this build successfully? Am I still missing some file or something is still pointing to the wrong place? Thanks. -John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so: undefined reference to `gr::fft::fft_complex::execute()'
On Wed, Jul 23, 2014 at 4:24 PM, John Murphy jmur...@comsonics.com wrote: I am getting a link error when making my Out-of-Tree module. I apologize in advance for the length of this, my first post to this list. I get the daily 'digest' version. This Out of Tree module was done with gr_modtool and cmake following the outline given in http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules which, after some figuring out how my setup was missing some things, worked (make and install and runs in GRC) on another simpler block in this same module. This is a re-run of the make spew that fails to link: [jmurphy@localhost build]$ make Scanning dependencies of target gnuradio-comso [ 7%] Building CXX object lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o Linking CXX shared library libgnuradio-comso.so [ 14%] Built target gnuradio-comso Linking CXX executable test-comso libgnuradio-comso.so: undefined reference to `gr::fft::fft_complex::execute()' collect2: error: ld returned 1 exit status make[2]: *** [lib/test-comso] Error 1 make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2 make: *** [all] Error 2 [jmurphy@localhost build]$ Note - it seems to me this is saying it linked my custom code to the fft but failed to link the test code? Or am I mis-reading this? In lib/CMakeLists.txt, look for the include(GrTest) line. Underneath a few lines there should be a target_link_libraries. You need to make sure that this includes the proper libraries needed to build the executable. For your purposes, you probably need the fftw3f library as well. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so: undefined reference to `gr::fft::fft_complex::execute()'
Hi John,
I think you're on the right track:
you use gr-fft in your code, but then don't tell your linker to link
against that, which leaves your libgnuradio-comso missing the symbols
from gr::fft, which breaks linking test-comso.
So what you need to do is edit your CMakeLists.txt in your module's root
dir and replace
set(GR_REQUIRED_COMPONENTS RUNTIME)
by
set(GR_REQUIRED_COMPONENTS RUNTIME FFT)
which will add the necessary linker directives, usually.
Then you will need to add
${GNURADIO_FFT_LIBRARY_DIRS}
to your
link_directories(...)
further down.
now, in your lib/ directory, edit the CMakeLists.txt
and extend the target_link_libraries(yourmodule...) directive with
${GNURADIO_FFT_LIBRARIES}
and do the same for the test-yourmodule target_link_libraries.
Hm. Maaaybe we should be adding some more CMake magic, but then again,
CMake is hard and mean :/
Greetings,
Marcus
On 23.07.2014 22:24, John Murphy wrote:
I am getting a link error when making my Out-of-Tree module.
I apologize in advance for the length of this, my first post to this list. I
get the daily 'digest' version.
This Out of Tree module was done with gr_modtool and cmake following the
outline given in
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules which,
after some figuring out how my setup was missing some things, worked (make
and install and runs in GRC) on another simpler block in this same module.
This is a re-run of the make spew that fails to link:
[jmurphy@localhost build]$ make
Scanning dependencies of target gnuradio-comso
[ 7%] Building CXX object lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o
Linking CXX shared library libgnuradio-comso.so
[ 14%] Built target gnuradio-comso
Linking CXX executable test-comso
libgnuradio-comso.so: undefined reference to `gr::fft::fft_complex::execute()'
collect2: error: ld returned 1 exit status
make[2]: *** [lib/test-comso] Error 1
make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2
make: *** [all] Error 2
[jmurphy@localhost build]$
Note - it seems to me this is saying it linked my custom code to the fft but
failed to link the test code? Or am I mis-reading this?
I get the same error when I throw a #define switch in my block implementation
header to directly use fft_impl_fft_complex instead of gr::fft::fft_complex.
To make this work, such as it is, I had download the fft_impl_fft.h header
file and edit as follows.
//#include fft/api.h
//#include gr_complex.h
#include gnuradio/fft/api.h
#include gnuradio/gr_complex.h
There may be a clue there, but I do not understand enough to know.
Then here is the make error for this version, essentially identical.
[jmurphy@localhost build]$ make
Scanning dependencies of target gnuradio-comso
[ 7%] Building CXX object lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o
Linking CXX shared library libgnuradio-comso.so
[ 14%] Built target gnuradio-comso
Linking CXX executable test-comso
libgnuradio-comso.so: undefined reference to `fft_impl_fft_complex::execute()'
collect2: error: ld returned 1 exit status
make[2]: *** [lib/test-comso] Error 1
make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2
make: *** [all] Error 2
[jmurphy@localhost build]$
I run GNU Radio Comapnion with FFT GUI's and they work fine, so clearly
something is executing FFT's although that may be unrelated. I do not have
any problems, for now, with any In-Tree heir blocks or with any Out-Of-Tree
blocks that do not link to the FFT libraries.
Also, this block uses the get_inbuf() and get_outbuf() functions for the
gnuradio fft classes, under either header mentioned above, with no linker
issues reported.
Module name is comso, block name is ofdm_rx, block is a C++ general-type block
I am running Fedora 20 with the LXDE desktop environment
GNU Radio is version 3.7.3 installed using yum from the default Fedora
repositories
linux kernel: 3.15.6-200.fc20.x86_64
Some possibly-relevant Fedora packages already installed and latest version:
gnuradio-3.7.3-1.fc20.x86_64
gnuradio-devel-3.7.3-1.fc20.x86_64
fftw-3.3.4-3.fc20.x86_64
fftw-devel-3.3.4-3.fc20.x86_64
fftw-libs-3.3.4-3.fc20.x86_64
fftw-libs-single-3.3.4-3.fc20.x86_64
fftw-libs-double-3.3.4-3.fc20.x86_64
fftw-libs-quad-3.3.4-3.fc20.x86_64
fftw-libs-long-3.3.4-3.fc20.x86_64
Anyone know what I need to do from here to make this build successfully? Am I
still missing some file or something is still pointing to the wrong place?
Thanks.
-John
___
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] Out of Tree linker error... libgnuradio-MYMOD.so: undefined reference to `gr::fft::fft_complex::execute()'
Ah, by the way, look for gr-specest [1]; you can look at it as an
example of using gr-fft, fftw itself, some more gnuradio modules, and
the idyllic language called fortran in an out-of-tree module.
Greetings,
Marcus
[1] https://github.com/kit-cel/gr-specest
On 23.07.2014 22:36, Marcus Müller wrote:
Hi John,
I think you're on the right track:
you use gr-fft in your code, but then don't tell your linker to link
against that, which leaves your libgnuradio-comso missing the symbols
from gr::fft, which breaks linking test-comso.
So what you need to do is edit your CMakeLists.txt in your module's root
dir and replace
set(GR_REQUIRED_COMPONENTS RUNTIME)
by
set(GR_REQUIRED_COMPONENTS RUNTIME FFT)
which will add the necessary linker directives, usually.
Then you will need to add
${GNURADIO_FFT_LIBRARY_DIRS}
to your
link_directories(...)
further down.
now, in your lib/ directory, edit the CMakeLists.txt
and extend the target_link_libraries(yourmodule...) directive with
${GNURADIO_FFT_LIBRARIES}
and do the same for the test-yourmodule target_link_libraries.
Hm. Maaaybe we should be adding some more CMake magic, but then again,
CMake is hard and mean :/
Greetings,
Marcus
On 23.07.2014 22:24, John Murphy wrote:
I am getting a link error when making my Out-of-Tree module.
I apologize in advance for the length of this, my first post to this list. I
get the daily 'digest' version.
This Out of Tree module was done with gr_modtool and cmake following the
outline given in
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules which,
after some figuring out how my setup was missing some things, worked (make
and install and runs in GRC) on another simpler block in this same module.
This is a re-run of the make spew that fails to link:
[jmurphy@localhost build]$ make
Scanning dependencies of target gnuradio-comso
[ 7%] Building CXX object
lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o
Linking CXX shared library libgnuradio-comso.so
[ 14%] Built target gnuradio-comso
Linking CXX executable test-comso
libgnuradio-comso.so: undefined reference to
`gr::fft::fft_complex::execute()'
collect2: error: ld returned 1 exit status
make[2]: *** [lib/test-comso] Error 1
make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2
make: *** [all] Error 2
[jmurphy@localhost build]$
Note - it seems to me this is saying it linked my custom code to the fft but
failed to link the test code? Or am I mis-reading this?
I get the same error when I throw a #define switch in my block
implementation header to directly use fft_impl_fft_complex instead of
gr::fft::fft_complex. To make this work, such as it is, I had download the
fft_impl_fft.h header file and edit as follows.
//#include fft/api.h
//#include gr_complex.h
#include gnuradio/fft/api.h
#include gnuradio/gr_complex.h
There may be a clue there, but I do not understand enough to know.
Then here is the make error for this version, essentially identical.
[jmurphy@localhost build]$ make
Scanning dependencies of target gnuradio-comso
[ 7%] Building CXX object
lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o
Linking CXX shared library libgnuradio-comso.so
[ 14%] Built target gnuradio-comso
Linking CXX executable test-comso
libgnuradio-comso.so: undefined reference to
`fft_impl_fft_complex::execute()'
collect2: error: ld returned 1 exit status
make[2]: *** [lib/test-comso] Error 1
make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2
make: *** [all] Error 2
[jmurphy@localhost build]$
I run GNU Radio Comapnion with FFT GUI's and they work fine, so clearly
something is executing FFT's although that may be unrelated. I do not have
any problems, for now, with any In-Tree heir blocks or with any Out-Of-Tree
blocks that do not link to the FFT libraries.
Also, this block uses the get_inbuf() and get_outbuf() functions for the
gnuradio fft classes, under either header mentioned above, with no linker
issues reported.
Module name is comso, block name is ofdm_rx, block is a C++ general-type
block
I am running Fedora 20 with the LXDE desktop environment
GNU Radio is version 3.7.3 installed using yum from the default Fedora
repositories
linux kernel: 3.15.6-200.fc20.x86_64
Some possibly-relevant Fedora packages already installed and latest version:
gnuradio-3.7.3-1.fc20.x86_64
gnuradio-devel-3.7.3-1.fc20.x86_64
fftw-3.3.4-3.fc20.x86_64
fftw-devel-3.3.4-3.fc20.x86_64
fftw-libs-3.3.4-3.fc20.x86_64
fftw-libs-single-3.3.4-3.fc20.x86_64
fftw-libs-double-3.3.4-3.fc20.x86_64
fftw-libs-quad-3.3.4-3.fc20.x86_64
fftw-libs-long-3.3.4-3.fc20.x86_64
Anyone know what I need to do from here to make this build successfully? Am
I still missing some file or something is still pointing to the wrong place?
Thanks.
-John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
Re: [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so: undefined reference to `gr::fft::fft_complex::execute()'
On Wed, 23 Jul 2014 16:33:50 -0400 Tom Rondeau t...@trondeau.com wrote: On Wed, Jul 23, 2014 at 4:24 PM, John Murphy jmur...@comsonics.com wrote: I am getting a link error when making my Out-of-Tree module. This Out of Tree module was done with gr_modtool and cmake following the outline given in http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules which, after some figuring out how my setup was missing some things, worked (make and install and runs in GRC) on another simpler block in this same module. This is a re-run of the make spew that fails to link: [jmurphy@localhost build]$ make Scanning dependencies of target gnuradio-comso [ 7%] Building CXX object lib/CMakeFiles/gnuradio-comso.dir/ofdm_rx_impl.cc.o Linking CXX shared library libgnuradio-comso.so [ 14%] Built target gnuradio-comso Linking CXX executable test-comso libgnuradio-comso.so: undefined reference to `gr::fft::fft_complex::execute()' collect2: error: ld returned 1 exit status make[2]: *** [lib/test-comso] Error 1 make[1]: *** [lib/CMakeFiles/test-comso.dir/all] Error 2 make: *** [all] Error 2 [jmurphy@localhost build]$ In lib/CMakeLists.txt, look for the include(GrTest) line. Underneath a few lines there should be a target_link_libraries. You need to make sure that this includes the proper libraries needed to build the executable. For your purposes, you probably need the fftw3f library as well. Thanks for the timely help. I tried this with no luck yet. I added fftw3f to the bottom of the list where you indicated and it did not change anything (other than a slight alteration because it detected a change in the file I suppose). Same error message at the same point. I also tried libfftw3f instead since I was not certain of the syntax here, and that actually gave me something like a library not found warning. So that at least confirms just fftw3f must indeed be the correct syntax verbatim and it does find that library on my system. Just to try it... I also added fftw3f to the end of the target_link_libraries list for include(GrPlatform) in the same CMakeLists file. But this made no relevant change to the make spew that I saw (the spew is pretty long when you edit the cmake text file because you get a ton of -Wno-dev supressable warnings, at least on my system). I also tried this with my #define switch for gr::fft::fft_complex versus fft_impl_fft_complex set both ways, with still no difference there other than which class is quoted in the error. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio dataflow, buffering and scheduling
Thank Nathan and Marcus, Yes, as you said the source code should be the best place to study the details. However, as you may experience, it is fairly challenging to just look at the code, analyze, and make connections among stuffs. It should be better if there are some references to guide us through the complicated codes such as the one Tom wrote, hopefully, there should be more similar presentations/documents like that. With that references, I believe we can have got how gnuradio works more comprehensively and more rapidly. I also agree it is not easy to describe the scheduler in a short, simple, but pretty in-depth ways; then I have asked for just some supplement readings Thank Nathan for your recommended two dissertations, I have just given them a quick look, and they appear to satisfy my desire. I also thank Marcus for key points and trends in the gnuradio scheduler and your frank suggestions how to approach the problems. To be honest, I am studying software structures/platform for software defined radio (SDR), of which, the scheduler is one of the most crucial that I wish to analyze in detail; and in turn, gnuradio scheduler for sure draws much of my attention due to it success and popularity. I hope I could receive more support and help from you all With best regards, Nguyen Anh Duc On Thu, Jul 24, 2014 at 12:51 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Anh, in addition to what Nathan explained very nicely, I'd like to point out that the GNU Radio scheduler is not a static thing, it's actively being worked on. Whilst the buffer architecture dates back quite a while, things like message passing and the associated asynchronous communication between blocks are fairly new. Also, you have to realize that there were several approaches to scheduling of GNU Radio blocks over the time -- right now, it seems that GNU Radio has largely settled for the Thread-Per-Block scheduler, that has one block_executors per block that itself runs in a thread of its own. You asked: Could you please provide me with some relevant or supplement readings to that presentation? I would grateful for it. I think since you have your very own level of understanding, your very own background in data processing and scheduling, and your very own interest in details, there will be no way around reading at least block_executor and some of the tpb_ stuff in detail, with a big piece of paper/whiteboard at hand and trying to understand these concepts yourself. Although scheduling is always a bit of a convoluted task, I find the thread-per-block architecture fairly understandable, and the idea of blocks notifying their neighbors' threads when they have finished filling/reading a buffer quite intuitive. The details, however, like how the scheduler keeps record of the flowgraph, how GNU Radio allocates and manages the circular buffers, and what happens when you reconfigure a graph, are so specific, that it's hard to write a text about it that is shorter or easier to understand for the skilled reader than the code itself. I'm afraid that's the reason that only Tom (and maybe, in very simplifying attempts, some GSoC student[1]) has written relevant details on that. That being said, Explain what the scheduler does, so that beginners understand it and experts get an in-depth comprehension has been on the GNU Radio needs this list for as long as I've been meddling with GNU Radio -- and that's really not because no one else had this problem, but because it is a hard thing to understand and a harder thing to textually represent correctly. Greetings, Marcus [1] http://gsoc.hostalia.de/posts/a-measurement-toolbox-for-gnu-radio-my-google-summer-of-code-project.html#evaluating-block-performance but that barely scratches the subject On 23.07.2014 18:37, Anh Duc Nguyen wrote: Thank Vanush, I have read this presentation already; unfortunately, I found it rather hard to draw an overall picture of gnuradio scheduler to some extent of details. Perhaps, as Tom said on his webpage (http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html) the scheduler is the most mysterious and complicated part of gnuradio - not easy to digest it Could you please provide me with some relevant or supplement readings to that presentation? I would grateful for it. My first intuitive question is that since each signal processing block does require both input and output buffers, then it may cause the source-sink latency to be significantly large. Is this true and is there any design analysis on this? With best regards, Nguyen Anh Duc On Wed, Jul 23, 2014 at 10:08 AM, Vanush Vaswani van...@gmail.com van...@gmail.com wrote: http://www.trondeau.com/storage/tutorial/gr_scheduler_overview.pdf On Wed, Jul 23, 2014 at 2:32 AM, Anh Duc Nguyen ducn...@gmail.com ducn...@gmail.com wrote: Dear all, I wish to study how gnuradio handles the dataflow,e.g., buffering,
Re: [Discuss-gnuradio] QAM Mod / Demod blocks
On Wed, Jul 23, 2014 at 9:45 PM, Tom Rondeau t...@trondeau.com wrote: On Wed, Jul 23, 2014 at 8:42 AM, Activecat active...@gmail.com wrote: Dear Sir, I am learning to use the built-in QAM Mod and QAM Demod blocks. Refer below flowgraph. The problem is, at the output of the QAM Demod block, I can't get what I fed into the QAM Mod block. What is missing ..? All modulators take in packed bits and all demodulators output unpacked bits. First, remember that there are filters involved, so there's going to be a delay. You'd need to synchronize the output of the demodulator to some known word to understand which output bit is the correct start of the data stream. Easier would be to unpack the source data. Out of the 'head' block, make another connection to a 'unpack_k_bits' block with an unpacking value of 8. Use this to compare to the demodulated bits. Also, the vector source should generate values from 0 to 255 to create the packed bits needed as input to the modulator. Otherwise, you'll just be heavily biasing the constellation to just a few points. You can stick a constellation display block on the output of the modulator to see. Tom Thank you very much. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
