[USRP-users] Direct Programming the FPGA

Eddie Carle eddie at isatec.ca
Fri Dec 5 22:27:49 EST 2014


On Wed, 2014-12-03 at 09:15 -0800, Ian Buckley via USRP-users wrote:
> Here's a link to a block diagram of an older N210 USRP….essentially
> half of an X300 showing the ADC/DAC's and RF mixers and LO's.
> http://www.ni.com/cms/images/devzone/tut/USRP_Advanced_Diagram_smaller.png

Ah yes. That diagram does help quite a bit thank you. It is all becoming
much more clear.

> IQ imbalance and DC offset are intrinsic issues with direct-conversion
> radio's and the corresponding blocks in the USRP are used to digitally
> cancel these analog impefections. After running Ettus's calibration
> S/W utilities then calibration data recorded against each daughter
> card radio's serial number will be applied by UHD as available using
> these blocks.
> 
> IQ swap is generally a transparent block for most daughter card
> radio's , don't worry about this block it will be managed by UHD.

Again, making much more sense now thanks.

> The CORDIC in essence provides tuning with arbitrary frequency
> precision, as Martin mentioned, allowing us to go beyond the minimum
> tuning quanta of the daughter card radio synthesizer.
> But in the context of direct conversion it has other interesting uses.
> Its for example very common to use the CORDIC to move the baseband
> signal signal significantly away from the DC offset artifact or LO
> leakage that results intrinsically in direct conversion radios.
> Another great advantage of having the the CORDIC is the ability to
> frequency hop instantaneously within the bandwidth of the converters.
> In multi-channel applications multiple CORDIC instances can be used as
> a channelizer. Etc etc.
> If UHD apportions no tuning component to the CORDIC then it too will
> be a transparent block to your signal.
> 
> Take a general read on google hits for direct conversion, most of this
> stuff is not USRP specific.

Will do thanks. Interesting stuff this is.

> As for stand-alone operation, that is where your potential workload is
> going to jump exponentially. The USRP's are designed primarily as SDR
> front ends, the intent being that the "S" part of SDR runs on a
> connected Host, not on the USRP. No software based signal processing
> is done on the USRP, it's all classic digital radio design. For the
> same reason all the intelligence of the device drivers for IC's in the
> X300 is pushed off to the host, and just the physical interfaces
> implemented in the FPGA. The network connection provides the linkage
> between all this host functionality and the FPGA. Thats not to say
> that the chassis couldn't be used as the foundation for a powerful
> standalone SDR, but that is not the FPGA design and support host S/W
> architecture that is supplied as part of the product. Ettus has a
> brand new product aimed directly at standalone operation and thats the
> E310. There is likely no reason why you could not use a very modest
> miniature host running UHD with an X300 for proof of concept style
> work like you are embarking on since you will be dealing with your
> real sample stream on the FPGA….you just need to trick UHD a little so
> it's handling a dummy sample stream of very low bit rate that is just
> discarded - thus avoiding any major S/W changes to UHD.

Yeah, that might be the better option in this case. I will likely pursue
that. However, this all raises one interesting question. What is the
daughterboard's "default" state if it receives no configuration
information on the SPI interface? Is it effectively disabled? Or is
there some default multiplication it does on whatever signal is being
sent out the DAC? As I had mentioned in my other reply, at this point my
carrier frequency is irrelevant. I simply need some sort of measurable
RF output for publication purposes. If that was the case, I could just
dump my I and Q pulses straight into the DAC and get a signal out of the
thing. Once I'm seeing something for collecting data I can start playing
with all these tuning mechanisms.
-- 
	Eddie Carle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141205/994adc0e/attachment.asc>


More information about the USRP-users mailing list