IEEE 802.15.4 Physical Layer Block

Hi Everyone,

Over the last couple of months I developed a IEEE 802.15.4 physical
layer block. It is capable of receiving and transmitting to IEEE
802.15.4 compliant hardware. The block implements the physical layer,
i.e., it can en- and decode the messages. The block itself does not
comply with IEEE 802.15.4 because the timing constraints are just too
small to achieve right now.

Some caveat:

  • You need a fast computer. My P IV 2.8 GHz could barely keep up with
    the data flow.

  • 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.

You can find the code here:
https://acert.ir.bbn.com/projects/gr-ucla/

Please feel free to send me any comments and bug reports :wink:

Cheers,
Thomas

On Tue, Jun 20, 2006 at 10:29:33AM -0700, Thomas S. wrote:

  • You need a fast computer. My P IV 2.8 GHz could barely keep up with
    the data flow.

  • 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

On Tue, Jun 20, 2006 at 10:44:05AM -0700, Eric B. wrote:

On Tue, Jun 20, 2006 at 10:29:33AM -0700, Thomas S. 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

This will be properly fixed when the mblocks are ready.

Eric

On 6/20/06, Eric B. [email protected] wrote:

On Tue, Jun 20, 2006 at 10:44:05AM -0700, Eric B. wrote:

On Tue, Jun 20, 2006 at 10:29:33AM -0700, Thomas S. 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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs