Hi again I was totally wrong!! I respond to myself in case anyone had this problem/mistake in the future. When a PAN works in nonbeacon-enabled mode, nodes must set the macRxOnWhenIdle parameter to one in order to be able to receive data (unicast, broadcast...) and acknowledge it accordingly (when necessary). Therefore, I don't have to use the promiscuous mode to receive whatever, just because the transmitter is not ON, only the receiver circuitry. I should read more carefully the IEEE 802.15.4 standard for the next time! Anyway, thanks! David
From: [email protected] To: [email protected] Date: Thu, 17 May 2012 11:27:44 +0000 Subject: [Tinyos-help] TKN15.4 issue: problem receiving ack Hi all I am working with the TKN15.4 libraries, the TinyOS implementation of the IEEE 802.15.4 standard. In particular, I am doing some tests with the non-beacon mode of this implementation. I've modified the TestIndirectData app (tinyos-2.x/apps/tests/tkn154/nonbeacon-enabled/TestIndirectData) aimed at performing a direct transmission instead of an indirect transmission. In this sense, I've done the following (a few) changes in the code: 1) The device acts as receiver node. It does not perform any polling process, only switches to receiver state (promiscuous mode) listening to incomming transmissions. TestIndirectDataDeviceAppC.nc----------------------------------------configuration TestIndirectDataDeviceAppC{} implementation { [...] App.PromiscuousMode -> MAC; //add}---------------------------------------- TestIndirectDataDeviceC.nc----------------------------------------module TestIndirectDataDeviceC{ uses { [...] interface SplitControl as PromiscuousMode; //add }} implementation { [...] void startApp() { [...] // call PollTimer.startPeriodic(62500U); call PromiscuousMode.start(); // add } [...] //<add> event void PromiscuousMode.startDone(error_t error) { } event void PromiscuousMode.stopDone(error_t error) { } //</add> }---------------------------------------- 2) The coordinator is who transmits data. Only modifications of txOptions in the MCPS_DATA.request has been done: TestIndirectDataCoordC.nc----------------------------------------module TestIndirectDataDeviceC{} implementation { [...] void sendIndirectData(){ [...] call MCPS_DATA.request( &frame, // frame, strlen(payload), // payloadLength, 0, // msduHandle, // TX_OPTIONS_INDIRECT | TX_OPTIONS_ACK // TxOptions, TX_OPTIONS_ACK // TxOptions, ); [...] } [...] event void MCPS_DATA.confirm( message_t *msg, uint8_t msduHandle, ieee154_status_t status, uint32_t Timestamp ) { [...] //<add> else if(status == IEEE154_NO_ACK) { call Leds.led2On(); } //</add> }[...] }---------------------------------------- Taking in account the aforementioned, the message is actually received by the device, but coordinator's led2On indicates to me that any ack has been transmitted or received. What am I doing wrong? All the help possible would be appreciated. Thanks! 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
