I’m going to feel like a jerk for not reading the source to figure out if it’s done in firmware or software before I point to it but meshtastic is doing something on both platforms to find new lorawan nodes and populate them in your device cache and it’s open source.
It’s something that’s consistent across both platforms is why I mention it, I don’t currently have an esp32 laying around to see if it’s done in the UI on the client or on the esp32 itself- mostly because I disliked the heltec and moved to an area where nobody’s using them now. I’m stuck on this question of trying other makes and models or giving up on the lorawan thing. For the moment I’m pegged out on how far I wanted to go with it.
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.
I’m going to feel like a jerk for not reading the source to figure out if it’s done in firmware or software before I point to it but meshtastic is doing something on both platforms to find new lorawan nodes and populate them in your device cache and it’s open source.
It’s something that’s consistent across both platforms is why I mention it, I don’t currently have an esp32 laying around to see if it’s done in the UI on the client or on the esp32 itself- mostly because I disliked the heltec and moved to an area where nobody’s using them now. I’m stuck on this question of trying other makes and models or giving up on the lorawan thing. For the moment I’m pegged out on how far I wanted to go with it.
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
https://github.com/furiousMAC/continuity
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.