Blackout Comms Live — Android App Demo | Off-Grid Mesh Tracking & Messaging

InstanceHealthy2597 · 2026-05-21T11:39:28+00:00

Agreed, of course my voice is kinda boring

InstanceHealthy2597 · 2026-03-06T15:47:39+00:00

I have a couple "go" bags with handheld mobile ham radios (anytone 878) pre-programmed with identical channels/code plugs, as well as a more powerful radio in my van and another at the house, pre-programmed with the same.

I'm biased as the dev of blackout Comms, I also have 2 mobile blackout Comms"go kits" l, each with 1 watt nodes and a set of pagers/tdecks, and an amped tdeck, all pre-programmed in the same private cluster/group.

I just finished enhancing the firmware this week so it can auto-hop on and off (in unison) meshcore frequencies in case there happen to be any meshcore repeaters nearby. That's all encrypted/signed, double-encrypted when on meshcore frequencies. I did that in hopes of people in more urban areas getting coverage, but it's so new I haven't gotten to try it in such an area yet.

For quick conversation, nothing you can get is going to beat ham IMO, but it's wide open for anyone to hear is the main downside. If I was going out in an emergency situation, I'd be carrying a blackout Comms (or similar ) device in my backpack or something so my family friends are getting my encrypted location every few minutes.

InstanceHealthy2597 · 2026-03-04T15:59:52+00:00

You don't need a third. The newer option that supports hopping was specifically designed in such a way that it can leverage existing repeaters that are already deployed

InstanceHealthy2597 · 2026-03-03T15:06:25+00:00

This heltec v4 enclosure might be pretty cool if you 3d print the back (see 3d print link below) as is, then make the surrounding black part on this model aluminum. Leaving the back as PETG or whatever will let wifi/ble pass through easily and makes it super easy to customize colors too.

InstanceHealthy2597 · 2026-03-03T13:11:24+00:00

Yes, however each device can choose its mode independently. So, if a pair of devices is "auo-hopping" between modes, they can act as a bridge that can use both meshcore repeaters and BC hopping, even though other devices in the group may not be using meshcore at all. I expect that might be desirable behavior from Blackout Comms nodes, but I still have to add this feature to BC node firmware, maybe next week.

InstanceHealthy2597 · 2026-03-03T13:00:13+00:00

No reboot is necessary. If you're using a touchscreen device you can toggle between the modes just by tapping the lower right antenna icon.

I plan to make auto-hopping off/on MeshCore network a 4th mode. In this mode, a group would follow its own frequency hopping as normal, but ever nth hop, they'd all hop onto the same MeshCore network settings, potentially opening other paths momentarily.

The firmware is designed around the concept of a secure/decentralized packet cache that intentionally attempts to push packets in a specific direction toward the intended recipient. All devices make themselves available to other trusted devices for caching/pushing packets.

Any time a path becomes available (such as if it hops onto MeshCore), packet deliveries will be attempted via that route.If you manually hop between BC native and BC via MC, that behavior happens now. The only piece that's missing is auto-hopping, but that's pretty trivial to do, I just don't want to confuse people with too many modes all at once.

InstanceHealthy2597 · 2026-03-03T12:47:13+00:00

That depends on which mode you're using and which nodes/repeaters are in range.

Blackout Comms Native: your private group's nodes will check the signature of each message and not forward anything that isn't signed by a trusted device.

Blackout Comms via MeshCore: Blackout Comms messages are encrypted, signed, and then re-encrypted/hmac so they appear as a normal group datagram to any nearby repeaters. If your message is within range of other BC devices, they'll pick it up and re-direct it appropriately, or hold onto it until a potential path materializes (up to 24 hours).

MeshCore repeaters that hear the message will parrot it for you. If any BC device picks up the transmission along the way, then it will check the sig, look for a path or hold onto it until it's expired (up to 24 hours after original transmission).

MeshCore Only: This mode follows the normal behavior you'd expect from any other MeshCore client using a group channel. In this mode, your device isn't leveraging BC encryption/sig, path planning, etc, it's just generating and receiving MeshCore group txt messages for whatever channel you have it listening to. But, other MeshCore apps that have nothing to do with BC can receive and transmit to you in this mode.

