WIO terminal as BLE client, scan reports "serviceUUID: <NULL>"

Products & Technology Wio Terminal
#1

Trying to get my WIO terminal to act as a BLE client (think it is called “central” in bluetooth lingo)
To get something going I start with a BLE-scan example. I have tried a few, they all have the same problem: serviceUUID: <NULL>

Here is a chunk of output when running the code:

BLE Advertised Device found: Name: , Address: ab:74:31:fd:cd:6f
BLE Advertised Device found: Name: , Address: 90:20:2c:a4:98:44, serviceUUID: <NULL>
BLE Advertised Device found: Name: , Address: 13:21:be:02:0f:48
BLE Advertised Device found: Name: , Address: f8:e8:88:af:b0:76
BLE Advertised Device found: Name: , Address: b5:72:7f:3e:09:48, serviceUUID: <NULL>
BLE Advertised Device found: Name: , Address: da:d3:96:1f:43:16
BLE Advertised Device found: Name: , Address: ab:51:0f:68:c0:51, serviceUUID: <NULL>
BLE Advertised Device found: Name: , Address: 03:e0:b9:bd:28:f3
BLE Advertised Device found: Name: , Address: 84:db:f5:af:fc:71, serviceUUID: <NULL>, serviceUUID: <NULL>, serviceUUID: <NULL>, serviceUUID: <NULL>
BLE Advertised Device found: Name: , Address: 19:3e:57:8e:bf:ec
BLE Advertised Device found: Name: , Address: 2d:ab:9f:36:07:06
BLE Advertised Device found: Name: , Address: 2e:1f:20:0f:4b:4b, serviceUUID: <NULL>
BLE Advertised Device found: Name: , Address: 74:82:e5:4a:e4:46
BLE Advertised Device found: Name: , Address: 4b:bf:58:27:66:d5
BLE Advertised Device found: Name: , Address: 22:97:91:95:cc:f9
BLE Advertised Device found: Name: MOGUL-Device, Address: 65:32:fc:2a:5f:f8, serviceUUID: <NULL>
BLE Advertised Device found: Name: , Address: 68:27:d3:4b:66:d8

Notice when ever a device report it has services the UUID is <NULL>. I know for sure that MOGUL-Device has a valid service, verified with the nRF Connect app.

I have tried both in Arduino-IDE and PlatformIO+vscode. And the two BLE-scan programs are

Anybody know how to get the scan to actually find some service UUID’s too?

I don’t think scan is the only thing not working, I have tried just to connect to a peripheral even when scan couldn’t find a service, but then it just goes haywire when I then try to use the service I know is there.

1 Like
#2

I am experiencing the same issue with the BLE scanner on the SEEED Wio Terminal. It cannot discover services.

I have spent a significant amount of time trying to resolve this issue, but I have not been successful. Discovering custom UUIDs to communicate with peripherals is a basic and critical feature, yet the SEEED BLE scanner fails to discover or submit the UUID services of peripherals.

I have tried multiple approaches, including discovering services both before and after connection, adding delays after connection, and implementing retries in the code. I even attempted to explicitly send messages to services without discovery, but all these efforts failed. It seems there may be a major issue with either the SEEED BLE hardware or its libraries.

Since I purchased the SEEED Wio Terminal specifically for BLE scanning and testing, it will be rendered useless for my purposes if this problem cannot be resolved.

For examle, I can not find UUID of STM32 OTA write which is:
serviceUUID = “0000FE20-CC7A-482A-984A-7F2ED5B3E58F”; // Primary Service
and
“0000FE22-8E22-4541-9D4C-21EDAE82ED19”; // Write Without Response

But with an old MCU like nrf52832, I can easily connect and discover services and send/recive data trought them.

#3

Hi there,

You sure its BLE 5.0 or is it BLE Classic? it makes a difference, for example some older Iphones won’t find a BLE 5.0 device, unless compatibility mode.

HTH
GL :slight_smile: PJ :v:

#4

I tested several peripherals that have 128-bit custom UUIDs for different Services, Seed can not find any of them. With nrf-Connect App on the ios, I can see those are fine, but Seed can not find them. Also, with nrf52 MCU series, I can find them and connect to the peripherals and then discover services and UUIDs, and send/receive data trough them. But Seed Wio can only connect to the peripherals and is not able to find 128-bit UUIDs, so I can not send/receive data with peripherals which have 128-bit UUIDs. I tried manythings, and still not able to fix it.

#5

Hi there,

So which BLE lib are you using and Which BSP are you using for the Nrf52 side?
roll it back and try again… :v:
HTH
GL :slight_smile: PJ :v:

Post the code , using the code tags above " </> " paste it in there. :+1:

1 Like
#6

Hi,

Thank you for following up.

I am using the libraries recommended in the Wiki, similar to the Client example provided there: [Client and Server introduction | Seeed Studio Wiki]

#include "rpcBLEDevice.h"
#include <BLEScan.h>
#include <BLEAdvertisedDevice.h>

