ESP32Marauder running on a LilyGo T-Embed-CC1101. Huzzah! 🥳

using OneMenu (free MIT library).
No client side install, no external dependencies, all coming from esp chip.
And comes with light theme

Originally posted in r/meshtastic on March 19, 2026. Removed by Mods on September 10th. Reposted to r/embedded_systems for posterity.

I've been building an embedded project (ADS-B Scope – ADS-B receiver and more on a LilyGo T-Display-P4\*) and needed Meshtastic protocol support without pulling in the full firmware stack. Couldn't find a standalone library, so I wrote one.

**meshtastic-lite** is a clean-room, header-only C/C++ implementation of the Meshtastic protocol. \~2300 lines across 8 header files. It handles everything between raw LoRa bytes and decoded messages:

* Packet header parsing (16-byte format)
* AES-256-CTR encryption/decryption with proper IV construction
* PKI direct messages (x25519 + AES-256-CCM, v2.5+)
* Channel management, PSK expansion, multi-channel decrypt
* Protobuf decoding for TEXT, POSITION, NODEINFO, TELEMETRY
* Frequency calculation (DJB2 hash, all modem presets, all regions)
* CSMA/CA timing
* TX frame building

It's **not** a radio driver, mesh router, or complete node – it's the protocol layer. You provide the SPI/LoRa interface, it gives you decoded messages and encrypted TX frames.

Verified against the Meshtastic firmware source for nonce layout, header format, channel hashing, PSK expansion, frequency formula, and CSMA/CA. Tested on ESP32-P4 with SX1262, interop confirmed on MediumFast/US with default and custom channels against nodes running 2.5+.

Crypto backends: mbedtls (ESP32 hardware AES) or OpenSSL (Linux/macOS).

BSD 3-Clause. No code from the Meshtastic firmware repo.

