nRF52832: RTOS Thread Latency causing total failure of MPSL Timeslots for micro-second TimeSync application?

Question

Hi DevZone Team, 
 I am working on a high-precision, low-power Time Synchronization application running on the nRF52832 using the nRF Connect SDK (Zephyr RTOS) . 
 
 Network Topology & System Constraints 
 The wireless architecture consists of a Tx Station (serving as the signal reference) and a Rx Sensor Node running multiple integrated peripherals (SAADC, SPIM, TWIM, DMA, and BLE communications). The goal is to keep the master clocks of both the Tx Station and the Rx Sensor Node perfectly synchronized. 
 The application requires microsecond-level timing accuracy to manage a high-frequency sensor signal up to 4100 Hz. To maintain proper phase alignment without destructive interference, our absolute phase error budget must stay well within a quarter-wavelength (~60 µs). 
 
 The Problem (Initial Architecture) 
 Initially, I implemented a time synching protocol using the nRF5-ble-timesync-demo to request dedicated radio windows alongside active BLE communications(to transmit processed data) to handle this master-to-replica clock synchronization. 
 
 When tested on a bare-metal architecture (via Segger Embedded Studio), this worked perfectly with zero timing issues. 
 However, when ported over to Zephyr RTOS , where the TimeSync loop was managed via threads (including the main thread) alongside multiple heavy worker threads handling the sensor data stream, the application struggled heavily. I experienced frequent MPSL_TIMESLOT_SIGNAL_BLOCKED and slot cancellation events, which regularly corrupted my synchronized data dataset.

The Solution (Current Architecture) 
 To bypass this, I redesigned the firmware to utilize BLE Connection time synchronization for micro-time synchronization between the Tx Station reference signal and the Rx Sensor Node clock. 
 
 By leveraging these hardware-level connection event timings to synchronize the master clocks, our synchronization delay is now completely stable at a maximum of 5 µs (this is what i could observe on the logic analyzer). 
 The phase correction from the reference signal is perfectly preserved, even though the rest of the Sensor Node firmware still relies heavily on Zephyr threads for high-speed sensor processing and storage.

My Theory & Questions for Nordic Community: 
 I want to make sure my understanding of the underlying architecture is correct so I can guarantee long-term stability for this multi-device synchronization. I suspect the MPSL thread-based failures were happening because: 
 
 RTOS Context-Switching Latency: While bare-metal handles MPSL signals instantly in an ISR, handling data inside Zephyr threads introduces context-switching overhead (around 5–20 µs). By the time a thread wakes up to calculate and request the next timeslot via mpsl , the calculated absolute timeline is already stale or conflicting with a hard BLE deadline, causing MPSL to reject it. 
 Driver Interrupt Masking (Critical Sections): The background threads on my sensor node rely heavily on SPIM, TWIM, and flash storage. I suspect these drivers call irq lock or mask interrupts briefly during transfers, delaying the core execution of the MPSL hardware timers just enough to fall out of bounds. 
 
 My Questions: 
 
 Is my hypothesis correct regarding why MPSL timeslots struggle heavily under a thread-heavy Zephyr environment compared to bare-metal? 
 By moving to BLE connection-interval-based synchronization, am I correct in assuming that the time-stamping of the reference signal occurs purely at the hardware/controller layer, making the master clock synchronization entirely immune to the jitter, preemption, or interrupt masking caused by upper-layer Zephyr threads? 
 Are there any hidden risks to watch out for when using BLE connection events for continuous clock drift compensation while heavy DMA-backed threads (SAADC/SPIM) are actively sampling on the sensor node? 
 
 Thanks in advance for your insights!