In this log I will be documenting my BLE research. On 4/8 I spent time researching BLE implementation in MicroPython for the ESP32. Through this research I was able to verify proper BLE implementation and communiccate with the ESP32 through an app!

One issue that I ran into was insufficient documentation for implementing BLE with MicroPython on the ESP32. I was able to find some examples that worked properly, but they were hard to find. It seems to me that not BLE with MicroPython on the ESP32 is not entirely common, so it requires building the BLE event handlers from scratch. Zerynth seems to have more support and well-documented examples, so I am currently exploring that route.

BLE background

Information about the basics of BLE can be found here. I found this link very helpful as I have never used BLE before. Here are the main points from BLE from that link:

"The different roles of a BLE device are:

• Broadcaster: a device that sends out Advertisements and does not receive packets or allow Connections from others.
  
• Observer: a device that listens to others sending out Advertising Packets, but does not initiate a Connection with the Advertising device.
  
• Central: a device that discovers and listens to other devices that are Advertising. A Central also has the capability of connecting to an Advertising device.
• Peripheral: a device that Advertises and accepts Connections from Central devices.
• Peripheral: a device that Advertises and accepts Connections from Central devices."

One device will be a central device, and another device will be a peripheral. The PC will be the central device so that it can discover (listens to Advertising devices) the ESP32 and send data to it. The ESP32 will be a peripheral device so that it can be discoverable (it Advertises) and receive commands from the central device.

The section labelled "Connections" is very useful and describes exactly how the two devices connect:

"Connections
In order for two BLE devices to connect to each other, the following needs to happen:

• The Peripheral needs to start Advertising and send out Connectable Advertisement packets.
• The Central device needs to be Scanning for Advertisements while the Peripheral is Advertising.
• If the Central happens to be listening on an Advertising Channel that the Peripheral is Advertising on, then the Central device discovers the Peripheral and is able to read the Advertisement packet and all the necessary information in order to establish a Connection
• The Central then sends a Connection Request packet.
• The Central then sends a Connection Request packet
  

The peripheral always listens for a short interval on the same Advertising Channel after it sends out the Advertising packet. This allows it to receive the Connection Request packet from the Central device — which triggers the forming of the Connection between the two devices.
After that, the Connection is considered “created ”, but not yet “established ”. A Connection is considered “established ” once the device receives a packet from its peer device. After a Connection becomes established, the Central becomes known as the Master, and the Peripheral becomes known as the Slave. The Master is responsible for managing the Connection, controlling the Connection Parameters and the timing of the different events within a Connection"

That's a lot of information! After reading it a few times, it started to make sense to me.

BLE test example

On the Micropython GitHub repository, there are BLE examples that can be used. I tested the example found here. In this example, the script generates a random temperature and publishes a random temperature value every 1 second.

To be able to view the values being broadcasted, downloaded a BLE scanning app. The app that I have been using is called nRF Connect, available for both iOS and Android devices. nRF Connect allows you to scan for available Bluetooth devices, connect to them, and see certain services that are being broadcasted.

Below you can see my app connecting to the test script running on my ESP32 that is publishing a temperature value.

The test is broadcasting a service labelled "Environmental Sensing." That service can be expanded, and there is a field identified with the UUID (universally unique identifier) 0x2A6E, labelled "Temperature." This "Temperature" field has the properties of "READ," meaning read-only, and "NOTIFY," meaning to notify the connected device. It then has a "Value" field, which is where the ESP32 is updating the randomly generated temperature. The current temperature value stored there is 18.99C.

The nRF Connect app is very useful because it contains so much information about the connected device and the various program-specific services that are running on that device.

Below is a screenshot of the program running on the ESP32.

At the red arrow, you can see where the ESP32 connects to the nRF Connect app. The subsequent events printed are the notify events sent to the nRF Connect app. So the test program is working properly and sending values to the app!

My next steps with BLE are going to be sending values to the ESP32 from the nRF Connect app and exploring implementing BLE within Zerynth, since there is more documentation for Zerynth.