Skip to content

Commit

Permalink
doc: nrf_modem: small updates
Browse files Browse the repository at this point in the history
Small updates (squash).

Signed-off-by: Emanuele Di Santo <[email protected]>
  • Loading branch information
lemrey committed Jan 23, 2025
1 parent 455ed75 commit 1660e1e
Showing 1 changed file with 5 additions and 6 deletions.
11 changes: 5 additions & 6 deletions nrf_modem/doc/dectphy.rst
Original file line number Diff line number Diff line change
Expand Up @@ -73,12 +73,12 @@ The DECT PHY interface offers four functions to manipulate the DECT PHY stack st
Initialization
==============

Initializing the DECT PHY readies the hardware resources for the PHY in the network processor.
Initializing the DECT PHY readies the hardware resources for the PHY in the modem.

Before initializing the DECT PHY, the application must:

#. Initialize the Modem library by calling the :c:func:`nrf_modem_init` function.
This also turns on the network processor.
This also turns on the modem.
#. Register the event handler for DECT PHY operations by calling the :c:func:`nrf_modem_dect_phy_event_handler_set` function.

Afterwards, the application can initialize the DECT PHY by calling the :c:func:`nrf_modem_dect_phy_init` function.
Expand Down Expand Up @@ -141,8 +141,7 @@ When in the deactivated state, the DECT PHY can be configured with different par
Deinitialization
================

The DECT PHY can be deinitialized using the :c:func:`nrf_modem_dect_phy_deinit` function.
The DECT PHY can be de-initialized, which in turn de-initializes the physical layer in the network processor, releasing all hardware resources.
The DECT PHY can be de-initialized using the :c:func:`nrf_modem_dect_phy_deinit` function, releasing all hardware resources.
Once de-initialized, the DECT PHY interface can be re-initialized by only calling the :c:func:`nrf_modem_dect_phy_init` function.

Temperature monitoring
Expand Down Expand Up @@ -243,13 +242,13 @@ The operation startup latency ``startup`` is indicated:
* For TX operations by: :c:member:`nrf_modem_dect_phy_latency_info.idle_to_active`

Since the operation is scheduled, we must include the additional startup delay associated with scheduled operations for the current radio mode.
This delay is represented by the value :c:member:`nrf_modem_dect_phy_latency_info.scheduled_operation_startup`, which refers to as ``sched_startup``.
Let ``sched_startup`` be the value of this delay, as indicated by :c:member:`nrf_modem_dect_phy_latency_info.scheduled_operation_startup`.

The earliest start time of the operation is then calculated by adding both the initial startup delay and the scheduled startup delay to the current modem time,
expressed as: ``t + startup + sched_startup``.

The earliest time at which the operation can be scheduled after another one must include the additional delay associated with transitioning from one scheduled operation to the next, according to the current radio mode.
This delay is represented by the value :c:member:`nrf_modem_dect_phy_latency_info.scheduled_operation_transition`, which refers to as ``sched_transition``.
Let ``sched_transition`` be the value of this delay, as indicated by :c:member:`nrf_modem_dect_phy_latency_info.scheduled_operation_transition`.

In conclusion, the start time of the operation being scheduled must be at least as large as the minimum between ``t + startup + sched_startup`` and ``start_time_op1 + duration_op1 + sched_transition``.

Expand Down

0 comments on commit 1660e1e

Please sign in to comment.