Unit 5: Bluetooth with NodeMCU - Subjective Questions

Bluetooth data communication is the wireless exchange of information over short distances using radio waves in the ISM band.

A standard ESP8266-based NodeMCU does not contain built-in Bluetooth hardware. Therefore, an external Bluetooth module such as HC-05 or HC-06 is connected to its UART interface.

• Connect the Bluetooth module's TX pin to the NodeMCU's RX pin.
• Connect the module's RX pin to the NodeMCU's TX pin, using suitable voltage-level protection when required.
• Connect VCC and GND according to the module specifications.
• Initialize serial communication at the baud rate configured in the Bluetooth module.
• Data received from a paired mobile phone is read through the serial port.
• The NodeMCU processes the received command and may return sensor readings or status messages through the same interface.

Thus, the Bluetooth module acts as a wireless serial bridge between the NodeMCU and another Bluetooth-enabled device.

The HC-05 can be interfaced with the NodeMCU through UART serial communication.

Typical connections:

• HC-05 VCC to the supply voltage recommended for the breakout board.
• HC-05 GND to NodeMCU GND.
• HC-05 TXD to a NodeMCU receive pin.
• HC-05 RXD to a NodeMCU transmit pin through an appropriate level shifter or voltage divider if the module input is not tolerant.

Procedure:

1. Configure a hardware or software serial port on the NodeMCU.
2. Set the serial baud rate to match the HC-05, commonly baud in data mode.
3. Power the circuit and pair the HC-05 with a phone or computer.
4. Open a Bluetooth terminal application on the paired device.
5. Read incoming characters using the serial interface.
6. Process commands such as ON, OFF, or STATUS.
7. Send acknowledgements or sensor data back to the application.

A common ground and matching baud rates are essential for reliable communication.

The complete data flow consists of the following stages:

1. Command creation: The user enters or selects a command in a mobile Bluetooth terminal application.
2. Wireless transmission: The phone sends the command over an established Bluetooth link.
3. Bluetooth reception: The external Bluetooth module receives the radio packet and converts its payload into UART data.
4. Serial transfer: The module transmits the command to the NodeMCU through its TXD pin.
5. Input processing: The NodeMCU reads the incoming bytes, stores them in a buffer, and identifies the command delimiter such as a newline character.
6. Command validation: The firmware trims unwanted characters and checks whether the command is supported.
7. Actuator control: The NodeMCU changes an output pin to operate an LED, relay, motor driver, or another actuator.
8. Feedback: The NodeMCU may send a message such as DEVICE ON back through UART and Bluetooth.

For safety, a relay or motor should be driven through a suitable transistor, relay module, or motor driver rather than directly from a NodeMCU GPIO pin.

HC-05 and HC-06 comparison:

• Operating role: HC-05 can generally be configured as either master or slave, whereas HC-06 is normally used only as a slave.
• Configuration: HC-05 provides a more extensive AT-command set. HC-06 has fewer configuration options.
• Complexity: HC-05 is suitable for applications requiring configurable roles or module-to-module links. HC-06 is simpler for basic phone-to-controller communication.
• Pins and modes: HC-05 breakout boards commonly include a KEY or EN pin for entering AT mode. HC-06 boards generally provide a simpler interface.
• Typical use: HC-05 may initiate or accept connections depending on its configuration. HC-06 usually waits for a master device, such as a smartphone, to connect.
• UART operation: Both modules normally exchange application data with the NodeMCU through asynchronous serial communication.

The exact voltage requirements, default baud rate, firmware behavior, and pin labels should be checked from the datasheet of the specific breakout board.

Baud rate represents the number of signal symbols transmitted per second. In a simple UART link where one symbol carries one bit, it is commonly treated as the bit rate. Typical Bluetooth UART settings include or baud, depending on the module and mode.

Importance of baud-rate matching:

• The NodeMCU and Bluetooth module must use the same baud rate.
• Their data bits, parity, and stop-bit settings must also agree.
• A mismatch can produce unreadable characters, missing bytes, or complete communication failure.

Message framing:

UART frames individual bytes using a start bit, data bits, optional parity, and stop bits. The application must additionally identify complete commands. This can be achieved by:

• Ending commands with \n or \r\n.
• Using fixed-length messages.
• Sending a length field before the payload.
• Using start and end markers.

For example, the message LED_ON\n can be buffered until the newline is received and then processed as one complete command.

A voice-controlled Bluetooth device commonly uses a smartphone for speech recognition and an external Bluetooth module for communication.

Main components:

