Hi Jan Thanks a lot for your reply. You are right! It has no sense doing an indirect broadcast transmission. What I just wanted to do is a broadcast transmission employing the unslotted IEEE 8021.5.4 csma-ca. For this reason, what it seems to me is that I am not using the correct transmission options in the MCPS_DATA.request function. That filed should be zero what means a direct broadcast transmission. I'll check that and see if it is works. Again, thanks a lot for your help! David > Date: Tue, 17 Apr 2012 15:09:10 +0200 > Subject: Re: [Tinyos-help] IEEE 802.15.4 Implementation and broadcast > transmission > From: [email protected] > To: [email protected] > CC: [email protected] > > 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
