ESP32-C3 (BLE)

[G8PTN]

Hi,
For general information, I recently built a simple remote interface for the Quansheng UV-K5 that uses an ESP32-C3 and does not rely on a PC connection.

A couple of interesting points were noted on the ESP32-C3 behaviour (see below).

It may be necessary to review the BLE interface on the ESP32-S3 when used for the ATS-Mini remote features.
73, Dave

Observation 1
If the USB Serial port is used for debug or functional output, when connected to a computer without the PC serial port being opened, the CDC port in the ESP32-C3 can become blocking. This is related to the ESP32-C3 outgoing buffer filling and the time taken for it to detect this and force it to be flushed, which can cause a problem if lots of data is being sent to the serial port. With the USB port disconnected, there were no issues.

This may be specific to the ESP32-C3 and is probably resolved in the latest ESP32 board library. To avoid any issues, all Serial.print statements are disabled by default and can only be enabled remotely via the serial port.

Observation 2
Using the MIT App Inventor (MIT AI2) tool for the remote application, the BLE MTU size appears to default to 20 bytes. For the UV-K5 remote use case, this is not a problem because the screen information has been arranged into a frame consisting of eight lines of 20 bytes. A frame is sent every second, with 100ms between lines.

Although BLE was intended for short and relatively infrequent data bursts, for applications requiring bigger frame sizes and higher throughput, the BLE parameters for MTU and Connection Interval need to be optimised.

My understanding is that the MTU size can range from 1 to 512 bytes, and the Connection Interval is 7.5ms minimum, 4000ms maximum in steps of 1.25ms.

UV-K5 Remote
A brief summary of the Quansheng UV-K5 remote interface is provided below.

The UV-K5 is using the nicsure fork of the egzumer firmware (0.31.21q) by Marcus which provides all of the necessary functions to allow key and screen emulation.

The interface uses an ESP32-C3 module to provide the BLE control interface and a KCX BT sender module for the receive audio link.

A simplified block diagram is shown below.

The ESP32-C3 parses the UI screen information from the UV-K5 and generates an output frame consisting of seven text only lines and a control line with various status data and flags. This information is sent periodically over the BLE data interface.

In the reverse direction the ESP32-C3 accepts control codes emulating key presses from the BLE interface (or USB-C debug serial), and sends the appropriate control messages to the UV-K5.

The MIT App Inventor tool was used to generate a basic Android App, which provides some minor customisation of the UI, including the S-Meter, scan group indicators and the status bar.

The interface does not provide all of the features of “Quansheng Dock” and is only intended to be used for receiving purposes, providing wireless (BLE) remote control of the UV-K5.

Transmit is possible, but there is no audio link, and as previously pointed out by Marcus (Quansheng Dock developer), the circuitry is prone to RF issues, particularly if the UV-K5 is used with a whip antenna.

[max-arnold]

Hi Dave, that is an interesting project! And thanks for sharing your observations..

A couple of questions if you don't mind:

• What kind of BLE stack do you use on ESP32-C3? I was using NimBLE because it has reduced memory footprint, but since ESP32 Arduino Core 3.3.0 it includes a subset of it, so I'm currently in the process of migrating to the built-in stack and dropping the NimBLE dependency
• Does the MIT AI2 support Nordic UART protocol, or it can be configured to talk using arbitrary charasteristics and service uuid?
• Did you try to measure the BLE power consumption? I do not remember the numbers, but it was surprisingly power hungry

[G8PTN]

Hi Max,
Brief response to your questions below.

• What kind of BLE stack do you use on ESP32-C3? I was using NimBLE because it has reduced memory footprint, but since ESP32 Arduino Core 3.3.0 it includes a subset of it, so I'm currently in the process of migrating to the built-in stack and dropping the NimBLE dependency

On the BLE for the ESP32-C3, I just used the BLE_uart example in the Arduino IDE. I think it uses the bluedroid stack.

• Does the MIT AI2 support Nordic UART protocol, or it can be configured to talk using arbitrary charasteristics and service uuid?

In MIT AI2, I use the BLE extension. Apart from the observations with MTU and Connection Interval, this seems to work fine with the ESP32-C3. It works with arbitrary characteristics and service uuid, but I believe it can work with the Nordic UART service.
The MIT AI2 environment is quite basic, but it is a quick and easy way to create a simple App.

• Did you try to measure the BLE power consumption? I do not remember the numbers, but it was surprisingly power hungry

Yes, the power consumption in BLE is high and does not reduce by very much at lower RF power settings. The power consumption is similar to that for WIFI. In my opinion the ESP32 is not ideal for low power wireless applications.

I have used the cheap Bluetooth (SPP) JDY-31 modules in the past, and they have an average current consumption of less than 10mA.

Kind Regards,
Dave