Accelerometer data polling latency and sample rate using stickers

Asset Tracking
1

I’m evaluating estimote stickers for one project where I would need really low latency events about sticker movement. I checked documentation and looks like I should be interested in ESTNearableManager and/or ESTNearableRule. My questions:

  1. What’s the average latency of being notified of some motion events (e.g. nearable.zAcceleration < 700)? (considering there is not many beacons around and frequency pollution)

  2. Are the rules/logic (e.g. nearable.zAcceleration < 700) being somehow executed on the sticker side (microprocessor) or the client (e.g. iphone) just keeps polling raw accelerometer data from sticker and test the rule. (this would have impact on latency/battery though)

  3. A little bit related to 1) and 2): What’s the maximum sample rate of accelerometer data when testing the rule or accelerometer events being broadcasted?

  4. Is there any ‘penalty/grace’ time we have to wait when second event is generated? e.g first event with z<700 at (t0) and second event with z>700 at (t0+20ms) -> both events will be detected/triggered?

BTW It seems there is not way to get stickers right now. Can my scenario (with latency ans sample rate) be tested using your simulator and SDK?

thanks

2

The current bottleneck when it comes to polling the accelerometer is stickers’ advertising rate, not the accelerometer sampling rate per se. Stickers advertise once every ~2.5 seconds by default, and a bit more frequently when in use. What kind of polling latency are you looking for? 1 sec? 100 ms? 10 ms? Stickers are realistically only capable of providing ~1 sec resolution at best. (This is mostly to conserve the battery, which in case of sticker-beacons is really tiny.)

The simulator can’t currently simulate the accelerometer, only changes in the proximity to the sticker.

3

Hi @heypiotr ,

Reading your response above. Is this resolution still this low? What about something closer to 100ms? Does the estimote beacon provide a potentially faster resolution as opposed to the stickers?

4

Accelerometers we use in beacons have output data rate set to 10 Hz, i.e., new accelerometer data is available every 100 ms. But, if your stickers or beacons are set to broadcast only, say, once a second, then naturally you’ll only get one sample from the accelerometer per second, and the other 9 will be discarded.

The solution is simple: just set the sticker’s or beacon’s advertising interval to 100 ms. Just keep in mind the battery life—for stickers, advertising interval this low will decrease their lifetime to just a few weeks. If you require the highest sampling rate, our brand new Location Beacons have ~ 3 year lifetime even when set to advertise every 100 ms.

What app or project do you have in mind that requires this frequent accelerometer readings?

5

@heypiotr Thank you! If multiple nearables are moving is it possible to collect multiple accelerometer readings at the same time, concurrently?

i.e. Stickers A and B are both moved. C is still.

I will detect that A & B are both moving.

Then, I want to collect ~2s of Accelerometer data from both A & B at 100ms intervals – hopefully at around the same real-world timestamps.

Thanks!

6

Yes, modern smartphones are capable of capturing anything between 50 up to 150 packets at once, so that shouldn’t be a problem.

How do plan to use the data?

Another thing to keep in mind is, while the packets are broadcast every 100 ms when the adv interval is set so, not all of them usually make it into the smartphone, so you should also account for some packet loss. At close ranges, it should be near 0% loss, but as you move away from the beacon/sticker, that number will rise. (Even more so if there’s no clear line of sight between the receiver and the beacon.)

7

Great! Thank you for the response @heypiotr. Will I have to set the scanning period to lower than 100ms to get most of these packets? If so, how do I do so because as I see in:

beaconManager.setBackgroundScanPeriod(x,y); beaconManager.setForegroundScanPeriod(x,y);

x has a bottom limit of 200ms, correct?

8

Hi @heypiotr,

I’ve been working on this for a few days and still no luck. I want to be able to sense movement more accurately to tell how a person is running roughly with a shoe+nearable sticker.

I know that’s not the main use case for this but it’s a proof of concept that should work.

Here are the problems:

  1. I’m getting my nearables packets anywhere from 200-500ms intervals even though I’ve set them to transmit at 100ms intervals and I’ve set my Android app to 100ms scan period (though I think the SDK will not let you go shorter than 200ms, as per my question above?))

  2. Getting identical Accelerometer readings. At this high of an update frequency (100ms) I tend to receive packets with identical accelerometer readings even though I am accepting packets from moving and still nearables. So if I plot my accelerometer data it is the same for 3-4 received packet.

Thanks for your help

9

Could be that your Android Bluetooth hardware physically isn’t responsive enough to detect every single packet. One idea that pops to my head would be to drop down to the low-level Android Bluetooth API, skipping the Estimote Android SDK, to check the actual capabilities of your hardware. (Estimote SDK will, for example, provide “cached” values if no new packets have been detected, which explains yo seeing identical readings in a row.)

10

Can all beacons, stickers included, reach an output data rate set & broadcast rate of 10Hz? Is there a way to detect distance between two beacons at this rate as well?