Re: [Discuss-gnuradio] USRP1 FPGA modification problem.
Hi, Thank you for your attention. We know that we are working with old versions and this is a problem. We've had some previous modifications, and it seemed easier to keep working with them instead of porting everything to the latest firmware/drivers. Anyway, we will take a closer look into what is happening on the host. Thanks, Tiago Em 15 de junho de 2011 14:05, Matt Ettus m...@ettus.com escreveu: Tiago, It is very hard to help you. You are basically saying we did something different and it doesn't work. You haven't posted code, you're using an old version of GNU Radio, and not using the latest drivers (UHD). This all makes it hard to help you. If the FPGA is asserting have_pkt_rdy, the FX2 is not setting RD and OE, and you haven't changed the code running in theFX2, then it is likely that your app on the host has died or closed. Matt On 06/14/2011 11:52 AM, Tiago Rogério Mück wrote: Hi, Have anyone taken a look at this ? We are still struggling to find a solution to this problem. Any tip would help a lot. Thanks, Tiago Em 27 de maio de 2011 16:51, Tiago Rogério Mück ti...@lisha.ufsc.br mailto:ti...@lisha.ufsc.br escreveu: Hi, We have been working with an (old) USRP1 and doing some modifications in the FPGA code. After our modifications (we added an extra layer of DDCs to perform channel separation in the FPGA), the things didn't work as expected. In some Gnuradio applications the USRP stops sending samples after some time. For example, usrp_fft.py runs just fine all the time, but usrp_rx_cfile.py and usrp_wfm_rcv.py work for some secs and then the USRP stops sending samples. I added some pics of our preliminary debugging. In the figures, the yellow, blue and red signals refer to the have_pkt_rdy, RD and OE signals, respectively. After some time, the Cypress stops setting RD and OE signals in response to the assertion of have_pkt_rdy (first figure). Latter, the USB FIFO in the FPGA overflows and then have_pkt_rdy goes down (figure 2). So it seems the problem is not with our modifications in the FPGA code but with something related to the Cypress. Have someone ever had a similar problem ? Any clue in how to solve this would help a lot. We are using Gnuradio 3.2.2. The funny thing is that usrp_fft.py works perfectly (we double checked all *.py to make sure our new bitstream is always being loadded and our new DDCs are being properly configured). Thanks. Regards, Tiago. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 FPGA modification problem.
Hi, Have anyone taken a look at this ? We are still struggling to find a solution to this problem. Any tip would help a lot. Thanks, Tiago Em 27 de maio de 2011 16:51, Tiago Rogério Mück ti...@lisha.ufsc.brescreveu: Hi, We have been working with an (old) USRP1 and doing some modifications in the FPGA code. After our modifications (we added an extra layer of DDCs to perform channel separation in the FPGA), the things didn't work as expected. In some Gnuradio applications the USRP stops sending samples after some time. For example, usrp_fft.py runs just fine all the time, but usrp_rx_cfile.py and usrp_wfm_rcv.py work for some secs and then the USRP stops sending samples. I added some pics of our preliminary debugging. In the figures, the yellow, blue and red signals refer to the have_pkt_rdy, RD and OE signals, respectively. After some time, the Cypress stops setting RD and OE signals in response to the assertion of have_pkt_rdy (first figure). Latter, the USB FIFO in the FPGA overflows and then have_pkt_rdy goes down (figure 2). So it seems the problem is not with our modifications in the FPGA code but with something related to the Cypress. Have someone ever had a similar problem ? Any clue in how to solve this would help a lot. We are using Gnuradio 3.2.2. The funny thing is that usrp_fft.py works perfectly (we double checked all *.py to make sure our new bitstream is always being loadded and our new DDCs are being properly configured). Thanks. Regards, Tiago. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 FPGA now builds on ISE12
Hello, Have you tried the new Xilinx's FIFOs ? All constraints were met after regenerating the FIFOs using Fifo Generator 6.1. I used ise12 branch and compiled the raw ethernet code. 2010/6/1 Matt Ettus m...@ettus.com The USRP2 FPGA image can now be built with ISE 12.x. ISE 11.x probably also works, but since 12 is a free upgrade from 11, I suggest you use 12. Everything still works on ISE 10.1.03 as well. One additional change is that both the plain (Raw Ethernet) and UDP versions (for UHD) are in the same tree now. Build the plain version with: make bin in the usrp2/top/u2_rev3 directory, and the UDP version can be built with: make -f Makefile.udp bin This experimental branch is called ise12_exp and you can get it from our git repository: http://code.ettus.com/redmine/ettus/projects/show/fpga It does not quite meet timing yet, but it is plenty good for experimental work. We will be working on timing closure in the next couple of weeks. Any feedback would be much appreciated. Huge thanks go to Ian Buckley for his help in this porting effort. Thanks, Matt ___ 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] USRP2 and ISE 12
Well, it seems the aeMB guys are working on a new version of the the core. Maybe the new core will perform better. Em 14 de maio de 2010 18:17, Brian Padalino bpadal...@gmail.com escreveu: 2010/5/14 Tiago Rogério Mück ti...@lisha.ufsc.br: Hello, It seems that everyone is having troubles with ISE 11.x, but has anyone tried the new ISE 12 ? We have successfully synthesized the USRP2 fpga code with ISE 12.1, but we got a timing error and the bitstream didn't seem to work: find_usrps didn't find anything and the leds didn't flash. We are using the latest code from the repositories for both fpga and firmware. Is there anyone who has tried ISE 12 and want to share the experience ? I am not building the USRP2 FPGA, or have experience with ISE 12, but the errors you have are all related to BRAM feeding the aeMB CPU - more specifically RAM output - Mux - Adder - FF, mostly with 7 to 10 layers of logic inbetween. Good luck debugging that portion of the CPU. Hopefully you can achieve timing closure. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 and ISE 12
Hello, It seems that everyone is having troubles with ISE 11.x, but has anyone tried the new ISE 12 ? We have successfully synthesized the USRP2 fpga code with ISE 12.1, but we got a timing error and the bitstream didn't seem to work: find_usrps didn't find anything and the leds didn't flash. We are using the latest code from the repositories for both fpga and firmware. Is there anyone who has tried ISE 12 and want to share the experience ? Release 12.1 Trace (lin) Copyright (c) 1995-2010 Xilinx, Inc. All rights reserved. /export/Xilinx/12.1/ISE_DS/ISE/bin/lin/unwrapped/trce -intstyle ise -e 10 -s 5 -n 3 -fastpaths -xml u2_rev3.twx u2_rev3.ncd -o u2_rev3.twr u2_rev3.pcf Design file: u2_rev3.ncd Physical constraint file: u2_rev3.pcf Device,package,speed: xc3s2000,fg456,-5 (PRODUCTION 1.39 2010-04-09) Report level: error report, limited to 10 items per endpoint, 3 endpoints per constraint Environment Variable Effect -- NONE No environment variables were set INFO:Timing:3386 - Intersecting Constraints found and resolved. For more information, see the TSI report. Please consult the Xilinx Command Line Tools User Guide for information on generating a TSI report. INFO:Timing:2752 - To get complete path coverage, use the unconstrained paths option. All paths that are not constrained will be reported in the unconstrained paths section(s) of the report. INFO:Timing:3339 - The clock-to-out numbers in this timing report are based on a 50 Ohm transmission line loading model. For the details of this model, and for more information on accounting for different loading conditions, please see the device datasheet. INFO:Timing:3390 - This architecture does not support a default System Jitter value, please add SYSTEM_JITTER constraint to the UCF to modify the Clock Uncertainty calculation. INFO:Timing:3389 - This architecture does not support 'Discrete Jitter' and 'Phase Error' calculations, these terms will be zero in the Clock Uncertainty calculation. Please make appropriate modification to SYSTEM_JITTER to account for the unsupported Discrete Jitter and Phase Error. Timing constraint: TS_clk_to_mac = PERIOD TIMEGRP clk_to_mac 8 ns HIGH 50%; 6393 paths analyzed, 1272 endpoints analyzed, 0 failing endpoints 0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 7.909ns. Timing constraint: TS_clk_fpga_p = PERIOD TIMEGRP clk_fpga_p 10 ns HIGH 50%; 6 paths analyzed, 6 endpoints analyzed, 0 failing endpoints 0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 5.987ns. Timing constraint: TS_cpld_clk = PERIOD TIMEGRP cpld_clk 40 ns HIGH 50%; 519 paths analyzed, 104 endpoints analyzed, 0 failing endpoints 0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 7.390ns. Timing constraint: TS_GMII_RX_CLK = PERIOD TIMEGRP GMII_RX_CLK 8 ns HIGH 50%; 8201 paths analyzed, 1191 endpoints analyzed, 0 failing endpoints 0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 7.837ns. Timing constraint: TS_ser_rx_clk = PERIOD TIMEGRP ser_rx_clk 10 ns HIGH 50%; 44 paths analyzed, 14 endpoints analyzed, 0 failing endpoints 0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 6.747ns. Timing constraint: TS_clk_div_to_dsp_clk = MAXDELAY FROM TIMEGRP clk_div TO TIMEGRP dcm_out 10 ns; 19534 paths analyzed, 7884 endpoints analyzed, 0 failing endpoints 0 timing
Re: [Discuss-gnuradio] USRP custom registers
Good to hear that. Thank you. 2009/9/16 Eric Blossom e...@comsec.com: On Wed, Sep 16, 2009 at 04:40:33PM -0300, Tiago Rogério Mück wrote: Hello, We are working on a custom FPGA build that is going to need more then the 32 registers available for user's builds. I looked at fpga_regs_standard.v/fpga_regs_common.v and seems that the registers 96-127 are not being used. Is there a problem in using these registers ? Or in extending the registers address space beyond 127? You should be good up to 127. The host code, the FX2 firmware and the FPGA code limit the register number to 7-bits (1 bit is used to code for read vs write in the SPI transaction that is used to read or write the FPGA registers). Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the USRP2 external SRAM
Thanks for the answer. I'm going to start working on it soon and then I'll come back here with the results (or with the problems :) 2009/6/15 Eric Blossom e...@comsec.com On Wed, Jun 10, 2009 at 04:59:24PM -0300, Tiago Rogério Mück wrote: Hi all, I'm working on some experiments using the USRP2, and the 32 Kb available for the firmware won't be enough for my experiments. I'll need to modify the FPGA code so I can use the 1 MB SRAM for both instructions and data for the aeMB, but I'm a bit lost on how I can do this modifications. I looked the code and came to some conclusions about what needs to be done: 1 - Change the memory map - Change the RAM space to 0 - 1 MB - Update the mapping of the buffer poll and the peripherals 2 - Change the logic inside the sys_ram block to forward access to addresses beyond 32 K to the external SRAM 3 - Change the ram_loader parameters so it can load the entire firmware. Could someone tell me if I'm going to the right direction? I will be very grateful for any hint you can give me. Yes, this is the right direction. You'll probably want to include a dcache to get any kind of throughput out of it. There's currently a small icache. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Using the USRP2 external SRAM
Anyone ? 2009/6/10 Tiago Rogério Mück ti...@lisha.ufsc.br Hi all, I'm working on some experiments using the USRP2, and the 32 Kb available for the firmware won't be enough for my experiments. I'll need to modify the FPGA code so I can use the 1 MB SRAM for both instructions and data for the aeMB, but I'm a bit lost on how I can do this modifications. I looked the code and came to some conclusions about what needs to be done: 1 - Change the memory map - Change the RAM space to 0 - 1 MB - Update the mapping of the buffer poll and the peripherals 2 - Change the logic inside the sys_ram block to forward access to addresses beyond 32 K to the external SRAM 3 - Change the ram_loader parameters so it can load the entire firmware. Could someone tell me if I'm going to the right direction? I will be very grateful for any hint you can give me. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Timer
I'm having some problems using the USRP2 timer. I tested the timer_test.c
and it's not setting a new time to interrupt after the firsts interrupt is
triggered. It doesn't work if the new time is set inside de timer ISR. If I
try to set the new time inside the main function using something like this:
while (1){
while(flag);
int t = timer_regs-time;
timer_regs-time = t + DELTA_T;
flag = 1;
}
And adding flag = 0 in the end of timer_handler.
It works, but I don't think this is the right way of using the timer.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using the USRP2 external SRAM
Hi all, I'm working on some experiments using the USRP2, and the 32 Kb available for the firmware won't be enough for my experiments. I'll need to modify the FPGA code so I can use the 1 MB SRAM for both instructions and data for the aeMB, but I'm a bit lost on how I can do this modifications. I looked the code and came to some conclusions about what needs to be done: 1 - Change the memory map - Change the RAM space to 0 - 1 MB - Update the mapping of the buffer poll and the peripherals 2 - Change the logic inside the sys_ram block to forward access to addresses beyond 32 K to the external SRAM 3 - Change the ram_loader parameters so it can load the entire firmware. Could someone tell me if I'm going to the right direction? I will be very grateful for any hint you can give me. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Missing files in USRP2 ISE project
I tried the makefile in u2_rev3 but got some erros:
Creating project: build/u2_rev3.ise
ERROR:HierarchicalDesignC:40 - Failed to close Project repository.
HDProject
data may not have been properly written to the Project file.
ERROR:HierarchicalDesignC:40 - Failed to close Project repository.
HDProject
data may not have been properly written to the Project file.
Setting: Project[family] = Spartan3
ERROR:TclTasksC - ERROR:TclTasksC:project_041: Internal error. Error getting
SynthesisOnly default view.
Setting: Project[device] = xc3s2000
Setting: Project[package] = fg456
Setting: Project[speed] = -5
Setting: Project[top_level_module_type] = HDL
Setting: Project[synthesis_tool] = XST (VHDL/Verilog)
Setting: Project[simulator] = ISE Simulator (VHDL/Verilog)
ERROR:TclTasksC:project_095 - project set : Unknown property simulator.
Type [project properties] for more information.
while executing
project set $key $opt
invoked from within
if ![string compare $process Project] {
project set $key $opt
} else {
project set $key $opt -process $process
}
invoked from within
if $state {
set key $opt
set state 0
} else {
puts Setting: $process\[$key\] = $opt
if ![string compare $process Project] {
...
(procedure set_props line 7)
invoked from within
set_props Project $env(PROJECT_PROPERTIES)
invoked from within
if [file isfile $env(PROJ_FILE)] {
puts Opening project: $env(PROJ_FILE)
project open $env(PROJ_FILE)
} else {
puts Creating project: $...
(file ../tcl/ise_helper.tcl line 43)
make: *** [proj] Error 1
I've found some info about this erros on
http://www.xilinx.com/support/answers/29765.htm , but I wasn't able to make
it work. So I tried the hard way. I created a project and manualy
configured it acording to the makefile.
There was also another error in the implementation step when I tried to
build the code:
ERROR:NgdBuild:789 -
/export/tiago/TCC/implementacao/usrp2/fpga/top/u2_rev3/u2_rev3.ucf Line
326: 'CLOCK_DEDICATED_ROUTE' is an invalid constraint name.
Commenting that constraint solves the problem and the project builds fine. I
uploaded the bitstream to the usrp2 and it seems to be OK.
Are these the errors related to the bugs in ISE 9.1 that you talked about?
Is there some consequence in removing the 'CLOCK_DEDICATED_ROUTE'
constraint?
Anyway, I'll try to get a more recent version of ISE.
Thanks
2009/5/8 Matt Ettus m...@ettus.com
Tiago Rogério Mück wrote:
Hi all,
I'm trying to open the ISE project in gnuradio/usrp2/fpga/top/u2_fpga and
it seems some files are missing.
Don't use u2_fpga. Use u2_rev3, which will compile fine.
I'm using ISE 9.1i and it first converts the project to version 9.1 and
then I got the annexed error.
I believe ISE 9.1 has some bugs which affect our design. You'll want to
upgrade to 10.1.03. I haven't tried the new 11.1 yet.
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Missing files in USRP2 ISE project
Yeah, I know, and I also looked for the files in gnuradio/usrp2/ and found some of them (strobe_gen.v and extram_interface.v) in another places. But u2_basic.v and fifo_...v seems to be realy missing. I couldn't find them anywhere on the trunk (rev 10991). Thanks 2009/5/8 Brian Padalino bpadal...@gmail.com 2009/5/8 Tiago Rogério Mück ti...@lisha.ufsc.br: Hi all, I'm trying to open the ISE project in gnuradio/usrp2/fpga/top/u2_fpga and it seems some files are missing. I'm using ISE 9.1i and it first converts the project to version 9.1 and then I got the annexed error. It's just a relative addressing versus absolute addressing problem with the files. It should be fixed, but it isn't a deal breaker. Those files exist, just not in the place where the Xilinx tool is looking for them. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using two flow graphs in the same application
I've wrote an application that have two flow graphs as follows: usrp2_source
- fir - file_sink. The only difference between the two are the usrp2
frequency and decimation rate.
As you can see in the annexed code, I start the first flow graph, five
seconds latter it stops and the second one starts. The problem is I'm not
able to set the new frequency on the second flow graph. set_center_freq
method returns None.
I tried to use the same usrp2_source for the two graphs, but the problem
persists.
Can somebody give me a hint on how make this work?
I'm using USRP2 with RFX2400 db and gnuradio rev 10780
Thanks
#!/usr/bin/env python
from gnuradio import gr, gru, blks2
from gnuradio import usrp2
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
import gnuradio.gr.gr_threading as _threading
from optparse import OptionParser
import os, struct, sys, time, math, random, threading
def get_fir_filter():
taps = [0.50, 0.25, 0.125, 0.0645]
return gr.fir_filter_ccf(1, taps)
class USRP2source:
__instance = None
def __init__(self, interface, mac_addr):
if USRP2source.__instance:
raise USRP2source.__instance
USRP2source.__instance = self
self.shared_usrp2_source32fc = usrp2.source_32fc(interface, mac_addr)
def get_usrp2_sorce32fc(interface, mac_addr):
try:
instance = USRP2source(interface, mac_addr)
except USRP2source, e:
instance = e
return instance.shared_usrp2_source32fc
class test1(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
#self.u = get_usrp2_sorce32fc(eth0, )
self.u = usrp2.source_32fc(eth0, )
self.fir = get_fir_filter()
self.sink = gr.file_sink(gr.sizeof_gr_complex, test1.dat)
tr = self.u.set_center_freq(2.462e9)
if tr == None:
sys.stderr.write('Failed to set center frequency\n')
raise SystemExit, 1
self.u.set_decim(16)
self.connect(self.u, self.fir, self.sink)
class test2(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
#self.u = get_usrp2_sorce32fc(eth0, )
self.u = usrp2.source_32fc(eth0, )
self.fir = get_fir_filter()
self.sink = gr.file_sink(gr.sizeof_gr_complex, test2.dat)
tr = self.u.set_center_freq(2.412e9)
if tr == None:
sys.stderr.write('Failed to set center frequency\n')
raise SystemExit, 1
self.u.set_decim(14)
self.connect(self.u, self.fir, self.sink)
def main ():
print Running test 1
t1 = test1()
t1.start()
time.sleep(5)
print Stopping test1
t1.stop()
t1.wait()
print Running test2
t2 = test2()
t2.start()
time.sleep(5)
print Stopping test2
t2.stop()
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
raise SystemExit
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
That's good news. The code I sent seemed to be working but i realy didn't tested it. We have only one USRP2 here and we were trying to receive pkts using a 802.11b PCI card (Realtek RTL8180L chipset), but without success (some problems with the card configuration). 2009/4/17 Valerio, Danilo vale...@ftw.at Hi Colby! We have also tried without success. We have used the TX path from Tiago and a modified version of the RX path (firmware and FPGA at their latest update). I also felt confident that the the TX path works, and consequently that the RX path had some problem. So we have tried to transmit with the USRP2 and receive with a real IEEE802.11 chipset (Ralink chipset RT2500). This chipset has no firmware and we modified the linux driver so as to: - avoid mac CRC (Everything received on the MAC layer is passed to the higher layers); - set fixed modulation schemes (i.e. DBPSK 1Mbps); - set PLCP long preamble. - set complete monitor/passive mode. The chipset detects some transmitted frames. This could be an indication that the PLCP preamble/header is correct (?). However the PLCP payload is just rubbish. We have also tried to submit stupid payloads (like ) and I have the impression that what we receive is just random. :-( If we obtain some successful result in the next few days, I'll let you know! Best Regards, Danilo On Friday 17 April 2009 09:17:38 Colby Boyer wrote: Hi All, I've been trying to run some hardware tests between two USRP2s, but I have had no success in receiving packets. I am using the modified TX from Tiago. I feel sorta confident that the TX code works, because when I run the usrp2_fft.py, I see a wave form being transmitted over the channel. Has anyone have any success on receiving packets between two USRP2s? When RX/TX there is a usrp2::ctor reset db failed error. Could this cause problems for the RX/TX? I am using the firmware that was shipped with the USRP2. Thanks, Colby Boyer On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr wrote: Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File ./bbn_80211b_rx.py, line 179, in module main () File ./bbn_80211b_rx.py, line 174, in main app = app_flow_graph() File ./bbn_80211b_rx.py, line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File ./bbn_80211b_rx.py, line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py, line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs) TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 arguments (1 given) do you have any idea about the origin of this problem? Thank you in advance. On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote: / Updated from the trunk and I'm not getting that msg anymore./ / / / Everything seems to be ok now./ Glad to hear it! Thanks for letting us know. 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] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Updated from the trunk and I'm not getting that msg anymore. Everything seems to be ok now. 2009/4/3 Eric Blossom e...@comsec.com On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote: I fixed the problem. The top_block on bbn_80211b_tx_port was not being properly initialized. It seems to be working now, but when I use 8 samples per data bit instead of 4 I randomly got the following error: usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes) Does anyone know what this mean? I'm sending the working code. Can you update from the trunk and try this again. We added what we believe is a work around for this problem on 3/26 in r10689 on the trunk. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
I fixed the problem. The top_block on bbn_80211b_tx_port was not being properly initialized. It seems to be working now, but when I use 8 samples per data bit instead of 4 I randomly got the following error: usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes) Does anyone know what this mean? I'm sending the working code. 2009/4/2 Tiago Rogério Mück ti...@lisha.ufsc.br Hi all, I'm trying to port the tx code to the usrp2 based on Colby's branch and i'm having some problems. The program freezes when the 3rd packet is being sent. The program uses a gr.message_source to buffer the packets and convert them into a data flow to the modulator, and the problem is that, for some reason, the data flow isn't flowing and the packets are accumulating in the msg_source. Since the msg_source's queue size is 2, the method to add the 3rd packet to the queue blocks because the queue is full. I didn't figured out whats the problem with my code. The bbn80211b_test.py woks, so the problem is probably related to the connection of the modulator block with the usrp2 sink or to the configuration of the usrp2. I'm sending the files i have modified. 2009/3/31 Colby Boyer csbo...@berkeley.edu Hi all, I created a branch on the cgran server for the usrp2 code. If anyone is interested in still using the usrp with the hier_block2, just dont use the rx/tx.py files. The rest of the files should work with the usrp1. Cheers, Colby On Mon, Mar 30, 2009 at 3:58 PM, George Nychis gnyc...@cmu.edu wrote: Hi all, CGRAN's trac has a core dumping issue that I still have not figured out how to address yet. So, if you're using the wiki and get blank pages or a 500 internal server error, sorry. I've been trying to sort it out, but no luck yet: http://www.gossamer-threads.com/lists/trac/users/40954 It should not affect the svn server though. - George 2009/3/30 Colby Boyer csbo...@berkeley.edu The cgran server seems to be down. I'll let you know when I am able to get an account. On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer colby.bo...@gmail.comwrote: Sure. I will try to get a cgran account and upload my code to their SVN. It would then be easy to see the changes I made. On Mon, Mar 30, 2009 at 2:21 AM, Costantini, Andrea costant...@ftw.at wrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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 #!/usr/bin/env python # # Copyright 2005 Free Software Foundation, Inc. # # Copyright (c) 2006 BBN Technologies Corp. All rights reserved. # Effort sponsored in part by the Defense Advanced Research Projects # Agency (DARPA) and the Department of the Interior National Business # Center under agreement number NBCHC050166. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. # from gnuradio import gr, gru, blks2 from gnuradio import usrp2 from gnuradio import eng_notation from gnuradio.eng_option import
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi all, I'm trying to port the tx code to the usrp2 based on Colby's branch and i'm having some problems. The program freezes when the 3rd packet is being sent. The program uses a gr.message_source to buffer the packets and convert them into a data flow to the modulator, and the problem is that, for some reason, the data flow isn't flowing and the packets are accumulating in the msg_source. Since the msg_source's queue size is 2, the method to add the 3rd packet to the queue blocks because the queue is full. I didn't figured out whats the problem with my code. The bbn80211b_test.py woks, so the problem is probably related to the connection of the modulator block with the usrp2 sink or to the configuration of the usrp2. I'm sending the files i have modified. 2009/3/31 Colby Boyer csbo...@berkeley.edu Hi all, I created a branch on the cgran server for the usrp2 code. If anyone is interested in still using the usrp with the hier_block2, just dont use the rx/tx.py files. The rest of the files should work with the usrp1. Cheers, Colby On Mon, Mar 30, 2009 at 3:58 PM, George Nychis gnyc...@cmu.edu wrote: Hi all, CGRAN's trac has a core dumping issue that I still have not figured out how to address yet. So, if you're using the wiki and get blank pages or a 500 internal server error, sorry. I've been trying to sort it out, but no luck yet: http://www.gossamer-threads.com/lists/trac/users/40954 It should not affect the svn server though. - George 2009/3/30 Colby Boyer csbo...@berkeley.edu The cgran server seems to be down. I'll let you know when I am able to get an account. On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer colby.bo...@gmail.comwrote: Sure. I will try to get a cgran account and upload my code to their SVN. It would then be easy to see the changes I made. On Mon, Mar 30, 2009 at 2:21 AM, Costantini, Andrea costant...@ftw.atwrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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 # # Copyright 2005 Free Software Foundation, Inc. # # Copyright (c) 2006 BBN Technologies Corp. All rights reserved. # Effort sponsored in part by the Defense Advanced Research Projects # Agency (DARPA) and the Department of the Interior National Business # Center under agreement number NBCHC050166. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. # from gnuradio import gr, gru, blks2 from gnuradio import usrp2 from bbn_80211b_pkt import * # / # transmit path # / class bbn_80211b_transmit_path(gr.hier_block2): def __init__(self, interp, spb, use_barker, interface=, mac_addr=None): gr.hier_block2.__init__(self, bbn_80211b_transmit_path, gr.io_signature(0,0,0), gr.io_signature(0,0,0)) self.normal_gain
[Discuss-gnuradio] Questions about the USRP
Hi, Guys, I want to start doing some experiments with SDR using the USRP and I have some doubts. To begin with, I'd like to replicate the experiment described in this paper: http://www.inf.ufsc.br/~tiagorm/Thomas_Schmid_PAPER.pdf , and would like to know what hardware you recommend(USRP1 or 2, the set of daughterboards and antennas). Next, i'm planning to build a standalone system using the USRP2 to bridge 802.11 and bluetooth connections, and i have some doubts about the RFX2400. Can it transmit and receive at the same time? Is there another daughterboard set that is better suited for this job? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
