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,
};
Show LessHello,
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 ?
Show LessI meet a strange error, I try to use memset(), I see it can be used in 2073x, and when I use in Apps/test/test.c, it works well, but if I increase a folder, use it in Apps/test/mem/mem.c, it has a error: undefined reference to `memset', and I am certain that I both add "string.h", but one is ok, the other is error, so I want to know whether I do something in makefile like increase a path?
Thanks.
Show LessAre there any causes that make the BCM20736S reboot after calling the function bleprofile_PrepareHidOff ? Very often, but not always , when I call this API, the BCM20736S reboots. Whithout calling it everything's ok.
Show LessI 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
Show LessWhen we were trying download code to device through the Tag3, the UART_RX, UART_TX, and GND pins from Tag3 are connected to this external device. we experienced the code download fail because the device is not detected. that means the RX, TX voltage are not correct.
Show LessHello,
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
Show LessChanges for WICED-Smart-SDK-2.2.2
- Upgrading to this SDK is highly recommended
- Improved RF performance for some parts at some corners
- I2C speed set to 400KHz to speed up boot when using EEPROM
- Modified upgrade sample apps to use write command for data transfer
- Updated patches to the latest version (#74)
- Added new optional libraries - disable_sw_timer_as_wake_source, raise_gpio_when_awake, sfi_ultra_deep, sflash_patches
- Installer tested for new versions of Windows
Windows Downloads:
Linux and OSX versions to follow
lucyli jamesle1 j.t jakewtorres boont
Show LessIs there a date to Update the 2.2.1 installer to fix the JRE version code bug, so it will install on Windows 10?
This has been an open issue for quite a while.
I documented this as an installer bug some time ago. See my other post.
Joe
Show LessI 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).
Show Less