search

neXenio / BLE-Indoor-Positioning

Multilateration using bluetooth beacons
Apache License 2.0
430 stars 129 forks source link

AdvertisingPacket is null #170

Closed KyleAdo closed 4 years ago

KyleAdo commented 4 years ago

Currently, every page is blank, despite changing the UUID filter to my IBeacons UUID ("ebefd083-70a2-47c8-9837-e7b5634df524"), so I'm not sure if the UUID filter as of now is making a difference.

However, I set up some logs in the processScanResult method and when I ran the app it showed that the Beacon Addresses and RSSI values are actually being scanned correctly and it is actually picking my beacons up, however, it does that regardless if I leave the UUID unchanged or not.

But I have noticed that the sensor is null, and so is the AdvertisingPacket, I'm not 100% sure why but after doing some research I think it might be something to do with my Ibeacons, after going through #79 I think I might have the same issue with meetspecification, currently, I'm using Avvel's Long Range Beacons and this is the raw data I received through nRF Connect

image

I apologise once again for laying a lot of information here, but I'm not sure if this meets the specification or not? If I'm correct and it doesn't, what would I need to do/change for it to meet the Advertising Packet specification?

KyleAdo commented 4 years ago

Hello guys, I've fixed the issue, I managed to analyse the raw data I posted there and it turns out the EXPECTED_FLAGS variable needed changing to match the very ones in the raw data, I changed the LE and BR/EDR flag byte (which is the byte number 2 on this list) from 06 to 04.

So it was originally

protected static final byte[] EXPECTED_FLAGS = {0x02, 0x01, 0x06};

now it's...

protected static final byte[] EXPECTED_FLAGS = {0x02, 0x01, 0x04};

So if anyone else is having this problem, make sure you analyse the raw data and modify the necessary byte checks in the advertising class.