Hi, Guys
I am suddenly a little bit confused about the difference between
usrp.source_s and usrp.source_c. Basically I have two questions:
-
Since the ADC only has 12 bits, does it mean the short integers
entering
the computer have their last four bits as zeros? Or are their first four
digits are zero (the first bit should be the sign)?
-
Is anything interesting done when the short integers converted to
float
values? Or are they simply converted to a different type without
changing
the values?
Thank you~
Dawei
Dawei Shen wrote:
Hi, Guys
I am suddenly a little bit confused about the difference between
usrp.source_s and usrp.source_c. Basically I have two questions:
- Since the ADC only has 12 bits, does it mean the short integers
entering the computer have their last four bits as zeros? Or are their
first four digits are zero (the first bit should be the sign)?
When you decimate a 12-bit signal, more bits of precision are created.
That is why all 16 bits are used.
- Is anything interesting done when the short integers converted to
float values? Or are they simply converted to a different type without
changing the values?
Nothing other than a conversion – Please see the code
(gr-usrp/src/usrp1_source_c.cc):
for (int i = 0; i < nitems; i++){
out[i] = gr_complex ((float) usrp_to_host_short(s16[2i+0]),
(float) usrp_to_host_short(s16[2i+1])); }
Matt
On Fri, Nov 03, 2006 at 06:58:41PM -0500, Dawei Shen wrote:
Hi, Guys
I am suddenly a little bit confused about the difference between
usrp.source_s and usrp.source_c. Basically I have two questions:
- Since the ADC only has 12 bits, does it mean the short integers entering
the computer have their last four bits as zeros? Or are their first four
digits are zero (the first bit should be the sign)?
The short integers entering the computer have been through the DDC and
have been processed as 16-bit ints. Without looking at the verilog
code I don’t recall how they’re adjusted before being clocked into the
DDC.
- Is anything interesting done when the short integers converted to float
values? Or are they simply converted to a different type without changing
the values?
At this point nothing besides the format conversion is done.
There have been some conversations about changing the _c format to be
normalized to +/- 1.0 but the details aren’t worked out yet. We’ll
probably define a new interface so that we don’t break a bunch of
code. The normalization would also be a function of the kind of
daughterboard that’s connected, and will probably factor in some kind
of two-tone IMD performance result.
Eric
On 11/3/06, Eric B. [email protected] wrote:
digits are zero (the first bit should be the sign)?
The short integers entering the computer have been through the DDC and
have been processed as 16-bit ints. Without looking at the verilog
code I don’t recall how they’re adjusted before being clocked into the
DDC.
The 12 bit output form the ADC goes first through the adc_interface.v
module
(check the verilog code if you’d like). Inside that module, the most
significant bit is propagated once to the left and 3 zero bits are
shifted
in from the right. The result is a 16 bit value. That value then goes
through the rx_dcoffset.v module (I don’t know what that does) before
going
to the DDCs in the rx_chain.v module.
I hope that helps.
Oussama.
Thank you guys for your replies. Confusion has been cleared now.
It might have been answered for many many times, but I just wish to
obtain a
quick answer. Recently I have been considering moving some of my work to
FPGA, where is the best place I should start with? (such as the verilog
code…)
Thanks
Dawei
Hi Dawei,
If you want to start working on the FPGA code, you might want to start
with
the top level verilog modue located at
gr-build/usrp/fpga/toplevel/usrp_std.v .
I don’t know what kind of modification to the code you’d like to do but
in
any case you’ll need the Altera Quartus II software.
Attached to this email you’ll find a description of the functionality of
the
FPGA with block diagrams of the different modules. Toward the end of the
document, there is a brief tutorial on how to change the verilog code
and
reprogram the board. (there is actually a slightly easier way to do
that,
but I did it the way I did because it saves a little bit of Hard drive
space
: about 20M.the easier way is to copy the whole usrp file)
There are still some minor details that I will add to that document
later
on.
I hope this document will be helpful.
Let me know if you have any questions.
Oussama.
On Sat, Nov 04, 2006 at 05:10:14PM -0800, Oussama S. wrote:
but I did it the way I did because it saves a little bit of Hard drive space
: about 20M.the easier way is to copy the whole usrp file)
There are still some minor details that I will add to that document later
on.
I hope this document will be helpful.
Let me know if you have any questions.
Oussama.
Hi Oussama,
Thanks for putting the document together.
In the future, please just post a link to the document, so that the
160kB attachment doesn’t come through the list.
Also, there’s no need to edit all the files to change the relative
include path specified in usrp_std.v:
This is not required:
include "/../../../firmware/include/[name].v" will need to be changed toinclude “c:\usrp\include[name].v”
You might have to edit the project property that sets the top of the
include path. Actually I don’t think you should even have to do that,
since I know that Matt and I build this code from different
directories and don’t change anything.
Eric
Hi Eric,
On 11/4/06, Eric B. [email protected] wrote:
Attached to this email you’ll find a description of the functionality of
later
In the future, please just post a link to the document, so that the
160kB attachment doesn’t come through the list.
Sorry about that, I forgot that the attachement was sent to the whole
mailing list.
Also, there’s no need to edit all the files to change the relative
include path. Actually I don’t think you should even have to do that,
since I know that Matt and I build this code from different
directories and don’t change anything.
Eric
Yeah, that’s one of the things I will fix in the document. It’s just
easier
to copy the whole usrp file to the PC. Otherwise, doing it the way I
did, it
wouldn’t compile unless I change the include statements.
Please let me know if you have any other suggestions for changes or
additions to the document.
Thank you,
Oussama.