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. 

  • 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?

Reply
  • 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?

Children
  • [Edit] Clealry my attempts to upload information clearly didn't work, I'll try another way.

    Does this  zip work for you? It's the three source files I am using. I took the central_uart project and have started modifying various things as I slowly begin to understand what's going on. Things like getting rid of mallocs, unnecessary queues and generally trying to make it read more like embedded code rather than desktop code (and better comments long term). 

    It's very much in flux at the moment and every time I change anything I ensure the wireless UART functionality still works by having an FTDI TTL level lead connected to RX and TX of each DK, typing in one terminal emulator and seeing it come out of the other end.

    As things stand it works as a central node and connects to the standard peripheral_uart project. So I have one DK as central and another as peripheral and send data via a pair of 240 byte characteristics.

    The one and only thing I change for it to go from connecting to the peripheral UART to not connecting to our custom hardware is in btle.h where I remove the

    #define NORDIC_UUIDs

    So it attempts to connect to our hardware with its cusom UUID of 0x2a1f963c, 0x143a, 0x4f7d, 0x9107, 0x6315196a02a6.

    Now, as far as I  can make out:

    CONFIG_BT_NUS_AUTHEN

    is not defined, I can't see:
    #define CONFIG_BT_NUS_AUTHEN

    But, and it's a big but, I can't get my head around this
    arcane ecosystem so maybe it's defined somewhere else in a
    file somewhere I'm not aware of and it should be defined.
    Maybe the fact I took out the:

    #ifdef CONFIG_BT_NUS_AUTHEN
    BT_GATT_PERM_READ_AUTHEN | BT_GATT_PERM_WRITE_AUTHEN),
    #else

    Bits and that is a problem, although I doubt it because previously in the project these ifdef lines were greyed out.

    I can't stress enough that the project works with both central and peripheral projects modified, the peripheral one lightly, the central one more heavily. 

    Here is a screenshot of the nrf Android App and what I'm trying to connect to. I can't see any issue with the service UUID being different to what's in the app and in fact I copied and pasted that UUID from the source code which was written to work on SES for another Nordic processor, but done with the infinitely superior SES.

    Although I'm not sure that jpeg has worked.

  • See if you can get the image and the zip here instead, the upload function of this website doesn't work for me.

    www.apostrophe.co.uk/.../src.zip

Related