[Discuss-gnuradio] Build Configuration Q
I'm working (again) on the MacPorts port and files associated with GNU Radio, playing with GNU Radio's "Build Configuration" options in order to get a separate package for each component (e.g. one each for "gnuradio-core", "usrp", "gr-usrp", and so forth). I note that on the BuildConfiguration wiki page < http://www.gnuradio.org/trac/wiki/ BuildConfiguration >, under "WARNING" it reads: "Individual GNU Radio components may depend upon other components (such as gnuradio-core) to successfully compile. In particular, during a build the library and include search paths point to the current build tree, not the system installation path. So one will need to either have compiled the dependent components already in a prior build (not necessary to install them), or one will have to build all the related components at once." While this is desirable from the perspective of maintaining consistency among the various components (same version, or save SVN revision; when one is updated, the other will be recompiled as well, and so forth), it makes building separate components somewhat of a PITA when using MacPorts: * creating the gnuradio-core package requires just omnithread, which is fine since that's not a big extra compile, but ... * creating the gr-usrp package requires the (re)compilation of usrp, gnuradio-core, and omnithread .. which is "up there" in terms of time because of (re)compiling gnuradio-core. For MacPorts, I don't have the option of re-using a single compiled trunk or tarball; I have to recompile everything for each component. While I can write Portfile's that can do this, it would be easier if there was a way around it - using some specific CONFIGURE options or MAKE environment variables that do allow for compiling just the component itself instead of it and all of its dependencies (which are already installed by MacPorts). Anyone know how to do this, or is it really just impossible? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re:[Discuss-gnuradio]Can not creating a flow graph
Hi Jacky , As far as I understand your question, you are expecting a GUI from the example, dial_tone.py. But gr.flow_graph is a used for connecting the different signal processing blocks, and ensures a proper data flow from the source to sink in the dial_tone.py case. Thus, the target of the program is linking the signal source with the audio sink. So, since you hear a sound ( a dial tone), the program executed successfully. If you are looking for a GUI, you can install GNU radio companion(GRC). Then, you can play with the different signal processing blocks. I think I have answered your question. Fasika - Looking for last minute shopping deals? Find them fast with Yahoo! Search.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
I would like to thank again Josh for the wonderfull job on GRC: I am now using it regularly for my classroom demonstrations on analog/digital communications. I have noticed (it has been more than 6 months since the last time I used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). In fact, 8 out of 10 times that I stop a running graph (usually with 4-5 graphical sinks running) either by closing the graph window or by pressing the "stop" button on the graphical editor of GRC, it closes the entire GRC editor... Can someone confirm this behavior? Thanks Achilleas PS: I have to add one more item on my wish list for 0.70 :-) In the "open file" and "save file" dialog boxes, make "open" and "save" the default action when pressing "enter", so you wont have to press the button with the mouse... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
Frank Brickle used GRC for our SDR class design lab. It was a success. I cannot comment on the crash. Bob Achilleas Anastasopoulos wrote: I would like to thank again Josh for the wonderfull job on GRC: I am now using it regularly for my classroom demonstrations on analog/digital communications. I have noticed (it has been more than 6 months since the last time I used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). In fact, 8 out of 10 times that I stop a running graph (usually with 4-5 graphical sinks running) either by closing the graph window or by pressing the "stop" button on the graphical editor of GRC, it closes the entire GRC editor... Can someone confirm this behavior? Thanks Achilleas PS: I have to add one more item on my wish list for 0.70 :-) In the "open file" and "save file" dialog boxes, make "open" and "save" the default action when pressing "enter", so you wont have to press the button with the mouse... ___ 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] ISE Project navigator and ISE files
On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O'Connor wrote: > On Wed, 16 Jan 2008, Ignacio wrote: > > I use xilinx ise tools regularly so please do not commit the whole > > ise project, this generates a corrupted project sooner o later. > > Xilinx made a workaround to make versioning of the files, please > > check this link to do it: > > http://forums.xilinx.com/xlnx/board/message?board.id=ISE&message.id=8 > >25#M825 By the way, take into account that if you use a makefile to > > Interesting! > It would seem the export option basically just generates the script I > wrote, but automatically. (Not that I can test it ATM, no 9.1 installs > handy) > > > build the bitstream file, you can not use ise to manage the project, > > specially if you use coregen. > > Hmm I think you can use both but you end up duplicating settings in the > makefile which is annoying (and potentially dangerous) We're not using coregen, so that part shouldn't be a problem. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE Project navigator and ISE files
Eric- > On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O'Connor wrote: > > On Wed, 16 Jan 2008, Ignacio wrote: > > > I use xilinx ise tools regularly so please do not commit the whole > > > ise project, this generates a corrupted project sooner o later. > > > Xilinx made a workaround to make versioning of the files, please > > > check this link to do it: > > > http://forums.xilinx.com/xlnx/board/message?board.id=ISE&message.id=8 > > >25#M825 By the way, take into account that if you use a makefile to > > > > Interesting! > > It would seem the export option basically just generates the script I > > wrote, but automatically. (Not that I can test it ATM, no 9.1 installs > > handy) > > > > > build the bitstream file, you can not use ise to manage the project, > > > specially if you use coregen. > > > > Hmm I think you can use both but you end up duplicating settings in the > > makefile which is annoying (and potentially dangerous) > > We're not using coregen, so that part shouldn't be a problem. How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a 'non-Xilinx' method? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE Project navigator and ISE files
Eric- > On Thu, Jan 17, 2008 at 11:55:42AM -0600, Jeff Brower wrote: > > Eric- > > > > > On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O'Connor wrote: > > > > On Wed, 16 Jan 2008, Ignacio wrote: > > > > > I use xilinx ise tools regularly so please do not commit the whole > > > > > ise project, this generates a corrupted project sooner o later. > > > > > Xilinx made a workaround to make versioning of the files, please > > > > > check this link to do it: > > > > > http://forums.xilinx.com/xlnx/board/message?board.id=ISE&message.id=8 > > > > >25#M825 By the way, take into account that if you use a makefile to > > > > > > > > Interesting! > > > > It would seem the export option basically just generates the script I > > > > wrote, but automatically. (Not that I can test it ATM, no 9.1 installs > > > > handy) > > > > > > > > > build the bitstream file, you can not use ise to manage the project, > > > > > specially if you use coregen. > > > > > > > > Hmm I think you can use both but you end up duplicating settings in the > > > > makefile which is annoying (and potentially dangerous) > > > > > > We're not using coregen, so that part shouldn't be a problem. > > > > How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a > > 'non-Xilinx' > > method? > > We write them in verilog. We like to avoid vendor specific code when > possible, and non-free code like the plague. > > We've pulled a fair amount of stuff from opencores.org. We've found > that the quality of code there is highly variable. Matt's fixed the > parts we care about, or found people to fix them. This includes a GbE > MAC, wishbone compatible microblaze knock off (currently running at > 50 MHz in a Spartan 3), lots of simple periperals such as I2C, SPI, > UART, interrupt controller, etc. That free software / open source > idea really does work ;) Ok understand. Matt's expertise is the key then, patching and fixing as needed. Otherwise you'd be dependent on the originators, which as I'm sure you've found they can sometimes be less than reliable or in the worst case no longer "findable". What about the Microblaze clone... would Xilinx have any issue with that? I would hope not since it's their chips being used. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build Configuration Q
On Jan 17, 2008, at 1:14 PM, Eric Blossom wrote: Michael, this is ticket:186, "Add option to disable intree dependencies", aka the "pkgsrc enhancement". Right now it's not possible. OK. Good to know it's in the queue somewhere. Any idea how difficult this would be to implement? Any hints on getting started? I'm writing a paper right now that's due Feb 1, and need some alternative-activity time every so often, and if I could figure out what to do it would "kill multiple birds with one stone" as the saying sort of goes. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE Project navigator and ISE files
On Thu, Jan 17, 2008 at 11:55:42AM -0600, Jeff Brower wrote: > Eric- > > > On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O'Connor wrote: > > > On Wed, 16 Jan 2008, Ignacio wrote: > > > > I use xilinx ise tools regularly so please do not commit the whole > > > > ise project, this generates a corrupted project sooner o later. > > > > Xilinx made a workaround to make versioning of the files, please > > > > check this link to do it: > > > > http://forums.xilinx.com/xlnx/board/message?board.id=ISE&message.id=8 > > > >25#M825 By the way, take into account that if you use a makefile to > > > > > > Interesting! > > > It would seem the export option basically just generates the script I > > > wrote, but automatically. (Not that I can test it ATM, no 9.1 installs > > > handy) > > > > > > > build the bitstream file, you can not use ise to manage the project, > > > > specially if you use coregen. > > > > > > Hmm I think you can use both but you end up duplicating settings in the > > > makefile which is annoying (and potentially dangerous) > > > > We're not using coregen, so that part shouldn't be a problem. > > How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a > 'non-Xilinx' > method? We write them in verilog. We like to avoid vendor specific code when possible, and non-free code like the plague. We've pulled a fair amount of stuff from opencores.org. We've found that the quality of code there is highly variable. Matt's fixed the parts we care about, or found people to fix them. This includes a GbE MAC, wishbone compatible microblaze knock off (currently running at 50 MHz in a Spartan 3), lots of simple periperals such as I2C, SPI, UART, interrupt controller, etc. That free software / open source idea really does work ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] install USRP drivers only?
All - I have an application for the USRP that does not use GNU Radio. Is there any simple way to install just those components required for the USRP driver? This is important because the application will eventually need to be embedded, but even during development we'd like to avoid having to install all of these other packages. -- David David A. Burgess Kestrel Signal Processing, Inc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build Configuration Q
On Thu, Jan 17, 2008 at 01:35:50PM -0500, Michael Dickens wrote: > On Jan 17, 2008, at 1:14 PM, Eric Blossom wrote: >> Michael, this is ticket:186, "Add option to disable intree >> dependencies", aka the "pkgsrc enhancement". Right now it's not >> possible. > > OK. Good to know it's in the queue somewhere. Any idea how difficult this > would be to implement? Any hints on getting started? I'm writing a paper > right now that's due Feb 1, and need some alternative-activity time every > so often, and if I could figure out what to do it would "kill multiple > birds with one stone" as the saying sort of goes. - MLD I think the first thing is to decide how you want it to behave, and what configure time options you'd want. I want to maintain the current behavior as the default, as it allows us to robustly test in the build tree prior to installing using make check. You should think carefully about how you want linking and "make check" to work in the case where you're pulling some stuff from the build tree and some from the installed location. How are you going to specify which libraries are loaded from which locations, etc? Finally, I'd worry about how to implement this so that it's clean and transparent to 95% of the code. That is, find a way to hide the hair in one or two places. Makefile.common might be one of them. Good luck on the paper, and "killing multiple birds". Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] top block segfaults
On Thu, Jan 17, 2008 at 12:36:38AM -0700, beezle bub wrote: > > Hey there again, > > Usually when I get segfaults, it's because my own C++ code does > something stupid. When I run it through the debugger, it always > lets me know where the problem is in the C++ code (that's how I know > it's the C++ code causing the problem). Imagine my surprise as I > got something to segfault in Python. > > For some reason the top block code is causing a segfault for me, and > I don't know why. Is there anything in top block that could cause > this? Or, is it more likely likely a problem with my own python > code? > > Here's the debug output: > > -> tb.run() > (Pdb) step > --Call-- > > /usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py(50)run() > -> def run(self): > (Pdb) step > > /usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py(51)run() > -> top_block_run_unlocked(self._tb) > (Pdb) step > --Call-- > > /usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py(1577)top_block_run_unlocked() > -> def top_block_run_unlocked(*args): > (Pdb) step > > /usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py(1579)top_block_run_unlocked() > -> return _gnuradio_swig_py_runtime.top_block_run_unlocked(*args) > (Pdb) step > Segmentation fault (core dumped) > > Any help you could give me would be greatly appreciated. > > -Ben Ben, it would be easier to figure out if you let us know the code you're trying to run, and what it looks like from the command line. This could be the "failing to trap exception problem", but from what you're showing us I can't tell. Also, GDB does a better job on our mixed C++/python code than pdb. Directions on running it in http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html#debugging Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Need info for paper.
I'm co-writing a paper on the use of GNU Radio. Because I'm inclined to use 'Open Source' solutions, GNU Radio and the attendant DSP library, was for me about the only choice I would have made... However, in the paper I'd like to at least make some attempt at indicating any 'alternatives', if there are any in the Open Source arena, or parish the thought, cost-money type packages. If anyone has done a more detailed evaluation and perhaps has a chart depicting features, that would be good. Also, a while ago, I saw someone who had put together a 'graphical' interface, where one could construct a DSP processor using graphical means, and setting various parameters using a GUI. I have not had the time to really keep up on that sort of thing, but if there is someone who has something that works, I'd also like to know about that. For those who have information, and send me a release, credit will be made in the paper for their contribution. Thanks, John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE Project navigator and ISE files
On Thu, Jan 17, 2008 at 12:35:59PM -0600, Jeff Brower wrote: > Eric- > > > > > We're not using coregen, so that part shouldn't be a problem. > > > > > > How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a > > > 'non-Xilinx' > > > method? > > > > We write them in verilog. We like to avoid vendor specific code when > > possible, and non-free code like the plague. > > > > We've pulled a fair amount of stuff from opencores.org. We've found > > that the quality of code there is highly variable. Matt's fixed the > > parts we care about, or found people to fix them. This includes a GbE > > MAC, wishbone compatible microblaze knock off (currently running at > > 50 MHz in a Spartan 3), lots of simple periperals such as I2C, SPI, > > UART, interrupt controller, etc. That free software / open source > > idea really does work ;) > > Ok understand. Matt's expertise is the key then, patching and fixing as > needed. And contributing the fixes back. > Otherwise you'd be dependent on the originators, which as I'm sure you've > found they > can sometimes be less than reliable or in the worst case no longer "findable". Same as with pretty much anything. That's why the code's there. > What about the Microblaze clone... would Xilinx have any issue with that? Shouldn't be any problem regardless of where we're running it. It's a clean-room implementation that executes the same instruction set. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
On Fri, 18 Jan 2008 03:09:29 am Achilleas Anastasopoulos wrote: > I would like to thank again Josh for the wonderfull job on GRC: > I am now using it regularly for my classroom demonstrations on > analog/digital communications. > > I have noticed (it has been more than 6 months since the last time I > used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). > In fact, 8 out of 10 times that I stop a running graph (usually with 4-5 > graphical sinks running) either by closing the graph window or by > pressing the "stop" button on the graphical editor of GRC, it closes the > entire GRC editor... > > Can someone confirm this behavior? > > Thanks > Achilleas > > > PS: I have to add one more item on my wish list for 0.70 :-) > In the "open file" and "save file" dialog boxes, make "open" and "save" > the default action when pressing "enter", so you wont have to press the > button with the mouse... G'day, I can confirm your observation. This is exactly my experience here too. I'm running NetBSD-i386-current 4.99.42. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE Project navigator and ISE files
On Jan 17, 2008 12:55 PM, Jeff Brower <[EMAIL PROTECTED]> wrote: > How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a > 'non-Xilinx' > method? I don't think there's any SDRAM on the new USRP2, but if there were, you can still write an SDRAM controller in RTL. DDR, on the other hand, has some different requirements. For the other stuff, RTL should work just fine. The repository is here: http://gnuradio.org/trac/browser/usrp2/trunk/fpga Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need info for paper.
Hi John, There are a couple other SDR-type platforms in the academic world... but none really come close to the code base of GR IMO. Rice has WARP: http://warp.rice.edu/ Kansas is developing the KU Agile Radio: http://www.ittc.ku.edu/techreview2005/presentations/Minden_Agile%20Radios.ppt UCSD has the CalRadio: http://calradio.calit2.net/ WARP is a very expensive platform IMO, and they are not as modular as GNU Radio. I would say GNU Radio has far more in the PHY layer, and WARP has 1 PHY (OFDM) + a bunch of MAC implementations. The KU Agile radio is still pretty new, Prof. Minden gave a talk here about it last semester and it seemed the hardware was pretty concrete but the software was still in progress... which is what truly separates SDR platforms :) CalRadio v1 is strict 802.11 based, and the PHY is not flexible. I think their goal was to keep the PHY in hardware and swap out daughterboards with different PHYs that you could re-program the MAC on. - George John Clark wrote: I'm co-writing a paper on the use of GNU Radio. Because I'm inclined to use 'Open Source' solutions, GNU Radio and the attendant DSP library, was for me about the only choice I would have made... However, in the paper I'd like to at least make some attempt at indicating any 'alternatives', if there are any in the Open Source arena, or parish the thought, cost-money type packages. If anyone has done a more detailed evaluation and perhaps has a chart depicting features, that would be good. Also, a while ago, I saw someone who had put together a 'graphical' interface, where one could construct a DSP processor using graphical means, and setting various parameters using a GUI. I have not had the time to really keep up on that sort of thing, but if there is someone who has something that works, I'd also like to know about that. For those who have information, and send me a release, credit will be made in the paper for their contribution. Thanks, John Clark. ___ 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] top block segfaults
beezle bub wrote: > For some reason the top block code is causing a segfault for me, and > I don't know why. Is there anything in top block that could cause > this? Or, is it more likely likely a problem with my own python > code? We currently have an open bug in the trunk and stable branches: http://gnuradio.org/trac/ticket/181 This, on the systems that exhibit it, will turn (some) exceptions thrown in swig wrapped C++ into aborts, even when the code is there to catch the exception and handle it gracefully. Since the new flow graph code in 3.1 is all done in C++ (in anticipation of allowing pure C++ GNU Radio applications in 3.2), if there is a misconfigured flowgraph in the user's Python code, the C++ runtime will throw an exception and the handler will report it with a helpful message. But, because of ticket:181, it simply becomes a segfault instead. That's probably what you're seeing here. To track down the original problem, execute Python and your script entirely from gdb. When you get the abort, do an 'info threads' and 'thread apply all bt'. On the faulting thread, a couple of stack frames from the top, will be the GNU Radio code that threw the exception. Switch to that frame and list the code, you'll see the conditional test and the proper error message. In your case, the function running was tb.run(), which invokes numerous checks on the flow graph topology before handing it to the scheduler, so one of these checks is probably failing. Ticket:181 is our highest priority bug at this point, and after many hours of tracing through swig generated code and x86 assembly, we think it is either a swig bug or (less likely) a gcc bug. The conditions (gcc version, swig version, 64-bit vs. 32-bit, Python version, specific exception) that trigger it are not consistent either, but when it does happen, it happens reliably. Eric and I have spent many hours trying to tackle this one--any help is appreciated. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] install USRP drivers only?
On Thu, Jan 17, 2008 at 11:18:05AM -0800, David Burgess wrote: > All - > > I have an application for the USRP that does not use GNU Radio. Is there > any simple way to install just those components required for the USRP > driver? This is important because the application will eventually need to > be embedded, but even during development we'd like to avoid having to > install all of these other packages. > > -- David > > David A. Burgess > Kestrel Signal Processing, Inc. > On the stable branch or 3.1.* tarballs this should work: ./configure --disable-all-components --enable-usrp make On the trunk ./configure --disable-all-components \ --enable-usrp --enable-omnithread --enable-mblock --enable-pmt make See http://gnuradio.org/trac/wiki/BuildConfiguration http://gnuradio.org/trac/wiki/BuildGuide Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help with DSP Cores for USRP2
I could use some help creating some DSP cores for the USRP2 since I'm very busy with other parts of the design. Some basic parameters: Clock Rate -- 100 MHz Sample format -- 16 or 18 bit 2's complement When sample streams are at a rate lower than 100 MS/s, valid samples are accompanied by a strobe signal Use distributed RAM or SRL16s, but not block RAM You can use hard multipliers or distributed arithmetic Filter taps should be writable Some cores which would be useful: 1 Halfband decimator Samples should come in at a settable rate of up to one half the clock rate and exit at half that rate (i.e. up to one fourth the clock rate). You'll probably need 2 hard multipliers. That gives you 8 multiplies per sample, giving you a 31-tap halfband filter. 2 Interpolator equivalent to the above. 3 For bonus points, make either of the above controllable such that at lower sample rates they use the extra cycles to implement a 63-tap halfband filter. 4 A decimate-by-5 filter which takes in samples at up to the full clock rate and outputs them at 1/5 of that rate. It should not be a CIC decimate-by-5 filter, but could be a CIC decimate by 2 followed by a decimate-by-2.5 polyphase filter. 5 The interpolator equivalent of the above. 6 Testbenches for any of the above, even if you aren't designing the filter core itself. I'd prefer not to use Xilinx cores, but you can use those to see what sort of performance should be attainable. Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build Configuration Q
On Thu, Jan 17, 2008 at 09:54:55AM -0500, Michael Dickens wrote: > I'm working (again) on the MacPorts port and files associated with GNU > Radio, playing with GNU Radio's "Build Configuration" options in order to > get a separate package for each component (e.g. one each for > "gnuradio-core", "usrp", "gr-usrp", and so forth). I note that on the > BuildConfiguration wiki page < > http://www.gnuradio.org/trac/wiki/BuildConfiguration >, under "WARNING" it > reads: > > "Individual GNU Radio components may depend upon other components (such as > gnuradio-core) to successfully compile. In particular, during a build the > library and include search paths point to the current build tree, not the > system installation path. So one will need to either have compiled the > dependent components already in a prior build (not necessary to install > them), or one will have to build all the related components at once." > > While this is desirable from the perspective of maintaining consistency > among the various components (same version, or save SVN revision; when one > is updated, the other will be recompiled as well, and so forth), it makes > building separate components somewhat of a PITA when using MacPorts: > > * creating the gnuradio-core package requires just omnithread, which is > fine since that's not a big extra compile, but ... > > * creating the gr-usrp package requires the (re)compilation of usrp, > gnuradio-core, and omnithread .. which is "up there" in terms of time > because of (re)compiling gnuradio-core. > > For MacPorts, I don't have the option of re-using a single compiled trunk > or tarball; I have to recompile everything for each component. While I can > write Portfile's that can do this, it would be easier if there was a way > around it - using some specific CONFIGURE options or MAKE environment > variables that do allow for compiling just the component itself instead of > it and all of its dependencies (which are already installed by MacPorts). > > Anyone know how to do this, or is it really just impossible? - MLD Michael, this is ticket:186, "Add option to disable intree dependencies", aka the "pkgsrc enhancement". Right now it's not possible. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE Project navigator and ISE files
Brian- > On Jan 17, 2008 12:55 PM, Jeff Brower <[EMAIL PROTECTED]> wrote: > > How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a > > 'non-Xilinx' > > method? > > I don't think there's any SDRAM on the new USRP2, but if there were, > you can still write an SDRAM controller in RTL. DDR, on the other > hand, has some different requirements. > > For the other stuff, RTL should work just fine. The repository is here: > > http://gnuradio.org/trac/browser/usrp2/trunk/fpga Ok... would prefer Verilog, which Eric indicates he and Matt are using. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Gnu Radio Companion (GRC) 0.69 experience
I was using FC7(32-bit) and GRC 0.69 for a little while. I too noticed GRC closing completely, but I do not have enough details to back-up your exact pattern. Come to think about it though, it happened more often than not in graphs that had a lot of sinks in them... I have not used GRC in some time, but I do have to say that if it doesn't exist already, it would have been nice to have access to the code of the actual graph that was being created. Something like an "export to .py" or if you really wanted to win my heart a gnu-radio 3.2 "export to c". > > Achilleas Anastasopoulos wrote: > > > > I would like to thank again Josh for the wonderfull job on GRC: > > I am now using it regularly for my classroom demonstrations on > > analog/digital communications. > > > > I have noticed (it has been more than 6 months since the last time I > > used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). > > In fact, 8 out of 10 times that I stop a running graph (usually with > > 4-5 graphical sinks running) either by closing the graph window or by > > pressing the "stop" button on the graphical editor of GRC, it closes > > the entire GRC editor... > > > > Can someone confirm this behavior? > > > > Thanks > > Achilleas > > > > > > PS: I have to add one more item on my wish list for 0.70 :-) > > In the "open file" and "save file" dialog boxes, make "open" and > > "save" the default action when pressing "enter", so you wont have to > > press the button with the mouse... > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Gnu Radio Companion (GRC) 0.69 experience
Hello,
On Jan 17, 2008 1:56 PM, Jeffrey Karrels <[EMAIL PROTECTED]> wrote:
> I was using FC7(32-bit) and GRC 0.69 for a little while. I too noticed
> GRC closing completely, but I do not have enough details to back-up
> your exact pattern. Come to think about it though, it happened more
> often than not in graphs that had a lot of sinks in them...
Strange. I have been running GRC on ubuntu and never noticed this.
Flow graphs are run with os.system("./ExecFlowGraphGUI.py
myflowgraph.xml"). So the flow graph is running as a separate process.
The stop button in GRC calls a kill -9 on the pid of this process.
Perhaps this has something to do with the flowgraph begin executed
from the same shell as GRC.
May I ask what version of python 2.4, 2.5, 3?
Is there someway to make this more robust?
In the meantime, you can run ./ExecFlowGraphGUI.py myflowgraph.xml
manually in a separate shell (should help).
>
> I have not used GRC in some time, but I do have to say that if it
> doesn't exist already, it would have been nice to have access to the
> code of the actual graph that was being created. Something like an
> "export to .py" or if you really wanted to win my heart a gnu-radio
> 3.2 "export to c".
>
Good news then: I plan to work on GRC this semester. One of the goals
is to generate the .py files. To do this, I will turn grc into a
module that actually has to appear in the python path, such as "import
grc". This module will contain custom signal blocks and wrappers for
some of the blocks.
I suppose, once that all works, there could be a separate set of block
definitions for c++ blocks, and one could make flow graps in GRC and
export it to cpp. As long as the GUI is general enough.
If any one has any wishlist requests, let me know.
-Josh
>
> >
> > Achilleas Anastasopoulos wrote:
> > >
> > > I would like to thank again Josh for the wonderfull job on GRC:
> > > I am now using it regularly for my classroom demonstrations on
> > > analog/digital communications.
> > >
> > > I have noticed (it has been more than 6 months since the last time I
> > > used it) that 0.69 version crashes a lot with my fedora 7 (64 bit).
> > > In fact, 8 out of 10 times that I stop a running graph (usually with
> > > 4-5 graphical sinks running) either by closing the graph window or by
> > > pressing the "stop" button on the graphical editor of GRC, it closes
> > > the entire GRC editor...
> > >
> > > Can someone confirm this behavior?
> > >
> > > Thanks
> > > Achilleas
> > >
> > >
> > > PS: I have to add one more item on my wish list for 0.70 :-)
> > > In the "open file" and "save file" dialog boxes, make "open" and
> > > "save" the default action when pressing "enter", so you wont have to
> > > press the button with the mouse...
> > >
> > >
>
>
>
> ___
> 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] Build error under OS X
According to < http://www.gnuradio.org/trac/browser/gnuradio/trunk/ README > , (10), you need guile 1.6 or 1.8 . Try upgrading to either of those, and if that doesn't fix the problem then we'll try something else. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
Josh, I am using python 2.5. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
As a follow up to the previous message regarding the segfault issue with
ticket:181, here is a simple test case that shows the problem. See the
end of this email for a request to help document which systems this
occurs on (you won't need to do all the below, or use gdb as shown; just
run a couple commands.)
The problem in short:
$ python
Python 2.5.1 (r251:54863, Oct 5 2007, 13:50:07)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import gr
>>> gr.firdes.hilbert(0)
terminate called after throwing an instance of 'std::out_of_range'
what(): Hilbert: Must have odd number of taps
Aborted (core dumped)
$
To show the problem in gory detail:
First, run Python inside gdb:
$ gdb python
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb)
Then run it to get the interactive prompt:
(gdb) run
Starting program: /usr/bin/python
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47791743497952 (LWP 9791)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Python 2.5.1 (r251:54863, Oct 5 2007, 13:50:07)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
>>>
Now execute a command that will generate an exception in swig wrapped
C++ code. In this case, we call the Hilbert filter generator with an
invalid number of taps. What should happen is that the swig wrapper
would catch this C++ exception and turn it into a Python exception,
which would then get printed and control returned to the Python command
line. Instead:
>>> from gnuradio import gr
>>> gr.firdes.hilbert(0)
terminate called after throwing an instance of 'std::out_of_range'
what(): Hilbert: Must have odd number of taps
Program received signal SIGABRT, Aborted.
[Switching to Thread 47791743497952 (LWP 9791)]
0x2b7761b25765 in raise () from /lib/libc.so.6
(gdb)
This above is what would happen if the exception thrown by GNU Radio C++
code were not being caught; it would unwind and eventually blow out the
top with an abort like above. However, lets look at the stack:
(gdb) info threads
* 1 Thread 47791743497952 (LWP 9791) 0x2b7761b25765 in raise ()
from /lib/libc.so.6
(gdb) thread apply all bt
Thread 1 (Thread 47791743497952 (LWP 9791)):
#0 0x2b7761b25765 in raise () from /lib/libc.so.6
#1 0x2b7761b271c0 in abort () from /lib/libc.so.6
#2 0x2b7762f2c7b4 in __gnu_cxx::__verbose_terminate_handler () from
/usr/lib/libstdc++.so.6
#3 0x2b7762f2a746 in ?? () from /usr/lib/libstdc++.so.6
#4 0x2b7762f2a773 in std::terminate () from /usr/lib/libstdc++.so.6
#5 0x2b7762f2a85a in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x2b7762b56ea6 in gr_firdes::hilbert (ntaps=0,
windowtype=gr_firdes::WIN_RECTANGULAR, beta=6.7598) at
gr_firdes.cc:306
#7 0x2b7763f11f7f in _wrap_firdes_hilbert (self=0x0, args=) at gnuradio_swig_py_general.cc:24183
#8 0x00417e53 in PyObject_Call ()
#9 0x00486997 in PyEval_EvalFrameEx ()
#10 0x00489d60 in PyEval_EvalCodeEx ()
#11 0x00487f32 in PyEval_EvalFrameEx ()
#12 0x00489d60 in PyEval_EvalCodeEx ()
#13 0x00489da2 in PyEval_EvalCode ()
#14 0x004abbb7 in PyRun_InteractiveOneFlags ()
#15 0x004abdc4 in PyRun_InteractiveLoopFlags ()
#16 0x004abeca in PyRun_AnyFileExFlags ()
#17 0x00414725 in Py_Main ()
#18 0x2b7761b11b44 in __libc_start_main () from /lib/libc.so.6
#19 0x00413c69 in _start ()
(gdb)
Stack frame #7 is the call to the swig generated C++ wrapper, #6 is the
actual GNU Radio C++ implementation of the Hilbert code. Let's look at #6:
(gdb) up 6
#6 0x2b7762b56ea6 in gr_firdes::hilbert (ntaps=0,
windowtype=gr_firdes::WIN_RECTANGULAR, beta=6.7598) at
gr_firdes.cc:306
306 throw std::out_of_range("Hilbert: Must have odd number of
taps");
Current language: auto; currently c++
(gdb) l
301 gr_firdes::hilbert (unsigned int ntaps,
302 win_type windowtype,
303 double beta)
304 {
305 if(!(ntaps & 1))
306 throw std::out_of_range("Hilbert: Must have odd number of
taps");
307
308 vector taps(ntaps);
309 vector w = w
Re: [Discuss-gnuradio] Build error under OS X
On Thu, Jan 17, 2008 at 12:29:15PM -0800, David Burgess wrote: > All - > > I just tried to build the trunk gnuradio from SVN under OS X 10.4.11 with > > ./configure --disable-all-components --enable-usrp --enable-omnithread > --enable-mblock --enable-pmt > make -j 2 > > > It ended thus: > > ... > GUILE_LOAD_PATH="/Users/dburgess/RangeNetworks/rangeNetworks/openBTS2/packages/gnuradio/pmt/src/lib/../../../pmt/src/scheme:/Users/dburgess/RangeNetworks/rangeNetworks/openBTS2/packages/gnuradio/pmt/src/lib/../../../mblock/src/scheme" > > /sw/bin/guile -e main -s ./../scheme/gnuradio/gen-serial-tags.scm > ./../scheme/gnuradio/pmt-serial-tags.scm pmt_serial_tags.h > ERROR: Unbound variable: port? > make[4]: *** [pmt_serial_tags.h] Error 2 > make[4]: *** Waiting for unfinished jobs > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > > I have no idea what this means or how to fix it. Does anyone else out > there? I have guile 1.4, if that matters. You need Guile 1.6 or later. 1.6 was released in 2002, so it's been out for a while. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_msg_queue
On Thu, Jan 17, 2008 at 03:19:21PM -0500, Tim O'Shea wrote: > Hi Eric, > > I have a gnuradio question, I posted this to the list but I don't think it > was accepted. Sorry, you have to post from a subscribed address. We don't generate an automatic response since several RBL's black list us when we do... http://gnuradio.org/trac/wiki/MailingLists > I have a flow graph which diverges down several pathways, and ends in > several separate gr_msg_queue's, my initial design was to have one python > thread running as a handler for each queue, > so each handler process would sit on delete_head() until a new item arrived. > > However it seems that if any more than a single python thread is using > delete_head() at one time, random memory access crashes seem to occur. Do you have a simple test case that reproduces it? If it's our bug we should fix it. > Is there a clean way to block on multiple queues currently in svn ? Not right now. However you may be able to use a loop that includes m0 = msgq0.delete_head_nowait() m1 = msgq1.delete_head_nowait() time.sleep(0.010) or something similar > I saw reference to a message passing interface of some sort upcoming, > but I assume this is not currently available ? Not yet ready for prime time. >Thanks, >-Tim Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Michael Dickens wrote: > % python > Python 2.5.1 (r251:54863, Jan 5 2008, 16:11:24) > [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin > Type "help", "copyright", "credits" or "license" for more information. from gnuradio import gr gr.firdes.hilbert(0) > Traceback (most recent call last): > File "", line 1, in > File > "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_general.py", > line 2837, in hilbert > return _gnuradio_swig_py_general.firdes_hilbert(*args) > IndexError: Hilbert: Must have odd number of taps We have a winner :-) Just FYI, the above is what is supposed to happen, with the C++ exception being turned into a Python exception by swig and control returned to the Python command line. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build error under OS X
All - I just tried to build the trunk gnuradio from SVN under OS X 10.4.11 with ./configure --disable-all-components --enable-usrp --enable- omnithread --enable-mblock --enable-pmt make -j 2 It ended thus: ... GUILE_LOAD_PATH="/Users/dburgess/RangeNetworks/rangeNetworks/openBTS2/ packages/gnuradio/pmt/src/lib/../../../pmt/src/scheme:/Users/dburgess/ RangeNetworks/rangeNetworks/openBTS2/packages/gnuradio/pmt/src/ lib/../../../mblock/src/scheme" /sw/bin/guile -e main -s ./../scheme/ gnuradio/gen-serial-tags.scm ./../scheme/gnuradio/pmt-serial-tags.scm pmt_serial_tags.h ERROR: Unbound variable: port? make[4]: *** [pmt_serial_tags.h] Error 2 make[4]: *** Waiting for unfinished jobs make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I have no idea what this means or how to fix it. Does anyone else out there? I have guile 1.4, if that matters. -- David David A. Burgess Kestrel Signal Processing, Inc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Hi, I get the same error. My system is Ubuntu Edgy, Intel Core 2 Duo, Macbook pro, fairly old SVN build of gnuradio. j@ /gnuradio> svn info Path: . URL: http://gnuradio.org/svn/gnuradio/trunk Repository Root: http://gnuradio.org/svn Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5 Revision: 6441 Node Kind: directory Schedule: normal Last Changed Author: eb Last Changed Rev: 6429 Last Changed Date: 2007-09-13 23:21:41 + (Thu, 13 Sep 2007) > uname -a Linux mcbook 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux Here is the listing, which hopefully contains all the necessary version numbers: j@ /j> gdb python GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run Starting program: /usr/bin/python (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 1075566272 (LWP 15317)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Program received signal SIGABRT, Aborted. [Switching to Thread 1075566272 (LWP 15317)] 0xe410 in __kernel_vsyscall () (gdb) info threads * 1 Thread 1075566272 (LWP 15317) 0xe410 in __kernel_vsyscall () (gdb) thread apply all bt Thread 1 (Thread 1075566272 (LWP 15317)): #0 0xe410 in __kernel_vsyscall () #1 0x400a5df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x400a7641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x40741270 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #4 0x4073eca5 in ?? () from /usr/lib/libstdc++.so.6 #5 0x4073ece2 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0x4073ee1a in __cxa_throw () from /usr/lib/libstdc++.so.6 #7 0x404f4104 in gr_firdes::hilbert () from /usr/local/lib/libgnuradio-core.so.0 #8 0x40970440 in _wrap_firdes_hilbert () from /usr/local/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_general.so #9 0x0805c787 in PyObject_Call () #10 0x080c6c2f in PyEval_EvalFrameEx () #11 0x080c9ca5 in PyEval_EvalCodeEx () #12 0x080c8169 in PyEval_EvalFrameEx () #13 0x080c9ca5 in PyEval_EvalCodeEx () #14 0x080c9d17 in PyEval_EvalCode () #15 0x080e9803 in PyRun_InteractiveOneFlags () #16 0x080e9a36 in PyRun_InteractiveLoopFlags () ---Type to continue, or q to quit--- #17 0x080e9b52 in PyRun_AnyFileExFlags () #18 0x08059330 in Py_Main () #19 0x08058862 in main () ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Ubuntu 7.10, 32-bit (real, not VM), latest updates; SVN latest revision Intel core-2-duo @ 2 GHz (single board computer "commell LS-371") $ python Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Aborted (core dumped) $ gcc --version gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ swig -version SWIG Version 1.3.31 Compiled with g++ [i686-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information $ uname -a Linux p1 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
> *** Request For Help *** $ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Aborted $ g++ --version g++ (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ swig -version SWIG Version 1.3.31 Compiled with x86_64-redhat-linux-g++ [x86_64-redhat-linux-gnu] Please see http://www.swig.org for reporting bugs and further information $ uname -a Linux GR5T61 2.6.22.7-57.fc6 #1 SMP Fri Sep 21 19:45:12 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Using gnuradio r7456, Fedora core 6 64bit on a Intel Core 2 Duo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
On Thu, Jan 17, 2008 at 09:46:39PM +, Juha Vierinen wrote: > Hi, > > I get the same error. My system is Ubuntu Edgy, Intel Core 2 Duo, > Macbook pro, fairly old SVN build of gnuradio. Thanks. Can you get us $ g++ --version $ python -V $ swig -version Eric > j@ /gnuradio> svn info > Path: . > URL: http://gnuradio.org/svn/gnuradio/trunk > Repository Root: http://gnuradio.org/svn > Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5 > Revision: 6441 > Node Kind: directory > Schedule: normal > Last Changed Author: eb > Last Changed Rev: 6429 > Last Changed Date: 2007-09-13 23:21:41 + (Thu, 13 Sep 2007) > > > uname -a > Linux mcbook 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 > i686 GNU/Linux > > Here is the listing, which hopefully contains all the necessary version > numbers: > > j@ /j> gdb python > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > (no debugging symbols found) > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > (gdb) run > Starting program: /usr/bin/python > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > [New Thread 1075566272 (LWP 15317)] > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > >>> from gnuradio import gr > >>> gr.firdes.hilbert(0) > terminate called after throwing an instance of 'std::out_of_range' > what(): Hilbert: Must have odd number of taps > > Program received signal SIGABRT, Aborted. > [Switching to Thread 1075566272 (LWP 15317)] > 0xe410 in __kernel_vsyscall () > (gdb) info threads > * 1 Thread 1075566272 (LWP 15317) 0xe410 in __kernel_vsyscall () > (gdb) thread apply all bt > > Thread 1 (Thread 1075566272 (LWP 15317)): > #0 0xe410 in __kernel_vsyscall () > #1 0x400a5df0 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0x400a7641 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0x40741270 in __gnu_cxx::__verbose_terminate_handler () >from /usr/lib/libstdc++.so.6 > #4 0x4073eca5 in ?? () from /usr/lib/libstdc++.so.6 > #5 0x4073ece2 in std::terminate () from /usr/lib/libstdc++.so.6 > #6 0x4073ee1a in __cxa_throw () from /usr/lib/libstdc++.so.6 > #7 0x404f4104 in gr_firdes::hilbert () >from /usr/local/lib/libgnuradio-core.so.0 > #8 0x40970440 in _wrap_firdes_hilbert () >from > /usr/local/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_general.so > #9 0x0805c787 in PyObject_Call () > #10 0x080c6c2f in PyEval_EvalFrameEx () > #11 0x080c9ca5 in PyEval_EvalCodeEx () > #12 0x080c8169 in PyEval_EvalFrameEx () > #13 0x080c9ca5 in PyEval_EvalCodeEx () > #14 0x080c9d17 in PyEval_EvalCode () > #15 0x080e9803 in PyRun_InteractiveOneFlags () > #16 0x080e9a36 in PyRun_InteractiveLoopFlags () > ---Type to continue, or q to quit--- > #17 0x080e9b52 in PyRun_AnyFileExFlags () > #18 0x08059330 in Py_Main () > #19 0x08058862 in main () > > > ___ > 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] Information on ticket:181 and invitation to help (long)
SVN latest revision; MacOS X 10.4.11 latest updates; Intel-iMac 2.16 GHz core-2-duo: % python Python 2.5.1 (r251:54863, Jan 5 2008, 16:11:24) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/ gnuradio_swig_py_general.py", line 2837, in hilbert return _gnuradio_swig_py_general.firdes_hilbert(*args) IndexError: Hilbert: Must have odd number of taps >>> % g++ --version i686-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % swig -version SWIG Version 1.3.33 Compiled with /usr/bin/g++-4.0 [i386-apple-darwin8.11.1] Please see http://www.swig.org for reporting bugs and further information ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
On Thu, Jan 17, 2008 at 01:09:31PM -0800, Johnathan Corgan wrote: > As a follow up to the previous message regarding the segfault issue with > ticket:181, here is a simple test case that shows the problem. See the > end of this email for a request to help document which systems this > occurs on (you won't need to do all the below, or use gdb as shown; just > run a couple commands.) > Thanks Johnathan, for posting this. We really do need ALL your help in bisecting this. If you can run the simple experiment below, and in the previous message, please do and post the info to the list. We know it used to work, and now it doesn't. What we're looking for are cases where it works and those where it doesn't. Then for those cases, biscect by compiler version / python version / 32-bit vs 64-bit / gnuradio version. Once we know what triggers it, it shouldn't be too hard to fix. My gut sense is that it's not directly swig related. The code they generate looks OK. Eric > The problem in short: > > $ python > Python 2.5.1 (r251:54863, Oct 5 2007, 13:50:07) > [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> from gnuradio import gr > >>> gr.firdes.hilbert(0) > terminate called after throwing an instance of 'std::out_of_range' > what(): Hilbert: Must have odd number of taps > Aborted (core dumped) > $ > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Gnu Radio Companion (GRC) 0.69 experience
On Jan 17, 2008, at 2:04 PM, Josh Blum wrote:
Strange. I have been running GRC on ubuntu and never noticed this.
Flow graphs are run with os.system("./ExecFlowGraphGUI.py
myflowgraph.xml"). So the flow graph is running as a separate process.
The stop button in GRC calls a kill -9 on the pid of this process.
Perhaps this has something to do with the flowgraph begin executed
from the same shell as GRC.
May I ask what version of python 2.4, 2.5, 3?
Josh,
I tried grc on a Fedora Core 6 installation, Python 2.4, and see this
crash (sometimes, maybe even "usually") when the graph has been
edited. I don't think it ever crashed on a run where the graph hadn't
been changed.
Steve
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
SVN latest version, Ubuntu Gutsy with latest updates, Pentium 4 [EMAIL PROTECTED]:~$ python Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Aborted (core dumped) [EMAIL PROTECTED]:~$ g++ --version g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~$ swig -version SWIG Version 1.3.31 Compiled with g++ [i686-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
SVN latest version, Gutsy Gibbon, Core Duo L2400 (not core 2 duo) [EMAIL PROTECTED]:~/school/gr/trunk$ python Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Aborted (core dumped) [EMAIL PROTECTED]:~/school/gr/trunk$ g++ --version g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~/school/gr/trunk$ swig -version SWIG Version 1.3.31 Compiled with g++ [i686-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information Linux x60s 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
PS3: [EMAIL PROTECTED] ~]$ python Python 2.5 (r25:51908, Nov 6 2007, 15:58:37) [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Aborted [EMAIL PROTECTED] ~]$ g++ --version g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] ~]$ swig -version SWIG Version 1.3.31 Compiled with g++ [powerpc-redhat-linux-gnu] Please see http://www.swig.org for reporting bugs and further information [EMAIL PROTECTED] ~]$ uname -a Linux ps3.comsec.com 2.6.23 #1 SMP Mon Nov 12 17:32:16 PST 2007 ppc64 ppc64 ppc64 GNU/Linux [EMAIL PROTECTED] ~]$ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Juha Vierinen wrote: > And the "quick fix" suggested in the bug report also works: > http://sourceforge.net/tracker/index.php?func=detail&aid=1863647&group_id=1645&atid=101645 Great catch! I'm going to try a fix in which we automate this; this will at least workaround the problem until the swig guys make a fix. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
On Fri, Jan 18, 2008 at 01:04:38AM +0200, Juha Vierinen wrote: > This might be a similar problem: > > http://www.nabble.com/C%2B%2B,-Python-and-multiple-libraries-td14223763.html > > juha Thanks! It does look similar. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Juha Vierinen wrote: > This might be a similar problem: > > http://www.nabble.com/C%2B%2B,-Python-and-multiple-libraries-td14223763.html Thanks, we found that too. It does look similar. So far from all the reports (thanks guys, keep them coming), the works/fails distinction is whether gcc is < 4.1 or not. But we don't have enough "works" examples to really draw that conclusion yet. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Upgrading to SWIG 1.3.33 doesn't change this. Ubuntu 7.10, 32-bit (real, not VM), latest updates; SVN latest revision Intel core-2-duo @ 2 GHz (single board computer "commell LS-371") $ python Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Aborted (core dumped) $ gcc --version gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux p1 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
And the "quick fix" suggested in the bug report also works: http://sourceforge.net/tracker/index.php?func=detail&aid=1863647&group_id=1645&atid=101645 j@ /swigp> python Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, dl >>> sys.setdlopenflags(sys.getdlopenflags() | dl.RTLD_GLOBAL) >>> from gnuradio import gr >>> gr.firdes.hilbert(0) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_general.py", line 2837, in hilbert return _gnuradio_swig_py_general.firdes_hilbert(*args) IndexError: Hilbert: Must have odd number of taps >>> On Jan 18, 2008 1:13 AM, Eric Blossom <[EMAIL PROTECTED]> wrote: > On Fri, Jan 18, 2008 at 01:04:38AM +0200, Juha Vierinen wrote: > > This might be a similar problem: > > > > http://www.nabble.com/C%2B%2B,-Python-and-multiple-libraries-td14223763.html > > > > juha > > Thanks! It does look similar. > > Eric > > > > ___ > 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] Information on ticket:181 and invitation to help (long)
> Thanks. Can you get us > > $ g++ --version > $ python -V > $ swig -version j@ /j> g++ --version g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. j@ /j> python -V Python 2.5.1 j@ /j> swig -version SWIG Version 1.3.31 Compiled with g++ [i686-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information > > Eric > > > > > j@ /gnuradio> svn info > > Path: . > > URL: http://gnuradio.org/svn/gnuradio/trunk > > Repository Root: http://gnuradio.org/svn > > Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5 > > Revision: 6441 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: eb > > Last Changed Rev: 6429 > > Last Changed Date: 2007-09-13 23:21:41 + (Thu, 13 Sep 2007) > > > > > uname -a > > Linux mcbook 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 > > i686 GNU/Linux > > > > Here is the listing, which hopefully contains all the necessary version > > numbers: > > > > j@ /j> gdb python > > GNU gdb 6.6-debian > > Copyright (C) 2006 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i486-linux-gnu"... > > (no debugging symbols found) > > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (gdb) run > > Starting program: /usr/bin/python > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > [Thread debugging using libthread_db enabled] > > [New Thread 1075566272 (LWP 15317)] > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) > > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > >>> from gnuradio import gr > > >>> gr.firdes.hilbert(0) > > terminate called after throwing an instance of 'std::out_of_range' > > what(): Hilbert: Must have odd number of taps > > > > Program received signal SIGABRT, Aborted. > > [Switching to Thread 1075566272 (LWP 15317)] > > 0xe410 in __kernel_vsyscall () > > (gdb) info threads > > * 1 Thread 1075566272 (LWP 15317) 0xe410 in __kernel_vsyscall () > > (gdb) thread apply all bt > > > > Thread 1 (Thread 1075566272 (LWP 15317)): > > #0 0xe410 in __kernel_vsyscall () > > #1 0x400a5df0 in raise () from /lib/tls/i686/cmov/libc.so.6 > > #2 0x400a7641 in abort () from /lib/tls/i686/cmov/libc.so.6 > > #3 0x40741270 in __gnu_cxx::__verbose_terminate_handler () > >from /usr/lib/libstdc++.so.6 > > #4 0x4073eca5 in ?? () from /usr/lib/libstdc++.so.6 > > #5 0x4073ece2 in std::terminate () from /usr/lib/libstdc++.so.6 > > #6 0x4073ee1a in __cxa_throw () from /usr/lib/libstdc++.so.6 > > #7 0x404f4104 in gr_firdes::hilbert () > >from /usr/local/lib/libgnuradio-core.so.0 > > #8 0x40970440 in _wrap_firdes_hilbert () > >from > > /usr/local/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_general.so > > #9 0x0805c787 in PyObject_Call () > > #10 0x080c6c2f in PyEval_EvalFrameEx () > > #11 0x080c9ca5 in PyEval_EvalCodeEx () > > #12 0x080c8169 in PyEval_EvalFrameEx () > > #13 0x080c9ca5 in PyEval_EvalCodeEx () > > #14 0x080c9d17 in PyEval_EvalCode () > > #15 0x080e9803 in PyRun_InteractiveOneFlags () > > #16 0x080e9a36 in PyRun_InteractiveLoopFlags () > > ---Type to continue, or q to quit--- > > #17 0x080e9b52 in PyRun_AnyFileExFlags () > > #18 0x08059330 in Py_Main () > > #19 0x08058862 in main () > > > > > > > ___ > > 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Gnu Radio Companion (GRC) 0.69 experience
On Jan 17, 2008, at 3:35 PM, Steve Bunch wrote: I tried grc on a Fedora Core 6 installation, Python 2.4, and see this crash (sometimes, maybe even "usually") when the graph has been edited. I don't think it ever crashed on a run where the graph hadn't been changed. Josh, Followup: retrying grc on Fedora 8 (Python 2.5), Core 2 quad, 32-bit, recent installation of GNURadio 3.1svn, grc from svn current, I have no crashes observed in dozens of edits and reruns of a previously- often-failing graph. Steve ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
This might be a similar problem: http://www.nabble.com/C%2B%2B,-Python-and-multiple-libraries-td14223763.html juha On Jan 18, 2008 12:55 AM, Juha Vierinen <[EMAIL PROTECTED]> wrote: > > Thanks. Can you get us > > > > $ g++ --version > > $ python -V > > $ swig -version > > j@ /j> g++ --version > g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > j@ /j> python -V > Python 2.5.1 > j@ /j> swig -version > > SWIG Version 1.3.31 > > Compiled with g++ [i686-pc-linux-gnu] > Please see http://www.swig.org for reporting bugs and further information > > > > > > Eric > > > > > > > > > j@ /gnuradio> svn info > > > Path: . > > > URL: http://gnuradio.org/svn/gnuradio/trunk > > > Repository Root: http://gnuradio.org/svn > > > Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5 > > > Revision: 6441 > > > Node Kind: directory > > > Schedule: normal > > > Last Changed Author: eb > > > Last Changed Rev: 6429 > > > Last Changed Date: 2007-09-13 23:21:41 + (Thu, 13 Sep 2007) > > > > > > > uname -a > > > Linux mcbook 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 > > > i686 GNU/Linux > > > > > > Here is the listing, which hopefully contains all the necessary version > > > numbers: > > > > > > j@ /j> gdb python > > > GNU gdb 6.6-debian > > > Copyright (C) 2006 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and you > > > are > > > welcome to change it and/or distribute copies of it under certain > > > conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > details. > > > This GDB was configured as "i486-linux-gnu"... > > > (no debugging symbols found) > > > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > > (gdb) run > > > Starting program: /usr/bin/python > > > (no debugging symbols found) > > > (no debugging symbols found) > > > (no debugging symbols found) > > > [Thread debugging using libthread_db enabled] > > > [New Thread 1075566272 (LWP 15317)] > > > (no debugging symbols found) > > > (no debugging symbols found) > > > (no debugging symbols found) > > > (no debugging symbols found) > > > Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) > > > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > > > Type "help", "copyright", "credits" or "license" for more information. > > > (no debugging symbols found) > > > (no debugging symbols found) > > > (no debugging symbols found) > > > (no debugging symbols found) > > > >>> from gnuradio import gr > > > >>> gr.firdes.hilbert(0) > > > terminate called after throwing an instance of 'std::out_of_range' > > > what(): Hilbert: Must have odd number of taps > > > > > > Program received signal SIGABRT, Aborted. > > > [Switching to Thread 1075566272 (LWP 15317)] > > > 0xe410 in __kernel_vsyscall () > > > (gdb) info threads > > > * 1 Thread 1075566272 (LWP 15317) 0xe410 in __kernel_vsyscall () > > > (gdb) thread apply all bt > > > > > > Thread 1 (Thread 1075566272 (LWP 15317)): > > > #0 0xe410 in __kernel_vsyscall () > > > #1 0x400a5df0 in raise () from /lib/tls/i686/cmov/libc.so.6 > > > #2 0x400a7641 in abort () from /lib/tls/i686/cmov/libc.so.6 > > > #3 0x40741270 in __gnu_cxx::__verbose_terminate_handler () > > >from /usr/lib/libstdc++.so.6 > > > #4 0x4073eca5 in ?? () from /usr/lib/libstdc++.so.6 > > > #5 0x4073ece2 in std::terminate () from /usr/lib/libstdc++.so.6 > > > #6 0x4073ee1a in __cxa_throw () from /usr/lib/libstdc++.so.6 > > > #7 0x404f4104 in gr_firdes::hilbert () > > >from /usr/local/lib/libgnuradio-core.so.0 > > > #8 0x40970440 in _wrap_firdes_hilbert () > > >from > > > /usr/local/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_general.so > > > #9 0x0805c787 in PyObject_Call () > > > #10 0x080c6c2f in PyEval_EvalFrameEx () > > > #11 0x080c9ca5 in PyEval_EvalCodeEx () > > > #12 0x080c8169 in PyEval_EvalFrameEx () > > > #13 0x080c9ca5 in PyEval_EvalCodeEx () > > > #14 0x080c9d17 in PyEval_EvalCode () > > > #15 0x080e9803 in PyRun_InteractiveOneFlags () > > > #16 0x080e9a36 in PyRun_InteractiveLoopFlags () > > > ---Type to continue, or q to quit--- > > > #17 0x080e9b52 in PyRun_AnyFileExFlags () > > > #18 0x08059330 in Py_Main () > > > #19 0x08058862 in main () > > > > > > > > > > > ___ > > > 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 mailing list Discuss-gnuradio@gnu.org http://li
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Johnathan Corgan wrote: > I'm going to try a fix in which we automate this; this will at least > workaround the problem until the swig guys make a fix. Trunk revision r7461 now contains an automated version of the workaround, which has stopped the problem in my development version. In particular, however, there could be some unwanted side effects. This workaround is to a single .py file, so once you update you can just re-run 'sudo make install' to get it into place. That is, unless you updated from an old enough version of the trunk that it includes non-Python updates, and then of course you'll have to rebuild. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Working on my P4 and Core Duo now! - George Johnathan Corgan wrote: Johnathan Corgan wrote: I'm going to try a fix in which we automate this; this will at least workaround the problem until the swig guys make a fix. Trunk revision r7461 now contains an automated version of the workaround, which has stopped the problem in my development version. In particular, however, there could be some unwanted side effects. This workaround is to a single .py file, so once you update you can just re-run 'sudo make install' to get it into place. That is, unless you updated from an old enough version of the trunk that it includes non-Python updates, and then of course you'll have to rebuild. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need info for paper.
George Nychis schrieb: Hi John, There are a couple other SDR-type platforms in the academic world... but none really come close to the code base of GR IMO. Some of these seemed pretty 'expensive' to get into... the use of ASICs, and the like, also, they seem to be directed to pretty specific implementations of transmissions, even though one could conceivably load in a new chunk of firmware 'on the fly' perhaps... WARP is a very expensive platform IMO, and they are not as modular as GNU Radio. I would say GNU Radio has far more in the PHY layer, and WARP has 1 PHY (OFDM) + a bunch of MAC implementations. Looked interesting, but did have this overhead of ASIC, and buying the attendant boards. The KU Agile radio is still pretty new, Prof. Minden gave a talk here about it last semester and it seemed the hardware was pretty concrete but the software was still in progress... which is what truly separates SDR platforms :) Looks closest to what I'm doing... albeit not with a PPC core... CalRadio v1 is strict 802.11 based, and the PHY is not flexible. I think their goal was to keep the PHY in hardware and swap out daughterboards with different PHYs that you could re-program the MAC on. Almost instant negative... I have my Master from UCSD, the consolation prize for those who didn't get a PhD... and further... have not forgotten the nonsense with UCSD Pascal and the Regents... but I digress... John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need info for paper.
John Clark wrote:
> I'm co-writing a paper on the use of GNU Radio. Because I'm inclined to
> use 'Open Source' solutions,
> GNU Radio and the attendant DSP library, was for me about the only
> choice I would have made...
> However, in the paper I'd like to at least make some attempt at
> indicating any 'alternatives', if there
> are any in the Open Source arena, or parish the thought, cost-money type
> packages.
High Performance Software Defined Radio (opensource)
An Open Source Design
The HPSDR is an open source (GNU type) hardware and software project intended
as a "next generation" Software Defined Radio (SDR) for use by
Radio Amateurs ("hams") and Short Wave Listeners (SWLs).
http://hpsdr.org
http://pcovington.blogspot.com/
There are GnuRadio developers which are in contact with or collaborate with
people of HPSDR.
They use some of the verilog sourcecode of the USRP for their FPGA in their
boards.
Gstreamer Quadrature library (opensource):
libgstiq is a library with Gstreamer plugins for use in software defined
radios.
http://sharon.esrac.ele.tue.nl/users/pe1rxq/libgstiq/index.html
libDSP (opensource)
libDSP is a C/C++ library of digital signal processing routines, including
standard vector operations, digital filtering, and transforms.
http://sourceforge.net/projects/libdsp/
flex-radio (commercial)
Company building software defined radio frontends (SDR-1000) for use through
the soundcard of a PC for the IF.
Aimed at Radio-amateurs
http://www.flex-radio.com/
Comblock (commercial)
Hardware oriented commercial company delivering blocks to build SDR systems
ComBlock modules are small commercial off-the-shelf modules which are
pre-programmed with essential communication processing functions,
including modulation, demodulation, error correction encoding and decoding,
digital to analog/RF, RF/analog to digital, formatting, data storage
and baseband interfaces.
http://www.comblock.com
ARRL page about software defined Radio projects:
http://www.arrl.org/tis/info/sdr.html
>
> If anyone has done a more detailed evaluation and perhaps has a chart
> depicting features, that would be
> good.
>
> Also, a while ago, I saw someone who had put together a 'graphical'
> interface, where one could construct
> a DSP processor using graphical means, and setting various parameters
> using a GUI. I have not had the
> time to really keep up on that sort of thing, but if there is someone
> who has something that works, I'd also
> like to know about that.
Thu GnuRadio GUI you are referring to is called GRC, written by Josh Blum
Download: http://www.joshknows.com/download/grc/
Wiki: http://gnuradio.org/trac/wiki/GNURadioCompanion
>
> For those who have information, and send me a release, credit will be
> made in the paper for their contribution.
If you need any other kind of info, please let me know.
I have done some presentations on GnuRadio and Software Defined Radio and I am
preparing for some GnuRadio courses that I will be giving.
It would be appreciated if you made the paper public and available somewhere on
the web.
Greetings,
Martin
>
> Thanks,
> John Clark.
>
>
>
>
> ___
> 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] Re: Gnu Radio Companion (GRC) 0.69 experience
On Friday 18 January 2008 09:20:55 Steve Bunch wrote:
> On Jan 17, 2008, at 3:35 PM, Steve Bunch wrote:
> > I tried grc on a Fedora Core 6 installation, Python 2.4, and see
> > this crash (sometimes, maybe even "usually") when the graph has been
> > edited. I don't think it ever crashed on a run where the graph
> > hadn't been changed.
>
> Josh,
>
> Followup: retrying grc on Fedora 8 (Python 2.5), Core 2 quad, 32-bit,
> recent installation of GNURadio 3.1svn, grc from svn current, I have
> no crashes observed in dozens of edits and reruns of a previously-
> often-failing graph.
>
G'day,
I've rebuilt and installed GNU Radio svn-7461 as of today on a system running
python-2.4.4 and swig-1.3.31. It still crashes when started and stopped a few
times, three times in this particular case, with message shown below. This
was using example noisy_sinusoid.grc.xml application provided by the GRC
package. This is reproducable at will. Note the "TypeError: 'str' object is
not callable" and the message just prior to the coredump.
barossa: {18} ./Editor.py ../examples/noisy_sinusoid.grc.xml
No module named serial in RS232 Source! -> continuing...
No module named serial in RS232 Sink! -> continuing...
Removing empty category "Custom"...
<<< Welcome to GRC 0.69 >>>
Loading: "../examples/noisy_sinusoid.grc.xml"
>>> Done
Showing: "/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml"
Executing: "/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml"
No module named serial in RS232 Source! -> continuing...
No module named serial in RS232 Sink! -> continuing...
Removing empty category "Custom"...
>>> Verbose:
Traceback (most recent call last):
File "/home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py", line 248,
in ?
exit(0)
TypeError: 'str' object is not callable
>>> Done
Executing: "/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml"
No module named serial in RS232 Source! -> continuing...
No module named serial in RS232 Sink! -> continuing...
Removing empty category "Custom"...
>>> Verbose:
Traceback (most recent call last):
File "/home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py", line 248,
in ?
exit(0)
TypeError: 'str' object is not callable
>>> Done
Executing: "/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml"
No module named serial in RS232 Source! -> continuing...
No module named serial in RS232 Sink! -> continuing...
Removing empty category "Custom"...
>>> Verbose:
Traceback (most recent call last):
File "/home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py", line 248,
in ?
exit(0)
TypeError: 'str' object is not callable
/home/wulf/projects/gnuradio/grc/src/ActionHandler.py:68: GtkWarning: Invalid
text buffer iterator: either the iterator is uninitialized, or the
characters/pixbufs/widgets in the buffer have been modified since the
iterator was created.
You must use marks, character numbers, or line numbers to preserve a position
across buffer modifications.
You can apply tags and insert marks without invalidating your iterators,
but any mutation that affects 'indexable' buffer contents (contents that can
be referred to by character offset)
will invalidate all outstanding iterators
gtk.main()
Segmentation fault (core dumped)
barossa: {19}
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
