search

sandeepmistry / arduino-BLEPeripheral

An Arduino library for creating custom BLE peripherals with Nordic Semiconductor's nRF8001 or nR51822.
MIT License
463 stars 179 forks source link

Can only put one item in advertisement #86

Closed asharov closed 8 years ago

asharov commented 8 years ago

Hi,

I have a need to implement a profile that requires me to put both the advertised service UUID and manufacturer data into the advertisement. My problem is that BLEPeripheral has an if-else chain for filling the advertisement so that it will not add both. I have solved this for myself by modifying the BLEDevice class to accept an array of advertisement payloads, so that the device implementation can add all of them to the advertisement. Would this be interesting to you? If so, I could clean my modifications up and make a pull request.

There's one problem in that I'm not sure whether this works at all with nRF8001. I recall not being able to set multiple advertisement payloads with nRF8001 even though I tried, but I did not dig very deeply into how it could be made to work as I switched to nRF51822 for other reasons anyway. So with my modifications the nRF8001 interface would have the begin function taking an array but only using the first element. This is, however, not a change in how BLEPeripheral currently works, as it will pass only one item as advertisement data to the device in any case.

sandeepmistry commented 8 years ago

Hi @asharov,

It's going to be a bit tricky to implement it on the nRF8001, since it uses a proprietary setup message that I had to reverse engineer, so I'm not too keen on porting this enhancement to nRF8001 over for now. I restricted it to service solicitation UUID || advertised service uuid || manufacturer data for this reason. nRF51/52 is much more flexible.

How are you handling scenarios where the advertisement data would overflow the 31 byte length?

asharov commented 8 years ago

Hi,

Okay on the nRF8001, then I can leave it as is with how it works currently.

For the manufacturer data, it would just follow the current behavior of cutting it off at the maximum available length. In case of both service solicitation UUID and advertised service UUID being specified as 16-byte values, I suppose the appropriate thing to do would be to drop the advertised service UUID to match current behavior?

sandeepmistry commented 8 years ago

Hi @asharov,

That sounds like reasonable behaviour, please go ahead and submit a PR.

sandeepmistry commented 8 years ago

Closed via #89.