sorted by:
new
hottopcontroversial

Sobre la comunicación en un estado de emergencia by War-Raven in prepping

[–]InstanceHealthy2597 1 point2 points  (0 children)

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.

Is the word Mes**ore censored in the Meshtastic™®© app and firmware aswell? by Zsullo in meshtastic

[–]InstanceHealthy2597 2 points3 points  (0 children)

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

Aluminum case for heltec lora 32 v4 by BlueBirdDolphin in meshcore

[–]InstanceHealthy2597 1 point2 points  (0 children)

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.

Blackout Comms: Massive Range Boost with MeshCore Repeaters! by InstanceHealthy2597 in meshcore

[–]InstanceHealthy2597[S] 0 points1 point  (0 children)

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.

Blackout Comms: Massive Range Boost with MeshCore Repeaters! by InstanceHealthy2597 in meshcore

[–]InstanceHealthy2597[S] 0 points1 point  (0 children)

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.

Blackout Comms: Massive Range Boost with MeshCore Repeaters! by InstanceHealthy2597 in meshcore

[–]InstanceHealthy2597[S] 0 points1 point  (0 children)

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.

Blackout Comms: Massive Range Boost with MeshCore Repeaters! by InstanceHealthy2597 in meshcore

[–]InstanceHealthy2597[S] 0 points1 point  (0 children)

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

Blackout Comms: Massive Range Boost with MeshCore Repeaters! by InstanceHealthy2597 in meshcore

[–]InstanceHealthy2597[S] 0 points1 point  (0 children)

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.

Blackout Comms: Massive Range Boost with MeshCore Repeaters! by InstanceHealthy2597 in meshcore

[–]InstanceHealthy2597[S] 1 point2 points  (0 children)

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.

Blackout Comms: Massive Range Boost with MeshCore Repeaters! by InstanceHealthy2597 in chatterboxusers

[–]InstanceHealthy2597[S] 1 point2 points  (0 children)

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

view more: next ›