redgridtactical

Most of the conversation around counter-drone is about the defeat side but honestly the bigger problem is coordination. If you have a drone sighting, how do you actually tell someone else exactly where it is?

Thank you!

Yeah exactly. Apple has a history of quietly changing undocumented behavior between point releases. Building on top of that is asking for a fun debugging session six months from now. The GATT handshake adds a couple seconds of latency on reconnect but at least I know it won't break with iOS 19.

Nice list, thanks. Meshtastic bridge is on the V2.0 roadmap so the app can route through LoRa hardware for multi-kilometer range. Being able to detect and pair with these devices over BLE is exactly how I'd want the integration to work.

Yes, definitely as a fallback! Currently working on a new build. If you are interested in testing please see the following link to become a tester!

https://play.google.com/apps/testing/com.redgrid.red_grid_li...

Hadn't seen that repo, really interesting find. Using undocumented Continuity fields for discovery is tempting but I wouldn't want to build on something Apple could break in any iOS update. I'm doing a GATT characteristic handshake with a session-derived service UUID for re-identification after address rotations. Takes a couple extra seconds on reconnect but at least it's stable. Those Continuity protocol docs are useful regardless though, good to understand what Apple is doing under the hood.

Good call, I've looked at Meshtastic's approach. They use CoreBluetooth on iOS with a known GATT service UUID for discovery, which is basically what I'm doing now. The main difference is they're discovering LoRa radios (which have fixed BLE addresses) rather than other phones. Phone-to-phone is trickier because iOS rotates the BLE address every ~15 minutes for privacy, so you can't really rely on address-based reconnection. You end up needing to encode enough identity into the GATT characteristics that peers can re-identify each other after an address rotation. Curious to see if anyone's found a cleaner approach for that.

Apologies for posting the incorrect link to the Red Grid MGRS test. Below is the corrected link, thank you for bringing that to my attention!

https://play.google.com/apps/testing/com.redgrid.red_grid_li...

If anyone is interested in testing the Android versions, please use the following link:

https://play.google.com/apps/testing/com.redgrid.redgridtact...

I welcome all feedback. My goal with this app is to make something I myself want to use. Hopefully it becomes that for you all as well!

You're right, I was wrong about iOS 17 auto-negotiating Coded PHY. After digging deeper, Apple did support it briefly in iOS 13.4 betas but pulled it in iOS 14 and it hasn't returned. CoreBluetooth still doesn't expose PHY selection at all. The iPhone hardware supports it but the OS won't use it. So BLE Long Range is going to be Android-only for now. I've updated the roadmap to reflect that.

For the time being yes, I am looking for Android testers (need 12 to publish and I am a solo dev), if you are interested please reach out!

Thanks you! Just started working on this project based on systems I use, and have gripes with, in the military. No plans to abandon it, but I understand your concern. This is the project I actually want to use myself so it's going to keep getting built.

1.Your tier determines your own device limit. If you have Pro+Link (8 devices), you can host a session with 8 people. The people joining don't need Pro+Link, they just need the free version with Field Link support (which covers 2 devices). So the session creator's tier sets the ceiling, not the lowest paying member. 2.Not yet, but it's open source so you can build from source and verify. Reproducible builds are something I'd like to get to but haven't prioritized over features yet. Fair ask though. 3.Good catch. AirDrop is just one option in the iOS share sheet for AAR exports. On Android it'll use the native share intent, so whatever sharing apps you have installed (email, Drive, Nearby Share, etc). The session export is just a JSON file so it works over any transfer method. I have put off building out the Android version for now because as a solo dev I need 12 testers before I can submit to the Play Store. If you are interested, or know anyone that is, please reach out! Would love to get testers for the Android version going! 4.That's an interesting idea. Something like a "source license" tier where you get build access and can self-host updates if the project goes dark. I'll think about that. The MIT + Commons Clause license already lets you build from source for personal use, but a paid tier with commercial self-build rights could make sense for teams that need that guarantee. 5.Good catch, the correct link is https://github.com/RedGridTactical/RedGridMGRS. Must be a typo somewhere, I'll fix it. 6.Yes, OpenStreetMap is actually what the offline maps use under the hood already. The tile sources are OpenTopoMap (which is built on OSM data) and USGS Topo. Adding more tile sources including vanilla OSM is on the list! 7.I hadn't seen fixphrase before, that's interesting. what3words has licensing issues that make it hard to integrate into open source projects, but an open alternative like that could work. I'll look into it. The main concern would be making sure it works fully offline since the whole point is no network dependency.

I appreciate all the feedback!

If you ever do get the chance to use, let me know what you think!

