[Discuss-gnuradio] implementing features directly in python
Hi, I would like to add some features ( say a function foo() ) in gr-trellis that is not implemented in c++ but directly in python. So in my programs when I do from gnuradio import trellis I would like to have access to trellis.foo() how do I do that? in particular, where should the python file reside and how should I change the Makefile.am file? is there an example of this in gnuradio? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] matlab/octave sample stream, 8 bit samples FEEDBACK
thanks Eric, thanks Lee. octave import function worked straightforward, and was actually very useful. I still have some doubts about the 8bit samples. I have tried the usrp_fft.py, but when I do require 8bit samples through the provided command line option, the fft sink displays nothing at all, even if the applications seems to be running all right. the same happens when I import the python code for 8bit conversion into my scripts. any hint? vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problem with RFX1800: No class defined to handle daughterboard
I have an USRP rev4 and tried to use the RFX1800 tranceiver with the usrp_oscope.py example program under Ubuntu on a PC. My CVS / SVN checkout is two or three days old. I own a RFX2400 tranceiver, too. The RFX2400 works out of the box, but if I plug the RFX1800 on the USRP I only get this error message: No class definded to handle daughterboard I had a similar problem with a TVRX board. Near that error, there should be something like (dbid=??). Mine showed 64, which is not in the list of ID #s at usrp/host/lib/usrp_dbid.py. I had to use usrp/host/apps/burn-db-eeprom TV_RX. After that it worked fine. Good luck! John __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Problem with RFX1800: No class defined to handle daughterboard
On Wed, Aug 09, 2006 at 09:34:49AM -0700, John Bratteli wrote: I have an USRP rev4 and tried to use the RFX1800 tranceiver with the usrp_oscope.py example program under Ubuntu on a PC. My CVS / SVN checkout is two or three days old. Please note that CVS/SVN is not longer the latest code. We've moved to an integrated Trac + SVN repository. [I'll delete the old CVS repo real soon now] For the lastest code: $ svn co http://gnuradio.utah.edu/svn/gnuradio/trunk gnuradio See also http://gnuradio.utah.edu/trac/wiki Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB throughput numbers for NetBSD (and Linux)
Hi, sorry for my long delay, I was on vacation and then playing catch-up. I'm not sure I followed the explanation for why on NetBSD the unidirectional case isn't equal to the sum of the bidirectional case. Could you try explaining again? On second thought, is the problem that there's only one request in the h/w endpoint queue for a given endpoint and direction? If so, I think you could get the completion interrupt service time out of the critical path by ensuring that there are always two requests queued in each direction, not just one. Yes, as the driver is currently implemented, there is only one request queued for a given endpoint at a time. You're correct that having more than one would reduce the interrupt service time's effect on performance, but doing this will require changes to more than just ugen. The ehci driver will need some work in order to work properly with more than one bulk request queued at a time. We haven't changed the ehci driver, so until that happens, the ugen driver will have to use just a single request at a time. I'd also be interested in seeing how the throughput holds up with smaller transfer sizes and smaller total amount of buffer space. Because we only have one request at a time, the throughput will suffer as request sizes get smaller. In my experience the total buffer space need not be more than a few requests' worth (and the numbers showed that having the buffers too large hurts performance), but this testing wasn't with much computation load. At least the latency should still be improved over what we had with ugen before. Using test_usrp_standard_rx and _tx, a block size of 1024 only works with decimation 64/interpolation 128 (4 MB/s) and a block size of 4096 works with decimation 16/interpolation 32 (16 MB/s). This is without real-time scheduling, which isn't working. Joanne ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build failing from trunk
I grabbed the latest trunk via svn, and attempted a build. ecc.cc appears to be causing the build to fail: ecc.cc:5875: error: conversion from 'int' to non-scalar type 'std::vectorint, std::allocatorint ' requested ecc.cc:5967: error: conversion from 'int' to non-scalar type 'std::vectorint, std::allocatorint ' requested Should I exclude the error-correction stuff from the build for now, or what? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failing from trunk
Try make -k. At least, compilation will not stop after the first failure.On 8/9/06, Marcus Leech [EMAIL PROTECTED] wrote:I grabbed the latest trunk via svn, and attempted a build. ecc.cc appears to be causing the build to fail:ecc.cc:5875: error: conversion from 'int' to non-scalar type'std::vectorint, std::allocatorint ' requestedecc.cc:5967: error: conversion from 'int' to non-scalar type 'std::vectorint, std::allocatorint ' requestedShould I exclude the error-correction stuff from the build for now, or what?___Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttp://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 failing from trunk
On Wed, August 9, 2006 13:22, Pascal Charest wrote: Try make -k. At least, compilation will not stop after the first failure. Correct, though it will fail install. You can edit configure.ac and comment out the line near the bottom that is GRC_GR_ERROR_CORRECTING_CODES ...which will exclude that component from every make target. Please file a bug and include your system configuration (compiler, autotools versions, OS, cpu. To file a bug from Trac go to: http://gnuradio.utah.edu/trac Log in as 'guest' with password 'gnuradio', then select New Ticket. (If you have a developer account use that name instead of guest). -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failing from trunk
I just got back from a vacation w/o internet, am playing catch-up, and haven't had time yet to update the (new to me) SVN for ecc. While the ecc stuff is a work-in-progress, it's supposed to compile correctly. I will work tonight to get all my updated programming into SVN, as well as see if I can figure out what the issue you found is. - MLD On Aug 9, 2006, at 4:14 PM, Marcus Leech wrote: I grabbed the latest trunk via svn, and attempted a build. ecc.cc appears to be causing the build to fail: ecc.cc:5875: error: conversion from 'int' to non-scalar type 'std::vectorint, std::allocatorint ' requested ecc.cc:5967: error: conversion from 'int' to non-scalar type 'std::vectorint, std::allocatorint ' requested Should I exclude the error-correction stuff from the build for now, or what? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failing from trunk
Johnathan Corgan wrote: To file a bug from Trac go to: http://gnuradio.utah.edu/trac Log in as 'guest' with password 'gnuradio', then select New Ticket. (If you have a developer account use that name instead of guest). -Johnathan Ok, so call me as dopey as a psychotic on lithium, but I can't see any New Ticket item anywhere on the page you referred me to, even after logging in (successfully) with my developer ID. I'm using Firefox 1.5.0.4, if that matters... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fsk_tx.py - transmission frequency
I'm looking at the following code:http://www.koders.com/python/fidA197012A520F0CE96AE6C6A41D559B9E2A5A8D63.aspxand if you look at line 72, you'll see: u.set_tx_freq(0, options.cordic_freq)However, when I look to see what that cordic_freq is, I see that the default is 29.32e6 (Line 19). I thought that the 2400 was supposed to communicate from 2.3-2.9 GHz. The comment for set_tx_freq() in usrp_standard.h says that the frequency argument for set_tx_freq() has to be set from [-44M, 44M]. Even more confusing is that when I tune the receiving USRP board to 2.4GHz, I get a high reading. How can I determine what center frequency the transmitting board is actually communicating at? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failing from trunk
Marcus Leech wrote: Ok, so call me as dopey as a psychotic on lithium, but I can't see any New Ticket item anywhere on the page you referred me to, even after logging in (successfully) with my developer ID. No, I'm the dopey one (hey, Lithium is not so bad once you get used to it :-) Try it again; I had forgotten to give you developer rights on Trac. I'm assuming your login is mleech; let me know if it's different as I'm on the road and can't ssh into the server right now. Worst case you can login as guest and do it until me or Eric straightens it out. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failing from trunk
Michael Dickens wrote: I just got back from a vacation w/o internet, am playing catch-up, and haven't had time yet to update the (new to me) SVN for ecc. While the ecc stuff is a work-in-progress, it's supposed to compile correctly. I will work tonight to get all my updated programming into SVN, as well as see if I can figure out what the issue you found is. - MLD The svn repository is current with CVS HEAD. Please see Eric about subversion commit access. Also, please create a developer branch in the tree: svn mkdir http://gnuradio.utah.edu/svn/gnuradio/branches/developers/mdickens svn cp http://gnuradio.utah.edu/svn/gnuradio/trunk http://gnuradio.utah.edu/svn/gnuradio/branches/developers/mdickens/wip (all on one line.) Then you can check out the developer branch: svn co http://gnuradio.utah.edu/svn/gnuradio/branches/developers/mdickens/wip gnuradio cd gnuradio You can fiddle to your hearts content here and check-in intermediate work in progress. Once 'make distcheck' passes successfully, you can merge your changes into the trunk. I'll walk you through that when you're ready. By using developer branches for intermediate work we keep the trunk in good shape for non-developers to check out from. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fsk_tx.py - transmission frequency
On Wed, Aug 09, 2006 at 04:30:50PM -0500, Michael Ford wrote: I'm looking at the following code: http://www.koders.com/python/fidA197012A520F0CE96AE6C6A41D559B9E2A5A8D63.aspx and if you look at line 72, you'll see: u.set_tx_freq(0, options.cordic_freq) However, when I look to see what that cordic_freq is, I see that the default is 29.32e6 (Line 19). I thought that the 2400 was supposed to communicate from 2.3-2.9 GHz. The comment for set_tx_freq() in usrp_standard.h says that the frequency argument for set_tx_freq() has to be set from [-44M, 44M]. Even more confusing is that when I tune the receiving USRP board to 2.4GHz, I get a high reading. How can I determine what center frequency the transmitting board is actually communicating at? Michael, please try using the current code. There's a reason that fsk_tx.py is not in the current code base, and hasn't been for the past year. If you want an example of transmit code that works with any daughterboard, please take a look (in the current svn code -- http://gnuradio.utah.edu/trac -- for directions) usrp-examples/python/usrp/fm_tx4.py Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failing from trunk
On Wed, Aug 09, 2006 at 02:45:23PM -0700, Johnathan Corgan wrote: Marcus Leech wrote: Ok, so call me as dopey as a psychotic on lithium, but I can't see any New Ticket item anywhere on the page you referred me to, even after logging in (successfully) with my developer ID. No, I'm the dopey one (hey, Lithium is not so bad once you get used to it :-) Try it again; I had forgotten to give you developer rights on Trac. I'm assuming your login is mleech; let me know if it's different as I'm on the road and can't ssh into the server right now. Worst case you can login as guest and do it until me or Eric straightens it out. -Johnathan Sorry about that Marcus. I didn't realize that I had an extra step to perform. Johnathan, can you put together a checklist for adding a developer? I did run htdigest in both directories, but clearly didn't even think about the Trac perms. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fsk_tx.py - transmission frequency
Eric,My apologies - I didn't know it wasn't available anymore, but the file was there when I checked out the code from the CVS server earlier this summer. The site I posted was just for easy reference. On 8/9/06, Eric Blossom [EMAIL PROTECTED] wrote: On Wed, Aug 09, 2006 at 04:30:50PM -0500, Michael Ford wrote: I'm looking at the following code: http://www.koders.com/python/fidA197012A520F0CE96AE6C6A41D559B9E2A5A8D63.aspx and if you look at line 72, you'll see: u.set_tx_freq(0, options.cordic_freq) However, when I look to see what that cordic_freq is, I see that the default is 29.32e6 (Line 19). I thought that the 2400 was supposed to communicate from 2.3-2.9 GHz. The comment for set_tx_freq() in usrp_standard.h says that the frequency argument for set_tx_freq() has to be set from [-44M, 44M]. Even more confusing is that when I tune the receiving USRP board to 2.4GHz, I get a high reading. How can I determine what center frequency the transmitting board is actually communicating at? Michael, please try using the current code.There's a reason thatfsk_tx.py is not in the current code base, and hasn't been for thepast year.If you want an example of transmit code that works with any daughterboard, please take a look (in the current svn code --http://gnuradio.utah.edu/trac -- for directions)usrp-examples/python/usrp/fm_tx4.pyEric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
