Tripwire Firmware: Extending Batear with New Nodes and Relay-Aware Communication

Batear에서 확장된 Tripwire Firmware: 더 다양한 노드와 Relay-Aware 통신 실험

드론을 탐지하는 방법이라고 하면 보통 카메라나 레이더를 먼저 떠올리게 됩니다. 프로젝트 Batear는 ESP32-S3와 MEMS microphone을 이용해 드론의 회전음에서 특징적인 harmonic pattern을 찾아내는 조금 다른 접근을 보여줍니다.

이번에 살펴본 paulrenzi/tripwire-firmware는 이러한 Batear의 acoustic detection 구조와 hardware 구성을 공유하면서, 여기에 추가 hardware platform, 새로운 node role, relay를 고려한 packet structure 등을 실험적으로 확장하고 있는 repository입니다.

즉 Batear 자체의 FFT 기반 drone detection을 다시 구현하는 프로젝트라기보다는, 이미 만들어진 detection platform을 바탕으로 좀 더 다양한 형태의 분산 감지 network를 구성하려는 시도라는 점이 흥미롭습니다.

• Official Batear: https://github.com/batear-io/batear
• Tripwire Firmware: https://github.com/paulrenzi/tripwire-firmware

기본 Detection 구조는 Batear에서 이어진다

기본적인 acoustic detection 방식은 Batear와 동일한 방향입니다.

I2S MEMS microphone으로 수집한 audio를 ESP32-S3에서 분석하고, drone rotor에서 나타나는 fundamental frequency와 harmonic component를 찾습니다.

대표적으로 다음과 같은 패턴을 확인합니다.

• fundamental frequency f0
• second harmonic 2 × f0
• third harmonic 3 × f0

16 kHz로 sampling한 audio에 1024-point FFT를 적용하고, SNR과 harmonic ratio 등을 이용해 detection confidence를 계산하는 방식입니다.

Tripwire Firmware의 차별점은 이 detection algorithm 자체보다는 감지 이후의 node 구성과 communication architecture를 확장하는 부분에서 더 분명하게 나타납니다.

Seeed XIAO ESP32S3 + Wio-SX1262 지원 추가

기존 Batear에서는 Heltec WiFi LoRa 32 V3/V4가 Detector와 Gateway의 주요 hardware이고, Wired Detector에는 ESP32-S3와 W5500이 탑재된 LILYGO T-ETH-Lite S3가 사용됩니다.

Tripwire Firmware에서는 여기에:

• sdkconfig.detector_xiao
• sdkconfig.gateway_xiao

가 추가되어 있습니다.

이를 통해 Seeed XIAO ESP32S3 + Wio-SX1262 조합을 Detector와 Gateway로 사용할 수 있도록 구성했습니다.

XIAO ESP32S3는 작은 form factor를 가지고 있으며, 해당 configuration에서는 native USB Serial/JTAG을 이용해 log와 configuration console을 처리합니다.

결과적으로 동일한 LoRa detection network를 좀 더 작은 hardware에서도 구성할 수 있는 선택지가 추가된 셈입니다.

Detector와 Gateway 사이에 Listener와 Edge가 추가된다

Tripwire Firmware에서 특히 눈에 띄는 부분은 새로운 node role입니다.

기본적인 Batear 구조는 다음 세 가지 역할을 중심으로 구성됩니다.

• Detector
• Gateway
• Wired Detector

Tripwire Firmware에는 여기에:

• Listener
• Edge

라는 configuration이 추가되어 있습니다.

Listener

Listener는 Detector role을 기반으로 하면서 CONFIG_TRIPWIRE_LISTENER option을 사용합니다.

일반적인 Detector가 audio를 직접 분석하고 event를 생성하는 역할이라면, Listener라는 별도의 role을 추가함으로써 network 안에서 수신 및 중계와 관련된 다른 node 구성을 실험할 수 있는 기반을 만들고 있습니다.

Edge

Edge configuration은 source에서 다음과 같이 설명됩니다.

Batear's gateway minus Wi-Fi, MQTT and transmit

즉 기존 Gateway의 모든 기능을 사용하는 대신, LoRa packet을 수신하면서 Wi-Fi와 MQTT forwarding 기능은 제외한 보다 경량화된 edge-side node를 구성하기 위한 설정입니다.

이 부분은 단순한 Detector → Gateway 구조보다 더 많은 node를 배치하는 network architecture를 고려하고 있다는 것을 보여줍니다.

tw_codec: 별도로 분리된 Packet Layer

또 하나의 중요한 차이는 components/tw_codec입니다.

