The code you posted is from an old version of IndirectTxP.nc, do a CVS update and take a look at line 232. Anyway, what is still missing is the device-side. It is on my todo list, but I will definitely not manage to do this within the next two weeks. Since it is probably not so complex you might want to take a look whether you can add the functionality yourself, you would have to edit PollP.nc (there is a comment in line 202, this is where you'd start). If you succeed, I'd be happy to integrate your code.
Jan On Sat, Feb 13, 2010 at 11:12 PM, Jonathan ROY <[email protected]> wrote: > Thank you for your answer Jan, but when I look to > tos/lib/mac/tkn154/IndirectTxP.nc it seems that the coordinator doesn't set > the Frame Pending flag in a DATA frame if it has more DATA frames for the > same device: > > event message_t* DataRequestRx.received(message_t* frame) > { > uint8_t i, j, srcAddressMode, dstAddressMode, *src; > uint8_t *mhr = MHR(frame); > uint8_t destMode = (mhr[1] & FC2_DEST_MODE_MASK); > > // received a data request frame from a device > // have we got some pending data for it ? > if (!m_numTableEntries) > return frame; > srcAddressMode = (mhr[1] & FC2_SRC_MODE_MASK); > if (!(srcAddressMode & FC2_SRC_MODE_SHORT)) > return frame; // no source address > src = mhr + MHR_INDEX_ADDRESS; > if (destMode == FC2_DEST_MODE_SHORT) > src += 4; > else if (destMode == FC2_DEST_MODE_EXTENDED) > src += 10; > if (!((mhr[0] & FC1_PAN_ID_COMPRESSION) && (mhr[1] & > FC2_DEST_MODE_SHORT))) > src += 2; > for (i=0; i<NUM_MAX_PENDING; i++){ > if (!m_txFrameTable[i]) > continue; > else { > dstAddressMode = (m_txFrameTable[i]->header->mhr[1] & > FC2_DEST_MODE_MASK); > if ((dstAddressMode << 4) != srcAddressMode) > continue; > else { > // we know: dstAddressMode IN [2,3] > uint8_t *dst = > &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS]) + 2; > uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8); > for (j=0; j<len; j++) > if (*dst != *src) > break; > if (j==len) > break; // match! break from outer loop > } > } > } > call Debug.log(LEVEL_INFO, IndirectTxP_REQUESTED, > NUM_MAX_PENDING-i,i,*src); > if (i != NUM_MAX_PENDING){ > // found a matching frame, mark it for transmission > m_txFrameTable[i]->client |= SEND_THIS_FRAME; > post tryCoordCapTxTask(); > } else { > // TODO: send an empty data frame to the device > } > return frame; > } > > I've tried to fix this issue but it doesn't seem to work better: > > event message_t* DataRequestRx.received(message_t* frame) > { > uint8_t i, j, srcAddressMode, dstAddressMode, *src; > uint8_t *mhr = MHR(frame); > uint8_t destMode = (mhr[1] & FC2_DEST_MODE_MASK); > ieee154_txframe_t *txFrame = NULL; > > // received a data request frame from a device > // have we got some pending data for it ? > if (!m_numTableEntries) > return frame; > srcAddressMode = (mhr[1] & FC2_SRC_MODE_MASK); > if (!(srcAddressMode & FC2_SRC_MODE_SHORT)) > return frame; // no source address > src = mhr + MHR_INDEX_ADDRESS; > if (destMode == FC2_DEST_MODE_SHORT) > src += 4; > else if (destMode == FC2_DEST_MODE_EXTENDED) > src += 10; > if (!((mhr[0] & FC1_PAN_ID_COMPRESSION) && (mhr[1] & > FC2_DEST_MODE_SHORT))) > src += 2; > for (i=0; i<NUM_MAX_PENDING; i++){ > if (!m_txFrameTable[i]) > continue; > else { > dstAddressMode = (m_txFrameTable[i]->header->mhr[1] & > FC2_DEST_MODE_MASK); > if ((dstAddressMode << 4) != srcAddressMode) > continue; > else { > // we know: dstAddressMode IN [2,3] > uint8_t *dst = > &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS]) + 2; > uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8); > for (j=0; j<len; j++) > if ( dst[ j ] != src[ j ] ) > break; > if (j==len) > { > if ( txFrame == NULL ) > txFrame = m_txFrameTable[ i ]; > else // More than one frame for this device: set Frame Pending > flag > { > txFrame->header->mhr[ 0 ] |= FC1_FRAME_PENDING; > break; // break from outer loop > } > } > } > } > } > call Debug.log(LEVEL_INFO, IndirectTxP_REQUESTED, > NUM_MAX_PENDING-i,i,*src); > if ( txFrame != NULL ) > { > // found a matching frame, mark it for transmission > txFrame->client |= SEND_THIS_FRAME; > post tryCoordCapTxTask(); > } > else > { > // TODO: send an empty data frame to the device > } > return frame; > } > > > Is there something else to do ? I really need this functionality to work... > Thanks, > > Jonathan > > > -----Message d'origine----- > De : Jan Hauer [mailto:[email protected]] > Envoyé : jeudi 11 février 2010 18:16 > À : Jonathan ROY > Cc : [email protected] > Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled > mode > > >> Content preview: Hi, I would like to do some tests using the 802.15.4 > implementation >> (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple > indirect >> transmissions to the same destination" functionality is missing, can > someone >> explain me in details what is the problem and its consequences please ? > [...] > > > Sect. 7.5.6.3 of IEEE 802.15.4-2006: > "If the Frame Pending subfield of the Frame Control field of the data > frame received from the coordinator is set to one, the device still > has more data pending with the coordinator. In this case it may > extract the data by sending a new data request command to the > coordinator." > > In the current implementation the coordinator sets the Frame Pending > flag in a DATA frame if it has more DATA frames for the same device, > but the device will not immediately poll for the DATA frame - instead, > it will wait for the next beacon and poll afterwards. > > Jan > > > On Thu, Feb 11, 2010 at 5:34 PM, Jonathan ROY <[email protected]> > wrote: >> Spam detection software, running on the system > "mail.Millennium.Berkeley.EDU", has >> identified this incoming email as possible spam. The original message >> has been attached to this so you can view it (if it isn't spam) or label >> similar future email. If you have any questions, see >> the administrator of that system for details. >> >> Content preview: Hi, I would like to do some tests using the 802.15.4 > implementation >> (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple > indirect >> transmissions to the same destination" functionality is missing, can > someone >> explain me in details what is the problem and its consequences please ? > [...] >> >> >> Content analysis details: (4.6 points, 3.3 required) >> >> pts rule name description >> ---- ---------------------- > -------------------------------------------------- >> 1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters >> 3.2 FH_DATE_PAST_20XX The date is grossly in the future. >> 0.0 HTML_MESSAGE BODY: HTML included in message >> 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% >> [score: 0.5000] >> >> The original message was not completely plain text, and may be unsafe to >> open with some email clients; in particular, it may contain a virus, >> or confirm that your address can receive spam. If you wish to view >> it, it may be safer to save it to a file and open it with an editor. >> >> >> _______________________________________________ >> 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
