3

I am trying to parse Estimote Nearable packet format using Altbeacon:

I have the reference for IBeacon:

// Apple iBeacon
beaconManager.getBeaconParsers().add(new BeaconParser()
            .setBeaconLayout("m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"));

And here is a sample of hex with I captured with my hci dump tool:

04 3E 2A 02 01 03 01 47 CC 3B D4 23 DF 1E 02 01 04 1A FF 4C 
00 02 15 D0 D3 FA 86 CA 76 45 EC 9B D9 6A F4 49 78 49 E0 E7 
74 4D 13 BF BD

You can clearly see the 02 15 bytes that matches that beacon format;

Now I am trying to match the Estimote Nearable:

The packet format:

04 3E 2B 02 01 03 01 47 50 19 A9 6E DF 1F 02 01 04 03 03 0F 
18 17 FF 5D 01 01 49 78 49 E0 E7 74 4D 13 04 01 90 61 AF FF 
01 41 46 00 57 B9

But I am not able to get anything using this code:

        beaconManager.getBeaconParsers().add(new BeaconParser()
            .setBeaconLayout("s:4-5=5d01,m:6-6=01,i:7-15,p:25-25,d:15-26"));

I used this resource to understand the packet format: https://github.com/sandeepmistry/node-bleacon/blob/master/estimote-sticker/estimote-sticker.js#L53

Can somebody point out what is wrong with my Beacon Lahyout?

Veaceslav
  • 181
  • 2
  • 12

2 Answers2

1

Try the following parser expression:

new BeaconParser()
        .setBeaconLayout("m0-2=5d0101,i=3-11,d=12,d=13,d=14-15,d=16,d=17,d=18,d=19,d=20,p=21")

EDIT: Based on the comments below, I have revised the expression here:

new BeaconParser()
        .setBeaconLayout("m2-6=02155d0101,i=7-14,d=16-16,d=17-17,d=18-19,d=20-20,d=21-21,d=22-22,d=23-23,d=24-24,p=25-25")

EDIT 2: Based on this byte sequence reported in the comments:

02010403030f1817ff5d01018fc81ebfbebb57d30482855135ff00bd580157

Try this expression:

new BeaconParser()
        .setBeaconLayout("m1-2=0101,i=3-11,d=12-12,d=13-13,d=14-15,d=16-16,d=17-17,d=18-18,d=19-19,d=20-20,p=21-21")

This may or may not work. The above assumes the packet format defined in the link supplied in the question (https://github.com/sandeepmistry/node-bleacon/blob/master/estimote-sticker/estimote-sticker.js#L53) is correct, which I have converted to an offset table here:

0-1: 5d01 (Bluetooth SIG manufacturer id for Estimote)
2: 01 (nearable protocol version)
3-11: identifier
12: firmware version
15: temperature
14-15: battery and moving indicator
16: acceleration x 
17: acceleration y 
18: acceleration z
19: current motion state duration  
20: previous motion state duration
21: power and firmware state

The layout defined above will return a beacon instance with a single identifier field and 8 data fields which map to:

Data Field #   Meaning
1              firmware version
2              temperature
3              battery and moving indicator
4              acceleration x 
5              acceleration y 
6              acceleration z
7              current motion state duration  
8              previous motion state duration

You will have to decode the meaning of the data fields properly from the raw values parsed out of the packets.

The above parser probably will not do distance estimates correctly, as the power calibration field (p=21) does not appear to be in a standard format (like used by AltBeacon, iBeacon and Eddystone) that the library will work with out of the box.

davidgyoung
  • 63,876
  • 14
  • 121
  • 204
  • Hello, thank you for your response. The expression given by you throws an cannot parse exception. Here is my working one: ("m:0-2=5d0101,i:3-11,d:12,d=13:20,p:21-21"); But if I look into the dump, I can see that IBeacon has m:2-3=0215, and the Estimotes 5D01 is even more delayed: m:4-5. Do I miss something? I do not care about correct decoding of data, I can do that later, but I can't match the packet at all... – Veaceslav Apr 22 '16 at 19:36
  • See a revised layout suggestion in an EDIT to my answer. – davidgyoung Apr 23 '16 at 02:27
  • The expression still doesn't match any beacons... I am not sure about thid part: "m2-6=02155d0101. Why do you match the beginning from the iBeacon? Shouldn't be m:4-6=5d0101 ? Also, with m:4-6=5d0101 the altbeacon do not match anything... – Veaceslav Apr 23 '16 at 19:31
  • sorry, I don't have one of the beacons, so I'm kind of flying blind here. If you can do the following for me, I can probably help more. Add a line to your code that sets `beaconManager.setDebug(true);` then capture a LogCat output when scanning for the beacon. Look for lines that look like this: `D/BeaconParser(11355): This is not a matching Beacon advertisement. (Was expecting be ac. The bytes I see are: 0201061aff4c000215078701d2fa844b429c161417dabc159d00010001c20000000000000000000000000000000000000000000000000000000000000000`, then paste one of them in your question. – davidgyoung Apr 23 '16 at 21:35
  • So I am getting a message like this: 04-24 12:30:41.467 22170-22449/org.altbeacon.beaconreference D/BeaconParser: This is not a matching Beacon advertisement. Was expecting 5d 01 at offset 11 and 01 at offset 13. The bytes I see are: 02010403030f1817ff5d01018fc81ebfbebb57d30482855135ff00bd58015700000000000000000000000000000000000000000000000000000000000000' – Veaceslav Apr 24 '16 at 10:32
  • Thank you very much, It worked. I tried to figure the matching by myself, but with not too much luck... – Veaceslav Apr 24 '16 at 19:37
0

What I did for OneBeacon was to decompile the Estimote Android SDK and look in the plain source code (which they didn't bother to minimize or obfuscate) to see how a Nearable is parsed. Unfortunately the broadcasted data is very inconsistent (a few byte offsets are used for different fields...) and the parsing is kind of awful to do right. Sorry, I meant it can never be done right, due to the fields overlapping. But good luck!

Adrian Crețu
  • 878
  • 8
  • 17
  • Can you confirm that the parsing in the https://github.com/sandeepmistry/node-bleacon/blob/master/estimote-sticker/estimote-sticker.js#L53 is accurate? Especially the power parsing, I do not seem to understand it, and in my implementation I get 8 dBm instead of 4... – Veaceslav May 13 '16 at 13:12
  • It looks to me like it's an almost exact counterpart to the Java code inside the Estimote SDK. If you think you have a bug in your implementation but the Estimote app shows the right info, my advice would be to check extremely carefully how you are parsing the bits. Java is notorious for its bit-wise operations handling (e.g. arithmetic shifts vs binary shifts, signed conversion between a byte and int, etc). – Adrian Crețu May 14 '16 at 22:18