Hi List,
what is the MSB on USB bus between USRP and the host?
Davide “Rocker” Anastasia
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
On Thu, Mar 15, 2007 at 11:16:03AM +0100, Davide A. wrote:
Hi List,
what is the MSB on USB bus between USRP and the host?Regards,
Davide “Rocker” Anastasia
Data is passed across the USB in little-endian byte order.
Eric
Il giorno gio, 15/03/2007 alle 07.12 -0700, Eric B. ha scritto:
On Thu, Mar 15, 2007 at 11:16:03AM +0100, Davide A. wrote:
Hi List,
what is the MSB on USB bus between USRP and the host?Data is passed across the USB in little-endian byte order.
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
On Thu, Mar 15, 2007 at 03:20:43PM +0100, Davide A. wrote:
Il giorno gio, 15/03/2007 alle 07.12 -0700, Eric B. ha scritto:
On Thu, Mar 15, 2007 at 11:16:03AM +0100, Davide A. wrote:
Hi List,
what is the MSB on USB bus between USRP and the host?Data is passed across the USB in little-endian byte order.
So, If I need to give the sign of a sample, I’ll take the most left bit?
Davide A.
Davide,
In the code that we distribute, yes. However, I think you’re asking
about the code that you have been modifying in the FPGA. You’re in
charge of that part. What are you doing?
In the unmodified code, we push 16-bit I & Q across the interface to
the FX2 and from there to the host. The data comes out I first, then
Q, and each 16-bit value is little-endian byte order.
Hope this helped.
Eric
Il giorno gio, 15/03/2007 alle 08.10 -0700, Eric B. ha scritto:
Davide,
In the code that we distribute, yes. However, I think you’re asking
about the code that you have been modifying in the FPGA. You’re in
charge of that part. What are you doing?
I’m working on usrp1_source_s.cc to obtain an unpacked stream of 1 bit
samples into char variables (no changes for short). So, if I have 1, I
wish to use 0x00000001 and 0x00000000 for 0 value. I guess it is
reasonable, because after I can use unpacked_to_packed and
packed_to_unpacked to obtain a stream of bit of byte. I fault?
In the unmodified code, we push 16-bit I & Q across the interface to
the FX2 and from there to the host. The data comes out I first, then
Q, and each 16-bit value is little-endian byte order.
Because Peter M.’ patch use a mask like this 16’b0000000000000001, I
need to give to a 16 bit sample a 15 bit shift to take the SIGN. Isn’t
it??
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
On Thu, Mar 15, 2007 at 04:36:56PM +0100, Davide A. wrote:
reasonable, because after I can use unpacked_to_packed and
Regards,Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
I Davide,
I think you’ll find it easier to do the unpacking in a separate block
downstream from the usrp1_source_s. Modifying usrp1_source* to handle
samples smaller than 1 byte is going to take quite a bit of work. Part
of the problem is that the code is written in terms of functions such
as sizeof_basic_sample() which returns a size in bytes. In your case,
your basic sample is smaller than a byte. The current code doesn’t
know how to deal with that.
After unpacking, what representation do you want for your samples?
If bytes containing 1-bit per byte are OK, then perhaps the easiest
approach is to create a gr_packed_to_unpacked_sb.*
You should be able to do this by changing:
others = (
(‘gr_chunks_to_symbols_XX’, (‘bf’, ‘bc’, ‘sf’, ‘sc’, ‘if’,
‘ic’)),
(‘gr_unpacked_to_packed_XX’, (‘bb’,‘ss’,‘ii’)),
(‘gr_packed_to_unpacked_XX’, (‘bb’,‘ss’,‘ii’))
)
to
others = (
(‘gr_chunks_to_symbols_XX’, (‘bf’, ‘bc’, ‘sf’, ‘sc’, ‘if’,
‘ic’)),
(‘gr_unpacked_to_packed_XX’, (‘bb’,‘ss’,‘ii’)),
(‘gr_packed_to_unpacked_XX’, (‘bb’,‘ss’,‘ii’, ‘sb’))
)
in gnuradio-core/src/lib/gengen/generate_common.py
On the other hand, I assume that ultimately these end up as some kind
of complex data type, so perhaps some other kind of mapping to
gr_complex would be useful.
Eric
Il giorno gio, 15/03/2007 alle 12.17 -0700, Eric B. ha scritto:
I think you’ll find it easier to do the unpacking in a separate block
downstream from the usrp1_source_s. Modifying usrp1_source* to handle
samples smaller than 1 byte is going to take quite a bit of work.
Part of the problem is that the code is written in terms of functions
such as sizeof_basic_sample() which returns a size in bytes. In your
case,your basic sample is smaller than a byte. The current code
doesn’t know how to deal with that.
I can use the “format()” function to obtain the width of the sample.
Actually I’m using this way:
case 1:
for (int i = 0; i < nitems; i++){
switch ( format() ) {
case 1:
out[i] = usrp_to_host_short(s16[i]);
// temp = 0 | s8[i] << 8;
// i++;
// out[i] = temp | s8[i]; // Si può fare?
break;
case 2:
out[i] = s8[i] << 14;
break;
case 4:
out[i] = s8[i] << 12;
break;
case 8:
default:
out[i] = s8[i] << 8;
}
}
break;
I change sizeof_basic_sample() in order to return 1 with samples smaller
than a byte. I written a little C++ program to obtain from a 1 bit
stream a table (#, value{0 or 1}). I think it can been reused to create
a module, which take a stream and return a 16 bit sample per bit.
After unpacking, what representation do you want for your samples?
I guess a simple continuos stream of bit is enough.
('gr_unpacked_to_packed_XX', ('bb','ss','ii')), ('gr_unpacked_to_packed_XX', ('bb','ss','ii')), ('gr_packed_to_unpacked_XX', ('bb','ss','ii', 'sb')) )in gnuradio-core/src/lib/gengen/generate_common.py
“b” stays for byte or bit?
On the other hand, I assume that ultimately these end up as some kind
of complex data type, so perhaps some other kind of mapping to
gr_complex would be useful.
–
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
Il giorno gio, 15/03/2007 alle 12.17 -0700, Eric B. ha scritto:
I think you’ll find it easier to do the unpacking in a separate block
downstream from the usrp1_source_s. Modifying usrp1_source* to handle
samples smaller than 1 byte is going to take quite a bit of work.
Part of the problem is that the code is written in terms of functions
such as sizeof_basic_sample() which returns a size in bytes. In your
case, your basic sample is smaller than a byte. The current code
doesn’t know how to deal with that.
I’m think about this question since I turn on my PC today. 
Ok, I receive from USRP a stream of samples. They are raw, not packed.
So, if I use a 1 bit quantization, I have 8 samples in a byte; with 2
bit, 4 samples… and so on! But any module in GNU radio uses only char,
short, gr_complex (std::complex, is the same?). If I change
usrp1_source* to return always * samples, I reach my purpose. And then,
after usrp1_source*, I can use every module in the library I need.
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
On Fri, Mar 16, 2007 at 01:26:08PM +0100, Davide A. wrote:
Ok, I receive from USRP a stream of samples. They are raw, not packed.
web: http://www.davideanastasia.com/
email: [email protected]
No particular fault. However, the outputs from the USRP are almost
always some kind of complex values. They may be encoded as 16-bit I &
Q, or 8-bit I & Q or 4-bit or 2-bit or 1-bit. The question is how do
we want to deal with them downstream from the USRP? The existing
usrp.source_s could be considered broken (although there are users of
it.) The data is really interleaved 16-bit I & Q, though it’s
presented as if each sample was only 16-bits wide. In fact a “sample”
is really composed of 2 16-bit values.
One way to approach this is to modify usrp.source_c so that it
internally handles the format conversion, and always produces
gr_complex as its output type.
When dealing with 1 bit samples, there is the question of whether you
want to treat them as -1, +1 or 0, +1. I suspect that -1, +1 makes
more sense, but on the other hand, treating them as -32767, 32767
would be consistent with how the 8-bit samples are handled. That is,
they are multiplied by 256 so that they fill the same range as the
“normal” 16-bit I & Q.
Another thought is to define a new complex interface that always
returns values normalized to [-1.0, +1.0].
Eric
No particular fault. However, the outputs from the USRP are almost
always some kind of complex values. They may be encoded as 16-bit I &
Q, or 8-bit I & Q or 4-bit or 2-bit or 1-bit. The question is how do
we want to deal with them downstream from the USRP? The existing
usrp.source_s could be considered broken (although there are users of
it.) The data is really interleaved 16-bit I & Q, though it’s
presented as if each sample was only 16-bits wide. In fact a “sample”
is really composed of 2 16-bit values.
Maybe we should make gr_complex_short be a typedef for complex
and output those.
Matt
Il giorno lun, 19/03/2007 alle 10.55 -0700, Matt E. ha scritto:
Maybe we should make gr_complex_short be a typedef for
complex
and output those.
Yep, in this way std::complex make conversion between float and short
transparently. Ok, I’ll work in this direction. Actually I’m working on
usrp1_source_s.cc. I’ll send you my work when is completed, tested and
fully working. Soon maybe.
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
Hi List,
again at work…
Il giorno ven, 16/03/2007 alle 14.05 -0700, Eric B. ha scritto:
One way to approach this is to modify usrp.source_c so that it
internally handles the format conversion, and always produces
gr_complex as its output type.
As I plan to do.
When dealing with 1 bit samples, there is the question of whether you
want to treat them as -1, +1 or 0, +1. I suspect that -1, +1 makes
more sense, but on the other hand, treating them as -32767, 32767
would be consistent with how the 8-bit samples are handled. That is,
they are multiplied by 256 so that they fill the same range as the
“normal” 16-bit I & Q.
I don’t know which representation is better, but I think that changing
it after the code is written is really simple.
Another thought is to define a new complex interface that always
returns values normalized to [-1.0, +1.0].
Why not a new module? I think a new module (called gr_vector_normalizer,
maybe?) is the best solution to preserve the generality of the library.
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
On Mon, Mar 19, 2007 at 10:55:46AM -0700, Matt E. wrote:
Maybe we should make gr_complex_short be a typedef for complex
and output those.Matt
That would make sense.
We’d need to come up with some kind of unambiguous naming convention
for the variants.
Eric
Il giorno mar, 20/03/2007 alle 10.09 +0100, Davide A. ha scritto:
Regards,
Hi List,
I attach to this mail the works I’ve done on the gr-usrp driver, in
special way on usrp1_source_s. It’s not a very beautiful code, but work!
Any suggestion is appreciate.
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
Il giorno gio, 22/03/2007 alle 12.14 +0100, Davide A. ha scritto:
Regards,
Hi List,
I attach to this mail the works I’ve done on the gr-usrp driver, in
special way on usrp1_source_s. It’s not a very beautiful code, but work!
Any suggestion is appreciate.
Attached there is a cumulative patch, which contains my mods for width
sample settings on usrp1_source_c.* and usrp1_source_s.*.
I tested it with usrp_fft.py and usrp_rx_cfile.py (with some mode I
made. Let me know if you need they.). They work nicely! 
In usrp1_source_c I still use the standard gr_complex, but I little
modification is needed to use a new gr_complex_short, if added to
complex.h.
Davide A.
web: http://www.davideanastasia.com/
email: [email protected]
Hi,
You can use decimation and a rational_resampler block.
If you really need to change the clock read this:
http://www.comsec.com/wiki?USRPClockingNotes
It explains how to use an external clock source with the usrp. I was
able
to use a 38.4MHz clock with the usrp from a signal generator. It seemed
to
work fine, so I bought a new 38.4MHz tcvcxo and installed it on the
board.
I hope that helps you,
Hans
----- Original Message -----
From: “eenrti” [email protected]
Cc: “Matt E.” [email protected]; “Eric B.” [email protected];
“gnuradio
mailing list” [email protected]
Sent: Monday, March 26, 2007 10:00 AM
Subject: [Discuss-gnuradio] Sampling rate of USRP board
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Hello,
I have recently purchased the USRP board and the RX daughterboard, and I
have started working on them.
One major factor that I need to change is the sampling rate frequency of
the ADCs on USRP, I know the USRP clock is at 64MSPS and I need to
reduce it to at least half of it.
My question is two fold, should I decimate the digitization, or is there
any other way of doing that? How difficult would be to change the clock?
And can someone confirm that the USRP can accept an external clock? If
yes do I need to have some hardware adjustments?
Please excuse me if I repeat an older thread, it would be nice to guide
me there. I think that it might could be a good idea to have some kind
of forum, with different parts dedicated to USRP.
Regards
Rigas Ioannides
Hello,
I have used a sinusoidal signal generator to test my USRP output stream
using a single or even the teo inputs to the RX daughterboard.
I suppose there are 4 channels at the end when I use both RX
daughterboard inputs, for I and Q so I tried to separate my output data
by using a 4 sample interleaving but it does not seem I can reconstruct
my input sinusoidal signal at all.
I have really a difficult time to decode the output data stream, I know
there is some kind of interleaving process, but I cannot speculate what
that is, can you please let me know of a reference or of a webpage or if
someone can tell me how to separate my output data for each channel?
Thank you
Rigas
Hello,
I have used a sinusoidal signal generator to test my USRP output stream
using a single or even the teo inputs to the RX daughterboard.
I suppose there are 4 channels at the end when I use both RX
daughterboard inputs, for I and Q so I tried to separate my output data
by using a 4 sample interleaving but it does not seem I can reconstruct
my input sinusoidal signal at all.
I have really a difficult time to decode the output data stream, I know
there is some kind of interleaving process, but I cannot speculate what
that is, can you please let me know of a reference or of a webpage or if
someone can tell me how to separate my output data for each channel?
Thank you
Rigas
Rigas,
It is not necessary to cc: Eric and me when sending a message to the GNU
Radio mailing list, since we are on the list. Sending 2 copies of your
message in 15 minutes is also not necessary.
of a webpage or if someone can tell me how to separate my output data
for each channel?
You need to send some code so we can tell you what you are doing wrong.
But the basics are : You need to tell the usrp source how many streams
you want. You need to set up the mux properly. If you want 4 streams,
you need to use the alternate rbf file.
Matt
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs