cc2520 is not receiving beacon request command packet --pls help

Hi,

please note this forum is about ZigBee TI products based on Z-stack.

We do not support ZigBee stack ports onto Contiki OS in this forum.

Please post your queries here: http://www.contiki-os.org/support.html

Thanks,

TheDarkSide

hi dark

i do know that its for ti products .. i think u didnt read my post properly

i aksed the question regarding the cc2520 rx issue which is a TI product .

Hi,

I understand that the beacon request message sent out by an 802.15.4 packet generator seems not to be detected by your coordinator implementation, which uses a CC2520, a pure radio transceiver from TI.

However, maybe a clarification would need to be made.

First of all, this forum is for questions on TI ZigBee/MAC stack SW products, which are based on OSAL, and use TI-ware stack and drivers.

As you know, since this is a pure transceiver, radio is controlled completely by a piece of SW running on an external MCU. Unfortunately, I can't comment on the CC2520 radio driver you are using: this driver is not delivered by TI. You mentioned in your post are using a ZigBee Contiki port on CC2530. We do not maintain and support ContikiOS port of ZigBee stack (including drivers for our radio that are developed by the community) so you should refer to them to get support on that SW product (again, drivers included).

As a reminder, our official SW products which implement full protocol stacks are made. Therefore, you can find an implementation of radio driver for the CC2520 available here: http://www.ti.com/tool/timac

and here http://www.ti.com/tool/z-stack (if you choose the Z-stack Energy product) that i encourage you to take a look at. The low-level MAC code (ie the SW that control the radio or 'radio driver') is exposed in source so you will find a reference example of how the CC2520 radio is controlled by an external MCU.

The stack can be downloaded freely from the web upon acceptance of the click-wrap end-user license agreement.

All the above being said, I took a look at the packet formatted by your generator and I think the packet is not reflecting the right order as it is supposed to be received by the PHY

Quoting your data:

a 8 3 df ff ff ff ff 7--- Len(1) + fcf(2)+dsn(1)+destaddr(2)+srcpanid(2)+ command id (1)

When 802.15.4 PHY payload for a beacon request should instead be 

03 08 dsn(1) ff ff ff ff 7 crc(2), whereas length is still 10. Please note 'a' is the length field of the PHY payload, which is 10 including the CRC for a beacon request. 'a' is not part of the PHY payload, it is in the PHY header.

In fact, please check the following excerpt of 802.15.4 spec, section 7.2 MAC frame formats which clarifies the order for MAC frames

"in this subclause are depicted in the order in which they are transmitted by the PHY, from left to right, where
the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost and least
significant) to k – 1 (rightmost and most significant), where the length of the field is k bits. Fields that are
longer than a single octet are sent to the PHY in the order from the octet containing the lowest numbered bits
to the octet containing the highest numbered bits

Frame control field is 2 octets (please see 7.2.1.1 of the same spec): the first byte, which contains the frame type info (bit 0 and bit 1 of the 16 bit frame control field) should be transmitted before the second byte to the PHY. 

Last but not least, please note we have a separate forum for all radio transceiver related questions and HW questions, for devices like CC2520, called  Low Power RF Hardware & Tools Forum

I hope this clarifies everything.

Thanks for choosing TI parts for your designs.

TheDarkSide