Hi, we've been trying to figure out if there's any way of redefining the CLProximity zones with Estimote? For our particular use case we need the range of 'Immediate' to be slightly larger and for 'Near' to be smaller.
Alternatively (if these proximity zones are locked down by Apple), is it possible/feasible to define your own proximity ranges using beacon.distance, or would this value not be stable enough?
Hey Sam,
Yup, afraid these are in fact locked down by Apple. beacon.distance could work, although you might need to end up smoothing its readings out: remove the outliers, do some averaging etc.
Thank you for your answer, we were thinking of looking into something like Kalman filtering for the averaging, i came across an old Estimote post here:
https://community.estimote.com/hc/communities/public/questions/200986703-rssi-kalman-filtering-for-trilateration-
that mentioned it being developed for the SDK, did this ever come to fruition or is it still in development? Thanks again!
Hey Sam
Short story: signal filtering/smoothing built into the SDK is a request we're hearing a lot, and we're still working on adding that to the SDK.
Long story: in the past few months we were focusing a lot on the "deployment" challenges around building beacon-powered experiences: fleet management, beacons security, sharing beacon infrastructure etc. We've made good progress here, and we're definitely not gonna stop, but we're definitely shifting some of our attention into helping out with the "development" part[1]—including signal smoothing algorithms.
[1] To put money where our mouth is, we've already started with [triggers](We've already started with triggers). I know this doesn't address your issue, but it hopefully proves that the shift I'm talking about is real (:
Cool, thank you for the response!