Rolling back is not an option for me because the nRF platform uses its own SoftDevice and C-based libraries, which are entirely different from Arduino libraries.

If you or anyone else knows of an example to send/receive data through custom 128-bit UUID services with the Wio Terminal acting as a Client (Scanner), please share the code or a link. It would be greatly appreciated.

Thank you!
Hossein

#7

Hi there,

Ok, did you update the wireless core?
What about the UART UUID did that work, if not then it’s a LIB issue or something else.
I’ll set this up and try it, time permitting… I have the same hardware.

GL :slight_smile: PJ :v:

1 Like
#8

Thank you for your reply.

Yes, On the Arduino IDE, the Wio Terminal core is 1.8.5 (Seeed SAMD Bords).
And Yes, I updated the BLE core (RTL8720 firmware) to the latest version (2.1.3). I even tried some older versions, as I thought the issue might be with the core rather than the Seeed Arduino libraries. But, that didn’t resolve the problem, so I’ve reverted to using the latest version again.

The Seeed Wio Terminal can connect to peripherals (Servers) successfully but is unable to discover or detect their 128-bit UUIDs. As a result, it cannot send or receive data (read/write) on those services, making communication with the servers entirely impossible.

Regards,
Hossein

#9

Hi there,

So sounds to me like you have checked all the cross streets on this. I feel pretty sure it’s a LIB issue, I need to set it up to test for sure, seem strange only the samd though, I’ll setup an additional Xiao to connect to the UUID thats 128 bit with notify ON.

Meanwhile , If Seeed engineers or support Have anything on this Phenomenon a.k.a bug Please enlighten us.

HTH
GL :slight_smile: PJ :v:

I’m looking for the freeCad file for the enclosure as well So I asked over on the Discord server see what shakes out :+1:

1 Like
#10

It would be great if I could get it to work. Since this is a general-purpose and useful feature, other users may also need it later. Having an example that demonstrates how to define 128-bit UUIDs, discover them after connection, and send/receive data through them would showcase the full capabilities and features of the SEEED Wio with BLE.

On the nRF (Nordic) MCU, there are many examples for client (Scanner/Central) functionality that define 128-bit UUIDs as follows:

#define NUS_BASE_UUID                   {{0x47, 0x71, 0xD0, 0x2A, 0x6C, 0x53, 0x52, 0x8A, 0x56, 0x4E, 0x08, 0xA3, 0x00, 0x00, 0x52, 0xB4}} /**< Used vendor-specific UUID. */
#define BLE_UUID_NUS_SERVICE            0x0100                      /**< The UUID of the Nordic UART Service. */
#define BLE_UUID_NUS_RX_CHARACTERISTIC  0x0101                      /**< The UUID of the RX Characteristic. */
#define BLE_UUID_NUS_TX_CHARACTERISTIC  0x0102                      /**< The UUID of the TX Characteristic. */

These UUIDs are then utilized in the main.c file, like this:

/**@brief NUS UUID. */
static ble_uuid_t const m_nus_uuid =
{
    .uuid = BLE_UUID_NUS_SERVICE,
    .type = NUS_SERVICE_UUID_TYPE
};

To send data via the UUID service:

ble_nus_c_string_send(&m_ble_nus_c, cBuffer_, 5);

To receive data, the ble_nus_c module’s event handler is used, as shown below:

switch (p_ble_nus_evt->evt_type)
{
    case BLE_NUS_C_EVT_DISCOVERY_COMPLETE:
        ble_nus_c_handles_assign(...);
        ble_nus_c_tx_notif_enable(p_ble_nus_c);
        // Discovery completed; perform additional actions now if you want.
         ....
        break;

    case BLE_NUS_C_EVT_NUS_TX_EVT:
        ble_nus_chars_received_uart_print(...);
        // Handle received data here.
       ...
        break;

    case BLE_NUS_C_EVT_DISCONNECTED:
        // Handle disconnection and restart scanning.
        ...
        scan_start();
        break;
}

This kind of comprehensive example would greatly illustrate the full potential of the SEEED Wio BLE capabilities and simplify implementation for developers."

1 Like
#11

Hi there,

I couldn’t agree more. The BLE has become the MOST important close network comm tool of the century. something like 60 Billion BLE device… WOW :exploding_head:

I have been preaching to the choir about the Nordic advantage on NOT just the Superior hardware but the Phenomenal support and Software to help and SOLVE problems not present them to the maker, Like some companies.

Now Seeed is the only company caring enough to continue on providing innovative tech for makers but sometimes I feel they are distracted too much by the shiny new thing in the Space. SOFTWARE is a secondary item. NOT with AI they are finding that out forsure…

So even though great HARDWARE products it takes software and support to get the most repeat business. A lot of competitors jumping into AI hardware space and being first may make you end up LAST!.
Just look at all the jetson nano post issues’ with more to come with these new more complex models coming on-line.
reCamera is going to be one of those I’m thinking… time will tell.

GL :slight_smile: PJ :v:

I’ll keep looking for this UID-128 bit issue more this weekend. :+1:

1 Like