• Smartphone with a voice-control application
• HC-05 or HC-06 Bluetooth module
• ESP8266-based NodeMCU
• Relay module, motor driver, LED, or another actuator
• Suitable power supply

Operation:

1. The user speaks a command such as "turn on light" into the phone.
2. The mobile application converts speech into text using its speech-recognition service.
3. The application sends the recognized text to the Bluetooth module.
4. The Bluetooth module forwards it to the NodeMCU through UART.
5. The NodeMCU normalizes the text, for example by removing spaces or converting it to lowercase.
6. The firmware compares the received text with stored commands.
7. On finding a match, it drives the required GPIO or actuator driver.
8. The system may display or transmit a confirmation message.

Speech recognition normally occurs on the phone; the Bluetooth module only transports the resulting command.

Reliable command processing requires more than checking each received character independently.

Recommended parsing procedure:

• Read incoming UART bytes into a bounded buffer.
• Continue reading until a defined terminator, such as \n, is received.
• Reject or truncate input that exceeds the maximum allowed length.
• Remove carriage returns, leading spaces, and trailing spaces.
• Convert the text to a common case so that LIGHT ON and light on are treated consistently.
• Compare the complete command against a list of permitted commands.
• Perform the associated action only after an exact or carefully designed match.
• Return an acknowledgement such as OK: LIGHT ON or an error such as UNKNOWN COMMAND.

The firmware should also handle duplicate messages, partial commands, communication timeouts, and unsafe commands. Critical actuators should use a default safe state at startup and after connection loss.

Limitations:

• Bluetooth has a limited operating range and may be affected by walls or interference in the band.
• Speech recognition can fail because of noise, pronunciation, language, or network availability.
• Classic Bluetooth pairing alone may not provide adequate security for sensitive equipment.
• Commands may arrive partially, repeatedly, or with unexpected capitalization and spacing.
• The smartphone application or Bluetooth connection may stop unexpectedly.
• An actuator can remain in its previous state after communication is lost.

Improvements:

• Use clear command phrases and ask the phone application to confirm recognized text.
• Normalize and validate every command in the NodeMCU firmware.
• Add acknowledgements, sequence numbers, checksums, and timeouts where appropriate.
• Restrict control to authenticated devices and change default pairing credentials.
• Avoid transmitting sensitive information as unprotected plain text.
• Implement a safe state for connection loss or invalid input.
• Add physical override controls for important equipment.
• Use electrical isolation and correctly rated relay or motor-driving circuits.

These measures improve both communication reliability and operational safety.

A common I2C LCD assembly contains two main parts:

• A character LCD controller, commonly compatible with the HD44780.
• An I2C I/O expander backpack, commonly based on the PCF8574.

The LCD itself normally requires several parallel control and data lines. The I/O expander converts commands received over the two-wire I2C bus into these parallel signals.

Working principle:

1. The NodeMCU sends the slave address and display data over SDA while providing clock pulses on SCL.
2. The I/O expander acknowledges the transfer.
3. The expander changes its output pins to generate the LCD's RS, E, data, and sometimes backlight-control signals.
4. The display controller interprets bytes either as commands or character data.
5. Commands configure the display, cursor, and addressing, while data bytes produce visible characters.

The backpack reduces the number of controller pins required by the LCD interface and allows multiple addressed I2C devices to share the same bus.

Hardware connections:

• Connect LCD backpack SDA to the NodeMCU's configured I2C data pin.
• Connect LCD backpack SCL to the configured I2C clock pin.
• Connect GND to the common ground.
• Power the LCD using the voltage required by its module.
• Connect the Bluetooth module to a separate UART or software-serial pair.
• Verify voltage compatibility because some LCD backpacks are powered at and may pull SDA and SCL up to that voltage. Use a bidirectional level shifter or suitable pull-up arrangement when necessary.

Software procedure:

1. Initialize the serial interface used by the Bluetooth module.
2. Initialize I2C by specifying the SDA and SCL pins.
3. Initialize the LCD with its correct I2C address and dimensions, such as 16 columns and 2 rows.
4. Turn on the backlight and clear the display.
5. Read a complete Bluetooth command into a bounded string or character buffer.
6. Clear or overwrite the required LCD row.
7. Set the cursor position and print the command.
8. Truncate or scroll text longer than the available display width.

An I2C address scanner can be used if the LCD backpack address is unknown.

I2C devices normally use open-drain or open-collector outputs. A device can actively pull SDA or SCL low, but it does not actively drive the line high. Pull-up resistors are therefore required to return both lines to the logic-high voltage when no device is pulling them low.

