Search Result

The example layouts for the nRF7002 CEAA make use of microvias for escape routing, which makes sense. However, those microvias are also used to connect the ground associated with the RFBUCKVDD/PWRBUCKVDD net to a ground plane on layer 2 (pink arrow in the picture) and then other buried vias are used to connect that layer 2 to a ground plane on layer 3 (orange arrow in the picture). I understand the intention of the ground cutout on layers 1, 2, and 3 that isolate this buck section of the circuit's ground planes and why there is a ground plane on both layers 2 and 3. What I'm not understanding is why the layout doesn't just use through-hole vias to connect the top layer ground net to both layers 2 and 3 at once. This would be much cheaper to manufacture and simpler than requiring the addition of buried vias and

Hello Nordic Support Team, I am using the nRF5340 Audio DK with the nRF Audio application provided with the nRF SDK, configured as a Unicast Server. The board advertises correctly, and when I check it using the nRF Connect app, I can see the expected LE Audio-related services/profiles. However, when I connect the nRF5340 Audio DK to a **Pixel 8 or Pixel 8a running Android 17, the connection is successful, but I don't see any LE Audio-related options or on/off settings on the phone side. Could you please confirm if any additional configuration is required on the nRF side or Android side to enable and establish the LE Audio connection? Thank you.

## Environment - nRF Connect SDK v3.4.0-99553055607b, Zephyr v4.4.0-bf801e4e3d19 - SoftDevice Controller on the nRF5340 network core (`ipc_radio`, `CONFIG_BT_LL_SOFTDEVICE=y`), HCI reports "Standard Bluetooth controller (0x00) Version 200.12506 Build 888207768" - Reproduced in BabbleSim (`nrf5340bsim`, `bs_2G4_phy_v1 -dump`). It is also seen on hardware (nRF5340 Audio DK, BlueZ central), where the link later ended with 0x28 (Instant Passed) or 0x08. ## Setup - DUT: peripheral, synchronized to a BIG (10 ms ISO interval, one BIS), PA synced. No CIS. - Central: a second device (SDC central in bsim) on a 1001.25 ms (801 units) connection to the DUT. - The DUT host asks for 11 units (13.75 ms) through the connection parameter update procedure. The central sends: `LL_CONNECTION_UPDATE_IND winSize=1 (1.25 ms) winOffset=0 interval=11 latency=0 timeout=600 (6 s)`. ## Observed (phy dump, link access address 0xE8CB3499) BIG held at the switch: ``` 95.044075 DUT rx link st=1 last packet on the old 801-unit

When running the modems gnss in single shot mode with external 600 second interval timer and periodic mode with the same 600 second interval, what differences are there in the modems behavior? For example are there some different optimization how previous valid fixes are used to aid in the next fix, how often is a-gnss requested? What I could gather from the gnss configuration documentation is that in periodic mode the gnss performs scheduled downloads for some gnss parameters and that this could be disabled if a-gnss is in use, but other than that I did not see any documentation of any differences.

This should be simple. Where do I add my webhook to NRF cloud? I have a physical device and the events from the device are showing up in NRFCloud. However, when I add the webhook link, I am not getting any events from NRFCloud. How i can get events from there side. Can somebody show me the flow where to add webhook so I can reliably get updates. Cos the webhook i added is not getting events and without that i cannot trigger anything on app side.

I am attempting to implement an HID device able to pose as a keyboard to the BIOS/UEFI and every OS. For this, I have created this code: https://github.com/dakhnod/BLEnky/blob/feature_hid_usb/src/ble/services/hid/usb_hid.c In line 85, if I change the class to APP_USBD_HID_SUBCLASS_NONE and APP_USBD_HID_PROTO_GENERIC, macOS recognizes my device without issues. Leaving the configuration like it is makes macOS ignore any keyboard inputs, strangely. I am receiving APP_USBD_HID_USER_EVT_SET_REPORT_PROTO, but I am unsure on how to handle that, since my descriptor should make the OS understand the boot protocol. Yet, with boot support, sending `00 00 04 00 00 00 00 00` yields nothing. With the generic configuration, the same payload yields to an 'a' being typed. What could I be missing here in order to support boot protocol? Thanks!

I'm running the central_hci example, initially on an nRF54LM20 DK and then on an nRF52840 DK. I'm trying to pair with a Redragon Antonium Pro 108 keyboard. The sniffer capture indicates that it never gets past the CONNECT_IND. Comparing this with a pairing I was able to successfully perform with my phone indicates that the only difference in the CONNECT_IND is the transmitWindowOffset, which is 0 on the DK. I found the SoftDevice Controller compatibility-mode window-offset command, hci_vs_sdc_compat_mode_window_offset_set, and tried this using version 3.4.1 of the SDK on the 54 DK, but hit an asserttion 57, 2024. I then started going back in SDK versions and using the nRF52840 as well. I had to use the direct SDC API function, sdc_hci_cmd_vs_compat_mode_window_offset_set, on earlier versions since the hci_vs_sdc_compat_mode_window_offset_set wasn't supported earlier. The direct call succeeds on NCS v2.4.0 but crashes on later releases. The test calls sdc_hci_cmd_vs_compat_mode_window_offset_set() after bt_enable() and holds

Currently, the ncs-serial-modem releases seem to be signed with the default signing key. Does Nordic plan to sign releases with a private Nordic key so we can be ensure non-Nordic-built images cannot be OTA'd to the device? Right now, our plan is to have a github action that would pull ncs-serial-modem and make a build with our own key. Ideally, we wouldn't have to do that and could use Nordic-signed builds. I believe something like this was discussed for nrf91m1 builds. Thanks, Konstantin

Hello, I am having an issue with nRF54LM20 rev B silicon where the gpio interrupts are not consistent for key functions with either code similar to the button demo or gpio-keys. I have tried with both CONFIG_PM_DEVICE_RUNTIME set to Y and N and I still need to use polling mode. Currently my keys are on gpio1 and I updated the edge sense mask. Is there something I am missing. I am on sdk 3.4.1. I now know that gpio2 can not be used since there is not GPIOTE and that will be changed on the next rev. buttons: buttons { compatible = "gpio-keys" ; status = "okay" ; debounce-interval-ms = ; no-disconnect ; /* FORCES PINS TO STAY CONNECTED */ polling-mode ; button0: button_0 { gpios = ; label = "Push button 0" ; zephyr,code = ; }; button1: button_1 { gpios = ; label = "Push button 1" ;

We are integrating Memfault Bort SDK 5.11.0 into an Android 16 AOSP device. According to the AOSP Integration Guide, we need to create a project with the project type Android (AOSP) . However, with the new nRF Cloud onboarding flow, a project is automatically created without providing an option to select Android (AOSP). When Bort tries to retrieve the Android SDK settings, the server returns: SDK settings are only supported for Android and Linux projects We also cannot create another project because the new nRF Cloud experience currently supports only a single project. Could you please enable/create an Android (AOSP) project for our organization, or advise how Android AOSP projects should be created with the new nRF Cloud onboarding flow?