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