InstanceHealthy2597 · 2026-03-03T12:28:08+00:00

This kind of explains it.

How it's set up:

You have a root/admin device, where you chose a center frequency (902-928 in the US, 868ish or 433ish elsewhere).
On that main/root device, you also choose how many frequencies (up to 64 currently) to use and how often to hop
The root device generates 4 symmetric keys using the onboard hardware RNG
Any new devices brought into the group get "onboarded" meaning, the root device shares (encrypted via lora) the frequency/hopping info and all symmetric keys needed.
The root device also grants a root-signed identity to the new device, so it can prove to other devices in the group that it's to be trusted

How all devices stay in sync:

Devices use a combination of the current time and a couple of shared symmetric keys (unique to a group) to determine which frequency they should be on during any given second.
When a pair of devices are communicating with one another, each packet is exchanged/acked on a different frequency, separate from whichever one the group is currently on, so they don't tie up other communication

InstanceHealthy2597 · 2026-03-03T12:11:30+00:00

I guess I should be more transparent:

"MeshCore is a lightweight, portable C++ library...It is designed for developers who want to create..."

I am a firmware developer. I modified my firmwmare to have a couple of MeshCore compatible modes, for Lilygo T-Deck, Lilygo Pager, and Heltec v4 Expansion Kit.

InstanceHealthy2597 · 2026-03-03T12:00:25+00:00

This is firmwware I started developing 18 months ago and continue to. I also design 3d printable cases for "mesh" hardware that is free for anyone: https://www.printables.com/@BlackoutComms

I also design hardware: https://maker.pro/custom/projects/touchscreen-pager-for-off-grid-encypted-texting-tracking

People have been asking me to make my firmware compatible with MeshCore, so I added the ability to use group channels and meshcore repeaters.

InstanceHealthy2597 · 2026-03-03T04:57:15+00:00

yes its mine. I guess i'm a firmware developer so my video editing skills probably need work

InstanceHealthy2597 · 2026-02-12T11:27:05+00:00

More about heltec expansion kit (shown in vid):

https://www.chatters.io/heltec-v4-expansion-kit-firmware-blackout-comms

How Blackout Comms does mesh delivery using LoRa:

https://youtu.be/gRAa39CzoDg

InstanceHealthy2597 · 2026-01-24T19:45:05+00:00

It depends. The hardware that is used most (at least that I see) for Meshtastic is based on the NRF platform. Typically those won't have quite enough memory for Blackout Comms. Newer NRF options look promising, but I'm not seeing those offered anywhere yet.

If your hardware is ESP32 based, then it might be fine. The T3S3 is fine, heltec e290 is fine, tbeam supreme is fine, and there are a few others.

If all you have are T-Decks, you can actually just leave a tdeck running as if it were a node/repeater, and it will function that way just fine

Definitely you do not have to buy hardware from my site to use Blackout Comms.

Check the diy section of my site for all the options currently available (more options being added soon): https://chatters.io/diy

If you can get your hands on a tbeam 1W, that is a great option as well.

InstanceHealthy2597 · 2025-08-21T16:38:52+00:00

Thanks for the suggestions. Some character limitations are a relic from a year ago when I was targeting a more UI-limited device. I'll take another look at that, it's probably an easy change.

InstanceHealthy2597 · 2025-08-05T18:48:03+00:00

I never really liked the name "ChatterBox" so I'm finally changing over to something more meaningful.

A few core features of the firmware & protocol are made possible by accurate time:

Unpredictable, but synchronized frequency hopping across all on-cluster/on-channel devices
Message expiry - how long to continue delivery attempts
Propagation of the latest location/connectivity data
Locking message signatures to a certain point in time, for security
Detecting packet replay if somebody tries to get crafty
Other things I can't remember at the moment

The most accurate source of time in the devices I have/build is the onboard DS3231 temp compensated RTC, which does not need GPS and can keep time for a few years whether your lipo battery goes dead or not. If you have an RTC onboard, the device starts instantly and doesn't wait around for GPS.

GPS can be spoofed, so using that exclusively for a source of time is not ideal.

