Things are starting to stabilize on the UHD front and everything is
moving forward rapidly. You should really be trying out the UHD now
if any of the following applies to you:
-
You want to use the USRP2 on Windows or Mac OS X
-
You want your USRP2 to use UDP instead of raw ethernet
-
You want VITA-49
-
You want to use USRPs with software other than GNU Radio (like
OpenBTS, OSSIE, SCARI, LabVIEW, Simulink, Matlab, or anything else),
especially if you are a developer of one of those systems
-
You have developed your own daughterboards
-
You want your application to be able to transparently use the USRP1 or
USRP2
The UHD currently supports the following hardware:
- USRP2
- BasicRX, BasicTX
- LFRX, LFTX
- RFX-series
- XCVR2450
It will support the following (soon, and in this order):
- WBX
- DBSRX
- TVRX
- USRP1
- All of our future products
You can find the docs and the code here:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki
Matt
Matt E. wrote:
Things are starting to stabilize on the UHD front and everything is
moving forward rapidly. You should really be trying out the UHD now
if any of the following applies to you:
- You want to use USRPs with software other than GNU Radio (like
OpenBTS, OSSIE, SCARI, LabVIEW, Simulink, Matlab, or anything else),
especially if you are a developer of one of those systems
What about support for timestamped packets (inband signalling for usrp1)
? Is that something UHD supports ?
From looking at the API it seems so (time_spec) but that uses ‘double’
and not an integer sample count. Isn’t there a risk of imprecision /
shift / gap of +/- 1 sample ? Especially if we use non standard clock
rates that don’t have nice # samples per seconds …
Cheers,
Sylvain
In band signaling is a misnomer. But yes, the UHD supports time stamped
samples down to the precision of the clock. The time spec uses a 32 bit
integer for seconds and a double for fractional seconds (in
nanoseconds). The reason for using nanoseconds was to make the time spec
independent of the usrp device clock rate, since we will want to support
other clock rates than just usrp2-100Mhz.
The double has about 52 bits of mantissa, only 30 of which are needed
for the integer part of the nanoseconds. So I dont think there is room
for ambiguity as to which clock tick a time spec will refer to (for a
clock rate in 10s of Mhz).
-Josh
On 04/26/2010 01:41 PM, Josh B. wrote:
clock rate in 10s of Mhz).
-Josh
My main “looking forward to’s”:
o n-bit OTW format, to facilitate higher bandwidth: n=4,8,16
o a generic method for setting/getting auxillary
TTL/LVCMOS/LVTTL/whatever control bits
if the daughtercard has 'em, without necessarily giving up data
bits.
My radio astronomy work could benefit greatly from both of these, as
well as time-stamped sampling.
Actually, I do have a question about time-stamping. Are individual
samples timestamped, or just
blocks of samples?
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 04/26/2010 12:09 PM, Marcus D. Leech wrote:
for ambiguity as to which clock tick a time spec will refer to (for a
bits.
Both coming, but further in the future than the other things mentioned.
My radio astronomy work could benefit greatly from both of these, as
well as time-stamped sampling.
Actually, I do have a question about time-stamping. Are individual
samples timestamped, or just
blocks of samples?
Blocks. It would be wasteful to send a whole timestamp for each sample
when they come at regular intervals.
Matt