LATE FA UNAM

In my final project, I used platform-type load cells. For this project, I started from a digital hanging scale (Lumbor37 model) with a maximum load capacity of 150 kg. The scale includes an LCD display and is powered by two 1.5 V AA batteries.
The goal was to “hack” the scale by connecting a custom PCB equipped with a XIAO ESP32C6 microcontroller and an HX711 load cell amplifier. This setup allows the system to capture the small resistance variations produced by the strain gauges attached to the metal sensing element shown in the image below.

The metal element contains two holes used to attach the suspension hook and the applied load. As the load changes, the strain gauges deform slightly, producing an electrical signal that can be amplified, measured, and transmitted for further processing.

This scale features two push buttons: one for power on and tare, and another for changing the measurement units. As shown in the image, the scale’s electronic board has four connections identified from left to right as: E-, S-, E+, and S+.
The connections labeled E-/+ are used to power the load cell, while the S-/S+ connections transmit the differential signal generated when the strain gauges deform under load.

Although the scale electronics could have been completely replaced, I decided to keep them because the LCD display is clear and easy to use. However, the goal was to extend the system so that the measured load could be shared with structural analysis software and used to evaluate the behavior of a structural system.

As a first step, I developed a prototype using a multifunction PCB. With the help of a breadboard, I connected the load cell output to an HX711 amplifier and then connected the amplifier to pins 7 and 8 of a XIAO ESP32C6.

At the same time, I connected an OLED display through the I²C interface to visualize the measured values. This made it possible to compare readings easily without relying on the Arduino IDE Serial Monitor.

A similar solution had already been developed during the Input Devices and Output Devices assignments in Fab Academy. For this project, I was able to improve several aspects of the system. The code was optimized to achieve more stable readings, a more accurate tare and calibration process, and the ability to define a target IP address for transmitting the load data collected by the hanging scale system.

The communication strategy evolved through several iterations, each revealing design decisions that needed to be made explicitly. In this section I document the process, describing the problems encountered in the spirit of Fab Academy. It has been an intense few days involving a demanding trial-and-error process that has finally led to a robust solution.

Starting Point: Fixed IP and Blocking Loop

The first version of the sketch transmitted data via UDP to a hardcoded IP address. It worked correctly under controlled conditions but presented several structural issues:

• get_units(5) was called directly inside loop() without any timing control, blocking the processor for approximately 500 ms per cycle and preventing the HTTP server from responding smoothly.
• The low-pass filter used α = 0.9, resulting in a time constant of approximately 4.5 seconds, far too slow for dynamic load measurements.
• The remote IP address was hardcoded, requiring the sketch to be recompiled almost every day because the laboratory network assigns dynamic IP addresses that change every 24 hours.
• Negative values produced by sensor noise were being transmitted to Grasshopper when they should instead be filtered and replaced with zero.

Dynamic IP Addresses on the Laboratory Network

The LATE WiFi network uses DHCP and changes assigned IP addresses every 24 hours. With Claude’s assistance, I evaluated three possible strategies:

• Option A: ipgh Serial Command
  Manual IP configuration through the serial monitor, stored in non-volatile memory using Preferences. Simple and dependency-free, but it requires a USB connection between the computer and the XIAO.

• Option B: mDNS
  The ESP32 publishes a fixed hostname (sensor1.local) on the network. Fully automatic, but potentially unreliable on university networks where multicast traffic may be filtered.

• Option C: UDP Broadcast
  The ESP32 transmits to 255.255.255.255, allowing every device on the subnet to receive the data without needing to know any specific IP address. Robust, autonomous, and compatible with multiple simultaneous receivers.

Selected solution: UDP Broadcast as the primary communication mode, with the ipgh command retained as an emergency fallback. This combination proved to be the most suitable for an educational laboratory environment where multiple computers may connect simultaneously to the sensor data and ESP32 nodes operate autonomously without USB connections.

Sensor Node Autonomy: No Permanent USB Connection

The ESP32 nodes are powered from a 5 V supply and operate autonomously without a permanent USB connection. This ruled out serial commands as the primary solution and further reinforced the broadcast approach.

Implemented solutions:

• Yellow LED on LED BUILT_IN:
  two operating states: a short blink every 2 seconds (WiFi connected + transmitting) and a fast blink every 200 ms (no WiFi connection). This allows the node status to be verified visually without using the serial monitor.
• OLED with oledAvailable flag:
  the system operates correctly even when no display is connected, making it suitable for minimal deployments. In principle, the displays from the WH-C100 scales will be used, but the system can also operate without them.
• millis()-based timers:
  HX711 reading every 300 ms, UDP transmission every 200 ms, and OLED refresh every 500 ms. This ensures that loop() never blocks.
• Low-pass filter adjusted to α = 0.6:
  time constant of approximately 0.5 seconds, providing a much faster response to actual load changes.

Security: secrets.h File

To allow the source code to be shared publicly without exposing WiFi credentials, sensitive information was separated into a secrets.h file located in the same folder as the .ino file:

// secrets.h — DO NOT include in public repositories
#define WIFI_SSID "network_name"
#define WIFI_PASS "password"

// Inside the .ino file
#include "secrets.h"
WiFi.begin(WIFI_SSID, WIFI_PASS);

This pattern is standard practice in open-source projects that handle credentials and allows the complete source code to be shared while preserving network privacy.

Final Sketch: Key Parameters

// CHANGE ON EACH ESP32
int sensorID = 1;           // Unique node ID (1 to 6)

// Timing
READ_INTERVAL    = 300ms   // HX711 reading
SEND_INTERVAL    = 200ms   // UDP broadcast transmission
DISPLAY_INTERVAL = 500ms   // OLED refresh

// UDP
broadcastIP = 255.255.255.255 : 8888   // always active
remoteIP    = stored in Preferences    // optional fallback

UDP message format: sensorID,kg → example: 1,45.20

Serial commands:

Grasshopper: UDP Data Reception

C# Script: Minimal Communication Layer

This approach has a strong educational component. The script is reduced to three responsibilities only: opening the UDP socket, receiving the raw string, and closing the socket during reset. All processing takes place directly on the canvas using native components that students can see, interact with, and modify without needing to understand socket programming.

The script evolved through several debugging iterations:

Socket already in use error:
the most difficult issue to resolve. When the script was reloaded in Rhino without being properly closed, port 8888 remained occupied by the previous instance: Only one usage of each socket address is normally permitted.
Solution: a CloseSocket() method called both during reset and initialization, ensuring that any existing socket is always closed before opening a new one. This allows the script to be reloaded without restarting Rhino.

Reserved keyword status: in the Rhino 8 ScriptEditor, status is a reserved keyword that caused compilation errors. Solution: rename the output parameter to message.

The script returns fixed-size lists (MAX_SENSORS = 6):

• loads → {45.20, 12.50, 0, 0, 0, 0} latest reading from each sensor, 0.0 if inactive.
• active → {true, true, false, false, false, false} indicates which sensors are currently transmitting.
• message → dynamic status string showing only active sensors: RX · S1=45.20 S2=12.50

Each ESP32 is programmed with a unique sensorID. The script automatically maps ID=N to loads[N-1]. Adding a new sensor only requires programming a new XIAO with the next available ID; no modifications to the script or canvas are necessary.

Grasshopper Canvas

Each section of the canvas contains an implicit question that students can answer visually and interact with in real time:

Adjustable parameters on the Grasshopper canvas: