Forum - Recent Threads

Couldn't continue my project due to health issues

sunnyiut — Wed, 19 Nov 2025 11:12:30 GMT

Hello everyone,

I am sorry to inform you all that I have been suffering from sciatica pain for the last one month. It was due to a disc bulge at lower back. I was in complete bed rest for three weeks, after that I started physiotherapy in limited manner. Unfortunately I developed dropped foot condition which is a neurological deficit and surgery is the only option. I was supposed to have the surgery after 21st November. However, observing my improvement (a very little though) doctor suggested to wait for a couple of weeks to decide whether I need to go for surgery or not. Therefore, I was totally out of the design challenge.

I am sorry. However, I wish you would consider that and I would love to carry on my project again once I get better. Though I couldn't follow others' projects, I would like to congratulate everyone for participating here. Please pray for me.

Setting up the KR260: Ubuntu 22.04, Pynq and Vitis AI Runtime v3.5

veluv01 — Tue, 18 Nov 2025 15:46:24 GMT

KR260 was chosen for this project due to its FPGA-accelerated AI processing and built-in ROS2 support. This allows it to handle ML inference, camera feeds, and ultrasonic sensor data in real time. Its hardware acceleration and flexible I/O make it perfect for applications that use multiple sensors and need quick responses.

Ubuntu 22.04 on KR260

For this project I am using the Ubuntu 22.04 instead of the 24.04 version which is available as the latest version as I faced some issues due to the Python version mismatch during the startup when I set the default interpreter to python3.10 as the VART 3.5 requires it.

For the setup I referred the guide "Booting Kria Starter Kit Linux on KR260", which has all the information regarding the basic setup of the Ubuntu 22.04 for KR260.It's also better to choose an SD with a storage capacity of 64 GB max for flashing the Ubuntu 22.04.

I used the Raspberry Pi Imager to flash the Ubuntu 22.04 Image onto the SD card.

Initialization

Before deploying AI workloads or running PYNQ overlays on the KR260, the board must be configured using AMD’s official initialization tools.This process prepares the operating system, sets up FPGA-related services, and installs board support packages to ensure that the runtime and PYNQ framework operate correctly.

The first step is to install the xlnx-config tool, which AMD provides through the Snap store. This utility automates KRIA-specific system configuration tasks, such as enabling FPGA management services, installing boot-time utilities, and preparing system directories used by XRT and runtime components. Installing the tool with the --classic option allows it to access the system-level paths needed for hardware configuration.

sudo snap install xlnx-config --classic --channel=2.x

After installation, the board is initialized using the sysinit routine.

xlnx-config.sysinit

Setting Up PYNQ for Kria

PYNQ(Python Productivity for Zynq) is an open-source framework from AMD/Xilinx that makes it easier to work with Xilinx's reconfigurable hardware, like the FPGA fabric on the Kria KR260.

To enable a Python-based workflow on the KR260, AMD provides the Kria-PYNQ framework. This repository includes board overlays, configuration scripts, Python drivers, and prevalidated examples.Cloning the repository ensures that the latest PYNQ board files and acceleration libraries are available locally for the setup.

git clone https://github.com/Xilinx/Kria-PYNQ.git

The final step is to run the installation script, specifying the target board. The install.sh script configures Jupyter, installs required Python packages, deploys PYNQ overlays, and sets up runtime services. Using the "-b KR260" flag ensures that the installation process applies the correct board-specific settings, including kernel modules and device-tree overlays.

sudo bash install.sh -b KR260

Setting up the Vitis AI 3.5 Runtime

Deploying AI workloads on the AMD/Xilinx KR260 requires the Vitis AI Runtime (VART). This runtime serves as the main execution engine for running quantized deep-learning models on the KR260’s DPU accelerator. The VART stack includes libraries for tensor processing, model graph handling, logging, and device abstraction. All of these need to be installed before running any inference workloads.

The Vitis AI runtime for KR260 is offered as a compressed ZIP file from AMD’s public download server. This package contains all the necessary libraries, device-specific binaries, and support tools.

wget -O vai3.5_kr260.zip "https://www.xilinx.com/bin/public/openDownload?filename=vai3.5_kr260.zip"

Once downloaded, the compressed archive must be extracted.

unzip vai3.5_kr260.zip

The runtime_deb directory holds Vitis AI's core runtime .deb files. These include important components like libunilog, libxir, libtarget-factory, libvart, and libvitis-ai-library. Together, they make up the VART execution layer. AMD provides a script called setup.sh in this directory to install these packages in the right order and ensure that earlier versions are upgraded properly.

pushd vai3.5_kr260/target/runtime_deb/  
bash setup.sh

This script automatically installs all the needed dependencies and configures the system for Vitis AI inference.

The KR260 Ubuntu image might lack certain low-level shared libraries needed by the Vitis AI runtime. AMD provides these in a compressed file named lack_lib.tar.gz. Extracting and copying them into /usr/lib fixes any missing dependency problems that could cause VART applications to fail at runtime due to unresolved symbols

cd ..  
tar -xzf lack_lib.tar.gz  
sudo cp -r lack_lib/* /usr/lib

After installing the runtime and any missing libraries, it’s helpful to return to the original working directory using the popd command. This step navigates back to the main vai3.5_kr260 folder, preparing for the installation of utilities like xbutil2.

popd

The KR260 needs a functioning xbutil2 utility for system inspection, FPGA health checks, and DPU diagnostics. This tool checks if the accelerator is properly initialized and if the Vitis AI runtime environment is ready for use. The utility is located in the xbutil_tool directory and must be copied to the correct system binary location (/usr/bin/unwrapped/) for the Ubuntu to recognize it.

sudo cp ./xbutil_tool/xbutil2 /usr/bin/unwrapped/

After installation, users can verify system health using

sudo xbutil2 examine

Final Hardware Setup

veluv01 — Tue, 18 Nov 2025 15:42:02 GMT

In this post let's explore the final hardware setup of the project.

Required Hardware

TDK USSM Demo Kit	Ultrasonic sensing module for precise distance measurement and object proximity detection.
KR260 Robotics Starter Kit	Primary computing platform featuring AMD Xilinx Kria K26 SoM for real time ML inference, sensor data processing, and ROS2 middleware integration.
Wireless USB Adapter	Enables WiFi connectivity for remote monitoring, data transmission, and network based control.
USB Camera Module	Captures real-time video for vision processing, object detection, and environmental perception.
Mounting Spacers	Hardware fasteners for secure component installation and proper PCB elevation.
Adjustable Tripod Stand	Provides stable support with adjustable height and positioning for optimal sensor placement.
Acrylic Mounting Sheets	Rigid, transparent platform for organized hardware assembly and improved cable management.

Block Diagram

Here's the block diagram showing how the hardware is connected to the KR260

Setting up...

The setup starts with preparing the acrylic sheets, cutting them to the required size for the tripod mounting and drilling the mounting holes to mount the hardware.

The main support structure has a two-layer design with upper and lower platforms. An additional medium-sized sheet is used for mounting the camera and TDK USSM modules. A smaller sheet is specifically reserved for the TDK Demo Kit.

Assembly begins with securely attaching the bottom acrylic layer to the tripod stand. This creates a stable foundation for the entire system.

Once the base is properly positioned and leveled, the KR260 Robotics Starter Kit is installed on this bottom layer with the help of plastic spacers. These spacers serve two purposes: they provide electrical isolation for the board and ensure there is enough space for ventilation, which helps with thermal management.

With the controller in place, the next step is to create the upper structure. Metal spacers establish standoffs between the bottom and top layers, ensuring both strong structural support and effective heat dissipation. The TDK Demo Kit is securely positioned on this top acrylic platform.

The final phase of setup focuses on installing the sensor module. The USB camera is attached to its designated mounting sheet using a magnetic mount that allows for quick adjustments and repositioning. The TDK USSM modules are installed next to the camera on the same sheet.This complete camera + USSM sensor unit is then secured to the main structure using metal angle brackets. These brackets allow for tilting and adjusting the sensor orientation to achieve the best field of view and detection range.

Here's the final setup after assembly....

Early Flood Warning and Monitoring System #5 Testing the Flood Warning System by prototype assembly

sandeepdwivedi17 — Sun, 16 Nov 2025 19:11:31 GMT

Testing the Flood Warning System by prototype assembly

So, this is it. The moment of truth.
After weeks of code, cables, and caffeine, it was time to see if my little flood warning system could actually handle the real world.

Spoiler: it didn’t catch fire. So, that’s already a win.

Setting the Scene

It was a Sunny morning — the perfect “let’s see what the water does” day. as this is winter time so not much changesin water level of river so decide to check it in a bucket filled with water. hwere i can rapidaly increase or decrease water level.

it is working good.
Google sheet Data LLog

email alert screen shot

For Now System is working good.

community.element14.com/.../WhatsApp-Video-2025_2D00_11_2D00_17-at-12.40.31-AM.mp4

Early Flood Warning and Monitoring System #4 - Wiring the Brains: Hooking Up the TDK Ultrasonic Sensors to the MKR 1010

sandeepdwivedi17 — Sun, 16 Nov 2025 18:47:41 GMT

So the fun part begins — wires, boards, and the faint smell of solder.
This is where the project goes from “cool idea” to “actual blinking lights.”

Here in this blog we will discuss the wiring of all components and the Code inside the Arduino Board.

Circuit Arrangement:

Required Hardware:

TDK USSM Distance measurement sendor — the stars of the show.They send ultrasonic pings and measure how long it takes for echoes to come back.
Arduino MKR WiFi 1010 — the brain that reads data, processes it, and sends it to the online google sheet for collection anf furture analysis as well as initiate warning email when danger mark is near.
BS170 MOSFET , 15 k Ohm Resistance , used for logic level converter to safely operate our arduino
LM2596S DC-DC Buck Converter Power Supply to poweup the sensor with 12 v
A bunch of colorful jumper wires — because what’s a DIY project without a rainbow of cables?

Open Arduino IDE and Upload following code into it

// TDK-MKR-Logger - MKR WiFi 1010 sketch (simulation mode) - API key + server-config reflect
// Paste into Arduino IDE and upload to MKR WiFi 1010
// Requires: WiFiNINA, ArduinoJson (v6.x)

// ------------------------ user config (replace placeholders) ------------------------


// set this to the API_SECRET / key you put in ConfigDetails (column Value for key API_SECRET)
const char* API_KEY = "jlkajlkj"; // <--- replace to match your sheet's API_SECRET

const char* SENSOR_NAME = "MKR_UltraSim_01"; // change if needed
const unsigned long POST_TIMEOUT_MS = 30UL * 1000UL;     // wait up to 30s for server response
// ------------------------------------------------------------------------------------

#include <WiFiNINA.h>
#include <ArduinoJson.h>
#include "arduino_secrets.h" // must contain SECRET_SSID and SECRET_PASS
#include <TDK_USSM.h>

//-- Instanciate Single Sensor
TDK_USSM TdkUssm(2); //Initialize Sensor Pins (IoPin)

unsigned long POST_INTERVAL_MS = 10000; // default if server doesn't override
float THRESHOLD_VALUE = 15.0;           // default if server doesn't override

unsigned long lastPost = 0;

void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 4000) ; // wait for Serial (short)
  Serial.println();
  Serial.println("TDK-MKR-Logger (with API key) starting...");

  randomSeed(analogRead(A0)); // seed random for simulation

  connectWiFi();

  // Optional: if you set GAS_CONFIG_URL and want to fetch config on boot, uncomment:
  // if (strlen(GAS_CONFIG_URL) > 0) tryFetchConfig();

  lastPost = millis() - 1000;
}

void loop() {
  unsigned long now = millis();

  // Only try posting on interval
  if (now - lastPost >= POST_INTERVAL_MS) {
    lastPost = now;

    int value = readDistanceSim();           // you changed to int
    bool alertNeeded = (value < THRESHOLD_VALUE);

    // Build JSON payload
    StaticJsonDocument<256> doc;
    doc["sensor_name"] = SENSOR_NAME;
    doc["value"] = value;
    doc["alert_requested"] = alertNeeded;
    doc["device"] = "MKR1010";
    doc["uptime_ms"] = now;
    doc["api_key"] = API_KEY;

    String payload;
    serializeJson(doc, payload);

    Serial.print("Posting payload: ");
    Serial.println(payload);

    String serverResp;
    const int MAX_POST_ATTEMPTS = 3;
    bool postOk = false;
    int attempt = 0;
    unsigned long backoff = 500; // ms - initial backoff

    while (attempt < MAX_POST_ATTEMPTS && !postOk) {
      attempt++;
      Serial.print("POST attempt ");
      Serial.println(attempt);
      if (httpPostJson(FLOOD_POST_URL, payload, serverResp)) {
        postOk = true;
        Serial.println("POST succeeded.");
        Serial.print("Server raw response: ");
        Serial.println(serverResp);
        // parse & apply server config (same as before)...
        StaticJsonDocument<512> respDoc;
        DeserializationError err = deserializeJson(respDoc, serverResp);
        if (!err) {
          if (respDoc.containsKey("config")) {
            JsonObject cfg = respDoc["config"].as<JsonObject>();
            if (cfg.containsKey("THRESHOLD_VALUE")) {
              float newTh = cfg["THRESHOLD_VALUE"].as<float>();
              Serial.print("Server requested THRESHOLD_VALUE = ");
              Serial.println(newTh);
              THRESHOLD_VALUE = newTh;
            }
            if (cfg.containsKey("POST_INTERVAL_MS")) {
              unsigned long newInterval = cfg["POST_INTERVAL_MS"].as<unsigned long>();
              Serial.print("Server requested POST_INTERVAL_MS = ");
              Serial.println(newInterval);
              POST_INTERVAL_MS = newInterval;
            }
          }
          if (respDoc.containsKey("alert")) {
            const char* alertText = respDoc["alert"];
            Serial.print("Server alert: ");
            Serial.println(alertText);
          }
        } else {
          Serial.print("Failed to parse server JSON: ");
          Serial.println(err.c_str());
        }
        break;
      } else {
        Serial.println("POST failed on attempt.");
        // small delay with backoff before retrying
        delay(backoff);
        backoff = min(backoff * 2, 5000UL); // cap at 5s
      }
    } // end attempts

    if (!postOk) {
      Serial.println("All POST attempts failed.");
      // Only attempt WiFi reconnect if link is actually not connected
      if (WiFi.status() != WL_CONNECTED) {
        Serial.print("WiFi status != CONNECTED (");
        Serial.print(WiFi.status());
        Serial.println(") - attempting reconnect.");
        connectWiFi();
      } else {
        Serial.println("WiFi appears connected; not reconnecting. Will try again on next interval.");
        // Optionally: you could force a reconnect if you see many consecutive POST failures
      }
    }
  }

  // If WiFi truly drops outside POST, try reconnecting (small check once every 10s)
  static unsigned long lastWifiCheck = 0;
  if (millis() - lastWifiCheck > 10000) {
    lastWifiCheck = millis();
    if (WiFi.status() != WL_CONNECTED) {
      Serial.print("WiFi status check: not connected (");
      Serial.print(WiFi.status());
      Serial.println("). Reconnecting.");
      connectWiFi();
    }
  }

  delay(50);
}


void printConfig() {
  Serial.println(F("\n--- Current Configuration ---"));
  Serial.print(F("THRESHOLD_VALUE: "));
  Serial.println(THRESHOLD_VALUE);
  Serial.print(F("POST_INTERVAL_MS: "));
  Serial.println(POST_INTERVAL_MS);
  Serial.println(F("------------------------------\n"));
}

/* -------------------- helpers -------------------- */

