Hi all
I've doing some research with the IEEE 802.15.4 TinyOS Implementation (TKN154)
whose libs are located at "/tos/lib/mac/tkn154" and test applications at
"/apps/tests/tkn154" directories. I am aware that the majority of the community
research do not work with this, but I appreciate all the help possible.
In particular, I'm trying to send a broadcast data frame employing the IEEE
802.15.4 non-beacon enabled mode. To to this, I've been working with the
TestIndirectData application (/apps/tests/tkn154/TestIndirectData/coordinator).
As the README.txt file indicates, "In this application one node takes the role
of a PAN coordinator in a nonbeacon-enabled 802.15.4 PAN, every 3 seconds it
sends a packet to a device using indirect transmission (i.e. the packet is
buffered until it is polled by the device). A second node acts as the device,
it switches to the pre-definedchannel and polls the coordinator every 1 second
for outstanding indirect transmissions." I've tested the application and it
works fine. However, I've changed two things in the code in order to send
broadcast frames instead unicast frames as follows (changes in bold):
------------------------
void sendIndirectData(){
ieee154_address_t deviceAddress; // deviceAddress.shortAddress =
DEVICE_ADDRESS; deviceAddress.shortAddress = 0xFFFF; call
Frame.setAddressingFields( &frame,
ADDR_MODE_SHORT_ADDRESS, // SrcAddrMode,
ADDR_MODE_SHORT_ADDRESS, // DstAddrMode,
PAN_ID, // DstPANId,
&deviceAddress, // DstAddr, NULL
// security ); /* call
MCPS_DATA.request( &frame,
// frame, strlen(payload), //
payloadLength, 0,
// msduHandle, TX_OPTIONS_INDIRECT | TX_OPTIONS_ACK
// TxOptions, ); */ status_t = call
MCPS_DATA.request( &frame,
// frame, strlen(payload), //
payloadLength, 0,
// msduHandle, TX_OPTIONS_INDIRECT // TxOptions,
); call Leds.led1On(); call
Led1Timer.startOneShot(12500U); }------------------------
When I tested the application, it didn't work when it was supposed to. For this
reason I've been checking the code looking for the problem. Firstly, the event
MCPS_DATA.confirm was never signaled. So I checked the return value of
MCPS_DATA.request (status_t) and its value was always
IEEE154_INVALID_PARAMETER. Following with the tests, I checked the DataP.nc
file (/tos/lib/mac/tkn154/DataP.nc) where the MCPS_DATA.request is implemented.
In that file, when the transmission options are equal to TX_OPTIONS_INDIRECT,
and the device address is equal to 0xFFFF, it does the following call:
------------------------
txStatus = call BroadcastTx.transmit(txFrame);------------------------
what it is fine but to my astonishment, when I checked that function which is
implemented at the bottom of the same file, I realized that the return value
was due to:
------------------------
default command ieee154_status_t BroadcastTx.transmit(ieee154_txframe_t *data)
{ return IEEE154_INVALID_PARAMETER;}------------------------
Therefore, the broadcast transmission is not implemented by default.
Taking into account the aforementioned, Does (or did) anybody have this same
problem? How can I solve it? Any ideas? What portion of code shoud I add?
Thanks a lot
David
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
