Can connect to uart_peripheral by UUID, but can't connect to a non-Zephyr product

I have managed to get, somehow, a central_uart talking to a peripheral_uart on a pair of  52840 DKs.

I've changed the UUIDs of what I'm trying to connect to, to be those of a different device that has BLE in it.

I've previously connected to this using an RPi and its UART, getting data in and out of it. So I went PC UART <-> Rpi BLE <-> Other Unit

Am trying to repeat that but using the 52840 DK

I've taken the central UART project and changed the code  do to this:

#define XLRT_SERVICE_UUID_VAL \
BT_UUID_128_ENCODE(0x2a1f963c, 0x143a, 0x4f7d, 0x9107, 0x6315196a02a6)

/** @brief UUID of the TX Characteristic. **/
#define XLRT_TX_UUID_VAL \
BT_UUID_128_ENCODE(0x651135b0, 0xdfe9, 0x45a2, 0x95c1, 0x46552a8a77e2)


/** @brief UUID of the RX Characteristic. **/
#define XLRT_RX_UUID_VAL \
BT_UUID_128_ENCODE(0xe7d6274e, 0xb765, 0x11e9, 0xa2a3, 0x2a2ae2dbcce4)


#define BT_UUID_XLRT_SERVICE BT_UUID_DECLARE_128(XLRT_SERVICE_UUID_VAL)
#define BT_UUID_XLRT_RX BT_UUID_DECLARE_128(XLRT_RX_UUID_VAL)
#define BT_UUID_XLRT_TX BT_UUID_DECLARE_128(XLRT_TX_UUID_VAL)

Previously this worked fine connecting to the peripheral_uart example project running on the second 52840DK. The only thing I have done is change the UUIDs of the service I want to connect to and the the UUIDs of the two characteristics that I want to read from  and write to.

Can you think of any reason why it would connect to the DK running peripheral_unit and not this other unit? The other unit has an older chip in, using SES and has   the same types od read/write characteristics.

I would expect it to simply connect to the unit because the service UUID matches, even if the BLE data might not get to/from at first due to some other bug in the code. I'm nevere getting the call to function:

static void connected(struct bt_conn *conn, uint8_t conn_err)

Which I do if I try to connect to peripheral_uart.

Thanks
Parents
  • Hi,

    I would also expect the connection to be established. I assume the scan_filter_match callback is not invoked either? This usually suggests that the service UUID declared in the firmware does not match the UUID included in the advertisement. Could you please double or tripple check that the UUID is correct? Note that in the nRF5 SDK, the UUID was declared in little-endian format, while in the nRF Connect SDK it is big-endian. The UUID declaration in the nRF Connect SDK should match the representation used for UUIDs in the nRF Connect app on Android/iOS.

    Best regards,

    Vidar

  • Hi, yes,

    scan_filter_match
    is never called. I get this in the temrinal at boot:

    [00:00:00.025,482] <inf> central_uart: Scan module initialized
    [00:00:00.025,512] <inf> central_uart: NUS Client module initialized
    [00:00:00.030,548] <inf> central_uart: Scanning successfully started

    I have checked the UUID over and over, it's what I would have expected to be wrong. I put the app on my Android  phone to see if the UUID looked any different to others BLE Android apps, but it looks identical there too.

    If I go back to the Nordic UUIDs to pair up with another DK running peripheral_uart exampkle I get this:

    [00:00:00.025,451] <inf> central_uart: Scan module initialized
    [00:00:00.025,482] <inf> central_uart: NUS Client module initialized
    [00:00:00.030,487] <inf> central_uart: Scanning successfully started
    34:A3:0A:8F:0A (random) connectable: 0
    [00:00:00.389,465] <inf> central_uart: Connected: C8:34:A3:0A:8F:0A (random)
    [00:00:00.389,831] <err> central_uart: Stop LE scan failed (err 0)
    [00:00:00.591,033] <inf> central_uart: MTU exchange done
    [00:00:00.691,009] <err> bt_smp: pairing failed (peer reason 0x3)
    [00:00:00.691,253] <wrn> central_uart: Security failed: C8:34:A3:0A:8F:0A (random) level 1 err 4
    [00:00:00.691,436] <wrn> central_uart: Pairing failed conn: C8:34:A3:0A:8F:0A (random), reason 4

    Which looks a bit odd, seems like it's saying it failed to "pair", but does work. I thought pairing wasn't a word used with LE BTW. 

  • I did build with 2.8.0, yes.

    How do you program a hex file with VSC please?

  • BTW, for your hex file, we'll need full UART debugging turned on for me to know whether it's connected.

  • You can program them from the command line with nrfjprog:

    nrfjprog --program HEXFILE.hex --chiperase --verify -r

    Or with the Programmer app in nRF connect for desktop

    BTW, for your hex file, we'll need full UART debugging turned on for me to know whether it's connected.

    I did not enable logging over UART. Any particular reason you can't view the logs with RTT?

  • Out of sheer desperation, I deleted your project, re-unzipped it, and tried again and this time it builds.

    It will not connect to our device.

    I would like to try connecting via a MAC address instead, but there's no documentation about the syntax. I've asked on separate thread and ther was a suggestion that ignored the syntax issue and I've not heard back on that for a day or so.

  • Please use the nRF connect app to confirm that the peripheral is including the service UUID in its advertisment payload:

    DiBosco said:
    I would like to try connecting via a MAC address instead, but there's no documentation about the syntax. I've asked on separate thread and ther was a suggestion that ignored the syntax issue and I've not heard back on that for a day or so.

    I haven't read the other ticket, but you can search the SDK tree for 'BT_SCAN_FILTER_TYPE_ADDR' to find examples of where the address filter is used. 

    	bt_addr_le_t addr = {
    		.type = BT_ADDR_LE_RANDOM,
    		.a.val = {0x62, 0x21, 0x24, 0xDB, 0xA0, 0xE8},
    	};

Reply
  • Please use the nRF connect app to confirm that the peripheral is including the service UUID in its advertisment payload:

    DiBosco said:
    I would like to try connecting via a MAC address instead, but there's no documentation about the syntax. I've asked on separate thread and ther was a suggestion that ignored the syntax issue and I've not heard back on that for a day or so.

    I haven't read the other ticket, but you can search the SDK tree for 'BT_SCAN_FILTER_TYPE_ADDR' to find examples of where the address filter is used. 

    	bt_addr_le_t addr = {
    		.type = BT_ADDR_LE_RANDOM,
    		.a.val = {0x62, 0x21, 0x24, 0xDB, 0xA0, 0xE8},
    	};

Children
Related