Tripwire Firmware에서는 communication packet 처리를 별도의 component로 분리하고 있습니다.

이 codec에는 다음 기능이 포함됩니다.

• Packet encode / decode
• Sender ID
• Boot counter
• Packet counter
• AES-128-GCM encryption
• Duplicate identification
• Replay protection
• Relay processing

특히 encryption에는 ESP-IDF의 PSA Crypto를 이용한 AES-128-GCM이 사용됩니다.

Packet의 nonce에는 sender ID와 boot counter, packet counter가 포함됩니다.

이 구조를 이용하면 단순히 packet을 암호화하는 것뿐 아니라, 이전에 사용된 packet이 다시 들어오는 상황도 확인할 수 있습니다.

Detection 정보도 Packet 안에 포함된다

tw_codec에서 정의하는 alert data에는 단순한 ON/OFF detection 결과보다 많은 정보가 들어갑니다.

예를 들면:

• Listener ID
• Event type
• Packet age
• Hop count
• Fundamental frequency bin
• RMS level
• Confidence
• Detection duration
• Battery information
• Temperature
• RSSI hint
• Flags

등입니다.

따라서 network의 다른 node는 단순히 “드론이 탐지됐다”는 사실뿐 아니라 어디에서 발생한 event인지, 얼마나 오래된 packet인지, 몇 번 relay되었는지, signal 상태가 어떤지까지 함께 전달받을 수 있는 구조입니다.

Relay를 고려한 통신 구조

Tripwire Firmware의 tw_codec에는 packet relay를 위한 처리도 포함되어 있습니다.

Packet이 다른 node를 거쳐 다시 전달될 경우:

• age 증가
• hops 증가
• RSSI 정보 갱신
• 새로운 nonce 생성
• AES-GCM 재암호화

와 같은 처리를 수행할 수 있습니다.

개념적으로 보면 다음과 같은 구조입니다.

Detector → Listener / Relay Node → Edge → Gateway

각 node를 통과하면서 packet의 hop과 age 정보가 갱신되고, 최종적으로 Gateway 또는 다른 network endpoint에서 event를 처리할 수 있도록 만들어진 형태입니다.

현재 repository만으로 완성된 mesh network가 실제 deployment되었다고 단정할 수는 없습니다.

하지만 최소한 code level에서는 point-to-point transmission을 넘어 relay-aware communication을 고려하고 있다는 점을 확인할 수 있습니다.

W5500 Wired Detector도 그대로 사용할 수 있다

Batear에서 사용하던 Wired Detector architecture도 Tripwire Firmware에 그대로 남아 있습니다.

Hardware는 LILYGO T-ETH-Lite S3이며:

• ESP32-S3
• WIZnet W5500
• Ethernet
• optional PoE
• I2S microphone
• microSD

구성으로 되어 있습니다.

Wired Detector는 LoRa Gateway를 거치지 않고 detection event를 Ethernet으로 직접 전달합니다.

대략적인 data flow는 다음과 같습니다.

Microphone → ESP32-S3 Detection → W5500 Ethernet → MQTT → Home Assistant

W5500은 ESP-IDF Ethernet driver를 통해 사용되며, application level의 MQTT와 TCP/IP 처리는 ESP32-S3의 network stack에서 수행됩니다.

따라서 이 프로젝트에서 W5500은 fixed installation을 위한 wired network interface 역할을 담당합니다.

PoE expansion을 함께 사용하면 network와 power를 Ethernet cable 하나로 공급할 수 있어 rooftop이나 facility perimeter 같은 고정 설치 환경에도 활용할 수 있습니다.

Official Batear와 Tripwire Firmware의 차이

두 repository의 기본 detection platform은 상당 부분 연결되어 있지만, 현재 main branch에서 확인되는 configuration에는 다음과 같은 차이가 있습니다.

따라서 Tripwire Firmware를 단순히 또 하나의 acoustic drone detector로 보기보다는, 기존 Batear detection platform에서 hardware와 node topology, packet communication을 더 확장해보는 experimental branch에 가까운 프로젝트로 보는 것이 적절해 보입니다.

왜 이 프로젝트가 흥미로운가?

개별 sensor 하나가 drone을 감지하는 데서 끝나지 않고, 여러 node가 넓은 지역에 배치되는 상황을 생각하면 communication architecture가 중요해집니다.

Tripwire Firmware에는 바로 이 부분을 고려한 흔적이 있습니다.

기존의:

Detector → Gateway

구조에서 더 나아가:

Detector → Listener → Edge → Gateway

