🚀 Brainstorming & Future Roadmap: Meshtastic, Offline Networks, and TinyML

[TN666]

🚀 Brainstorming & Future Roadmap: Meshtastic, Offline Networks, and TinyML

Welcome everyone! 👋

Thanks to the recent features on Hackaday and Hacker News, we’ve had a massive influx of amazing ideas from the community. Batear is currently a solid, $15 flashable baseline using the Goertzel algorithm, but this is just the beginning.

I’m opening this thread to centralize all the great ideas for the future roadmap. If you want to contribute, build a bridge, or just share what you are testing, this is the place!

🔥 Top 3 Directions We Are Exploring:

1. 📻 Offline Alerting & Mesh Networks (Meshtastic / LoRa)

• The Goal: When the ESP32 detects a drone, it shouldn't just print to serial—it should warn the neighborhood even if cell towers are down.
• The Idea: Integrating Batear with Meshtastic. We could use the ESP32's UART to send a simple text payload (e.g., ⚠️ Batear Node 1: Drone Detected!) to a connected Meshtastic LoRa node.
• Looking for: Anyone familiar with the Meshtastic Serial API to help write a lightweight bridge or plugin.

2. 🌬️ Environmental Noise & Hardware Mods

• The Goal: Reduce false positives from wind, cars, and lawnmowers.
• The Idea: The Hackaday article mentioned using a "foam sock" or a physical acoustic amplifier (like a parabolic dish or "war tuba" cone) to improve directionality and block wind.
• Looking for: 3D printing enthusiasts to design snap-on acoustic cones for the ICS-43434 mic, and folks who can test the thresholds outdoors in windy conditions.

3. 🧠 TinyML / ESP-NN Upgrades

• The Goal: Move beyond static Goertzel frequency bins to recognize complex acoustic signatures.
• The Idea: Train a lightweight TensorFlow Lite Micro model that can classify drone rotors vs. background noise, while still fitting inside the ESP32-S3's SRAM and running locally.
• Looking for: ML engineers who want to help build an audio dataset (DJI, FPV, ambient noise) and train the first edge model.

---

🤝 How to get involved:
If you have an ESP32 and a micro-drone, please share your real-world test results below! Let me know what your cal: active=N/6 output looks like when the drone is hovering vs. flying aggressively.

Let's build a world where no one needs to fear the sky. 🦇 Drop your thoughts, links, and experiments below! 👇

[robinsandfort]

