Zephyr BLE Mesh Publication sending took longer than the period

Dear Nordic-Team,

I’m developing multiple Bluetooth sensors for a "high" speed sensor network (maximum 12 sensors). To network topology requirements BLE Mesh fits best.

My "high" speed requirements for all sensors looks like, sending 32 Byte within 10ms, or sending 96 Byte within 30ms. 

I’m working with following setup:

- Thingy52 / Adafruit Feather nRF52840 / nRF52840 Dongle

- nRF Connect SDK v2.1.0 / Zephyr

- BLE Mesh Sensor Server/Client example (with modified descriptor for temperature sensor)

model_handler.c

...

static const struct bt_mesh_sensor_descriptor temp_desc = {

    .sampling_type = BT_MESH_SENSOR_SAMPLING_COUNT,

    .period = 300,

    .update_interval = 50,

};

 

static struct bt_mesh_sensor chip_temp = {

    .type = &bt_mesh_sensor_present_dev_op_temp,

    .get = chip_temp_get,

    .descriptor = &temp_desc,

};

...

Sending with BLE GATT notification (connection interval 7,5ms, PHY 2M) this works like a charm. 

Sending with BLE Mesh Sensor Server causes the following message:
[133]
D: Delta: -1.750000 (21.000000 - 20.750000) thrsh: 0.000000
W: Publication sending took longer than the period
D: #3 Period: 100 ms Divisor: 0 (fast)

The period is set to 100ms, but the actual period is about 133ms. Therefore, the warning is printed.

Are there any SW/HW limitations on the advertising channel in BLE Mesh?
How can I achieve my speed requirements? (BLE with GATT, BLE Mesh, or fallback to ESB)

Thank you for your advice.

 

Kindly regards,

Robert

2843.sensor_server.zip

Parents Reply Children
  • Good Morning Torbjørn

    do you have any updates to this issue?

    according to Mesh Profile specification https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634#page105

    the definition of update Intervall is:

    4.1.1.6 Sensor Update Interval
    The measurement reported by a sensor is internally refreshed at the frequency indicated in the Sensor Update Interval field (e.g., a temperature value that is internally updated every 15 minutes). This field specifies a uint8 value n that determines the interval (in seconds) between updates, using the formula:
    = 1.1n−64
    For those cases where a value for the Sensor Update Interval is not available or is not applicable, a special number has been assigned to indicate Not Applicable. The values for the state are defined in the following table.

    My point of view is, that theoretically 10 or 30 ms should be possible, but technically this might be hard to reach.

    Kindly regards,

    Robert

  • Hi Robert! 

    I have to apologize for the long delay here! I've missed your reply to the ticket.

    Robert Krahl said:
    My point of view is, that theoretically 10 or 30 ms should be possible, but technically this might be hard to reach.

    Theoretically yes.

    Note that the Mesh Specification limits devices to transmit only 100 messages over a period of 10 seconds. You should be able to transfer more, but you will no longer be compliant with the specification.

    sending 32 Byte within 10ms, or sending 96 Byte within 30ms. 

    BLE Mesh have limited throughput and you will not be able to fit 32 bytes in a single packet, if that is what you are looking for? Are you using segmented messages? Or just sending 32/96 bytes over a duration of 10/30 ms?

    Br, 
    Joakim

Related