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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
