Smart Bluetooth Forum Discussions

Hi all,

I have a GATT profile with 2 services and their respective characteristic. For some reason the 2nd service is not get fully discovered by the remote peers:

1) A Linux box discovers the CONSOLE_RX characteristic only

2) and iPhone discovers the CONSOLE_TX characteristic only

Sure, I would expect both of them get discovered regardless of the peer. Here is by GATT profile (note the UUIDs and handles are unique within the database):

const UINT8 puart_control_gatt_database[]=

{

       PRIMARY_SERVICE_UUID16 (0x0001, UUID_SERVICE_GATT),

       PRIMARY_SERVICE_UUID16 (0x0014, UUID_SERVICE_GAP),

       CHARACTERISTIC_UUID16 (0x0015, 0x0016, UUID_CHARACTERISTIC_DEVICE_NAME,

                   LEGATTDB_CHAR_PROP_READ, LEGATTDB_PERM_READABLE, 10),

                   'G','T','A','M',' ','N','a','n','o', 0x00,

       CHARACTERISTIC_UUID16 (0x0017, 0x0018, UUID_CHARACTERISTIC_APPEARANCE,

          LEGATTDB_CHAR_PROP_READ, LEGATTDB_PERM_READABLE, 2),

          BIT16_TO_8(APPEARANCE_GENERIC_TAG),

       //-------------------------------------------------------------------------------------------------------------

    PRIMARY_SERVICE_UUID128 (WIFI_LIST_SERVICE, UUID_WIFI_LIST_SERVICE),

    CHARACTERISTIC_UUID128_WRITABLE (WIFI_LIST_CHARACTERISTIC, WIFI_LIST_CHARACTERISTIC_VALUE, UUID_WIFI_LIST_VALUE,

      /*LEGATTDB_CHAR_PROP_NOTIFY,

        LEGATTDB_PERM_NONE,*/

        LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE | LEGATTDB_CHAR_PROP_NOTIFY,

        LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ,

      WIFI_LIST_CHARACTERISTIC_LEN),

      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

      0x00, 0x00, 0x00, 0x00,

    CHAR_DESCRIPTOR_UUID16_WRITABLE (WIFI_LIST_CHARACTERISTIC_DESCRIPTOR,

          UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

          LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_CMD | LEGATTDB_PERM_WRITE_REQ | LEGATTDB_PERM_RELIABLE_WRITE | LEGATTDB_PERM_AUTH_WRITABLE,

          2),

          0x00, 0x00,

       //-------------------------------------------------------------------------------------------------------------

       PRIMARY_SERVICE_UUID128 (CONSOLE_SERVICE, UUID_CONSOLE_SERVICE),

       CHARACTERISTIC_UUID128_WRITABLE (CONSOLE_RX_CHARACTERISTIC, CONSOLE_RX_CHARACTERISTIC_VALUE, UUID_CONSOLE_RX_VALUE,

              LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE,

              LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ,

          20),

          0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

                   0x00, 0x00, 0x00, 0x00,

       CHAR_DESCRIPTOR_UUID16 (CONSOLE_RX_USER_DESCRIPTION,

                   UUID_DESCRIPTOR_CHARACTERISTIC_USER_DESCRIPTION,

                   LEGATTDB_PERM_READABLE, 10),

                   'C','o','n','s','o','l','e',' ','R','X',

       CHARACTERISTIC_UUID128 (CONSOLE_TX_CHARACTERISTIC, CONSOLE_TX_CHARACTERISTIC_VALUE, UUID_CONSOLE_TX_VALUE,

          LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE,

          LEGATTDB_PERM_READABLE,

              20),

              0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

              0x00, 0x00, 0x00, 0x00,

   CHAR_DESCRIPTOR_UUID16 (CONSOLE_TX_USER_DESCRIPTION,

                   UUID_DESCRIPTOR_CHARACTERISTIC_USER_DESCRIPTION,

                   LEGATTDB_PERM_READABLE, 10),

                   'C','o','n','s','o','l','e',' ','T','X',

       CHAR_DESCRIPTOR_UUID16_WRITABLE (CONSOLE_TX_CHARACTERISTIC_DESCRIPTOR,

                 UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

                 LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_CMD | LEGATTDB_PERM_WRITE_REQ | LEGATTDB_PERM_RELIABLE_WRITE | LEGATTDB_PERM_AUTH_WRITABLE,

                 2),

                 0x00, 0x00,

};

Hello,

Per this thread: Re: PUART RTS/CTS Hardware Flow Control

I enabled the flow control using the current pins:

RX = P33

TX = P32

RTS = P1

CTS = P3

But my problem is that when I am receiving on the TAG board, the bytes that are read have weird values (0xFF, 0x7F, 0xF7, ...) but they are not the one I am sending. When the TAG board sends bytes to the computer, I receive the correct bytes.

What could be wrong ?

jakewtorres

I have implemented bulk transfer communication between an Android device and the 20736. The implementation is based on the speed test example code where there's a while() loop and blecm_getAvailableTxBuffers() is called. Data is sent via notifications. Just like the speed test example, the notifications are sent from the fine timer callback.

Connection parameters are:

Min connection interval = 7.5 mS

Max connection interval = 7.5 mS

Slave latency = 0 mS

The following snippet was taken from the BT HCI log retrieved from the Android device showing data transmitted via notifications from the 20736 to Android

Time stamps are in the second column and show the following.

• Typically only 1 packet is sent per connection interval
• Sometimes connection intervals are skipped (there's ~14 mS gaps between some data)

Note that when data is sent from Android to the 20736, I see up to 4 packets within one connection interval. See snippet below

Hence, the speed limitation does not seem to be on the Android side.

What can I do to get more than one packet to be sent from the 20736 to Android during one connection interval?

Why are some connection intervals not even sending 1 packet?

Shouldn't it be possible to send 4 packets in one interval?

I can't event get 20 bytes per 7.5 mS. Please help me figure this out.

Thanks

Hello,

Where can I find the latest blood glucose monitor profile?

I have seen in the datasheet of 20737S : that full qualification and use of these profiles may require FW update from Broadcom

Thanks

Tamas

I reworked the Hello_Client and Hello_Sensor to enable the pairing with passkey. There is a defined at the top of the hello_sensor.c and hello_client.c : #define PASSKEY_PAIRING. This is used to turn ON this feature (over Just Work or OOB).

The client initiate a scan and does connect with the sensor. The sensor is in charge of initiating the security request calling: lesmp_sendSecurityRequest();

The passkey is set right after the call lesmp_setPairingParam() early during the xxx_create() for both the client and the sensor.

The pairing on the client side is set with: lesmp_setPairingParam() with LESMP_IO_CAP_DISP_KEYBOARD_ONLY. The client is also set with lesmp_setSMPRole(LESMP_ROLE_RESPONDERS);

The sensor lesmp_setPairingParam() is called with LESMP_IO_CAP_DISP_ONLY. So the pairing key is displayed on the sensor and entered on the client.

I am getting stuck at the beginning of the third phase of the pairing during the key distribution. I do see the exchange of pairing information and the authentication of the link (see SM_PAIRING_CONFIRM in the air capture attached to this post). After that I am getting stuck.

Also I have the feeling that I am not even getting that far if I remove the lesmp_setSMPRole(LESMP_ROLE_RESPONDERS) in the client code.

I need to understand why I cannot complete the pairing process/key exchanges at this stage of the game. Am I missing a call in the code?

The sample code of the sensor and the client is attached to this post.

Attached:

Sniff_Air_traffic_Capture_Pairing_not_completed: capture of the traffic between the Master and Slave.

Source code for the Master and Slave (.c/.h files).