(19) Struggling with the coexistence of BLE and IEEE802.15.4! - Development Log @ 2025/06/16 (Mon)

I've uploaded the latest development diary! I really struggled with the coexistence of BLE and IEEE802.15.4, but the moment the motor moved, I was truly moved! There's still a stuttering issue, but progress is solid! Everyone, please take a read!

Challenge of linking BLE transmission and MAUI app

This part covers the struggle to set up the mechanism for sending data via BLE while ensuring the MAUI app could receive it. It started with simple byte array transmission, but I hit a series of trial-and-error issues with the MAUI app's notification settings and scanning problems.

The first step of byte array transmission

First, to send data from the ESP32 via BLE, I started by constructing a 5-byte byte array and sending it with `ble_bidi_fast_tx_send`. I thought, "I'll just pack the motor number, position, and acceleration into the payload and send it!" but an error occurred because the MAUI app side wasn't ready (lol). I realized that notification settings needed to be turned on in the app, so I added `_bleCharacteristicTX.StartNotificationsAsync()` within `SynchroDeviceManager`'s `OnBleDeviceConnectionStateChanged`. I was all fired up thinking this would work, but then I faced a problem where the device wouldn't show up in scans. It was a moment where I held my head in my hands, wondering, "Why? It was working until yesterday."

The wall of notification settings and scanning

Once I added the notification settings, I ran into a problem where the device couldn't be found during scanning. When I thought about the cause, I suspected changing the antenna to a shorter cable or turning on IEEE802.15.4 reception. I tried moving the antenna closer, but there was no change. Then, when I turned off IEEE802.15.4... oh, the device appeared! But does this mean BLE and IEEE802.15.4 can't work at the same time? I panicked a bit, but looking at the logs, it seemed like reception was working. I realized the Coexistence setting was likely the problem and started tweaking it. This was the start of a storm of trial and error!

Struggling with Coexistence settings

To realize the coexistence of BLE and IEEE802.15.4, I adjusted the Coexistence settings many times. While trying HIGH, MIDDLE, and LOW, I searched for settings that would allow both BLE scanning and IEEE802.15.4 reception. Since the result changes drastically with just one setting, it was extremely nerve-wracking!

Initial Coexistence settings and trial and error

Even though the Coexistence API should help with the coexistence of BLE and IEEE802.15.4, it wouldn't show up in scans with the initial settings (`idle=HIGH, txrx=HIGH, txrx_at=LOW`). I tried changing to balance settings or stopping the API call itself. When I tried removing `esp_ieee802154_set_coex_config`, it scanned successfully! However, I was worried that the priority of IEEE802.15.4 would drop, so I was concerned about whether the motor control would work properly. Checking how the API is used on GitHub, I found that `txrx=MIDDLE` and `txrx_at=MIDDLE` seemed good. When I set it to `idle=IDLE, txrx=MIDDLE, txrx_at=MIDDLE`, both scanning and reception were OK! It felt like, "I did it!"

Motor control and stuttering issues

With the Coexistence settings stabilized, I tested the motor control. On Windows, a single motor was smooth, but when I moved two motors simultaneously on Android, it stuttered. It was the same on iOS. There was no queue overflow in the logs, so is the MAUI app's notification setting or the increase in the number of motors having an effect? I tried turning off notifications and reducing the number of motors, but it didn't improve. In the end, it seems like high-frequency BLE transmission is the bottleneck. I changed it to send multiple commands at once, but the stuttering didn't resolve. When I realized the slider wasn't designed for multi-touch, I laughed and thought, "Wait, seriously?" but I'll put this issue on hold for now. Let's move on!

Data reception from FIZ unit and motor control

This is the part where I receive data from the FIZ unit via IEEE802.15.4, send it to the MAUI app via BLE, and move the motor. From data analysis to reflecting it on the slider, it's finally taking shape, but the stuttering during simultaneous control remains an issue.

Data reception and analysis

I re-enabled notifications to send data from the FIZ unit to the MAUI app via BLE. When I set it to `txrx_at=MIDDLE`, IEEE802.15.4 reception was perfect! I added the `_bleCharacteristicTX.ValueChanged` event on the app side and received 5 bytes of data. Looking at the logs, the channel, motor number, and position matched the ESP32 side! But I was surprised to find that the event handler wasn't on the main thread. I used `MainThread.BeginInvokeOnMainThread` to reflect it on the slider. Data analysis went smoothly, and I was able to accurately obtain the motor position. It was a moment where my excitement peaked, thinking, "Finally, I'm going to move the motor!"

Motor control and the pursuit of smoothness

I searched for the active motor and reflected the received position data. When I checked the channel and motor number with `foreach` and set the position... it moved! I was so moved when I confirmed it with GIFs and videos! However, even when I stopped the log output, the smartphone side stuttered during simultaneous control of multiple motors. There were no errors on the ESP32 side, so maybe the MAUI app's processing is heavy. Is the property setting of `CommunityToolkit.Mvvm` putting a burden on it? I tried queuing, but it had little effect. I started thinking that since the code has become complex, I need to split the functions.

Summary

This day was spent giving my all to the coexistence of BLE and IEEE802.15.4.
Starting with byte array transmission, MAUI app notification settings, Coexistence adjustments, data reception from the FIZ unit, and finally motor control—it was incredibly intense! Especially with the Coexistence settings, I tried out HIGH and MIDDLE repeatedly, and when I finally managed to achieve both scanning and reception with `idle=IDLE, txrx=MIDDLE, txrx_at=MIDDLE`, I felt like pumping my fist in victory. The motor control looked impressive in the GIF, but the stuttering during simultaneous control of multiple motors remains a major issue. Looking at the logs, there are no errors, and the queue isn't a bottleneck, so the processing load on the MAUI app side is suspicious. I'm also getting concerned about the code becoming too complex, so I felt the need to split up the functionality.
Man, I'm tired, but I'm satisfied because I made solid progress!

Moving forward

Starting tomorrow, I want to begin by splitting up the functionality to clean up the MAUI app code.

`SynchroDeviceManager` is way too cluttered, so I plan to organize it by separating connection management, data analysis, and command transmission into different classes. For the stuttering issue, there's a possibility that property notifications or UI updates in CommunityToolkit.Mvvm are too heavy, so I'll explore ways to make them more lightweight. I'm also curious about the limits of high-frequency BLE transmission, so I'll look into ways to reduce data transmission frequency and investigate the possibilities of BLE 5.0. Also, while the coexistence of IEEE802.15.4 and BLE is stable, I want to test the motor control stability a bit more to ensure smooth movement even with multiple motors.

The tasks are piling up, but I've got momentum from today's progress, so I'm going to keep pushing forward!