DECT NR+ and DPPI

[nir_g]

Hi there,

Is it possible to have the DECT NR+ modem trigger events via DPPI? For instance, I'd like to capture a Timer value *exactly* when nrf_modem_dect_phy_time_get() takes the modem time; or when the PCC callback (void (*pcc)(const uint64_t *time, const struct nrf_modem_dect_phy_rx_pcc_status *status, const union nrf_modem_dect_phy_hdr *hdr)) is called - I'd like to have a capture of a Timer *exactly* at the same time the PCC arrives.

Without this, I have to create mapping (e.g. PLL) between the system timers and the modem's, and use inexact measurements when these modem functions are called or call-back.

Thank you in advance,

Nir

[Benjamin]

Hi Nir,

It is not possible since the modem core is not a standard peripheral. DPPI is used to connect peripheral events and tasks via PUBLISH/SUBSCRIBE registers in the peripherals. There are no such registers in the modem core.

Could you expand on what you are trying to achieve here so we can check if there may be some solutions?

Regards,
Benjamin

[nir_g]

Thanks, Benjamin, that's what I thought.
My app is very sensitive to latency, and I need to use as much bandwidth as I can. The current switching time between transmission and reception is 2-3 subslots, which really kills performance for my app. Therefore, each of my devices may eventually use two nrf9161/9151 chips - one will only receive, and the other will only transmit. This means that the dedicated transmitter never actually sees a beacon signal, and can't use the PCC STF of the beacon to set the frame start time in its own modem time domain. My solution is this: (1) the receiver chip signals the transmitter chip via GPIO as soon as the PCC callback gets control; (2) the transmitter chip captures the GPIO signal time using DPPI and a 1Mhz TIMER; (3) the transmitter periodically issues nrf_modem_dect_phy_time_get(), while capturing the TIMER value just before the function is called - and using that I keep a PLL that translates the Modem's tick time domain to the system Timer's and vice cersa; (4) this allows me to take the GPIO signal time, translate it to modem time, and use it as the beacon frame reference.  
This isn't bad, but it's still challenging to get to the microsecond resolution that I need for that transmitter to truly be in microsecond-level sync with the Beacon, and not overlap other device's transmissions.

[nir_g]

Thanks, Benjamin, that's what I thought.
My app is very sensitive to latency, and I need to use as much bandwidth as I can. The current switching time between transmission and reception is 2-3 subslots, which really kills performance for my app. Therefore, each of my devices may eventually use two nrf9161/9151 chips - one will only receive, and the other will only transmit. This means that the dedicated transmitter never actually sees a beacon signal, and can't use the PCC STF of the beacon to set the frame start time in its own modem time domain. My solution is this: (1) the receiver chip signals the transmitter chip via GPIO as soon as the PCC callback gets control; (2) the transmitter chip captures the GPIO signal time using DPPI and a 1Mhz TIMER; (3) the transmitter periodically issues nrf_modem_dect_phy_time_get(), while capturing the TIMER value just before the function is called - and using that I keep a PLL that translates the Modem's tick time domain to the system Timer's and vice cersa; (4) this allows me to take the GPIO signal time, translate it to modem time, and use it as the beacon frame reference.  
This isn't bad, but it's still challenging to get to the microsecond resolution that I need for that transmitter to truly be in microsecond-level sync with the Beacon, and not overlap other device's transmissions.

[Benjamin]

Hi Nir,
We are looking at this and I will come back to you later this week.

Regards,
Benjamin

[Benjamin]

Hi Nir,
In January we will release a new firmware (1.2.0) that will help with this issue. It will include a new clock synchronization API. This API can provide an application event tied more closely to the modem tick count, based on a COEX pin interrupt.

It would allow for one chip to output a COEX1 1PPS signal and the other chip to synchronize its clock using that signal routed to the SIM_DET pin. The devices can then exchange information in software about how the 1PPS pulse relates to frame and slot timing.

You will also need to configure the hardware accordingly, routing the COEX pin to the SIM_DET pin. This is not possible on the DK, as SIM_DET is not exposed.

Best regards,
Benjamin