Remote device name

Yuri Cherniakov

hello!

This thread is the continuetion of an older thread which wasnt resolved:

after testing with the suggested example code (with some modifications since it isnt LE code), i received only garbage in the

(GAP_Event_Data->Event_Data.GAP_Remote_Name_Event_Data->Remote_Name) when trying to read from an smartphone (nexus 5)

and received the real name from a tablet (galaxytab 10).

Could you please point me to the right direction? why do i receive garbage from the smartphone?

over 8 years ago

0 S over 8 years ago

TI__Mastermind 35795 points

hi , we have assigned your query to BT expert. We will get back to you soon
Saurabh

0 Chen Loewy over 8 years ago

TI__Expert 5285 points

Hello Yuri,

As we've talked in the past we've tried this issue and could get valid data each time.

Can you please describe your scenario so we can try to duplicate it over here.

BR,
Chen Loewy

0 Yuri Cherniakov over 8 years ago in reply to Chen Loewy

Expert 1740 points

Hello Chen!

Here is my scenario:

After i pair and connect to a smartphone (This was tested with several android smartphones such as Nexus5 , OneplusOne, OneplusOne2 and others with different Android versions such as 6.0.1 and 5.1.1 etc), i try to acquire its name by using the "GAP_Query_Remote_Device_Name()" API:

GAP_Query_Remote_Device_Name(ApplicationStateInfo.BluetoothStackID, ApplicationStateInfo.LEConnectionInfo.BD_ADDR, DeviceNameCallBack, (unsigned long)0);

As parameters i enter the BT stack ID, the BD address and the callback function where i catch the returning event.

After several seconds i catch an event in the device name callback which looks like this:

void DeviceNameCallBack(unsigned int BluetoothStackID, GAP_Event_Data_t* GAP_Event_Data, unsigned long CallbackParameter)
{
if(GAP_Event_Data->Event_Data.GAP_Remote_Name_Event_Data->Remote_Name)
memcpy(str,GAP_Event_Data->Event_Data.GAP_Remote_Name_Event_Data->Remote_Name, 100 );

while(1);
}

The name received is copied into a buffer which i then check, the results are always some kind of gibberish.

0 Vihang Parmar over 8 years ago in reply to Yuri Cherniakov

TI__Mastermind 29291 points

Hi Yuri,

The name of a BLE device is found during the LE scan process since the name of the remote LE device will be in the advertising data field of the advertised packet.

The GAP_Query_Remote_Device_Name API is used to query name of a remote classic bluetooth device.

Best regards,
Vihang

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang!

OK, so in this case where and how exactly do i retrieve the name?

Moreover, how does this sit with the fact that when i try to connect to a tablet (galaxytab) i receive a valid name as an answer using the same API?

0 Yuri Cherniakov over 8 years ago in reply to Yuri Cherniakov

Expert 1740 points

Hello!

Is there any update on this matter?

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang,

Any updates?

0 Vihang Parmar over 8 years ago in reply to Yuri Cherniakov

TI__Mastermind 29291 points

Yuri,

Yuri Cherniakov said:

Moreover, how does this sit with the fact that when i try to connect to a tablet (galaxytab) i receive a valid name as an answer using the same API?

The GAP_Query_Remote_Device_Name is for classic BT only. Most of the tablets are dual mode devices (classic + LE). Depending on the OS version and manufacturer configurations, the dual mode device can be using the same BD_ADDR for classic and LE (in other words, using public address of dual-mode device as LE address). I bet, the galaxytab that gave you the name using GAP_Query_Remote_Device_Name has this so when you used this API, it did a classic BT name query for the BD_ADDR. This is not a reliable way of getting name of a remote LE device.

Yuri Cherniakov said:

OK, so in this case where and how exactly do i retrieve the name?

There are 2 ways of getting device name of a remote LE device.

When the remote LE device is already connected, you can read DeviceNameHandle Attribute handle to get name of a remote device. Please refer to the ReadRemoteName function in the LE sample applications (i.e. SPPLEDemo, HOGPDemo etc) for implementation.
When the remote LE device is not connected, you can preform LE scan from local device and get name of the remote LE devices from their advertisement data. The remote device need to be advertising at this time. To do this, you will need to have the following in your code.

a. Start and stop scanning using the following APIs.

/* Start LE scan                                   */
Result = GAP_LE_Perform_Scan(BluetoothStackID, stActive, 10, 10, latPublic, fpNoFilter, TRUE, GAP_LE_Event_Callback, 0);

