contikimac timing issue with acknowledge

[nbrunner]

When i try to ping the cc26xx-demo with CC1310DK, i see that the acknowledge are see as collision is the border router (6LBR BBB with slip radio CC1310DK). With an oscilloscope i saw that the acknowledge are sent more than 2ms after receiving the packet, this is explaining the collision see in the router. I inspected the contikimac code and saw that inside input_packet() the radio was getting off before sending the acknowledge. I modified the code to power off the radio at the end of input_packet() and now my router correctly see acknowledge.

Here are the modifications i have done in contikimac.c:

removed:

  if(!we_are_receiving_burst) {
    off();
  }

Moved to the end of input_packet() :

      if(we_are_receiving_burst) {
        on();
        /* Set a timer to turn the radio off in case we do not receive
       a next packet */
        ctimer_set(&ct, INTER_PACKET_DEADLINE, recv_burst_off, NULL);
      } else {
        off();
        ctimer_stop(&ct);
      }

[arurke]

Have you looked at #1747 and the proposed solution #1783 - related?

[nbrunner]

I just look at your link but for what i understand the main problem is that the contikimac is switching off the RF before sending the acknowledge. This make it impossible to have a good reactivity time for sending the acknowledge. The slip-radio works well because it keep the radio ON with NETSTACK_RDC.off(1);

[bkozak-scanimetrics]

Seems like more of an issue with the CC1310 than anything. The driver for the CC1310 shouldn't let you turn it off if it's sending an ACK or about to send an ACK. This should probably be fixed in platform code if at all possible.

I'd guess that this only affects the CC1310 and not the CC2650 because the sub-ghz operations tend to be slower.

I think this may be caused because we are using CMD_ABORT (stop immediately) to stop the radio instead of CMD_STOP (stop gracefully) to shut-down the RF core. In #1549 I used CMD_STOP to shut-down the radio precisely because I was afraid of interrupting an ACK and it seems to work there (note that I'm using the CC2650 however).

[g-oikonomou]

So the main difference between CC1310 (and CC1200 and other sub-ghz radios) is that they don't send out ACKs automatically. Thus, in terms of what Billy is posting, the radio will never turn off while sending an ACK, simply because the ACKs are in fact sent by s/w inside the ContikiMAC driver.

I can see what @nbrunner is trying to say about ContikiMAC turning off the radio inside packet_iput before sending out an ACK, but unfortunately it is what it is and the radio has to play nicely with this, until the ContikiMAC code realizes that not all underlying radios can do h/w ACKs :)

One idea is to extend the block that wraps around this off() call to also check the value of CONTIKIMAC_SEND_SW_ACK. So if we are about to send out a s/w ACK, don't turn off.

[g-oikonomou]

But to expand a little bit: Yes, we do have an issue here, but I still think #1783 is a suitable workaround. If we merge this one in, then the discussion here will be mainly around performance improvement (which is of course something we still want irrespectively)