int readDistanceSim() {
  TdkUssm.GetDistanceCm();  // Prints Distance in cm.
}


void connectWiFi() {
  Serial.print("Connecting to WiFi SSID: ");
  Serial.println(SECRET_SSID);

  WiFi.end();
  delay(200);

  int status = WiFi.begin(SECRET_SSID, SECRET_PASS);
  unsigned long start = millis();
  while (WiFi.status() != WL_CONNECTED && (millis() - start) < POST_TIMEOUT_MS) {
    delay(500);
    Serial.print(".");
  }
  if (WiFi.status() == WL_CONNECTED) {
    Serial.println();
    Serial.print("WiFi connected. IP: ");
    Serial.println(WiFi.localIP());
  } else {
    Serial.println();
    Serial.print("WiFi connect failed, status=");
    Serial.println(WiFi.status());
  }
}

// Simple HTTPS POST with JSON payload; returns server response body
bool httpPostJson(const String &url, const String &jsonPayload, String &responseBody) {
  responseBody = "";
  if (url.length() == 0) {
    Serial.println("GAS_POST_URL not set!");
    return false;
  }

  String host = hostFromUrl(url);
  String path = pathFromUrl(url);
  if (host.length() == 0 || path.length() == 0) {
    Serial.println("Invalid GAS_POST_URL.");
    return false;
  }

  WiFiSSLClient client;
  Serial.print("HTTPS POST to host: ");
  Serial.print(host);
  Serial.print(" path: ");
  Serial.println(path);

  if (!client.connect(host.c_str(), 443)) {
    Serial.println("Connection failed (POST).");
    return false;
  }

  // Build request
  client.print(String("POST ") + path + " HTTP/1.1\r\n");
  client.print(String("Host: ") + host + "\r\n");
  client.print("Connection: close\r\n");
  client.print("Content-Type: application/json\r\n");
  client.print(String("Content-Length: ") + jsonPayload.length() + "\r\n");
  client.print("User-Agent: MKR1010\r\n");
  client.print("\r\n");
  client.print(jsonPayload);

  unsigned long timeout = millis();
  while (client.connected() && !client.available()) {
    if (millis() - timeout > 8000) {
      Serial.println("Timeout waiting for POST response.");
      client.stop();
      return false;
    }
  }

  // read status line
  String statusLine = client.readStringUntil('\n');
  statusLine.trim();
  Serial.print("Status: ");
  Serial.println(statusLine);

  // skip headers
  while (client.available()) {
    String line = client.readStringUntil('\n');
    line.trim();
    if (line.length() == 0) break;
  }

  // read body
  String body = "";
  unsigned long start = millis();
  while (client.available()) {
    char c = client.read();
    body += c;
    if (millis() - start > 8000) break;
  }

  client.stop();
  responseBody = body;
  return true;
}

// URL helpers
String hostFromUrl(const String &url) {
  int idx = url.indexOf("://");
  int start = (idx >= 0) ? idx + 3 : 0;
  int slash = url.indexOf('/', start);
  if (slash < 0) return url.substring(start);
  return url.substring(start, slash);
}

String pathFromUrl(const String &url) {
  int idx = url.indexOf("://");
  int start = (idx >= 0) ? idx + 3 : 0;
  int slash = url.indexOf('/', start);
  if (slash < 0) return "/";
  return url.substring(slash);
}

// arduino_secrets.h
// Put this in the same folder as your sketch or in your Arduino sketchbook/libraries folder.
// Replace the values between the quotes exactly (case-sensitive). No trailing spaces.

#ifndef ARDUINO_SECRETS_H
#define ARDUINO_SECRETS_H

#define SECRET_SSID "WIFIname"      // <-- replace with your Wi-Fi SSID (2.4 GHz)
#define SECRET_PASS "wifipass"  // <-- replace with your Wi-Fi password







#define HTTPS_PORT_NUMBER 443

#define FLOOD_POST_URL   "https://script.google.com/macros/s/AKfycbw27cP9jphgyeJNA7Mr2523E2NE8FiNO1ZGUrQqqFY99Hr-roe357eSuJDAVEvfmZKCzw/exec" 
// OPTIONAL: endpoint that returns JSON config { "THRESHOLD_VALUE": 15, "POST_INTERVAL_MS": 10000 }
// If you don't have this, set GAS_CONFIG_URL to "" and sketch will use defaults below.
#define FLOOD_CONFIG_URL "https://script.google.com/macros/s/REPLACE_WITH_YOUR_CONFIG_URL/exec"

#endif

In Next Blog we will see the testing and results

Early Flood Warning and Monitoring System #3 - Code and Cloud Making the MKR Talk to Google Sheets

sandeepdwivedi17 — Sun, 16 Nov 2025 17:44:52 GMT

Alright — time for the slightly nerdy, very satisfying bit.
This is where the sensors stop being lonely hardware and start sending real data to the cloud.
No smoke. No drama. Just packets, spreadsheets, and the occasional garbage value that makes you laugh and cry.

The simple goal — in one line

Read water level. Send it. Get an alert if things go wrong.

What I stitch together here

Arduino MKR WiFi 1010 — the brain and Wi-Fi radio.
TDK Eval board + USSM sensors — they do distance sensing.
Google Sheets — the datastore and quick dashboard.
Google Apps Script — the tiny web API that accepts posts and emails alerts.

Think: sensor → MKR → HTTPS POST → Apps Script → Sheet → emails.
That chain is the whole system.

Why Google Sheets? (Spoiler: Because it’s fast)

Sheets is free, easy, and everyone knows it.
You don’t need a server or a database yet.
For a prototype and a competition demo, it’s perfect.
Later we can swap it for a proper backend. But right now — speed wins.

Server-side: Apps Script doPost

On the Google side, doPost(e) checks:

JSON parse ok?
api_key matches?
value is numeric?
alert_requested true AND value compared vs THRESHOLD_VALUE in the sheet?

If conditions match, it sends email(s) and writes Alert Sent @ TIMESTAMP into the DataLog row.

Create a google sheet "TDK-MKR-Logger" with 3 tabs.
tab1 named "ConfigDetails"

Tab 2 "Email_list"

Tab 3 "DataLog"

Click on Extensions and select Apps Script

Copy and Paste my Code into it.

/**
 * Google Apps Script for "TDK-MKR-Logger" Google Sheet
 *
 * Sheets expected:
 * 1) "ConfigDetails" - columns: key | Value | Description
 *      - keys expected: THRESHOLD_VALUE, POST_INTERVAL_MS
 * 2) "Email_list"    - column A header "Email Addresses" followed by emails
 * 3) "DataLog"       - columns: Timestamp | Sensor Name | Value | Alert Sent
 *
 * doPost(e): Accepts JSON payload and appends row to DataLog
 *           Payload example:
 *           { "sensor_name": "MKR_UltraSim_01", "value": 12.3, "alert_requested": true }
 *
 * doGet(e): Returns JSON config: { "THRESHOLD_VALUE": 15, "POST_INTERVAL_MS": 10000 }
 *
 * Notes:
 * - This script uses MailApp to send emails (requires permission).
 * - Deploy as Web App and set "Execute as: Me" so MailApp runs under your account.
 */

const SHEET_NAME = 'TDK-MKR-Logger';
const TAB_CONFIG = 'ConfigDetails';
const TAB_EMAILS = 'Email_list';
const TAB_DATALOG = 'DataLog';

