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, <[EMAIL PROTECTED]> wrote: > Send Discuss-gnuradio mailing list submissions to > [email protected] > > 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 > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > 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" <[EMAIL PROTECTED]> > Subject: [Discuss-gnuradio] Trondeau C++ daughterboard code > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Trondeau C++ daughterboard code > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > 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/<http://www.kawo1.rwth-aachen.de/%7Elurchi/> > phone: +49 241 53809034 mobile: +49 151 50412019 > > > > > ------------------------------ > > Message: 3 > Date: Mon, 6 Oct 2008 10:39:39 -0700 > From: Eric Blossom <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Gnuradio block behaves > strange.....please have a look at this > To: Murtuza <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Trondeau C++ daughterboard code > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > 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/<http://www.kawo1.rwth-aachen.de/%7Elurchi/> > 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 <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Trondeau C++ daughterboard code > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > 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/<http://www.kawo1.rwth-aachen.de/%7Elurchi/> > 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 <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Gnuradio block behaves > strange.....please have a look at this > To: "Eric Blossom" <[EMAIL PROTECTED]>, [email protected] > Message-ID: > <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > End of Discuss-gnuradio Digest, Vol 71, Issue 14 > ************************************************ >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
