advertising / scanning data

Hi Willis,

here is a sample code inserted in SimpleBLEPeripheral_Init :

uint8 mydata[] = {0x1A,0x1A,0xFF,0x01};
gapAdvDataToken_t mytoken = { GAP_ADTYPE_SIGNED_DATA, 4, mydata};
bStatus_t st= SUCCESS;
st= GAP_SetAdvToken(&mytoken);

st= GAP_UpdateAdvTokens();

... probably I have to handle notifying events after sending these commands ?

I found an error :

I defined advertising data as local variables, whereas in "gap.h" it's specified that the application has to allocate token structure by itself.

So I put data definition as global :

uint8 mydata[] = {0x1A,0x1A,0xFF,0x01};
gapAdvDataToken_t mytoken = { GAP_ADTYPE_SERVICE_DATA, 4, mydata};

leaving SetAdvToken and UpdateAdvTokens in SimpleBLEPeripheral_Init .

The result was the same : no change in advertData[] and no change in advertising data PDU as seen by LL master (USB dongle).

Hi guy,

   I come across the same question.

   What your solution of this at last, can you share with me.

   Thanks!

Hi,

Never used that particular ability of BLE stack, but in general, most GAP/GATT calls shoud be followed by either processing its result via callback or at least (crude and unreliable) ample pause. Maybe it is same with setting tokens.

Hi Oleg, 

the interest in sending some data through advertising was originated by the limitation in the number of simultaneous connections in the Texas BTLE stack implementation. 

If now we can have multiple simultaneous connections , there is no reason to send data through advertising (this way is also less efficient) 

Instead of using tokens, you can set the advertisement PDU with the code:

static uint8 advertData[] = { data and flags go here}

GAPRole_SetParameter( GAPROLE_ADVERT_DATA, sizeof( advertData ), advertData );

In the EE Times article included below, the author mentions that a scanner can request an additional 31 bytes from the advertising device. Does anyone know how to setup a call back for that request?

Thanks!

=============================================

http://www.eetimes.com/document.asp?doc_id=1278927

“The PDU for the advertising channel consists of the 16-bit PDU header, and depending on the type of advertising, the device address and up to 31 bytes of information. Also, the active scanner may request up to 31 bytes of additional information from the advertiser if the advertising mode allows such an operation. It means that a sizable portion of data can be received from the advertising device even without establishing a connection”

That additional packet 31 byte packet is called the scan response (extended inquiry request for 3.0). You tell the GAP layer what data the packet should contain similar to the advertising packet:

uint8 scanRspData[] = {data goes here};

GAPRole_SetParameter( GAPROLE_SCAN_RSP_DATA, sizeof ( scanRspData ), scanRspData );

Make sure your data is formatted according to BLE Core spec version 4 volume 3 chapter 11

Peter,

Is there away to get notified / setup a call back / receive an event when a controller requests the scan response data?

I'm trying to setup a very simple connectionless sensor that only awakes up / is discoverable when a change occurs. The controller should be able to then read the updated state in the scan response data. Once the sensor knows it returned at least one scan response (or hits a timeout), it will go back to sleep.

Thanks,

Dave

That sounds exciting. I had the same question in the past and I think the answer is no, the peripheral sense unit cannot tell if it was asked for a scan response. I'm not confident your idea would work.  What would happen if another scanning device were nearby?  Your sensor would stop assisting without ever communicating with the controller. 

Why not establish a secure connection with the controller?  The controller could then tell the sensor to so advertising. 

What kinda of sensor are you using?  What are you using as the controller? 

Forgive any grammar mistakes; I'm responding on a phone

I agree that as described, we would lose transitions if there were other scanning controllers in the area. There are  ways around that though. 

I'm trying to put together a very quick and dirty proof of concept of a many sensors to many controllers system. For the sake of simplicity and improved battery life, I was hoping to keep things connectionless. Battery life is much more important than really good encryption to us. The sensors need to live for 2+ years on 2 CR2032's transmitting state at least once an hour.

I really appreciate the advice. For now, connecting to the device when it's discoverable will get the job done. In the future I would like to revisit the connectionless approach if it's shown to significantly reduce transceiver on time. Since the functionality we need is so minimal, it may be worth writing a small portion of the stack to get at the information we need.

Hello David,

I too implemented sending sensor data via scan response packet and it works without initiating a connection. The beauty on this packet is that it only gets sent when someone scans for it, so the advertising packet doesn't grow. Further I used a timer to update the scan response packet e.g. every 10 minutes (so my sensor doesn't get read too often). In order to save battery power you could implement that the device goes to sleep for e.g. 10 minutes and then advertises for e.g. 30 seconds before it goes to sleep again. Thus I would expect to reach the 2+ years (depends of corse on the other HW you employ). Another option is to increase the advertising interval to the max (I believe it is around 30 seconds) and make the power calculation (TI has a nice spread sheet for this) and see if that is already satisfying.

-Kai