Search Result

we had a issue where we used the zdo_mgmt_lqi to find what the network looked like. and we have found somthing we belive is a bug. i have replicated the issu with the zigbee light bulb exsample. if the chip is setup to be a end device, and have router inbetween in and the cordinator asking the mgmt_lqi_req the neighbor table most likly will have multible entry withe the releationship parent. my understaning is that only one entry should be parent? this was tested on nrf connect sdk 2.9.1.

Hi, We’re Hydro-Guard, a volunteer student team (TU Delft / University of Milan) building solar-powered acoustic recorders that detect illegal boats in nature parks ( short video ). We currently use an ESP32 and are considering the nRF9151 for our next generation. What the device needs to do: Continuously sample a digital MEMS mic (PDM or I²S) at 16 kHz. Run an FFT-based detector on the application core: ~75 FFTs of 4096 points per 5 s clip, ~20–40 kB working memory. Compress selected 5 s clips (~10–40 kB each) and upload them over LTE-M, up to ~100 clips/day. Run on a small solar panel + battery. Questions: Is there enough RAM left for audio buffers and this processing while the modem library and TLS are active? Can audio capture and processing keep running while the modem is transmitting? Are there samples or reference designs for audio capture + LTE-M upload

We are evaluating separate anti-rollback counters for this nRF5340 application-core boot chain: NSIB/B0 → updatable MCUboot S0/S1 → application We want to preserve authenticated bootloader recovery and application TEST/confirm/revert behavior. Pinned sources: sdk-nrf v3.4.1: b20f8619ba9a5530f8c34b0a130d829947cfe55d sdk-mcuboot: 8122be0de002ede060d37aa39b2a7f18aecc00c3 Commit 286c7454a6 , dated 12 June 2024, adds depends on !SECURE_BOOT_APPCORE to MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION , explaining that the mechanisms would conflict. The documentation and this DevZone answer confirm that the combination is unsupported, but we would like to understand the specific conflict. In the pinned source: bl_storage.h defines separate counter descriptors: NSIB = 1 and MCUboot application = 2. provision.py:add_hw_counters() can emit both records in one collection. bl_storage.c:get_counter_struct() looks up counters by descriptor. nrf_nv_counters.c uses descriptor 2 for MCUboot image ID 0. An in-memory provisioning-generator check fits 32 NSIB counter slots + 240 application counter slots + one NSIB key hash into 628 bytes of the 640-byte provision allocation, including the lifecycle/implementation-ID prefix. These

Hi, Setup: nRF54L15 with NCS v3.4.1. NSIB with MCUboot as an upgradable bootloader (S0/S1), built with sysbuild and no Partition Manager. SMP over Bluetooth. App and MCUboot updates both work. For the app, image list shows slot0: 1.0.0 . For MCUboot, the only thing we can query is active_b0_slot , which gives the slot but no version. NSIB only uses the fw_info version, and the semver from SB_CONFIG_SECURE_BOOT_MCUBOOT_VERSION only appears in the update image's header. Copies programmed with west flash ( signed_by_b0_mcuboot.hex ) don't have that header. Questions: What is the intended way for a mobile app to read which MCUboot version a device is running? Or should the backend just keep track of which MCUboot package it sent? After an MCUboot update, is checking that active_b0_slot changed the recommended way to confirm it worked? Can production program signed_by_mcuboot_and_b0_mcuboot.hex and its _s1_variant instead of signed_by_b0_*.hex , so the header and

Looking the nRF7002 reference schematics in the datasheet and I'm wondering if you really have to use so many different capacitor values for decoupling. I would like to harmonize the values to reduce the number of lines in the BOM, which would reduce cost in manufacturing. Are there any specifications about the minimum and maximum capacitance values? The MLCC capacitance under DC bias is a related matter. As we all know, for example 100nF 0201 capacitor under 3V3 might be actually something like 60 nF. For bigger caps, the loss of capacitance is even worse. Therefore, it would be nice to know what are the real required capacitances under DC bias, rather than some nominal values. Another thing I would like to protest, is that you show smaller capacitors connected in parallel with a larger one. It's based on wrong conclusion. All the caps are small SMD chips, and they

