HID + beacon detection joined operation

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

   

Is it possible for BLE v4.2 to function as HID device while at the same time acting as Observer that continuously scans for advertising packets such as that from a Beacon? The scenario is that the BLE is connected to the PC sending HID packets. When it detects a certain beacon, it would trigger an event (ie. turning an LED on).

   

Here's my idea so far:

   

1. As HID Device, BLE acts as GAP Peripheral and GATT Server. As Observer, BLE acts as Central for it to scan for peer devices (ie. Beacons). Or, is it possible to scan for peers while configured as GAP Peripheral?

   

2. BLE would be configured with Custom Profile w/ GAP Role: Central and Peripheral for it to cater HID Device and Beacon detection function. Thus, it would contain the HID Service and probably a custom service.

   

If it's possible, how do I handled the APIs, GATTs, etc? Any suggestions on how to begin?

   

 

   

Thanks.

0 Likes
1 Solution
Anonymous
Not applicable

1. It is possible to behave as both central/peripheral configurations, but the complexity quadruples >:)

   

I believe I read on some of the forum threads that you could have a device connected to another and transmitting data back/forth while sending broadcast packets to a third BLE device, but I'm not sure you can scan while connected. (I don't know for sure, but I would lean towards it being a no)

   

2. As for making/implementing the custom BLE profile, this is a good starting point: http://www.cypress.com/documentation/application-notes/an91162-creating-ble-custom-profile

   

Keep in mind that: UUIDs will be different sizes between standard services and custom services (16 versus 128 bits), the UUID constants will need to be configured/tracked differently, as the compiler generates the custom services/handles differently (either not at all, or a pretty different naming convention iirc).

   

Here is the thread that mentions doing "two" things at the same time, but no mention of observing while connected: http://www.cypress.com/forum/psoc-4-ble/gap-profiles-broadcast-observer

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

1. It is possible to behave as both central/peripheral configurations, but the complexity quadruples >:)

   

I believe I read on some of the forum threads that you could have a device connected to another and transmitting data back/forth while sending broadcast packets to a third BLE device, but I'm not sure you can scan while connected. (I don't know for sure, but I would lean towards it being a no)

   

2. As for making/implementing the custom BLE profile, this is a good starting point: http://www.cypress.com/documentation/application-notes/an91162-creating-ble-custom-profile

   

Keep in mind that: UUIDs will be different sizes between standard services and custom services (16 versus 128 bits), the UUID constants will need to be configured/tracked differently, as the compiler generates the custom services/handles differently (either not at all, or a pretty different naming convention iirc).

   

Here is the thread that mentions doing "two" things at the same time, but no mention of observing while connected: http://www.cypress.com/forum/psoc-4-ble/gap-profiles-broadcast-observer

0 Likes
Anonymous
Not applicable

Thanks. I'll keep those in mind and look into them.

   

About the UUIDs, isn't it that UUIDs of Custom Services/Characteristics are configurable in 16 bits or 128 bits? It can be 16 bits so long as it won't conflict with SIG's standard services' UUIDs. That's what I thought. Is it wrong?

0 Likes
Anonymous
Not applicable

Hmmm; Possibly you can use unallocated 16-bit UUIDs, but I would expect that Bluetooth SIG wants to reserve all 16-bit UUIDs for official designations. When using the psoc creator it automatically forces me to use the 128-bit UUIDs, so I assumed it wasn't possible 😉

   

If you can, I would recommend not using the 16-bit UUIDs, but if you find a way to use an unallocated 16-bit UUID I suppose it would be up to you whether you want to use it or not

0 Likes