// MAIN - POST handler
function doPost(e) {
  try {
    if (!e || !e.postData || !e.postData.contents) {
      return jsonResponse({ error: 'No POST data received' }, 400);
    }

    // parse JSON body
    let payload;
    try {
      payload = JSON.parse(e.postData.contents);
    } catch (err) {
      return jsonResponse({ error: 'Invalid JSON', details: err.toString() }, 400);
    }

    const sensorName = (payload.sensor_name || payload.sensor || 'UnknownSensor').toString();
    // coerce numeric
    const value = parseFloat(payload.value);
    const alertRequested = Boolean(payload.alert_requested || payload.alert || false);

    if (isNaN(value)) {
      return jsonResponse({ error: 'Value must be a number' }, 400);
    }

    const ss = SpreadsheetApp.getActiveSpreadsheet();
    if (!ss) {
      return jsonResponse({ error: 'Spreadsheet not found or not opened' }, 500);
    }
    const configSheet = ss.getSheetByName(TAB_CONFIG);
    const emailSheet = ss.getSheetByName(TAB_EMAILS);
    const dataSheet  = ss.getSheetByName(TAB_DATALOG);

    if (!configSheet || !emailSheet || !dataSheet) {
      return jsonResponse({ error: 'One or more expected tabs not found', requiredTabs: [TAB_CONFIG, TAB_EMAILS, TAB_DATALOG] }, 500);
    }

    // read config values
    const config = readConfig(configSheet);
    const threshold = Number(config.THRESHOLD_VALUE);
    // fallback if config missing or invalid
    const THRESHOLD_VALUE = isFinite(threshold) ? threshold : 15;
    const nowIso = (new Date()).toISOString();

    // prepare row: Timestamp | Sensor Name | Value | Alert Sent
    let alertSentText = '';
    const newRow = [ nowIso, sensorName, value, '' ];
    dataSheet.appendRow(newRow);
    const lastRow = dataSheet.getLastRow();

    // If alert requested AND value is below threshold (per your spec "lesser than threshold triggers alert")
    if (alertRequested && value < THRESHOLD_VALUE) {
      // read emails
      const emails = readEmails(emailSheet);
      if (emails.length > 0) {
        const subject = `ALERT: ${sensorName} reading ${value} < ${THRESHOLD_VALUE}`;
        const body = [
          `Sensor: ${sensorName}`,
          `Value: ${value}`,
          `Threshold: ${THRESHOLD_VALUE}`,
          `Timestamp: ${nowIso}`,
          '',
          'This alert was generated by the TDK-MKR-Logger Google Apps Script.'
        ].join('\n');

        // send to each email (MailApp.sendEmail handles comma-separated list too)
        try {
          MailApp.sendEmail(emails.join(','), subject, body);
          alertSentText = `Alert Sent @ ${nowIso}`;
          // write alert info into the Alert Sent column (4th column)
          dataSheet.getRange(lastRow, 4).setValue(alertSentText);
        } catch (mailErr) {
          // email failed - log error into sheet in Alert Sent column
          const errText = `Alert FAILED @ ${nowIso} -- ${mailErr.toString()}`;
          dataSheet.getRange(lastRow, 4).setValue(errText);
          // return success with warning about email failure
          return jsonResponse({ status: 'ok', message: 'row appended, email failed', error: mailErr.toString() }, 200);
        }
      } else {
        // no emails found - put note in Alert Sent
        const note = `Alert requested but no email addresses found @ ${nowIso}`;
        dataSheet.getRange(lastRow, 4).setValue(note);
      }
    }

    // Successful append (and maybe alert)
    return jsonResponse({ status: 'ok', row: lastRow, alert: alertSentText || null, config: config }, 200);

  } catch (err) {
    return jsonResponse({ error: 'Unhandled exception', details: err.toString() }, 500);
  }
}

// GET handler - returns config as JSON
function doGet(e) {
  try {
    const ss = SpreadsheetApp.getActiveSpreadsheet();
    const configSheet = ss.getSheetByName(TAB_CONFIG);
    if (!configSheet) {
      return jsonResponse({ error: 'ConfigDetails sheet not found' }, 500);
    }
    const config = readConfig(configSheet);
    // ensure numeric where appropriate
    if (config.POST_INTERVAL_MS) config.POST_INTERVAL_MS = Number(config.POST_INTERVAL_MS);
    if (config.THRESHOLD_VALUE) config.THRESHOLD_VALUE = Number(config.THRESHOLD_VALUE);
    return jsonResponse(config, 200);
  } catch (err) {
    return jsonResponse({ error: 'Unhandled exception', details: err.toString() }, 500);
  }
}

/* ================= Helper functions ================= */

function readConfig(sheet) {
  // Expecting two columns: key (A) | Value (B)
  // Read all data and build a simple key->value object
  const values = sheet.getDataRange().getValues();
  const config = {};
  for (let i = 1; i < values.length; i++) { // skip header row assumed at row 1
    const row = values[i];
    const key = (row[0] || '').toString().trim();
    const val = (row[1] !== undefined && row[1] !== null) ? row[1] : '';
    if (key) config[key] = val;
  }
  return config;
}

function readEmails(sheet) {
  // Read column A (skip header); filter empty and validate basic email format
  const col = sheet.getRange(2, 1, Math.max(0, sheet.getLastRow() - 1), 1).getValues();
  const emails = [];
  for (let i = 0; i < col.length; i++) {
    const v = (col[i][0] || '').toString().trim();
    if (v) {
      // Allow comma-separated addresses in single cell too; split and trim
      const parts = v.split(',');
      parts.forEach(p => {
        const e = p.trim();
        if (e && e.indexOf('@') > -1) emails.push(e);
      });
    }
  }
  // dedupe simple
  return Array.from(new Set(emails));
}

function jsonResponse(obj, statusCode) {
  // Apps Script ContentService doesn't allow setting HTTP status codes directly to callers,
  // but when deployed as Web App it will return 200 unless an exception is thrown.
  // We'll return a JSON wrapper with a code field so the device can inspect success/failure.
  const wrapper = Object.assign({}, obj, { _code: statusCode || 200 });
  const json = JSON.stringify(wrapper);
  return ContentService.createTextOutput(json).setMimeType(ContentService.MimeType.JSON);
}

Click on Deploy

Select New Deployment> in description type any thing you want >in Who has access select anyone >Click Deploy > from there a web URL will be created. Copy it and save for next part of arduino mkr 1010 Programming.
In next Blog we will discuss the hardware part.

Early Flood Warning and Monitoring System #2 - The Flow of Data

sandeepdwivedi17 — Sat, 15 Nov 2025 13:58:12 GMT

Every good project needs a brain.
But the real magic? That’s in the flow — how information moves from sensors to the cloud and back.

This blog is all about that invisible choreography. The part you don’t really see but totally depends on.

Working of my Project

Let’s break it down.
Imagine water rising in a river.
Here’s what happens, step by step, inside my setup:

TDK Ultrasonic Sensors measure water level distance from Sensor which is placed at Danger line marking.
Arduino will Connect to wifi. If not connected it will keep trying until its connected.
Once wifi connected it will fetch the google sheet Named “TDK-MKR-Logger’ tab “ConfigDetails”
From there it will fetch the THRESHOLD_VALUE and POST_INTERVAL_MS parameter
THRESHOLD_VALUE will define the alarming water level to send upcoming flood alert
POST_INTERVAL_MS will tell the frequency of distance measurement i.e. interval after which distance is measured
Arduino will keep measureing distance of water level from Danger mark at fixed time interval (POST_INTERVAL_MS ) from TKD Sensors. It packages that info into a neat little JSON payload .
Then send this distance to Google sheet. payload is sent via HTTPS POST to my Google Apps Script Web App . The script logs it in Google Sheets under the “DataLog” tab.
When distance from water level is received by google sheet it will check if Distance is less than threshold ?
if yes then it will send alert to Predefined Email addresses stored in “Email_list” Tab in sheet.
I keep configuration in google sheet so that in case if you want to change the threshold level or frequency of measurement taken , yoou don’t need to go to riverbed or waterbody and take Arduino out of box and reprogram it. Just simply change configuration details in google sheet and it will work . no need to reprogram Arduino for each time we change Flood parameters Configuration.

The System at a glance

So when the water rises, this happens in about 3–4 seconds:

Sensor sees distance drop
Arduino detects it’s below threshold
JSON sent to script
Sheet updates
Email alert sent
Arduino confirms

From splash to inbox — all automated.

Why This Flow Works

It’s modular, lightweight, and transparent.

Change the cloud? Just update the endpoint URL.
Change sensors? Code barely changes.
No complex cloud subscription, no hidden dependencies.
Can be created multiple such small packets of devices at different places of the water body or river with unique names so can be get more clear picture of flood estimation

It’s simple enough for DIYers, yet structured enough for scaling. But for now we will be focused only on our useful tiny Project.

Early Flood Warning and Monitoring System #1 - Introduction

sandeepdwivedi17 — Sat, 15 Nov 2025 13:50:44 GMT

You ever stood by a river after a long night of rain?
The air smells like wet soil, frogs are losing their minds, and the water looks calm… until it’s not.

That’s where this project started.

One evening last monsoon, I watched a lot of news regarding river flood in some states , bikes were stalled, people were pushing carts through knee-deep water, and the power cut out.

So yeah, that’s what pushed me to build a river water monitoring and flood warning system using TDK Ultrasonic Sensors .

I came across the TDK In-Reach Ultrasonic Sensing Challenge on Element14 and thought, “Wait… that’s exactly the kind of tech that could help.”

Perfect for tracking how close the water is to trouble.it could give people a few extra hours to move to safety. And in a flood, a few hours can make a huge difference.

(Image: TDK kit photo)

Here’s what I’m building:

A TDK USSM ultrasonic sensors mounted above a river or Water body.
An Arduino MKR WiFi 1010 that reads water levels from sensors and sends data to Google Sheets (yep, good old Sheets—simple, free, works).
A Google Apps Script that emails alerts when levels go past a threshold.

So basically, it’s a mini early warning station in a waterproof box that can be deployed in quick pace to any desired location for flood tracking.
Think of it as the river’s way of texting you: “Hey buddy, I’m rising fast.”

I’m not a big corporation or a disaster management expert. I’m just someone who got tired of watching small floods cause big chaos.

People lose things they can’t replace—photos, furniture, sometimes entire homes—because no one tells them in time.
If a simple sensor and a Wi-Fi board can give them that heads-up… why not build it?

What Makes This Special

This isn’t just about distance sensing. It’s about turning that distance into action.
Every reading is logged, timestamped, and compared against a threshold stored in a Google Sheet.That can be used as Data Analysis also in future to predict floods even before water level crosses the danger mark for flood.

What’s Next

Over the next few blogs, I’ll be posting my full build journey here on Element14.

Here’s my rough plan:

Blog 2 The Flow Chart of Data in My Flood Warning System
Blog 3: Wiring the Brains Hooking Up the TDK Ultrasonic Sensors
Blog 4: Code walkthrough + Google Sheet connection.
Blog 5: Testing the Flood Warning System by prototype assembly, Final build, results, and thoughts on real-world deployment.

Final Thought

If this project works—even in a small way—it could be used by anyone living near a water body.
A farmer. A fisherman. A small-town engineer trying to protect their community.

