From ebb561d028bfd4a3ca2571fb997bb13a514bd87c Mon Sep 17 00:00:00 2001 From: JohnOrlando Date: Thu, 13 May 2010 18:03:13 -0500 Subject: [PATCH] Updated db_bitshark_rx.c to the proper version that includes the delays when sending back-to-back I2C commands, as well as the proper command when setting the bw (previous blunder with git resulted in the wrong version on this branch) --- usrp2/firmware/lib/db_bitshark_rx.c | 36 +++++++++++++++++++---------- 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/usrp2/firmware/lib/db_bitshark_rx.c b/usrp2/firmware/lib/db_bitshark_rx.c index af17457b..669bb7c4 100644 --- a/usrp2/firmware/lib/db_bitshark_rx.c +++ b/usrp2/firmware/lib/db_bitshark_rx.c @@ -154,24 +154,38 @@ bitshark_rx_init(struct db_base *dbb) /* hal_gpio_write( GPIO_RX_BANK, ENABLE_5|ENABLE_33, ENABLE_5|ENABLE_33 ); */ /* above isn't needed, since we don't have any GPIO from the FPGA */ + /* The next set of initialization commands sent to the bitshark board + require a brief delay after each command. This only seems to be + necessary when sending a sequence of commands one after the other. + This issue appears to be specific to the USRP2, since it isn't + necessary on the USRP1. The 5 mS delay is a bit of + an emperical compromise: too short (say, 1 mS), and every once + in a great while a command will still be magically dropped on its + way out...too long (say, 500 mS) and higher-level apps such as + usrp2_fft.py seem to choke because the init sequence is taking + too long. So 5 mS was tested repeatedly without, and deemed + reasonable. Not sure if this is an issue with the I2C master + code in the microblaze or some place else, and I hate magic + delays too, but this seems to be stable. */ + /* setup the clock scheme to accept the USRP2's 100 MHz ref clk */ set_clock_scheme(0,100000000); - + mdelay(5); /* initial setting of gain */ dbb->set_gain(dbb,U2_DOUBLE_TO_FXPT_GAIN(20.0)); - + mdelay(5); /* Set the freq now to get the one time 10ms delay out of the way. */ u2_fxpt_freq_t dc; dbb->set_freq(dbb, dbb->freq_min, &dc); - + mdelay(5); /* set up the RF bandwidth of the signal of interest...Note: there doesn't appear to be a standard way of setting this bandwidth in USRP2-land (compared to USRP1-land, where we have the straight-forward set_bw() method). Not sure why this is, but for now, simply set the bandwidth once for the intended application. */ - db->extra.set_bw(dbb, 20000); /* 20 MHz channel bw */ - + db->extra.set_bw(dbb, 25000); /* 25 MHz channel bw */ + mdelay(5); return true; } @@ -227,7 +241,7 @@ bool bitshark_rx_set_bw(struct db_base *dbb, uint16_t bw_in_khz) { struct db_bitshark_rx_dummy *db = (struct db_bitshark_rx_dummy *) dbb; - unsigned char val[4]; + unsigned char val[2]; unsigned char args[NUM_BYTES_IN_I2C_CMD]; if(!(bw_in_khz >= db->extra.bw_min && bw_in_khz <= db->extra.bw_max)) @@ -236,12 +250,10 @@ bitshark_rx_set_bw(struct db_base *dbb, uint16_t bw_in_khz) } memset(args,0x00,NUM_BYTES_IN_I2C_CMD); - memcpy(val,&bw_in_khz,4); - args[0] = RF_CENTER_FREQ_REG; - args[5] = val[3]; - args[6] = val[2]; - args[7] = val[1]; - args[8] = val[0]; + memcpy(val,&bw_in_khz,2); + args[0] = RF_CHAN_FILTER_BW_REG; + args[5] = val[1]; + args[6] = val[0]; i2c_write(I2C_ADDR, args, NUM_BYTES_IN_I2C_CMD); -- 2.30.2