Re: [Discuss-gnuradio] Activating/Deactivating Blocks in real time
On Wed, Oct 2, 2013 at 11:06 PM, Achilleas Anastasopoulos anas...@umich.edu wrote: I guess I forgot to make this one thing more clear: I would like the input stream of block A to be consumed even when s(t)=1. With Tim's suggestion, when s(t)=1 we will have the right output, but the input will be waiting in block's A queue to be processed the moment s(t) turns 0. Is this correct, or am I missing something? But this gives me the following idea: I guess what i need in addition to that is a block that based on s(t) either sends the input to the output when s(t)==0 (which is then connected to A), or just consumes the input (when s(t)==1). Is there such a block available? (even if not, this is pretty easy to write!) Any comments on this? thanks for the hints and ideas! Achilleas Achilleas, I solved a similar problem by creating a general block that consumes an input stream on some condition, and passes it otherwise. If you pair this with another block that tags a sample where passing or rejecting should begin (correlate_access_code_tag?) it works quite nicely. With this approach you could use the control pin idea, but I would recommend tags to keep it cleaner. Looking at this might help you get going a little faster if this sounds like it would work for you: https://github.com/n-west/gr-west_3_6/blob/master/lib/filter_payload_impl.cc It's a little messy because I was trying (and more or less failied) to make it dynamic and allow multiple streams coming in to be synchronized and let any input stream control output of all streams. It also still uses 3.6 API (I know, the shame!) -Nathan On Wed, Oct 2, 2013 at 5:51 PM, Monahan-Mitchell, Tim tmona...@qti.qualcomm.com wrote: Can you do this with a 2:1 mux block? Input 2 = constant 0, control input is s(t)? ** ** *From:* discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org[mailto: discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org] *On Behalf Of *Achilleas Anastasopoulos *Sent:* Wednesday, October 02, 2013 3:48 PM *To:* Discuss-gnuradio@gnu.org *Subject:* [Discuss-gnuradio] Activating/Deactivating Blocks in real time ** ** I have the following problem that I would like your opinion on how to solve elegantly: I have a block A (say a standard sync block with some memory--eg an fir filter) which has input x(t) and output y(t) and is pretty computationally intensive.** ** I would like to add the following functionality to it: Add a new input s(t) to A which can be 0 or 1. When s(t)=1 the block operates as before ie, it processes x(t) to generate y(t). If s(t)=0 I would like it to output y(t)=0 and consume the appropriate x(t)'s from the input. This way when s(t)=0 block A essentially does not work. ** ** This is pretty straightforward to code if I modify the work function of block A. However, block A for me is a pretty complicated hierarchical block, so I don't have access to its work function. One way to do this is to rewrite the whole hierarchical block A as a flat block and then do as suggested above. Is there a better way? ** ** Thanks Achilleas ** ** ___ 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] [Openlte-discuss] Error while building openLTE code on USRP
Dincer, Hopefully this will clarify things a bit: 1) The dl_scan application will not work with USRP currently due to the resampling issue. Since gr-osmosdr will support USRP, the dl_scan application should run using a USRP, but the sampling rate will be incorrect and it will not decode anything. This is the application that will need to have a resampler block added. 2) The dl_file_scan application is not dependent on any hardware. It just uses a recorded baseband I/Q file for its processing. However, the file must be recorded at one of the valid LTE sampling rates. So again, if you are using the USRP, you will have to resample the data. I have found that the octave function resample works great for this task. I have not worked with grc in the past, so I can help much with anything you do there. However, you can modify LTE_fdd_dl_scan_flowgraph.cc directly if you need. Hope this helps, Ben On Tue, Oct 1, 2013 at 10:08 AM, Dincer Beken dbe...@blackned.de wrote: Hi Ben, ** ** thank you for your answer. ** ** My previous question was bit strange. ** ** There are to functions of you, once the dl_file_scan and once the only dl_scan function. ** ** I did undertood that the dl_file_scan function kinda works with USRP, but I was not sure about the dl_scan function. ** ** I read here that dl_scan does not support USRP: http://sourceforge.net/p/openlte/mailman/message/30559702/ ** ** Is it still valid: Does the dl_scan function still not suppoert USRP? ** ** OR can we by adding the resampler block run it? When I did run the dl_scan function, it (probably the osmo code) recognized the USRP2/N-SERIES device and got overflow alerts (“D”). I don’t undertand, if that means that the dl_scan function works with the USRP2/N but needs some resampling? ** ** So from your mail, I thought first the addition of the “resampler” is only valid for the dl_file_scan function, till I managed to run the dl_scan, thatswhy I am confused. ** ** ** ** Lastly, (this is probably my job). I don’t know if one can create from your source files grc flowcharts. I looking for that right now. Then, it would be “easy” to add a resampling block to your code. If not, could you also please give a hint about how it can be done in your source code? ** ** Regards, Dincer *Von:* Ben Wojtowicz [mailto:bwojt...@gmail.com] *Gesendet:* Dienstag, 1. Oktober 2013 14:47 *An:* Dincer Beken *Cc:* openlte-disc...@lists.sourceforge.net; Discuss-gnuradio@gnu.org *Betreff:* Re: [Openlte-discuss] Error while building openLTE code on USRP ** ** Dincer, I believe that you will need to add a resampler to the openLTE code in order to run on a USRP. I don't have a USRP myself, but I believe that they only allow sample rates that are integer divisions of 100Msps (except the USRP B200 series). In order to get a valid LTE sample rate (30.72, 15.36, 7.68, 3.84, or 1.92Msps), you will need to add a resampling block.* *** As you mentioned, I am using the gr-osmosdr blocks to interface currently to rtl-sdr and hackRF. There is support in gr-osmosdr for USRP, but it will need to be handled in the flowgraph. Hope this helps, Ben ** ** On Mon, Sep 30, 2013 at 7:21 AM, Dincer Beken dbe...@blackned.de wrote:* *** Sorry but I think I mailed to early. On a normal gnuradio distribution from the build-gnuradio.py -m” code on Fedora, I did not experience the problems while build and install. I am checking out the code right now.. Regarding OSMO and RTL-SDR, I did understand it like the libraries can detect and work with USRP, so that’s probably clear, too. When using those libraries with USRP, are there any specific changes that I should make for some blocks etc.? Regards, Dincer *Von:* discuss-gnuradio-bounces+dbeken=blackned...@gnu.org [mailto: discuss-gnuradio-bounces+dbeken=blackned...@gnu.org] *Im Auftrag von *Dincer Beken *Gesendet:* Montag, 30. September 2013 13:42 *An:* openlte-disc...@lists.sourceforge.net *Cc:* Discuss-gnuradio@gnu.org *Betreff:* [Discuss-gnuradio] Error while building openLTE code on USRP*** * Hi all, I am new to Gnuradio and USRP. I want to try the openLTE Project on my USRP N210. During the cmake process I am getting the following errors: CMake Warning at CMakeLists.txt:92 (find_package): Could not find a configuration file for package Gnuradio that is compatible with requested version 3.7.0. The following configuration files were considered but not accepted: /usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 3.8.git.0 Also since I am not using one of the following devices: I also get : -- checking for module 'gnuradio-osmosdr' -- package 'gnuradio-osmosdr' not
Re: [Discuss-gnuradio] Summary of desires for GRC, just discuss on the #ghuradio channel
o some kind of organizer for parameters and variables I'll take one of those, please. I can see how it might be a tricky feature though. Do you aggregate existing variables, but allow editing/viewing them from a single pane, or just scrap it all and have one multi-variable block? I would go with simply either adding a new multi-variable block, or modifying the existing one to allow multiple variables. Don't do any 'automatic' variable aggregation. o A way to make Note blocks larger and maybe multi-line Notes are cool, but their context can be easily lost when moving blocks around. I always thought that each block ought to have a comment field among the other properties, which is just a dumb text blob. When you generate the python, this could even be inserted as a real python comment. I can't say how many times I've opened a block and thought, why is that property set to that value? A contextual comment for the block would help there I think. If you want to get really crazy, you could even display a truncated version of it on the block itself in the FG, the same way values are shown. I second the request for a 'notes' field for all blocks, but also want to have a more flexible 'note' block. Ideally, it would support multi-line (HTML-formatted?) text, and allow setting the size/shape manually. -Greg ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRcon13 video stream on ustream
Someone is streaming the talks today. URL: ustre.am/15Ale ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Summary of desires for GRC, just discuss on the #ghuradio channel
On Thu, Oct 3, 2013 at 9:35 AM, Gregory Warnes g...@warnes.net wrote: I would go with simply either adding a new multi-variable block, or modifying the existing one to allow multiple variables. Don't do any 'automatic' variable aggregation. I agree that it shouldn't be automatic. I was thinking something like: 1. Select a bunch of blocks 2. Choose create group 3. A new group symbol appears (visually like three rectangles in a stack, viewed from above) 4. The previously selected blocks are moved into the group 5. If you double-click the group, a box is displayed over the current graph that lets you see its contents. For the open group, I'm imagining something like a toolbox-style box that can be dragged around the graph (and left open), complete with a little grey title bar and a minimize button that restores it to its icon state. That way you can leave it open and work with it until you're done, then minimize it to its icon form when you've finished working with its contents. I can only imagine this making sense for blocks that don't need any I/O - or even perhaps for blocks that only have connections among each other. Visually showing connections going into or out of a group might be tricky. Ethan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pybombs update fails - or is it just me?
This problem has been fixed now - thanks a lot! Updating Pybombs should resolve the issue. Original Message Subject:Re: [pybombs] pybombs update fails with package not found followed by FIRST LETTER OF PKGNAME (#32) Date: Thu, 03 Oct 2013 06:21:43 -0700 From: osh notificati...@github.com Reply-To: pybombs/pybombs reply+i-20395094-546de77d9b329098241ee4182fc20dbc161c5eb9-5022...@reply.github.com To: pybombs/pybombs pybo...@noreply.github.com CC: mark-orion i...@mdammer.net this has now been fixed update was expecting a list of strings instead of a string - there is now a check ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] XInitThread QT standard app template
Hi, So, when looking where to add the XInitThread call inside GR, for some places it's obvious and for some it's not. The gnuradio companion template is an obvious place. For WX, the class stdapp is also a pretty obvious choice because a lot of external app use that template and so will not require changes. For QT it's not as easy. AFAICT, all the example python QT applications just have their own init code that create the QApplication themselves. And I think that creating the equivalent of stdapp inside the qtgui python package could probably be useful for all python app with qt widget to use. And then I could stick my XinitThread in there. For C++ app, well I doubt there is any good solution, it'll be the job of whatever app that uses a Qt widget needing multi-threaded gui access to call this itself. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Buffering samples from USRP
Hi all, I'm looking for something like a buffer block to include inside a C++ flowgraph. I'm getting samples off an USRP N210 at ~17MSamps/sec, and they enter the flowgraph through an OsmoSDR source block. Unfortunately the downstream block (openLTE) cannot initially keep up with the data rate, and samples are lost inside the UDP kernel buffer. Later, the downstream block changes into a faster state and I expect it to decrease the buffer fill level. The docs (http://files.ettus.com/uhd_docs/manual/html/transport.html) suggest to increase the kernel buffer, but I was wondering if there would be a way to include a buffer inside the flowgraph? I've come across gr::buffer, but it doesn't seem to be what I need (http://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00345.html) Many thanks! Till ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Openlte-discuss] Error while building openLTE code on USRP
Hi Ben, many thanks for your clarifying answer. I will need to think little bit about 2). But I have another Question: Why did you not use a usual Python flowgraph (like in file scan) but a C++ flowgraph? Is there anywhere a python flowgraph for the live scan app? Thanks again, Dincer Von: Ben Wojtowicz [mailto:bwojt...@gmail.com] Gesendet: Donnerstag, 3. Oktober 2013 14:40 An: Dincer Beken Cc: Discuss-gnuradio@gnu.org; openlte-disc...@lists.sourceforge.net Betreff: Re: [Openlte-discuss] Error while building openLTE code on USRP Dincer, Hopefully this will clarify things a bit: 1) The dl_scan application will not work with USRP currently due to the resampling issue. Since gr-osmosdr will support USRP, the dl_scan application should run using a USRP, but the sampling rate will be incorrect and it will not decode anything. This is the application that will need to have a resampler block added. 2) The dl_file_scan application is not dependent on any hardware. It just uses a recorded baseband I/Q file for its processing. However, the file must be recorded at one of the valid LTE sampling rates. So again, if you are using the USRP, you will have to resample the data. I have found that the octave function resample works great for this task. I have not worked with grc in the past, so I can help much with anything you do there. However, you can modify LTE_fdd_dl_scan_flowgraph.cc directly if you need. Hope this helps, Ben On Tue, Oct 1, 2013 at 10:08 AM, Dincer Beken dbe...@blackned.demailto:dbe...@blackned.de wrote: Hi Ben, thank you for your answer. My previous question was bit strange. There are to functions of you, once the dl_file_scan and once the only dl_scan function. I did undertood that the dl_file_scan function kinda works with USRP, but I was not sure about the dl_scan function. I read here that dl_scan does not support USRP: http://sourceforge.net/p/openlte/mailman/message/30559702/ Is it still valid: Does the dl_scan function still not suppoert USRP? OR can we by adding the resampler block run it? When I did run the dl_scan function, it (probably the osmo code) recognized the USRP2/N-SERIES device and got overflow alerts (D). I don't undertand, if that means that the dl_scan function works with the USRP2/N but needs some resampling? So from your mail, I thought first the addition of the resampler is only valid for the dl_file_scan function, till I managed to run the dl_scan, thatswhy I am confused. Lastly, (this is probably my job). I don't know if one can create from your source files grc flowcharts. I looking for that right now. Then, it would be easy to add a resampling block to your code. If not, could you also please give a hint about how it can be done in your source code? Regards, Dincer Von: Ben Wojtowicz [mailto:bwojt...@gmail.commailto:bwojt...@gmail.com] Gesendet: Dienstag, 1. Oktober 2013 14:47 An: Dincer Beken Cc: openlte-disc...@lists.sourceforge.netmailto:openlte-disc...@lists.sourceforge.net; Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org Betreff: Re: [Openlte-discuss] Error while building openLTE code on USRP Dincer, I believe that you will need to add a resampler to the openLTE code in order to run on a USRP. I don't have a USRP myself, but I believe that they only allow sample rates that are integer divisions of 100Msps (except the USRP B200 series). In order to get a valid LTE sample rate (30.72, 15.36, 7.68, 3.84, or 1.92Msps), you will need to add a resampling block. As you mentioned, I am using the gr-osmosdr blocks to interface currently to rtl-sdr and hackRF. There is support in gr-osmosdr for USRP, but it will need to be handled in the flowgraph. Hope this helps, Ben On Mon, Sep 30, 2013 at 7:21 AM, Dincer Beken dbe...@blackned.demailto:dbe...@blackned.de wrote: Sorry but I think I mailed to early. On a normal gnuradio distribution from the build-gnuradio.py -m code on Fedora, I did not experience the problems while build and install. I am checking out the code right now.. Regarding OSMO and RTL-SDR, I did understand it like the libraries can detect and work with USRP, so that's probably clear, too. When using those libraries with USRP, are there any specific changes that I should make for some blocks etc.? Regards, Dincer Von: discuss-gnuradio-bounces+dbeken=blackned...@gnu.orgmailto:blackned...@gnu.org [mailto:discuss-gnuradio-bounces+dbekenmailto:discuss-gnuradio-bounces%2Bdbeken=blackned...@gnu.orgmailto:blackned...@gnu.org] Im Auftrag von Dincer Beken Gesendet: Montag, 30. September 2013 13:42 An: openlte-disc...@lists.sourceforge.netmailto:openlte-disc...@lists.sourceforge.net Cc: Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org Betreff: [Discuss-gnuradio] Error while building openLTE code on USRP Hi all, I am new to Gnuradio and USRP. I want to try the openLTE Project on my USRP N210. During the cmake process I am getting the following errors: CMake Warning at
Re: [Discuss-gnuradio] [Openlte-discuss] Error while building openLTE code on USRP
Dincer - Why did you not use a usual Python flowgraph (like in file scan) but a C++ flowgraph? Python flowgraphs aren't any more 'usual' than C++ flowgraphs. Python is perhaps more widely used because that is how GRC generates flowgraphs, but many applications, especially those that need low-level control of memory, are written in C++. Both are natively supported by GNURadio - it's just up to the application developer which is more appropriate. Cheers, Ben Is there anywhere a python flowgraph for the live scan app? ** ** Thanks again, Dincer ** ** *Von:* Ben Wojtowicz [mailto:bwojt...@gmail.com] *Gesendet:* Donnerstag, 3. Oktober 2013 14:40 *An:* Dincer Beken *Cc:* Discuss-gnuradio@gnu.org; openlte-disc...@lists.sourceforge.net *Betreff:* Re: [Openlte-discuss] Error while building openLTE code on USRP ** ** Dincer, Hopefully this will clarify things a bit: 1) The dl_scan application will not work with USRP currently due to the resampling issue. Since gr-osmosdr will support USRP, the dl_scan application should run using a USRP, but the sampling rate will be incorrect and it will not decode anything. This is the application that will need to have a resampler block added. 2) The dl_file_scan application is not dependent on any hardware. It just uses a recorded baseband I/Q file for its processing. However, the file must be recorded at one of the valid LTE sampling rates. So again, if you are using the USRP, you will have to resample the data. I have found that the octave function resample works great for this task. I have not worked with grc in the past, so I can help much with anything you do there. However, you can modify LTE_fdd_dl_scan_flowgraph.cc directly if you need. Hope this helps, Ben ** ** On Tue, Oct 1, 2013 at 10:08 AM, Dincer Beken dbe...@blackned.de wrote:* *** Hi Ben, thank you for your answer. My previous question was bit strange. There are to functions of you, once the dl_file_scan and once the only dl_scan function. I did undertood that the dl_file_scan function kinda works with USRP, but I was not sure about the dl_scan function. I read here that dl_scan does not support USRP: http://sourceforge.net/p/openlte/mailman/message/30559702/ Is it still valid: Does the dl_scan function still not suppoert USRP? OR can we by adding the resampler block run it? When I did run the dl_scan function, it (probably the osmo code) recognized the USRP2/N-SERIES device and got overflow alerts (“D”). I don’t undertand, if that means that the dl_scan function works with the USRP2/N but needs some resampling? So from your mail, I thought first the addition of the “resampler” is only valid for the dl_file_scan function, till I managed to run the dl_scan, thatswhy I am confused. Lastly, (this is probably my job). I don’t know if one can create from your source files grc flowcharts. I looking for that right now. Then, it would be “easy” to add a resampling block to your code. If not, could you also please give a hint about how it can be done in your source code? Regards, Dincer *Von:* Ben Wojtowicz [mailto:bwojt...@gmail.com] *Gesendet:* Dienstag, 1. Oktober 2013 14:47 *An:* Dincer Beken *Cc:* openlte-disc...@lists.sourceforge.net; Discuss-gnuradio@gnu.org *Betreff:* Re: [Openlte-discuss] Error while building openLTE code on USRP Dincer, I believe that you will need to add a resampler to the openLTE code in order to run on a USRP. I don't have a USRP myself, but I believe that they only allow sample rates that are integer divisions of 100Msps (except the USRP B200 series). In order to get a valid LTE sample rate (30.72, 15.36, 7.68, 3.84, or 1.92Msps), you will need to add a resampling block.* *** As you mentioned, I am using the gr-osmosdr blocks to interface currently to rtl-sdr and hackRF. There is support in gr-osmosdr for USRP, but it will need to be handled in the flowgraph. Hope this helps, Ben On Mon, Sep 30, 2013 at 7:21 AM, Dincer Beken dbe...@blackned.de wrote:* *** Sorry but I think I mailed to early. On a normal gnuradio distribution from the build-gnuradio.py -m” code on Fedora, I did not experience the problems while build and install. I am checking out the code right now.. Regarding OSMO and RTL-SDR, I did understand it like the libraries can detect and work with USRP, so that’s probably clear, too. When using those libraries with USRP, are there any specific changes that I should make for some blocks etc.? Regards, Dincer *Von:* discuss-gnuradio-bounces+dbeken=blackned...@gnu.org [mailto: discuss-gnuradio-bounces+dbeken=blackned...@gnu.org] *Im
[Discuss-gnuradio] FOSDEM 2014 GNU Radio
Hi everyone, I'm very happy to announce that there will be an SDR-themed developer room at FOSDEM 2014. FOSDEM is an annual event for free software people of all shapes and colours. It always takes place in Brussels; the next FOSDEM will happen on 1 2 February 2014. For more info on this event see https://fosdem.org/. I believe this is an awesome opportunity to network developers in the SDR scene, specifically in Europe. We will keep you updated on the details, but the gist of it will be that we do a mini-conference within FOSDEM to talk SDR etc. At some point, we will be asking people to volunteer for doing talks. Also, I'd like to thank Phil, he deserves all the praise for getting this done. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpWWSfDQqUyQ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pybombs update fails - or is it just me?
Thanks for fixing it - it works for me too now, although trying to update gnuradio gives the error: remote branch master does not exist on git:// http://www.gnuradio.org/git/gnuradio.git I assume this is a gnuradio/git issue. Alex On Thu, Oct 3, 2013 at 5:29 PM, M Dammer i...@mdammer.net wrote: This problem has been fixed now - thanks a lot! Updating Pybombs should resolve the issue. Original Message Subject: Re: [pybombs] pybombs update fails with package not found followed by FIRST LETTER OF PKGNAME (#32) Date: Thu, 03 Oct 2013 06:21:43 -0700 From: osh notificati...@github.comnotificati...@github.com Reply-To: pybombs/pybombs reply+i-20395094-546de77d9b329098241ee4182fc20dbc161c5eb9-5022...@reply.github.comreply+i-20395094-546de77d9b329098241ee4182fc20dbc161c5eb9-5022...@reply.github.com To: pybombs/pybombs pybo...@noreply.github.com pybo...@noreply.github.com CC: mark-orion i...@mdammer.net i...@mdammer.net this has now been fixed update was expecting a list of strings instead of a string - there is now a check ___ 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] GNURADIO.org down???
It appears that gnuradio.org is down. There's a domain name advertisement up instead. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO.org down???
On Thu, Oct 3, 2013 at 3:19 PM, Tommy Tracy II tj...@virginia.edu wrote: It appears that gnuradio.org is down. There's a domain name advertisement up instead. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It's still working for me. http://www.downforeveryoneorjustme.com/gnuradio.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO.org down???
It's still working for me. http://www.downforeveryoneorjustme.com/gnuradio.org Down for me. I see the advert for domains priced right. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting to know about USRP FPGA programming
Hi Marcus, Thank you for your reply, What I am aiming ultimately is to estimate the time delay a packet could have when running through the following path: HOST(1) =[Ethernet]= USRP(1)[FPGA-DAC-AnalogPath-Antenna] == On the air == The same path Reversed (USRP(2)) == HOST(1) or another HOST, The problem here is that the time delay of propagation on the air is so insignificant compared to the time delay of Hardware propagation then especially through the Ethernet from the Host(1) or to the Host(2), NEXT, that let's say software delay (From the moment the packet is passed from a modulator block in a gnu radio top block to the USRP Sink to the moment it is transformed and inserted into the stream to the FPGA) is VARIABLE, That's why I asked if it is better to migrate to use FPGA time domain, by inserting time register's value into the appropriate field in the packet stream, Am I pursuing a good path or non realistic and infeasible. Best Regards, -- View this message in context: http://gnuradio.4.n7.nabble.com/Getting-to-know-about-USRP-FPGA-programming-tp43909p43936.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO.org down???
Hm. I suspect a DNS problem. I get the domain advertisement page using Chrome, and get to the GNURADIO webpage using Firefox. I cleared both caches; same results. Weird. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Oct 3, 2013, at 4:28 PM, Aditya Dhananjay adi...@cs.nyu.edu wrote: It's still working for me. http://www.downforeveryoneorjustme.com/gnuradio.org Down for me. I see the advert for domains priced right. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO.org down???
Tom will fix this momentarily. On Thu, Oct 3, 2013 at 1:47 PM, Tommy Tracy II tj...@virginia.edu wrote: Hm. I suspect a DNS problem. I get the domain advertisement page using Chrome, and get to the GNURADIO webpage using Firefox. I cleared both caches; same results. Weird. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Oct 3, 2013, at 4:28 PM, Aditya Dhananjay adi...@cs.nyu.edu wrote: It's still working for me. http://www.downforeveryoneorjustme.com/gnuradio.org Down for me. I see the advert for domains priced right. ___ 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] Summary of desires for GRC, just discuss on the #ghuradio channel
Slick, I always seem to end up with long linear chains of blocks that need duplication on the page, your grouping mechanism could save me from having to make so many custom hier blocks. Jared On Oct 3, 2013 7:55 AM, Ethan Trewhitt gnura...@potophobia.net wrote: On Thu, Oct 3, 2013 at 9:35 AM, Gregory Warnes g...@warnes.net wrote: I would go with simply either adding a new multi-variable block, or modifying the existing one to allow multiple variables. Don't do any 'automatic' variable aggregation. I agree that it shouldn't be automatic. I was thinking something like: 1. Select a bunch of blocks 2. Choose create group 3. A new group symbol appears (visually like three rectangles in a stack, viewed from above) 4. The previously selected blocks are moved into the group 5. If you double-click the group, a box is displayed over the current graph that lets you see its contents. For the open group, I'm imagining something like a toolbox-style box that can be dragged around the graph (and left open), complete with a little grey title bar and a minimize button that restores it to its icon state. That way you can leave it open and work with it until you're done, then minimize it to its icon form when you've finished working with its contents. I can only imagine this making sense for blocks that don't need any I/O - or even perhaps for blocks that only have connections among each other. Visually showing connections going into or out of a group might be tricky. Ethan ___ 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] Activating/Deactivating Blocks in real time
Perhaps the gr.copy() block will accomplish what you need. Help on function copy in module gnuradio.gr.gnuradio_core_general: copy(*args, **kwargs) copy(size_t itemsize) - gr_copy_sptr output[i] = input[i] When enabled (default), this block copies its input to its output. When disabled, this block drops its input on the floor. enabled(self) method of gnuradio.gr.gnuradio_core_general.gr_copy_sptr instance enabled(self) - bool set_enabled(self, *args, **kwargs) method of gnuradio.gr.gnuradio_core_general.gr_copy_sptr instance set_enabled(self, bool enabled) On Thu, Oct 3, 2013 at 5:03 AM, West, Nathan n...@ostatemail.okstate.eduwrote: On Wed, Oct 2, 2013 at 11:06 PM, Achilleas Anastasopoulos anas...@umich.edu wrote: I guess I forgot to make this one thing more clear: I would like the input stream of block A to be consumed even when s(t)=1. With Tim's suggestion, when s(t)=1 we will have the right output, but the input will be waiting in block's A queue to be processed the moment s(t) turns 0. Is this correct, or am I missing something? But this gives me the following idea: I guess what i need in addition to that is a block that based on s(t) either sends the input to the output when s(t)==0 (which is then connected to A), or just consumes the input (when s(t)==1). Is there such a block available? (even if not, this is pretty easy to write!) Any comments on this? thanks for the hints and ideas! Achilleas Achilleas, I solved a similar problem by creating a general block that consumes an input stream on some condition, and passes it otherwise. If you pair this with another block that tags a sample where passing or rejecting should begin (correlate_access_code_tag?) it works quite nicely. With this approach you could use the control pin idea, but I would recommend tags to keep it cleaner. Looking at this might help you get going a little faster if this sounds like it would work for you: https://github.com/n-west/gr-west_3_6/blob/master/lib/filter_payload_impl.cc It's a little messy because I was trying (and more or less failied) to make it dynamic and allow multiple streams coming in to be synchronized and let any input stream control output of all streams. It also still uses 3.6 API (I know, the shame!) -Nathan On Wed, Oct 2, 2013 at 5:51 PM, Monahan-Mitchell, Tim tmona...@qti.qualcomm.com wrote: Can you do this with a 2:1 mux block? Input 2 = constant 0, control input is s(t)? ** ** *From:* discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org[mailto: discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org] *On Behalf Of *Achilleas Anastasopoulos *Sent:* Wednesday, October 02, 2013 3:48 PM *To:* Discuss-gnuradio@gnu.org *Subject:* [Discuss-gnuradio] Activating/Deactivating Blocks in real time ** ** I have the following problem that I would like your opinion on how to solve elegantly: I have a block A (say a standard sync block with some memory--eg an fir filter) which has input x(t) and output y(t) and is pretty computationally intensive.* *** I would like to add the following functionality to it: Add a new input s(t) to A which can be 0 or 1. When s(t)=1 the block operates as before ie, it processes x(t) to generate y(t). If s(t)=0 I would like it to output y(t)=0 and consume the appropriate x(t)'s from the input. This way when s(t)=0 block A essentially does not work. ** ** This is pretty straightforward to code if I modify the work function of block A. However, block A for me is a pretty complicated hierarchical block, so I don't have access to its work function. One way to do this is to rewrite the whole hierarchical block A as a flat block and then do as suggested above. Is there a better way? ** ** Thanks Achilleas ** ** ___ 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] Possibly incorrect gr_msg_queue.delete_head_nowait() implementation
According to the documentation comments, gr_msg_queue::delete_head_nowait()
should return 0 if no message is available. The current implementation,
however, results in a core dump.
For example, when executed in a script, the eleven lines:
#/usr/bin/env python
from gnuradio import gr
q = gr.msg_queue(1)
msg1_in = gr.message_from_string('msg1 payload')
q.insert_tail(msg1_in)
msg1_out = q.delete_head_nowait()
print 'msg1_out object: %s' % str(msg1_out)
print 'msg1_out value: %s' % msg1_out.to_string()
msg2_out = q.delete_head_nowait()
print 'msg2_out object: %s' % str(msg2_out)
print 'msg2_out value: %s' % msg2_out.to_string()
generate the output:
msg1_out object: gnuradio.gr.gnuradio_core_runtime.gr_message_sptr; proxy
of Swig Object of type 'gr_message_sptr *' at 0x16529c0
msg1_out value: msg1 payload
msg2_out object: gnuradio.gr.gnuradio_core_runtime.gr_message_sptr; proxy
of Swig Object of type 'gr_message_sptr *' at 0x16529f0
python: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
boost::shared_ptr template-parameter-1-1 ::operator-() const [with T =
gr_message]: Assertion `px != 0' failed.
Aborted (core dumped)
All of the other gr.msg_queue swig'd functions also cause a core dump.
The definition of gr_msg_queue:delete_head_nowait() includes the block:
if ((m = d_head) == 0){
//return 0;
return gr_message_sptr();
}
I believe the correct implementation should the 'return 0' line uncommented
and the 'return gr_message_sprt()' removed.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possibly incorrect gr_msg_queue.delete_head_nowait() implementation
Of course, if 0 is returned, msg2_out would not be an message instance, but
it would be possible to check if msg2_out == 0 before trying to call any
instance methods.
On Thu, Oct 3, 2013 at 3:27 PM, Isdren Gineer
gineer.isd...@nkiengineering.com wrote:
According to the documentation comments,
gr_msg_queue::delete_head_nowait() should return 0 if no message is
available. The current implementation, however, results in a core dump.
For example, when executed in a script, the eleven lines:
#/usr/bin/env python
from gnuradio import gr
q = gr.msg_queue(1)
msg1_in = gr.message_from_string('msg1 payload')
q.insert_tail(msg1_in)
msg1_out = q.delete_head_nowait()
print 'msg1_out object: %s' % str(msg1_out)
print 'msg1_out value: %s' % msg1_out.to_string()
msg2_out = q.delete_head_nowait()
print 'msg2_out object: %s' % str(msg2_out)
print 'msg2_out value: %s' % msg2_out.to_string()
generate the output:
msg1_out object: gnuradio.gr.gnuradio_core_runtime.gr_message_sptr; proxy
of Swig Object of type 'gr_message_sptr *' at 0x16529c0
msg1_out value: msg1 payload
msg2_out object: gnuradio.gr.gnuradio_core_runtime.gr_message_sptr; proxy
of Swig Object of type 'gr_message_sptr *' at 0x16529f0
python: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
boost::shared_ptr template-parameter-1-1 ::operator-() const [with T =
gr_message]: Assertion `px != 0' failed.
Aborted (core dumped)
All of the other gr.msg_queue swig'd functions also cause a core dump.
The definition of gr_msg_queue:delete_head_nowait() includes the block:
if ((m = d_head) == 0){
//return 0;
return gr_message_sptr();
}
I believe the correct implementation should the 'return 0' line
uncommented and the 'return gr_message_sprt()' removed.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possibly incorrect gr_msg_queue.delete_head_nowait() implementation
This should have been obvious to me earlier. The problem is that 0 _is_
being return and the assertion that 'px != 0' (correctly) fails. Perhaps
the use of gr.msg_queue.delete_head_nowait() should be deprecated and the
equivalent behavior achieved by checking if gr.msg_queue.count() == 0 prior
to calling gr.msg_queue.delete_head().
On Thu, Oct 3, 2013 at 3:33 PM, Isdren Gineer
gineer.isd...@nkiengineering.com wrote:
Of course, if 0 is returned, msg2_out would not be an message instance,
but it would be possible to check if msg2_out == 0 before trying to call
any instance methods.
On Thu, Oct 3, 2013 at 3:27 PM, Isdren Gineer
gineer.isd...@nkiengineering.com wrote:
According to the documentation comments,
gr_msg_queue::delete_head_nowait() should return 0 if no message is
available. The current implementation, however, results in a core dump.
For example, when executed in a script, the eleven lines:
#/usr/bin/env python
from gnuradio import gr
q = gr.msg_queue(1)
msg1_in = gr.message_from_string('msg1 payload')
q.insert_tail(msg1_in)
msg1_out = q.delete_head_nowait()
print 'msg1_out object: %s' % str(msg1_out)
print 'msg1_out value: %s' % msg1_out.to_string()
msg2_out = q.delete_head_nowait()
print 'msg2_out object: %s' % str(msg2_out)
print 'msg2_out value: %s' % msg2_out.to_string()
generate the output:
msg1_out object: gnuradio.gr.gnuradio_core_runtime.gr_message_sptr;
proxy of Swig Object of type 'gr_message_sptr *' at 0x16529c0
msg1_out value: msg1 payload
msg2_out object: gnuradio.gr.gnuradio_core_runtime.gr_message_sptr;
proxy of Swig Object of type 'gr_message_sptr *' at 0x16529f0
python: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
boost::shared_ptr template-parameter-1-1 ::operator-() const [with T =
gr_message]: Assertion `px != 0' failed.
Aborted (core dumped)
All of the other gr.msg_queue swig'd functions also cause a core dump.
The definition of gr_msg_queue:delete_head_nowait() includes the block:
if ((m = d_head) == 0){
//return 0;
return gr_message_sptr();
}
I believe the correct implementation should the 'return 0' line
uncommented and the 'return gr_message_sprt()' removed.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possibly incorrect gr_msg_queue.delete_head_nowait() implementation
Hi Isdren, I believe the correct implementation should the 'return 0' line uncommented and the 'return gr_message_sprt()' removed. That would not compile, since you can't convert int to boost::shared_ptr. What you see in your python output are really only the swig wrappers of these shared pointers including their memory address, not the address they points at. So yes, if you use a _nowait() method, you usually have to check its output; that's the price you pay for not waiting as long as it takes to produce your return value. As far as I know, there is no way to check the address that a shared_ptr points add from within python; I'm not quite sure there is an easy way to fix this. Swig just doesn't work like that, and extending boost::shared_ptr doesn't sound very sensible. I guess a logical way would be to have a c++ implementation of the equality comparison operator that takes two boost::shared_ptrgr::message . That would make it possible to check wether a sptr actually points to an object or is a nullpointer from python. However, that'd be a really ugly thing from a syntax point of view: p2 = q.delete_head_nowait() p_ref = gr.message_sptr() if not gr.message.sptr_equals(p2,p_ref): print p2.to_string() You further wrote: This should have been obvious to me earlier. The problem is that 0 _is_ being return and the assertion that 'px != 0' (correctly) fails. Perhaps the use of gr.msg_queue.delete_head_nowait() should be deprecated and the equivalent behavior achieved by checking if gr.msg_queue.count() == 0 prior to calling gr.msg_queue.delete_head(). I strongly disagree - the delete_nowait_method has it's uses and is part of the standard scheduler; it's generally a good idea to have a non-blocking pop for a mutexed queue, otherwise it can be really hard to avoid deadlock conditions. Since your if gr.msg_queue.count() == 0: p2 =gr.msg_queue.delete_head() is not atomic, it would not even fix the issue - someone else might still be stealing your last queue element between your check and your delete_head(). Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Activating/Deactivating Blocks in real time
Thanks for all the suggestions; they helped a lot. Here is my progress and the BIG problem that I have not solved... Recall, my original big block is A (it is a complex hier block with 1:1 input:output rate) as shown below in -- [ A ] -- out (overall hier sync block) I want to prepend it with a block PRE and append it with a block POST, so that the overall block behaves as A when a control input s(t)=1 and outputs 0 (while consuming input) when s(t)=1 in -- [ PRE-- A -- POST ] -- out (overall sync block) ^^ | | ctr- My motivation for all this is that with s(t) I can control when A works because it is really complex and its output is not needed always, while not disturbing the remaining graph... I created one block (call it PRE) that essentially does what the copy block does, with the only difference it is controlled by another control input s(t). When s(t)=1 it copies its input to the output and consumes the input when s(t)=0 it just consumes the input. I also created another block (call it POST) which is based on the MUX idea that was suggested (only simpler) that (is supposed to) behave as follows: It has two inputs: 0) the output of A and 1) the SAME control signal s(t). When s(t)=1 it copies the input to the output. When s(t)=0 is outputs 0's The problem is that the POST block (which is a general block) is problematic: I set the ninput_items_required[1] (the control port) to noutput_items in the forecast method BUT I cannot set the ninput_items_required[0] to any meaningful value, since the number of input items required depends on the control signal s(t). I cannot just set it to noutput_items, because when s(t)=0 block A is not producing anything (that's the whole point!!!) and thus the POST block will be just waiting for its input0 queue to fill but nothing comes to that!!! Any ideas? thanks again for all the help, Achilleas On Thu, Oct 3, 2013 at 8:03 AM, West, Nathan n...@ostatemail.okstate.eduwrote: On Wed, Oct 2, 2013 at 11:06 PM, Achilleas Anastasopoulos anas...@umich.edu wrote: I guess I forgot to make this one thing more clear: I would like the input stream of block A to be consumed even when s(t)=1. With Tim's suggestion, when s(t)=1 we will have the right output, but the input will be waiting in block's A queue to be processed the moment s(t) turns 0. Is this correct, or am I missing something? But this gives me the following idea: I guess what i need in addition to that is a block that based on s(t) either sends the input to the output when s(t)==0 (which is then connected to A), or just consumes the input (when s(t)==1). Is there such a block available? (even if not, this is pretty easy to write!) Any comments on this? thanks for the hints and ideas! Achilleas Achilleas, I solved a similar problem by creating a general block that consumes an input stream on some condition, and passes it otherwise. If you pair this with another block that tags a sample where passing or rejecting should begin (correlate_access_code_tag?) it works quite nicely. With this approach you could use the control pin idea, but I would recommend tags to keep it cleaner. Looking at this might help you get going a little faster if this sounds like it would work for you: https://github.com/n-west/gr-west_3_6/blob/master/lib/filter_payload_impl.cc It's a little messy because I was trying (and more or less failied) to make it dynamic and allow multiple streams coming in to be synchronized and let any input stream control output of all streams. It also still uses 3.6 API (I know, the shame!) -Nathan On Wed, Oct 2, 2013 at 5:51 PM, Monahan-Mitchell, Tim tmona...@qti.qualcomm.com wrote: Can you do this with a 2:1 mux block? Input 2 = constant 0, control input is s(t)? ** ** *From:* discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org[mailto: discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org] *On Behalf Of *Achilleas Anastasopoulos *Sent:* Wednesday, October 02, 2013 3:48 PM *To:* Discuss-gnuradio@gnu.org *Subject:* [Discuss-gnuradio] Activating/Deactivating Blocks in real time ** ** I have the following problem that I would like your opinion on how to solve elegantly: I have a block A (say a standard sync block with some memory--eg an fir filter) which has input x(t) and output y(t) and is pretty computationally intensive.* *** I would like to add the following functionality to it: Add a new input s(t) to A which can be 0 or 1. When s(t)=1 the block operates as before ie, it processes x(t) to generate y(t). If s(t)=0 I would like it to output y(t)=0 and consume the appropriate x(t)'s from the input. This way when s(t)=0 block A essentially does not work. ** ** This is pretty straightforward to code if I modify the work
Re: [Discuss-gnuradio] Activating/Deactivating Blocks in real time
After some more thought I decided that what i want to accomplish can only be done by rearranging the graph in real time as for example in the selector and valve blocks. I have tried a simple example and it works fine this way. I will post a complete solution once I iron out the details. thanks Achilleas On Thu, Oct 3, 2013 at 8:11 PM, Achilleas Anastasopoulos anas...@umich.eduwrote: Thanks for all the suggestions; they helped a lot. Here is my progress and the BIG problem that I have not solved... Recall, my original big block is A (it is a complex hier block with 1:1 input:output rate) as shown below in -- [ A ] -- out (overall hier sync block) I want to prepend it with a block PRE and append it with a block POST, so that the overall block behaves as A when a control input s(t)=1 and outputs 0 (while consuming input) when s(t)=1 in -- [ PRE-- A -- POST ] -- out (overall sync block) ^^ | | ctr- My motivation for all this is that with s(t) I can control when A works because it is really complex and its output is not needed always, while not disturbing the remaining graph... I created one block (call it PRE) that essentially does what the copy block does, with the only difference it is controlled by another control input s(t). When s(t)=1 it copies its input to the output and consumes the input when s(t)=0 it just consumes the input. I also created another block (call it POST) which is based on the MUX idea that was suggested (only simpler) that (is supposed to) behave as follows: It has two inputs: 0) the output of A and 1) the SAME control signal s(t). When s(t)=1 it copies the input to the output. When s(t)=0 is outputs 0's The problem is that the POST block (which is a general block) is problematic: I set the ninput_items_required[1] (the control port) to noutput_items in the forecast method BUT I cannot set the ninput_items_required[0] to any meaningful value, since the number of input items required depends on the control signal s(t). I cannot just set it to noutput_items, because when s(t)=0 block A is not producing anything (that's the whole point!!!) and thus the POST block will be just waiting for its input0 queue to fill but nothing comes to that!!! Any ideas? thanks again for all the help, Achilleas On Thu, Oct 3, 2013 at 8:03 AM, West, Nathan n...@ostatemail.okstate.eduwrote: On Wed, Oct 2, 2013 at 11:06 PM, Achilleas Anastasopoulos anas...@umich.edu wrote: I guess I forgot to make this one thing more clear: I would like the input stream of block A to be consumed even when s(t)=1. With Tim's suggestion, when s(t)=1 we will have the right output, but the input will be waiting in block's A queue to be processed the moment s(t) turns 0. Is this correct, or am I missing something? But this gives me the following idea: I guess what i need in addition to that is a block that based on s(t) either sends the input to the output when s(t)==0 (which is then connected to A), or just consumes the input (when s(t)==1). Is there such a block available? (even if not, this is pretty easy to write!) Any comments on this? thanks for the hints and ideas! Achilleas Achilleas, I solved a similar problem by creating a general block that consumes an input stream on some condition, and passes it otherwise. If you pair this with another block that tags a sample where passing or rejecting should begin (correlate_access_code_tag?) it works quite nicely. With this approach you could use the control pin idea, but I would recommend tags to keep it cleaner. Looking at this might help you get going a little faster if this sounds like it would work for you: https://github.com/n-west/gr-west_3_6/blob/master/lib/filter_payload_impl.cc It's a little messy because I was trying (and more or less failied) to make it dynamic and allow multiple streams coming in to be synchronized and let any input stream control output of all streams. It also still uses 3.6 API (I know, the shame!) -Nathan On Wed, Oct 2, 2013 at 5:51 PM, Monahan-Mitchell, Tim tmona...@qti.qualcomm.com wrote: Can you do this with a 2:1 mux block? Input 2 = constant 0, control input is s(t)? ** ** *From:* discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org[mailto: discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org] *On Behalf Of *Achilleas Anastasopoulos *Sent:* Wednesday, October 02, 2013 3:48 PM *To:* Discuss-gnuradio@gnu.org *Subject:* [Discuss-gnuradio] Activating/Deactivating Blocks in real time ** ** I have the following problem that I would like your opinion on how to solve elegantly: I have a block A (say a standard sync block with some memory--eg an fir filter) which has input x(t) and output y(t) and is pretty computationally intensive.
