nrf52840 view advertising data

[devtty]

Hello,

In a previous post I asked about scanning and connecting based on specific advertised data. After some testing I realized that my two nrf dks only connect sometimes. For example, it seems that the peripheral must always be advertising before the central scans, and even then often the two boards never connect, usually I have to restart the central a couple times. I can verify that the peripheral is advertising and the central is scanning(no matter how long I wait they wont connect unless i restart the central a couple times). In order to aid in debugging how can I print out and view the advertising data that the central scanned? Preferably in the scan_evt_handler()? Thanks!

[Karl Ylvisaker]

Hello,

I can verify that the peripheral is advertising and the central is scanning(no matter how long I wait they wont connect unless i restart the central a couple times). In order to aid in debugging how can I print out and view the advertising data that the central scanned? Preferably in the scan_evt_handler()?

I think we first should ensure that the peripheral is advertising, and that the central is scanning.
How are you verifying that the peripheral is advertising, and that the central is scanning?
What is your advertising interval and duration, and what is your central's scan window and interval?

For example, it seems that the peripheral must always be advertising before the central scans, and even then often the two boards never connect, usually I have to restart the central a couple times.

Yes, the peripheral must be advertising before a connection can be established. 

There could be many reasons why you are not seeing all the advertisements on the other side of your link. For example, one of the three advertisement channels can be completely engulfed in the noise from a WiFi network, or the route of your packets may be blocked by dense obstructions, etc.
How are the two devices positioned in relation to each other? What is the distance between them, and do they have line of sight?
Does this testing happen in a noisy environment?

Are you familiar with the nRF Sniffer tool? It is a powerful tool to wield when developing with BLE, since it allows you to monitor the on-air BLE traffic. This could be helpful to take a look at in this case, to get a better overview of what is happening on the air. Please keep in mind that the Sniffer only reports on the packets that it successfully is able to intercepts, so it may loose the same amount of packets as the central, if placed with a similar position and environment.

Looking forward to resolving this issue together!

Best regards,
Karl

[devtty]

Karl Ylvisaker said:

How are you verifying that the peripheral is advertising, and that the central is scanning?
What is your advertising interval and duration, and what is your central's scan window and interval?

I verified the peripheral is advertising by using the nrfConnect app to see it. I also just used that nrf Sniffer tool and saw pieces of my advertising data. For the scanning all I did was simply put a print statement within the scan_evt_handler() to see that events were occurring.

I have the Advertising setup like so:  

init.advdata.flags              = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE; // gives us the ability to advertise indefinetely. limited -> BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE;

init.srdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
init.srdata.uuids_complete.p_uuids  = m_adv_uuids;

init.config.ble_adv_fast_enabled  = true;
init.config.ble_adv_fast_interval = APP_ADV_INTERVAL;
init.config.ble_adv_fast_timeout  = 0; 

and the interval/ duration:

#define APP_ADV_INTERVAL                64                                          /**< The advertising interval (in units of 0.625 ms. This value corresponds to 40 ms). */

#define APP_ADV_DURATION                18000                                       /**< The advertising duration (180 seconds) in units of 10 milliseconds. */

The scan interval/window defined in the SDK_CONFIG.h is:

NRF_BLE_SCAN_SCAN_INTERVAL 160

NRF_BLE_SCAN_SCAN_WINDOW 80

NRF_BLE_SCAN_SCAN_DURATION 0

Karl Ylvisaker said:

How are the two devices positioned in relation to each other? What is the distance between them, and do they have line of sight?
Does this testing happen in a noisy environment?

The devices are like a foot apart, just doing some testing at my desk. 

Karl Ylvisaker said:

Yes, the peripheral must be advertising before a connection can be established. 

Sorry for the confusion what I meant was it seems that the order of events for me to get a successful connection must be:

1. peripheral advertising 2. central is scanning. If its 1.central is scanning 2. Peripheral begins advertising I don't seem to get a connection. 

I know that was A LOT. So thank you :) 

[Karl Ylvisaker]

Hello,

devtty said:

I know that was A LOT. So thank you :) 

No problem at all, I am happy to help!

devtty said:

