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 ?

[tesc]

HI,

The Beaconing example should print info for all packets received, as is. This is done in main.c with the function rx_cb, which is a callback function that gets registered by the line "nrf_mesh_rx_cb_set(rx_cb);" in mesh_init() also in main.c.

What does the output that you do get look like? Can you share it?

Regards,
Terje

[SHawY]

Hi Terje,

Here's what I got after I flash the example,

<t: 0>, main.c, 225, ----- Bluetooth Mesh Beacon Example -----
<t: 13436>, main.c, 231, Initialization complete!
<t: 18239>, advertiser.c, 323, advertiser_enable
<t: 18241>, prov_bearer_adv.c, 408, PB-ADV: context at 0x20002F64 added to bearer
<t: 18246>, mesh_app_utils.c, 65, Device UUID (raw): D5663AB3804DC24FB36A7B17B215CC75
<t: 18249>, mesh_app_utils.c, 66, Device UUID : B33A66D5-4D80-4FC2-B36A-7B17B215CC75
<t: 18257>, net_beacon.c, 368, net_beacon_enable
<t: 18263>, main.c, 260, Bluetooth Mesh Beacon example started!

And nothing print else while actually there are several ble device advertsing nearby. Until I turn on a mesh node I got this:

<t: 7783267>, net_beacon.c, 419, SNB RX ID: 54D021362603E40E ivu: 0 kr: 0 IV: 0
<t: 7783275>, main.c, 87, RX [@237524360]: RSSI: -20 ADV TYPE: 2 ADDR: [98:fe:b7:55:a6:eb]: 172B010054D021362603E40E00000000C1ABE802E7AEC2C7
<t: 8102924>, net_beacon.c, 419, SNB RX ID: 54D021362603E40E ivu: 0 kr: 0 IV: 0
<t: 8102932>, main.c, 87, RX [@247279514]: RSSI: -23 ADV TYPE: 2 ADDR: [98:fe:b7:55:a6:eb]: 172B010054D021362603E40E00000000C1ABE802E7AEC2C7
<t: 8454414>, net_beacon.c, 419, SNB RX ID: 54D021362603E40E ivu: 0 kr: 0 IV: 0
<t: 8454422>, main.c, 87, RX [@258006141]: RSSI: -24 ADV TYPE: 2 ADDR: [98:fe:b7:55:a6:eb]: 172B010054D021362603E40E00000000C1ABE802E7AEC2C7

The example should also advertise it's name("Nordic Semi Mesh") according to the instruction but I can't find such node in nRF Connect App.

