Hi David, > 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: [...] > Therefore, the broadcast transmission is not implemented by default.
A default is called when no component is wired. In nonbeacon-enabled mode indeed no component is wired, so the default is executed and you get an error code. This was likely done, because I'm not quite sure what indirect transmission using a broadcast address in nonbeacon-enabled mode actually means (maybe you can give your interpretation?). The standard (IEEE 802.15.4-2006) says in Sect. 7.1.1.1.3: "If the TxOptions parameter specifies that an indirect transmission is required and this primitive is received by the MAC sublayer of a coordinator, the data frame is sent using indirect transmission, i.e., the data frame is added to the list of pending transactions stored on the coordinator and extracted at the discretion of the device concerned using the method described in 7.5.6.3. Transactions with a broadcast destination address will be transmitted using the mechanism described in 7.2.1.1.3.". Unfortunately Sect. 7.2.1.1.3 does not describe any mechanism (it just defines the use of the frame pending bit) ... One interpretation could be: the coordinator stores the packet and any device that asks for the data via POLL will get the packet. The problem with that approach is: when would you remove the packet from the coordinator's queue (after macTransactionPersistenceTime)? BTW, make sure you're using the latest code from SVN (http://code.google.com/p/tinyos-main/). Thanks, Jan On Tue, Apr 17, 2012 at 10:39 AM, David Rodenas <[email protected]> wrote: > 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-defined > channel 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 _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
