Bluetooth-LE-Audio-Auracast-Transmitter/docs

Auracast-like Workmanship Documentation using ESP32-S3

1. Preparation of the ESP-IDF/Arduino toolchain, creation of the repository structure, and initial configuration of the simulation.

In this 1st stage, the engineer started to create a repo for the project on github, initially the engineer wanted to use the development kit NXH3675, but due to the minimal deadline and project limitations, esp32-s3 was chosen which is easy to get for this ble simulation. ESP32s3 is considered sufficient for the simulation of the connectivity control of the ble structure. For device simulation, there are several options such as NRF Connect and BLE simulator on smartphone devices, NRF Connect was chosen because of its fairly complete features and is more stable than BLE-Simulator.

Results :

The ESP32-S3 was chosen because of its ease of access compared to waiting for the arrival of NXH3675 as a transmitter/server device. The smartphone is installed with nrf Connect as a client that will receive data from the ESP32-S3/Server/Transmitter.

--

2. Implementation of the basic structure of BLE advertising and Auracast (mock) flows.

At this stage, the engineer looks for several references about BLE, starting from the type of device role such as advertiser (server) and central (client), then there are options such as connectable and scannable, to studying BLE data frames. Due to the use of esp32-s3, the engineer also took a reference from the official espressif website, there is an overview of BLE in ESP32, it is also explained on the website about the host ble in esp332-s3 in the form of ESP-nimBLE and ESP-Bluedroid.

Results:

The ESP32-S3 simulation was successfully carried out, here the ESP32-S3 acted as a server that later sent data to the connected device (notify), in this experiment the smartphone was selected as the client (central) using the nrf Connect application, the data sent by ESP2-S3 was successfully read by the smartphone device

--

3. Implementation of LC3 (mock encoder) audio packet representation.

At this stage, there is an obstacle, namely the inability of ESP32-S3 to encode audio data into lc3 codec, therefore the engineer is looking for a solution by using python on the host device (laptop) and then sending it to esp32 via usb serial, but it needs to be underlined that this lc3 is a dummy and not actually lc3 encode, neither esp nor python have the support to do this

4. Simulate 3–5 virtual receiver devices for broadcast testing.

At this stage, the engineer creates a new program where the esp32-s3 becomes able to connect to more than one device by adding an advertiser program after the esp connects with other devices

Results:

ESP32 Successfully connected by 2 different devices

--

5. Simulate the join/leave receiver process and data synchronization.

Here after successfully connecting the device more than a few times, the engineer added a new control program in the form of disconnect, disconnect itself parameter used is connID, so when the initial device is connected it will get a connID and then stored in the json data of the connected device, then when the disconnect command is executed, it will break the connectivity between the server and the device

Results:

The engineer succeeded in creating a program where by entering the command it could disconnect the device connected to the server from the server side

--

6. Implementation of audio buffering logic for simulated repetitive broadcasts.

Just like with stage encode lc3, here the results of the dummy lc3 encode are sent in serial to esp32-s3 for further in the broad cast with the connected pernate

--

7. Data flow testing, log serial analysis, and error correction

Here engineers design connectivity between hardware. From the Host side to the transmitter will use USB-TTL to send commands from the host or send data from the Transmitter to the Host

--

8. Review and preparation of firmware for the integration stage.

--

9. Creation of a basic dashboard view (HTML/CSS/JS).

For the backend that will be connected to the serial port, the engineer decided to use Node Js for ease of access and documentation that is quite helpful during the creation process

Results:

The engineer managed to create a simple display so that later this website can display device connectivity data.

--

10. Determination of JSON data formats and communication endpoints.

The engineer examines all the needs required by the website to be able to control and display a list of connected devices. The result: The engineer decided on some data that would be used as one to be sent from ESP32-S3 to the Host.Among others: • Mac Address • Device Name • RSSI • TXPOWER • connectedID • connectedInterval • Latency • Timeout • Status • ConnectedClient {"connectedClients":2,"Devices":[{"connectedID":1,"connInterval":36,"latency":0,"timeout":500,"mac":"Unknown","name":"Unknown"},{"connectedID":2,"connInterval":24,"latency":0,"timeout":72,"mac":"Unknown","name":"Unknown"}],"Status":"NEW_CONNECT"}

--

11. Real-time communication integration via Serial/HTTP/WebSocket.

Here the engineer creates a program in Node Js to read the data sent by the ESP32-S3 using the Serial Port Results: The engineer managed to create a program where the JS Node could read the data sent by the ESP32-S3

--

12. Added the number of connections, activity logs, and signal graphs displays.

The engineer adds indicators such as the number of connected devices whose data is taken from JSON connectedClients, then the mac address is also stored as an activity log where there will be a timestamp of how long the device is connected and also a graph of the signal that will be taken from the RSSI

--

13. Final testing and refinement of the website's appearance

In this Stage, there are not many changes, it's just that the engineer fixed minor bugs on the website such as the number of connected Clients that do not match the actual number and such as the addition of a Dropdown to choose which ports have connectivity with ESP32-S3

--

14. Definition of the firmware's structure, data flow, and MCU hierarchy.

After several stages that have been running, the data flow can be explained as follows:

1. Transmitter/Server/ESP32-S3 turns on and does advertiser
2. The Central/Client device will scan the server
3. Device Connect with Server
4. When the Rank is connected, the Transmitter/Server/ESP32-S3 will issue json data for the identity of the device.
5. JSON data will be sent by the Transmitter/Server/ESP32-S3 to the Host to be displayed on the Website
6. The Js node receives the serial data and sends it to the HTML page with Websocket
7. HTML Page receives data from the js node through the websocket and displays it in the page view.
8. When the Disconnect Button is pressed, the HTML page will send a command to Node Js through the Websocket which will then be forwarded to the Transmitter/Server/ESP32-S3 serially.
9. When the Transmitter/Server/ESP32-S3 receives the disconnect command, it will run a program to disconnect the client according to the specified id.

--

15. Definition of communication paths between the user's web firmware.

Here the Engineer uses Websocket as an intermediary between the backend (Node Js) and the Frontend.

PROBLEM LIMITATIONS

1. When using Auracast, the server cannot manage connectivity because the deviceconnect only reads adv data.

2.ESP32 can't run Auracast,

3.ESP32 Can't do Encode LC3

4. When it becomes a server, the transmitter cannot read rssi data, device name and TxPower.

Conclusion

So far, engineers can conduct research on connectivity management using ESP32-S3, such management as managing the number of device connectivity and doing log history with the Website, besides that ESP32-S3 can also send dummy data to connected devices. But for the audio transmitting itself, it has not worked because of the ESP32-S3's less promising capabilities.