• State Not Answered
  • Replies 15 replies
  • Subscribers 65 subscribers
  • Views 2923 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288836
Options

Periodic Advertising

axel_s

Hi,

I recently started with nRF52840-DK, Zephyr and nRF Connect SDK (v. 1.9.1). I want to test extended advertising, that's why I use the periodic_adv example coming with thr SDK. Compiling and downloading without problems, I see in the terminal the printed outputs, mainly the counting of the simple counter in the example.

Using a Sodera sniffer, I see the three advertising frames in channels 37/38/39 of type ADV_EXT_IND, as well as the frame in one of the data channels (channel given in the advertising frames) of type AUX_ADV_IND (this frame includes too the device name I can set in the prj.conf).  What I don't see is the data, which I would expect to be in a frame shortly after AUX_ADV_IND.

When I use the periodic_sync example for reception, I'm informed too about the existence of a device with the given name (I assume that I'll receive only the data channels). But again, there is no data frame.

What have I missed to configure to be able to send data in the extended advertising?

Thanks!

Parents
  • 0

    Hi Hung Bui,

    meanwhile I did some tests without the periodic option. Last week there were some open points, but today I found my code behaving completely different (e.g. in the scan_recv() call-back function buf->len is always 0). Therefore, I took my periodic example from last week - and it's behaviour has changed too. Last week I found 3xADV_EXT_IND, one AUX_ADV_IND (containing the complete local name) and one AUX_SYNC_IND (containing the data). Now I find 3xAUX_EXT_IND, one AUX_ADV_IND (containing the data) and one AUX_CHAIN_IND (containing the complete local name).  This is strange and quite frustrating - I already opened a separate ticket. Do you know what happened here?

    Thanks, Axel

  • 0 in reply to axel_s

    Hi Axel, 

    I'm not sure why it changed like that. But from my point of view AUX_CHAIN_IND  is used when the length of the data exceed the maximum data to send in one packet and our stack will automatically change the advertising to chained advertising. Could you try to test with smaller data size ? Maybe the stock example when only 3 bytes are sent ? 

  • 0 in reply to Hung Bui

    Hi Hung Bui,

    In my application I need to receive 600 bytes, which requires chaining the periodic advertisements.  I’m using these same periodic advertising samples, but for NCS v 2.3.0 rc1.

    My issue is that the network buffer in the .recv (recv_cb() function in periodic_sync ) doesn’t seem to support packets greater than 254 bytes.  Do you know if there’s a Kconfig option that I need to set to be able to receive 600 bytes as 1 report?

    Thanks!

Reply
  • 0 in reply to Hung Bui

    Hi Hung Bui,

    In my application I need to receive 600 bytes, which requires chaining the periodic advertisements.  I’m using these same periodic advertising samples, but for NCS v 2.3.0 rc1.

    My issue is that the network buffer in the .recv (recv_cb() function in periodic_sync ) doesn’t seem to support packets greater than 254 bytes.  Do you know if there’s a Kconfig option that I need to set to be able to receive 600 bytes as 1 report?

    Thanks!

Children
Related