I’m currently detecting Estimote Stickers using a node.js application(using bleacon). When I move the sticker around, I see the broadcast of the nearable packet pretty quickly (within a second or so of moving it), but when the sticker is still, it broadcasts only rarely - sometimes once a minute, sometimes once every 5 minutes, sometimes hours apart. If I move the sticker around, it appears to immediately start broadcasting again until I stop moving it.
For testing, I have the sticker at the maximum strength, 100ms intervals - this is after trying larger intervals - and I still see the same behavior. Firmware is the latest and was just purchased last week.
Is this the expected behavior? If so, is there a way to turn it off? If not, any suggestions of how to get a more regular/predictable broadcast? Ideally I would want the sticker to broadcast the nearable once every ~10 seconds no matter what (to make sure it’s still there), and more often if it is in motion, but this behavior seems highly irregular.
Sorry for the long wait! Are you sure you adjusted the settings for broadcasting when still to 100 ms? Stickers have two values of Advertising Interval, one for when they’re still and the other one for when they’re in motion. They’re also programmed to broadcast much faster for a couple of second after their status changes (they’re put in motion or stop moving).
Also, what OS and device are you using for testing? Because no matter the settings, several hours apart between received packets is way too long.
The receiving device is a Raspberry Pi 3 (with built-in Bluetooth), using the Estimote-Sticker part of the node-bleacon library to listen to the stickers in a node.js application. The bluetooth on the Pi appears to be functioning fine, in that i’ve been using it to monitor other BLE devices without issue.
Yes, I used the Estimote iOS app to adjust the settings to 100ms moving /100ms still for testing. I also tried upgrading to the 1.3 firmware you guys just released late last week and it appeared to have no effect.
A few other points: I am able to see the sticker consistently from the Estimote iOS app. This implies to me that the estimote packet is being broadcast properly, and that the nearable packet appears to be the issue. I also tried two different stickers and they both showed the same behavior fairly consistently.
The only thing that comes to my mind is, stickers broadcast a non-connectable variant of their packet when still, and a connectable packet when in motion. Maybe your app or bleacon only scans for the connectable variant? Can you post a code snippet from your app where you set up and start scanning?
An example output:
found Mon, 11 Jul 2016 22:48:04 GMT,{“id”:“2eca7f025c919a3e”,“uuid”:“d0d3fa86ca7645ec9bd96af42eca7f025c919a3e”,“type”:“SB0”,“firmware”:“unknown”,“bootloader”:“SB1.0.0”,“temperature”:24.5625,“moving”:false,“batteryLevel”:“unknown”,“acceleration”:{“x”:0,“y”:-15.625,“z”:-1046.875},“currentMotionStateDuration”:0,“previousMotionStateDuration”:1,“power”:6,“firmwareState”:“app”}
Is there documentation on the other advertisement format? I could try writing code against the noble library directly to parse the other advertisement myself if that is possible.
Just to add to my observations so far: I used hcitool lescan along with hcidump I did notice something apparently being broadcast even if the device isn’t moving at about the expected interval. An example:
the advertisements were all pretty similar for the most part. Not yet familiar enough with BLE advertisement format to completely understand the data, however, I think I see the manufacturer-specific data in there after the 17 FF.
the address the advertisement was from appeared to rotate, but always started with C0 and ended with E1, with 8 seemingly random octets inbetween.
One final update: I wrote some code using the lower-level library that is used by the estimote-sticker.js implementation: bluetooth-hci-socket, and then taking the parsing code for the sticker from the bleacon library, and can now see the sticker advertisement on the proper interval from the Pi regardless of whether the sticker is moving or not.
I suspect a bug in the noble library, which is used by bleacon - it appears to be filtering out the nearable packets when not moving by default, which seems wrong to me.
Regardless, I should be set for now. Thanks for your help.
Thanks so much for sharing @tpir, that’s an interesting find! It seems to support my hypothesis:
stickers broadcast a non-connectable variant of their packet when still, and a connectable packet when in motion. Maybe your app or bleacon only scans for the connectable variant
Maybe it’s worth reporting on the bleacon bug tracker. I’ll see if I can find some time to investigate deeper and maybe submit a pull request with a fix.
had the same issue with node-bleacon. Try running it with “NOBLE_REPORT_ALL_HCI_EVENTS=1”, helped for me to receive the periodic non-movement related beacons, too.
I get possibly the same behavior when using nearables. No “enter” event in monitoring mode unless the transmitter is moving. I’m only trying in iBeacon protocol, with default settings otherwise. Using it through the React Native package react-native-beacons-manager which works fine with stationary Proximity Beacons.
These nearables can be detected by the Estimote app, though, so I know they are transmitting.