ESP32-C3-DevKitM-1 BLE - tx duty cycle vs. rx duty cycle

[Tiiecher]

Hello there,

I am using the ESP32-C3 DevKit with Bluetooth 5.0 mesh for my project. I have created an overload scenario where I am producing more PDUs to send than the advertising duration allows. This results in a network buffer overflow and related error messages. So far, so good.

However, there is one behavior that I do not understand. How can the node receive advertising messages with just one activated antenna, if the it has to send one advertising message after another, resulting in a 100% TX duty cycle? There seems to be no time left for the node to complete a scanning event.

Any suggestions? I have searched for a kind of prioritization, like giving scanning events higher priority over advertising events, but I haven't found anything.

Thanks a lot
Tiiecher

[bidrohini]

In the ESP32-C3 DevKit with Bluetooth 5.0 mesh, when you overload the network with more PDUs to send than the advertising duration allows, you may encounter network buffer overflow and related error messages. This is a situation where the node's ability to handle incoming advertising messages might be affected. Let's try to understand how this happens and discuss some possible suggestions.

The ESP32-C3 DevKit, like many other Bluetooth devices, operates in a time-division manner between advertising and scanning. During advertising, the device sends out advertising packets at regular intervals to broadcast its presence and make itself discoverable to other devices. During scanning, the device listens for advertising packets from other devices.

When you have a high TX (transmit) duty cycle due to back-to-back advertising events, the device indeed spends most of its time transmitting advertisements and has little time left for scanning. This can result in the device not being able to receive incoming advertising messages effectively, leading to potential missed connections or disruptions.

Here are some suggestions to address this issue:

1. **Adjust Advertising Interval:** One way to mitigate the impact of a high TX duty cycle is to increase the advertising interval. By increasing the time between advertising events, you allow more time for scanning in between advertisements. However, be mindful that increasing the interval will also reduce the frequency at which other devices can discover your device.

2. **Prioritization and Scheduling:** While Bluetooth 5.0 mesh doesn't inherently provide prioritization mechanisms, you can implement your own simple scheduling mechanism within your application. For example, you can create a time slot-based approach where you allocate specific time slots for advertising and scanning. This way, you ensure that scanning events get their dedicated time for listening to advertising packets.

3. **Throttle Advertising Rate:** If the network buffer overflow occurs due to an excessive number of PDUs generated by your application, you can throttle the advertising rate to a more manageable level. This will help in reducing the TX duty cycle, giving the device more time for scanning.

4. **Check Error Handling Mechanism:** Ensure that your application has robust error handling mechanisms in place to handle network buffer overflow and other potential issues gracefully. This can help recover from errors and resume normal operation after such events.

5. **Optimize Mesh Networking Parameters:** Review your mesh networking parameters and configurations to ensure they are optimized for your specific use case. This includes considering the number of nodes in the mesh, the size of the network, and the frequency of communication.

Remember that the ESP32-C3 DevKit's Bluetooth 5.0 mesh implementation may have some constraints and limitations, so it's essential to refer to the official documentation and forums for additional insights and best practices. Additionally, conducting thorough testing and monitoring the device's behavior under different scenarios will help you fine-tune your application for optimal performance.

[bidrohini]

In the ESP32-C3 DevKit with Bluetooth 5.0 mesh, when you overload the network with more PDUs to send than the advertising duration allows, you may encounter network buffer overflow and related error messages. This is a situation where the node's ability to handle incoming advertising messages might be affected. Let's try to understand how this happens and discuss some possible suggestions.

The ESP32-C3 DevKit, like many other Bluetooth devices, operates in a time-division manner between advertising and scanning. During advertising, the device sends out advertising packets at regular intervals to broadcast its presence and make itself discoverable to other devices. During scanning, the device listens for advertising packets from other devices.

When you have a high TX (transmit) duty cycle due to back-to-back advertising events, the device indeed spends most of its time transmitting advertisements and has little time left for scanning. This can result in the device not being able to receive incoming advertising messages effectively, leading to potential missed connections or disruptions.

Here are some suggestions to address this issue:

1. **Adjust Advertising Interval:** One way to mitigate the impact of a high TX duty cycle is to increase the advertising interval. By increasing the time between advertising events, you allow more time for scanning in between advertisements. However, be mindful that increasing the interval will also reduce the frequency at which other devices can discover your device.

2. **Prioritization and Scheduling:** While Bluetooth 5.0 mesh doesn't inherently provide prioritization mechanisms, you can implement your own simple scheduling mechanism within your application. For example, you can create a time slot-based approach where you allocate specific time slots for advertising and scanning. This way, you ensure that scanning events get their dedicated time for listening to advertising packets.

3. **Throttle Advertising Rate:** If the network buffer overflow occurs due to an excessive number of PDUs generated by your application, you can throttle the advertising rate to a more manageable level. This will help in reducing the TX duty cycle, giving the device more time for scanning.

4. **Check Error Handling Mechanism:** Ensure that your application has robust error handling mechanisms in place to handle network buffer overflow and other potential issues gracefully. This can help recover from errors and resume normal operation after such events.

5. **Optimize Mesh Networking Parameters:** Review your mesh networking parameters and configurations to ensure they are optimized for your specific use case. This includes considering the number of nodes in the mesh, the size of the network, and the frequency of communication.

Remember that the ESP32-C3 DevKit's Bluetooth 5.0 mesh implementation may have some constraints and limitations, so it's essential to refer to the official documentation and forums for additional insights and best practices. Additionally, conducting thorough testing and monitoring the device's behavior under different scenarios will help you fine-tune your application for optimal performance.