The approximate rising behavior is determined by the pull-up resistance and total bus capacitance. A simplified RC time constant is:

where is the pull-up resistance and is the total bus capacitance.

• If is too large, the lines rise slowly and may not reach a valid high level before the next clock edge.
• If is too small, devices must sink excessive current when driving the line low.
• Longer wires and more devices increase and may require a lower pull-up resistance or a lower clock frequency.

Typical values are often in the kilo-ohm range, but the correct value depends on supply voltage, bus capacitance, clock speed, and device sink-current limits.

I2C, or Inter-Integrated Circuit, is a synchronous serial communication protocol that allows one or more controllers to communicate with addressed peripheral devices using two main signal lines.

• SDA: Serial Data line used to transfer addresses, data, and acknowledgement bits.
• SCL: Serial Clock line used to synchronize communication.
• START condition: Generated when SDA changes from high to low while SCL is high. It indicates the beginning of a transaction.
• Address: Usually a 7-bit value identifying the target device, followed by a read/write direction bit.
• ACK: The receiver pulls SDA low during the acknowledgement clock pulse to confirm reception.
• NACK: SDA remains high during the acknowledgement clock pulse. It may indicate failure, absence of a device, or the end of a read.
• STOP condition: Generated when SDA changes from low to high while SCL is high. It releases the bus.

During normal data transfer, SDA should remain stable while SCL is high, except when generating START, repeated START, or STOP conditions.

I2C write transaction:

1. The controller generates a START condition.
2. It sends the peripheral's address followed by a write bit, normally .
3. The addressed peripheral sends an ACK.
4. The controller sends a register address or command byte, if required.
5. The peripheral acknowledges the byte.
6. The controller sends one or more data bytes.
7. The peripheral acknowledges each accepted byte.
8. The controller generates a STOP condition.

I2C read transaction:

1. The controller may first write the required register address to the peripheral.
2. It generates a repeated START without releasing the bus.
3. It sends the peripheral address followed by a read bit, normally .
4. The peripheral acknowledges and transmits data bytes.
5. The controller sends an ACK after each byte when more data is required.
6. The controller sends a NACK after the final byte.
7. The controller generates a STOP condition.

The exact register-selection sequence depends on the peripheral's communication specification.

Each I2C peripheral is identified by an address. Most basic systems use 7-bit addressing, although the protocol also supports a 10-bit format.

In 7-bit addressing:

• The controller sends the 7-bit device address.
• The next bit specifies the direction: write or read.
• The matching peripheral responds with an acknowledgement.

I2C LCD backpacks may have different addresses because of their expander type or address-jumper settings. Common values exist, but they should not be assumed.

An I2C scanner tests the valid 7-bit address range by:

1. Generating a START condition.
2. Sending each candidate address in turn.
3. Checking whether a device returns an ACK.
4. Reporting the addresses that acknowledge.

The discovered address is then supplied to the LCD library during initialization. A scanner identifies responsive bus addresses, but it does not automatically identify the device type or guarantee that the device is functioning correctly.

SPI, or Serial Peripheral Interface, is a synchronous serial protocol commonly used for short-distance, high-speed communication between a controller and one or more peripherals.

Its principal signals are:

• SCLK: Serial clock generated by the controller to synchronize each bit transfer.
• MOSI: Controller Output, Peripheral Input; carries data from the controller to a peripheral.
• MISO: Controller Input, Peripheral Output; carries data from a peripheral to the controller.
• CS/SS: Chip Select or Slave Select; activates a specific peripheral, commonly using an active-low signal.

SPI is usually full duplex because transmission and reception can occur simultaneously on MOSI and MISO. Multiple peripherals can share SCLK, MOSI, and MISO, while each usually requires a separate chip-select line. Unlike I2C, conventional SPI has no standard address field or acknowledgement mechanism; device selection and higher-level command formats are handled by hardware connections and peripheral-specific protocols.

SPI timing is defined using clock polarity, denoted by CPOL, and clock phase, denoted by CPHA.

• CPOL = 0: The clock is idle low.
• CPOL = 1: The clock is idle high.
• CPHA = 0: Data is sampled on the first clock transition and changed on the second transition.
• CPHA = 1: Data is changed on the first transition and sampled on the second transition.

The combinations form four modes:

• Mode 0: ,
• Mode 1: ,
• Mode 2: ,
• Mode 3: ,

The controller and peripheral must use the same mode. If the mode is incorrect, data may be sampled while it is changing, producing shifted or corrupted values. The peripheral datasheet specifies the required mode, maximum clock frequency, bit order, and chip-select timing.

