samples: dect: add simple sample #136

eivindj-nordic · 2024-03-21T09:40:02Z

Add simple dect sample.

TODO:

Documentation
Cleanup

lemrey

Did a first pass

lemrey · 2024-04-18T12:08:10Z

samples/dect/dect_phy_simple/Kconfig

+
+config CARRIER
+ int "Carrier to use"
+ default 1677 #during development, remove default from sample so cutomer must address it?-


this number depends on the local regulations.. perhaps we should not have compile out of the box, since we don't know which country the customer is. We could have an overlay for Europe and one for USA maybe with different values for this KConfig that are ready to use, but require a manual configuration step by the customer.

lemrey · 2024-04-18T12:09:17Z

samples/dect/dect_phy_simple/Kconfig

+ default 1677 #during development, remove default from sample so cutomer must address it?-
+ help
+ The availability of the channels and the exact regulation to use them varies in different countries.
+ See ETSI TS 103 636-2 5.4.2 for the calculation.


Table 4.3.2.3-2 of ETSI EN 301 406-2

Or actually, nevermind that. ETSI EN applies to Europe only.. better to refer to the TS document here I suppose.

lemrey · 2024-04-22T12:34:33Z

samples/dect/dect_phy_simple/CMakeLists.txt

let's call it something else than simple maybe hello_dect ?

lemrey · 2024-04-22T12:51:24Z

samples/dect/dect_phy_simple/src/main.c

+ return 0;
+}
+
+SHELL_CMD_REGISTER(exit, NULL, "Download modem firmware", shell_exit);


exit .. Download modem firmware ?

lemrey · 2024-04-22T12:53:54Z

samples/dect/dect_phy_simple/src/main.c

+ struct nrf_modem_dect_phy_rx_params rxOpsParams = { 0 };
+
+ rxOpsParams.start_time = 0;


do this instead:

struct foo = { .bar = 1, .baz = 2, }

lemrey · 2024-04-22T12:55:38Z

samples/dect/dect_phy_simple/src/main.c

I think splitting the sample in two RX/TX samples would simplify it quite a bit.. In particular we avoid having to configure a board as transmitter or receiver, which here is done with DK buttons. I'd rather not use any buttons and LEDs at all to be honest.

Ideally the transmitter would send "Hello world, DECT" and a counter, and the receiver would just display that on the console.

The board is not configured with the DK button, those are only used to exit the sample. The first device will take the TX role as it does not receive anything.

We could split it so that we have two samples too, though it would be some duplicate code and the user would have to build and flash two different applications.

Indeed, the buttons and LEDs are not for configuring the sample; that was my misunderstanding. The sample self-configures through a different method. Regardless, if the logic was hardcoded, it would simplify understanding the sample. Building and flashing two distinct samples is necessary, though I believe it's not a big deal..

Also, I think the sample should run some configurable number of iterations and then exit by itself (no buttons/shell). Optionally, the number of iterations can be some special value indicating "don't exit".

lemrey · 2024-04-22T13:00:19Z

samples/dect/dect_phy_simple/CMakeLists.txt

+FILE(GLOB app_sources src/main.c)
+target_sources(app PRIVATE ${app_sources})


just add main.c with target_sources()

1. SDC_HCI_OPCODE_CMD_VS_SCAN_CHANNEL_MAP_SET This command can be used to set the primary advertising channels that should be used for scanning and initiating. 2. SDC_HCI_OPCODE_CMD_VS_SCAN_ACCEPT_EXT_ADV_PACKETS_SET This command enables/disables processing of extended advertising PDUs. Signed-off-by: Johan Stridkvist <johan.stridkvist@nordicsemi.no>

Commit sets adjusted values for `OPENTHREAD_PLATFORM_CSL_UNCERT` and `IEEE802154_NRF5_DELAY_TRX_ACC`. Signed-off-by: Przemyslaw Bida <przemyslaw.bida@nordicsemi.no>

Add a Features of nRF53 Series page Signed-off-by: Katherine Depa <katherine.depa@nordicsemi.no>

Add service for managing SUIT-based updates. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

adds ns target based on crypto samples. Signed-off-by: Anna Wojdylo <anna.wojdylo@nordicsemi.no>

