Smart Bluetooth Forum Discussions
1. modify the hello_client.c as below to add LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE permission;
CHARACTERISTIC_UUID16 (0x0062, 0x0063, UUID_CHARACTERISTIC_BATTERY_LEVEL,
LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE,
LEGATTDB_PERM_READABLE /*| LEGATTDB_PERM_WRITE_CMD |LEGATTDB_PERM_WRITE_REQ*/, 1),
2. using the following code to modify characteristic value and send out the notification:
bleprofile_sendNotification(0x63, db_pdu.pdu, (INT32) db_pdu.len);
3. the connected android device can't receive the notification, but the value has been modified;
4. bleprofile_sendNotification(HANDLE_HELLO_CLIENT_DATA_VALUE, db_pdu.pdu, (INT32) db_pdu.len); ----for this characteristic,
the connected device can receive the notification.Show Less
I have 2 interrupt lines i must tie to the bcm20737s module. I am wondering are there any recommended i/o to connect to or ones to stay away from?
I was planning to Make use of BCM20702 chip set for one of the product.
Is it possible for someone to please upload the datasheet along with a Application design Guide.
My product is neither a master nor a slave. I am trying to connect two of my identical peripheral devices to each other without a third-party central. When pairing the devices, how do I pick which one should advertise and which one should scan for the connection? I can press a button on the dev kits to make one a master (scanning for advertisements) and the other a slave (sending advertisements), but I would rather just let them both be masters and slaves to each other, at the same time. In other words, they both send advertisements and scan for advertisements from at the same time. When they find each other, they are both master/slave to each other over the two connections.
Is this possible?
I tried to modify hello_client to do exactly that and it failed. Device A was master to device B, but when I tried to kick off another connection where device B was master to device A, it failed. Device B found advertisements from device A just fine, but I never got to connection up. Note that I did program the BD_ADDR differently for each dev kit to ensure that they are different.Show Less
app: our application based on hello-sensor sample code.
firmware size ~ 29KB.
Use one handset to connect with sensor device for 2~3 days, and take handset
back home and device still stays in office; after back office, handset can not scan
it for connection. Then check the trace, device had ever called with plan_air_connection_down()
for disconnection and during idle, it will periodically call plan_air_advertisement_stopped() to broadcast
by bleprofile_Discoverable(). But handset still cannot find this MAC; is there any similar issue happened before?
On the BCM90726S-Module in our own design we get the DiscReason 08. Sometimes after some minutes, sometimes after some hours.
But I can't find the reason for this disconnect or how to avoid/solve it, nor what it means.Show Less
We are finding in our BCM20736S application (on SDK 2.1.1) which has an external I2C EEPROM the following issues/observations regarding the I2C API in the SDK: (Note: we are using a garden variety Atmel 512Mbit eeprom)
1. Both i2cm.h and cfa.h work for reading and writing but only up to 14 bytes of data (two bytes of address for a total of 16). Attempting to write 15 or 16 bytes of data (or anything larger) always fails.
2. The header files advertise that longer byte strings are supported but that they break them into separate 16 byte transactions. We are finding that this is not the case, and the functions don't work as advertised. Only a single 16 byte transaction per function call is working (14 data bytes for the write).
3. In any case, what we need is to write 128 bytes (page write to eeprom) of data in a single transaction. This is not supported but needs to be as it is very inefficient to write to eeprom in other than page mode. (We buffer data in RAM and write to EEPROM in full page chunks.)
4. The cfa.h and i2cm.h function calls do not always work on the first try. We have found success by embedding the calls in a loop with a max iteration of 20 with a wait of 1 millisecond between calls. Exiting the loop when the return status is SUCCESS or max iterations reached. This seems to be related to the internally timed page write cycle of the eeprom device, but it's not clear how. The eeprom datasheet puts maximum write time at 5 milliseconds. The 1mS waits appear to be needed for the i2cm loop but not the cfa loop. The loop coded with cfa.h and no waits (and no traces) typically completes successfully after no more than 16 iterations. The i2cm loop with a 1 mS wait completes with success status in 2 or 3 tries).
5. changing the I2C speed with i2cm_setSpeed() did not seem to affect the above performance. Using divisors of 240 (100kHz) and 60 (400kHz) both worked the same. I will need to check with an oscilloscope to be sure the set Speed worked as advertised. Have not done so yet.
6. Would like if Broadcom could expose some lower level I2C interface so we could write our own driver that supports page writes.
I am looking to set my pressure sensor up which talks over I2C with a BCM20737S. Hardware wise i am ok.
I am not familiar with the M0 libraries. How would you go about initializing the I2C? I need to set my SCL clock speed to 400KHz. My slave address is 0x21h. I do not need to write to the pressure sensor, only read. What is the best way to read incoming data?
Any examples that could help?
hello_sensor_write_handler: handle ff02
Active DS is not DS1 and not DS2. Cannot upgrade.Show Less
It appears that the version of GCC included with the WICED Smart IDE was not compiled with plugin support enabled. Is it possible to use another version of ARM GCC that does support plugins with the WICED Smart IDE or if that won't work would it be possible for Broadcom to provide a version of ARM GCC that was compiled with plugins enabled?Show Less