Individual Contributions

👩‍💻 Micaela Córdova — GUI Tool Comparison

GUI Analysis

Micaela's focus: Comprehensive comparison of two major graphical user interface development platforms for embedded systems. She evaluated MIT App Inventor (visual block-based programming for mobile) and Python + Tkinter (text-based programming for desktop GUI development). Her research included hands-on experimentation building sample applications, documenting workflow differences, analyzing learning curves, and comparing serial communication capabilities for hardware integration.

👨‍💻 André Mamani — WebSocket Communication & Real-Time Visualization

Wireless Communication

André's focus: Exploration of wireless communication technologies for embedded systems and real-time data visualization. He investigated WebSocket communication with JavaScript browser-based interfaces, Python serial monitoring for debugging, and wireless Wi-Fi connectivity using the ESP32-C3 platform. His research covered advantages and disadvantages of each communication method, implementation complexity, and appropriate use cases for different project requirements.

Section 1: GUI Tool Comparison

MIT App Inventor vs Python + Tkinter

🎨 Overview: Two Different Approaches

Micaela compared two fundamental approaches to GUI development: visual block-based programming (MIT App Inventor) and text-based scripting (Python + Tkinter). Each platform serves different purposes and skill levels.

📱 MIT App Inventor — Visual Block-Based Programming

MIT App Inventor is a visual, block-based programming environment specifically designed for creating Android mobile applications. Its logic mirrors Scratch, making it intuitive for those familiar with puzzle-piece programming.

✓ Advantages
  • Drag-and-drop design — zero code writing
  • Ideal for rapid mobile visualization
  • Built-in blocks for Bluetooth, GPS, sensors
  • QR code testing on real devices instantly
✗ Disadvantages
  • Limited to predefined components
  • Android platform only
  • Limited AI integration capabilities
  • Complex USB serial workflows difficult

First Experience: "Hello Codi!" App

Following a tutorial, Micaela created a simple app where touching a bee triggers a sound effect. This demonstrated App Inventor's object-oriented approach and event-driven programming model.

MIT App Inventor interface Hello Codi Bee app design Bee app preview
Object-Oriented Logic

Every element (Button, Sound, Label) is an independent object with customizable properties — similar to modern UI frameworks.

Event-Driven Programming

Logic managed through action blocks like when Button1.Click — without writing manual code.

🖥️ Python + Tkinter — Text-Based GUI Development

Python is a high-level language and Tkinter is its standard library for creating desktop graphical user interfaces. This combination provides total control over logic, appearance, and advanced library integration.

✓ Advantages
  • Total control over logic and appearance
  • AI-friendly — code generation with Gemini/ChatGPT
  • Cross-platform: Windows, macOS, Linux
  • Robust USB Serial integration via pySerial
✗ Disadvantages
  • Requires programming syntax knowledge
  • Layout coding slower than drag-and-drop
  • Desktop-only (no mobile support)

Development Workflow

Spyder IDE showing the complete development environment: Python code editor, Tkinter GUI interface, and console output for debugging

Spyder editor interface Spyder with GUI popup Spyder full view
Spyder with GUI in background Spyder with console
01
Import Libraries & Dependencies

Start with import statements for tkinter, pySerial, and other required modules.

02
Design Window Layout

Use grid() or pack() geometry managers to define window structure and component placement.

03
Implement Logic Functions

Write callback functions for serial communication, data processing, UI updates.

04
Execute & Test

Run the Python script — window opens instantly with full functionality.

📊 Side-by-Side Comparison
Feature MIT App Inventor Python (Tkinter)
Logic StyleBlock-based (like Scratch)Text-based scripting
Primary TargetMobile users (Android)Desktop users (Win/Mac/Linux)
Hardware LinkBluetooth / Wi-FiUSB Serial (COM ports)
AI IntegrationLimited (manual block mapping)High (copy/paste code logic)
Learning CurveVery low — drag and dropMedium — syntax knowledge required
CustomizationLimited to built-in componentsUnlimited control
Best ForQuick mobile prototypingRobust desktop + serial projects
Verdict: MIT App Inventor excels for rapid mobile prototyping without programming knowledge. Python + Tkinter provides flexibility and superior hardware integration, making it ideal for desktop-based embedded systems projects.

Section 2: Communication Technologies

WebSocket, Python Serial, and Wireless Monitoring

🔗 Communication Methods for ESP32-C3

André investigated four distinct communication approaches for the Seeeduino ESP32-C3 platform, evaluating their strengths for real-time data transmission and visualization.

MIT App Inventor

Mobile GUI with Bluetooth/Wi-Fi wireless communication for sensor visualization on Android.

