On Wed, Feb 17, 2010 at 11:50 PM, Jonathan ROY <[email protected]> wrote: > I did a CVS update, but I've still some troubles with the Frame Pending > flag: in case the coordinator has 2 data frames pending for a device, the > first one to be requested will have its Pending Flag set (this is OK) but > the second frame will also have it whereas the coordinator doesn't have > another pending frame for the device...Is this normal ?
No, but since "our" devices are not using this information it wasn't noticed / didn't matter so far. I will take a look. Jan On Wed, Feb 17, 2010 at 11:50 PM, Jonathan ROY <[email protected]> wrote: > I did a CVS update, but I've still some troubles with the Frame Pending > flag: in case the coordinator has 2 data frames pending for a device, the > first one to be requested will have its Pending Flag set (this is OK) but > the second frame will also have it whereas the coordinator doesn't have > another pending frame for the device...Is this normal ? > > In IndirectTxP.nc I did the following test (added lines are prefixed by > '>>'): > > event message_t* DataRequestRx.received(message_t* frame) > { > uint8_t i, j, srcAddressMode, dstAddressMode, *src; > uint8_t *mhr = MHR(frame); > uint8_t destMode = (mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_MASK); > ieee154_txframe_t *dataResponseFrame = NULL; > > // received a data request frame from a device > // have we got some pending data for it ? > srcAddressMode = (mhr[MHR_INDEX_FC2] & 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[MHR_INDEX_FC1] & FC1_PAN_ID_COMPRESSION) && > (mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_SHORT))) > src += 2; > for (i=0; i<NUM_MAX_PENDING; i++) { > if (m_txFrameTable[i] == NULL) > continue; > else { > dstAddressMode = (m_txFrameTable[i]->header->mhr[MHR_INDEX_FC2] & > 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; // no match! > if (j==len) { // match! > if (dataResponseFrame == NULL) { > dataResponseFrame = m_txFrameTable[i]; >>> if ( dataResponseFrame->header->mhr[ MHR_INDEX_FC1 ] & > FC1_FRAME_PENDING ) >>> Leds.led0Toggle(); > } > else // got even more than one frame for this device: set > pending flag > dataResponseFrame->header->mhr[MHR_INDEX_FC1] |= > FC1_FRAME_PENDING; > } > } > } > } > if (dataResponseFrame != NULL) { > // found a matching frame, mark it for transmission > dbg_serial("IndirectTxP", "We have data for this device, trying to > transmit...\n"); > dataResponseFrame->client |= SEND_THIS_FRAME; > post tryCoordCapTxTask(); > } else { > dbg_serial("IndirectTxP", "We don't have data for this device, sending > an empty frame...\n"); > transmitEmptyDataFrame(frame); > } > return frame; > } > > And LED 0 is toggled when the second data request is received from the > device, how can this be possible ? > Thank you very much for your help... > > Jonathan > > > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] De la part de Jan > Hauer > Envoyé : lundi 15 février 2010 17:45 > À : Jonathan ROY > Cc : [email protected] > Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled > mode > > > 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
