Search Result

Hi, Im designing a custom board using a NRF9160 MCU. From the product specification it operates at a voltage range of 3.0(2.8)-5.5V. I want to use a 3xLI socl2 3.6v (parallel) battery to power the MCU, however this battery can go down to 2.0V. Would I need a boost converter to ensure that I have a stable voltage for when the battery starts to go low ? Thanks!

We have devices that have low signal so they have to reconnect to AWS a lot. We have a watchdog timer with a 100s timeout that we feed every 10 seconds in the control loop. Occasionally we see the device hit the 100s watchdog timer and reset when connecting to AWS. Environment: Only see with devices with low signal nRF Connect SDK v3.5.99-ncs1-1 SDK and tool chain: v2.6.1 Tf-M v2.0.0 MODEM_INFO_FW_VERSION: mfw_nrf9160_1.3.6 LTE-M cellular connected in the U.S. Configs: CONFIG_AWS_IOT_CONNECT_TIMEOUT_SECONDS =30 Code: LOG_INF("Connecting to AWS IoT broker"); const struct aws_iot_config config = { .client_id = client_id_buf, .host_name = CONFIG_AWS_IOT_BROKER_HOST_NAME, }; int start_time = k_uptime_get(); // This is synchronous and cant take a while (30+ seconds) err = aws_iot_connect(&config); Logs: [00:06:04.668,487] [0m cloud: Connecting to AWS IoT broker [00:06:04.674,621] [0m mqtt_helper: broker_init: Resolving IP address for [deleted] [00:06:06.815,155] [0m mqtt_helper: broker_init: IPv4 Address found [deleted] (AF_INET) [00:06:06.823,944] [0m mqtt_helper: mqtt_state_set: State

Good evening, I noticed that the IMEI for the nRF9161 is not embedded like it is for the nRF9160, and it requires retrieval either through nRF Cloud or via the API. However, when I attempt to request the IMEI, I am prompted to upgrade my nRF Cloud license from the Dev plan to the Pro plan, which incurs a monthly cost. Is there any way to obtain the IMEI for the nRF9161 without needing to pay for the Pro license? Thank you in advance!

Dear Nordic, We made an attempt to use the external flash in the LwM2M sample. We tried to follow this: docs.nordicsemi.com/.../nrf9160_external_flash.html As soon as we add: ' / { chosen { nordic,pm-ext-flash = &mx25r64; }; }; The sample stops working, it does not even start. We guess, it is related with MCUBoot issue or not having pm_static.yml file. Could you please tell us how the proper configuration shall look in this case? Regards, Marcin

My NCS version is 2.6.1, and the modem firmware version is 1.3.6 I found that delta upgrade often fails when testing the firmware of FOTA upgrade modem for 9160. Currently, I have discovered that there are some issues with the dfu_target _offset_get function in the dfu_target header file. According to the upgrade process, the first step is to use dfu_target_init, which requires passing in a parameter to determine the update type. When I successfully initialize with DFU_TARGET_IMAGE_TYPE_FULL_MODEM , I then use dfu_target _offset_get to read the flash area in the modem used to store the update firmware. Generally, a normal result is obtained, which is 0. Then, I continue to use dfu_target_write to loop through the modem and write the new firmware. I choose to write 2k each time. When I write 2 times, that is, every 4k data is written, and then use dfu_target_write again, I will get a

The instructions are: On the command line, open the directory ncs . The following steps have one do a west init directly in the directory ncs. But they should say to create a directory below ncs that is identical to the nRFConnectSDK_revision and cd to that directory prior to doing west init and west update. The existing instructions are inconsistent with the diagram below step 6. And inconsistent with every other method you have for setting up a west workspace. Can you fix the documentation? I know it has been this way for many years; always incorrect, AFAICT. Thanks. Burt Silverman

Hi, I want to connect LDC2114 to nRF9160. I write the nrf9160dk_nrf9160_ns.overlay and the astri,ldc2114.yaml. I don't know how to set GPIOs in & i2c1 - ldc2114: ldc2114 @ 2a which are the output pins of LDC2114 and input pins of nRF9160. devzone.nordicsemi.com/.../1462.nrf9160dk_5F00_nrf9160_5F00_ns.overlay.txt devzone.nordicsemi.com/.../2308.astri_2C00_ldc2114.yaml.txt Also, What else should I do in order to connect the devices? Best regards, Liza

Hi! I have built a sample application "location," got some warnings, and got runtime errors. I have attached a zip file with code and images. I just have reinstalled nRF Connect Desktop, nRF Command Line Tools and VSC extension, I think I have some problems with my setup My setup: Updated Windows 11, Spanish SDK 2.6.1 and 2.8.0 Any hints would be greatly appreciated. devzone.nordicsemi.com/.../location.zip

There was no problem when the current version of ccache was 4.6.1. However, the current version of ccache, 4.10.2, behaves differently with the --specs option. It will do nothing at all with NCS. To correct this, I make this change diff --git a/cmake/modules/ccache.cmake b/cmake/modules/ccache.cmake index c1d41d6b9e4..14b9b683519 100644 --- a/cmake/modules/ccache.cmake +++ b/cmake/modules/ccache.cmake @@ -9,7 +9,7 @@ if(USE_CCACHE STREQUAL "0") else() find_program(CCACHE_FOUND ccache) if(CCACHE_FOUND) - set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache) + set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "ccache ignore_options=--specs=picolibc.specs") set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache) endif() endif() Thank you for any possible correction. I guess in the Linux case you include ccache in the Zephyr toolchain and it is a version that works. Burt Silverman

Hi, I’m experimenting with the nrf9160 LTE modem in poor network conditions. I would like to be able to keep track of how long the modem spends searching for LTE networks. I had assumed that we could do this by observing the registration status events emitted by the modem and tracking time spent in the LTE_LC_NW_REG_SEARCHING state but that appears to be insufficient. Here are some timestamped logs I captured during testing, showing the values of the lte_lc_nw_reg_status events emitted from the modem : 00:01:42.464 Sleep exit: LTE_LC_MODEM_SLEEP_FLIGHT_MODE(4) 00:02:01.638 Reg status: LTE_LC_NW_REG_UNKNOWN (4) 00:03:27.269 Reg status: LTE_LC_NW_REG_SEARCHING (2) 00:03:29.888 RRC status: LTE_LC_RRC_MODE_CONNECTED (1) 00:03:30.947 Reg status: LTE_LC_NW_REG_REGISTERED_HOME (1) From power measurement I can see that the modem begins LTE searching after the LTE_LC_NW_REG_UNKNOWN event, and it continues to search until 03:29 when it connects. What can be inferred about the modem’s search behavior when we receive the LTE_LC_NW_REG_UNKNOWN event? Why