/* Stop LE scan                                    */
Result = GAP_LE_Cancel_Scan(BluetoothStackID);

/* Note : The LE scan will stay active untill the  */
/*        GAP_LE_Cancel_Scan is called.            */

b. When the local device is doing LE scan, every remote LE device's advertising report will trigger an event in the GAP_LE_Event_Callback. You can print the advertising data and remote device information by adding the following in your GAP_LE_Event_Callback function.

...
      switch(GAP_LE_Event_Data->Event_Data_Type)
      {
         case etLE_Advertising_Report:
            Display(("\r\netLE_Advertising_Report with size %d.\r\n",(int)GAP_LE_Event_Data->Event_Data_Size));
            Display(("  %d Responses.\r\n",GAP_LE_Event_Data->Event_Data.GAP_LE_Advertising_Report_Event_Data->Number_Device_Entries));

            for(Index = 0; Index < GAP_LE_Event_Data->Event_Data.GAP_LE_Advertising_Report_Event_Data->Number_Device_Entries; Index++)
            {
               DeviceEntryPtr = &(GAP_LE_Event_Data->Event_Data.GAP_LE_Advertising_Report_Event_Data->Advertising_Data[Index]);

               /* Display the packet type for the device                */
               switch(DeviceEntryPtr->Advertising_Report_Type)
               {
                  case rtConnectableUndirected:
                     Display(("  Advertising Type: %s.\r\n", "rtConnectableUndirected"));
                     break;
                  case rtConnectableDirected:
                     Display(("  Advertising Type: %s.\r\n", "rtConnectableDirected"));
                     break;
                  case rtScannableUndirected:
                     Display(("  Advertising Type: %s.\r\n", "rtScannableUndirected"));
                     break;
                  case rtNonConnectableUndirected:
                     Display(("  Advertising Type: %s.\r\n", "rtNonConnectableUndirected"));
                     break;
                  case rtScanResponse:
                     Display(("  Advertising Type: %s.\r\n", "rtScanResponse"));
                     break;
               }

               /* Display the Address Type.                             */
               if(DeviceEntryPtr->Address_Type == latPublic)
               {
                  Display(("  Address Type: %s.\r\n","atPublic"));
               }
               else
               {
                  Display(("  Address Type: %s.\r\n","atRandom"));
               }

               /* Display the Device Address.                           */
               Display(("  Address: 0x%02X%02X%02X%02X%02X%02X.\r\n", DeviceEntryPtr->BD_ADDR.BD_ADDR5, DeviceEntryPtr->BD_ADDR.BD_ADDR4, DeviceEntryPtr->BD_ADDR.BD_ADDR3, DeviceEntryPtr->BD_ADDR.BD_ADDR2, DeviceEntryPtr->BD_ADDR.BD_ADDR1, DeviceEntryPtr->BD_ADDR.BD_ADDR0));
               Display(("  RSSI: %d.\r\n", (int)DeviceEntryPtr->RSSI));
               Display(("  Data Length: %d.\r\n", DeviceEntryPtr->Raw_Report_Length));

               Display(("  Advertise Data: %s \r\n", DeviceEntryPtr->Advertising_Data.Data_Entries->AD_Data_Buffer));
            }
            break;
...

Best regards,

Vihang

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang!

Thank you so much for the detailed response.

I will try this and get back to you as soon as possible.

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang!

I have implemented your suggestions with the following results:

1. Retrieving a connected device's name: After connecting to LE device i call the ReadRemoteName function which always fails in the same place, The DeviceNameHandle in the GAPSClientInfo struct is zero (and therefore the function is terminated). I have also tried using the "GATT_Read_Value_Request" API without the name handle check but it fails non the less. How is this resolved?

2. Scanning for unconnected devices names: I have added the specific event in the GAP_LE_Event_Callback as well as the API's that allow to start and end a scan. Activating of the GAP_LE_Perform_Scan API was always successful (return value was correct). After testing with several devices (which were recognized by each other - thus advertising for sure) no "etLE_Advertising_Report" event was triggered and no data regarding device name was printed out. what could be the reason for this?

thanks.

0 Vihang Parmar over 8 years ago in reply to Yuri Cherniakov

TI__Mastermind 29291 points

Yuri Cherniakov said:

1. Retrieving a connected device's name: After connecting to LE device i call the ReadRemoteName function which always fails in the same place, The DeviceNameHandle in the GAPSClientInfo struct is zero (and therefore the function is terminated). I have also tried using the "GATT_Read_Value_Request" API without the name handle check but it fails non the less. How is this resolved?

The GAPSClientInfo struct is populated during the GATT Service Discovery process. I guess this part is missing in your code so there is no DeviceNameHandle populated to be used during the ReadRemoteName function. You might want to add implementation of the DiscoverGAPS after establishing LE connection to populate service handles including the DeviceNameHandle from the GAP Service (GAPS). Please refer to the HOGPDemo.c source for implementation.

Yuri Cherniakov said:

2. Scanning for unconnected devices names: I have added the specific event in the GAP_LE_Event_Callback as well as the API's that allow to start and end a scan. Activating of the GAP_LE_Perform_Scan API was always successful (return value was correct). After testing with several devices (which were recognized by each other - thus advertising for sure) no "etLE_Advertising_Report" event was triggered and no data regarding device name was printed out. what could be the reason for this?

What are these devices that you were performing the tests with? I am having no problems getting advertising reports for surrounding LE devices that are advertising. Not quite sure what could be the reason.

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang!

I found the missing parts of the code which populate the name handle and now i am able to read the device name. thanks!

Regarding the Scanning for unconnected devices: The devices i scanned for were smartphones which i can always identify during their advertising. I will make some further tests and get back to you with some more details.

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang!

There is an issue i have encountered during the name reading process.
When i want to read a device name i activate a discovergaps() command , when it's done i make a read request using the readremotename() command.

Some of the times the discovery process is long (more then 5 seconds - mind that a successfull process is very quick) and unsuccessful after which the device is unresponsive (Bluetooth-wise).

i have also noticed that there is a change in the connection interval during this process (perhaps this can be one of the causes?)

I have logged this issue and i am adding it here. DiscoverGapsLog.rar

Is this a known issue? how do i resolve/debug this?

thanks.

0 Vihang Parmar over 8 years ago in reply to Yuri Cherniakov

TI__Mastermind 29291 points

Hi Yuri,

This is not a known issue. Following are some things to check.

- When you call the discovergaps() function, it essentially does a service discovery. The service discovery event callback has 2 events : etGATT_Service_Discovery_Indication and etGATT_Service_Discovery_Complete. The etGATT_Service_Discovery_Indication calls the function to populate GAPS handles and the etGATT_Service_Discovery_Complete indicates that the service discovery process is complete.

- Are you calling the readremotename() command after the etGATT_Service_Discovery_Complete ? If not, you might be running into a race condition. Please verify that you are getting the etGATT_Service_Discovery_Complete event and calling the readremotename() after that.

If this is not the case, I recommend doing a code review to verify the order of calls. You can upload/e-mail me the part of your code that deals with reading the name of remote device.

Best regards,

Vihang

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang!

At this stage i am using the discovergaps() and the readremotename() in a completely separate and manual manner.

I first activate the discovergaps() function and only when i see indications that it was completed i call the readremotename() function.

The problem arises when i use the discovergaps() function which starts with "GATT_Start_Service_Discovery " and can sometimes run quickly and smoothly returning a status of 0x00 in the callback (afterwards the name reading goes well and connectivity is preserved).

In other cases i get the "GATT_Start_Service_Discovery success" message, meaning the service discovery has started but after a few seconds the callback prints out a status of 0x02 (timeout as i understand)

and connectivity problems start imidietly afterwards. perhaps the Log file i have added in the previous message can be of some assistance (it captures the problematic call of the (discovergaps() function)?

0 Yuri Cherniakov over 8 years ago in reply to Yuri Cherniakov

Expert 1740 points

Hi Vihang!

Did you by any chance have an opportunity to look this over?

0 Vihang Parmar over 8 years ago in reply to Yuri Cherniakov

TI__Mastermind 29291 points

Hi Yuri,

The attached CC256x firmware logs do not contain the details of the GAP and GATT profile layers that is responsible for the service discovery. So the logs are not much help here. A sniffer log (like ellisys/fte) can be helpful.

If you are using the HOGPDemo as it is, I do not see any case in repeated attempts using HOGPDemo w/ android and iOS phones that show similar behavior. What has changed in the HOGPDemo code?

Best regards,
Vihang

0 Yuri Cherniakov over 8 years ago in reply to Vihang Parmar

Expert 1740 points

Hi Vihang!

There were additions around the HOGP demo but the connection/disconnection mechanism wasn't touched.
Unfortunately I do not have a proper sniffer in my immediate possession, however, i can try and meet Chen and get his help in sniffing the data we need to debug this. I'll update this thread ASAP after i talk to him.

Bluetooth®︎

Bluetooth forum

Remote device name