Receive Advertisement Packet in Mesh Beaconing Example

[SHawY]

Hi,

Got some questions about receiving adv packet in Mesh Beaconing Example:

According to the description "The beaconing example also demonstrates the usage of the Packet RX callback. This functionality allows to receive all non-filtered, BLE-compliant advertisement packets in the application code. These packets are captured by @ref SCANNER". I expect getting the iBeacon advertising but during I run the example it's actually only received adv packet from another mesh node. I'm not sure if this is how the example exactly works. Is the example could scan and print all ble adv packet or I need implement it myself ?

[SHawY]

Hi Terje,

I have changed back to default mode and now I can find other advertisements. However I found that only beacon with name can be found - I also tried create different advertiser in nRF Connect App and got the same result. Do I have to advertise the name to find them? 

I also tried implement the nRF5 SDK scanner with mesh stack. You are right I got problems with time-division multiplexing. It would be better if the rx_cb could work properly. Is there anywhere I can change the scan window and interval for beaconing example? 

I modified long range according to this. It could works with the light switch example.

[tesc]

Hi,

With the callback from the mesh stack (registered with nrf_mesh_rx_cb_set) you will only get advertisements on the same phy as the mesh is running on. That means if you look for "normal" advertisements using 1Mbit and the mesh stack runs on coded phy you will not find those normal advertisements. The mesh stack calls the callback on all advertisements that it detects, there is no requirement of e.g. name.

As mentioned in that other thread, on-air time for coded phy messages is eight times longer than for 1Mbit. This means two things: First, the chance of an advertisement packet arriving fully within a scan window is smaller. Second, the chance of a packet getting lost to noise/interference may increase (despite of the added error correction,) depending of the type of noise. Thus, which phy is best depends on the use case and RF environment.

The mesh stack uses all available time for scanning. That is, when it does not need to send a packet it will scan. Values used by the mesh stack are BEARER_SCAN_INT_DEFAULT_MS and BEARER_SCAN_WINDOW_DEFAULT_MS, which are defined along with other parameters in <sdk root folder>/mesh/bearer/api/nrf_mesh_config_bearer.h. All of those can be overridden by defining them as preprocessor defines, so there is no need to change the mesh stack files for using other values.

Regards,
Terje

[SHawY]

Hi Terje,

Much thanks for explainations. I created two advertisers in nRF Connect which advertising the same Service Data. The only different is one with Complete Local Name and the other didn't - and the scanner can only print the packet which advertising with the name. That's why I wonder if it is necessary. Do you have any idea about this?

The purpose using coded phy is trying to extend the range as much as possible in my senario. Maybe I need more test to see if it's necessary...

[tesc]

Hi,

There should not be any such restriction for the scanner in the beaconing example, no. It should detect all advertisements on the same phy as the mesh stack is running.

It may be an issue on the sender side. Have you checked to see if you receive advertisements through nRF Connect? (Either a separate session of nRF Connect for desktop, or using nRF Connect for iOS or Android.)

Regards,
Terje

[SHawY]

Yes I tried... No problem receiving advertisements through nRF Connect for iOS, could discover them both.