Published August 25, 2026 © CC BY-NC-ND

HMTT: Proof of Presence

HMTT: Zero-Interval Edge Computing for Reliable Carpooling Proof of Presence

BeginnerWork in progress8 hours25

Things used in this project

Hardware components

XIAO ESP32-C6

DS3231SN

ESP32-S3 DevKitC-1 N16R8 (16MB Flash, 8MB PSRAM)

ESP32-C6-DevKitC-1 N16 (16MB Flash, WiFi6/BLE/Zigbee)

Raspberry Pi 5 (8 GB RAM)

Software apps and online services

Arduino IDE

KiCad

Copilot

Antigravity

Hand tools and fabrication machines

PCBWay CNC machining

Story

HMTT— Zero-Interval Edge Computing System

Verifiable Proof of Presence for Carpooling & Industrial Tracking

Elevator Pitch

HMTT (HM TeamTravel) is a commercial-grade Edge Computing system that delivers tamper-proof Proof of Presence through a synchronised ecosystem of BLE-enabled hardware nodes and a local backend server. Designed for corporate carpooling, facility patrol verification, and industrial attendance tracking, HMTT operates entirely offline at the edge — with zero reliance on GSM, GPS, or mobile apps. Total hardware cost per user: approximately 160 PLN (~$40 USD).

System full spec and whitepaper web (PL):

https://hmtt.ozmina.pl/portal

The Problem

Corporate carpooling, employee attendance verification, and shift-based presence tracking face a persistent triad of challenges:

1. Verification Fraud – Employees can manipulate timestamps on mobile devices, "check in" from bed, or retroactively claim attendance. There is no objective, tamper‑proof mechanism to prove that a person was physically present at a specific time and location.

2. ESG & Cost Reporting Gaps – Organisations lack reliable data to substantiate sustainability claims around shared commuting. Without objective ridership logs, fair cost distribution among carpool participants devolves into disputes and manual record‑keeping.

3. Platform Fragmentation & UX Friction – Smartphone‑based solutions are trapped in the Android/iOS ecosystem war, require paid developer accounts, demand constant user attention, and drain batteries. Users forget to open apps, drivers get distracted, and GSM‑based trackers incur recurring SIM costs while failing in coverage dead zones.

4. Lack of Organisational Visibility & Mutual Support – Beyond the technical challenges, carpooling ecosystems suffer from poor team coordination. Employees who share rides do so for environmental reasons and cost savings — but without a centralised system, they lack visibility into each other's availability. Key information remains fragmented.

Unplanned absences – When a driver's car breaks down or requires servicing, colleagues are unaware and cannot offer alternative transport.
Leave & absence tracking – Team members don't know who is on annual leave, working from home, or on sick leave, leading to wasted journeys or last‑minute scrambles.
Shared cost management – Without objective logs, fair distribution of fuel and toll costs relies on trust and manual calculations, often leading to disputes or inequity.
Missed opportunities for support – Colleagues who could offer a lift to someone whose car is in the shop remain unaware, resulting in unnecessary solo trips and lost environmental benefits.

"HMTT remembers for people — the keychain fob simply sits in the user's pocket — while the system provides full visibility into who is travelling, who is available, and who needs support."

The Edge Computing Solution: Proof of Presence

HMTT implements a hardware-enforced Proof of Presence paradigm that is virtually impossible to spoof:

• Physical Proximity Requirement – The user must be within metres of the verification node (Car Node) at a precisely scheduled second. No amount of phone-based timestamp manipulation can circumvent this.

• Offline-First Architecture – At the moment of scanning, the system requires zero GSM or Wi-Fi coverage. All verification occurs over the local BLE radio link. Synchronisation with the backend happens only upon return to base.

• Pharmaceutical-GradeTiming – The external DS3231 RTC ensures wake windows are perfectly punctual and independent of the main microprocessor, immune to power loss or restarts.

• Zero-Friction UX – No mobile app, no screens, no passwords, no interface loading. The user simply carries the keychain fob, which vibrates to provide hardware feedback that the task is complete. This completely eliminates "digital fatigue" from the tracking process.

The Hardware Ecosystem

HMTT comprises exactly four physical components working in concert.

1. Passenger Terminal — "Brelok" (Keychain Fob)

• MCU: Seeed Studio XIAO ESP32-C6 (16 MB Flash)

• Custom PCB: Designedin KiCad v10, featuring the Maxim Integrated DS3231SN Real-Time Clock (RTC) for offline timestamping

DS3231SN PCB

• Power: 3.7 V 1S 1000mAh Li-Po battery– charged exclusively via the XIAO's built-in battery management (no external charger module)

