• State Suggested Answer
  • Replies 19 replies
  • Answers 2 answers
  • Subscribers 95 subscribers
  • Views 4497 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 297322
Options

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

Parents
  • 0

    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"
  • 0 in reply to AndyM

    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.

Reply
  • 0 in reply to AndyM

    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.

Children
Related
Terms of service