Python + Tkinter

Desktop GUI with USB Serial communication for hardware control and real-time monitoring.

Python Serial Monitor

Terminal-based real-time data monitoring and debugging for rapid hardware testing.

WebSocket + JavaScript

Browser-based real-time visualization with wireless Wi-Fi and animated graphics.

WebSocket Communication — Advantages & Disadvantages

✓ Advantages
  • Real-time bidirectional communication without page refreshes
  • Wireless monitoring via Wi-Fi from any device
  • Dynamic visualization with JavaScript animations
  • Modern UI frameworks (Shadcn UI, web components)
  • Multiple client support simultaneously
✗ Disadvantages
  • Wi-Fi dependency — requires stable 2.4 GHz connection
  • Complex debugging — IP addresses, ports, credentials, browser issues
  • Library conflicts — ESP32 compatibility issues with servo control
  • Implementation complexity — multiple configuration layers
  • Browser requirement — visualization needs compatible environment

Python Serial Monitoring — Simple but Effective

✓ Advantages
  • Simple implementation — minimal configuration
  • Efficient debugging — rapid issue identification
  • Fast data monitoring — direct COM port reading
  • Extensive documentation — large Python community
  • Future-ready — flexible for data analysis and logging
✗ Disadvantages
  • Wired communication — USB connection required
  • Limited visualization — basic terminal output
  • Single connection — not scalable
  • Less accessible — requires development environment
  • Constant monitoring — console must stay open
Key Learning: Python serial communication is ideal for development and debugging, while WebSocket enables advanced wireless visualization for production systems. Choose based on project phase: serial monitoring during development, WebSocket for deployed systems.

Section 3: Complete Technology Evaluation

Comprehensive Comparison Matrix

📊 All Technologies Compared
Aspect MIT App Inventor Python + Tkinter Python Serial WebSocket + JS
Interface TypeMobile appDesktop GUITerminalBrowser-based
CommunicationBluetooth / Wi-FiUSB SerialUSB SerialWebSocket over Wi-Fi
Real-Time PerformanceModerateFast localFastHigh-speed bidirectional
Learning CurveVery easyIntermediateEasyMedium / High
Wireless CapableYesNoNoYes
Best ForMobile prototypingDesktop hardware controlDebuggingAdvanced visualization

🎯 Technology Recommendations

For Mobile Projects

Use MIT App Inventor for rapid prototyping with integrated wireless support. Perfect for student projects and quick Android proof-of-concepts.

For Desktop + Hardware

Choose Python + Tkinter for robust serial communication and complete control over logic. Ideal for USB-connected embedded systems.

For Development & Debugging

Employ Python serial monitoring as a debugging tool during hardware development before implementing complex visualization.

For Wireless Visualization

Implement WebSocket + JavaScript for advanced real-time monitoring over Wi-Fi with modern, interactive web interfaces.

Final Conclusion: No single tool is universally superior. The best choice depends on target platform (mobile vs. desktop vs. browser), communication type (wireless vs. wired), developer expertise, and visualization complexity. For hardware-intensive projects like HigiBox, combining multiple technologies during different development stages often yields the best results.

Section 4: Individual Experience & Learnings

What We Learned This Week

👩‍💻 Micaela Córdova — GUI Development & Serial Communication
Individual Assignment

What I Built

I created a complete Python + Tkinter GUI application that communicates with my XIAO ESP32-C3 microcontroller over USB serial connection. The interface allows a user to control an LED: pressing a button sends an 'H' command (LED ON) or 'L' command (LED OFF) to the board, with real-time status feedback.

Key Learnings

1. GUI Tools Have Different Philosophies

MIT App Inventor says "no coding needed." Python+Tkinter says "you need control." WebSocket says "let's go wireless." Each philosophy enables different outcomes.

2. Serial Communication is a Contract

Both Arduino and Python must agree on: baud rate (9600), message format ('H'/'L'), and interpretation. One mismatch breaks everything silently.

3. Test Hardware Before GUI

I used Arduino's Serial Monitor first. Only when hardware was confirmed working did I build the Python interface. This separation saved debugging time.

4. Python + Tkinter Won for My Use Case

Desktop control + wired connection + existing Python knowledge = best fit. But this choice came after analyzing alternatives, not by default.

Why Python + Tkinter vs Alternatives

Tool Would It Work? Why I Didn't Choose It
MIT App Inventor Yes, via Bluetooth Mobile only, not ideal for lab setting. Board needs to be tethered.
WebSocket + JavaScript Yes, wireless Overkill for simple LED control. Too many failure points (Wi-Fi, browser).
Arduino Serial Plotter For output only Can't send commands, only visualize data. Not interactive enough.
Python + Tkinter ✓ Perfect fit All-in-one: serial communication + GUI + buttons + status feedback.

