Hello David, I am glad that you were able to help yourself, nevertheless I wanted to add a few points to make things more clear in case they are still a little foggy.
You are absolutely right, that you have to activate the receiving mode explicitly because of the fact that a device is assumed to have very strong energy constraints and is supposed to safe as much power as possible. Therefore you usually perform a poll whenever you want to check if the coordinator has new messages for you. I didn't understand exactly what you meant by saying that 'the transmitter is not ON'. Basically the transmit and receive circuitries are the same anyway and in any case the transmitter only gets involved and activated when you (or the mac) send messages. During the rest of the time it can either be disabled or in receiving mode (when explicitly activated). There is btw also another routine that activates the receive mode for a given time. This function is accessiable via MLME_RX_ENABLE interface. Finally, as you already figured out, the promiscuous mode is only deactivating a filter, letting messages pass that were not meant for you in the first place (like different address of PAN Id). In case of anything being still unclear don't hesitate to ask right away. Jasper Am 18.05.2012 um 12:47 schrieb David Rodenas: > 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
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
