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

[DiBosco]

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

[Vidar Berg]

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

[DiBosco]

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. 

[Vidar Berg]

Hi,

A UUID mismatch was the only explanation I could think of. Could you share a 'diff' or a list of changes you made to main.c for the central UART sample? That way, I can try to reproduce the problem on my end.

DiBosco said:

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

The log suggests that the peripheral requires pairing with authentication (e.g., MITM protection with passkey or numeric comparison). The UART central only supports Just works pairing (no passkey or numeric comparison). Are you testing with the original peripheral_uart sample without any modifications?