SPI and I2C comparison:

• Signal lines: I2C uses SDA and SCL, regardless of the basic number of peripherals. SPI normally uses SCLK, MOSI, MISO, and at least one chip-select line.
• Device selection: I2C selects peripherals using addresses. SPI usually assigns a separate chip-select signal to each peripheral.
• Data direction: I2C uses a bidirectional data line and is effectively half duplex. Standard SPI can transfer data simultaneously in both directions and is full duplex.
• Speed: SPI commonly supports higher data rates, while I2C is often preferred for moderate-speed control and sensor communication.
• Acknowledgement: I2C includes ACK and NACK bits. SPI does not define a standard acknowledgement mechanism.
• Electrical behavior: I2C uses open-drain lines with pull-up resistors. SPI usually uses actively driven logic signals.
• Hardware cost: I2C is efficient when connecting many addressed peripherals because it uses fewer controller pins. SPI requires more chip-select pins as devices are added.
• Typical uses: I2C is common for sensors, real-time clocks, and character LCD backpacks. SPI is common for displays, memory devices, ADCs, and other higher-throughput peripherals.

The choice depends on bandwidth, pin availability, distance, peripheral support, and software complexity.

Multiple devices on I2C:

• All devices share the same SDA and SCL lines.
• Each peripheral must have a unique address on that bus.
• The controller sends an address at the start of a transaction.
• Only the addressed peripheral should respond.
• An address conflict can sometimes be resolved using address pins, a bus multiplexer, or a separate I2C bus.

Multiple devices on SPI:

• Devices commonly share SCLK, MOSI, and MISO.
• Each device normally has its own chip-select line.
• The controller asserts the chip-select of the required device and leaves the others inactive.
• Inactive devices must release MISO so that they do not create bus contention.
• Alternative arrangements, such as daisy chaining, are possible only when supported by the peripherals.

I2C reduces pin usage through addressing, while SPI uses direct selection to provide simple and often faster transfers.

Common Bluetooth faults:

• Incorrect TX/RX wiring or failure to cross the lines
• Baud-rate mismatch
• Missing common ground
• Incorrect pairing credentials or module mode
• Unsafe voltage applied to a logic pin

Common I2C LCD faults:

• Incorrect I2C address
• SDA and SCL interchanged
• Missing pull-up resistors or unsuitable voltage levels
• Incorrect LCD dimensions or library configuration
• Contrast adjusted incorrectly
• Bus held low by a faulty connection or device

Common SPI faults:

• Wrong CPOL or CPHA mode
• Excessive SCLK frequency
• Incorrect chip-select polarity or timing
• Reversed MOSI and MISO connections
• Multiple devices driving MISO simultaneously

Systematic procedure:

1. Verify power rails, logic levels, common ground, and current capacity.
2. Check wiring against both the NodeMCU pin map and peripheral datasheet.
3. Test one peripheral at a time with a minimal program.
4. Confirm UART baud rate, I2C address, or SPI mode as applicable.
5. Reduce bus speed and shorten wires.
6. Print diagnostic messages through a separate debug interface.
7. Use an I2C scanner, logic analyzer, or oscilloscope to inspect signals.
8. Add devices back one at a time after each interface works independently.

System architecture:

• A smartphone performs speech recognition and sends the recognized command over Bluetooth.
• An HC-05 or HC-06 module converts the Bluetooth data into UART data.
• The NodeMCU receives, validates, and executes the command.
• A transistor-driven relay module controls the appliance.
• A 16x2 I2C LCD displays the command and appliance status.
• A regulated supply powers the modules, with voltage-level conversion and isolation where required.

Algorithm:

1. Configure the relay output in a safe inactive state.
2. Initialize the Bluetooth serial interface.
3. Initialize the I2C bus and LCD.
4. Display a startup message and current appliance state.
5. Wait for a complete newline-terminated Bluetooth command.
6. Normalize the command by trimming whitespace and converting it to a common case.
7. If the command is turn on appliance, activate the relay.
8. If the command is turn off appliance, deactivate the relay.
9. For an unknown command, preserve the current state and report an error.
10. Update the LCD and return an acknowledgement through Bluetooth.
11. Apply a timeout or fail-safe rule if communication is lost.

Design considerations:

• The appliance must never be connected directly to a GPIO pin.
• The relay and wiring must be rated for the controlled load.
• Mains-voltage construction requires proper enclosure, isolation, fusing, and qualified handling.
• UART input should use bounded buffers, while I2C lines must use compatible pull-up voltage levels.