Re: [Discuss-gnuradio] IEEE 802.15.4 Physical Layer Block

[Thomas Schmid]

On 6/20/06, Eric Blossom <address@hidden> wrote:
> On Tue, Jun 20, 2006 at 10:44:05AM -0700, Eric Blossom wrote:
> > On Tue, Jun 20, 2006 at 10:29:33AM -0700, Thomas Schmid wrote:
> > > Hi Everyone,
> > >
> > > - Right now, we need to send an additional 100 byte at the end of each
> > > message or else, the other side can not decode them. Still figuring
> > > out why that is.
> >
> > Probably not padded out to a USB boundary.  See the kludge in packet_utils.py

I thought so, but searching in packet_utils.py I figured out that this
can not be the case. Here my reasoning:
- IEEE 802.15.4 does spreading, i.e., each data byte gets spread to 64 bit
- I then upsample by 2 to get nyquist rate
- Each sample is 16 bit (i.e. 2 byte), thus we get the 512 byte for
the usb packet

In short, each data byte will yield one usb packet.

I experimented a little bit further and found that when I don't pad at
the end of the message, then the bytes received at the receiver are
not correctly synchronized and thus, at some point, I get an error in
despreading. The 100 bytes I mentioned before are from an earlier
experiment where my packets were smaller. I now use a packet with 28
bytes and need to pad it with 50x 0 bytes and the packets get received
correctly by a CC2420 radio chip and my GnuRadio code. If I don't zero
pad, or if I zero pad with a smaller amount (like 5x 0 bytes) then,
the packet gets received by my GNURadio code, though the bytes are
wrong (so, there is stuff sent out), but the CC2420 fails since the
CRC at the end is wrong. This shows me, that the problem must be on
the sending side, not the receiving...

Any ideas why that could happen? Are there any other buffers in the
FPGA I have to take care of, i.e., needs to be flushed?

Cheers,
Thomas

> This will be properly fixed when the mblocks are ready.
>
> Eric