Re: [Discuss-gnuradio] Make db_base::_refclk_divisor pure virtual?
On Sun, Jul 11, 2010 at 1:38 AM, Jason Abele wrote: > Unfortunately, I am not a good person to ask about this, my name > appears on that line solely because I fixed a typo in the error > message that had made tracking down a problem in my code more > difficult. Can I ask what the problem was? > I would guess that either Eric or Johnathan have more insight into the > design decisions on the USRP daughterboard api than I can offer. Actually, I realized that the db_base::*refclk* functions are only used by some of the daughterboards, so it makes sense to only define _refclk_divisor for some dbs. The error messages might be more helpful as something like "Daughterboard must define _reflck_divisor() to use db_base::*refclk*()", though. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Make db_base::_refclk_divisor pure virtual?
Hi, This question is addressed mostly to Jason Abele since I see he's been working on this code recently. db_base::_refclk_divisor currently throws a runtime_error when it is called in the base class (not overridden by the daughterboard class). How do you feel about making this method a pure virtual method? This is the usual C++ idiom for specifying that a method must be overridden by the subclass, and is enforced at compile time. I've attached a patch but I wanted to run it by you in case there was another reason this was done using runtime_error. Thanks, Catalin 0001-Enforce-at-compile-time-that-db_base-_refclk_diviso.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio with alternate python
On Sat, Jun 26, 2010 at 10:29 PM, Josh Blum wrote: > Somehow distutils solves this problem: > http://docs.python.org/release/2.5.2/dist/node11.html > If you figure out what its calling, perhaps we could port that the > gnuradio build system The code that does this can be seen here: http://svn.python.org/view/python/trunk/Lib/distutils/command/build_scripts.py?revision=77704&view=markup They use the following regexp: ^#!.*python[0-9.]*([ \t].*)?$ This handles both things like /usr/bin/env python and /usr/local/bin/python, which is nice in the general case but not particularly relevant for GR. They also restrict the match to the first line of the file, which I think is prudent. One thing about the @@PYTHON@@ option is it would make the scripts no longer executable directly from the tree. Arguably you could still execute them using "python
Re: [Discuss-gnuradio] Interfacing Spartan-3AN FPGA starter kit with BasicRX
On Wed, Jun 16, 2010 at 11:15 PM, Elvis Dowson wrote: > Would this onboard ADC be sufficient to implement an FM Radio receiver with > GNU Radio? Can you clarify, by "FM Radio" do you mean broadcast FM (87.5-108 MHz)? In terms of bandwidth, 3Msps sounds sufficient, but you'll have to implement an FPGA design which communicates with GNU Radio. Instead of starting from scratch, you can try to start from the USRP2 sources (http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2) and apply modifications for your particular board. To get an idea of what this is like, you can look at similar changes we made to USRP1. There are two repos (FPGA and GNU Radio) hosted at http://git.thinkrf.com/, look at branches ending in "wsa". It's a bit of a mess at the moment, but I'd be happy to answer any questions. Catalin .:..thinkRF.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ltmain.sh in 3.3.0 tarball?
On Fri, Jun 11, 2010 at 3:36 PM, Eric Blossom wrote: > If you unpack the tarball (and don't modify anything), run configure, then > make, it should work. Yes, you're right. The problem was that I was also running autoreconf, which I guess creates a mixed-version libtool environment in the tree. > If you modify anything you'll need a consistent set of autotools. The reason for all this is I need to make changes in a *.am file. Is there a way to un-bootstrap a tarball? Just doing ./bootstrap causes the same mismatched libtool version problem. The only solution I've found so far is to remove ltmain.sh from the tree, then bootstrap, which feels kind of hackish. Thanks, Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ltmain.sh in 3.3.0 tarball?
Hi, I'm wondering if ltmain.sh really is supposed to be distributed in the release tarballs.. Commit 81133f7b (http://gnuradio.org/cgit/gnuradio.git/commit/?id=81133f7b37ba2cc1df65dc5704542fa758f32f23) seems to indicate otherwise. I stumbled on this because the combination of very old system libtool (1.5.22) and tarball ltmain.sh (2.2.6b) causes build errors at the beginning of "make". Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Git commit for 3.2.2 release?
On Fri, May 21, 2010 at 5:44 PM, Thomas Tsou wrote: > That could work. In either case, unless you're generating patches > against tarball or repo only code sections, patches should apply to > both version. Indeed! I'm working off rev eefb51c0c0fac68d16544e492aebd883528607e1 and my patch applies just fine against 3.2.2. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Testbench Question
On Mon, May 17, 2010 at 12:00 PM, wrote:
> Date: Sun, 16 May 2010 10:20:51 -0700 (PDT)
> From: D V
> Subject: [Discuss-gnuradio] USRP1 Testbench Question
> To: discuss-gnuradio@gnu.org
> Message-ID: <683009.51945...@web114517.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> [...]
> I made a (hilariously naive) attempt at writing my own testbench using
> Xilinx's ISim, associated with usrp_std, linking 64 Mhz and 48 Mhz clocks to
> master_clk and usbclk, respectively, inputting a square wave on the rx_a_a
> bus, and holding usbctl lines OE and RD high. When I do all this, the usbdata
> bus goes from 16'Z to 16'0, when RD and OE are
> enabled, but that's about it. I would imagine that there are all sorts of
> other registers that I would need to send commands to, maybe over the SDI/SDO
> or io_rx lines, to get a response from the FPGA firmware, but after looking
> at the FAQs I'm not quite sure where to start. I've included this testbench
> code below, if anybody would care to comment on what else is needed to
> initialize USRP1; or if someone could tell me where I could find a detailed
> discussion on writing a testbench for usrp_std that's already online, I would
> be very grateful.
Hi Bardus,
I think I can offer some insights into this porting process as ThinkRF
has done this for a Spartan 3E. Know however that I have not done any
work on the testbenches. The ported design does work though :)
First off, it's good to keep in mind that there are two clock domains
in this design. The digital downconverter (DDC) runs in the ADC clock
domain, SPI runs in the USB domain.
Some clock configurations on the 1600E lead to some sort of
interference which basically butchers your clocks. If in doubt about
your clocks, feed them to a single toggle flip-flop and check with a
scope that your output is nice and clean. (Feeding the clock directly
to an I/O leads to the usage of regular lines instead of the
"low-skew" dedicated clock lines. I've only observed strange behaviour
on these dedicated clock lines.)
Next up: SPI. Most likely the reason you weren't seeing anything on
usbdata is the DDC was unconfigured. This is indeed done through SPI
(usbdata is used only for data, no control). Check that your SPI is
working by reading register 4, which should be hardcoded to a constant
in your top module. You will become intimately familiar with
usrp_prims during this part of the process. At a higher level, actual
DDC configuration is done by
usrp/host/lib/{usrp_basic,usrp_standard}.cc.
Moving data from the FPGA's FIFO to the Cypress FX2's FIFO is done by
an FX2 peripheral called the GPIF (General-Purpose InterFace). It's
basically a glorified programmable state machine which handles flow
control on the FX2<->FPGA bus. It's badly documented and the tool
Cypress provides for configuring it sucks, but hopefully it "just
works" for you with what's already in the repo.
Other than that, expect little hiccups along the way.. I found it not
too hard to understand at a high level but once you drill down there
are lots of things that can go wrong. A few LEDs and a header where
you can route FPGA internal signals are indispensable.
Good luck!
Catalin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Git commit for 3.2.2 release?
On Fri, May 21, 2010 at 2:01 PM, Thomas Tsou wrote: > http://github.com/ttsou/gnuradio-ttsou/tree/releases/3.2 The best I've been able to find in there is 24d0fd9: http://github.com/ttsou/gnuradio-ttsou/commit/24d0fd908510846254f7317d353506c41daf079c This seems to have only SVN keywords-related diffs in common files, but there are a slew of files that are in one and not the other (the commit's tree vs 3.2.2 tarball). I think my best bet at the moment is to import a 3.2.2 tarball into my git repo and rebase on top of that? The reason we're stuck with 3.2.2 is that there's already an SRPM out there where we can add our changes as a distro-level patch. > The problem with this approach - or any method dependent on old, > divergent branches - is that there will almost surely be conflicts if > you plan on merging upstream. I can't wait for the 3.3 release! :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Git commit for 3.2.2 release?
Hi, I'm trying to create a patch that applies cleanly onto a 3.2.2 tarball. I would like to maintain my changes in the form of a Git branch. I can't seem to find a commit that matches up with the 3.2.2 release. The best I've been able to do is about 3000 lines of diff, which still feels quite big. Are the releases made from the git://gnuradio.org/gnuradio.git repo? Thanks, Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP
On Tue, Apr 13, 2010 at 5:06 PM, Eric Blossom wrote: > I suggest (following Cypress's lead) that you have your device come > up as something other than an unconfigured Cypress FX2. Eric, would you be able to assign a temporary PID to us under the FSF VID? We are working toward USB certification but we would like to have something to work with in the meantime. I mentioned this to Matt and he feels that this would be a good way to handle this. Note that we will release all our modifications to the USRP USB firmware and FPGA code, as per the GPL. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP
On Mon, Apr 12, 2010 at 12:00 PM, wrote: > Date: Mon, 12 Apr 2010 16:02:43 +0800 > From: =?GB2312?B?TGlhbmcgWGluIMG66r8=?= > Subject: [Discuss-gnuradio] About EEPROM and FX2(68013a) USB interface > in USRP > To: discuss-gnuradio@gnu.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi All > > I am developing a board with gnuradio which is like USRP. It is also use > FX2LP(CY7C68013a) and AD9862, and I add some surroundings. > > I hope that my board can work well with gnuradio, but it seems like it can > only support USRP now. So could you please give me some help, if I want to > run gnuradio on my board. How should I do with it? ThinkRF (www.thinkrf.com) is also developing GNU Radio compatibility for its product. I have been working on this project for a few months. We're interested in feedback on the approach we took. Our board is also an unconfigured Cypress FX2 on power-up, so we will have a proprietary utility that changes the personality of the board. Once that is done, the board "looks" like a USRP, presenting the corresponding VID/PID and responding to the USRP USB protocol. We chose to have it show up as a USRP "rev 5" to distinguish it from a real USRP, of which I believe the latest revision is 4. Is this likely to conflict any time soon? One of our goals was to minimize the changes required to the GNU Radio source tree, to make deployment and maintenance easier and to increase the chances of changes being integrated upstream. Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interfacing GNU Radio with RF digitizer product
On Thu, Jan 28, 2010 at 2:09 PM, Eric Blossom wrote: > usrp2 is the directory for the second architectural rev of the USRP1 > (Note that when these directories were created, the USRP2 was years > in the future.) Sorry for any confusion this may have caused. Thanks for the clarification! > The USRP1 firmware is contained in /usrp/firmware/* > > The USRP2 firmware is contained in /usrp2/firmware/* I was about to ask where's the USB firmware for USRP2.. but then realized it doesn't even have USB :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interfacing GNU Radio with RF digitizer product
Under usrp/firmware/src I see a directory called "usrp2". This is the Cypress firmware for USRP2? (while usrp2/firmware is firmware for the microblaze?) Is the Cypress USRP1 firmware still kicking around anywhere? On Wed, Jan 27, 2010 at 2:27 PM, Johnathan Corgan wrote: > On Wed, Jan 27, 2010 at 11:21, Catalin Patulea wrote: > >> One more question: what is the difference between the various u2_revX? > > They are various hardware revisions; the current shipping hardware us > u2_rev3. The vast majority of the FPGA code shared among them. > > Johnathan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interfacing GNU Radio with RF digitizer product
On Wed, Jan 27, 2010 at 1:32 PM, Johnathan Corgan wrote: > For now, yes. We haven't yet made a formal announcement, but the FPGA > code for both the USRP1 and USRP2 will be moved over to a repository > managed by Ettus Research. Okay, thanks. One more question: what is the difference between the various u2_revX? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Interfacing GNU Radio with RF digitizer product
Hi everyone, I'm working with ThinkRF (www.thinkrf.com) to implement a GNU Radio backend for their "WSA1000E Remote RF Digitizer" product (http://www.thinkrf.com/wsa1000e.html). Their product is (internally) very similar to the USRP devices, but it is RX only. In particular, there is an FPGA for processing the ADC data so we're looking to reuse some of the Verilog code already written for the USRP2. The PC interface is USB2, so the bandwidth will be in the same ballpark as USRP1. Any modifications or derivatives of GNU Radio will be released under GPL2. I have only one question at this point: is the Git repo (under the usrp2 directory) the main place where development happens for the USRP2? Any other repos I should look at/keep an eye on? Thanks, Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Interfacing GNU Radio with RF digitizer product
Hi everyone, I'm working with ThinkRF (www.thinkrf.com) to implement a GNU Radio backend for their "WSA1000E Remote RF Digitizer" product (http://www.thinkrf.com/wsa1000e.html). Their product is (internally) very similar to the USRP devices, but it is RX only. In particular, there is an FPGA for processing the ADC data so we're looking to reuse some of the Verilog code already written for the USRP2. The PC interface is USB2, so the bandwidth will be in the same ballpark as USRP1. Any modifications or derivatives of GNU Radio will be released under GPL2. I have only one question at this point: is the Git repo (under the usrp2 directory) the main place where development happens for the USRP2? Any other repos I should look at/keep an eye on? Thanks, Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
