Boost Meshtastic Performance: Node-Side BLE Configuration

Aug 20, 2025 by Benjamin Cohen 58 views

Feature Request: Node-Side Configuration for BLE MTU Size and Data Length Extension

Hey everyone! Let's dive into a super interesting feature request focusing on BLE MTU size and Data Length Extension configuration directly on the node side. This is a cross-platform discussion, but it's particularly relevant for those of us working with iOS devices and Meshtastic firmware. Currently, iOS apps have limitations when it comes to requesting MTU sizes or enabling BLE Data Length Extension, which means we need to find a way for our peripherals to handle these negotiations.

Understanding the Issue with BLE MTU Size and Data Length

So, the core problem is that iOS apps communicating with BLE peripherals can't directly request a specific MTU size or enable BLE Data Length Extension (DLE). This puts the onus on the peripheral devices to negotiate these parameters with the Core Bluetooth central manager instance. The current Device API documentation explicitly asks for clients to request a 512 MTU, but iOS clients can't do this natively today. This limitation can impact the efficiency and speed of data transfer, especially in mesh networks where we're constantly exchanging information.

I've been experimenting with a custom firmware build to address this, and I've seen some promising results. But before I go too far down this road, I wanted to gauge the community and maintainers' interest in a contribution to help solve this issue. Essentially, we're talking about enabling node-side configuration for BLE MTU size and DLE, giving us more control over how our devices communicate.

Diving Deeper into the Technical Details

To give you a clearer picture, I’ve been working with a Station G2 and Heltec v3, using the NimbleBluetooth framework. The key is to set the MTU size on the node side and enable Data Length Extension. This allows us to increase the amount of data we can send in each packet, which can lead to significant performance improvements. For instance, increasing the MTU size to 512 bytes (from the current 252) can make a noticeable difference in throughput.

Here’s a snippet of the code I’ve been using successfully on firmware version 2.6.11:

void NimbleBluetooth::setup()
{
    NimBLEDevice::setMTU(512);

This line sets the MTU size to 512 bytes. To confirm this is working, you can check peripheral.maximumWriteValueLength(for: .withoutResponse) in Core Bluetooth on the iOS side. You should see the increased MTU size reflected there.

But setting the MTU is just one piece of the puzzle. We also need to enable Data Length Extension to maximize the amount of data we can send per packet. Here’s the code I’ve been using to enable DLE:

virtual void onConnect(NimBLEServer *pServer)
{
    LOG_INFO("BLE device connected");
   
    std::vector<uint16_t> connHandles = pServer->getPeerDevices();
    if (!connHandles.empty()) {
        uint16_t connHandle = connHandles[0];
        
        int result = ble_gap_set_data_len(connHandle, 251, 2120); 
        if (result == 0) {
            LOG_INFO("DLE enabled: 251 bytes per packet");
        } else {
            LOG_WARN("DLE configuration failed: %d", result);
        }
    }
    
    bluetoothStatus->updateStatus(new meshtastic::BluetoothStatus(meshtastic::BluetoothStatus::ConnectionState::CONNECTED));
}

This code snippet is executed when a BLE device connects. It retrieves the connection handle and then calls ble_gap_set_data_len to set the data length. In this example, I’m setting the data length to 251 bytes per packet, with a maximum transmit time of 2120 microseconds. If the function returns 0, it means DLE was enabled successfully. Otherwise, it logs a warning message.

The Potential Impact and Benefits

Enabling BLE MTU size configuration and Data Length Extension on the node side can bring several benefits:

Improved Data Transfer Speed: By increasing the MTU size and enabling DLE, we can send more data in each packet, which reduces the overhead and improves overall data transfer speed. This is crucial for mesh networks where we need to exchange data efficiently.
Enhanced Reliability: Larger packets can also improve the reliability of data transfer. By reducing the number of packets required to send a message, we reduce the chances of packet loss and retransmissions.
Better User Experience: Faster and more reliable data transfer translates to a better user experience. Apps will be more responsive, and users will experience fewer delays.
Optimized Battery Life: While it might seem counterintuitive, sending data more efficiently can actually improve battery life. By reducing the amount of time the radio is active, we can conserve power.

How Can We Make This Configurable?

Now, the question is: how can we make this configurable in a user-friendly way? My initial thought is that this could be configured, enabled, or disabled through the BluetoothConfig protobuf. This would allow users to easily adjust these settings without having to modify the firmware directly.

Imagine a scenario where you could go into your Meshtastic app, navigate to the Bluetooth settings, and have options to set the MTU size and enable/disable DLE. This would give users a lot of flexibility to fine-tune their devices for optimal performance in different environments.

Community Input and Next Steps

I’m really interested in hearing your thoughts on this. Do you think this is a valuable feature to add to Meshtastic? Are there any potential drawbacks or challenges that we should consider? How would you like to see this implemented from a user perspective?

I believe that by enabling node-side configuration for BLE MTU size and Data Length Extension, we can significantly improve the performance and reliability of Meshtastic networks, especially when used with iOS devices. But it’s crucial that we do this in a way that is user-friendly and doesn’t introduce any new issues.

So, let’s discuss this further! I’m eager to hear your ideas and feedback. Together, we can make Meshtastic even better!

Potential Challenges and Considerations

While the benefits of configuring BLE MTU size and DLE are clear, there are a few potential challenges and considerations we need to address:

Compatibility: We need to ensure that any changes we make are compatible with a wide range of devices and operating systems. While iOS is a primary focus, we also need to consider Android and other platforms.
Power Consumption: While optimized data transfer can improve battery life, we need to carefully test and monitor power consumption to ensure that we're not introducing any regressions.
Stability: Any changes to the Bluetooth stack need to be thoroughly tested to ensure stability and prevent crashes or other issues.
User Experience: As mentioned earlier, it's crucial that any new configuration options are user-friendly and easy to understand. We don't want to overwhelm users with technical jargon or complex settings.

Exploring Implementation Options

If we decide to move forward with this feature, there are several implementation options we could consider:

BluetoothConfig Protobuf: As I mentioned earlier, using the BluetoothConfig protobuf seems like a natural fit. We could add new fields to this protobuf to allow users to configure the MTU size and enable/disable DLE.
Command-Line Interface (CLI): For more advanced users, we could also provide a CLI option to configure these settings. This would allow users to fine-tune their devices from a terminal.
Web Interface: If we eventually develop a web interface for Meshtastic, we could include these settings there as well. This would provide a graphical interface for users who prefer not to use the command line.

Let's Collaborate and Build Something Awesome!

This is a really exciting opportunity to improve Meshtastic, and I'm looking forward to collaborating with all of you to make it happen. Your input and expertise are invaluable, and together, we can build something truly awesome.

So, please share your thoughts, ideas, and concerns. Let's discuss the best way to implement this feature and make Meshtastic even more powerful and user-friendly. Whether you're a seasoned developer or a curious user, your voice matters!