On Sun, Mar 04, 2007 at 01:33:08AM -0800, Peter M. wrote:
Except for the 1-bit case, the user is going to have to do some AGC
USB bus instead of converting to shorts or floats.
The “short” version doesn’t touch the data. You’ll be able to unpack
it youself. “short”'s probably the wrong name for the interface. We
should revisit the name.
The test_usrp_standard_rx app comes close to what I want, but
it doesn’t seem to have daughterboard intelligence, so I can’t
set gain properly. Finally, it would be good to have support
for a decimation ratio of 2 (just the halfband filter) and 1
Once the daughterboard code is ported to C++, we can back-port it into
Because of the lack of h/w multipliers, and our desire to minimize
resource usage in the halfband filter, it’s implemented with a single
synthesized multiplier, and it takes 8 clocks to generate each output
from the 31-tap half-band filter (It’s symmetric, and the center tap
is one). That determines the minimum decimation rate required upstream
from the halfband (4).
If you’re willing to remove some stuff from the FPGA (leaving e.g,
0 tx, 2 rx), you might have room to reimplment the half-band.
I’d eventually like to dump to disk 2-bit samples at 32 Ms/s complex
using two dbs_rx cards, which should just fit within the 32 MByte/sec
USB limit. This is for a dual-frequency GPS application (L1/L2C at first,
but the USRP provides enough bandwidth for the wider P/Y-code signals
I’m hoping the dbs_rx’s close-in phase noise is low enough
to allow a small carrier-loop bandwidth—are there any measurements
I can look at?
Check with Matt.
Please let me know if anything else is needed for the patch.
There’s a testbench for bit_pack.v I can send along if you like.
One possible issue is synchronization, to make sure that the
channels are properly distributed within the 16 bits after
The test bench would be nice.