Location Services

Environment:
We have 3 ALE servers setup, each with just under 2,000 APs. We have 2 Airwave servers, and about 12 Aruba WLCs. We are running version 2.0.0.14 (61339) on the ALE servers. We have AMON data coming into the servers, but I have exported floor plans from Airwave and then imported them into ALE. I have Single AP mode enabled, because some of our AP deployments aren't that dense. We are using Context with device location (estimated) for the mode.

Question(s):

Using the location API, we have very odd GPS coordinates from clients on the same floor. Users are showing up in the Arctic Circle for example instead of the North East US. I don't see any way to configure GPS settings within ALE. We are looking at setting a reference point on the buildings located within VisualRF, that way when I export the floor plans they should contain that data and report X,Y coordinates accurately. I'm waiting until tomorrow morning after our VisualRF backup to try that.

Has anyone else run into this issue? Any ideas on callibration of the GPS? Is there a way to feed that into the server? We're assuming the GPS settings within VisualRF will take care of it, but we wanted to get some insight from the community.

Thanks for taking a look.

I have not seen a feature to calibrate the ALE floorplan to GPS like coordinates. Till now, I have only seen 'relative to the floorplan' coordinates, which might end up in the Arctic if you try to plot them as GPS coordinates.

In the ALE API Guide you can find:

sta_location_x: X coordinate used to determine client location on a map.
This value is based on the number of feet, or meters if
configured, the station is from the top left corner of the floor

If you need absolute GPS coordinates, you might need to calculate them in your backend.

Hmmm. In the ALE API guide, the full returned data structure for the location is supposed to be like below. What are the latitude and longitude values supposed to be? Ditto for the Floor API (also below). How are these fields supposed to be populated?

Thank you for your time.

{
Location_result": [
{
"msg":{
"sta_eth_mac": {
"addr": "c0:bd:d1:56:81:f3"
},
"sta_location_x": 17.033,
"sta_location_y": 16.5164,
"error_level": 9,
"associated": true,
"campus_id": "08FBBBBF81D937759B5DAC4963DFBC1A",
"building_id": "24C73B58A1F33C3ABE427485A9977BFF",
"floor_id": "D635A61B06673775ADFF61D70B55785C",
"hashed_sta_eth_mac": "A09B5D8F99F9BB8034A8ADBBEC11B24494981096",
"geofence_ids": true,
"loc_algorithm": "ALGORITHM_CALIBRATION",
"longitude": -122.008,
"latitude": 37.4129,
"altitude": 5,
"unit": METERS
} "
ts": 1434750262
}
]
}

Floor API

{
"Floor_result": [
{
"msg": {
"floor_id": "1C48EF7D78DC4B948F1A15D7CD14FDED",
"floor_name": "Floor 1",
"floor_latitude": 0,
"floor_longitude": 0,
"floor_img_path": "/images/plan/img_1c48ef7d-78dc-4b94-8f1a-15d7cd14fded.jpg",
"floor_img_width": 246.33,
"floor_img_length": 249.92,
"building_id": "DAD3A7092AC04AA4B2F5DAF266EBD81B",
"floor_level": 2,
"units": FEET,
"grid_size": 20
},
"ts": 1382046667
}
]
}

Ah, you are using calibrate mode, which has an absolute location. I have never used it like this, and was not aware of that feature.

If you look up these coordinates, they are in the old Aruba office in Sunnyvale California (https://www.gps-coordinates.net/gps-coordinates-converter):

If you are not testing in that location, it could be that these longitude/latitude are rogue values. I don't have an ALE in calibration mode available to test the same, so please contact Aruba TAC for support on this and confirmation if this indeed is a feature that is supposed to work. I didn't find any reference to it before.

All:

This is what is really going on with ALE location values and (lat, long).

Prior documentation would lead an end user to thinking that in Context mode (estimated) that for device location values the latitude and longitude are returned, in addition to the (x, y) coordinates which are in either feet or meters relative to the TLHC (Top Left Hand Corner) of the floor drawing. This is NOT the case. ALE will NOT return a location's (latitude, longitude) coordinates and requires that you run in calibration mode, which is much more expensive to deploy. I was told that the documentation was to be changed in order to reflect that limitation. 

For what it's worth, I wrote a small piece of Python code which emulates the functionality that I wanted, meaning that it calculates the device location's (latitude, longitude) from:

• TLHC (latitude, longitude)
• Drawing's degrees deviation of drawing North from True North
• (x, y) offsets (in feet or meters) from the drawing TLHC.

It's kind of approximate, but it works.