This fixes a few bugs where cadence-related functions would attempt to work with uninitalized sensor values causing null pointer dereferencing. This makes it so that: * Cadence updates before cadence is initialized are ignored * The first delta check before any `prev` value is available will always return `true`. Also adds a null check to `bt_mesh_sensor_value_get_status` by using the API function for float conversion (which already does a NULL check) instead of the bare type callback function. Signed-off-by: Ludvig Jordet <ludvig.jordet@nordicsemi.no>

Use suit-processor revision, compatible with ZCBOR 0.8.1. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

Enable SUIT subsystem unit tests. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

eivindj-nordic · 2024-04-23T12:24:30Z

I've added more alternatives to the sample now:

One where the RX and TX is split into different samples
One where each device will both send and transmit

Please have a look what approach to go for.

MirkoCovizzi

First cursory look

MirkoCovizzi · 2024-04-23T12:32:31Z

samples/dect/dect_phy/hello_dect/README.rst

+
+The sample shows a simple broadcast of DECT NR+ messages from one device to other devices on a hard-coded channel.
+
+During initialization the devices listens on the channel for broadcast transmissions.


Suggested change

During initialization the devices listens on the channel for broadcast transmissions.

During initialization the devices listen on the channel for broadcast transmissions.

MirkoCovizzi · 2024-04-23T12:32:48Z

samples/dect/dect_phy/hello_dect/README.rst

+The sample shows a simple broadcast of DECT NR+ messages from one device to other devices on a hard-coded channel.
+
+During initialization the devices listens on the channel for broadcast transmissions.
+Dependent on the detection of transmissions, the device takes one of the following roles:


Suggested change

Dependent on the detection of transmissions, the device takes one of the following roles:

Depending on the detection of transmissions, the device takes one of the following roles:

MirkoCovizzi · 2024-04-23T12:33:12Z

samples/dect/dect_phy/hello_dect/README.rst

+During initialization the devices listens on the channel for broadcast transmissions.
+Dependent on the detection of transmissions, the device takes one of the following roles:
+
+* If no transmission is detected, the device takes the role as a tranceiver. In this role, the device sends an incrementing counter value on the hard-coded channel. The period between each transmission is decided by the :kconfig:option:`CONFIG_TX_INTERVAL_SECONDS` Kconfig option.


Suggested change

* If no transmission is detected, the device takes the role as a tranceiver. In this role, the device sends an incrementing counter value on the hard-coded channel. The period between each transmission is decided by the :kconfig:option:`CONFIG_TX_INTERVAL_SECONDS` Kconfig option.

* If no transmission is detected, the device takes the role of a tranceiver. In this role, the device sends an incrementing counter value on the hard-coded channel. The period between each transmission is decided by the :kconfig:option:`CONFIG_TX_INTERVAL_SECONDS` Kconfig option.

MirkoCovizzi · 2024-04-23T12:33:38Z

samples/dect/dect_phy/hello_dect/README.rst

+Dependent on the detection of transmissions, the device takes one of the following roles:
+
+* If no transmission is detected, the device takes the role as a tranceiver. In this role, the device sends an incrementing counter value on the hard-coded channel. The period between each transmission is decided by the :kconfig:option:`CONFIG_TX_INTERVAL_SECONDS` Kconfig option.
+* If a transmission is detected, the device takes the role as a receiver. In this role, the device listens for incomming messages.


Suggested change

* If a transmission is detected, the device takes the role as a receiver. In this role, the device listens for incomming messages.

* If a transmission is detected, the device takes the role of a receiver. In this role, the device listens for incoming messages.

MirkoCovizzi · 2024-04-23T12:42:32Z

samples/dect/dect_phy/hello_dect_rx/src/main.c

+ return err;
+ }
+
+ k_sem_take(&modem_sem, K_FOREVER);


Please add some comments explaining what it is blocking on and what it is unblocking (next line). It might get confusing in my opinion since there are many moving parts sharing this semaphore.

MirkoCovizzi · 2024-04-23T12:43:22Z

samples/dect/dect_phy/hello_dect_rx/src/main.c

+ return -EIO;
+ }
+
+ LOG_INF("Dect NR+ PHY initialized %d", err);


Is logging err necessary here even in happy path?

This is removed.

MirkoCovizzi · 2024-04-23T12:44:01Z

samples/dect/dect_phy/hello_dect_rx/src/main.c

+ }
+
+ err = modem_rx(NRF_MODEM_DECT_PHY_RX_MODE_SINGLE_SHOT,
+ CONFIG_RX_TIMEOUT_S * MSEC_PER_SEC, handle);


