Location API Bluetooth Devices

[JudgeyK]

Hi All,

I'm still having a few issues with this which I have a ticket in with Meraki for,  namely I still do not get the V3 (Beta) option for Bluetooth in the Network General settings for the Location API.  But I have tried with the V2 and I am now getting the BLE devices in the JSON from the location API onto our server.  when I try to position them using the X,Y offset they are not where they are supposed to be,  they are probably very close on the Y Access most of the time,  but the X Axis is about 4 metres too far to the right which I don't understand.

The Location API Help says V3 has "improved accuracy for wifi clients of +/- 3.5 metres",  does this apply to BLE devices or is there a different accuracy for BLE ?

Anybody know how accurate we should be able to position a BLE Device using the X,Y offset ?

Kind Regards

Ken

[BrechtSchamp]

Those coordinates are relative to the coordinates of the access points. Are they positioned correctly?

The inaccuracy could be due to walls in your building. The location is still a best effort based on maths. Those maths can't account for the fact the next to one AP there's a wall, and for the others there isn't.

[JudgeyK]

Hi,

Thanks for the swift response,  the Floorplan is accurate from CAD and the APs are positioned accurately,  I cannot see any walls between where the BLE tags are and the AP,  below is from the location heatmap but the Red Cross shows where my app is positioning the BL Tags and where they actually should be in the circle.  I was expecting it to be a little more accurate than this ?

[sungod]

Your image shows only two APs, unless you've got 3+ APs and the positioning of APs (and devices) is reasonable you will get bad location data.

With only two APs 'seeing' the device, it can only be positioned on a line between the two APs, which is exactly what you are seeing in the location data.

[sungod]

Btw this may help understand placement...

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Real-Time_Location_Services_(RTLS)

In our test/demo environment this is pretty much how I set it up (with 10+ APs covering a floor of the building), it's not always practical to put APs at all the corners/edges, but in unobstructed areas 'outside' the AP boundary the results are still reasonable as long as there is line of sight to 3+ APs.

Even with no people there to move things around or affect signal strength, there can still be a few metres jitter in a fixed device's location, depending on your application you might want to consider some filtering to create a 'smoothed' location rather than using a snapshot.

[JudgeyK]

Hey SunGod,

Ok so we took the Tags downstairs to do a test as our APs are more in triangles to test this and we were completely confused to the result.  The Cross on the image is where the Tag was actually located,  probably 2 metres away from AP 13 with no obstruction,  however,  in the Meraki Dashboard under Bluetooth Clients,  it constantly showed every minute that the tag was last seen by AP 11 which was over 30 metres away through several glass walls.  Would you know how this was possible,  and why it was not being seen by AP 13 but yet other devices were using AP 13 without issue ?

[sungod]

I'd assume for BLE that 'last seen by' is just a reporting choice of one AP out of many, i.e. there could be many APs that 'see' a client but only one AP can be chosen.

If position calculation is wrong, as a first step I'd check AP type(s) and firmware are supported for BLE location and API version in use, also check the firmware release notes for any relevant issues etc.

Depends on environment, if allowed you could try turning off PoE to AP11 to 'force' information from elsewhere.

[JudgeyK]

Hi SunGod,

So I'm confused now,  sorry for my lack of knowledge,  but how do I know which JSON File to read from the location Scanning API to get the X,Y offset,  my theory was I look at which AP the tag was last seen on to get the X,Y offset,  but this positions the tag next to AP 11 and not AP 13 ?

Will the Tag appear in many of the JSON Files,  because we get a JSON file for each AP and if so,  how do I know which to choose in order to get the correct X,Y ?

Kind Regards

Ken

[BrechtSchamp]

I think you may be misinterpreting the x and y values... They are offsets in m, relative to the lower left corner of the specified floorplan, not relative to the AP. I assume you have seen these docs:

https://developer.cisco.com/meraki/scanning-api/#!api-version-3-beta/example-payloads

[JudgeyK]

Hi BrechtSchamp,

I'm not misinterpreting the X,Y values,  I fully understand they are from the Bottom Left of the Floorplan,  I was just asking the question in case they were not.  I am picking up the X,Y values from the AP 11 JSON file from the Location API and it positions the Tag next to AP 11,  when its actually sitting directly under AP 13 which is what is confusing me...

Kind Regards

Ken

[sungod]

I guess this is V2.x   https://developer.cisco.com/meraki/scanning-api/#!2-1/bluetooth-devices