• Haptic Feedback: Coin/pancake-type vibration motor

• User Input: Tactilepush buttons for service mode activation (RESET + BOOT)

• Enclosure: Custom 3D-printed housing (designed in Blender, printed on Creality Ender 3 Neo)

Note: The XIAOESP32-C6 + external DS3231RTC duo provides absolute NimBLE stack stability, the ability to create an Access Point (Service Mode), and perfect zero-drift timekeeping.

Implementation: StatusAdv Packet Builder (Keychain Fob Firmware)

The following snippet from the keychain fob's BLE communication layer shows how the 11-byte StatusAdv payload is assembled. Each wake cycle, the fob evaluates its internal state — pending logs, sync requirements, battery level — and encodes the result into a compact Manufacturer Data packet. The Hub parses this packet passively from the BLE scan response, enabling the Zero-Interval decision without ever establishing a connection.

2. Vehicle Node — "Car Node"

• MCU: ESP32-S3DevKitC-1 N16R8 (16 MB Flash, 8 MB PSRAM)

• Configuration: Barebone board only — no external sensors, no battery

• Enclosure: 3D-printed protective case

• Power: Vehicle 12 V system (cigarette lighter socket, ignition-switched)

• Function: Passive BLE scanner that listens for keychain fob advertisements during scheduled travel windows

3. Synchronisation Node — "System Hub"

• MCU: ESP32-C6-DevKitC-1N16 (16 MB Flash, WiFi6/BLE/Zigbee)

• Configuration: Barebone board only

• Enclosure: 3D-printed case

• Power: USB-C (5 V)

• Function: BLE-to-Cloud gateway; coordinates communication between keychain fobs and the backend server

4. Backend Server Infrastructure

• Hardware: Raspberry Pi 5 (8 GB RAM) with 500 GB NVMe SSD

• Alternative: Firebase (Firestore + Cloud Functions) can be used as a cloud backend

• Software Stack: Custom backend, system logic, calendar engine, and admin/user web portal — all hosted locally or in the cloud

Zero-Interval Architecture: Event-Driven BLE Communication

Traditional BLE systems suffer from fixed-interval polling — devices blindly connect at predetermined times, often missing each other and wasting battery life. HMTT eliminates this entirely with a Zero-Interval, Event-Driven architecture.

The Core Innovation

Instead of periodic connections, the keychain fob broadcasts a Status Advertisement — an 11-byte Manufacturer Data packet that contains status flags before any connection is established:

Byte Range Content

0-1 Company ID: 0xFFFE

2-5 Protocol: 'H', 'M', 'T', 'T'

6 Type: 0x03 (StatusAdv)

7 Flags (bitfield)

8 Battery % (0–100)

9-10 BrelokHash: 16-bit FNV-1a hash of brelok_id

Decision Flags

• HAS_LOGS– keychainhas scan logs to upload

• NEEDS_SYNC– keychainrequires time/configuration sync

• SERVICE_MODE– keychainis in service/debugmode

• LOW_BATTERY– battery below 10%

The Hub's Decision Logic

The Hub connects to a keychain only and exclusively when at least one condition is met:

(Condition; Initiator; Description)

HAS_LOGS = 1; Keychain; Logs ready for upload

NEEDS_SYNC = 1; Keychain; Time/configurationrequired

BOOT_SERVICE = 1; Keychain (physical); Userpressed RESET+BOOT-> full sync cycle (R01-R12);

HUB.DIRTY = 1; Hub/Server; New backed configuration pending for this keychain

HUB.HAS_OTA = 1; Hub/Server; OTA firmware update ready for the keychain

Result: If no flag is set, the Hub sees the key chain but does not connect. Zero BLE storms. Zero wasted intervals. Maximum battery life.

Technical Reference Classifications (R01–R12)

Each communication type receives a unique reference code:

(REF; Type; Route; Trigger)

R01; RTC Time Sync; Backend → Hub → Keychain; Every connection

R02; Log Upload; Keychain → Hub → Backend; HAS_LOGS flag

R03; Log Clear; Hub → Keychain; After successful R02

R04; Battery Report; Keychain → Hub → Backend; Every session

R05; Wake Schedule; Frontend → Backend → Hub → Keychain; User "Save"

R06; Keychain Config; Frontend → Backend → Hub → Keychain; User "Save"

R07; Car Node Config; Frontend → Backend → Hub → Keychain → Car Node; User "Save"

R08; Device Binding; Frontend → Backend → Hub → Keychain; User action

R09; OTA Firmware; Frontend → Backend → Hub → Keychain/Car Node; User action

