LPL channel probing is too short

[tim-ist]

We experimented with RPL in LPL mode in Cooja (TMote) and got low PDR (e.g. 93%) even on a small network of 9 nodes. The reason for the losses was that the duration of the channel probing (5 ms) was much less than the inter-packet interval in the packet train (8 ms). Therefore, sometimes receivers could not detect the TX, hitting the inter-packet holes during all TX attempts (we configured it to 5).
The attached screenshot clearly demonstrates the problem. Look at the node 1 trying to transmit to node 2 (blue is TX, green is RX, grey is idle listening).

Note that broadcast frames (which do not request for an ACK) are sent much more densely (node 6).

The problem is in two timing settings. On the sender side, there is the CC2420_ACK_WAIT_DELAY inserted after the TX-completed interrupt and before the sendDone is signalled (unlike broadcasts for which it is signalled immediately). This constant is set to 256 jiffies which for 32768Hz clock gives 256*30.5us=7.8ms.

On the receiver side the probing duration is controlled by the number of reads from the CCA pin, MAX_LPL_CCA_CHECKS=400. The actual duration I could only observe in Cooja and it is around 5ms.

Partial solution: set CC2420_ACK_WAIT_DELAY = 36 which is around 1.1ms. It is enough for hardware-generated ACKs and solves the problem. Although, it may break software acknowledgements if they require more time due to processing.

I tried to disable hardware ACKs, commenting out the following lines in support/blip/blip.extra:

PFLAGS += -DCC2420_HW_ACKNOWLEDGEMENTS

PFLAGS += -DCC2420_HW_ADDRESS_RECOGNITION

But this broke down everything.

I am willing to fix this issue, but I would be happy to receive some feedback/guidelines first.
This was done on TinyOS 2.1.2 but nothing has changed in the CC2420 LPL code since that time.

[cire831]

sounds like you understand the problem.

i'd say go ahead and propose a fix.