I verified the peripheral is advertising by using the nrfConnect app to see it. I also just used that nrf Sniffer tool and saw pieces of my advertising data. For the scanning all I did was simply put a print statement within the scan_evt_handler() to see that events were occurring.

I understand - if you saw the advertising packets using the sniffer and nRF Connect then we at least know that the peripheral is advertising.
I think we need to take a closer look at the central's behavior, and the scanning in particular.
Could you elaborate what you mean when you say that you saw pieces of the advertising data using the sniffer? If you select your device from the 'device select' dropdown menu in wireshark it will filter for packets inbound/outbound from a specific device - this will make it alot easier to keep track of what a particular device is doing. 

Back to your question about printing out the data the central sees, you can use the BLE_GAP_EVT_ADV_REPORT event to see the received advertising data.

devtty said:

The devices are like a foot apart, just doing some testing at my desk. 

devtty said:

Sorry for the confusion what I meant was it seems that the order of events for me to get a successful connection must be:

1. peripheral advertising 2. central is scanning. If its 1.central is scanning 2. Peripheral begins advertising I don't seem to get a connection. 

Thank you for clarifying this, this is very helpful for me to know.
With the advertising and scanning configuration you describe in your comment you should see the peripheral advertise once every 40 ms, for 180 seconds. The Central should be scanning for 80 ms every 160 ms, indefinitely. I dont see any good reason for why the peripheral's advertising needs to start before the scanning, since the scanning goes on indefinitely (until stopped explicitly). Is there any place in your code in which you explicitly stop scanning? Could it be that the device goes into SYSTEM OFF sleep if it scans for a certain duration without finding anything? Could you set breakpoints on all scanning-stopping sections of your code, such as going to SYSTEM_OFF sleep and explicitly stopping scanning statements, and then try again with having the central scan for a while before the peripheral begins advertising?

Looking forward to resolving this issue together!

Best regards,
Karl

[devtty]

There were no sleeps (well after I commented them out). After printing out the advertising data successfully with  BLE_GAP_EVT_ADV_REPORT  it narrowed it down to scan_evt_handler() which is where the issue was (some incorrect advertisement parsing on my end before connection was wrong). 

However this has left me with some more questions and issues. For example, I am using the dk boards as relays. If i connect to one of the boards with the nrf connect app and send it data the LEDs should blink by design, this only happens when the board is plugged in to the computer and I run it in segger with "Build and debug". If i simply just power the board it doesnt work. And on another note the data does not get forwarded....

This is likely an unrelated issue. Please let me know if I should create a different ticket to resolve these other problems. Thanks so much for your assistance. 

[Karl Ylvisaker]

devtty said:

There were no sleeps (well after I commented them out). After printing out the advertising data successfully with  BLE_GAP_EVT_ADV_REPORT  it narrowed it down to scan_evt_handler() which is where the issue was (some incorrect advertisement parsing on my end before connection was wrong).

I am glad to hear that you were able to identify and resolve this issue! 

devtty said:

However this has left me with some more questions and issues. For example, I am using the dk boards as relays. If i connect to one of the boards with the nrf connect app and send it data the LEDs should blink by design, this only happens when the board is plugged in to the computer and I run it in segger with "Build and debug". If i simply just power the board it doesnt work. And on another note the data does not get forwarded....

In general I recommend that you create a new ticket for any topic or questions that diverge from your original issue, so that the forum is kept tidy and easy to navigate for other users. - It is fine to have multiple open tickets as well, if you encounter multiple different issues or questions.
I will however write down my initial thoughts when reading your description of the new issue would be to check whether the program is running at all when not connected to the PC. To do this, you should use the LEDs to indicate the different states of the board, for example by blinking certain leds upon board startup and 'application running'. If they do not blink as expected, you should look into the power source and power configuration of the board, or check if the board is resetting because of some fault in the application. If the LEDs do show up correctly I would proceed to debug exactly where in the program execution the program is failing. For example, is the device advertising, or does the device reboot when a central attempts to connect.

Please try this, and if it does not aid you in identifying and resolving the issue please do not hesitate to open another ticket detailing your current issue and results from these tests so we may take a look at it together.

devtty said:

Thanks so much for your assistance. 

No problem at all, I am happy to help!

Best regards,
Karl