Skip to content

Cattle Tracking Initiative: Edge Processing & Hardware Requirements

1. Context and Architectural Role

The Leader Node (Collar) in our Two-Tier architecture is not merely a transparent bridge; it operates as the intelligence center for a local cluster. It must manage the local Sub-GHz/LoRa network, aggregate data, process raw telemetry to extract actionable insights, and handle sporadic, expensive NTN satellite uplinks.

This document defines the baseline processing and storage requirements for hardware partners (e.g., Gosuncn, Softgent) evaluating the design of the Leader Node.

2. Scalability and Network Topology

  • Maximum Herd Density: The hardware must support managing up to 500 Member Nodes (Ear Tags) concurrently per Leader Node.
  • Local Network MAC: The Leader Node must process a star or mesh topology, handling synchronization, scheduled wake-ups (Wake-on-Radio), collision avoidance, and asynchronous alert listening from all 500 members.

3. Processing Requirements (MCU Selection)

Given the constraint of a 1-year replaceable battery lifespan for the Leader Node, using a high-power MPU (e.g., Cortex-A running Linux) is strictly unviable. We require an advanced Microcontroller Unit (MCU).

Key Processing Tasks

  1. Operating System: The MCU must be capable of running Zephyr RTOS efficiently to manage our multithreaded edge logic.
  2. Edge Logic (TinyML & Telemetry Processing): The node must process incoming accelerometer data streams from the 500 tags to detect anomalies (estrus, sickness, predator attacks, or escaping behavior) without relying on cloud servers.
  3. Data Compression: It must drastically filter and compress raw telemetry into highly optimized payloads to minimize NTN data costs ($1/KB).
  4. Relative Positioning (Optional): If GPS on member tags is removed for cost/power saving, the MCU must handle the mathematical overhead of RSSI or AoA positioning calculations.

Target Architecture

  • Family: We do not mandate a specific processor class (e.g., locking into Cortex-M33). We expect partners to propose the most cost-effective and available MCU that meets the capabilities listed below, prioritizing native Zephyr RTOS support.
  • Features: Must include a Floating-Point Unit (FPU) or DSP instruction set for efficient math and sensor processing.
  • Clock Speed: Expected operation between 64MHz and 240MHz (e.g., nRF52/nRF53 series, STM32L4/U5 series, ESP32-S3).

4. Storage Requirements (Memory Sizing)

The Leader Node requires sufficient external Flash memory to handle two primary scenarios: Satellite orbital blind spots and Firmware Over-The-Air (FOTA) updates.

Data Caching Calculation

  • Throughput: 500 nodes × 4 heartbeats/hour × 24 hours = 48,000 messages/day.
  • Payload: Assuming an average of 20 bytes per log (Node ID, timestamp, battery, temp, accel summary).
  • Daily Storage: ~960 KB/day (~1 MB/day).
  • Blind Spot Buffer: To ensure zero data loss during extreme weather or satellite unavailability, the node must cache at least 5 days of raw logs (~5 MB).

Total Flash Requirement

  • Data Cache: ~5 MB
  • FOTA Image Buffer (Zephyr + Application): ~2 MB
  • Recommended Hardware: A dedicated 8 MB to 16 MB SPI NOR Flash chip. This provides ample headroom, costs pennies at scale, and consumes negligible power in deep sleep.

5. Firmware Architecture & SDK Strategy

To maintain absolute control over our intellectual property and edge intelligence, we will not outsource the final application logic to the hardware partner. * Requirement: The hardware partner must provide a stable, low-level C/C++ SDK natively integrated with Zephyr RTOS. * Workflow: The partner is responsible for the board support package (BSP), hardware drivers, and providing a functional, simple template application. Our internal team will use this template and the provided SDK to write, compile, and deploy the final application firmware.

6. Data Compression & Payload Strategy

Given the drastic cost difference between satellite and terrestrial networks, the application logic will feature dynamic payload optimization. * NTN (Satellite) Mode: When out of cellular range, the system will compress the daily summary of 500 cows into highly optimized bitmaps and minimal binary structs. No raw strings or JSON will be transmitted. * Terrestrial Mode (LTE/NB-IoT): When the herd is within range of a cheap terrestrial network (e.g., near farm HQ), the system will switch to sending the full, uncompressed data logs.

7. Edge Algorithms & TinyML

The specific algorithms used to detect estrus, disease, or predatory panic are not fixed. They will evolve continuously based on real-world usage patterns and feedback from ranchers. * Requirement: The most critical aspect of the Edge Processing layer is the ability to execute arbitrary algorithms that can be seamlessly updated over the air (FOTA) over time. * TinyML: Deploying pre-trained TinyML models (e.g., via Edge Impulse) directly onto the Zephyr RTOS is a primary target for classifying complex accelerometer patterns without cloud intervention.

8. Summary for Hardware Partners

When proposing hardware architectures, ODM/OEM partners should target: 1. Processor: A capable MCU with FPU/DSP instruction sets and native Zephyr RTOS support, optimized for low-power operations. 2. Memory: 8-16 MB External SPI NOR Flash. 3. Concurrency: Hardware and MAC capability to manage up to 500 concurrent LoRa/Sub-GHz endpoints.