R10; Hub Config; Frontend → Backend → Hub; User "Save"

Chunked Data Transfer

BLE's MTU limit is 247 bytes (244 bytes of payload). Both Hub and Car Node implement a chunking mechanism — large JSON payloads are split into 244-byte fragments, transmitted sequentially, and reassembled at the receiver.

System Flow: A Day in the Life

Morning Commute — Near the Car

1. Car Node powers up from vehicle ignition and reads configuration from Flash.

2. Keychain Fob wakes from Deep Sleep according to its internal schedule, opening the Car Window.

3. KeychainFob broadcasts a unique BLE trigger packet (Manufacturer Data).

4. Car Node receives the trigger, initiates ambient scanning, and builds a JSON scan log.

5. Car Node transmits results back to the keychain via BLE Notify.

6. Keychain Fob aggregates all scan dumps in LittleFS and returns to sleep.

Return Home — Synchronisation with Hub

1. Keychain Fob wakes for the Hub Window and broadcasts StatusAdv (11-byte Manufacturer Data with HAS_LOGS flag, battery %, and hash ID).

2. Hub scans BLE in the background, analyses StatusAdv flags, and connects ONLY when there is a reason.

3. Hub connects via BLE and retrieves aggregated logs from the keychain's LittleFS (chunked transfer).

4. Hub pushes received JSON logs to the backend (Raspberry Pi or Firebase) via HTTPS.

5. Hub queries the backend for new configuration and sends a sync command to the keychain, delivering:

• Current server time (Epoch)

• Updatedwake schedule

• Configuration settings (e.g., Service Mode)

Time Cascade

Time always flows from the server downward:

Server(NTP)-> Hub (Internet)-> Keychain (BLE)-> Car Node (BLE)

When the keychain connects to the car the next morning, it relays the new configuration to the Car Node — keeping the vehicle node 100 % independent of internet connectivity.

Cost Efficiency & Scaling

Total hardware cost per user: ~160 PLN / ~$40 USD

Component

Seeed Studio XIAO ESP32-C6

Approx. Cost (PLN) ~30

ESP32-C6-DevKitC-1 N16 ~39

(Hub) ESP32-S3 DevKitC-1 N16R8 (Car Node) ~29

Maxim DS3231SN RTC ~4 (41 PLN for 10 pcs)

3.7 V 1S 1000 mAh Li-Po battery ~19

Vibration motor (KY-002PWM module) ~1 (4.71 PLN for 5 pcs)

Voltage divider resistors (2× 100 k? THT) ~5 (for 100 pcs)

Tactile switches (12×12×7.3mm) ~15 (for 25 pcs)

PCB 2.4 GHz antenna (IPX/UFL) ~1 (4.33 PLN for 5 pcs)

Total per User Set ~160 PLN

In my case the Raspberry Pi 5 with NVMe SSD or Firebase backend is a shared infrastructure cost, scaling across all users.

Strategic Advantages (SWOT Highlights)

Hard Advantages

• Absolute Proof of Presence– Nearly impossible to spoof. The user must be physically within metres of the Car Node at the precise scheduled second.

• Offline-First Edge Computing– Zero reliance on GSM or Wi-Fi during verification. Local BLE radio only.

• Pharmaceutical-GradePrecision– External DS3231 RTC ensures wake windows are perfectly punctual and independent of the main microprocessor.

• Zero-Friction UX– No mobile app, no screens, no passwords. Just a vibrating keychain fob.

• Exceptional Power Efficiency– Microamperes in standby; 1000 mAh battery lasts through extensive duty cycles, outperforming GPS/GSM-based systems.

Ideal Use Cases

• Corporate Carpooling– Primary design target. Automatically tracks driver rotation and passenger manifests for fair cost distribution and ESG reporting.

• Security Patrol Verification– Guards must physically reach designated zones at precise times — works in parking garages and buildings with no GSM coverage.

• Critical Infrastructure & Industry– Maintenance engineers in mines, pump stations, server rooms — areas often isolated (Faraday cages).

• Healthcare & Caregiving– Proof of nurse presence at patients during strict medication dosing windows.

• Fleet & Service Vehicles– Natural extension of carpooling to police cars, technical vehicles, and any multi-crew operation.

Technical Specifications

(Parameter; Specification)

Communication; BLE 5.0 (NimBLE stack)

Frequency Band; 2.4 GHz ISM

Range; ~10-20 metres (indoor/vehicle)

Power; (Keychain) 3.7 V Li-Po, microamp standby

Power (Car Node); Vehicle 12 V ignition-switched

