Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2?
Sorry to dig up an old thread, but does anyone know of anyone who's implemented a polyphase filter bank on a USRP FPGA? John On Thu, May 9, 2013 at 12:02 AM, Marcus D. Leech mle...@ripnet.com wrote: Or am I wrong that the resource is in the computer and not in the USRP? LD It's all in the computer, unless you do an FPGA-based implementation. Gnu Radio blocks run on the host machine, not the USRP hardware. I admit to being a little bit surprised that you don't know that already, given how long you've been posting things to this list, and using USRP hardware. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ 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] GSoC2014 Turbo Equalizer
Hey Guys, I wrote a blind turbo equaliser for LDPC encoded data a few years ago in GNU Radio, the code is probably pretty horrific, and it wasn't optimised very well, but it worked as a proof on concept, I could dig out the code if anyone was interested? John On Sat, Mar 1, 2014 at 10:33 AM, Jan Kraemer krae...@int.uni-karlsruhe.dewrote: Hey Nguyen Anh Duc, thanks for your input. It's nice to see that there seems to be some guys interested in the whole turbo EQ topic. These are some interesting points you mentioned. To be honest i never thought about using MLSE/MAP for the equalizer part. Same goes with another turbo decoder in the turbo equalizer cause I discarded them as to computationally heavy to be implemented in software. But it seems that right now there is greater need to speed up the gr-trellis module before attempting a full turbo equalizer. Best regards, Jan Am 28.02.2014 16:57, schrieb Anh Duc Nguyen: Dear Jan Krämer, I am very interested in your proposal. However, to my best of knowledge, turbo equalizer (TB) is pretty complicated and computationally heavy, then it is challenging to have an effective real-time implementation of TB. I would like to have some questions as follows: 1. Your ISI channels' characteristics: fixed/ known beforehand or time-variant, how dispersive they are 2. which techniques do you wish to use for equalizer part: MMSE, MAP, or MLSE? 3. coding: as you presented above - it may be a convolutional or turbo code, and others? 4. Some special hardware platform may require 5. why do you select 2. and 3. to have the best performance in terms of complexity or quality, and that combination is realistic to be real-time implemented in GnuRadio plus 4. To be honest, I have desperately struggled these question for quite a long time, then you and some others can help work together to find the answers, Best regards, Nguyen Anh Duc On Tue, Feb 25, 2014 at 8:59 PM, Jan Krämer krae...@int.uni-karlsruhe.dewrote: Hi everyone, I am a student at Communications Engineering Lab (CEL) at Karlsruhe Institute of Technology. I major in communication systems and I am currently doing my masterthesis on Parallel log-map decoders for manycore architectures. I am interested in participating in GSoC 2014. There is an older GNURadio GSoC proposal from 2013 to implement a turbo equalizer module in GNURadio in which i am particularly interested working on, as it is closely connected to my current field of study. So i would like to share my thoughts on a possible Update of the old turbo equalizer proposal (and maybe upgrading it to a current proposal ?). - *Turbo Equalizer* A Turbo Equalizer is a receiver component that is highly effective when receiving messages corrupted by Intersymbol Interference (ISI). To archive this, the turbo equalizer uses an Equalizer to eliminate the ISI and a Log-Map Decoder for Forward Error Correction. Both components pass soft information to each other to increase the performance. *Objectives* Possible (sub-)projects: 1. Implement the Log-Map decoder - preferably it can be fully configurable (constraint length, number of states, trellis structure) - preferably optimized for real time applications 2. Implement the linear equalizer - preferably optimized for real time applications *Skills* Knowledge of digital signal processing, C/C++, Python *Potential mentor(s)* Sebastian Koslowski, Michael Schwall -- That would be a project I think would be really interesting to work on and i think it fits well with some of the other proposals for new GNU Radio Modules. As the turbo eq itself is a highly complex architecture, it could also be beneficial to split the tasks in this project. It would be great to get some feedback from you, if this was a proposal that would benefit GNURadio and if it has the potential to be included in the GSoC list of ideas. Thanks and regards, Jan Krämer ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Addding enums to custom processing blocks
Hi,
What's the process by which enums are added to the Python namespace via
SWIG in gnuradio? I mean in gr_firdes, the following are added to the
gr.firdes namespace in Python:
enum win_type {
WIN_HAMMING = 0,// max attenuation 53 dB
WIN_HANN = 1,// max attenuation 44 dB
WIN_BLACKMAN = 2,// max attenuation 74 dB
WIN_RECTANGULAR = 3,
WIN_KAISER = 4, // max attenuation variable with beta, google it
WIN_BLACKMAN_hARRIS = 5,
};
But I can't seem to get it to work with my code?
Cheers,
John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Static compilation of GNU radio
Hey guys, I wonder whether anyone has done this before/can help me out. I'm looking to compile GNURadio with all static libraries, so that there are zero .so dependencies. I've been playing around with CMake, but it looks like the linker order is wrong for compiling against static libraries: What CMake is generating is: COMPILER OBJECT.o -o TARGET -lLIB1 -lLIB2 etc. This works for shared libs, but I believe the linker will search for libraries specified before the target on the command line, it's coming up with undefined refs using static libs at the moment. What I think my binutils needs is: COMPILER OBJECT.o -lLIB1 -lLIB2 etc. -o TARGET i.e. how can I coerce cmake to generate link scripts with the target at the end of the line (or at least, after the libraries) Cheers, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 4x RX chains on USRP1 with DBSRX2
Hi guys, Another quick (couple of) question(s); - The DBSRX2 has a programmable channel filter 1-60 MHz. Is the firmware clever enough to know to increase this bandwidth when I'm reading two separate frequencies, or is there a chance that it will ruin my day by centering a too-narrow filter around what I set as rf_freq? - Does GNU radio provide an interface to manually change the daughterboard channel filter? Cheers, John On Wed, Feb 13, 2013 at 8:54 AM, John Wilson johnmwilso...@gmail.comwrote: Hey yes I had that bit working okay (found that page before), I was just wondering how to actually use it, all seems so simple now anyway! It would be nice to see some simple instructions on those application notes about how the individual RX chains can be used (pretty much what Josh said below). Anyway having got back into the lab it all seems to be up and working, now I've just got to hope I don't hit the bandwidth limit on the USB :) Thanks again, John On Wed, Feb 13, 2013 at 2:23 AM, Josh Blum j...@ettus.com wrote: On 02/12/2013 04:03 PM, Marcus D. Leech wrote: On 02/12/2013 12:10 PM, John Wilson wrote: Hi, I'm wondering whether it's possible/how to use a USRP1 with 2x DBSRX boards to generate 4 separate streams via the 4rx usrp1 firmware. The required channels will be within the front end bandwidth of the DBSRX2. At the moment I'm using a subdev spec of 'A:0 A:0 B:0 B:0' which I assume runs the signal from subdev A through RX chains 0 and 1, and subdev B through 2 and 3. Is this correct? That seems correct. I am planning to set each daughter board to a frequency between its two frequencies of interest, then I'd like the DDCs to downconvert the data from the ADC independently to sit the two frequencies of interest in the centre of their respective baseband channels out of the USB bus. So can I change the DDC frequencies independently of the centre frequency in the You will want a tune_request object where the rf_freq is set to the desired center frequency of the DBSRX (something in between that each CORDIC can shift away from). And set the rf freq policy to manual. There are some examples of making the tune request in the grc block for usrp source properties dialog box. daughterboard? Also what is the resolution of the DDS in the DDC, i.e. can I tune each one independently in ~1Hz steps? The CORDIC resolution is pretty much 64e6/(132), so sub Hz. -josh Also, will he need to use the 4rx FPGA image, or will UHD automagically use the right image? Its an args option, exact example here: http://files.ettus.com/uhd_docs/manual/html/usrp1.html#specify-a-non-standard-image -josh ___ 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] 4x RX chains on USRP1 with DBSRX2
Cool thanks, I guess that's exposed in the Python scripts by usrp_source.set_bandwidth then? John On Wed, Feb 13, 2013 at 5:53 PM, mle...@ripnet.com wrote: ** On 13 Feb 2013 12:51, John Wilson wrote: Hi guys, Another quick (couple of) question(s); - The DBSRX2 has a programmable channel filter 1-60 MHz. Is the firmware clever enough to know to increase this bandwidth when I'm reading two separate frequencies, or is there a chance that it will ruin my day by centering a too-narrow filter around what I set as rf_freq? - Does GNU radio provide an interface to manually change the daughterboard channel filter? Cheers, John In GRC, if you use the bandwidth parameter when creating the source, it will set the closest settable bandwidth, if the card has settable bandwidth. The DBSRX2 has settable bandwidth, so you should set it manually to something appropriate based on your channel spacing. ___ 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 3.4.1 build error
Use a different version of boost for the older Gnuradio builds, I used boost-1.40 to compile 3.4.0 against which worked. On Tue, Feb 12, 2013 at 4:31 PM, Zulfiqar Khan zulfi.khan@gmail.comwrote: Hello, I am trying to build gnuradio 3.4.1 on ubuntu for usrp1 but it gives me the following error when I run the make command. Please help! /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/ src/lib/.libs/libgnuradio-core.so: undefined reference to `boost::filesystem3::detail::create_directory(boost::filesystem3::path const, boost::system::error_code*)' /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/ src/lib/.libs/libgnuradio-core.so: undefined reference to `boost::filesystem3::path::operator/=(boost::filesystem3::path const)' /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/ src/lib/.libs/libgnuradio-core.so: undefined reference to `boost::system::system_category()' /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/ src/lib/.libs/libgnuradio-core.so: undefined reference to `boost::filesystem3::detail::status(boost::filesystem3::path const, boost::system::error_code*)' /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/ src/lib/.libs/libgnuradio-core.so: undefined reference to `boost::filesystem3::path::wchar_t_codecvt_facet()' /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/ src/lib/.libs/libgnuradio-core.so: undefined reference to `boost::system::generic_category()' collect2: ld returned 1 exit status make[5]: *** [usrp_rx_cfile] Error 1 make[5]: Leaving directory `/home/imran/Desktop/gnuradio/ gnuradio-3.4.1/gr-usrp/apps' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/imran/Desktop/gnuradio/ gnuradio-3.4.1/gr-usrp/apps' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/imran/Desktop/gnuradio/ gnuradio-3.4.1/gr-usrp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/imran/Desktop/gnuradio/ gnuradio-3.4.1/gr-usrp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/imran/Desktop/gnuradio/gnuradio-3.4.1' make: *** [all] Error 2 ___ 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] 4x RX chains on USRP1 with DBSRX2
Hi, I'm wondering whether it's possible/how to use a USRP1 with 2x DBSRX boards to generate 4 separate streams via the 4rx usrp1 firmware. The required channels will be within the front end bandwidth of the DBSRX2. At the moment I'm using a subdev spec of 'A:0 A:0 B:0 B:0' which I assume runs the signal from subdev A through RX chains 0 and 1, and subdev B through 2 and 3. Is this correct? I am planning to set each daughter board to a frequency between its two frequencies of interest, then I'd like the DDCs to downconvert the data from the ADC independently to sit the two frequencies of interest in the centre of their respective baseband channels out of the USB bus. So can I change the DDC frequencies independently of the centre frequency in the daughterboard? Also what is the resolution of the DDS in the DDC, i.e. can I tune each one independently in ~1Hz steps? Sorry if this has been asked before, I've been searching Google and the email lists all day and have not yet found an answer! Thanks, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio 3.3 on Ubuntu 12.04LTS
Hi Ed, I've been doing the same recently with gnuradio-3.4 on ubuntu 12.04 x64, So I'm guessing it's pretty similar. Anyway, copying and pasting some notes I made which should hopefully help you, there were a few little horrors in there! NB The boost version is probably not that important so long as it compiles, 1.40 was 'known good' though. Good luck! John Installing GNU Radio on 12.04 To avoid spending days figuring out how to install our old versiojn of GNU Radio onto Ubuntu 12 (and probably later versions also), follow these instructions TO THE LETTER. Use g++ = 4.5 (using ‘make CXX=g++-4.5’) Use swig 1.3 Use Boost 1.40 I used automake 1.11, which needed patching, due to it causing problems with ‘make install’: --- lib/am/python.am.orig 2012-01-31 11:41:18.0 + +++ lib/am/python.am @@ -23,8 +23,8 @@ endif %?INSTALL% ## Installing. ## ## ## +?FIRST?am__py_compile = PYTHON=$(PYTHON) $(SHELL) $(py_compile) if %?INSTALL% -?FIRST?am__py_compile = PYTHON=$(PYTHON) $(SHELL) $(py_compile) am__installdirs += $(DESTDIR)$(%NDIR%dir) .PHONY install-%EXEC?exec:data%-am: install-%DIR%PYTHON install-%DIR%PYTHON: $(%DIR%_PYTHON) You need to add two lines to ./gnuradio-core/src/lib/Makefile.am, under the libgnuradio_core_la_LIBADD section: $(BOOST_FILESYSTEM_LIB) \ $(BOOST_SYSTEM_LIB) or else the complier will complain about not being able to find symbols in gr-usrp and audio, and these modules won’t work. On Tue, Feb 12, 2013 at 6:51 PM, Ed Criscuolo edward.l.criscu...@nasa.govwrote: Thanks Jonathan! That tidbit probably saved me an hour of troubleshooting right there! :) @(^.^)@ Ed On 2/12/13 10:16 AM, Johnathan Corgan wrote: On Sat, Feb 9, 2013 at 10:24 AM, Ed Criscuolo edward.l.criscu...@nasa.gov mailto:edward.l.criscuolo@**nasa.govedward.l.criscu...@nasa.gov wrote: My question is, are there any showstoppers for able to run GnuRadio 3.3 on Ubuntu 12.04LTS? My customer _really_ wants all the SDRs to be the same for CM purposes, and does not have the schedule time for me to port his custom blocks and flowgraphs from GR3.3 to GR3.6. I know over the last year or two there's been a lot of Boost and Qt version issues, and I want to know if I'm about to paint myself into a corner here. Well, I'm not aware of anything that would prevent 3.3 from working on Ubuntu 12.04, but of course I don't think anyone has actually tried it. The Boost version in 12.04 defaults to 1.46, which has a known bug that affects GNU Radio, but 1.48 is also available on that distro. Johnathan __**_ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://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] FFT of noise assumes a gaussian shape at certain sample frequencies
Hey guys, I've got a quick question on a project I'm currently working on which is scanning a range of frequencies using GNU radio and the USRP-N210 with the SBX daughterboard. Basically when I take the FFT of the wgn receiver noise, at certain sample rates (e.g. 5Msps) the spectrum output is roughly flat, while at other rates (e.g. ~6 Msps), the spectrum takes on a decidedly Gaussian look, where the magnitude of the first and last bins of the FFT are 5-10 dB below the centre bins of the FFT. Does anyone know why this is? I've confirmed this behaviour with the fft_sink2 block. Also, in an unrelated question, is 25Msps the maximum bandwidth of the host-USRP interface for the N210 without having to modify the firmware? Cheers, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP, GNU Radio on Windows
Hey, This may seem like a dumb suggestion but have you tried running the scripts from the command line to see why they're failing? Start with something simple like dial_tone.py (from the python/audio subfolder in gnuradio-examples). I've never used minGW, but I had no problems getting GNURadio installed and working with cygwin. John On Thu, Aug 5, 2010 at 5:41 AM, Florian Eugen florian_eu...@yahoo.comwrote: Hi Jason, thank you for the reply, I updated the GNU Radio to version 3.3.0, but there is not working. If I want to start a script by double clicking the cmd line window is opened and closed and nothing happens. The USB driver is installed, everything seems to be OK but it's not. Florian. Florian, Welcome. Unfortunately, your next step will be to upgrade to GNU Radio 3.3.0 or later. The WBX was released after GNU Radio 3.2.2 and therefore will not be supported by your GNU Radio installation. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PLL and VCO questions
Hey, You can't make a feedback system in the Python flowgraph. You can, however use feedback in an individual signal processing block. If you need to use a PLL look at the Costas loop block which locks to RF signals with complex baseband components eg. QPSK, SSB etc. John On Mon, Aug 2, 2010 at 2:52 AM, Rahman, Muhammad Mahboob Ur mahboob-rah...@uiowa.edu wrote: Hi all, I have made up a simple PLL block in GRC using a multiplier phase detector, low pass filter (FIR) and VCO to lock to a 1KHz reference. When I run the simulation, it gives me a run time error flow graph has loops!. Does it mean that I cannot make any kind of feedback system in the gnuradio or is there something else to ponder? Also, I am adding 1 to the output of the low pass filter so that when the phase error (output of low pass filter) becomes zero in the locked state, the VCO then runs at its quiescent frequency of 1KHz (I have set the sensitivity of VCO as 2*pi*1K rad/s/V). Is it the right way to use VCO? Below is the error message: -- -- Generating: /home/mahboob/Desktop/top_block.py Executing: /home/mahboob/Desktop/top_block.py gr_fir_fff: using SSE Traceback (most recent call last): File /home/mahboob/Desktop/top_block.py, line 71, in module tb.Run(True) File /usr/lib/python2.6/dist-packages/grc_gnuradio/wxgui/top_block_gui.py, line 73, in Run if start: self.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: flow graph has loops! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PLL and VCO questions
Hey Mahboob, Maybe take a look at the gr_mpsk_receiver block source for reference, that implements a Costas Loop with provision for constant frequency offset (theta). Anyway processing block it is, good luck! John On Mon, Aug 2, 2010 at 3:47 PM, Rahman, Muhammad Mahboob Ur mahboob-rah...@uiowa.edu wrote: Hi John, I have to implement a modified version of costas loop which is to be used to compensate for frequency offset present between LO's of two USRP's (RFX900). So, I think I should make a new such signal processing block now. Thanks, Mahboob -- *From:* John Wilson [johnmwilso...@gmail.com] *Sent:* 02 August 2010 02:33 *To:* Rahman, Muhammad Mahboob Ur *Cc:* discuss-gnuradio *Subject:* Re: [Discuss-gnuradio] PLL and VCO questions Hey, You can't make a feedback system in the Python flowgraph. You can, however use feedback in an individual signal processing block. If you need to use a PLL look at the Costas loop block which locks to RF signals with complex baseband components eg. QPSK, SSB etc. John On Mon, Aug 2, 2010 at 2:52 AM, Rahman, Muhammad Mahboob Ur mahboob-rah...@uiowa.edu wrote: Hi all, I have made up a simple PLL block in GRC using a multiplier phase detector, low pass filter (FIR) and VCO to lock to a 1KHz reference. When I run the simulation, it gives me a run time error flow graph has loops!. Does it mean that I cannot make any kind of feedback system in the gnuradio or is there something else to ponder? Also, I am adding 1 to the output of the low pass filter so that when the phase error (output of low pass filter) becomes zero in the locked state, the VCO then runs at its quiescent frequency of 1KHz (I have set the sensitivity of VCO as 2*pi*1K rad/s/V). Is it the right way to use VCO? Below is the error message: -- -- Generating: /home/mahboob/Desktop/top_block.py Executing: /home/mahboob/Desktop/top_block.py gr_fir_fff: using SSE Traceback (most recent call last): File /home/mahboob/Desktop/top_block.py, line 71, in module tb.Run(True) File /usr/lib/python2.6/dist-packages/grc_gnuradio/wxgui/top_block_gui.py, line 73, in Run if start: self.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: flow graph has loops! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What happens to a block as wait() finishes?
Hello, I'm just wondering, what happens within block code when whatever shuts down the graph after the gr_top_block.wait() executes? Is there condition detectable from within a block which could be used to run some code when the block pauses? I want to copy the remaining input buffer into an internal memory buffer to fix a problem I'm getting with the FIR block over a wait() run() cycle. Also I'm guessing that I can overload the gr_block.start() function within a custom block declaration to copy this buffer back to the input buffer somehow? Cheers, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problem with FIR filter
So does no one have any idea about this? It doesn't seem like it should be too difficult to solve, I've worked around the problem for the simulations I'm currently running but it's a shame as it reveals a fundamental incapacity for GNU Radio to perform some other interesting simulations and techniques, notably (for me at least) in the area of repeat requests. Currently I'm implementing a type II HARQ repeat request system by dynamically reconfiguring a flow graph during operation, this makes use of the run() command a lot but if every time I run this command every filter in the system is reset it's going to make it almost impossible to implement. Up to now I've been really impressed with GNU Radio, even to the point of writing a conference paper (for the upcoming NORDIC '10 HF conference in Sweden) about how good the system is in the lab. I think the API is very well written and like how the Python scripting aspect allows code written for testing and simulation of techniques to be plonked straight into a working radio. Unfortunately the problem below seems pretty fundamental and can be treated (at least in the context of how I'm using the software) as a pretty major bug. Does anyone have any opinion on this? Also if anyone has any information on how the filters are implemented I'll have a go at fixing this myself, I've taken a quick look at the filters folder in the source directory but nothing's jumping out at me and I'm currently pretty busy desperately trying to finish off my thesis! Cheers, John On Tue, Jul 20, 2010 at 7:55 PM, John Wilson johnmwilso...@gmail.comwrote: Hello, I've got a problem with the FIR filters in GNU radio. Basically, at the moment I'm using it as a platform to run some simulations on (as I've already written a load of code on it for implementing a digital radio), and one of the tests I'm doing is trying to find the BER through an equaliser. To do this I'm loading a vector source up, running my flow graph with run() and upon completion I'm checking a vector sink for errors. This works fine for a fixed channel. The channel model I'm now using (a Watterson model which I've coded into the flow graph), however, uses a FIR with a large number of taps. Now the problem is that every time I run my flow graph with run(), which presumably also calls wait(), the FIR seems to start from a reset state. Is there any way to keep the contents of the FIR's shift register in situ through calling run() multiple times? Every other signal processing block I have maintains its state through this. For the record I'm not calling stop() at all in the code, which I would expect to reset everything. I've set up a quick test case to describe this problem, So if I set up a little top_block like this, which just sends a string of complex symbols valued +1+0j through a FIR filter, and receives the result in block_out; -- -- class my_top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self) self.data_rate = 1000; self.totbits = 0; self.toterrors = 0; grey_const = ([1, -1]) length = 2 blank = [0x0,] * (length) taps = [1,] * 10 self.transmit_source = gr.vector_source_b(blank, False, length); self.unpack_for_mod = gr.packed_to_unpacked_bb(1, gr.GR_MSB_FIRST) self.symbol_mapper = gr.chunks_to_symbols_bc(grey_const) self.fir = gr.fir_filter_ccc(1, taps) self.v2s = gr.vector_to_stream(1, length) self.connect(self.transmit_source, self.v2s, self.unpack_for_mod, self.symbol_mapper, self.fir) self.connect(self.fir, block_out) - Then if I run it from main() like this; - def main (): tb = my_top_block(); for a in range(20): tb.run() for n in block_out.data(): print n block_out.clear() tb.transmit_source.rewind() - I get as output; - gr_fir_ccc: using SSE (1+0j) (2+0j) (3+0j) (4+0j) (5+0j) (6+0j) (7+0j) (8+0j) (9+0j) (10+0j) (10+0j) (10+0j) (10+0j) (10+0j) (10+0j) (10+0j) (1+0j) (2+0j) (3+0j) (4+0j) (5+0j) (6+0j) (7+0j) (8+0j) (9+0j) (10+0j) (10+0j) (10+0j) (10+0j) (10+0j) (10+0j) (10+0j) (1+0j) (2+0j) (3+0j) (4+0j) (5+0j) (6+0j) (7+0j) (8+0j) . . etc Which is wrong (after the first 10 outputs the output should
Re: [Discuss-gnuradio] Re: Problem with FIR filter
On Thu, Jul 22, 2010 at 6:48 PM, Eric Blossom e...@comsec.com wrote: On Thu, Jul 22, 2010 at 05:13:09PM +0100, John Wilson wrote: So does no one have any idea about this? It doesn't seem like it should be too difficult to solve, I've worked around the problem for the simulations I'm currently running but it's a shame as it reveals a fundamental incapacity for GNU Radio to perform some other interesting simulations and techniques, notably (for me at least) in the area of repeat requests. Currently I'm implementing a type II HARQ repeat request system by dynamically reconfiguring a flow graph during operation, this makes use of the run() command a lot but if every time I run this command every filter in the system is reset it's going to make it almost impossible to implement. Part of the challenge in implementing dynamic reconfiguration is what to do with any intermediate samples left over in the buffers. This brings up questions such as do the blocks own the buffers? If so, does the upstream block own the buffer, or the downstream block? What about the cases where there are multiple downstream readers of a buffer? What happens if you replace the upstream block? What about the downstream block? With regards to the FIRs, I think what you're seeing is a side effect of our decision to implement the delay line implicitly. That is, it's handled using the history mechanism, and involves pre-stuffing the input buffer with zeros. The chief advantage of this strategy is performance. This idea combined with the our zero copy MMU circular buffer trick, means there are no corner cases in the implementation of the FIRs (no end-of-buffer wrap around etc.) and no cycles are expended storing anything in any delay line. (Having versions of the FIRs that explicity handle a delay line is definitely possible.) I understand, so I'm guessing the operation of the FIRs is a lot more 'fundamental' than the other common blocks in that their operation is quite intimately tied up with the lower level buffer management of the flow graph itself. I've read about the history mechanism, and I understand that when flow graph edges are reconfigured then not calling it could cause problems. However in my case I don't need the graph edges connecting to the FIR to change at all, in fact I need them to stay in the exact state that they were left in when wait() was called to maintain the data integrity through these buffers (and therefore the FIR). To put this into context the part of the graph that's causing a problem is part of the channel model, a Watterson model which goes something like this; Signal In I v WGN - Gaussian Filter - Interpolation - Anti-Aliasing filter - Multiply I v AWGN I v Signal Out The anti-aliasing filter has a large number of taps compared to each packet length. I was hoping to send one packet at a time, check it and re-run the graph, starting the model from here it left off, the model takes a few thousand bits sent through it to fill up the buffers, so the first few packets send through it are received as rubbish. When sending one packet at a time between resets, it's always rubbish! I fixed this by just sending all my packets in one transmission and checking them at the block level with a custom block, but the repeat request techniques I have require that the run() method be called. Looking back at my ARQ test code (which I wrote a while back) I can see that it was a bit of a hack, I'm instructing my transmit source to 'send nothing' when a repeat is needed, by this I mean the start point is actually requested to run the work function again, copy nothing to the buffer and return 0. The repeat packet generator then generates the actual data to be transmitted. This is to fool GNU Radio into believing that its sending something from the start point of the graph and is clearly related to this issue. So me calling this a 'serious bug' might have been a little melodramatic! I understand that you're relating with this like it's a serious bug, but I think it would be more productive if you would specify exactly the behavior that you want, see if that spec is consistent with expectations that other folks may have (for their own good reasons), and then we could discuss where in the code the modifications would go. A related question is when (if ever) should runtime state (both external to a block, like the buffers) and internal state (say PLL state inside of a block) be reset. This is a good question and I think it would be nice to build in a little more user involvement into this. I think there needs to be a further state that can be entered on request, where the graph can be paused under certain conditions without causing a reset of some or all of the buffers on the graph edges, for instance when the graph detects that no further data is being 'pulled' towards the end point (I'm guessing
