Zephyr BLE Mesh Publication sending took longer than the period

[Robert Krahl]

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

[Joakim Jakobsen]

Hi! 

Thank you for your question. I’ll look into this closer and get back to you later today. 

br, 

Joakim

[Joakim Jakobsen]

Hi again.

Not quite sure why you are seeing this extended period. Will forward this to our Mesh developers so they can comment on this.

Br,
Joakim

[Joakim Jakobsen]

Hi.

Thank you for your patience. I haven't gotten any feedback on this yet. I'll ask for an update as soon as possible!

BR,
Joakim

[Robert Krahl]

Hello Joakim,

thank you for your effort. I am still searching for some new ideas. Recently found following links:

https://github.com/zephyrproject-rtos/zephyr/issues/13553
Increasing Mesh TX max transmit frequency - nrf52840

Is the transmission count per second limited by BLE Mesh specification to 10 per second?

Well for me it is quiet hard to read BLE specification. Otherwise might it be possible to work temporary outside the specification e.g in a 30ms cycle?

Kindly regards,

Robert

[ovrebekk]

Hi Robert

Unfortunately because of the Christmas holiday response will be slower than normal. Joakim will get back to you on this topic when he is back next week. 

Best regards
Torbjørn

[Robert Krahl]

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

[Joakim Jakobsen]

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