Hi there,
And Welcome here…
So yes, in a Sleepy End Device (SED) you want the RF front-end / antenna switch “dark” during sleep to save power — but you can’t safely do that from the Matter “cluster app” level, because Thread/Matter will bring the 802.15.4 radio up/down for polling, keep-alives, MAC timing, etc., outside your window-cover callbacks.
Where this should live (and why)
If you need “power-on RF switch, wait ~10 µs, then allow radio activity” (and the reverse on power-down), the right layer is the radio front-end control path, not the application:
- In Zephyr/NCS, external RF front-end modules (FEMs) are handled via devicetree + driver-controlled GPIO sequencing (TX_EN/RX_EN/PDN/ANT_SEL, etc.).
- The FEM integration exists specifically so the stack can assert pins before RF ramps and can apply microsecond settle times without relying on an app-thread callback (which is too late / too jittery).
A concrete example: Zephyr’s nordic,nrf21540-fem devicetree binding includes configurable settle/hold timings in microseconds (exactly your kind of requirement):
pdn-settle-time-us (PD → PG)tx-en-settle-time-us (PG → TX)rx-en-settle-time-us (PG → RX)trx-hold-time-us (RX/TX → PG)
Even if you’re not 
using an nRF21540, the key point is: this is the pattern to follow—model your external RF switch/front-end in devicetree and let the radio/FEM control layer handle the timing.
Is there a “hook before Zephyr radio starts” you can register?
Not in the way you’re imagining (a neat “radio about to TX/RX” callback exposed to the Matter app).
You can run code early at boot with Zephyr init levels (SYS_INIT()), but that only helps for initial boot sequencing, not for every wake/poll/TX/RX event in a Thread SED.
For runtime RF events, the practical “hook” is:
- Use the existing FEM control mechanism (or implement a small FEM-style driver for your switch) so the radio driver can:
- enable supply
- wait the required settle time (10 µs is totally reasonable in that system)
- then proceed with RX/TX
Zephyr even has a shared FEM control implementation used by the Nordic 802.15.4 radio driver (nrf_fem_control)—that’s the right neighborhood for this kind of timing-critical gating. I’ll find the GIT for it and add it later
pretty sure it’s how the Bare Metal addresses it BTW.
Even if you did have a callback, you would be fighting other issues
- Turning the antenna switch off in “sleep” is desirable, but only if it’s done by the same subsystem that knows when the radio is truly idle.
- You Don’t do it in the cluster app (window cover) because you will race Thread’s background radio use.
- Do it as a FEM/front-end controlled by the radio driver, with microsecond timing configured in devicetree (settle/hold times). Zephyr already supports this pattern and even documents µs-level timing properties for FEMs.
- The hardware is just an RF switch + a power enable (not a full FEM), treat it like a FEM: write a tiny driver/binding or adapt the existing FEM support so the 802.15.4 stack owns it.
Why your 10 µs requirement matters
a callback that runs “right before TX” in an application context is too late. Even if you found a callback somewhere, you’d be fighting:
- scheduling jitter
- interrupt timing
- stack-owned radio timelines
The FEM approach avoids that by letting the radio subsystem schedule GPIO transitions precisely relative to radio state changes.
Nordic does this also in the NBioT setup and there modem.
(control the radio hardware) before Zephyr
I would map it to a clean Zephyr devicetree + Kconfig approach that matches the FEM timing model (including your 10 µs / 3 µs numbers).
HTH
GL 
PJ 
“on RF message edge” means running the receiver most of the time → mA range, not µA.
