Search Result

I'm currently evaluating the Shorter Connection Intervals feature of BT 6.2, and its use for low-latency HID applications. I have seen the updated HID mouse sample ( https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/samples/bluetooth/peripheral_hids_mouse/README.html ) has SCI support, with a minimum of 750us connection interval. What I find strange in this sample is that the mouse data is split into 2 reports of 3 bytes each. Is this because the reduced interval limits the payload size? It would be great if the formula to calculate the effective GATT notification payload size was made available, so developers can understand the necessary tradeoffs between connection interval (or frame space if relevant) and usable payload size. The bt_gatt_notify_cb() method returns -ENOMEM if the payload size exceeds what the MTU allows, is there a similar mechanism for SCI imposed limitations, or is the MTU adjusted to match the SCI parameters? Thanks in advance.

Hello, I am debugging a custom board that uses an nRF7002 connected to an nRF54L15. The nRF7002 power-up sequence appears to be working correctly, but the device does not start and I cannot get any response from it over SPI. I have checked the relevant supply rails and control signals: VIN: 3.3 V CONTROL: 3.3 V Regulator output: 3.3 V nRF7002 IOVDD: 3.3 V The required enable and power-control GPIOs are also being driven correctly. However, the host is unable to communicate with the nRF7002. For example, calls such as rpu_wakeup() and rpu_rdsr2() fail, and no valid status-register response is received. While reviewing the PCB layout, I noticed an important difference between my design and the Nordic reference layout. In my PCB, pins 27 and 28 of the nRF7002 are connected directly to the exposed GND pad area. In the reference design, these pins are routed separately and connected to

Hi Håkon, this is my follow-up ticket as requested here: RE: How to achieve NRF52840 ESB Maximum data rate You can see my setup in the esb_ptx application in https://github.com/stemschmidt/esb-evaluation.git I am currently able to transmit the data that I want to transmit, but only with the 4 MBit/s on-air data rate. So I assume I am not using ESB efficiently, but the documentation is really thin. You can see in the prj.conf that I tried CONFIG_ESB_NEVER_DISABLE_TX=y (which is now commented out) but that failed immediately. I also tried to use ESB_TXMODE_MANUAL to control the timing, but that did not work either: /** Manual TX mode: Packets are not sent until @ref esb_start_tx * is called. This mode can be used to ensure consistent packet timing. */ ESB_TXMODE_MANUAL , Please let me know if you find any stupid setting or handling in the project. Best regards Stefan

Dear Nordic Experts. We designed a device based on the nRF54LS05B module. We are writing a production test program and using nRF54LS05-DK Rev 0.3.1 for verification. We control the CW wave based on a radio test sample code. The datasheet states that the LS05B's TX power is 4 dBm, but when we set it to 4 dBm (radio_unmodulated_tx_carrier(0,4,40);), the actual TX power is only 2.41 dBm. When we overspec-set it to 8 dBm (radio_unmodulated_tx_carrier(0,8,40);), the actual measured TX power is 5.9 dBm. We are using SDK 3.4.0. How can we solve this problem?

SDK: nRF Connect SDK v3.3.1 Zephyr: v4.3.99 Board: nrf7002 DK I'm implementing a WebSocket server using the Zephyr HTTP server. The callback looks like: static int ws_connected_cb ( int ws_socket , struct http_request_ctx * request_ctx , void * user_data ) { while ( true ) { ret = websocket_recv_msg ( ws_socket , recv_buf , sizeof ( recv_buf ) - 1 , & message_type , & remaining , SYS_FOREVER_MS ); // ret = recv(ws_socket, // recv_buf, // sizeof(recv_buf), // 0); . . . return 0 ; } Observed Behavior - Connection succeeds. - Messages are exchanged successfully. - websocket_send_msg() works. - websocket_recv_msg() returns valid payloads. - After approximately 10 seconds, websocket_recv_msg() returns -ENOTCONN. - The callback exits. Continuous traffic does NOT prevent the disconnect. (I am sending data over the websocket using POSTMAN software. . as visible the websocket disconnects after 10 seconds exactly. I tested this multiple times and everytime

Hi nRF54L15-DK QFAAC0, ncs v3.4.0, project path: ncs\v3.4.0\zephyr\samples\boards\nordic\system_off After compiling and flashing this example, the power-on reset (POR) power consumption is abnormal, measuring 169.37 µA. However, after pressing the RESET button on the DK board, the power consumption returns to normal, measuring 1.31 µA. The following patches were added via AI assistance, but the issue persists: *(volatile uint32_t *)0x5005340C = 1; The following device tree patch: text &vregmain { status = "okay"; regulator-initial-mode = ; }; # Normal power consumption # abn ormal power consumption devzone.nordicsemi.com/.../systemoff-AI.txt devzone.nordicsemi.com/.../2318.system_5F00_off.zip devzone.nordicsemi.com/.../8267.zephyr.hex

Hi, Should COEX_GRANT (pin 43) on an nRF7000 be left floating if not used? Thanks, Alan

Hello, I ma gathering some data from nRFCloud API, and I noticed a small issue with the pageNextToken. I noticed this on https://api-docs.nrfcloud.com/#tag/FOTA-Job-Executions/operation/ListFOTAJobExecutionsForDevice , but haven't checked other endpoints. I look at a device with 20 FOTAJobExecution. When setting the pageLimit to 20, I retreive the entire list, but there is a pageNextToken. Reaching the endpoint again, with this pageNextToken results in an empty response. Same goes with 2 calls with pageLimit set to 10. It looks like there is an issue with pageNextToken . Sounds like small issue, like a bad rounding, or a >= instead of <.

Setup: - Board: Thingy:53 - Host: Mac Mini M4, 16GB, macOS Tahoe 26.6 - nRF Connect for Desktop v5.3.2, Programmer v4.8.0 - NCS v2.9.0, installed via Toolchain Manager (freshly reinstalled once during troubleshooting — no change in behavior) - Flashing: USB DFU via Programmer, dfu_application.zip built with `west build -b thingy53/nrf5340/cpuapp --sysbuild`. DFU consistently reports "Completed successfully" (~180s, including the expected net-core wait). Symptom: The completely unmodified, official `nrf/applications/zigbee_weather_station` sample builds and flashes without error, but the device shows ZERO visible activity afterward — no LED blink/pulse, no CDC-ACM console output, ever (left running untouched for 35+ minutes on one test, in case this was the "~20 minute delayed join" behavior reported by other users in devzone.nordicsemi.com/.../thingy-53-weather-station-demo-doesn-t-work — it is not; there is no activity at all, not even a delayed one). Isolation steps taken (with the help of an AI assistant, so please excuse the thoroughness — we wanted

nRF52840 DK detected by J-Link, but recovery and SWD connection consistently fail Hardware information Board: nRF52840 DK Board version: PCA10056 Failing board serial number: 1050246008 Known-good comparison board serial number: 1050227180 Host operating system: Windows x86-64 Connection: USB using the onboard J-Link debugger Target voltage reported by J-Link: 3.300 V Issue summary The onboard J-Link debugger of an nRF52840 DK is detected normally over USB, and both virtual COM ports are available. However, the onboard nRF52840 target cannot be accessed through SWD. The following operations consistently fail: nrfutil device recover nrfutil device device-info Direct SWD connection using SEGGER J-Link Commander Another nRF52840 DK of the same board version, PCA10056, successfully completed nrfutil device recover using the same computer and installed software environment. The failure therefore appears to be specific to board 1050246008 . 1. Device detection Command: nrfutil device list Output: 1050246008 Product J-Link Board version PCA10056 Ports COM8, vcom: