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)

diff --git a/usrp2/firmware/lib/db_bitshark_rx.c b/usrp2/firmware/lib/db_bitshark_rx.c
index af17457b81e979fb1f425bb35b5581d8468e33da..669bb7c49d9faa005199d6dccff4a18320e7d68b 100644 (file)
--- 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);