[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.

[tesc]

Hi,

Going back to what output to expect from the example, this is the log I get when testing here (with a few BLE devices in the area):

<t:          0>, main.c,  218, ----- Bluetooth Mesh Beacon Example -----
<t:      13970>, main.c,  224, Initialization complete!
<t:      18734>, mesh_app_utils.c,   65, Device UUID (raw): 073D03C4720B6745AB6E06D305F13C5E
<t:      18737>, mesh_app_utils.c,   66, Device UUID : C4033D07-0B72-4567-AB6E-06D305F13C5E
<t:      18748>, main.c,  253, Bluetooth Mesh Beacon example started!
<t:      33706>, main.c,   87, RX [@1028329]: RSSI: -82 ADV TYPE: 4 ADDR: [c6:54:7a:9b:36:f8]: 0B0972757769646F20424C45
<t:     133396>, main.c,   87, RX [@4070477]: RSSI: -92 ADV TYPE: 4 ADDR: [b7:34:ba:c7:52:04]: 020A0A1B094C452D426F736520436F6C6F7220494920536F756E644C696E6B
<t:     192247>, main.c,   87, RX [@5866604]: RSSI: -81 ADV TYPE: 4 ADDR: [d2:9e:a7:a1:41:2c]: 020A080E094C452D72657365727665645F43
<t:     314305>, main.c,   87, RX [@9591431]: RSSI: -89 ADV TYPE: 4 ADDR: [b7:34:ba:c7:52:04]: 020A0A1B094C452D426F736520436F6C6F7220494920536F756E644C696E6B
<t:     605565>, main.c,   87, RX [@18480001]: RSSI: -84 ADV TYPE: 4 ADDR: [76:7b:a7:a1:41:2c]: 020A0816094C452D426F736520467265652048656E72696B6B65
<t:     769199>, main.c,   87, RX [@23473756]: RSSI: -82 ADV TYPE: 4 ADDR: [d2:9e:a7:a1:41:2c]: 020A080E094C452D72657365727665645F43

Comparing it to the log that you provided earlier, I see that the line numbers for corresponding log outputs do not match. Can you double check that you are using the unmodified example from the <SDK folder>/examples/beaconing/ folder? (With unmodified main.c in the src folder of that folder.)

Regards,
Terje

[SHawY]

Hi Terje,

I'm sure I'm using the unmodified files. Here's what I tried:

I create two advertiser which advertising User Data, the first one advertsing the Local Name as well.

When I enable either of them or both, only the one with Local Name can be found during scanning (ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344)

<t:          0>, main.c,  218, ----- Bluetooth Mesh Beacon Example -----
<t:      12870>, main.c,  224, Initialization complete!
<t:      17601>, mesh_app_utils.c,   65, Device UUID (raw): 83C4140939D7514483FD76458708046C
<t:      17605>, mesh_app_utils.c,   66, Device UUID : 0914C483-D739-4451-83FD-76458708046C
<t:      17616>, main.c,  253, Bluetooth Mesh Beacon example started!
<t:     113982>, main.c,   87, RX [@3478019]: RSSI: -86 ADV TYPE: 0 ADDR: [8a:08:6c:8d:cd:c0]: 0709534D492D4D31031900000201060F1695FE3120A1011D8A086C8DCDC00D
<t:     175528>, main.c,   87, RX [@5356307]: RSSI: -86 ADV TYPE: 0 ADDR: [8a:08:6c:8d:cd:c0]: 0709534D492D4D31031900000201060F1695FE3120A1011D8A086C8DCDC00D
<t:     299087>, main.c,   87, RX [@9127103]: RSSI: -88 ADV TYPE: 0 ADDR: [8a:08:6c:8d:cd:c0]: 0709534D492D4D31031900000201060F1695FE3120A1011D8A086C8DCDC00D
<t:     360440>, main.c,   87, RX [@10999283]: RSSI: -89 ADV TYPE: 0 ADDR: [8a:08:6c:8d:cd:c0]: 0709534D492D4D31031900000201060F1695FE3120A1011D8A086C8DCDC00D
<t:     362671>, main.c,   87, RX [@11067431]: RSSI: -64 ADV TYPE: 4 ADDR: [50:9c:36:34:2d:58]: 09094D4A5F48545F563105030F180A180916FFFFD65F151E817F
<t:     428411>, main.c,   87, RX [@13073674]: RSSI: -72 ADV TYPE: 4 ADDR: [50:9c:36:34:2d:58]: 09094D4A5F48545F563105030F180A180916FFFFD65F151E817F
<t:     483872>, main.c,   87, RX [@14766208]: RSSI: -88 ADV TYPE: 0 ADDR: [8a:08:6c:8d:cd:c0]: 0709534D492D4D31031900000201060F1695FE3120A1011D8A086C8DCDC00D
<t:     516380>, main.c,   87, RX [@15758347]: RSSI: -63 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     525718>, main.c,   87, RX [@16043348]: RSSI: -66 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     535036>, main.c,   87, RX [@16327704]: RSSI: -61 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     544388>, main.c,   87, RX [@16613116]: RSSI: -63 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     545312>, main.c,   87, RX [@16641227]: RSSI: -87 ADV TYPE: 0 ADDR: [8a:08:6c:8d:cd:c0]: 0709534D492D4D31031900000201060F1695FE3120A1011D8A086C8DCDC00D
<t:     563025>, main.c,   87, RX [@17181865]: RSSI: -67 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     572322>, main.c,   87, RX [@17465615]: RSSI: -67 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     581784>, main.c,   87, RX [@17754364]: RSSI: -78 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     591204>, main.c,   87, RX [@18041864]: RSSI: -69 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     600830>, main.c,   87, RX [@18335615]: RSSI: -73 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     607049>, main.c,   87, RX [@18525331]: RSSI: -87 ADV TYPE: 0 ADDR: [8a:08:6c:8d:cd:c0]: 0709534D492D4D31031900000201060F1695FE3120A1011D8A086C8DCDC00D
<t:     610275>, main.c,   87, RX [@18623857]: RSSI: -63 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     619532>, main.c,   87, RX [@18906358]: RSSI: -63 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344
<t:     628911>, main.c,   87, RX [@19192608]: RSSI: -63 ADV TYPE: 6 ADDR: [a4:e8:6c:8a:31:45]: 0E094F6E65506C757320372050726F07161C1811223344

[tesc]

Hi,

I am able to reproduce. Looking into why this may be.

Regards,
Terje