Hardware & PCB Design

XIAO ESP32-C3 microcontroller boards with annotated pins, digital/analog connectors, and button integration

Annotated XIAO ESP32-C3 with labeled pins Alternative PCB configuration KiCad PCB design
  • Arduino IDE — Program XIAO ESP32-C3 in C++
  • Spyder IDE — Write Python GUI application
  • pySerial library — Handle USB serial communication
  • Tkinter — Build graphical interface with buttons, labels, port selector
  • Arduino Serial Monitor — Debug hardware before touching GUI code

Lessons for Next Time

1
Always Start with Hardware Testing

Don't even think about the GUI. Use Serial Monitor to confirm the board works independently.

2
Document Your Serial Protocol Upfront

Write down exactly what messages flow in each direction. This becomes your debugging checklist.

3
Separation of Concerns is Powerful

Test hardware → communication → GUI independently. Each layer should work before the next is attempted.

Individual Experience: André Mamani

Wireless Real-Time Radar System

👨‍💻 André Mamani — WebSocket Communication & Real-Time Visualization
Individual Assignment

What I Built

I designed a complete wireless radar system: ESP32-C3 with HC-SR04 ultrasonic sensor + servo motor hardware that scans 0°-180° and broadcasts distance readings in real-time over WebSocket to a React web application. The browser displays a live animated radar showing detected objects at their angle and distance.

André's Radar Application - WebSocket visualization

Real-time radar display showing object detection and surface reconstruction with green trace pattern

Key Learnings

1. Wireless is Beautiful But Complex

Real-time data over Wi-Fi is magical. But one wrong IP address, one dropped connection, one malformed JSON packet and the whole system breaks silently.

2. WebSocket Demands Respect

Every advantage (real-time, wireless, browser-based) came with hidden complexity. I underestimated the debugging burden.

3. You Need Multiple Debugging Layers

When WebSocket failed, I had no visibility. I should have kept Arduino's serial monitor as a fallback for hardware verification.

4. Systems Thinking Beats Single Tools

This wasn't "just WebSocket." It was hardware (sensors) + firmware (scanning) + communication (protocol) + visualization (Canvas). Each must work together.

Why WebSocket vs Alternatives

Tool Would It Work? Why I Chose WebSocket Instead
Python Serial Yes, with USB cable Wired only. A radar should move around — wireless is essential.
MIT App Inventor Yes, via Bluetooth Building animated graphics in blocks would be painful. JavaScript + Canvas is more natural.
Python + Tkinter Yes, but tethered Desktop only, wired connection. I wanted wireless monitoring from anywhere.
WebSocket ✓ Perfect fit Wireless, browser-based, real-time, no installation needed. Browser = instant access.

Tools & Technologies Used

  • Arduino IDE — Program ESP32-C3 with HC-SR04 sensor + servo control
  • WebSocketsServer library — Enable real-time bidirectional communication
  • ArduinoJson library — Serialize sensor data into JSON packets
  • React + JavaScript — Build web application frontend
  • HTML5 Canvas API — Draw animated radar visualization
  • Wi-Fi (ESP32-C3 built-in) — Wireless communication

Challenges & Solutions

Challenge: Wi-Fi Connectivity

Problem: IP address changes break the connection URL. Solution: Use mDNS hostname instead of IP address (e.g., `radar.local` vs `192.168.1.100`).

Challenge: JSON Parsing

Problem: One malformed packet crashes JavaScript parser. Solution: Add try-catch error handling + validate all incoming data before use.

Challenge: Canvas Performance

Problem: Redrawing 60 times/second = high CPU usage. Solution: Only redraw affected regions, reuse objects instead of creating new ones each frame.

Challenge: Debugging Wireless

Problem: Can't see what's happening when connection fails. Solution: Kept Arduino Serial Monitor working in parallel for fallback data verification.

Lessons for Next Time

1
Plan Communication Protocol Before Building

Write down exact JSON format, message frequency, error cases. This document becomes your contract between hardware and software.

2
Build Mock Data Generator for Testing

Don't wait for hardware to test visualization. Write JavaScript code that generates fake sensor data so you can test UI in isolation.

3
Add Error Recovery From Day One

Don't assume packets arrive perfectly. Log errors, continue operation, reconnect gracefully. Recovery isn't optional.

4
Test on Real Networks

Lab Wi-Fi is perfect. Real networks have interference, dead zones, latency. Test under degraded conditions early.