As step one, dump the complete response for a few tags so that you can manually plot on the floorplan and get a feel for the data by AP.

If a client is not present in at least three different AP observation[], I'd wonder if the location data is safe, where did it come from if < three APs saw the client? By manually examining the data you can decide if it would be sensible to discard such clients until seen by more APs

Do all APs report the same location? I don't know what happens 'inside' Meraki's location system that creates the data, some things to try...

Out of all the different AP observations for a client, try some methods to see if you can improve client location, for instance...

If the location data vary, choose the location with lowest 'unc' (uncertainty value).

Calculate a final location based upon the midpoint of 2-3 locations with lowest 'unc'.

[DexterLaBora]

I can add some clarity here with the Location services.

I highly suggest you begin your new BLE project using Scanning API v3 beta.

- requires firmware r27 beta

- the JSON is now structured as an array of client objects

- (Note, this is beta, so we might adjust the JSON structure slightly, or rename a parameter. So, ensure you are flexible with your code while in beta) 

https://developer.cisco.com/meraki/scanning-api/#!api-version-3-beta

Why?

- v2 sends a JSON payload of calculated locations, per access point, per minute. This requires you to make sense of multiple AP calculations that could be confusing as well as processing potentially a large number of payloads per network. 

- v3 sends a JSON payload.. per network, per minute. This dramatically improves the efficiency for both delivering and receiving the payloads.

- In addition, the accuracy was improved by mitigating some interference from known sources (other Meraki APs, etc) and some other adjustments with the calculations. 

Both versions have a delay in the location calculation and delivery, but v3 includes the path history between delivery periods along with historical RSSI records. This also provides you with the flexibility of calculating your own location if you wanted to be more advanced about it. 

Re: Accuracy

- 3 APs need to observe a client for proper tri-lateration

- WiFi is a little more difficult to predict location, because each client may broadcast at varying power levels, confusing the RSSI math. 

- BLE is easier to compute location because the power and broadcast interval are usually constant, providing more consistent values (less frantic RSSI measurements)

Hope this helps. We are working on a lot of awesome enhancements to our Location services, so stay tuned for more info. We are always interested in your use cases and ways we can make leveraging our APIs easier and valuable, 

Cheers!

[JudgeyK]

Hi Dexter,

SunGod did point me in the write direction in that I have many APs seeing the iTags,  sometimes up to 5 APs seeing on Tag, ALL with different X,Y Values,  so I have no idea which one to take,  unless I just take the one with the strongest RSSI Value.

I currently have Case : 05279068 open with yourselves,  because as shown above,  I am running Firmware R27.1 on all APs,  but on the General Settings in Network Wide for the Location and Scanning,  when I select Bluetooth,  I only get the dropdown options for V1 or V2.  If I select WiFi,  I get, V1,V2 and V3 (Beta).  So are you able to explain why I am not getting V3 (beta) as an option for Bluetooth ?

Is it available for Bluetooth ?,  the reason I ask is your web link on the Location and Scanning API specifically refers to V3 (beta) only for Wifi,  it does not mention BLE ?

https://developer.cisco.com/meraki/scanning-api/#!api-version-3-beta/wi-fi-location-api-v3

Kind Regards

Ken

[JudgeyK]

Hi All,

Meraki Support have enabled our Dashboard so that I can now get the V3 (Beta) on the Bluetooth option,  So I have now selected this but I am now not getting any JSON files from the API at all.  I also noticed that there is now the option for Bluetooth clients on the Location Heatmap,  not sure if its linked but this is not showing any Bluetooth clients either ?

Is there anything else I need to do to get the V3 Beta working for Bluetooth.  I have validated the location API etc on the settings and everything is ok,  but its showing o the settings as Status Grey: Host has not been validated or sent any Scanning API requests.

Kind Regards

Ken

[JudgeyK]

Well That sucks !

After ringing support, just been told that MR32's are not compatible with Firmware R27 or above so we will not be able to use the Location and scanning API Version 3.

Even though the Meraki Dashboard upgraded the Firmware and said they were on R27.1, the technician said they were still actually just running R26

Weeks of work down the swanny !

[chengineer]

Wi-Fi scanning v3 actually works on R26.6.1. If you don't see the option on a network running that version, navigate a page under the Wireless tab (for example, SSIDs), then back to Network-wide > General as there is a current bug preventing "v3" from showing as an option when navigated from an MX/MS page.

[chengineer]

Oh sorry, this thread was on BLE, my mistake!