discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 71, Issue 14


From: birjodh tiwana
Subject: [Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 71, Issue 14
Date: Mon, 6 Oct 2008 23:17:46 -0400

Hi All,

I am trying to migrate my code for a program fro hier_block to hier_block1. I know some details.
Any suggestions? I couldn't found a good page for this in  gnuradio Wiki.

Best
Birjodh


On Mon, Oct 6, 2008 at 5:20 PM, <address@hidden> wrote:
Send Discuss-gnuradio mailing list submissions to
       address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
       http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
       address@hidden

You can reach the person managing the list at
       address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

  1. Trondeau C++ daughterboard code (Per Zetterberg)
  2. Re: Trondeau C++ daughterboard code (Stefan Br?ns)
  3. Re: Gnuradio block behaves strange.....please     have a look at
     this (Eric Blossom)
  4. Re: Trondeau C++ daughterboard code (Stefan Br?ns)
  5. Re: Trondeau C++ daughterboard code (Stefan Br?ns)
  6. Re: Gnuradio block behaves strange.....please have        a look at
     this (Murtuza)


----------------------------------------------------------------------

Message: 1
Date: Mon, 6 Oct 2008 18:02:29 +0200
From: "Per Zetterberg" <address@hidden>
Subject: [Discuss-gnuradio] Trondeau C++ daughterboard code
To: <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain;       charset="us-ascii"


Dear All,

I am trying to migrate from home-made daughterboard code to the code by
Trondeau. I am using the version 9305. I use  db_flexrf_1800_tx_mimo_b.
After changing "d_common->R_DIV(1)" to "d_common->R_DIV(16)" the signal is
showing up on my spectrum analyzer at the correct frequency. However, the
amplitude is about 25dB weaker than when using the home-made daughterboard
code. I am using the daughterboard code as given by the code fragment below.
Does anyone have an idea what could be wrong ?


BR/
Per

usrp_standard_tx* tx = usrp_standard_tx::make(0,64,2,47768);
std::vector<db_base_sptr> db_rx0,db_rx1,db_tx0,db_tx1;

db_tx0=tx->db(0);
db_tx1=tx->db(1);


db_tx0[0]->set_lo_offset(tx_lo_offset);
tr=db_tx0[0]->tune(0,carrier_frequency);

db_tx0[0]->set_enable(true);
db_tx0[0]->set_gain(db_tx0[0]->gain_max());









------------------------------

Message: 2
Date: Mon, 06 Oct 2008 19:31:04 +0200
From: Stefan Br?ns <address@hidden>
Subject: Re: [Discuss-gnuradio] Trondeau C++ daughterboard code
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=iso-8859-1

On Monday 06 October 2008 18:02:29 Per Zetterberg wrote:
> Dear All,
>
> I am trying to migrate from home-made daughterboard code to the code by
> Trondeau. I am using the version 9305. I use  db_flexrf_1800_tx_mimo_b.
> After changing "d_common->R_DIV(1)" to "d_common->R_DIV(16)" the signal is
> showing up on my spectrum analyzer at the correct frequency. However, the
> amplitude is about 25dB weaker than when using the home-made daughterboard
> code. I am using the daughterboard code as given by the code fragment
> below. Does anyone have an idea what could be wrong ?

The DB code sets the gain in the 9862 to the wrong value (there is something
wrong with the calculation of the register value from the gain in db) - this
may be fixed in the cppdb feature branch.

Stefan

--
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
mailto:lurch at gmx.li  http://www.kawo1.rwth-aachen.de/~lurchi/
  phone: +49 241 53809034     mobile: +49 151 50412019




------------------------------

Message: 3
Date: Mon, 6 Oct 2008 10:39:39 -0700
From: Eric Blossom <address@hidden>
Subject: Re: [Discuss-gnuradio] Gnuradio block behaves
       strange.....please      have a look at this
To: Murtuza <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On Sun, Oct 05, 2008 at 04:23:10AM -0500, Murtuza wrote:
> Hi Eric
>
> I did exactly as you told me to do but still I face the same problem. I use
> gr.packed_to_unpacked_bb(1,gr.GR_LSB_FIRST) to send one bit each time but I
> still find some data missing in the destination file.

What, where, and how much data is missing?  Is the data incorrect, or
are there gaps, or zeros, or what?  You not giving us much to work with...

Eric




------------------------------

Message: 4
Date: Mon, 06 Oct 2008 20:30:36 +0200
From: Stefan Br?ns <address@hidden>
Subject: Re: [Discuss-gnuradio] Trondeau C++ daughterboard code
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On Monday 06 October 2008 19:31:04 Stefan Brüns wrote:
> The DB code sets the gain in the 9862 to the wrong value (there is
> something wrong with the calculation of the register value from the gain in
> db) - this may be fixed in the cppdb feature branch.

Patch attached.

Stefan

--
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
mailto:lurch at gmx.li  http://www.kawo1.rwth-aachen.de/~lurchi/
  phone: +49 241 53809034     mobile: +49 151 50412019
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp_pga-fix.diff
Type: text/x-diff
Size: 1926 bytes
Desc: not available
Url : http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20081006/4de133cb/usrp_pga-fix.bin

------------------------------

Message: 5
Date: Mon, 06 Oct 2008 20:35:59 +0200
From: Stefan Br?ns <address@hidden>
Subject: Re: [Discuss-gnuradio] Trondeau C++ daughterboard code
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

On Monday 06 October 2008 20:30:36 Stefan Brüns wrote:
> On Monday 06 October 2008 19:31:04 Stefan Brüns wrote:
> > The DB code sets the gain in the 9862 to the wrong value (there is
> > something wrong with the calculation of the register value from the gain
> > in db) - this may be fixed in the cppdb feature branch.
>
> Patch attached.
>
> Stefan

Sorry, wrong one, only the last hunk is the correct part.

Attached again.

Stefan

--
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
mailto:lurch at gmx.li  http://www.kawo1.rwth-aachen.de/~lurchi/
  phone: +49 241 53809034     mobile: +49 151 50412019
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp_pga-fix.diff
Type: text/x-diff
Size: 629 bytes
Desc: not available
Url : http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20081006/ad5f552d/usrp_pga-fix.bin

------------------------------

Message: 6
Date: Mon, 6 Oct 2008 16:20:35 -0500
From: Murtuza <address@hidden>
Subject: Re: [Discuss-gnuradio] Gnuradio block behaves
       strange.....please have a look at this
To: "Eric Blossom" <address@hidden>, address@hidden
Message-ID:
       <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Hi Eric ,

This is the detail.

File source : I have a binary file with only one byte in it. The byte value
is 0x5B in hex.
PN Sequence : By using
                        c = gr.glfsr_source_b(3,True,0x05,0x01)
                        d = gr.glfsr_source_b(3,True,0x06,0x01)
as the m-sequence generators and XORing them together I get a gold-code
sequence of [ 0 1 0 1 0 0 0 ],which when written in HEX should appear as
[00 01 00 01 00 00 00 ] as the sequence of inputs on the input_stream[0] of
the spread.spreading_blk_b.

As I am reading the data repeatedly from file_source and unpacking it
bit-by-bit using gr.packed_to_unpacked_bb(1,gr.GR_LSB_FIRST) the input on
input_stream[1] is sequence of either 0x01 or 0x00. In my case one full
sequence of a byte should look like this in HEX at the input_Stream[1]  -->
[01 01 00 01  01 00 01 00] which is 0x5B with the first entry representing
the LSB of 0x5B .

For each input on input_stream[1] I must get 7 items on output_stream which
is the gold-code sequence. If I have 0x01  on input_stream[1] I must get [00
01 00 01 00 00 00 ] and if I have 0x00 on input_stream[1] I must get [01 00
01 00 01 01 01] which is the complement of the PN-sequence.

I check the output_stream on stdout and the values for out[i] each time is
exactly as it has to be. But the data written to the file is not right. This
is the data in the output file. The gr.file_sink block takes output from the
spread.spreading_blk_b block as the input. This is the data I got in the
output file in HEX (arranged in blocks of length of PN-sequence = 2^3 - 1 =
7)

00 00 01 00 00 01 00   01 00 00 01 00 00 01
00 01 00 00 01 01 01   00 01 00 00 00 00 00
00 00 00 00 00 00 01   01 01 01 00 01 00 00
00 01 01 01 00 01 00   00 00 00 00 00 00 00
00 01 01 01 01 01 00   00 00 00 00 01 01 00
01 00 00 00 00 01 00   01 00 01 01 00 00 00
00 00 01 01 01 01 00   01 00 00 01 00 01 00
00 00 00 00 01 00 01   01 00 00 00 00 01 01
01 01 00 00 00 00 00   01 01 00 01 00 01 00
00 01  . . . . . . .

Clearly, this data is not right as I must either get a complete PN-sequence
or the complement of it. The data observed above doesn't show [00 01 00 01
00 00 00 ] (output when input is 0x01)or [ 01 00 01 00 01 01 01](output when
input is 0x00). The correct data should look as shown below for 1-byte of
input i.e. 8 items on input_stream[1].