All true, but the tradeoff is zero additional hardware cost and zero setup. For a family hike, small team, or a hunting party staying within a few hundred meters of each other, pulling out your phones beats buying and configuring radios for everyone.

That said, BLE Long Range (Coded PHY) pushes it to 400m-1km and is on the roadmap for the next version. I'm also planning a Meshtastic bridge so if you already own LoRa hardware, the app can route through it for multi-kilometer range. Best of both worlds: works without hardware, works better with it. Would love some feedback if you ever try it out!

Yeah iOS supports BLE Coded PHY since the iPhone 12 / iOS 14. The tricky part is negotiating it at the library level. flutter_blue_plus doesn't fully expose Coded PHY yet so I'd need to handle it through platform channels on both sides. It's on my list though, the range improvement would be significant!

Thank you! Would love some feedback if you try it out!

There's haptic feedback when a peer connects or disconnects, and the ghost marker system gives you a visual alert when someone drops off the grid. Battery wise, there's an Ultra Expedition mode that drops BLE updates to once every 60 seconds and keeps drain under 2% per hour. In normal active mode it's more like 5 second intervals, so heavier on battery but way more responsive. You pick the mode based on how long you'll be out.

BLE Coded PHY is on my radar. The theoretical range boost is huge, something like 4x over standard in ideal conditions. The challenge right now is that flutter_blue_plus (the BLE library I'm using) has limited support for negotiating Coded PHY, and both devices need to support it. But phone hardware has been shipping with it since around 2020 so the install base is there. Definitely something I want to add, probably as an automatic upgrade when both peers support it.

Haha fair point. In open terrain you get maybe 50-100m which I agree, not far. In practice it's more useful than it sounds though. You don't need miles of range when the point is "where did my buddy go 5 minutes ago." And if they walk out of range their last position and heading stick on your map as a ghost marker so you're not totally blind or left guessing.

Thanks, yeah the ghost markers ended up being one of those features that came out of necessity. Once I accepted that the BLE range was never going to be amazing, the question became what happens when someone drops off? Felt wrong to just remove them from the map.

Definitely was one of the use cases I designed around!

It's not long range by any stretch. The use case is more "my group split up on a trail and I want to know which fork they took" vs "track someone across a mountain." The ghost marker system helps here too. If someone walks out of range, their last known position and direction stays on your map, so you at least know where they're heading and how long ago they traveled that direction.

Meshtastic is great if you're willing to carry extra hardware. Everyone in your group needs a LoRa radio (which can range from $30-50 each), and you need to pair them, flash the firmware, configure channels, etc. For a SAR team or preppers who already own the gear, it's definitely a solid choice.

Red Grid Link was more so for those already carrying their phones and those that don't want to buy anything else. The trade-off is range for convenience. BLE gets you maybe ~50-100m in the open, ~20-60m in densely woooded areas. That's enough to keep tabs on a hunting party spread across a hillside or a hiking group. Absolutely not a replacement for a radio relay across a valley.

Different tools for different problems. If I need a 2km mesh range I'd set up Meshtastic too.

I feel like this will have a short shelf life. OpenAI is going to notice traffic through that Codex endpoint that doesn't match its usage patterns and lock it down.

That's an awesome story and meaning behind that. Thanks for sharing!

Thanks! If you get a chance to try it outside, the GPS lock is usually pretty fast. Would love to hear how it works for you — especially if anything feels off or missing. I don't have analytics so user feedback is the only way I know what to improve.

This is the natural consequence of building everything around "the agent needs access to everything to be useful." The more capabilities you hand an agent, the larger the attack surface when it encounters a malicious page.

The simplest mitigation is also the least popular one: don't give the agent credentials in the first place. Scope it to read-only where possible, and treat every page it visits as untrusted input. But that limits what agents can do, which is why nobody wants to hear it.

That tracks. The defense primes have zero incentive to make things cheaper — their business model is cost-plus. A guy building something for 10k in his garage is an existential threat to programs billing 500k per unit. Of course they ignored him until the geopolitical situation made it impossible to keep ignoring.

From what I've seen, the teams that are actually on the fireline mostly use paper ICS 214s and radio. The structured digital stuff lives at the ICP/EOC level. So the gap is really between field collection and the management system — if you can get a compact record off a phone with no connectivity requirement, that bridges it without asking anyone to change their workflow.

I think the practical win is SALUTE-style reports that auto-populate grid and DTG, exportable as plain text. No one wants another app to learn at 0200 on a fire.

Visual SLAM on a rocket would be wild. The frame rates you'd need at those velocities are brutal though — feature tracking falls apart fast when your entire visual field is changing at hundreds of m/s. Drones are the sweet spot where camera-based nav really shines.