Smart Bluetooth Forum Discussions
I'd like to implement using white list in Wiced_Smart_SDK2.1.0.
I use 2 boards, 1 is hello_sensor and the other is hello_client.
But connection looks like being done not related with bd_addr even though I put the blecm functions.
I already read the discussions
1. 20732 mac filtering possible?
2. Adding and Removing Entries from Whitelist
I modified hello_client like following
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
BLECM_SELECT ADDR list_addr[4];
UINT8 targetaddr[6] = {0x20, 0x73, 0x6A, 0x1C, 0x8C, 0xCA}; // hello_sensor bd_addr is 20736a1c9cca
void hello_client_create(void)
{
.......................
..........................
blecm_enableAddressSelection();
BT_MEMCPY(list_addr[0].addr, targetaddr,6);
list_addr[0].type = 0;
blecm_SelectAddress(list_addr, 1);
}
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
whatever I write the value in targetaddr in hello_client while the board address of hello_sensor does not change, connection is always successful.
What should I do or change in my code?
Show LessI see that the hello_client.c application in SDK 2.1.1 "allows another master to connect, so the device will behave as a slave in one Bluetooth piconet and a master in another." I presume that this is the "Mesh Networking" that is supported on the BCM20737S. If using this mesh networking configuration, is there a limit to the number of supported nodes in the network? Or could the size of the network scale indefinitely by adding new piconets?
Show LessHi ...
In this thread: Re: Europe and Canada approval for BCM20732S, you said the EN 301489 is only neccesary on system level, you mean only for a end product ?!?
But for a CE certification (BCM92073x Board is CE marked) is this test a basic requirment - please correct me if I´m wrong.
And in this case the board have to pass this test .. correct ??
My question is .. are there any documents that the BCM20736s is able to pass this test ?? I know at the end the whole system have to be tested. But this kind of document help for the right decision for my customer.
Show LessPer the thread here: how to get a random number with the sdk?
Can ulp_rand() be used with BCM20732S ?
Show LessDoes the app also work on tablets which have android version kit kat?
My understanding is the connection timeout error is supposed to happen
after supervision timeout which is 500 ms in my application.
The problem is scan no longer works once the connection timeout (0x8) occurs.
My application is the Initiator of the connection and
emconinfo_getDiscReason() returns 0x8 on connection down callback.
Can you provide some advice to debug this issue?
I am using 20737 with SDK 2.1.1
Here are my scan parameters.
blecen_cen_cfg.scan_type = HCIULP_PASSIVE_SCAN; |
blecen_cen_cfg.scan_adr_type = HCIULP_PUBLIC_ADDRESS;
blecen_cen_cfg.scan_filter_policy = HCIULP_SCAN_FILTER_POLICY_WHITE_LIST_NOT_USED;
blecen_cen_cfg.filter_duplicates = HCIULP_SCAN_DUPLICATE_FILTER_OFF;
blecen_cen_cfg.init_filter_policy = HCIULP_INITIATOR_FILTER_POLICY_WHITE_LIST_NOT_USED;
blecen_cen_cfg.init_addr_type = HCIULP_PUBLIC_ADDRESS;
blecen_cen_cfg.high_scan_interval = 1500; //slots |
blecen_cen_cfg.low_scan_interval = 1500; //slots
blecen_cen_cfg.high_scan_window = 100; //slots
blecen_cen_cfg.low_scan_window = 100; //slots
blecen_cen_cfg.high_scan_duration = 300; //seconds
blecen_cen_cfg.low_scan_duration = 300; //seconds
blecen_cen_cfg.high_conn_min_interval = 8; //frames |
blecen_cen_cfg.low_conn_min_interval = 8; //frames
blecen_cen_cfg.high_conn_max_interval = 8; //frames
blecen_cen_cfg.low_conn_max_interval = 8; //frames
blecen_cen_cfg.high_conn_latency = 0; |
blecen_cen_cfg.low_conn_latency = 0;
blecen_cen_cfg.high_supervision_timeout = 50;
blecen_cen_cfg.low_supervision_timeout = 50;
blecen_cen_cfg.conn_min_event_len = 0;
blecen_cen_cfg.conn_max_event_len = 0;
Show LessHow do I enable trace output on the WICED Sense board? I tried commenting out the BLE_TRACE_DISABLE but that didn't help.
// Enable/disable tracing
//#define BLE_TRACE_DISABLE
Show LessIn the WICED SMART SDK, under the include directory structure in bleprofile.h, starting on line 74, there are several #defines for GPIO flag bits. The first section appears to define direction, initialization state, etc. I can make sense of these.
// GPIO flag bit (this is different than definition that used in gpio driver source code (GPIO_INPUT_ENABLE, etc)
#define GPIO_NUM_MAX 16
#define GPIO_INPUT 0x0000
#define GPIO_OUTPUT 0x0001
#define GPIO_INIT_LOW 0x0000
#define GPIO_INIT_HIGH 0x0002
#define GPIO_POLL 0x0000
#define GPIO_INT 0x0004 // Interrupt
#define GPIO_BOTHEDGE_INT 0x0008 // Both Edge
Just under those, starting on line 82, there are another series of magic numbers. Can anyone explain why the values are what they are?
#define GPIO_WP 0x0010 //EEPROM write protect
#define GPIO_BAT 0x0020
#define GPIO_BUTTON 0x0100
#define GPIO_BUTTON1 0x0100
#define GPIO_BUTTON2 0x0200
#define GPIO_BUTTON3 0x0400
#define GPIO_LED 0x1000
#define GPIO_BUZ 0x2000
Thank you,
-Troy
Show LessBluetooth 4.2 Unveiled: No Mesh Yet, But Big on IoT | EE Times
- New IPSP profile which is designed to enable IPv6 for Bluetooth
- Increased speed and reliability allowing devices to transfer data up to 2.5 times faster than with previous version
- NIST approved algorithms for encryption and hash
- Ability to constantly change BD_ADDRs
Comments for Android App developers (based in experience):
Mentioned already, BLE supports max. 4 Notifications (where we can subscribe to). Here, the WICED Sense uses just two Notifications (see the document "Sensor Data Format").
(OK, maybe reasonable to do because so we can get all 6 sensor values with just two Notifications. If we would have for every sensor an own Notification (which is actually the standard way to do) - we would have a limitation to decide which maximal four).
It results in following:
a) Even BLE supports well-known UUIDs for Temperature, Pressure characteristics etc. - they are not used here. All sensor values are encoded as proprietary data format. Therefore, you cannot use any BLE data types, e.g. FLOAT, SFLOAT etc. You have to decode all sensor values by your own. (BLE supports a nice FLOAT format where even degC or degF can be encoded - not used here, it makes it harder and losing flexibility).
b) Also not using the UUID for a temperature characteristic results in "Unknown Service" and "Unknow Characteristic",
What the "Sensor Data Format" doc does not tell you:
I) The bytes come as Big Endian! So, a Notification as Java byte[] value comes as: 0x34 0xXX 0xXX (Hum) 0xXX 0xXX (Pressure) 0x09 0x01 (Temp)
II) The value (example) 0x0901 is d'2305
III) I think it should mean: 2 bytes BigEndian degC * 100 (we have two factional digits, not just one with *10).
Therefore, if you convert Temp value into floating decimal - divide by 100, not 10, and watch out for the big endian when doing on
a little endian platform (Android ARM CPU for instance where your app is running)
The "Code Snippet" there with the struct I do not understand completely. What are all these bits?
Is my interpretation right?:
1) The first byte in the Characterstic value (sent via Notification) is a bit encoded field which tells us if a sensor value is present or not (6 or 2 byte fields have valid data or not, but they are always transmitted).
2) Does it mean we can have all combinations, not just starting with 0x0B or 0x34? It can be also 0x01, 0x3F?
3) 0x3F we might not see because all the sensor datas are always split into two Notifications?
4) Is the set of values always constant, what is inside 1st and 2nd Notification?
Means: Humidity, Pressur and Temp. come always in 2nd Indication, not in first, but the first byte bit field gives us indication
which values are valid inside packet?
OK, this might make sense, e.g. if we disable a sensor in WICED Sense device and related value is transmitted as 0 (or garbage).
So, it means, we have to decode first byte always because a sensor value can be missing on Notification data packet.