처럼 역할을 세분화하고, packet 자체에 age, hops, RSSI hint를 넣어 중계 과정까지 추적할 수 있도록 하고 있습니다.

여기에 기존 W5500 Wired Detector를 함께 사용하면 고정 설치 지점은 Ethernet/PoE로 연결하고, cable을 설치하기 어려운 위치는 LoRa 기반 node로 구성하는 식의 다양한 topology도 검토할 수 있습니다.

아직 모든 구성이 실제 field network로 검증된 완성 제품이라고 보기는 어렵지만, 기존 acoustic detection platform을 distributed sensing network로 확장하려는 engineering 방향을 살펴볼 수 있다는 점에서 흥미로운 프로젝트입니다.

마무리

Tripwire Firmware의 시작점에는 이미 공개된 Batear acoustic drone detection platform이 있습니다.

하지만 현재 개인 repository에서는 그 기반 위에 Seeed XIAO 지원, Listener와 Edge 역할, 독립적인 tw_codec, relay-aware packet processing과 replay protection 같은 새로운 실험이 이어지고 있습니다.

특히 W5500 기반 Wired Detector까지 기존 architecture에 포함되어 있어, wireless LoRa node와 wired Ethernet node가 함께 존재할 수 있는 다양한 deployment 구조를 생각해볼 수 있습니다.

완성된 하나의 제품을 소개한다기보다는, 이미 동작하는 detection platform이 앞으로 어떤 방향으로 확장될 수 있는지를 보여주는 개발 repository라는 점에서 살펴볼 가치가 있습니다.

Tripwire Firmware: Extending Batear with New Nodes and Relay-Aware Communication

When it comes to drone detection, cameras and radar are usually the first technologies that come to mind. However, the open-source Batear project takes a different approach by using an ESP32-S3 and a MEMS microphone to detect characteristic harmonic patterns in drone rotor noise.

The paulrenzi/tripwire-firmware repository builds on that existing Batear foundation while experimenting with additional hardware platforms, new node roles, and a relay-aware packet architecture.

Rather than being another implementation of Batear's FFT-based acoustic detector, Tripwire Firmware is more interesting as an exploration of how the original platform can be expanded into a more flexible distributed sensing network.

• Official Batear: https://github.com/batear-io/batear
• Tripwire Firmware: https://github.com/paulrenzi/tripwire-firmware

The Detection Foundation Comes from Batear

The basic acoustic detection approach follows the same direction as Batear.

Audio from an I2S MEMS microphone is processed locally on the ESP32-S3, where the firmware looks for the fundamental frequency and harmonic components typically associated with rotating drone motors and propellers.

The main pattern of interest is:

• fundamental frequency f0
• second harmonic 2 × f0
• third harmonic 3 × f0

Audio is sampled at 16 kHz and processed using a 1024-point FFT. SNR, harmonic ratios, and other factors are then used to calculate a detection confidence score.

What makes Tripwire Firmware different is not the detection algorithm itself, but what happens after a detection event is generated.

The repository expands the hardware choices, node roles, and communication model around the existing detection engine.

Additional Support for Seeed XIAO ESP32S3 + Wio-SX1262

Batear primarily targets the Heltec WiFi LoRa 32 V3/V4 for Detector and Gateway roles, while the Wired Detector uses the LILYGO T-ETH-Lite S3 with W5500 Ethernet.

Tripwire Firmware adds:

• sdkconfig.detector_xiao
• sdkconfig.gateway_xiao

These configurations introduce support for the Seeed XIAO ESP32S3 + Wio-SX1262 combination.

The XIAO ESP32S3 offers a compact hardware platform, and the Tripwire configuration uses native USB Serial/JTAG for logging and configuration instead of relying on a separate UART bridge.

This creates another hardware option for building detector and gateway nodes while keeping the existing LoRa network and configuration model.

Listener and Edge Roles Extend the Original Architecture

One of the most interesting differences in Tripwire Firmware is the introduction of additional node roles.

The standard Batear architecture is mainly organized around:

• Detector
• Gateway
• Wired Detector

Tripwire Firmware adds two more configurations:

• Listener
• Edge

Listener

The Listener configuration is based on the Detector role but enables the additional:

CONFIG_TRIPWIRE_LISTENER

option.

This suggests a node intended to participate in the network differently from a standard acoustic Detector.

Rather than focusing only on generating a detection event, the role provides a foundation for experimenting with receiving, relaying, or extending coverage between nodes.

Edge

The Edge configuration is described directly in the source as:

Batear's gateway minus Wi-Fi, MQTT and transmit

In other words, it retains part of the Gateway behavior while removing the normal Wi-Fi and MQTT forwarding path.

