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?
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.
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.
Ah yeah. They solve that by referencing the lorawan ble MAC But you know that.
did you find this project in your travels yet? apparently some portions of it stay and remain uniquely identifiable which this team considers a bug and apples position on it for now is a wont-fix
I like the fact that they rotate them (and WiFi addresses) out so I don’t get stalked with tailored ads in Walmart or whatever but they only went so far with it and it’s probably still feasible
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.
fair, I wouldn’t want a business model that’s dependent on something they could take away overnight.
so that’s discovery, I don’t have any ideas about retention offhand (you already do) but you’ve had that question rattling around for awhile and it’s new to me.
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.
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.
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.
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!
Oh, I thought that support was only present in some iOS 13 beta and then disappeared again? (At the OS/driver level; I’m pretty sure the hardware supports it.)
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.
reply