How to cconnect ESS Client to ESS Server using the service UUID

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RoSy_3754371
Level 1
Level 1
First like given

Hi

I am having trouble understanding how to connect a ESS client to ESS server using the service UUID.

I edited the SimpleBLECentral code to scan for Bluetooth devices and connect to a server with a advertisement packet length of 30. This works fine but the client connects to any device with a packet length 30. I want to edit this by connecting to a ESS peripheral device (with the UUID 181A).

The SimpleBLECentral project compared the scanned servcie UUID with an expected UUID and if the are the same, it pairs and does whatever it needs to thereafter.

For my project I cannot find the required reference for the expected ESS UUID.  Is my approach incorrect? How do I get around this? Below is the particular snip of code i am working on. I have commented out the other if statements (SimpleBLECentral and the length statements) and highlighted where my issue is. My guess is there is no direct reference o the UUID, but I get lost when it comes to deciphering the structure pointers, and I am not confident i understand how they reference the correct member.

Additionally, I am having trouble actually printing out the UUID when I do connect to a ESS it in the message printed once. This is a minor issue but if you can see where my issue is as regards this, id be grateful if you can point me in the right direction.

Thanks in advance for any help.

       case CY_BLE_EVT_GAPC_SCAN_PROGRESS_RESULT:          

           

            // Print Out Information about the Device that was found

            printf("Device ");

           

            cy_stc_ble_gapc_adv_report_param_t  *scanProgressParam = (cy_stc_ble_gapc_adv_report_param_t  *)eventParameter;

           

            printf("BD Addr: ");          

            for(unsigned int i=0;i<CY_BLE_BD_ADDR_SIZE;i++)

                printf("%02X",scanProgressParam->peerBdAddr);          

            printf("\tLength: %d ",scanProgressParam->dataLen);

            printf("\tRssi: %d",scanProgressParam->rssi);

            //printf("Data Received:\t\t%.*s\r\n\r\n",currentAdvInfo.sensorData_len, currentAdvInfo.sensorData);

           

            findAdvInfo(scanProgressParam->data,scanProgressParam->dataLen);

           

            if(currentAdvInfo.name != 0)

                printf("%.*s",currentAdvInfo.name_len,currentAdvInfo.name);             

            printf("\r\n");            

           

            //if the advertised data length matches the scanned data length for EnviroSensor(25), attempt to connect

            //if(scanProgressParam->dataLen==30)

//            if(currentAdvInfo.servUUID_len > 0

//                && memcmp(currentAdvInfo.serviceUUID,cy_ble_customCServ [CY_BLE_CUSTOMC_LED_SERVICE_INDEX].uuid,

//                currentAdvInfo.servUUID_len) == 0)

            if(currentAdvInfo.servUUID_len>0

               &&memcmp(currentAdvInfo.serviceUUID,cy_ble_ess , currentAdvInfo.servUUID_len)==0)

            {

                Cy_GPIO_Write(GREEN_0_PORT, GREEN_0_NUM, 1);

                printf("\r\nFound ESS Service");

                cy_stc_ble_bd_addr_t connectAddr;

                memcpy(&connectAddr.bdAddr[0], &scanProgressParam->peerBdAddr[0] , CY_BLE_BD_ADDR_SIZE);

                connectAddr.type = scanProgressParam->peerAddrType;

               

                Cy_BLE_GAPC_ConnectDevice(&connectAddr,0);

                Cy_BLE_GAPC_StopScan();              

                //if connection is successful

                if(CY_BLE_EVT_GATT_CONNECT_IND)

                {

                    printf("\r\nConnection Success\r\n");                           //print information about connected device

                    printf("\r\nConnected to:\t\t");         //device name

                    printf("%.*s\r\n",currentAdvInfo.name_len,currentAdvInfo.name);

                    printf("Name Length:\t\t%d \r\n",currentAdvInfo.name_len);      //length of device name

                    printf("Service UUID:\t");                               // uuid

                    printf("%.*s\r\n",currentAdvInfo.servUUID_len,currentAdvInfo.serviceUUID);

                    printf("Data Received:\t\t%.*s\r\n\r\n",currentAdvInfo.sensorData_len, currentAdvInfo.sensorData);

                    Cy_GPIO_Write(LED9_0_PORT,LED9_0_NUM,0);                        //Light LED9   

                }

            }

        break;

0 Likes
1 Solution

Obviously, you have get what you want in currentAdvInfo. The serviceUUID points to '0x1A' and ServUUID_len is 0x02. They are correct.

The problem is below printing sentence can not print the UUID correctly -

printf("%.*s\r\n",currentAdvInfo.servUUID_len,currentAdvInfo.serviceUUID);

It is used to print a string, instead of hexadecimal number.

View solution in original post