What a great project!
I´m flying drones for conservation projects myself but I`m also involved
in monitoring and protecting conservation areas like nationalparks and
sensitive areas like nest sites of breeding raptors (like eagles) from illegal drone activity and disturbance.
This would be a great use case with long range Lora connection (I already build and use a TTN network in the parc.
Greetings from the woods,
Robin

[TN666]

Hi @robinsandfort, That would be incredible! Having specific recordings for the Mini 4 Pro and Mavic Pro at varying heights and speeds is exactly what I need for the next stage of validation.

I have some solid benchmark data to share from the ESP32-S3:

Sample rate : 16000 Hz
[Goertzel]  6 bins x 512 samples :   0.2 us  (0.000 ms)
[FFT-512]   512-pt complex          :  263.6 us  (0.264 ms)
[FFT-1024]  1024-pt complex      : 564.4 us  (0.564 ms)

--- Analysis ---
- Time to collect 1024 samples: 64,000 us (64 ms)
- Time to process 1024-pt FFT: 564.4 us
- CPU Overhead: ~0.88%
=====================================================

Even though the FFT is computationally heavier than my previous Goertzel implementation, it only consumes about 0.88% of the CPU cycle. This massive headroom allows Batear to analyze the entire spectrum in real-time without dropping any I2S frames.

With this efficiency, your proposed recordings will be the "Golden Dataset" for calibrating multi-harmonic detection. This is key to distinguishing DJI motor signatures from birds or wind noise in the woods.

Please go ahead with the recordings whenever you can. Can't wait to feed them into the new v1.2.0 engine!

Best,

TN

[robinsandfort]

Would it make sense to record with the same / similar microphone
setup? It is rainy and stormy here right now, we will have to wait.
Greetings from the woods, Robin

[TN666]

Hi @robinsandfort

Safety first—please do NOT fly in the rain! We definitely don't want to risk any damage to your DJI gear.

Regarding the microphone: Any setup is fine. Using different hardware (phone, recorder, etc.) actually helps me test the robustness of the FFT engine and ensures it's not "overfitted" to one specific device.

We can wait for a clear, dry day for the actual flight recordings. Stay dry and safe!

Best,
TN

[robinsandfort]

Hi @TN666,
I do have some audio files from an experiment.
I hung an audiorekorder (mini version of audiomoth) under
my DJI mavic pro. 3-4 meters of rope between the drone and the recorder.
My aim was to record bats from above with the recorder hanging below.

The higher frequency signal are echo location calls from our local bats and you can see the low noise bed of the drone.
The recordings are quite noisy but maybe helpful?

[TN666]

Hi @robinsandfort

This is incredible data! The separation you've captured between the Mavic Pro’s low-frequency motor noise and the high-frequency bat echolocation pulses is exactly the kind of 'edge case' we need to stress-test our DSP pipeline. 3-4 meters of rope was a very smart move to isolate structural vibrations.

To manage these high-fidelity recordings professionally without bloating our firmware source code, I’ve just launched a dedicated research repository:

👉 batear-io/batear-datasets

I have configured this new repo with Git LFS (Large File Storage) to handle raw .wav files. I would like to formally invite you to contribute these samples to our field-tests/mavic-series/ folder.

Your Mavic Pro recordings will become our 'Gold Standard' for:

Benchmark Testing: Validating our FFT binning accuracy in noisy environments.

Filter Optimization: Fine-tuning our High-Pass Filters to isolate biological signals from mechanical noise.

Downsampling Research: Testing how these signals behave when decimated to our 16kHz production target.

Would you be interested in uploading the raw files there? I can add you as a contributor to the organization so you can manage the data directly in the lab.

Looking forward to your high-res 'bat-detection' insights!"

[Clo363]

Here is a potentially life-saving feature idea from a real-world use case in Ukraine.

We are constantly attacked by Shahed-136 drones, and because alerts happen so frequently, people often cannot realistically run to shelters for every single warning. What would help enormously is distinguishing between a drone that is merely passing nearby and one that is actually flying toward your location.

Would it be possible to add directional tracking / trajectory estimation for Shahed-type acoustic signatures?

The drone has a very distinctive sound — similar to a very loud 2-stroke trimmer engine. In practice, we can often hear it clearly at roughly 3 km distance or closer.

Some ideas that might make this feasible:

• A microphone array could estimate bearing and track movement over time
• A distributed mesh of low-cost LoRa-connected microphones could triangulate direction and trajectory
• Since the drone speed is relatively constant (~185 km/h except during terminal dive), prediction algorithms may work well
• The target is usually significantly above ambient noise level
• The sound signature is easy to emulate for testing using a 2-stroke trimmer at high RPM

Even approximate “moving toward you / moving away / passing sideways” classification could greatly improve civilian response decisions and reduce alert fatigue.

[TN666]

@Clo363 Thank you for this — the real-world context is exactly the kind of feedback that shapes priorities.

Of the three approaches you outlined, single-node Doppler trend analysis looks like the most realistic path on existing hardware: track the dominant harmonic's frequency drift over a few seconds and classify approaching / receding / passing. It directly addresses the alert-fatigue problem without adding microphones or relying on mesh timing.

Microphone arrays would push BOM and enclosure complexity beyond batear's low-cost positioning, and LoRa's packet latency (hundreds of ms) is too coarse for TDOA triangulation in real time — so those two are unlikely for the mainline firmware, though mesh coordination is being tracked separately in #51.

I'll prototype the Doppler approach offline first and open a tracking issue once I have something to validate. If you have any Shahed recordings you can share, even phone-quality, that would help enormously. Stay safe.

[Clo363]

Thanks for the reply! Take into account that drones are sent in multiples, so there are several at once in the air. Regarding microphones array wont a local 4 analogue microphones do the trick? Spread apart and have some auto position calibration on a clap. If its a LoRa mesh a GPS for expre prescice time would be needed, not to rely on signal latancy. Register distinct sound + exact time + moving to/away could allow real positioning with enough nodes (it seems military uses something like this, but they dont share exact location with civil population).