Interface and Application Programming

Introduction

For this week's assignment, I created multiple user interfaces that allow interaction with my Hydration Monitor Robot system. The interfaces bridge the gap between humans and embedded hardware, enabling users to:

• Monitor real-time water consumption data via smartphone
• Control and test the system remotely through BLE commands
• Receive visual feedback through an expressive robot face display

Three Interface Layers

My system provides three distinct ways for users to interact with the hardware:

Interface System Overview

User-Centered Design Philosophy

I designed the interfaces with different user personas in mind:

User Type	Interface	Primary Use Case
Daily User	Robot Display	Quick glance at hydration status without picking up phone
Power User	Phone App	Detailed data monitoring, testing, and remote control
Developer	Serial Terminal	Calibration, debugging, firmware updates

Data Flow Through Interfaces

┌─────────────────┐
│  Load Cell      │ ← Input Device (Week 8)
│  Water Bottle   │
└────────┬────────┘
         │ Weight Data
         ↓
┌─────────────────┐
│  ESP32 Server   │ ← Processes & Broadcasts
│  (BLE)          │
└────┬────────┬───┘
     │        │
     │        └──────────────────┐
     ↓                           ↓
┌─────────────────┐    ┌─────────────────┐
│  Phone App      │    │  Robot Display  │ ← Output Device (Week 9)
│  (nRF Connect)  │    │  (TFT Screen)   │
└─────────────────┘    └─────────────────┘
     ↓                           ↓
┌─────────────────┐    ┌─────────────────┐
│  Human reads    │    │  Human sees     │
│  numbers/charts │    │  emotions 😊😐😢 │
└─────────────────┘    └─────────────────┘
     ↑
     │ Control Commands
     │ (Test Mode, etc.)
     │
┌─────────────────┐
│  User Input     │ ← Application Programming (Week 13)
└─────────────────┘

Phone Application Interface

Using Generic BLE Apps

Rather than developing a custom smartphone app from scratch (which would require iOS/Android development), I leveraged existing professional BLE debugging tools that provide a powerful interface to my hardware:

Connecting to the Device

Step-by-step guide to connect your phone to the Water Bottle Scale:

1. Open nRF Connect (Android) or LightBlue (iOS)
2. Tap "SCAN" to search for nearby BLE devices
3. Look for device named "WaterBottle" in the list
4. Tap "CONNECT" next to the device name
5. Once connected, you'll see the service UUID: 4fafc201-1fb5-459e...
6. Tap to expand and view all four characteristics

Phone showing active BLE connection to WaterBottle device

Reading Data Characteristics

The app interface displays four BLE characteristics. To view real-time data:

Data Visualization

The apps automatically convert hex data to human-readable formats:

BLE Protocol Design

Why Bluetooth Low Energy?

I chose BLE as the communication protocol for several reasons:

• Universal compatibility: Every modern smartphone has BLE built-in
• No pairing required: Users can connect instantly without entering codes
• Low power consumption: Critical for battery-operated devices
• Real-time notifications: Push data to connected clients automatically
• Multiple connections: Phone AND robot display can connect simultaneously
• Industry standard: Well-documented with robust libraries

Service & Characteristics Architecture

BLE uses a hierarchical structure of Services and Characteristics. I designed my protocol to be intuitive and extensible:

📡 BLE Device: "WaterBottle"
│
└── 📦 Service: Hydration Monitor
    UUID: 4fafc201-1fb5-459e-8fcc-c5c9c331914b
    │
    ├── 📊 Characteristic: Current Weight
    │   UUID: beb5483e-36e1-4688-b7f5-ea07361b26a8
    │   Properties: READ, NOTIFY
    │   Data: String (grams)
    │
    ├── 💧 Characteristic: Water Consumed
    │   UUID: beb5483e-36e1-4688-b7f5-ea07361b26a9
    │   Properties: READ, NOTIFY
    │   Data: String (grams)
    │
    ├── 📈 Characteristic: Percentage Remaining
    │   UUID: beb5483e-36e1-4688-b7f5-ea07361b26aa
    │   Properties: READ, NOTIFY
    │   Data: String (0-100)
    │
    └── 🎛️ Characteristic: Control Commands
        UUID: beb5483e-36e1-4688-b7f5-ea07361b26ab
        Properties: READ, WRITE, NOTIFY
        Data: String (single char commands)

Notification vs Polling

BLE supports two ways to get data from devices:

Method	How It Works	Best For
Polling (READ)	App requests data on demand	One-time checks, debugging
Notifications (NOTIFY)	Device pushes updates automatically	Real-time monitoring, live data

My system uses notifications by default, pushing updates every 1 second to all subscribed clients. This is more efficient than having the phone constantly poll for new data.

Firmware Implementation

Here's how the BLE server broadcasts data in the ESP32 firmware:

// Called every 1 second in main loop
void updateBLE() {
  // Format current weight as string
  String currentStr = String(currentWeight, 1);
  pCharCurrent->setValue(currentStr.c_str());
  pCharCurrent->notify();  // Push to all subscribers
  
  // Format water consumed
  String consumedStr = String(waterConsumed, 1);
  pCharConsumed->setValue(consumedStr.c_str());
  pCharConsumed->notify();
  
  // Format percentage (integer)
  String percentStr = String(percentRemaining);
  pCharPercent->setValue(percentStr.c_str());
  pCharPercent->notify();
}