6 Replies
ShipingW_81
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

To get the service UUID of ESS server on ESS client, you need to guarantee the ESS server advertising packet contains that ID. For PSoC 6 device, you need to check the item of target service under 'Advertisement packet' -> 'Service UUID' in BLE component customizer, to make the service UUID included in the advertising data packet(stored in cy_ble_discoveryData[ ]).

Once the advertising packet is received on Client side and CY_BLE_EVT_GAPC_SCAN_PROGRESS_RESULT generated, the data along with that event is typed as cy_stc_ble_gapc_adv_report_param_t :

/** Advertisement report parameter */

typedef struct

{

    /** Advertisement event type

        - Connectable undirected advertising = 0x00

        - Connectable directed advertising = 0x01

        - Scannable undirected advertising = 0x02

        - Non connectable undirected advertising = 0x03

        - Scan Response = 0x04

    */

    cy_en_ble_gapc_adv_event_t      eventType;

    /** BD address type of the device advertising.

        - CY_BLE_GAP_ADDR_TYPE_PUBLIC

        - CY_BLE_GAP_ADDR_TYPE_RANDOM

        - CY_BLE_GAP_ADDR_TYPE_PUBLIC_RPA

        - CY_BLE_GAP_ADDR_TYPE_RANDOM_RPA

    */

    uint8_t                      peerAddrType;

    /** Public Device Address or Random Device Address for

      each device that responded to scanning. */

    uint8_t*                      peerBdAddr;

    /** length of the data for each device that responded to scanning */

    uint8_t                      dataLen;

    /** Pointer to advertising or scan response data */

    uint8_t*                      data;

    /** Rssi of the responding device.

                * Range: -85 <= N <= 0

                * Units: dBm */

    int8_t                        rssi;

} cy_stc_ble_gapc_adv_report_param_t;

You can decipher the target UUID from element cy_stc_ble_gapc_adv_report_param_t -> data, which is the pointer of data array with identical content of cy_ble_discoveryData[] on peer device.

It's strange how did you pass the received data packet to 'currentAdvInfo'? It looks a custom variable. Maybe you can attach your whole project to get more details for us.

lock attach
Attachments are accessible only for community members.

Hi WangS_81 thanks for your reply!

I do have the service UUID included in the advertisement packet. The client checks for certain bytes within the packet, and fills the currentAdvInfo with the related data. The packet data for name and (sensor ) data does display correctly, but the UUID does not, so i am unsure if I am actually receiving the UUID bytes. For 'name' , for example, i check for the byte 0x09, and place the related information into the currentAdvInfo structure. However, for the service UUID, the switch statement checks for 0x02, but there are actually 0x02 bytes in the packet being sent, so maybe it would be an issue with that perhaps?

Please find the two projects attached. there has been slight edits to the Central project but in principle it works the same. The 2520719_BLE_Test is the peripheral device project.

Thanks again for your help.

0 Likes

I roughly looked through you project. It looks the code logic of deciphering the adv apcket in the central project is fine.

However, I would like to know the specific test result on your side? You mentioned the Name could be correctly printed. but UUID not. What is the UUID printed?

The switch case 0x02 in findAdvInfo ever entered? If yes, what is actually stored in currentAdvInfo.serviceUUID and currentAdvInfo.servUUID_len? Can you observe the above two items under debug mode?

There is nothing printed for the UUID in he message. I have attached 3 images, one with the message results, one with the currentAdvInfo elements just after it had entered the 0x02 switch condition, and one with the currentAdvInfo elements when the message has completed printing.

I am unsure of my approach and maybe I should consider another, as I will need to implement a number of the ESS servers to the project eventually  (around 10) . But from what i can tell, if i want the master to  only connect to ESS servers, I must use the ESS UUID. This is why I want to print the ESS UUID, so I know I am receiving it, so I can use it to connect to the client.

So i the UUID is '181A', I should compare that with what is received in the currentAdvInfo using this line:

if(currentAdvInfo.servUUID_len > 0

                &&memcmp(currentAdvInfo.serviceUUID,"181A",currentAdvInfo.servUUID_len)==0)

           

But When I use that instead of comparing the name string or the length, for example, the client does not attempt to connect and continues to scan indefinitely.

debug.PNG

1.PNG

2.PNG

Thanks again for your time, I truly appreciate it.

0 Likes

Obviously, you have get what you want in currentAdvInfo. The serviceUUID points to '0x1A' and ServUUID_len is 0x02. They are correct.

The problem is below printing sentence can not print the UUID correctly -

printf("%.*s\r\n",currentAdvInfo.servUUID_len,currentAdvInfo.serviceUUID);

It is used to print a string, instead of hexadecimal number.

I could have spent another week looking at this and never would have seen that. Thank you!

0 Likes