the SDK says this value should contain
Time since last change of motion state (isMoving value changed) returned in seconds.
It does seem to reset properly, but it is not counting up in seconds.
for example, it seems to count in up in small increments, and when it hits 60 seconds, it will return 60 for a long time, then jump to 120.
I know my phone will not be in range of the beacon at all times, so when it finally sees the beacon again after minutes/hours, I need to know if it has moved sometime since it was last receiving packets.
without accurate count here, I will miss events, or have false positives.
Is this a hardware problem?
What you’re seeing is because we count in seconds first, then once it reaches 60 we switch to minutes, then to hours, days (up to 31), and then weeks. [Although the SDK always reports in seconds, so you’ll see 58, 59, 60, then 120, 180, …, then 3600, 7200, etc.]
There’s very limited space in the Bluetooth packet, so we designed it this way. For example, 10 weeks = 10 * 7 days * 24 hours * 60 minutes * 60 seconds = 6,048,000 seconds, you need 23 bits to encode that if you want granularity in seconds. With our algorithm, we can encode it on just 8 bits, albeit dropping down to the week-level granularity.
I need to know if it has moved sometime since it was last receiving packets.
without accurate count here, I will miss events, or have false positives.
Correct me if I’m wrong, but that’s still perfectly possible to do, even with the least granular case, i.e., weeks:
- Say, your bag was static for 5 weeks. You come in range, you detect that, you leave range.
- While you’re away, the bag has moved.
- After 2 days, you come back in range. If the bag hadn’t moved, you’d expect the counter to still be 5 weeks (because 5 weeks + 2 days is not enough to advance the counter to 6 weeks). But since the bag did move, the counter is just 2 days, so you know.
That makes sense.
So in the 8-bits,
a) is it always counting with 8-bits, and the phone software tries to make sense of it,
b) or is the sticker also encoding the units into some of the bits, and the rest of the bits are counting?
If (a), and the phone is out of range, then coming back into range, it won’t know what units to measure.
if (b), then well done, that is usable 
If:
- a beacon was being monitored when it stopped moving,
- and then the phone left range
- an hour later the beacon moved again
- the phone came back in range 2 weeks later.
the beacon now counting week increments wouldn’t tell the phone it moved.
It’s (b), the SDK also knows the unit, and converts that to seconds automatically.
[quote]If:
- a beacon was being monitored when it stopped moving,
- and then the phone left range
- an hour later the beacon moved again
- the phone came back in range 2 weeks later.
the beacon now counting week increments wouldn’t tell the phone it moved.[/quote]
That’s … a good point. Sadly, I can’t think of any work around to that.
I’m not working on anything that would involve the phone leaving range for those long duration, so it should be fine, but will keep it in mind.
ok, thank you for your help.
I’m getting frustrated trying to detect if the beacon has moved since the last time I got a nearable packet:
- Receive nearable packet, it says current motion state duration = 60
so the beacon hasn’t moved for 60 seconds,
so I store current time -60 for 60 seconds ago
- Receive next nearable packet, it still says current motion state duration = 60
(current time -60) is now a newer time then the stored time.
the more I think about it, the only points in time that I can create a calculation that works is when
- it’s counting actual seconds, (because this is the reporting period)
- the 2 packets I want to compare came from different unit measurements (first packet received when it was counting minutes, comparing to packet received when counting hours).
can you think of a way to make current motion state duration useful?
am I missing something?
Are the new Location Beacons transmitting the same data?
I would like to know before buying.
Perhaps this field can be changed to 18bits, counting seconds?
It’s the same data actually. We already had to split the Estimote Telemetry frame into two physical packets to fit all the extra sensors and data, so we also went for the same motion state duration compression as in the Nearable packet.
I’m also seeing that even though my NearableListener is called, the motionStateDuration is not incremented.
I’m getting:
nearable.currentMotionStateDuration 0, 1, 1, 1, 1, 5, 5, 5, 5, 5, 11, 11, 13
so I also have to remember the last value, and only act if it changed…
Perhaps you could describe how you intended this field to be useful?
Thanks,
Dan
If motion state duration is the same as in the previous invocation of the NearableListener, it simply means that no data arrived since that time. Nearables broadcast once every 2.5 seconds by default, so with the default 1 s scanning interval, you have to go at least 3 scans without new data.
The intention was mostly to allow apps to know long the nearables has been still or in motion. For example, in retail, we’re seeing people implementing simple analytics, tracking how long customers are engaged with a product that has a sticker on it. Or, one of our engineer’s has build himself a simple app which checks if his mailbox has been opened while he was at work, so he knows he needs to check it for new mail.