consumed time by SMPL_SendOpt time() call

Hi,

as you might have seen in the code, when the SMPL_SendOpt is called with SMPL_TXOPTION_ACKREQ option (and APP_AUTO_ACK is activated), this will make the function to wait for a request by calling NWK_REPLY_DELAY() which is basically calling the MRFI_ReplyDelay() function. Looking into the code of MRFI_ReplyDelay():

void MRFI_ReplyDelay()

it will basically wait for number of milliseconds which is defined in sReplyDelayScalar variable. sReplyDelayScalar is initialized during MRFI_Init() as follows:

I hope this helps at least to give you the picture how the delay will be calculated.

Thanks Leo!

So that is a real complex formula... But when I break this down to a simple staement, ist looks like there are two factors: One is the "frame-time" dependend on frame size and dataRate which should be not really much (e.g. like a millisecond for a payload of 10 byte).  The other is a complex estimation of maximum delay caused by the stack procedures of the ack-ing device which includes hopping over several repeaters, getting retries because of other traffic on channel (cca) together with backoff delays to solve concurrency. This estimation seems to sum up to tremendous values for the demo kit default values, like several hundret ms. Am I correct with that simplification? If yes I would say there are view chances to use the auto-ACK mechanisms in a real world embedded system as a worst case blocking of such a long time is not easy to handle. It seems to me that we will need to implement a state machine for ACK on the App layer to get rid of such worst case blocking. Please let me know if there are already alternatives which do not block during the delay until time out.

Volker.

Hi Leo,

I've done a little deeper digging and would be very happy if you could help me understanding the following:

The simpliciTI code comments just a little on the "Platform_Factor_Constant". As fare as I have understood it calculates the peer processing time to send the Ack plus the possible everage CCA delay depending on the number of max. hops. The forumla reads:

(2 + 2*(MAX_HOPS*(MRFI_CCA_RETRIES*(8*MRFI_BACKOFF_PERIOD_USECS)/1000)))

I do understand the named factors and the "2 +" term. But I do have trouble understanding the factor "2" which is commented "round trip". It seems to me that there is a mistake: the message send may need up to MRFI_CCA_RETRIES to detect a free channel. So fare OK! BUT: The Ack-Message from the peer will never have any CCA-delays as it is sent with Option "forced" thus not using CCA (at least if I have anlysed the code correctly). This seems to me to be the correct procedure as the chance of another device (using CCA) to block that channel is reduced to the small gap of processing time of the peer.

Could you please inform me if there is indeed a differnece between the theory of the formula of the Platform_Factor_Constant and the implementation of the Ack-Process in the code? If yes I would simply shorten the sReplyDelayScaler time to reflect just one direction using CCA.

Thanks for your patience with my questions and your help,

Volker.

Hi Leo,

that explains this matter fully! Thanks again for your competent help! I will replace the NWK_REPLY_DELAY()  macro in SMPL_SendOpt() with the following code, which is a replacement for MRFI_ReplyDelay():

  bspIState_t s;
  uint16_t    milliseconds = 3;

  BSP_ENTER_CRITICAL_SECTION(s);
  sReplyDelayContext = 1;
  BSP_EXIT_CRITICAL_SECTION(s);

  while (milliseconds)
  {
    Mrfi_DelayUsecSem( APP_USEC_VALUE );
    if (sKillSem)
    {
      break;
    }
    milliseconds--;
  }

  BSP_ENTER_CRITICAL_SECTION(s);
  sKillSem           = 0;
  sReplyDelayContext = 0;
  BSP_EXIT_CRITICAL_SECTION(s);
}

This replacement reflecst the fact, that the delay need not to calc for the TX time but only for the ACK-response time which is about 2ms peer pocessing time plus another 0.5ms TX time of the Ack-frame (using 250kbps). Hopefully this is working well and will reduce the max. timeout period to a much smaller value.

greetings,

Volker.