I guess I missed that. Thanks for the fix.
You should be able to test it by sending a short frame that is exactly SIFS_MAXPKTSIZE including FCS. With this PR, SIFS should be selected as intended, instead of LIFS. Best to test with a Logic Analyzer on a GPIO.
Unfortunately I did not manage to send smaller packets than ~40 with gnrc_networking. Does anyone have an idea how to do that?

This PR again is reasonable, the code looks good and compiles, and ping still works.

However I could not test this PR to my satisfaction and might have found another bug.
testing:
I tried with examples/default and sent smaller and larger packets to the short address. With a sniffer I received packets smaller than 18 Bytes (SIFS_MAXPKTSIZE), as desired.

problem:
I tried to read the backoff time of the timer with gpios - set gpio directly after timer_start and cleared it in the timer callback - but strangely the backoff time scaled with the packetsize. For each additional Byte, let it be 1 or 50 Bytes of payload, the timer took additional 32 us.

Can you reproduce this - might this even be correct behavior?

problem:
I tried to read the backoff time of the timer with gpios - set gpio directly after timer_start and cleared it in the timer callback - but strangely the backoff time scaled with the packetsize. For each additional Byte, let it be 1 or 50 Bytes of payload, the timer took additional 32 us.

Interesting, I'll try to reproduce this asap. In the mean time, is this also an issue on master? Furthermore, with IEEE 802.15.4, the "air time" of a byte is exactly 32 µs (8 bit / (62.5Ksymbol/s * log_2(16) bit/symbol), this matches a bit too well with your scaling factor to be simply ignored :D

Interesting, I'll try to reproduce this asap. In the mean time, is this also an issue on master?

I did test this on master first, before i cherrypicked your commit, and yes, i got the same result.. I dont think I got significant timing differences with and without your PR.

I am out of office today, I will look into that later this week. Please keep me posted :)

Okay, I think I've nailed the issue here. It's an related bug with the timer initialization. First #11146 should be a dependency of this PR to actually validate the timing. with those commits cherry-picked in, I get the following (17B total size):

The weird thing here is that the GPIO is high->low->high, while it should be low->high->low.

issue:

As per API, timers are initialized running, so after initialization the NRF802154_TIMER is already running. So when the timer_set call in _send is executed, the timer_cb is executed SIFS or LIFS time later, clearing the GPIO. After some time, the transmission ends, setting the GPIO again. The fix is to call timer_stop() directly after the timer_init() (below the assertion check). I'll add this as an additional commit to #11146 as that PR attempts to fix all timer related issues.

With a timer_stop() in the _init function, my measurements show this for short frames (13B) that can use SIFS:

And for longer frames (21B) requiring LIFS:

@SemjonKerner see d89db8d

Great bug, yet so obvious.
Sadly I will be out of office tomorrow, too. But I will test it as soon as possible.

Sadly I will be out of office tomorrow, too. But I will test it as soon as possible.

No worries, thanks!

Thanks for the contribution :)

Thank you for the review :)