It was a bit flakey, but I’ve learned things since then. All the app did was to switch to the information screen that corresponded with the nearest beacon. But, if the nearest one is fluctuating by enough, and the second nearest beacon fluctuates and becomes stronger just for a moment, the screen would switch. Also, sometimes a beacon will not read at all. I think that happens if the polling happens just after the beacon has finished transmitting for that second.
Anyway, you do a combination of averaging to take care of the glitches, and you also give the current beacon another chance if it disappears for a moment. Then you might end up with something stable. It’s worth knowing the distances too. Within a foot is classed as “immediate”, 1-4 feet is “near”, 4-20 feet is “far”, beyond 20 feet may show as “unknown”. I tended not to use the proximity reading anyway, but if you do you could have the app only consider the ones that are “near” or “immediate”, if you want the app to only react when the user is right on top of the destination. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
