[CSL] otPlatRadioReceiveAt window start time question

[lukatug]

Describe the bug A clear and concise description of what the bug is.
I am currently implementing OT1.2 on a STM32 device, currently stuck on CSL support (see Network topology for more details).
I have question related on how some APIs are called by the stack.

When the function otPlatRadioReceiveAt is called, I noticed that the input paramter aStart, the start of the receive window, is earlier than the current time of the system. We are around 29ms 'late'.

I looked at the call stack in the OT source code, starting from SubMac::UpdateCsl, I list the important steps (in my opinion) in the process before otPlatRadioReceiveAt is called:

• mCslSampleTime = TimeMicro(static_cast<uint32_t>(otPlatRadioGetNow(&GetInstance()))); (sub_mac.cpp, l1078).

HandleCslTimer()

• mCslSampleTime += periodUs; (sub_mac.cpp, l1124).
• IgnoreError(Get<Radio>().ReceiveAt(mCslChannel, mCslSampleTime.GetValue() - periodUs - timeAhead, timeAhead + timeAfter)); (sub_mac.cpp, l1139).

My question is on the last line; from my understanding, 'aStart' is thus (mCslSampleTime.GetValue() - periodUs - timeAhead), which is equal to (otPlatRadioGetNow() - timeAhead).

Is it normal behavior for otPlatRadioReceiveAt to be called with these parameters?

To Reproduce Information to reproduce the behavior, including:

1. Git commit id

  commit 32ac6ddfad2bc196e216c42249c73420542daac0
  Author: Jonathan Hui <jonhui@google.com>
  Date:   Tue Jul 26 14:51:14 2022 -0700

3. IEEE 802.15.4 hardware platform
   STM32 platform
4. Build steps
5. Network topology

Leader: Golden Unit as Leader (CLI binary)
ot panid 0xbaba
ot channel 22
ot networkkey 00112233445566778899aabbccddeeff
ot extaddr 11112222b12e1ead
ot mode rdn
ot ifconfig up
ot thread start

Child: DUT implementation ongoing (CLI binary)
panid 0xbaba
channel 22
networkkey 00112233445566778899aabbccddeeff
extaddr 11112222b12ec11d
mode -
ifconfig up
thread start

Expected behavior A clear and concise description of what you expected to happen.
Once the connection is established, I add csl period 3125 on DUT. A Child Update Request with CSL information is forwarded to Leader which acknowledges and sends an Update Response, which Child does not ACK.

Console/log output If applicable, add console/log output to help explain your problem.

Additional context Add any other context about the problem here.
First issue submited there, please tell me if you require additionnal informations.

[edmont]

Hi @lukatug.

Notice that mCslSampleTime is initialized once with the otPlatRadioGetNow value and then periodically increased by periodUs.

When RadioSupportsReceiveTiming the logic for each iteration is as follows:

• Timer is configured to be triggered a few milliseconds before the next sample time.
  mCslTimer.FireAt(mCslSampleTime - timeAhead);
• The radio is informed about the next sample time value:
  Get<Radio>().UpdateCslSampleTime(mCslSampleTime.GetValue());
• The receive window around the current sample time is configured:
  Get<Radio>().ReceiveAt(mCslChannel, mCslSampleTime.GetValue() - periodUs - timeAhead, timeAhead + timeAfter));
  Here timeAhead doesn't include kCslReceiveTimeAhead which is only used for the purpose of triggering the timer, but not for the actual receive window duration.

Hope this helps.