Power Management (EchoFill #5)

taifur — Fri, 14 Nov 2025 07:03:03 GMT

Power management is one of the challenging parts of a project. My device will be independent, battery-powered, as it will be placed on the rooftop tank; utility supply may not always be available. The device will be powered from a 18650 li-ion battery. The nominal voltage of a Li-ion battery is 3.7, which is not appropriate for an ESP8266 MCU board. I need to boost it to 5V or down it to 3.3V. Besides, I need a charging mechanism for the battery. I decided to use a Monocrystalline Solar Panel (5V, 1A) from DFRobot.

The panel has an internal regulator and provides a constant 5V to the output through the USB port.

A Li-ion battery requires a sensitive charging mechanism, and we can not directly connect a battery to a 5V supply. So, I manage the following UPS circuit for the battery, which takes 5V and charges the li-ion battery and also provides 5V constant output.

The circuit came with a separate battery holder. So, I soldered the battery holder with the circuit.

The circuit has a jumper that must be shorted to enable the output.

So, I added some solder and shorted the jumper to enable the 5V output.

The 5V output is shown in the following image. This output will be provided to the Wemos D1 Mini board.

The sensor required 8 to 18 V to its Vsup pin. I decided to provide 12V to this pin. So, I collected an MT3608 adjustable boost converter module and adjusted the output to 12V for 5V input.

I connected the power supply output to the input of the boost converter module and attached the multimeter to its output. Then I gradually adjusted the trim pot until the module’s output reached 12V.

Interfacing TDK Ultrasonic Sensor with ESP8266 Board (EchoFill #4)

taifur — Thu, 13 Nov 2025 07:18:21 GMT

My project needs an internet connection to send the water level to the cloud. So, I selected ESP8266-based Wemos D1 Mini board for its form factor and low price. As the connector of the TDK Ultrasonic sensor is not breadboard-friendly, I removed the official green connector from the sensor.

Then I attached a breadboard-friendly 3-pin connector to the sensor wire.

I added the TDK USSM Arduino library to my Arduino IDE. I opened the single sensor cm measurement example file and tried to compile it for my Wemos D1 Mini board. Unfortunately, I was getting the following error messaage.

After doing some research and with the help of ChatGPT I was able to solve the problem by replacing STATUS with TDK_STATUS as shown in the image below.

After making the changes, the code was successfully compiled and uploaded to my board.

After uploading the code to my ESP8266 board, I provided 12V to the sensor from my power supply.

I was getting the sensor data in the serial monitor, as shown in the screenshot below.

Smart Blind Assistance Device #2:Hardware & Sofware

meera_hussien — Wed, 12 Nov 2025 21:42:30 GMT

Block Diagram

The figure below shows the simple block diagram for this project.

The Hardware

Ultrasonic Sensor Demo Kit

The first hardware that we would like to look at is the TDK Demo Kit.

{gallery}My Gallery Title

Figure below illustrate the hardware reference design of the TDK USSM Demo Board.

And below is the TDK B59110W2111W032 Ultrasonic sensor and its overview

The kit comes with the user interface software which can be downloaded here. The file is an executable file hence no installation is required. The figure below shows how the User Interface

Before we go in details into the demo board, lets go through the other main hardware that is used in this project as well

Arduino Nano 33 IoT

The next hardware that we would like into is the Arduino Nano 33 IoT. One of the main reason for me to choose this controller is because it comes with the on-board Wi-Fi module which is pretty much similar to ESP32.

Vibration Sensor & Buzzer

For the vibration sensor i will be using the Seeed Studio Mini Vibration Motor

And as for the buzzer, i will be using the

Power Supply Module

At the time of designing this, i am thinking of using the Lithium Battery TP4056 1A USB-C Charger with Protection as the charger controller

and the 3.7V 5000mAh LiPo Battery with JST-PH2.0 as the power source

Please note that, the hardware the charging module may need to be changed in the future based on the testing.

Now we have looked at the main hardware that is used in this project. The other hardware that is used in developing this project will be discussed later in other upcoming post. Now let's move on to the software part.

The Software

There will two main software that we will be using in this project. First is the TDK Ultrasonic Sensor User Interface and Arduino IDE. Since Arduino IDE is pretty straight forward, i will not be covering it here. We will look more into the TDK Ultrasonic Sensor User Interface.

Inside the the Zip file there will be two files. One is the config folder and second is the executable file.

The config files consists the ml_models, STM32_Bootloader and other files

The functions of each button in the GUI window is as explained below

That's about the hardware and software used in this project. In the next post, we shall see how to get started with the TDK Ultrasonic Demo Kit

Smart Blind Assistance Device #1: Introduction and Project Concept

meera_hussien — Tue, 11 Nov 2025 11:48:00 GMT

Introduction

Mobility and independence are essential aspects of everyday life, yet for visually impaired individuals, navigating crowded or unfamiliar environments can be challenging and unsafe. The Smart Blind Assistance Device aims to bridge this gap using advanced sensing technology and intelligent feedback mechanisms. By combining TDK’s USSM Plus-FS ultrasonic sensors with haptic and audio feedback, the device enhances spatial awareness—allowing users to detect obstacles in real time through vibration or sound cues.

This project is developed as part of the TDK Ultrasonic Sensor Sensing Challenge, which encourages creators to explore innovative ways to apply TDK’s high-performance sensing technology to real-world problems.

Problem Statement

Traditional white canes, while effective, offer limited sensing range and cannot detect elevated obstacles such as hanging signs, tables, or moving objects. Existing electronic aids are often expensive or cumbersome. The Smart Blind Assistance Device is designed to be compact, lightweight, and affordable, offering an intuitive feedback system that can easily be adapted into various form factors—such as a wearable glove, a cane attachment, or a clip-on module.

Project Concept

At the heart of this device lies the TDK USSM Plus-FS ultrasonic sensor, a high-precision distance sensor that measures the proximity of nearby objects. The device continuously monitors its surroundings and translates the measured distance into vibration intensity or audio feedback, depending on how close the user is to an obstacle.

When the object is far, the vibration is weak or silent.
As the object approaches, the vibration strength increases.
For very close obstacles, a short audio or buzzer alert may trigger as a final warning.

This intuitive sensory mapping allows users to build a mental picture of their environment without visual input, helping them move confidently and safely.

System Overview

Component	Function
TDK USSM Plus-FS Ultrasonic Sensor	Measures distance to obstacles using ultrasonic waves
Arduino Nano 33 IoT	Controls sensors and processes data
Vibration Motors	Provide tactile (haptic) feedback proportional to distance
Buzzer or Audio Module (optional)	Provides auditory alerts for close obstacles
Battery & Charging Circuit	Powers the system for portable use

Development Plan

The project will be developed in five main phases, each covered in a dedicated post:

Introduction and Concept (this post)
Hardware and Circuit Design – connecting the TDK sensor, Arduino, and feedback modules
Firmware and Sensor Integration – programming distance detection and response logic
3D Enclosure Design – designing and printing the wearable shell
Testing and Results – performance evaluation and final prototype demonstration

Expected Impact

By leveraging TDK’s ultrasonic sensing capabilities, this device can become a low-cost assistive tool for enhancing independent mobility among the visually impaired. It demonstrates how modern sensor technology can transform accessibility—blending empathy, innovation, and practicality into a single, meaningful project.

Unboxing The TDK Evaluation Board

Now let's do the unboxing of the TDK Evaluation Board.

community.element14.com/.../20251111_2D00_234632.avi

Next Steps

In the next blog post, Smart Blind Assistance Device #2: Hardware and Circuit Design, I’ll dive into the hardware setup, showing how the TDK USSM Plus-FS sensor interfaces with the Arduino Nano IoT, vibration motors, and buzzer.

Measuring Water Level (EchoFill #3)

taifur — Mon, 10 Nov 2025 18:02:24 GMT

One of the main goals of my project is to measure the water level using the ultrasonic sensor. So, I was trying to measure the water level using the TDK Demo Kit. I used a 25-liter water jar and positioned the sensor unit at the top opening of the jar. After launching the demo kit software, I activated the sensor’s zero calibration. With this setup, the sensor measured a distance of 235 cm. I was a bit confused about the reading because the actual height of an empty jar should be more.

I filled one-third of the jar and measured the distance again. Surprisingly, I got the same reading from the sensor, which is shown in the following image.

I filled the jar to about half and still read the same value. I became very disappointed.

I continued the experiment and filled the jar to about two-thirds of its capacity, but the measured value remained unchanged.

I was quite disappointed with the reading, yet at the same time, curious to understand the reason behind it. I suspected that the narrow neck of the jar might be causing the inaccurate measurement. To eliminate this issue, I decided to use a water bucket instead of the jar. The bucket has a wide opening, which should prevent any obstruction or disturbance to the sensor readings. I made the following setup to measure the water level of the bucket using the sensor kit.

With a portion filled, I was getting the following result (not 235cm at this time!). The reading was around 165cm.

I added more water to the bucket until it was nearly full, and the sensor reading changed as expected. This confirmed that the previous error was for the narrow neck of the jar.

Since I plan to measure the water level in a large tank that doesn’t have a narrow opening, the sensor is unlikely to face any difficulties or produce errors in level detection. I got a very accurate level in the case of the water bucket.

SwishMaster - #7 - Miscellaneous

amgalbu — Thu, 06 Nov 2025 17:22:28 GMT

While I wait for the right moment to the test the SwishMaster on a court (which will be, hopefully, this weekend), here is a miscellaneous update on the project

Firmware

Firmware will have three main states:

Calibration: in order to reliably detect the ball, I need no other obstacle is in the range of the USSMs. For this reason, firmware has a state where it reports, on the display, whether any obstacle is detected. This function is useful to help the user place the SwishMaster device in a proper position
Levelling: not sure about how useful is this function, but I added a state where the firmware shows the horizontal alignment of the device
Working: in this state, the firmware tracks the ball and compute trajectory parameters

Firmware logic is shown in the following flowchart

Data pre-processing

To avoid spurious readings, I applied the following pre-filtering logic. Every time I need a sample from the USSM, the following algorithm is performed

Take 5 samples
Remove minimum and maximum values
Make an average of the remaining 3 values

In this way, the values sent to the trajectory computation block are more reliable and accurate

Tripod mounting

Besides the firmware, I also completed the assembly of the prototype. In particular, I built a mounting for a standard camera tripod. I used an aluminum hollow cylindrical bar. On one side, I press-fitted a bolt with a standard 20 UNC thread. This bolt will be screwed into the tripod

On the other side, I externally threaded the bar to screw in a bolt that secures the SwishMaster's base

Testing the Range & Accuracy of TDK USSM Sensor (EchoFill #2)

taifur — Sat, 01 Nov 2025 07:03:29 GMT

After unboxing the TDK Demo Kit, I was curious about the accuracy and range of the TDK Ultrasonic sensor. Fortunately, the TDK provides an official Demo Kit Software that helps trigger and visualize USSM sensor measurements and data without writing any code. For testing the sensor, we need the TDK Demo board that came with the Challenger kit. Though the kit came with two sensor modules, I want to use one for my project to keep it simple and cheap. So, I wanted to test the accuracy using a single sensor.

After downloading the demo kit software, I ran it and got the following warning.

So, I connected one sensor to the demo board, then connected the demo board to my PC and ran the software again. That time everything was ok and I did not receive any warning.

The board was connected to the COM6 port of my PC. To ensure accurate distance measurements, it was essential to keep the sensor stable on a surface. However, I faced some difficulty securing it on the table, so I designed a 3D-printed base to hold the sensor firmly during testing.

The new design allows the sensor to be placed securely on any surface, with its height easily adjustable by altering the orientation of the 3D-printed base.

From the distance tab, I was able to easily measure the distance of the obstacle as shown in the above image. I have attached a short video of my distance measurement test.

community.element14.com/.../TDA-Ultrasonic-Sensor-Testing.mp4

From my experiment, I observed that the sensor provided stable and consistent readings when the obstacle was placed at a distance greater than 12 cm. For objects positioned closer than this range, the readings became noticeably unstable and fluctuated significantly. On average, I recorded an approximate measurement error of around 2 cm. I was unable to test the sensor at longer distances due to the limited space on my desk; however, this limitation does not significantly affect my project, as the intended measurement range in the water tank is relatively short.

SwishMaster - #6 - Hardware assembly

amgalbu — Sun, 26 Oct 2025 17:05:30 GMT

In this post, I am going to share my progress on building the container and assembling the electronic components of the SwishMaster device

The case

The SwishMaster case is made up of three main parts

1. The main case

The main case has slots for all the electronics components, namely

2 USSMs
The Arduino Nano 33 IoT board
The stepup converter
The level shifter

Each component will be housed in the position shown in the following picture

Note that the holes for the USSMs are 50 degrees apart, to match my findings on the area covered by the USSMs themselves (see my post here)

2. The cover

The cover is quite simple. It stays in place thanks to a bevel and is secured to the case with two screws

3. The base

The base has two brackets to hold the power bank and features a bolt to fix the SwishMaster to a camera tripod

Installation

The following pictures show the installation process of the electronic components that make up the SwishMaster

1. USSMs

2. LCD display

3. Electronic boards

All the boards are kept in place by the bevels (the boards fits exactly in the slots). For a better hold, I added some double-sided tape.

I also created a piggy-back for the Arduino board to simplify the soldering of the connections.

The final result

And, finally, here are some pictures of the first (almost) completed SwishMaster prototype

Next steps

Hardware assembly is 90% completed: some finishing are missing here and there. Firmware has been partially debugged: LCD display works as expected and trajectory calculation algorithm has been tested with simulated data. Now it's time to mount the device on a camera tripod and make some tests on field

Echo Park – Sound tube and Hardware Cleanup Post 5

ralphjy — Sun, 26 Oct 2025 00:07:38 GMT

Sound tube

I'll have to give some credit to beacon_dave again for cajoling me into trying a sound tube to make the ultrasonic sensor more directional. I had been complaining about latency I was getting from trying to use a moving average filter to reduce the multi-path noise that I was getting. I had previously tried a short 30mm tube that I had printed for another project, but I couldn't really see any positive effect.

Here it is being used with my ESP32 setup:

I realized that the best way to get a quantitative look at the effect of a tube would be to use the Demo board with its GUI for quick visualization. It seemed intuitive to me that the tube wasn't going to help much with the transmitted pulse, but would help restrict the angle of the received echoes. I have no idea how I would go about optimizing a sound tube, so I took a seat of the pants empirical approach with the goal of just making the noise "better". Dave had a picture of a long (>300mm) sound "trumpet" that was used on an 80's era ultrasonic tape measure. It is basically a long tapered tube with the small end at the sensor. I've seen sound tubes for PIL Sensors, but they are used only on the short range (400mm), high frequency (360KHz) sensors. I decided to mimic the design of the SR04T - Ultrasonic distance sensor cone on Thingiverse that is designed for a 40KHz sensor.

I ended up trying a 40mm cylinder with a 30mm cone on top as it was quick to design and print.

I then printed a new mounting plate for the sensor and here is the new setup (I call it the sound trumpet in honor of Dave ☺):

Testing

To test the effect of the trumpet, I ran a series of envelope plots:

No trumpet, no target

No trumpet, square panel target at 120cm

Trumpet added, square panel target at 120cm

I'll admit that looking at the envelope data, I couldn't determine that I'd improved anything. It looks like the amplitudes all increased and shifted in time. The primary echo was wider.

What really surprised me was the Streamout readings. Without the tube it was measuring 90cm and with the tube it was measuring 50cm. I was using default thresholds, so I was probably catching the first secondary echo which had more amplitude with the trumpet added.

I had read that it might help to line the tube with sound absorbing material to prevent getting reflections caused by the transmit pulse. So, I tried lining the tube with 1/8" felt that is used for furniture pads.

Re-ran the envelope tests.

Trumpet with felt lining, no target

Trumpet with Felt Lining, square panel target at 120cm

Now, the part that I don't fully understand is the Streamout data now shows 128cm and it is extremely stable (quiet).

https://youtu.be/-AjFFXtC1xg

I, then modified the thresholds (increased them for near echoes) and Streamout showed 123cm and it was even more stable.

https://youtu.be/W4ST3NeTObo

So, I'm extremely happy with the results. I'll need to modify the project setup so that I can use the trumpet and do additional testing in the garage.

Hardware cleanup

I'm in process of cleaning up the project hardware to get ready for final testing.

Created a separate assembly for the LED strip and buzzer so that they can be mounted above the sensor assembly for visibility (I settled on 50cm above). I rewired things so that the buzzer and Neopixel wires are in the same Grove cable.
Modified the USSM sensor mount to accommodate the sound trumpet.
Made shelf mounting brackets for the LED and sensor assemblies.
Cleaned up wiring.
Added test points for the sensor level shifter.
Retested the hardware

Here is the side view of the final assembly with the trumpet and shelf mount. The LED assembly is on the desk in back.

And the front view - you can see the felt lining in the trumpet cylinder.

And the assembly test video.

https://youtu.be/mf0y5z2cQjk

What's next?

Lots of software integration left. Code became unmanageable, so need to modularize it. And the final garage testing. Many opportunities to break stuff.

And, of course, the Project Blog is going to take a bunch of time...

SwishMaster - #5 - Ball trajectory

amgalbu — Mon, 20 Oct 2025 18:59:17 GMT

In this post, I will talk about some of the relevant features of the firmware I am developing.

Reading ball height

I explained how to measure the distance between the ball and the SwishMaster in a previous post. Basically, I am leveraging the TDK USSM Arduino Library and, in particular, the GetDistanceCm() function.

Computing the ball trajectory

The main task of the firmware is to reconstruct the ball trajectory from the ball height readings. The process involves the following steps

Get an approximation of the horizontal coordinate. USSM does not provide a reading for the horizontal position of the object -just the time of flight of reflected sound waves
Correct measurement depending on horizontal position. Given the estimated horizontal position, the real distance between the ball and the sensor (i.e the distance measured along the sensor axis) can be calculated
Align the axes: sensors measure distances in two different reference systems, which have to be aligned to make all the readings refer to a common reference system
Compute the parameters of the parabola that best matches the points
Compute the ball entry angle

1. Estimate ball horizontal position

As the basketball travels across the area covered by the USSM, we need to correct the measured distance to take into account the horizontal offset of the actual position of the ball from the sensor vertical axis. The sensor does not provide such an information, but it’s possible to estimate the ball horizontal position under the following conditions

The ball speed is constant
The ball distances are read at a fixed rate

In this scenario, the following algorithm works with a good precision

Compute the average height of the ball
Calculate the width of the covered area at the computed height
The horizontal distance between samples is given by the area width divided by the number of sample

The area where the sensor can detect the basketball is approximated by a six-edges polygon, shown in the following picture

For example, the formula to compute the width of the covered area at a given height “C” is

Where “Y” is the measured distance, and X is the width of the covered area. Solving the equation, we get

2. Correct measurements for horizontal position

Given the estimation of the horizontal position and the distance returned by the USSM, we can calculate the distance along the sensor axis using the Pitagora theorem

3. Aligning the axis

Samples are taken in two different reference systems, whose axis are 50 degrees apart. To align the axis, we need to rotate the axis 25 degrees clockwise and 25 degrees counterclockwise, as shown in the following picture

To rotate a point (x, y) around the origin by an angle θ (in degrees), the standard 2D rotation formulas are:

Finally, a translation is applied to make the origins overlap

4. Parabola fitting

This is essentially performing a quadratic regression to find coefficients a,b,c for:

Using the least squares method for n points, the system of equations to solve is:

This 3×3 system can be solved using Cramer's rule.

Cramer's Rule says that we can find the value of a given variable by dividing that variable's determinant by the regular coefficient-determinant's value. That is, Cramer's Rule specifies this relationship:

where D is the matrix determinant and Da Db, Dc are the matrix where the 1st, 2nd and 3rd columns have been replaced by the determinant D. Showing the C code is probably simpler than explaining the Cramer’s rule…

Parabola SwishMasterParabola::fit()
{
  // Summations
  double Sx=0, Sx2=0, Sx3=0, Sx4=0;
  double Sy=0, Sxy=0, Sx2y=0;

  for (int i=0; i<n; i++) {
    double xi = x[i];
    double yi = y[i];
    double xi2 = xi*xi;

    Sx += xi;
    Sx2 += xi2;
    Sx3 += xi2*xi;
    Sx4 += xi2*xi2;
    Sy += yi;
    Sxy += xi*yi;
    Sx2y += xi2*yi;
  }

  // Build matrices for solving
  double denom = (Sx4*(Sx2*n - Sx*Sx)
    - Sx3*(Sx3*n - Sx*Sx2)
    + Sx2*(Sx3*Sx - Sx2*Sx2));

  double a = ( (Sx2y*(Sx2*n - Sx*Sx))
    - (Sxy*(Sx3*n - Sx*Sx2))
    + (Sy*(Sx3*Sx - Sx2*Sx2)) ) / denom;

  double b = ( (Sx4*(Sxy*n - Sy*Sx))
    - (Sx3*(Sx2y*n - Sy*Sx2))
    + (Sx2*(Sx2y*Sx - Sxy*Sx2)) ) / denom;

  double c = ( (Sx4*(Sx2*Sy - Sx*Sxy))
    - (Sx3*(Sx3*Sy - Sx2*Sxy))
    + (Sx2*(Sx3*Sx2y - Sx2*Sx2y)) ) / denom;

  Parabola p = { (float)a, (float)b, (float)c };
  Serial.print("Parabola parameters: ");
  Serial.print(a);
  Serial.print(", ");
  Serial.print(b);
  Serial.print(", ");
  Serial.println(c);

  return p;
}

5. Ball entry angle

We have the fitted parabola

The slope of the tangent at any point x_0is simply the derivative:

The angle with the horizontal is:

I just need to apply to formula to the last known point to get an estimate of the ball entry angle

And luckily...that's all

Sorry for the boring post full of formulas, but I think that some knowledge about the algorithm I implemented to computed the ball trajectory can make clearer how SwishMaster works. Next posts will focus on the case, the electronics and hopefully the first field test

Echo Park – License Plate Recognition Post 4

ralphjy — Mon, 20 Oct 2025 04:39:28 GMT

Software woes

A feature that I wanted to add to my project is license plate recognition of the vehicle that just parked. No real need for it, but it looked straightforward and there are a few different project examples for an ESP32 based camera, so I decided to try it just for fun.

Well, as Murphy’s law would have it, the fun turned into a nightmare. I’ve had some problems from the very start with the TDK software, but for the most part I’ve been able to work around them. I haven’t figured out a way to get technical support from TDK (their contact form seems sales related, and they didn’t respond when I used it to request technical support). I probably just haven’t figured out their infrastructure and to be fair, they are really set up to support OEMs not individuals. I really wanted to get the previous version of their Demo GUI because of the features that are shown in their documentation but haven’t been able to find it.

The problem that I encountered was that the USSM Arduino library had a conflict with the latest ESP32 brdlib. The latest USSM library was released in August of 2023 and there have been 17 ESP32 brdlib releases since then. I backed off the ESP32 brdlib version to a 2023 release and that allowed me to get the sensor working with my board, so I continued with the project.

Unfortunately, as I’ve been trying to incorporate new features, I’ve run into ESP32 issues with other libraries. I ran into issues with DNS resolution of sites that use ipV6 as the primary address as it appears that the ipV4 fallback is not working in the esp32 core version I’m using. I then went down a rabbit hole that consumed days of my time. I first encountered the issue when I was trying to use “pool.ntp.org” to set the time on the RTC. Switching to a hard-coded ipaddr solved that quickly. I encountered the problem again when I tried to use “generativelanguage.googleapis.com” to use Gemini for the license plate recognition (LPR). Unfortunately, a hard-coded ipaddr did not resolve it because of the way certificates are handled. I then made the mistake of trying to use AI to help me fix the problem and I spent days making changes that ended up being a complex Band-Aid that ultimately didn’t work reliably.

It seemed that I had two choices – find a later version of the ESP32 brdlib that would fix the DNS issue and still work with the USSM library or switch to a different MCU. I’ve planned my project around the Xiao ESP32S3 Sense, so I chose to try to find a compatible brdlib version. That led me down another rabbit hole. When Arduino IDE upgraded to V2 it lost the ability to easily create a clean isolated “portable” environment. There are ways that “sort of” work, but that’s a long story… I didn’t want to mess up the environment that I use for a lot of other projects or to create another virtual machine, so I switched to using another computer. Suffice to say I lost lots of time, but I think that I’ve found a small intersection of versions that work. I got DNS working which allowed me to complete an LPR program which I’ll demonstrate here, but I am concerned that if I run into additional library issues during final integration that I may have to omit some program features. I wouldn’t recommend using the current USSM Arduino library with an ESP32 MCU.

License Plate Recognition (LPR)

Processing power and memory constraints on Edge AI boards like the Xiao ESP32S3 Sense prevent doing the complex, general-purpose OCR required for License Plate Recognition. A viable technique is to capture the license plate image using an esp32 camera and then send the image to a Cloud-Based OCR for processing.

Among several options that popped up in a search for LPR projects using an ESP32 and the Arduino IDE, I found this one on Hackster: AI-Powered ANPR using DFRobot's ESP32-S3 AI Cam & Gemini API

The details of the Hackster project are available at the link and I’ll provide more detail on my implementation in the final blog post.

The project setup is like mine, but it uses a DFRobot ESP32S3 AI Camera Module. The key differences are:

Camera: OV3660 3MP vs OV2640 2MP
Flash: 16MB vs 8MB

The fact that I have less image resolution and a smaller flash size shouldn’t be an issue. The biggest problem is that I am constrained by the ESP32 brdlib version that is compatible with the USSM Arduino library. This is where I ran into the DNS issue with Google’s Gemini API. Now I’ve found a version that seems to work and have implemented the LPR program.

Here is the basic program flow (modified from the Hackster project):

Capture QVGA Image using OV2640 sensor on Xiao ESP32S3
Send image via MQTT to Node-Red for display
Encode image into Base64 format
Send an HTTP request (with encoded image) to Gemini Vision API to detect and extract the license plate characters
Send JSON doc with timestamp license plate data via MQTT to Node-Red for display

For my initial test I will use either a local pushbutton or a capture command sent via MQTT from Node-Red to initiate the flow. In the final project I will use detection of a parked vehicle to initiate it.

Serial Monitor output showing the program flow:

WiFi connect
Camera initialization
Sync RTC
Connect MQTT
MQTT request image capture
Capture image
MQTT Publish Image

Send data to Gemini
Gemini response

Parsed data
MQTT Publish Time and PlateNumber

Node-Red Flow

Receive Image Data and display
Receive Time and PlateNumber and display
Send Capture request when button pushed

Node-Red Dashboard

There are 3 groups on the dashboard:

ESP32S3 Camera - displays the last captured image
Gemini LPR - displays up to the last 10 plate data responses from Gemini, latest is on top
Command - Capture button to send capture request

Video demonstrating dashboard operation:

Images are various sizes of license plate images
Initially you will see stale data in the Gemini table
The mouse pointer will move over the Capture button to select it
The image will update immediately
The Gemini table will update after the the Gemini response which gives a sense of the processing time
All images in this test are printed on white paper

https://youtu.be/EwIQPqjkvw8

All previous images were taken in my office. I then moved the setup down to the garage and positioned the camera at parking distance and height and captured the next image. The image is pretty dim but the correct information was extracted. I may try adjusting the brightness setting on the camera...

Next steps

I have been working on adding a sound tube to reduce the multi-path reflections reaching the sensor. Results look promising. I'll discuss this in the next post.
Lots of work to do to integrate the various software programs into a single application. Hope there are no surprises. Resource conflicts are the primary worry.
I also have lots of hardware cleanup. I am working on a separate LED strip/buzzer module that I can mount 90cm above the main sensor unit. And I need the shelf mounting hardware, sound tube adapter, and a main enclosure.
Then writing the final project blog.

Clock's ticking. If I end up with a fully functional unit, I'll consider that a success. Having nice enclosures will be icing on the cake 🙂.

Hardware Setup and GUI based Configuration of the TDK USSM

veluv01 — Sat, 18 Oct 2025 15:42:59 GMT

Introduction

In the previous forum post, I have unboxed the TDK USSM kit and then completed a deep-dive into the respective hardware components and their specifications. In this forum post I'll connect the USSM sensors to the demo kit and then explore the TDK's GUI.

Mounting the USSM's in the Enclosure

Before even plugging anything in, I wanted to give my hardware a proper enclosure. A stable and secure mounting for the USSMs is critical for getting clean, repeatable data. So, I designed a simple but effective case using two acrylic sheets as shown in the below, the transparent sheet(on the left) to mount the demo board which is the bottom layer and the black opaque sheet (on the right) which is the top layer having mounting holes for the USSM sensor.

The USSMs are mounted as per the instructions(as shown below) which is given in the sensor's datasheet.

This acrylic enclosure allows the two USSM1.0 PLUS-FS sensors to be snugly fitted and secured with their included locking nuts. This setup not only protects the two USSM's but also provides a solid base for the demo board along with the USSM's, so that I can easily mount them to a tripod for testing and configuration.

Here's how it looks after all the assembly is done.

Getting the TDK USSM GUI

Now that I have fitted the sensors and the demo kit into the enclosure, I can proceed to download the GUI by going to the TDK Demo Kit Software downloads page.

And then I clicked on get user interface/ firmware.

Then I entered the details in the pop-up “Get the Software” then clicked on send and got the download option(as shown below) to download the .zip file.

After the .zip file is downloaded I extracted the files to a folder. There's a folder named "config" and an .exe file. The .exe file named "20250228_TDK_USSM_Sensor_GUI_V3.5" is the GUI for the USSM Demo kit.

Note : The instructions for installation and using the GUI, provided in the reference manual seems to be for the previous version of the GUI which is different as compared to the present(v3.5) version of the GUI available for download.

Exploring the TDK USSM Demo Kit's GUI

Now, after downloading and extracting the GUI, I connected the demo kit to the pc via the USB cable and then launched the GUI.

Note: The demo kit has to be connected to the PC before launching the GUI, else the GUI doesn't detect the connected demo kit and you'll have to relaunch the GUI for it to detect the demo kit.

After the GUI loaded I was greeted with the home screen consisting of the Measurements, Data Visualization and the Terminal sections as shown below.

At the bottom of the GUI application the connection status and through which COM port the device is connected is listed.

Measurements Section

The measurements section is the command panel for running tests. It's possible to add new measurement tasks, select from the sensor's various operational modes (I'll discuss more about these modes in the project blog) as shown below.

STREAMOUT is the preferrable type of measurement for my initial testing which involves getting the sensor's reading in centimeters so as to check how accurate the distance reading from the USSM is. Another point to be noted is that only one type of measurement can be active at a time, it's not possible to allocate multiple type of measurements for each USSM.

The measurements section can also be used to assign specific sensors to the measurement task, and then start, stop, and save or either export the results from/to a file. There's also a icon to access the Registers Window which allows for the configuration of the sensors parameters (I'll dive into this in my project blog since there's a lot of parameters(109 of them ! but only a few may be required in the final application) to be discussed and configured).

Note: The measurement profiles A,B,C can also be configured through this Registers Window.

Data Visualization Section

It's a real-time graphing window that visualizes the data from the USSMs. It's possible add and visualize data from multiple USSMs and see the sensor's perception through this section.

Note : It also has some features for data analysis through transforms, accessible by right-clicking on the graph, which is useful for some quick analysis of the USSM's waveforms.

Terminal Section

This is the only working serial console available to pass send commands(as listed in the reference manual) directly to the demo kit through the COM port. It's also possible to save the log of commands and update the firmware of the board in this terminal section.

Note: I did try to connect through the COM port using PuTTY to send commands but it wasn't working. Pressing on the boot button gave some metadata.

community.element14.com/.../PuTTY_5F00_conn.mp4

Taking the measurements from the USSMs

I mounted the TDK USSM Demo Kit on the tripod stand and took it outside to take some measurements using the solo mode for each USSM, by placing a wooden surface nearly 3 feet away from the sensors.

Here's how it looks

Now, using the STREAMOUT measurement type, I observed the measurements from the USSMs.

It seems like the sensor_0 was giving me some fluctuating and "jumpy" readings, especially when compared to the sensor_1's readings, the same result can also be observed from the Distance tab (only the solo measurement mode is available to test even though the picture at the center of GUI shows the range for pitch and catch mode) in the TDK GUI.

community.element14.com/.../distance_5F00_tab_5F00_readings.mp4

Even after placing the the sensors nearly 2 feet away from the wooden surface the sensor_0 readings had too much of the fluctuations.

community.element14.com/.../streamout_5F00_2ft.mp4

So, I looked into the sensor parameter's through the Registers Window and found that the some of the register values were a bit different.

My first thought was that this might be an error. But in fact, this is probably the sign of calibration during the manufacturing process. No two physical components are ever perfectly identical. There may be some tiny, microscopic variations in the piezoelectric material of the transducer or in the analog components of the ASIC and TDK probably performed an end-of-line calibration for each sensor, testing its specific performance and then writing a unique set of calibration values to its internal EEPROM (non-volatile memory) to compensate for the these defects.

This discovery also likely explains an issue I was having, was related to these parameters. So I did adjust the noise suppression from 0% to 50% and the temperature, to try and see if the readings are stabilized for the sensor_0.

After comparing the data from the STREAMOUT measurement for both the USSM's the readings seems to be relatively stable after the calibration, with the margin of error within +/- 1cm (hopefully after a through final re-calibration, I'll try to resolve this too).

community.element14.com/.../after_5F00_calibration.mp4

Then, I moved the the wooden surface and then did a max range test of the USSM's solo mode (only the pitch and catch mode has the max range of 5m) both the sensors gave different values.

Sensor_0 maxed out at 238 cms

Sensor_1 maxed out at 251 cms.

Unboxing TDK Ultrasonic Sensor Kit (EcoFill #1)

taifur — Fri, 17 Oct 2025 17:17:29 GMT

I am proud to be an official challenger of In Reach! Ultrasonic Sensor Sending Challenge. Although I received the challenger kit two weeks ago, I couldn't start until yesterday. Yesterday, when I first opened the box, it gave me a good feeling about the organization of the kit inside a small box. The kit includes a demo board inside an antistatic bag, two waterproof sensors, two sensor connection cables for linking the sensor unit to the demo board, one micro USB cable for connecting the demo board to the PC, and two sensor washers and gaskets for waterproof mounting.

Fig 1. Inside the box

The inner side of the box’s top cover features three QR codes linking to the demo kit quick-start guide, the demo kit software, and the official landing page. These three QR codes immediately caught my attention as soon as I opened the box.

The size, shape, and design of the sensors make it ideal for installation inside a liquid tank for precise level monitoring. Its compact form even allows it to fit inside a regular water bottle—perfect for creating a smart water bottle project, which I might explore in the future.

The kit comes with a demo board featuring two sensor connectors and a pair of I2C ports. I’m not entirely sure about the purpose of the I2C ports yet, but I plan to explore their functionality during later experiments. The sensor ports have only three pins, and this confirms that the sensor will communicate with only one wire. It seems the board also has a 10-pin JTAG connector, possibly for programming and debugging the microcontroller.

Design and quality of the sensor cables are very impressive. I also like the aluminum washers.

The 3-pin interfacing cable is long enough for experimental application, and attaching the sensor to the demo board using the interfacing cable was very easy.

First, I connected one of the sensors to the demo board, but I was curious to see how it looks with both of the sensors. And I finally did it, and it looks cool. Though the accuracy and stability of the sensor are more important than the looks but I believe that as it looks cool, it will work cool.

I have not powered the sensors yet. Before powering the device, I want to read the datasheet and reference materials. I will share my experience soon.

Echo Park – Hardware Design Post 3

ralphjy — Mon, 13 Oct 2025 03:44:25 GMT

Hardware Description

Features

Ultrasonic Sensor measures vehicle position from 225cm to 50cm
Visual indication of position in 25cm steps
Audible and Visual feedback when position is less than 50cm
Onboard display of measured distance
Vehicle identification using License Plate Recognition (LPR)
MQTT notification of vehicle parked

Block Diagram

Components

Module BOM

Component	Description	Qty	Link
TDK USSM1.0 PLUS-FS	ULTRASONIC SENSOR, 74.5KHZ	1	www.newark.com/.../82AK9947
Xiao ESP32S3 Sense	Xiao ESP32S3 with OV2640 Camera	1	www.seeedstudio.com/Seeed-Studio-XIAO-ESP32S3-Sense-Pre-Soldered-p-6335.html
Xiao Expansion Board	Xiao Expansion Board with 0.96 OLED	1	www.seeedstudio.com/Seeeduino-XIAO-Expansion-board-p-4746.html
DC-DC Boost Converter	3.3V to 12V Boost Converter	1	www.amazon.com/.../B08M19C7MM
2N7000 MOSFET	N-Channel MOSFET 200mA 60V	1
DC 5V Active Buzzer	Electromagnetic Buzzer 2300Hz 85dB @10cm	1
Carbon Film Resistors	Various values 5% 1/4W	3
NeoPixel Stick	8 x 5050 RGB LED with Integrated Drivers	1	www.adafruit.com/.../1426
JST SH 1.0mm pigtail	3 Pin Male Connector with 20AWG 20cm wires	1

I will defer the detailed hardware description to the final project blog post but will show the operation of the prototype assembly that I am testing.

Initial tests

Boost converter

The first component that I checked out was the DC-DC Converter. I didn’t expect any issues because it is using the PW5300A part which has far more capability than is required for this simple circuit and it is switching at a fixed frequency of 1.2MHz.

The input to the converter is the output of the 3.3V regulator on the Xiao ESP32S3. The documentation states that you can draw 700mA from the regulator, but I’ll need to be wary of too much WiFi activity. I want to use the 3.3V because I’d like to have the ability to run off a battery if I want to use this project in a portable mode.

The output of the converter by default is 12V but is selectable to 5V, 8V, or 9V using pad jumpers. I decided to leave it at 12V to match the setup on the Demo board. The USSM is capable of running down to 8V but it is easier to correlate when setups are the same.

The output was at 11.98V with reasonable output ripple. I will document this in the final blog.

Level converter

Since I only have to translate a single IO pin for the sensor I decided to use a discrete MOSFET circuit rather than use a 4 channel BSS138 level converter that I have from Adafruit. It will also make it easier to make changes to the pullup resistors in case that is necessary.

My primary concern with this circuit is that I am using a relatively old N-channel FET so the on resistance and VGS threshold are higher than more recent parts. The typical values for this part should be fine for this circuit but if I get a part that is on the high side of the specification it could be marginal. E.G. the typical VGS is 2V but max is 3V. The currents are under 1mA for this setup so that helps. I tested the converter statically and everything looked good (under 10mV). I also observed it on a scope and it was switching cleanly but I may reduce the 15K pullup on the USSM side to get better transitions (when I copied the circuit from the reference manual I did not account for the extra 10K pullup in the cable – that was pointed out by another challenger). I am doing the testing using my handheld scope and I haven’t set up the USB interface to my PC yet so some of this documentation is being deferred until the project blog.

Prototype Assembly

Distance visual feedback

Dave Beacon had mentioned in a comment on an earlier post that I could use an LED pixel strip as a horizontal light bar that illuminated more pixels as you got closer then flashed solid red once you reached zero distance. It turns out that I had an Adafruit 8 NeoPixel strip available so the following is my first implementation attempt. I am just lighting a single pixel that moves across the strip based on distance, but I may change that later. My initial testing was in my office, so my “zero” distance was 25cm and 25cm steps from right to left as distance increases.

The following pictures show the progression of the pixel lighting based on the distance that is displayed on the OLED screen.

I haven’t implemented blinking all the LEDs red at the “zero’ distance, but I will do that later in addition to adding an audible alarm using the buzzer.

One thing that I had forgotten about is how bright these NeoPixels are. It’s recommended that you run them off a 5V supply, but I usually connect them to a Grove interface, so I run them on 3.3V. I had left the intensity at 100% and when testing I had one light up when I was looking directly at it, and I had flashes in my vision for about 10 minutes. I’ve reduced the brightness to 30% while testing.

Zero distance audible alarm

There is a passive buzzer on the Xiao Expansion board down next to the MCU. I was going to use this as alarm when the correct parking distance was reached. When I tried the test program I didn’t hear anything. It turns out that I had cut the jumper trace to the buzzer so that I could use that GPIO pin elsewhere. I restored the connection, and the buzzer was audible but not very loud. This is a passive buzzer driven with a PWM pattern on the GPIO pin. I then recalled that I have never had any luck with these passive buzzers. I had probably cut that trace earlier because it was a waste of a GPIO pin…

I also recalled that I had purchased a bag full of active buzzers to address this problem. These are relatively small (12mm diameter x 10mm tall) and even though they are rated at 4-6V, they work well at 3.3V.

So, I added some jumper wires to the GPIO and ground, mounted it near the level converter, and proceeded to test it out. The sound level was good, but I’ll have to see whether it can be heard in the vehicle (might be difficult with the windows up and the engine running). I then encountered something that I hadn’t considered – my distance measurements were all messed up. The resonant frequency of the buzzer is 2300Hz, but that all must have been reflected at the sensor because of where I had mounted it. I repositioned the buzzer behind the assembly and pointed upward and that corrected the problem. I am going to mount the LED strip and buzzer separately from the sensor assembly in the final version, so hopefully this shouldn't be a problem.

Testing in the garage

Time to do some testing in the garage. I have changed the "zero" distance to 50cm. For the first test I positioned the sensor assembly at the garage door and just walked toward it. I couldn’t find a small “vehicle” handy that I could attach the cell phone to, so apologies for the shaky video.

Echo Park Distance Test

https://youtu.be/E_o9vvhoHYE

Then I did a quick test with the sensor pointed at the front of the car. I was somewhat surprised that the sensor actually alarmed at 50cm and stopped at 53cm. Of course, this was not a dynamic test and I’m realizing that it might be a real challenge trying out to figure out how to document that. Maybe if I had a dashcam...

Parking Distance 50cm

https://youtu.be/RtsqxCBWcwo

At 53cm the first pixel lights and the alarm stops.

I am having concerns about how responsive this system needs to be. I have a median filter to try to de-glitch the measurements and a moving average filter following it. I’ve had to back those off a lot to get a reasonable tracking response. I guess a lot of empirical testing will be required.

License Plate Recognition

I haven’t quite got this working yet. I plan to use a cloud service to do the number/character extraction. I’ve seen several project examples using this method. My first attempt has been experiencing memory issues, and I’ve been getting into reboot loops a lot.

I have a couple of more things to try and I’m still hopeful that I can get this working. That will be the subject of the next post.

SwishMaster - #4 - Connecting USSM to Arduino

amgalbu — Sat, 11 Oct 2025 06:17:11 GMT

As I said in my previous post, the SwishMaster device will be based on an Arduino 33 BLE Sense, which connects to two USSMs by means of level shifters. The overall hardware architecture is shown in the following picture

However, after checking parts availability in my components shelf, I switched the an Arduino Nano 33 IoT

Connecting the USSM

As shown in the diagram above, I am going to use a level shifter to connect the USSM IO data line to the Arduino board. In particular, I chose a bidirectional level shifter converter made by Adafruit, which is made by four identical channels. Each channel features the following circuit

Here LV (low-voltage) side is connected to a IO on the Arduino board, and the HV (high voltage) side is connect to the USSM IO data line. Regarding the MOSFET pins,

the gate (G) is tied to the LV power supply (in my case, 3.3V)
the source (S) is connected to the Arduino IO pin
the drain (D) is connected to the USSM IO data line

The principle of operation for thsi circuit is

when both sides (LV1 and HV1) are high, the voltage on the source is equal to the voltage on the gate, and the MOSFET is not conducting. Hence, HV1 is pulled-up to the voltage of the HV power supply
when LV1 is pulled-down, the MOSFET furms on because the voltage between gate and source is 3.3 V. The drain is pulled-down as well, so the low state is propagated to HV1
when HV1 is pulled-down, the MOSFET’s body diode (intrinsic diode between drain and source) conducts slightly, pulling the source (LV side) a little below 0.7 V. This drop causes the MOSFET to turn on, and the low state is propagated to LV1

According to Adafruit documentation, the maximum voltage on the HV side is 10V. This statement puzzles me, because the BSS138 states that the maximum drain-source voltage is 50 V. Anyway, just to be on the safe side, I will power the USSM with 10V, since such a voltage is still within the specifications.

Another problem with the breakout board is the 10K pullup resistor (or, at least, this is my explanation). This resistor is bit too strong and prevents the signal to get close to the ground when the sensor imposes a low state on the data line. This condition is shown in the following screenshots of the signals captured by the oscilloscope (red signal is the signal on the LV side, yellow is the signal on the HV side)

The signal from USSM is read correctly by Arduino, but, in my opinion, the voltage of the low state is too close to the threshold between low and high states. As a matter of fact, according to the Microchip SAMD21G18 datasheet, a low state is detected when voltage is below 0.99 V...

The simplest solution is to remove or short-circuit the pull-up resistor on the breakout board and add an external pull-up resistor of maybe 15K or more. At the moment, I will keep on working without any changes because I fear damaging the board. I will make this change after I have a working prototype

Reading USSM data

To interface with the USSM, I will leverage the Arduino library provided by TDK and can be downloaded from this link.

You can install the library from the Arduino IDE by clicking Sketch -> Include library -> Add .ZIP library

Here is an example of usage of the library. In my case, I just need to measure distance in centimeter. The example TDK_USSM_multiple_cm implements exactly what I need for this project

#include <TDK_USSM.h>


//-- Sensors Pinmap Sensors
#define N_SENSORS 2
const int IoPins[N_SENSORS] = {14, 16}; // Trigger/Echo Pin of Ultrasonic Sensor

// Note: Echo Pins could be same as Trigger pin if a bidir level shifter is used.

TDK_USSM TdkUssm(IoPins, N_SENSORS); //Initialize Sensor Pins

//-- Setup
void setup()
{
  Serial.begin(115200);
}

//-- Runtime.
void loop()
{
 while(1)
 {
   for(int i=0; i<N_SENSORS; i++)
   {
     Serial.print( TdkUssm.GetDistanceCm(i) ); // Prints Distance in cm of sensor i.
     Serial.print(" ");
     delay(100);
   }

   Serial.println(); // Terminate single capture line
   delay(2);
 }
}

I just changed N_SENSORS (from 4 to 2) and IoPins to match the pins used on my board.

The original version of the library did not compile, so I had to make a little change to the file Arduino/Libraries/TDK_USSM_Ultrasonic_Sensor-1.0.2/src/tdk_ussm_defs.h

The change is shown in the following code snippet

/*! \ingroup tdk_ussm
 * \brief Measurement Data Structure.
 */
typedef struct
{
    uint16_t id; // <-- original code was uint8_t id
    uint8_t lsb;
    uint8_t nbit;
    uint32_t val;
    const char *name;
    const char *description;
    const eLUTStruct *lut;
} eParameterElement;

First test

And here is the terminal output after the above test code have been downloaded and run

Next steps

I am going now to implement the firmware to calculate the ball parabola, show results on a local LCD screen, send data out through BLE and so on and so on.

The Water Wizard: 01 - Concept & Challenge Kickoff

sunnyiut — Fri, 10 Oct 2025 22:18:56 GMT

**the images in this introductory blog are AI generated. I have used it for reference to describe the concept.

The Frustration of an Empty Tank
A Simple, Wire-Free Solution
The Concept in a Nutshell
Micromanaging the power
Exploring the Kit
Limitation

This is the introductory blog for the “In Reach! - Ultrasonic Sensor Sensing Challenge,” and my project is something very familiar to all – a Water Level Monitor. A simple project with smartness of precise sensing, battery-efficient and completely wireless.

It's for those living in areas with unreliable water supply.

The Frustration of an Empty Tank

Well, I know that you all know how it feels to find out the empty tank suddenly and you are quite familiar with the water level monitoring devices. Still then trying to keep it short –

It's a common issue for people living in any region where water supply isn’t consistent. Resulting the motor runs too long, tanks overflow, or sometimes, the pump is never turned on in time or even running the pump dry.

The solutions are there as water level monitoring devices are available, but it needs long wires from the pump control unit to the sensor. Which also makes the installations complicated. Wires from float sensors or long cables increases the risk of break, corrode or cause leakage.

On the other hand, the advanced wireless devices are quite expensive and power hungry.

A Simple, Wire-Free Solution

The core goal of The Water Wizard is to create a battery-friendly, wire-free system to monitor water levels in any tank, whether it’s at home or out in the field. I’ll use the TDK USSM-plus-FS, an advanced ultrasonic sensor to measure the water level in the tank and use the Bluetooth Low Energy for long range energy efficient wireless communication. Primarily, I intend to utilize a couple of Nordic nRF5340 boards.

It sends water level data straight to a control panel and automates the pump when needed.

The Concept in a Nutshell

This project is about simplicity, affordability, and reliability. The target is to develop such a product that gives no hassle to the user and the key features are –

{gallery}Concept in a nutshell
The sensor - TDK USSM plus-fs ultrasonic sensor + nRF5340
Wireless solution - BLE - nRF5340
BLE nRF5340 + solid state relay
Sample image of a companion app

{gallery}Concept in a nutshell

The sensor - TDK USSM plus-fs ultrasonic sensor + nRF5340

Wireless solution - BLE - nRF5340

BLE nRF5340 + solid state relay

Sample image of a companion app

The Sensor Node:

In this project the sensor module will be consists of two main components.

I’m pairing the TDK USSM plus-fs ultrasonic sensor (the "eyes" of the system) with the incredibly energy efficient nRF5340 BLE module (the "voice"). The Ultrasonic sensor will accurately measure the water level, and the nRF5340 will process that data and send it out wireless.

No Wires, No Worries:

The entire sensor node sits right on or inside the tank. It uses Bluetooth Low Energy (BLE) Long Range mode and is designed for low power, avoiding cables for power or data. I'll be aiming for months of operation on a battery pack or potentially even a small solar cell. I'll try to make it simple and it should like 'a plug n play' sensor.

The Control Panel:

A separate Control Panel, also powered by an nRF5340, will receive the wireless data from the tank. This unit acts as the interface between the sensor and the pump automation..

Pump Automation & Alerts:

The Control Panel will actively control the water pump using a relay. I'll be using a magnetic contactor or Solid State Relay. This means we can automate the pumping: turn it on when the tank is low and off when it's full.

Data in the Pocket:

Finally, there will be an Android app which connects to the Control Panel, allowing to check the current water level, view history, and receive alerts right on the phone.

Micromanaging the power

A major issue for the wireless solutions currently available is that it's not only expensive, but also very much power hungry. The sensor nad communication module needs to be powered by a separate supply. I have to keep it in my mind to make this solution energy - efficient as much as I can.

My power management strategy will be putting the nRF5340 and TDK USSM into deep sleep when the motor is turned off. In my case the water pump is turned on manually twice a day and it runs around 30mins to fill up the tank fully. So, for most of the day, when the pump is idle, the nRF5340 can remain in its ultra-low-power sleep mode. So, it will be drawing only a few microamps (μA) to maintain an internal clock and listen for a "pump-on" trigger through BLE. This 'pump-on' trigger can be generated by the control unit itself after a certain amount of time automatically.

Comparatively the ultrasonic sensor draws most of the current when it's active. During this motor off period, the 'power down' mode can be activated which makes it draw nearly zero current. Upon receiving the signal from the cotrol unit, the system wakes up and takes a precise measurement.

Another option to further conserve the power could be adapting the sample rate. When the pump starts to fill up the tank the sensor can check the level every two minutes initially and upto 95% fill. As the tank approaches the 90% full mark it can increase the measurement frequency like every 30 seconds. I hope that we don't need to make continuous measurement and that can save the battery energy.

Exploring the Kit

This time I received the kit without any hassle - Thanks to TNT and element14 team for that.

The USSM1.0 PLUS-FS is an ultrasonic pulse-echo product intended for range-finding and presence-detection applications.

image courtesy: TDK Electronics

Key Features and Technical Advantages

The main feature of the USSM plus-fs for this project is the combination of robustness and advanced signal processing:

Integrated ASIC and Driver: The module is an all-in-one package. Single transducer can be used for both Tx and Rx or two of them can be paired together. The sensor includes the piezoelectric transducer, the necessary driver circuitry, and a high-end Application-Specific Integrated Circuit (ASIC) for signal processing. This integration handles complex Time-of-Flight (ToF) calculations internally, delivering clean, reliable digital range readings to the connected microcontroller (like the nRF5340 - for my project). I'll be using the 'single mode'. The range can be around 18cm to 5m. Detects transparent surfaces, insensitive to object color and density, which is important for this project. Also it has high immunity against electromagnetic interferences (EMI) noise, maybe helpful as I'll be using the wireless communication.

Mechanical Decoupling (Vibration Immunity): The piezoelectric disk, is physically separated from the main housing. I am not sure whether it's through a matching material or something else [which is not clear to me]. However, mechanically decoupled sensor element is a critical industrial feature. External mechanical vibrations can produce the false measurement result. It's good to see that this sensor has good immunity to the vibration, and I would like to check it out during my experiments.

Robust Environment Performance: The sensor has a compact, durable, water/dust protected chassis integration up to IP65/67 (EN60529). I'll check it's performance to dust, water splashes, and even temporary submersion. It's essential for outdoor water tank monitoring. It works in a wide range of lighting conditions, including full sunlight to complete darkness.

Power Down Mode: An interesting feature that gives me the opportunity to make it more energy-efficient. The inclusion of a dedicated Power Down Mode is crucial for battery-powered projects. I need to check it out - I think it can be activated by sending a command to the sensor using bidirectional IO (3-wire) communication interface.

**I'll cover more details in my second blog on the transducer itself. I had a previous experience of housing raw piezoelectric transducer in a PVC tube with matching material, backing material prepared from epoxy resin. I'll try to prepare a writeup on that too - it was interesting and I hope others will like it.

Application in Water Level Monitoring

For water level monitoring in the reservoir, there are general purpose ultrasonic sensor modules available with lower price range. But the TDK USSM plus-fs offers two major advantages:

High Accuracy and Range: In single mode, the range is 18 to 5m. It provides accurate, centimeter-level distance measurement over a range suitable for most domestic and industrial tanks.
Reliability in Adverse Conditions: We often experience rooftop water tanks prone to condensation, temperature fluctuations, and exposure to dust/insects. The USSM has a robust housing. Also it's more immune to vibration which can ensure that the sensor continues to provide stable, reliable readings. I'll try to check it's performance in adverse condition during my experiments to be rational.

Limitation

A major limitation could be the range of the nRF5340. In the long range mode [coded PHY] it should cover a good distance which can be helpful for farms like places where line of sight communication will be available. But for indoor, this range may get reduced. Which I need to check and if I cannot reach a good coverage, then I may need to think about some alternatives.

Echo Park – Sensor Characterization Setup Post 2

ralphjy — Wed, 08 Oct 2025 22:02:50 GMT

Sensor Characterization Setup

I have used a lot of the simple HC-SR04 Ultrasonic Ranging Modules that have similar range capabilities (2cm-4m). These modules use separate send and receive elements and provide the transmit and receive circuits but use an external MCU to do the time-of-flight calculations. The MCU sends a trigger pulse and receives an echo pulse. It provides the timing to determine the roundtrip time and calculates the distance. These modules operate at 40KHz and are not configurable. They are easy to use (just program the MCU using one of many available libraries) and they just seem to work with moderate accuracy.

So, I was very interested in testing the TDK USSM1.0 PLUS-FS module, which uses the elmos E524-33 ASIC. This is a pulse-echo module that uses a single piezo sensor for sending and receiving (to measure very short range (4cm), two modules can be used to send/receive). The module operates at 74.5 KHz and has a single sensor range of (18cm-5m).

This is a highly configurable module that can be tuned for specific measurement environments. The following parameters can be adjusted:

Transmit Burst Power: Adjusts the energy of the ultrasonic pulse. Higher power is generally used for longer ranges.
Receiver Sensitivity (Gain): Controls how faint an echo the sensor can detect. Higher sensitivity is needed for longer ranges, while lower sensitivity helps prevent false echoes from nearby objects. The E524.33 features advanced settings for the dynamic gain curve.
Threshold Levels: Digital signal processing compares the received echo against programmable threshold levels. You can set a primary and a secondary threshold.
Burst Length and Frequency: Defines the duration and frequency of the ultrasonic pulse.
Damping Algorithm: For near-field measurements, the "Smart Damping" algorithm can be configured to minimize the transducer's "settling time" or "blind zone" after transmitting the burst.

This configurability is a blessing and a curse. This is certainly not a point and shoot sensor. I was somewhat surprised when I set up the Demo Kit on my desk, pointed it at a large cardboard panel about 160cm away and got very noisy readings using the Streamout measurement although the average value was correct. I moved the panel back to 175cm and got similar results. Here are a couple of short videos of the Streamout plots.

https://youtu.be/UzgbIyHvets

https://youtu.be/AWDGroIn7N0

I then decided to try the measurements out in the hallway next to my office and the results were so bad that the average value was not monotonic as I varied the range. Here’s a plot of the sensor pointed at the door at the end of the hall at about 135cm.

I realized that the default threshold and gain settings were not correctly configured for my measurement setup and that I was detecting lots of multipath reflections.

The sensor specification indicates that the reference target is a cylindrical pole, 75mm diameter, 1m height. That should provide a good primary reflection and scattering of any of the sound waves that do not strike perpendicular to the target. That should minimize the amplitude of multipath reflections.

To test this out I used the Envelope measurement which provides an analog measurement of the amplitude and time of received echoes.

Here is a comparison of the Envelope measurement of a cylinder and a cardboard panel at 65cm. In the initial 1000us or so of both plots you see the initial transmission pulse and the ringdown period (time for the piezo element to settle). During this period the receiver is clipping. The target reflection occurs around 4000us and in the case of the cardboard panel the echo is strong enough to drive the receiver to clip while in the case of the cylinder it only has around 40% of that amplitude. The secondary multipath reflections are also significantly larger for the cardboard panel. The secondary reflections are also a lot earlier in time. This demonstrates that if the receiver gain and threshold are set for a faraway target that a near target measurement will suffer from significant multipath noise. Or if there is no near target it could mistake a multipath echo in its field of view (FOV) as the target. The shift in time of the secondary reflections shows the effect of the shape and size of the target surface relative to the location of other reflecting surfaces in the environment.

My project target is the front of a vehicle which is not solid or flat, so it is obvious that I will need to do my sensor characterization and parameter tuning in the garage with the vehicle (I’ll ignore for the moment that different cars may have different profiles). To that end, I built two tripod mounted measurement setups. The kit has two sensors, and I am doing single sensor measurements, so I have one sensor attached to the Demo Board so that I can leverage the capabilities of the Demo GUI software and I have the other sensor attached to the Xiao ESP32-S3 in my project configuration in order to test my application program.

The USSM sensor internal registers contain the following information:

ID, EEPROM, Wakeup, Standby
Sensor calibration
Measurement configuration
Threshold setting for profiles A and B. C uses one of them
Status: measurement context and feedback, near-field flag
Temperature

These registers contain 93 values that are stored in volatile memory.

There is also non-volatile EEPROM memory that stores the factory calibration data. After power-up the calibration data is copied into the volatile memory, and the default values are written to the Measurement Setup and Threshold Setup A/B registers.

The 4 registers "Measurement Setup", "Threshold Setup A", "Threshold Setup B" and "Calibration Setup" are used to configure the device. During characterization I’ll need to determine the correct measurement modes and threshold values. These values will need to be written to registers after power-up.

The Threshold Setups allow the configuration of 10 Threshold vs Time zones that set the detection sensitivity at different distances. The default values lower the detection thresholds as distance increases. Not sure about why the final threshold is 0 lsb, but I'll check that out.

TdkUssm[1].THRESHOLD_A[20] = {
0 | 75 | 5 | 31 |THVAL_A1 | 31 | 155.000 lsb |THVAL_A1
1 | 72 | 3 | 1 |THPOS_A1 | 1 | 256.000 us |THPOS_A1
2 | 67 | 5 | 15 |THVAL_A2 | 15 | 38.000 lsb |THVAL_A2
3 | 64 | 3 | 2 |THPOS_A2 | 2 | 512.000 us |THPOS_A2
4 | 59 | 5 | 15 |THVAL_A3 | 15 | 38.000 lsb |THVAL_A3
5 | 56 | 3 | 2 |THPOS_A3 | 2 | 512.000 us |THPOS_A3
6 | 51 | 5 | 10 |THVAL_A4 | 10 | 22.000 lsb |THVAL_A4
7 | 48 | 3 | 2 |THPOS_A4 | 2 | 512.000 us |THPOS_A4
8 | 43 | 5 | 10 |THVAL_A5 | 10 | 22.000 lsb |THVAL_A5
9 | 40 | 3 | 4 |THPOS_A5 | 4 |2048.000 us |THPOS_A5
10 | 35 | 5 | 10 |THVAL_A6 | 10 | 22.000 lsb |THVAL_A6
11 | 32 | 3 | 4 |THPOS_A6 | 4 |2048.000 us |THPOS_A6
12 | 27 | 5 | 5 |THVAL_A7 | 5 | 11.000 lsb |THVAL_A7
13 | 24 | 3 | 4 |THPOS_A7 | 4 |2048.000 us |THPOS_A7
14 | 19 | 5 | 5 |THVAL_A8 | 5 | 11.000 lsb |THVAL_A8
15 | 16 | 3 | 5 |THPOS_A8 | 5 |4096.000 us |THPOS_A8
16 | 11 | 5 | 5 |THVAL_A9 | 5 | 11.000 lsb |THVAL_A9
17 | 8 | 3 | 5 |THPOS_A9 | 5 |4096.000 us |THPOS_A9
18 | 3 | 5 | 0 |THVAL_A10 | 0 | 0.000 lsb |THVAL_A10
19 | 0 | 3 | 5 |THPOS_A10 | 5 |4096.000 us |THPOS_A10

My initial plan had been to use the full 5m range of the sensor to track the vehicle from the point where it entered the garage up to its parking position. It seems that it might require me to dynamically change the gain and threshold profile to reliably track it. I’ve decided that initially I’ll just characterize and track the final 2m.

I’ll describe my project configuration and measurement characterization results in future posts.

Note: Other challengers have been doing a good job of describing the sensor and kit specifications and operation using excerpts of the user and reference manuals, so I won’t include a lot of redundant information. I’ll reference specific features and specifications when they are unique to my project.