On Sun, Feb 26, 2006 at 11:16:17AM -0500, Clark Pope wrote: > You'll want to strip out the extra receiver. The default fpga is 2 rx and 1 > tx. You probably don't need the second RX for your application. You also > may not need the halfband filter on your receiver. > > In the past I've stripped down to a single RX and got utilization down to > about 30%. You'll probably be at 40% with one RX and one TX.
The current code is (mostly) conditionally configured for number of Rx and Tx channels. You can select 0, 1, 2 or 4 Rx, but right now, the Tx is either 0 or 2. It's easy to fix. I'd welcome a patch (the Tx should be conditionalized in the same style as the Rx). Take a look at usrp/fpga/toplevel/usrp_std/usrp_std.v, usrp_std.vh and usrp_std_config_*.vh > As far as control logic. I've been planning something similar (open 802.11 > mac) and I was thinking I could write a linux device driver to do a lot of > the time critical stuff (agc, CA, etc.). Seems like one can poll some > status lines from the FPGA frequently enough to do a lot of things. FYI, It's not clear that going to a driver is going to make too much difference. It might, but I'd start with the user mode code. Measure twice, cut once ;) There is some fairly straight-forward work that can be done to reduce the latency of the user mode code, and that's probably a good first step. This would also including enabling real-time scheduling for the signal processing threads (SCHED_FIFO), reducing the amount of user space buffering for the USRP (no need to mess with the generic buffering in GNU Radio, it's not the problem), and transfering smaller chunks of data across the user/kernel boundary (that that won't help throughput!). Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