Hello, It seems that the "pageLimit" option in the REST API is no longer working. No matter what the value is set, the response to https://api.nrfcloud.com/v1/messages seem to always only contain 1 item, with the pageNextToken for the following. This used to work fine, but it's no longer (since a few days ?). Is this a known bug ? Is there a workaround ? Thanks.

Hi all, This is a real newbie for Nordic devices. I'm testing the usbd-ble-uart with an nRF52840 dongle(PCA10059) as following features. - Develop under nRF5 SDK version 17.1.1. - Using soft device 1.4.0 - firmware download with the built-in DFU bootloader It's working fine. However I found 2 dongles(HolyIOT 21017/17120) for applying into our real product. since both of them have plastic cases and antenna. I tried to download the hex file of the PCA10059. The "nRF52 SDFU USB" was running when I inserted Holy-IOT YJ-17120 into the USB slot. The programmer in the nRF connect said ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ "Failed with exit code 1. One or more program tasks failed: * ED6CF1F60BA7: Internal sdfu error: Response failure from packet: DfuResponse { opcode: ObjectExecute, result: ExtError, extended_error: SdVersionFailure, response: None } (Generic) Message: Failed, Internal sdfu error: Response failure from packet: DfuResponse { opcode: ObjectExecute, result: ExtError, extended_error: SdVersionFailure, response: None }."

Good day, I have noticed that cellular reception is very weak using an NRF9151 SMA DK. For more context, we have been using SIMCOM7080G modems in NB-IoT mode with all bands configured, we primary work on Band 3 since this is what our operators use. With the SIMCOM we are able to get and RSSI of 3-4 in poor receptions areas(around 20km from the nearest tower). Now using the exact same antenna on the NRF9151, with the exact band configuration as the SIMCOM, the NRF9151 was not able to even produce any signal reception. When searching for signal we keep in the search for signal state for up to 10 minutes, occasionally polling AT+CESQ and AT+CSQ We have tested with NB-IoT mode only, NB-IoT and CAT-M. We have set it to lock on only band 3 and to also have no lock. Is there any other configurations that need to

Dear Nordic， The device occasionally fails to receive packets sent by the power switch, but Wireshark can capture packets.The button itself is the trigger and power source for the emission, which is the working mode of the EnOcean energy harvesting switch. The number of copies N for each burst is not fixed and is determined by the energy of that press. Nodes need to support MESH and relay functions. Relay retransmission is 0, and there are no other devices in the network. Each device only has one receiving node. It may be caused by time-division multiplexing. Mesh+scan, burst sent out but it was very short, and then the RF was not on that channel, resulting in packet loss. What parameters can be changed to increase the probability of receiving broadcast messages? Attempted: 1.#define BT_MESH_SCAN_INTERVAL_MS 10 // 30->10 #define BT_MESH_SCAN_WINDOW_MS 10 // 30->10 2.CONFIG_BT_MESH_GATT_PROXY=n The above modifications have little effect and

An nRF7000-QFAA (QFN48) is used in a 2.4 GHz-only scan design: one antenna on TXRF behind a 2.4 GHz band-pass filter, no diplexer, no 5 GHz path. Scanning is restricted to the 2.4 GHz band in firmware. Current schematic: - Pin 7, TXRF : not connected (no trace, pad left open). - Pin 8, PAVDD : connected to PALDO (pin 12) together with PAVDD , as in Figure 17 of the nRF7000 Product Specification v1.1. Questions: 1. Is an unconnected TXRF acceptable for the nRF7000? The nRF7001 pin table lists pin 7 as "Reserved – Do not connect", and case 102082 states that TXRF1 can be left floating when 5 GHz is not used. 2. Should PAVDD stay on PALDO, or should it be connected to VSS? The nRF7001 pin table lists pin 8 as VSS. Does either option affect sleep current or 2.4 GHz performance? 3. If a 5