For complete BLE server and client implementation details, see the BLE Communication section of my Final Project page.

Remote Control Interface

Writing Commands from Phone

The Control characteristic (...26ab) enables bidirectional communication. Users can send commands to the device wirelessly:

Available Commands

How to Send Commands

1. Navigate to the Control characteristic (...26ab)
2. Tap the "↑" up arrow (write button)
3. Select "Text/UTF-8" format (not Hex!)
4. Type a single character command (e.g., x)
5. Tap "Send"
6. If subscribed to notifications, you'll see the response immediately

Command Processing Flow

User types 'x' in phone app
    ↓
Phone sends character via BLE WRITE
    ↓
ESP32 receives in onWrite() callback
    ↓
handleCommand('x') function executes
    ↓
Test mode toggles ON
    ↓
Response "Test mode ON" sent back via NOTIFY
    ↓
Phone app displays confirmation
    ↓
User sees feedback instantly

Firmware Command Handler

void handleCommand(char cmd) {
  Serial.print("BLE Command: ");
  Serial.println(cmd);
  
  switch(cmd) {
    case 'x':
    case 'X':
      if (!testMode) {
        enterTestMode();
      } else {
        testMode = false;
        sendControlResponse("Test mode OFF");
      }
      break;
      
    case '0':
      if (testMode) {
        testState = 0;  // 100% full
        sendControlResponse("Full: 100%");
      }
      break;
      
    // ... more cases ...
  }
}

Testing Demo with Phone

Robot Display Interface

Visual Interface Design

While the phone app provides precise numerical data, the robot face offers something more valuable: emotional communication. This interface translates technical measurements into human-understandable emotions.

Interface States

The robot face implements a finite state machine with discrete emotional states:

Emotion Mapping

Water Level	Emotion	Visual Design	User Message
60-100%	😊 Happy	Squinted eyes, >U< smile	"You're doing great!"
30-59%	😐 Neutral	Round eyes, straight mouth	"Drink some water soon"
0-29%	😢 Sad	Small eyes, frown, tear	"REFILL NEEDED!"

Robot Face Animation Demo

Animation as Interface Feedback

The blinking animation serves multiple interface purposes:

• Liveness indicator: Shows system is powered and responsive
• Personality: Makes the robot feel like a companion, not a machine
• Attention draw: Periodic movement catches user's eye
• Natural interaction: Mimics human blinking for relatability

Interface Responsiveness

The display updates with minimal latency to maintain the illusion of a reactive companion:

• BLE notification → Emotion update: <200ms
• Face state change: Immediate (single frame redraw)
• Blink animation: 150ms duration
• Smooth animation: 60 FPS refresh rate

For complete technical details on the TFT display programming, see Week 9: Output Devices or the Robot Face section of my Final Project.

Interface Testing & Demonstration

Multi-Interface Integration Test

The ultimate test of interface design: using all three interfaces simultaneously to demonstrate seamless communication:

1. Setup: Connect phone app to "WaterBottle" device
2. Setup: Power on robot display (auto-connects to scale)
3. Test 1: Enable notifications on all characteristics in phone app
4. Test 2: Write command 'x' to enter test mode
5. Observe: Control characteristic notifies "Test mode ON"
6. Test 3: Write command '0' (100% full)
7. Observe:
   • Phone shows: Percentage = "100"
   • Robot shows: Happy face 😊
8. Test 4: Write command '1' (50% full)
9. Observe:
   • Phone shows: Percentage = "50"
   • Robot shows: Neutral face 😐
10. Test 5: Write command '2' (25% full)
11. Observe:
    • Phone shows: Percentage = "25"
    • Robot shows: Sad face 😢
12. Test 6: Write command 'a' for auto-cycle
13. Observe: System automatically cycles through all states every 5 seconds

Usability Findings

Through self-testing and informal observation, I identified several usability insights:

Reflection & Learnings

Interface Design Principles Applied

This project reinforced several key principles of interface design:

Technical Learnings

• BLE is powerful but complex: Managing connection states, notifications, and callbacks requires careful state machine design
• Notifications > Polling: Push-based updates are more efficient and feel more responsive than constant polling
• String encoding matters: UTF-8 is more user-friendly than hex for human-readable data
• Multiple clients work: BLE supports simultaneous connections, enabling phone + robot display at once
• Testing is interface design: The test mode I built for debugging became a core feature for demonstrating the interface

Future Interface Enhancements

Given more time, I would improve the interfaces in these ways:

Closing Thoughts

This assignment reinforced that interface design is not decoration - it's the bridge between human intent and machine capability. The same hardware can be frustrating or delightful depending entirely on how users interact with it.

My favorite realization: the robot face, which I initially thought was just "cute decoration," is actually the most effective interface. It requires zero learning, zero cognitive load, and creates an emotional bond that motivates behavior change. That's the power of thoughtful interface design.

Related Documentation

This week's interface work is closely integrated with other assignments:

Download Source Code