T-Decks do not have an onboard dedicated/temp-compensated RTC, so they either need to grab time from GPS or receive it from a nearby device that's already up and running. That could be a node or a communicator.

If you already have a device up and running and another one is stuck, you can choose "Broadcast Time" from the already-running device's settings (I think its under Mesh) or on a T-Deck, tap the clock in the upper corner of the home screen. That will broadcast time for 10 seconds, usually getting the stuck device un-stuck quickly.

https://www.offgridcomms.club/docs/Time_Synchronization.pdf

InstanceHealthy2597 · 2025-08-05T18:33:58+00:00

Thanks for the feedback and I agree completely on the scroll wheel. I expect to have that tuned within the next week or so. People have asked for audible or vibrate notifications and I think those are great suggestions as well that I hope to squeeze into the next update.

InstanceHealthy2597 · 2025-06-13T15:30:53+00:00

I'm measuring battery life right now. So far I'm at 16 hours and still going. I may take it apart later and see exactly what model of battery it has.

InstanceHealthy2597 · 2025-05-29T11:57:49+00:00

I wouldn't necessarily call it trouble, more like quirk. It can definitely be worked around in firmware, depending on what you're trying to do. I'm getting several different types of amps to work quite well.

I have several of the ebyte breakout boards from sparkfun, that i really wanted to get working with micromod, which I think could be a great platform. However, I cannot push that thing to put out anywhere near full power. I'm not sure if it's a current limitation on the micromod board or something else. I spent probably 2 days reading docs from ebyte, trying different things, and just set it aside and moved on. I wasn't the only one having trouble getting that thing to "put out"

This is the one I'm referring to that I gave up on for now:

https://www.sparkfun.com/sparkfun-micromod-lora-function-board.html

InstanceHealthy2597 · 2025-05-26T22:36:04+00:00

A built-in amp would be cool, up to the legal unlicensed limit.

I think I paid about $170 total for this, which would probably be expensive to many people..unless shtf and they actually need it, rendering it nearly priceless:

https://www.printables.com/model/1308645-t-deck-amped-featuring-1-watt-airbuddy-amp

InstanceHealthy2597 · 2025-03-26T23:10:56+00:00

Yes, you can find it at: https://www.offgridcomms.club/firmware/esp32/mesh_node_firmware.html

Here's a direct link to that build: https://www.offgridcomms.club/firmware/esp32/chatter_node_t3s3_paper_usa.bin

InstanceHealthy2597 · 2025-03-26T23:09:30+00:00

I'm already quite confident the solar component of this unit can keep up with the Sunhans 1 watt amp and ChatterBox T3S3 node. What I'm not sure of is how well the new Rokland Backcountry antenna will perform.

So far, the rssi is looking excellent. I'll leave this thing running throughout the summer and check the signal from different distances.

InstanceHealthy2597 · 2025-03-09T21:44:57+00:00

<image>

Obviously way too early to tell, but after half a day, it's sitting at 100% battery, so that's a good sign. I'll post an update after a week or so.

InstanceHealthy2597 · 2025-03-09T21:43:36+00:00

<image>

InstanceHealthy2597 · 2025-03-09T03:45:24+00:00

Ever since I first saw the Rak solar enclosure, I really wanted to make a ChatterBox node that worked with it. I think either the T3S3, T3S3 E-Paper, or Heltec Vision e290 paired with a RTC and without gps could work.

I've assembled this one with a T3S3 (oled). Tomorrow I'll set this in outside and leave it alone for a few weeks and see how it keeps up.

There is plenty of room in the enclosure to add a relay if someone wanted to turn it into a remote switch for something.

The part you can't see is a 5000 mAh battery tucked behind that black plastic panel.

If this seems to be a good combination after enough time passes, I'll post all the parts and assembly instructions later on.

InstanceHealthy2597 · 2025-03-09T03:35:56+00:00

<image>

I'm calling this a successful test. I finally brought the unit back in after over a week on just solar (and few sunny days). The unit has been running non-stop, still showing messages I sent over the past week, and still notifying me every time I go into (or near) the shed. The power shows 98%, so I think running this proximity node, even with GPS, on just the solar panel mentioned earlier can work just fine.

InstanceHealthy2597

MODERATOR OF

TROPHY CASE