manual advertising

RE: manual advertising

run_ar — Fri, 17 Mar 2017 10:01:15 GMT

Ok, In that case, yes, you might as well use a timer to controll this as you proposed.

RE: manual advertising

vea45 — Fri, 17 Mar 2017 09:23:40 GMT

This is exactly what I'm doing now, but this way I can't set one advertisement to be sent every X seconds and the other one every Y seconds without using a timer...

RE: manual advertising

run_ar — Thu, 16 Mar 2017 15:39:15 GMT

If you need to know the exact number of advertisement sent, sure. If you don't I would just call sd_ble_gap_adv_data_set on each radio notificaiton inactive events.

RE: manual advertising

vea45 — Wed, 15 Mar 2017 12:13:15 GMT

So maybe the best option I have is to continue doing what I'm doing, but including a couple of timers that emulate the advertising_interval calling the ble_x_start functions on each timer handler...

RE: manual advertising

run_ar — Wed, 15 Mar 2017 11:44:29 GMT

You can find advertiser examples in this github project. Note that even though there is some conformance testing done on this (see different branch) this is not a qualified implementation, so I would recommend using the Softdevice if possible.

RE: manual advertising

run_ar — Wed, 15 Mar 2017 11:34:14 GMT

The time from when you call sd_ble_gap_adv_start until the first adv packet is sent will have a random delay between 0-10 ms added to it.

RE: manual advertising

vea45 — Tue, 14 Mar 2017 22:08:34 GMT

All is working perfectly, but what I can see there is that when I call some of the ble_X_start functions the device inmediately sends a packet... And the next one is after the configured interval. So I want to know if this is what I say, and also if there is some easier way to do this.

RE: manual advertising

endnode — Tue, 14 Mar 2017 21:39:44 GMT

So radio notifications work and the only problem is, that it doesn't give you interrupt before the first packet(s)? You can call it bug but I guess Nordic will call it feature (ending packets out fast looks like more important then waiting for some notification interrupt). If you really have problem with counting then simply start from 1. Am I missing something?

RE: manual advertising

vea45 — Tue, 14 Mar 2017 20:46:35 GMT

I have configured the radio notification to be callen on active and inactive radio events. So the handler is called during and after a radio event, this way I can know when a packet is sent (In my case I'm turning on a LED during the active radio period and turning off when the radio is innactive). And what I see is that the packet is sent inmediately after the ble_X_start functions..."

RE: manual advertising

endnode — Tue, 14 Mar 2017 20:04:39 GMT

Well this contradicts my experience: after calling sd_ble_gap_adv_start you get called only when radio is being deactivated (= adv. packet has been already sent) and on each next event you get called before packets are sent (boolean radio_active parameter is true) and then after it (radio_active is false). With this knowledge you can easily count everything, can't you?

RE: manual advertising

vea45 — Tue, 14 Mar 2017 19:21:47 GMT

Well the problem is that the radio notification handler is called exactly after calling "ble_advertising_start" so this indicates that a packet is sent just after calling it... So another one is sent when the interval time is reached.

RE: manual advertising

endnode — Tue, 14 Mar 2017 18:56:01 GMT

Hi,

When you use radio notification events with SD S13x it gives you first interrupt after first ADV_xxx packet is sent. So you need to start counting from there. Also remember that SDK library will call your radio notification handler twice per each interval (once before and once after) - you can detect that with bool parameter of the handler - and also note that depending on adv. channel map soft device sends 1, 2 or 3 packets during every interval. Does this solves your counting? If not could you paste your code to see where is the problem?

To your question: sure you can do advertisement "manually". Either by running custom applicative timer and using adv. start and stop or by not using Soft Device at all. Just bare in mind that a) advertisement interval should have jitter (mandated by BT SIG to prevent collisions) and b) that start/stop of advertising activity through Soft Device API isn't guaranteed to start immediately so there can be pretty random inaccuracy (on top of your timer) which can go up to +-10ms (at least this is what I've measured with S13x V2 but it might be caused by other things then Soft Device processing).

Cheers Jan