Power (Hub) ;USB-C 5 V

Backend Platform; Raspberry Pi 5, 8 GB RAM, 500 GB NVMe (or Firebase)

Data Storage; LittleFS (on-device), NVMe / Firestore (backend)

Time Synchronisation; NTP-> Server-> Hub-> Keychain-> Car Node

OTA Updates; Full firmware upgrade path for all nodes

Calendar auto-filled by backend logic

Dashboard

Schedule

HUB settings

LED settings

Notifications panel

Daily analytics

Keychain charge graph panel

car nodes setting

Keychains settings

Two keychain fobs and a HUB

keychain fob no case

Project Status & Call for Feedback

Current Development Stage:

All system components are fully developed and operational — including embedded firmware, backend logic, and frontend web portal. Two out of three planned production sets have been fully assembled and are currently undergoing real‑world road testing. Initial results are promising, with only minor tweaks required for email notifications related to missing calendar entries.

Third Unit Assembly:

Assembly of the third keychain fob is pending due to challenges with soldering cable connections to the very small DS3231 RTC package legs. To address this, I have designed a custom PCB interposer board for the DS3231 chip, which will simplify connections via a standard pin header socket (Conn_01x06) for cables or pins. The PCB has been ordered and is currently in manufacturing — assembly will resume upon receipt.

What I Am Sharing Today:

At this stage, I am not yet making compiled firmware files publicly available, nor do I have a ready‑to‑try demo version prepared for external testing. The system remains in active development and closed‑source commercial status.

However, I am excited to share the current design, system architecture, and technical approach with the Hackster.io community. My goal is to:

Present the engineering work completed so far
Gather feedback, insights, and constructive criticism from fellow engineers and IoT specialists
Validate the concept and identify potential improvements before moving to wider distribution

"I believe in the power of community feedback — your thoughts, questions, and suggestions will help shape the next iteration of HMTT."

Code

Implementation: StatusAdv Packet Builder (Keychain Fob Firmware)

Implementation: StatusAdv Packet Builder (Keychain Fob Firmware)

Arduino

// ============================================================
// StatusAdv: Keychain state flagging in BLE ADV packet
// Enables Hub to make connect/no-connect decisions WITHOUT connecting.
// Format: 11 bytes Manufacturer Data
//   [0-1]  Company ID: 0xFE, 0xFF
//   [2-5]  Protocol:   'H','M','T','T'
//   [6]    Type:       0x03 (StatusAdv)
//   [7]    Flags:      bitfield (HAS_LOGS, NEEDS_SYNC, SERVICE_MODE, LOW_BATTERY)
//   [8]    Battery %:  0-100
//   [9-10] BrelokHash: 16-bit FNV-1a hash of brelok_id
// ============================================================
#define STATUS_ADV_TYPE          0x03
#define STATUS_FLAG_HAS_LOGS     0x01
#define STATUS_FLAG_NEEDS_SYNC   0x02
#define STATUS_FLAG_SERVICE_MODE 0x04
#define STATUS_FLAG_LOW_BATTERY  0x08

// --- FNV-1a 16-bit hash of brelok_id ---
static uint16_t fnv1a16(const char* str) {
    uint16_t hash = 0x811C; // FNV offset basis (truncated to 16-bit)
    while (*str) {
        hash ^= (uint8_t)*str++;
        hash *= 0x0101; // FNV prime (truncated to 16-bit)
    }
    return hash;
}

// --- Build 11-byte StatusAdv payload ---
std::string buildStatusAdvPayload() {
    uint8_t flags = 0;
    if (getLogCount() > 0)                   flags |= STATUS_FLAG_HAS_LOGS;
    if (!g_syncCompleted || epochBase == 0)   flags |= STATUS_FLAG_NEEDS_SYNC;
    if (serviceMode || localServiceOverride)  flags |= STATUS_FLAG_SERVICE_MODE;
    uint8_t bat = getBatteryPercent();
    if (bat < 15 && bat > 0)                 flags |= STATUS_FLAG_LOW_BATTERY;

    uint16_t brelokHash = fnv1a16(assignedBrelokId);

    uint8_t payload[11] = {
        0xFE, 0xFF,             // Company ID
        'H', 'M', 'T', 'T',    // Protocol magic
        STATUS_ADV_TYPE,        // Type = StatusAdv
        flags,                  // Decision flags bitfield
        bat,                    // Battery percentage
        (uint8_t)(brelokHash & 0xFF),        // BrelokHash low byte
        (uint8_t)((brelokHash >> 8) & 0xFF)  // BrelokHash high byte
    };

    return std::string((char*)payload, 11);
}