Some alignments problems, at least on GitHub.

MirkoCovizzi · 2024-04-23T12:45:35Z

samples/dect/dect_phy/hello_dect_rx/src/main.c

+};
+
+/* Receive operation, listen for listen_time_ms duration */
+int modem_rx(uint32_t rxMode, int listen_time_ms, uint32_t handle)


Why camelcase rxMode? Also camelcase rxOpsParams later on.

left from earlier versions, I will correct for the sample(s) we end up with.

MirkoCovizzi · 2024-04-23T12:47:08Z

samples/dect/dect_phy/hello_dect_rx/src/main.c

+void capability_get(const uint64_t *time, enum nrf_modem_dect_phy_err err,
+ const struct nrf_modem_dect_phy_capability *capability)
+{
+ LOG_DBG("capability_get time %"PRIu64" Status %d", *time, err);


Is time always non-null or is there a chance that it might be null?

MirkoCovizzi · 2024-04-23T12:47:28Z

samples/dect/dect_phy/hello_dect_rx/src/main.c

+void pdc_crc_err(
+ const uint64_t *time, const struct nrf_modem_dect_phy_rx_pdc_crc_failure *crc_failure)
+{
+ int16_t resp=calcRSSI(crc_failure->rssi_2);


Suggested change

int16_t resp=calcRSSI(crc_failure->rssi_2);

int16_t resp = calcRSSI(crc_failure->rssi_2);

MirkoCovizzi · 2024-04-23T12:48:00Z

samples/dect/dect_phy/hello_dect_rx/src/main.c

+K_SEM_DEFINE(rx_sem, 0, 1);
+
+/* ETSI TS 103 636-2 spec 8.3.3 RSSI is reported every 0.5dbm */
+int32_t calcRSSI(int16_t recrssi){


Camelcase? Is this copied from somewhere else?

MirkoCovizzi

I notice that there is a lot of shared code between the samples.

MirkoCovizzi · 2024-04-23T12:50:05Z

samples/dect/dect_phy/hello_dect_tx/src/main.c

+ k_sem_give(&tx_sem);
+}
+
+K_TIMER_DEFINE(tx_timer, tx_timer_callback, NULL);


Could be moved up together with the other defines.

This needs to be defined after the callback.

The callback can be declared on top and defined later.

True, though I don't see the need when the function is this small and there is different type of defines.

I've restructured a bit in the _rxtx sample.

MirkoCovizzi · 2024-04-23T12:51:15Z

samples/dect/dect_phy/hello_dect_tx/src/main.c

+K_TIMER_DEFINE(tx_timer, tx_timer_callback, NULL);
+
+/* ETSI TS 103 636-2 spec 8.3.3 RSSI is reported every 0.5dbm */
+int32_t calcRSSI(int16_t recrssi){


I see that this is shared with other samples. Perhaps there is a way to have a common implementation for code reuse?

I don't think that is a good idea for samples as it often becomes messy over time and less easy to get an overview. If there is features that should be split out it should be in a library. In this case, I think we should go with the _txrx sample, which will remove this issue.

MirkoCovizzi · 2024-04-23T12:52:28Z

samples/dect/dect_phy/hello_dect_tx/src/main.c

+ int err;
+ uint32_t tx_counter_value = 0;
+
+ LOG_INF("Dect NR+ PHY sample started");


I would specify here which variant of the sample this is (TX).

MirkoCovizzi · 2024-04-23T12:52:56Z

samples/dect/dect_phy/hello_dect_tx/src/main.c

+ if (exit) {
+ return -EIO;
+ }
+


Extra newline.

MirkoCovizzi · 2024-04-23T12:53:04Z

samples/dect/dect_phy/hello_dect_tx/src/main.c

+
+
+ LOG_INF("Dect NR+ PHY initialized %d", err);
+


Extra newline.

MirkoCovizzi · 2024-04-23T12:56:16Z

samples/dect/dect_phy/hello_dect_tx/src/main.c

+ err = transmit_counter(tx_counter_value);
+ if (err) {
+ LOG_ERR("transmit failed, err %d", err);
+ continue;


Is there a chance this might fail repeatedly if there is no backoff in between retransmissions?

If this fails it is due to an issue in the modem library or misuse by the sample. This returns as soon as the request is sent to the modem, and will synchronize internally with other modem calls.

MirkoCovizzi · 2024-04-23T12:56:31Z

samples/dect/dect_phy/hello_dect_tx/src/main.c

+ continue;
+ }
+
+ LOG_INF("Data sent %d",tx_counter_value);


Suggested change

LOG_INF("Data sent %d",tx_counter_value);

LOG_INF("Data sent %d", tx_counter_value);

Pull in a fix in pinctrl that prevents the nrf_qspi_nor driver from failing to initialize when the flash chip is configured to work in non-Quad mode. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Support WPA Auto security mode wherein supplicant can implicitly choose the highest security among WPA, WPA2 and WPA3 for association with a network based on network support. Fixes SHEL-1131. Signed-off-by: Ravi Dondaputi <ravi.dondaputi@nordicsemi.no>

The `connect` command has been updated to take key-value style arguments. Update the description to include this information. Fixes SHEL-2699. Signed-off-by: Ravi Dondaputi <ravi.dondaputi@nordicsemi.no>

To limit integration scope. For: zephyr/tests/subsys/mgmt/mcumgr/os_mgmt_info zephyr/tests/subsys/mgmt/mcumgr/fs_mgmt_hash_supported zephyr/tests/subsys/mgmt/mcumgr/smp_version zephyr/tests/subsys/mgmt/mcumgr/os_mgmt_echo zephyr/samples/subsys/mgmt/mcumgr/smp_svr nrf/tests/subsys/dfu/dfu_target_stream Signed-off-by: Piotr Kosycarz <piotr.kosycarz@nordicsemi.no>

Compilation with nrf7002ek configuration had less than 200 bytes of SRAM free, which didn't allow much room for own tweaks. It's evident this would overflow in the near future so decreasing the number of requested WiFi APs from 30 to 20. It could be even 10 like with Thingy91X configuration. Signed-off-by: Tommi Rantanen <tommi.rantanen@nordicsemi.no>

Thingy91x has some configurations that doesn't really need to be supported and they do not fit to flash. Removing them. Signed-off-by: Tommi Rantanen <tommi.rantanen@nordicsemi.no>

Update sdk-zephyr to pull in several commits cherry-picked from upstream. Signed-off-by: Jędrzej Ciupis <jedrzej.ciupis@nordicsemi.no>

Add basic sample that demonstrates SUIT-based boot and update procedures. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

Require at least 3 backups to encode SUIT SSF responses and enforce canonical en/decoding if the SUIT-enabled SDFW is used. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

Add a sleep to address the issue where the sample doesn't wait for the WPA supplicant to be fully initialized before proceeding with Wi-Fi operations. Signed-off-by: Triveni Danda <triveni.danda@nordicsemi.no>

The new Zephyr revision introduces experimental EXMIF peripheral driver. Signed-off-by: Rafał Kuźnia <rafal.kuznia@nordicsemi.no>

The compatible nordic,nrf2220-fem is added to bindings. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

This commit adds initial experimental support for nrf2220 Front-End device. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

This commit adds initial support for nrf2220 Front-End device through fem_al API. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

This commit adds initial support for the nrf2220ek shield. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

The compatible nordic,nrf2240-fem is added to bindings. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

This commit adds initial experimental support for nrf2240 Front-End device. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

This commit adds initial support for nrf2240 Front-End device through fem_al API. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

This commit adds initial support for the nrf2240ek shield. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

The nrf2220 and nrf2240 devices require that mpsl_fem_init operation happens before the initialization of I2C if the TWI interface is used with these devices. This was achieved by hardcoded 49 value which is less than default value of Kconfig option I2C_INIT_PRIORITY. This commit removes the magic value form SYS_INIT(..., 49) and introduces a new Kconfig option MPSL_FEM_INIT_PRIORITY. The default value for MPSL_FEM_INIT_PRIORITY in case of nrf2220 or nrf2240 with TWI is still hardcoded to 49 due to following limitations: 1) The Kconfig compiler does not allow compile-time calculation of default value like: config MPSL_FEM_INIT_PRIORITY default (I2C_INIT_PRIORITY-1) if ... 2) The third parameter of SYS_INIT must be a literal or come from a macro expanding to literal. It cannot expand to expression. So following is impossible: #define FEM_INIT_PRIO (CONFIG_I2C_INIT_PRIORITY - 1) SYS_INIT(mpsl_fem_init, POST_KERNEL, FEM_INIT_PRIO); Providing Kconfig option MPSL_FEM_INIT_PRIORITY with appropriate BUILD_ASSERT gives ability to have correct priority of FEM initialization in case the Kconfig I2C_INIT_PRIORITY is changed. For nrf21540_gpio, nrf21540_gpio_spi and simple_gpio the default value is equal to KERNEL_INIT_PRIORITY_DEVICE (no change in default value and behavior) is used. The SYS_INIT priority at which legacy forwarding of pins happens (mpsl_fem_host_init sys init priority) is intentionally not affected. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

Add simple dect sample. Signed-off-by: Eivind Jølsgard <eivind.jolsgard@nordicsemi.no>

eivindj-nordic · 2024-05-10T07:44:41Z

opened to NCS

eivindj-nordic requested review from lemrey, MirkoCovizzi and anhmolt March 21, 2024 09:40

eivindj-nordic self-assigned this Mar 21, 2024

eivindj-nordic force-pushed the dect_phy_sample branch from ab567a5 to 75b84b3 Compare April 8, 2024 08:56

github-actions bot added doc-required manifest changelog-entry-required labels Apr 8, 2024

eivindj-nordic force-pushed the dect_phy_sample branch 2 times, most recently from 72144f1 to 4eb86e9 Compare April 9, 2024 13:50

lemrey reviewed Apr 22, 2024

View reviewed changes

eivindj-nordic force-pushed the dect_phy_sample branch from 4eb86e9 to 95ee4a7 Compare April 22, 2024 13:38

jostn and others added 8 commits April 23, 2024 09:58

kconfig: openthread: nrf54L CSL parameters adjustments.

70fed93

Commit sets adjusted values for `OPENTHREAD_PLATFORM_CSL_UNCERT` and `IEEE802154_NRF5_DELAY_TRX_ACC`. Signed-off-by: Przemyslaw Bida <przemyslaw.bida@nordicsemi.no>

doc: add nrf53 features page

3f2b93a

Add a Features of nRF53 Series page Signed-off-by: Katherine Depa <katherine.depa@nordicsemi.no>

sdfw_services: Add SUIT service

1d73de1

Add service for managing SUIT-based updates. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

doc: include ns target in board name rst

5bbe994

adds ns target based on crypto samples. Signed-off-by: Anna Wojdylo <anna.wojdylo@nordicsemi.no>

manifest: Update suit-processor revision

f555303

Use suit-processor revision, compatible with ZCBOR 0.8.1. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

tests: suit: Enable unit tests

015adc2

Enable SUIT subsystem unit tests. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

eivindj-nordic force-pushed the dect_phy_sample branch from 95ee4a7 to 4a098bf Compare April 23, 2024 12:23

MirkoCovizzi reviewed Apr 23, 2024

View reviewed changes

eivindj-nordic force-pushed the dect_phy_sample branch 2 times, most recently from 1c0548f to 7cc0a6d Compare April 23, 2024 12:54

MirkoCovizzi reviewed Apr 23, 2024

View reviewed changes

anangl and others added 3 commits April 23, 2024 15:00

manifest: Update zephyr revision

e4bb53a

Pull in a fix in pinctrl that prevents the nrf_qspi_nor driver from failing to initialize when the flash chip is configured to work in non-Quad mode. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

doc: wifi: Update description for connect command

7e3b7e0

The `connect` command has been updated to take key-value style arguments. Update the description to include this information. Fixes SHEL-2699. Signed-off-by: Ravi Dondaputi <ravi.dondaputi@nordicsemi.no>

nordic-piks and others added 18 commits May 9, 2024 10:57

applications: asset_tracker_v2: Remove some thingy91x build configs

70989d9

Thingy91x has some configurations that doesn't really need to be supported and they do not fit to flash. Removing them. Signed-off-by: Tommi Rantanen <tommi.rantanen@nordicsemi.no>

manifest: update sdk-zephyr revision

17b4dc7

Update sdk-zephyr to pull in several commits cherry-picked from upstream. Signed-off-by: Jędrzej Ciupis <jedrzej.ciupis@nordicsemi.no>

samples: suit: Add smp_transfer sample

4581457

Add basic sample that demonstrates SUIT-based boot and update procedures. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

suit: Adjust ZCBOR configuration

fe11031

Require at least 3 backups to encode SUIT SSF responses and enforce canonical en/decoding if the SUIT-enabled SDFW is used. Ref: NCSDK-26629 Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>

samples: wifi: Fix synchronization issue

c6cb467

Add a sleep to address the issue where the sample doesn't wait for the WPA supplicant to be fully initialized before proceeding with Wi-Fi operations. Signed-off-by: Triveni Danda <triveni.danda@nordicsemi.no>

manifest: update sdk-zephyr revision

b1ee287

The new Zephyr revision introduces experimental EXMIF peripheral driver. Signed-off-by: Rafał Kuźnia <rafal.kuznia@nordicsemi.no>

dts: binding: Add binding for nrf2220

2129997

The compatible nordic,nrf2220-fem is added to bindings. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

mpsl: fem: initial support for nrf2220

6da8a46

This commit adds initial experimental support for nrf2220 Front-End device. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

fem_al: add support for nrf2220

b15a450

This commit adds initial support for nrf2220 Front-End device through fem_al API. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

boards: shields: add support for nrf2220ek

8794c43

This commit adds initial support for the nrf2220ek shield. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

dts: binding: Add binding for nrf2240

a13423f

The compatible nordic,nrf2240-fem is added to bindings. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

mpsl: fem: initial support for nrf2240

208fb5f

This commit adds initial experimental support for nrf2240 Front-End device. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

fem_al: add support for nrf2240

f641ec3

This commit adds initial support for nrf2240 Front-End device through fem_al API. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

boards: shields: add support for nrf2240ek

f1ea890

This commit adds initial support for the nrf2240ek shield. Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>

samples: dect: add simple sample

e7ee15c

Add simple dect sample. Signed-off-by: Eivind Jølsgard <eivind.jolsgard@nordicsemi.no>

eivindj-nordic force-pushed the dect_phy_sample branch from f07bae7 to e7ee15c Compare May 10, 2024 07:42

eivindj-nordic requested review from trantanen, tokangas, rlubos, MarkusLassila, tomi-font and stig-bjorlykke as code owners May 10, 2024 07:42

github-actions bot added ble mesh and removed changelog-entry-required labels May 10, 2024

tomi-font removed their request for review May 10, 2024 07:42

eivindj-nordic closed this May 10, 2024

		struct nrf_modem_dect_phy_rx_params rxOpsParams = { 0 };

		rxOpsParams.start_time = 0;

		FILE(GLOB app_sources src/main.c)
		target_sources(app PRIVATE ${app_sources})


		The sample shows a simple broadcast of DECT NR+ messages from one device to other devices on a hard-coded channel.

		During initialization the devices listens on the channel for broadcast transmissions.

	Dependent on the detection of transmissions, the device takes one of the following roles:
	Depending on the detection of transmissions, the device takes one of the following roles:

	* If no transmission is detected, the device takes the role as a tranceiver. In this role, the device sends an incrementing counter value on the hard-coded channel. The period between each transmission is decided by the :kconfig:option:`CONFIG_TX_INTERVAL_SECONDS` Kconfig option.
	* If no transmission is detected, the device takes the role of a tranceiver. In this role, the device sends an incrementing counter value on the hard-coded channel. The period between each transmission is decided by the :kconfig:option:`CONFIG_TX_INTERVAL_SECONDS` Kconfig option.

	* If a transmission is detected, the device takes the role as a receiver. In this role, the device listens for incomming messages.
	* If a transmission is detected, the device takes the role of a receiver. In this role, the device listens for incoming messages.

	int16_t resp=calcRSSI(crc_failure->rssi_2);
	int16_t resp = calcRSSI(crc_failure->rssi_2);

	LOG_INF("Data sent %d",tx_counter_value);
	LOG_INF("Data sent %d", tx_counter_value);

samples: dect: add simple sample #136

samples: dect: add simple sample #136

Conversation

eivindj-nordic commented Mar 21, 2024

lemrey left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eivindj-nordic Apr 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lemrey Apr 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eivindj-nordic commented Apr 23, 2024

MirkoCovizzi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MirkoCovizzi Apr 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MirkoCovizzi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eivindj-nordic commented May 10, 2024

eivindj-nordic Apr 22, 2024 •

edited

Loading

lemrey Apr 22, 2024 •

edited

Loading

MirkoCovizzi Apr 23, 2024 •

edited

Loading