00 01 00 01 00 00 00     00 01 00 01 00 00 00
01 00 01 00 01 01 01     00 01 00 01 00 00 00
00 01 00 01 00 00 00     01 00 01 00 01 01 01
00 01 00 01 00 00 00     01 00 01 00 01 01 01

I hope this information is good enough for you to help me. Do you want me to
send my files as a ".tar.gz" compressed file ?

This is what I do in Python(mentioning it again)

>>> from gnuradio import gr,spread
>>> a=gr.file_source(gr.sizeof_char,"/home/murtuza/f",True)
>>> b=gr.packed_to_unpacked_bb(1,gr.GR_LSB_FIRST)
>>> c=gr.glfsr_source_b(3,True,0x05,0x01)
>>> d=gr.glfsr_source_b(3,True,0x06,0x01)
>>> x=gr.xor_bb()
>>> s=spread.spreading_blk_b(3)
>>> ds=gr.file_sink(gr.sizeof_char,"/home/murtuza/newf")
>>> t=gr.top_block()
>>> t.connect(a,b)
>>> t.connect(b,(s,1))
>>> t.connect(c,(x,0))
>>> t.connect(d,(x,1))
>>> t.connect(x,(s,0))
>>> t.connect(s,ds)
>>> t.start()


Thanks once again,
Ali



On Mon, Oct 6, 2008 at 12:39 PM, Eric Blossom <address@hidden> wrote:

> On Sun, Oct 05, 2008 at 04:23:10AM -0500, Murtuza wrote:
> > Hi Eric
> >
> > I did exactly as you told me to do but still I face the same problem. I
> use
> > gr.packed_to_unpacked_bb(1,gr.GR_LSB_FIRST) to send one bit each time but
> I
> > still find some data missing in the destination file.
>
> What, where, and how much data is missing?  Is the data incorrect, or
> are there gaps, or zeros, or what?  You not giving us much to work with...
>
> Eric
>



--
Mir Murtuza Ali
Graduate Student
Center for Wireless Communications
University of Mississippi
University, MS 38677
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20081006/c24fce5b/attachment.html

------------------------------

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


End of Discuss-gnuradio Digest, Vol 71, Issue 14
************************************************


reply via email to

[Prev in Thread] Current Thread [Next in Thread]