Search Result

I followed the documentation, I'm also using nrf- but I still got:

how could I recover data from the internal sensors of the thingy 91 card via bluetooth

I hope someone can help me here with my question. In my project we are using a nrf9160 with modem fw version 1.3.5. The application sends/receives data periodically (1 hour etc) using nB-Iot. Meanwhile it is in PSM. We were running for several times in the last months/years into a modem state that it hangs and a connection can not be established. There were several reasons, previous modem firmware versions that were buggy etc etc (not only in my project) ... There is a fault handler implemented as I see which might help https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/nrf_modem/doc/fault_handling.html The goal is to detect whether the modem is in a functional state and could connect if a connection can be established. Excepts the fault handler that directly signals a not functional state of the modem, are there any other ways how to detect whether the modem is functional? Sending AT-commands periodically? Unfortunately I did not

can i add wifi in nordic thingy 91

Hi, I am using custom board (nRF9160) and zephyr V2.6 and I would like to make sure that I understand the ADC settings correctly in the device tree: channel @ 1 { reg = ; zephyr,gain = "ADC_GAIN_1_4" ; zephyr,reference = "ADC_REF_VDD_1_4" ; zephyr,vref-mv = ; zephyr,acquisition-time = ; zephyr,input-positive = ; /* P0.16 */ zephyr,resolution = ; zephyr,oversampling = ; }; 1- "ADC_REF_VDD_1_4"; means I am using the board power supply as a ref ? it is 3.38V 2- vref-mv is 3.38 / 4 3- oversampling = ; is this the sampling rate ? so every time I execute adc_read_dt function, 256 samples will be collected ? 4- I am measuring the voltage every 100ms once, is ADC_ACQ_TIME_MICROSECONDS , 3 considered suitable ? 5- when the voltage is 33mV the ADC reads it as 23mV, I measured the physical pin and it is 33mV, why such difference ?

Hi everyone, I have a fairly mature project that I am now required to add MCUboot to so that remote firmware updates can be possible. I am building for a custom board based upon the NRF9160. I have verified the following things so far: My project builds with CONFIG_MCUBOOT=n without issue I can build a simple sample (hello world) with CONFIG_MCUBOOT=y on my custom board I get the following output message from the build process: Building SG-Firmware west build --build-dir /home/cmabon/Documents/Projects/SG-Firmware/build_primary /home/cmabon/Documents/Projects/SG-Firmware --pristine --board crm_nrf9160_primary_ns --no-sysbuild -- -DNCS_TOOLCHAIN_VERSION=NONE -DBOARD_ROOT=/home/cmabon/ncs/v2.4.1/zephyr;/home/cmabon/Documents/Projects/SG-Firmware -Db0_OVERLAY_CONFIG=/home/cmabon/ncs/v2.5.0/nrf/subsys/partition_manager/partition_manager_enabled.conf -Dmcuboot_OVERLAY_CONFIG=/home/cmabon/Documents/Projects/SG-Firmware/child_image/mcuboot.conf;/home/cmabon/ncs/v2.5.0/nrf/subsys/partition_manager/partition_manager_enabled.conf -DCACHED_CONF_FILE=/home/cmabon/Documents/Projects/SG-Firmware/prj.conf -DDTC_OVERLAY_FILE=/home/cmabon/Documents/Projects/SG-Firmware/boards/crm_nrf9160_primary_ns.overlay -- west build: generating a build system Loading Zephyr default modules (Zephyr base). -- Application: /home/cmabon/Documents/Projects/SG-Firmware -- CMake version: 3.20.5 -- Found Python3: /home/cmabon/ncs/toolchains/7795df4459/usr/local/bin/python3.8 (found suitable version "3.8.2", minimum required is "3.8") found components: Interpreter -- Cache files will be written to: /home/cmabon/.cache/zephyr -- Zephyr version: 3.4.99 (/home/cmabon/ncs/v2.5.0/zephyr) -- Found west (found suitable version "1.1.0", minimum required

what should i do to get the what should i do to get the thingy91 connected to LTE Network ? the SIM has been acitvited but i still cannot connect the Dk to the network.thingy91 connected to LTE Network ? the SIM has been acitvited but i still cannot connect the Dk to the network.

Hi, We've got a board with a fairly limited power supply in production and it's expected to brown out under certain conditions. As such, I need to verify the reset loop prevention described in this Nordic Semiconductor white paper. I'm using mfw_nrf9160_1.3.5 and SDK 2.0, so I expect the prevention to trigger after 7 resets. To test this I unconditionally trigger a connection during the boot sequence and have our power supply limited to ~30 mA to trigger a brown out. I can see +CEREG: 2 and +CSCON: 1 just before each reset, so the device appears to be browning out during active comms, but it never triggers the reset loop prevention. I let it reset approx 20 times before stopping the test. I never call +CFUN=0 and can't it doesn't appear to be called from any sdk code as if I breakpoint in `lte_lc_func_mode_set` it never triggers. Any help

I have two nrf9160DKs that are talking to each other over BLE. Things are working fine but I want to eliminate some of the external noise in my environment. Is it possible to connect the two J3 connectors and expect it to work? Thanks Mike

Hi, I started fesh on a new laptop, installed nrf Connect for desktop. I used VS Code to install the the latest nrf toolchain and sdk, verison 2.6.1, as they recommend that using Vs code is the preferred method. I then installed the quickstart app, version 0.2.6, inside nrf connect for desktop and tried to flash a sample. Flashing was unsuccessful and with error as seen in the attached images. I also tried flashing a sample using the nrf extension in VS code and got a similar error. It seems that the J-Link programmer is not detected. I have also tried using the programmer app version 4.3.0 but also no success. See attached log file. I hope to hear from you soon. Best regards, devzone.nordicsemi.com/.../2024_2D00_05_2D00_14T17_5F00_52_5F00_18.234Z_2D00_log.txt