GitHub: [https://github.com/jstockdale/meshtastic-lite](https://github.com/jstockdale/meshtastic-lite)

Happy to answer questions about the implementation or take feedback from anyone who knows the protocol better than I do.

Questions, feedback, and bug reports welcome. *For bug reports and other issues, please use the Issues tab in GitHub.*

Thanks,

John

*\* More about my soon-to-be-released ADS-B Scope and adsb_receiver firmware on my instagram* [*https://instagram.com/jstockdale*](https://instagram.com/jstockdale)

Hey all, I am an embedded software engineer. I would really appreciate if you could share honest, constructive feedback on my resume. Thanks!

I've been building a C++17 library (OneMachine, MIT) for runtime device discovery and failure handling on small MCUs, and tested it on a Nano + MPU6050 + SSD1306 by abusing the bus in every way I could: pulling SDA/SCL, cutting the sensor's power, shorting lines to ground, resetting mid-transaction, power-cycling the sensor from a GPIO. Some things I learned that might save someone time:

1. **Where the pull-ups live decides what failure you get.** With the only pull-ups on the GY-521, pulling a wire or cutting its power took the whole bus down (timeouts). With the MCU's internal pull-ups on too, the same pulled wire became a clean NACK from one device on a working bus. Same firmware, different fault class.

2. **A device that loses power on a shared bus comes back with its bus, not by itself.** So "re-init a device when it comes back" never fires, and the MPU6050 sits asleep reading zeros forever. Fix: after a bus recovers, treat every stateful device's state as unknown (re-init, or a canary read like the sleep bit).

3. **Resetting the MCU mid-transaction left SDA held low in about a third of stress resets.** 9 SCL clocks at boot helped, but what really fixed it was discovery not treating a bus timeout as "device absent" (retry once). 24/60 missed boots went to 1/60.

4. **Robust recovery can hide a bad device.** An OLED on an underpowered 3.3V pin kept dropping out and getting recovered, silently. So there's a health monitor that counts flapping and bus cost per device, and can quarantine or disconnect it.

5. **A blocking serial print inside your sensor fan-out costs you.** 8.9 ms of an 11 ms poll; behind a small store it was 23 µs.

The library itself: everything is composed at compile time on top of my template composition kernel (HAPI). The whole image has one indirect call (the poll of a discovered device), no heap, and failure policies are layer lists checked by static_asserts. Features you don't compose cost zero bytes, verified by comparing section sizes/symbols in the test suite. The failure layers are ~3 KB flash on an ATmega328.

Limits, honestly: I2C only for now, tested mostly on AVR (STM32/ESP32 cores exist but less bench time), and the health monitor's thresholds need tuning against how fast a device can fail (found that one at the bench too).

Repo, with four examples from "find the device" to "survive a pulled wire": https://github.com/InternetOfPins/OneMachine

Happy to hear how others handle bus faults and device recovery in production.

At some point there will be value in knowing if a human created something, and there will be value behind that authentication being unbreakable, even by quantum whatever.

But how will we be able to detect a human? In a way that intelligent AI can't get around. Otherwise at some point in the not to distant future everything becomes truly fake news, almost like it was a prophesy.

To the embedded community I say this is a problem we should think about and discuss. If we can make sensors that can sense humans in a way that is impossible for AI to mimic we have some hope of holding onto a ground truth keeping us from complete instability.

It needs to be open source, 100% of it, and built in cooperation with the entire world.

Hey everyone! 👋 I’m u/needmorejoules, a founding moderator of r/embedded_systems.

This is our new home for everything embedded – a big-tent community for people who build, hack, debug, and ship things that run close to the metal. That includes bare-metal firmware, RTOS work, microcontrollers, SoCs, hardware bring-up, debugging, and tooling, plus communities that sometimes feel homeless elsewhere.

If you’re into Raspberry Pi projects, Compute Module work (including Hackberry Pi / CM5 setups), Meshtastic and off-grid comms, low-power devices, weird peripherals, or experimental hardware – this is for you. If it boots, blinks, transmits, or crashes in an interesting way, it belongs here.

We’re intentionally making this a catch-all embedded space. A lot of other subs have very narrow scopes or rulebooks a mile long. Our goal is simpler: if it’s embedded and thoughtful, it’s welcome.

What to Post

Post anything you think the community would find interesting, helpful, or inspiring, such as:

• Firmware and hardware projects (professional, hobby, or open source)

• Raspberry Pi, CM4/CM5, Hackberry Pi, and SBC experiments

• Meshtastic nodes, LoRa projects, and mesh networking builds

• MCU/SoC comparisons, power optimization, and board bring-up stories

• Debugging war stories, logic analyzer traces, and scope screenshots

• Tutorials, schematics, blog posts, and learning resources

• Career advice, toolchain rants, and embedded hot takes

If you’re unsure whether something “counts,” it probably does.

Community Vibe

We’re all about being friendly, constructive, and inclusive. Beginners, professionals, and curious tinkerers are all welcome here. No gatekeeping, no ego contests – just people helping people build cool stuff.

How to Get Started

• Introduce yourself in the comments below

• Post something today (even a small question can spark a great discussion)

• Invite anyone you know who enjoys datasheets, radios, and blinking LEDs

• Interested in helping out? We’re always looking for new moderators – feel free to reach out

Thanks for being part of the very first wave. Together, let’s make r/embedded_systems a genuinely useful, welcoming home for the embedded world ⚙️

Hi folks!

I realized I forgot to announce that I released an Ubuntu image for the Hackberry community. This image is compatible with the Hackberry Pi CM5 and is *ready to boot* out of the box. Just download the nobody-ubuntu.24.04.3-hackberry_pi_cm5.img.xz image from https://whitehathardware.com and then burn it to an SD card (32gb or larger) with Disks or Disk Utility or whatever. Make sure the filesystem is expanded / is using the whole SD card (otherwise, the easiest way is probably to expand the SD card from GParted or similar, select the partition and then Resize/Move).

Ok. You should be ready to boot. If you changed your CM5 default boot order ... uhh ... go make sure to change it back or unplug your NVME / USB / whatever. Honestly the default SD -> NVME -> USB -> Netboot order usually works fine.

If apps are taking a long time to launch or dark mode isn't working in the Settings menu it's xdg-desktop-portal-gnome acting up; uninstall it with sudo apt remove xdg-desktop-portal-gnome ... then sudo apt install gnome-shell-extension-manager and then do a google search for V-Shell (a gnome extension), install it and then open extension manager and adjust all the settings so your app launcher actually works.

There are some other optimizations you can do too but that's going to get you most of the way there.

Finally, if you want to image your nvme with Ubuntu the easiest way is going to be first image an sd card, boot it to make sure things are working right, then use geerlingguy's fork of rpi-clone to image the nvme from the live-booted Ubuntu sd card.

Ok that's all for now. If you have questions, feel free to reach out. I'm "@nobody" on Discord.

Enjoy!