rssi-1 measurements DECT NR+

RE: rssi-1 measurements DECT NR+

Charlie — Tue, 10 Sep 2024 08:15:14 GMT

Hi,

This will be in DECT PHY firmware new release to fix this. This is still under evaluating according to developer.

Best regards,

Charlie

RE: rssi-1 measurements DECT NR+

nrfuser2137 — Tue, 10 Sep 2024 07:17:51 GMT

Please let me know if there is any update on this issue.

RE: rssi-1 measurements DECT NR+

Charlie — Mon, 29 Jul 2024 07:07:35 GMT

Hi,

I have inquired developer on NCS modem library side:

The customer is correct wrt to the inconsistency in the documentation of the RSSI reporting interval for the RSSI measurement operation, where it is documented to be in subslots instead of slots:

This will be corrected. As to why the values of the measurement start times and the absolute time are incorrect, I am unsure. I have ran some tests locally and am able to reproduce.

Next step, I will check with our modem developer for further analysis. This may take some time due to summer vacation period. Thanks for your patience.

Best regards,

Charlie

RE: rssi-1 measurements DECT NR+

nrfuser2137 — Wed, 24 Jul 2024 06:41:28 GMT

[quote userid="93921" url="~/f/nordic-q-a/113296/rssi-1-measurements-dect-nr/495259"]The meas_start_time interval is around 1418900 modem time unites[/quote]

meas_start_time is an interval or an absolute time?

According to the comments in nrf_modem_dect_phy.h, I understood the meas_start_time is an absolute timestamp when the modem started the measurements. So, FT could take meas->meas_start_time value as the reference point to calculate start of a frame which can be further used by FT for scheduling, ..

To see how the PHY API works, I wanted to do the rssi measurement for 10ms and also have the information at what time the rssi measurement started. RSSI measurement operation needs duration and reporting_interval. I wanted to keep both of them equal to 10ms. According to the documentation, both params need to be in subslots. But the

enum nrf_modem_dect_phy_rssi_interval reporting_interval seems to have fields in "slot" units (not in subslots), e.g., NRF_MODEM_DECT_PHY_RSSI_INTERVAL_24_SLOTS. The params i used to scheduled the operation are, duration = 48 subslots (10ms) and reporting_interval=NRF_MODEM_DECT_PHY_RSSI_INTERVAL_24_SLOTS (10ms).

Now, looking at the logs printed, cbtime refers to *time param of the callback. The time difference between first two callbacks is 249746536-249018865=727671 or (727671÷69120=10.5ms). I would account 0.5ms for the debug logs overhead, etc... and the callbacks are async. MAC operations can be scheduled taking modem time into account.

I was also expecting the (meas->meas_start_time - *time) roughly ~727671 considering the parameters to schedule the operation, but this is not the case. And except for the first log, meas->meas_start_time is greater than *time. How can meas_start_time be greater than the current modem_time? Seems like I misunderstood the measurement operation.

While looking at the nrf_modem_dect_phy.h again, I found some inconsistencies. We can also get rssi measurements with rx operation. But there, the documentation does not mention whether the reporting_interval is in slots or subslots. The duration for rx operation is in modem time units (in contrast to rssi operation where duration is in subslots).

Would be very helpful if you can comment on this...

RE: rssi-1 measurements DECT NR+

Charlie — Tue, 23 Jul 2024 14:33:00 GMT

Hi,

Try to catch up with your calculation.

The meas_start_time interval is around 1418900 modem time unites. Considering the following definition in nrfxlib\nrf_modem\include\nrf_modem_dect_phy.h. The actual meas_start_time interval is around 1418900/69120=20.5ms.

#define NRF_MODEM_DECT_MODEM_TIME_TICK_RATE_KHZ 69120

The subslot duration is defined in ETSI TS 103 636-3 [2], clause 4.4. a slot duration is 0,41667ms. There are 48 subslots measurement duration and 24 slots reporting interval, but I am not sure if you will get a report if the measurement is not finished. You can also easily verify with a test like 72 subslots measurement duration. If this is true, 48*0,41667ms=20ms, still have 0.5ms mismatch.

I will check with our modem developer anyway.

Best regards,

Charlie