Questions about Nordic Distance Measurement library sample

[AndyM]

1. The code uses a value 0xFF55AA5A to identify the adv packet as the one that supports distance measurement. Is this value checked by  lower layers?

If not - why not just use 1 bit ?

2. The advertising interval in the sample is set to BT_GAP_ADV_FAST_INT_MIN_1 ( 30 ms )

Have slower intervals been tested ? My concern is the device battery life

3. My application uses mesh and its scanner ( registers a scanner callback )

Have the app been tested with mesh? 

Thanks

[Amanda Hsieh]

Hi, 

2): You should be able to reduce the time, but that means that it takes longer until the ranging starts.

3): We are working on this. 

I will be back with the answer for Q1.

Regards,
Amanda 

[AndyM]

Sorry, accidentally hit a wrong button to mark the previous response as a suggested answer. Wonder if this can be undone.

This is far from resolved

I did some digging and it looks like the sample is not going to work out of the box with mesh because it wants to start scan in active mode as it needs to call the distance library API during a scan response. However mesh starts scan in passive mode in

bt_mesh_scan_enable() in adv.c 

I'm going to  poke around some more, but if you have any suggestions how to get around this - please share

Thanks

[AndyM]

Update
I was able to incorporate the DM library into my app that uses mesh.

Details

1. It does not work out of the box because mesh uses a passive scan and DM library requires an active scan. And starting another scanner after mesh is initialized  returns -EALREADY
Had to change the scan type to BT_HCI_LE_SCAN_ACTIVE in adv.c: bt_mesh_scan_enable() 

This is obviously a hack just to prove it can work.

With this change dm library coexists with mesh just fine. I was able to provision my devices, send data over mesh network while measuring distance between them.
There is a need for an API to update the mesh scan parameters. Or provide them in the bt_mesh_init() function

2. the "supports_dms" field uses the value 0xFF55AA5A  - it does not appear to be a magic value. I replaced it with 1 and it still works 

I need those extra bits in the packet for application data. Just adding 8 bytes for "suppports_dms" and  "access_address" fields required by the DM library, result in an error "packet too big"

[Amanda Hsieh]

Hi, 

From the team:

1. The code uses a value 0xFF55AA5A to identify the adv packet as the one that supports distance measurement. Is this value checked by  lower layers?

If not - why not just use 1 bit ?

 This value is defined in the sample code and is used be the bt_scan module to identify device that support distance measurement. This value is not used by the subsys/dm module.

I thing the value could be shorter, such as 1 byte. The length of data passed to bt_scanis given in bytes. We used 4 byte value to avoid situations where other device that also advertise `MANUFACTURER_DATA` (but not support DM) have the same byte sequence after the company_cod field.

As for mesh, it will be nice if you wait a bit. If you want to try, you can use model messages to achieve synchronization as shown here:
https://github.com/omkar3141/sdk-nrf/commit/53fb0582da728e3b35e125bfc971c1cb8d5962d8

To evaluate, flash the light and light_switch on two boards, and press SW0 on the light_switch sample.

-Amanda H.

[AndyM]

Not sure I understand the part of your answer that pertains to mesh
Are you saying that mesh support for active scan will be implemented later?

Thanks