+ /* 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. */
+