This creates a lighter edge-side node that can receive LoRa traffic without operating as a full Batear Gateway.

The presence of Listener and Edge roles shows that the repository is exploring a topology that goes beyond a simple:

Detector → Gateway

structure.

A Separate tw_codec Packet Layer

Another major addition is the standalone:

components/tw_codec

component.

Tripwire Firmware separates packet handling into its own codec layer.

The component includes support for:

• packet encode / decode
• sender ID
• boot counter
• packet counter
• AES-128-GCM encryption
• duplicate identification
• replay protection
• relay processing

Encryption is implemented using AES-128-GCM through the ESP-IDF PSA Crypto interface.

The nonce includes the sender ID, boot counter, and packet counter.

This provides more than basic packet encryption. The receiver can also determine whether a packet is older than previously accepted traffic and reject replayed messages.

Detection Metadata Travels with the Packet

The Tripwire alert packet carries more information than a simple detected/not-detected flag.

Fields include information such as:

• listener ID
• event type
• packet age
• hop count
• fundamental-frequency bin
• RMS level
• confidence
• event duration
• battery information
• temperature
• RSSI hint
• flags

This allows other nodes in the network to understand not only that a detection occurred, but also:

where the event originated,

how old the packet is,

how many relay steps it has passed through,

and basic signal-quality information.

This is particularly useful when considering a wider distributed sensor network rather than a single detector connected directly to a gateway.

Relay-Aware Communication

The tw_codec component also contains explicit handling for packet relay.

When a packet is forwarded by another node, the implementation can update:

• age
• hops

RSSI information

and then generate a new nonce and seal the packet again using AES-GCM.

Conceptually, the network could follow a path such as:

Detector → Listener / Relay Node → Edge → Gateway

As a packet moves through the network, its age and hop count are updated before it reaches the final destination.

The current repository does not by itself prove that a complete field-deployed mesh network has been implemented.

However, the source clearly shows a relay-aware communication foundation that goes beyond a simple point-to-point alert link.

The W5500 Wired Detector Is Still Part of the Platform

The Wired Detector architecture inherited from Batear is also retained.

It uses the LILYGO T-ETH-Lite S3, which combines:

• ESP32-S3
• WIZnet W5500
• Ethernet
• optional PoE
• I2S microphone support
• microSD

The Wired Detector does not require the LoRa Gateway path.

Instead, the data flow is approximately:

Microphone → ESP32-S3 Detection → W5500 Ethernet → MQTT → Home Assistant

The W5500 is used through the ESP-IDF Ethernet driver, while application-level MQTT and TCP/IP processing run on the ESP32-S3 network stack.

In this architecture, W5500 acts as the wired Ethernet interface for fixed installations.

With optional PoE, network connectivity and power can be delivered over a single Ethernet cable, which can be useful for permanent installations such as rooftops, building perimeters, or facility monitoring points.

Official Batear vs. Tripwire Firmware

The two repositories share much of the same detection platform, but their current configurations show several meaningful differences.

Tripwire Firmware is therefore better understood as an experimental extension of the Batear detection platform rather than a separate acoustic detector built from scratch.

Why This Repository Is Interesting

Once multiple acoustic sensors are deployed over a wider area, the communication architecture becomes just as important as the detection algorithm itself.

Tripwire Firmware shows signs of exploring exactly that problem.

Instead of stopping at:

Detector → Gateway

the repository introduces the possibility of roles such as:

Detector → Listener → Edge → Gateway

The packet format also carries age, hops, and RSSI hint, allowing the system to preserve useful information while an event moves through intermediate nodes.

The existing W5500 Wired Detector can also remain part of the system, which creates the possibility of combining different installation types:

• LoRa nodes where cabling is difficult
• Ethernet/PoE nodes at fixed infrastructure locations
• intermediate Listener or Edge nodes for additional coverage

This does not mean every topology has already been fully field-validated.

Instead, the repository is valuable because it shows how an existing acoustic detection platform can evolve toward a more distributed sensing architecture.

Conclusion

Tripwire Firmware starts from an already established open-source foundation: Batear.

But the personal repository goes further by experimenting with:

• Seeed XIAO ESP32S3 support
• Listener and Edge roles
• a dedicated tw_codec
• relay-aware packet processing
• sender-based replay protection

The existing W5500 Wired Detector remains part of the architecture, providing a wired Ethernet/PoE option alongside LoRa-based nodes.

Rather than presenting a completely separate product, Tripwire Firmware is best viewed as a development repository showing how the Batear platform could be extended into a broader and more flexible distributed drone-detection network.