Implement nRF Cloud Location Services ✔️ #9
Replies: 3 comments
-
|
NordicSemiconductor/asset-tracker-cloud-firmware-aws#9 adds SUPL support using the supl_client. |
Beta Was this translation helpful? Give feedback.
-
|
nRF Connect for Cloud now provides the GetAssistanceData (AGPS) endpoint:
The idea would be to implement an optional module for the backend that uses the REST endpoint and provide the data for Asset Tracker v2 if not connected to the nRF Connect for Cloud MQTT broker. |
Beta Was this translation helpful? Give feedback.
-
Cell Location Service Cloud to Cloud Integration guideThe Cell Location Service allows to acquire an approximate location of a device based on the cell tower it is currently connected to and those that it can communicate with. The information about the cell towers can be converted in a geolocation, which for example can be shown on a map:
The above screenshot shows three locations for a device: its last GPS location (a blue dot), the approximate location based on the cell it is currently connected to (yellow circle), and the approximate location based on the on the cell it is currently connected to and the neighboring cells it can receive a signal from (red circle). This guide will walk you through the components and processes that you need to implement in order to integrate the nRF Cloud Cell Location service in your cloud solution so that you can use their approximated location in an application for example to visualize or to track them. 1. Send cell data from the device to the cloud
1.1. Send information about the current connected cell to your backendOn the device you can use the modem information library to acquire information about the network the device is currently connected to. This information can be used on the backend to resolve the device location. The digital twin is a good place to store this information. An example could look like this: {
"nw": "LTE-M GPS",
"area": 2305,
"mccmnc": 24202,
"cell": 33703712
}
1.2. Send information about the current connected cell and neighboring cells to your backendThe More specifically, the Link Controller library has a method This information can be used on the backend to resolve the device location and if neighboring cells are found, then the approximate location will be more precise. Given that the size of the report can be quite big, it's not suitable to store this in the device shadow. Therefore it is recommended to send it as a separate message on a custom MQTT topic. An example could look like this: {
"area": 2310,
"adv": 65535,
"mnc": 2,
"rsrq": 8,
"rsrp": 24,
"mcc": 242,
"cell": 34288908,
"earfcn": 6300,
"nmr": [
{
"rsrp": 22,
"cell": 291,
"rsrq": 6,
"earfcn": 6300
},
{
"rsrp": 21,
"cell": 129,
"rsrq": 4,
"earfcn": 6300
}
]
}2. Store cell location data on the cloud
The cell data sent from devices needs to be stored in the IoT digital twin service / and or a database. This allows to provide this information to applications at a later time and also allows to asynchronously resolve cell information to geolocation using the nRF Cloud Cell Location Service REST API: in case processing of the data fails it can be retried. In case of single cell location this store can serve as a cache, since the location information for a cell can be re-used in case many devices are connected to the same cell; their approximated geolocation is the same. 3. Resolve cell location dataThe cell location data needs to be resolved into geolocations using the 3.1. Store Cell Location Service KeyAll API calls need to be authenticated using a JSON Web Token (JWT) which is signed with the Cell Location Service Key. Therefore the Cell Location Service Key needs to be stored in a secure way in your cloud backend. 3.1. Implement cell location resolver
A resolver needs to be implemented, that queries the A location looks like this: {
"lng": 14.44629273,
"lat": 68.21394572,
"accuracy": 637
}3.3. Implement merging of similar cell requestsImagine a scenario where hundreds, or thousands of devices are unloaded from a steel walled cargo container (intermodal container). All of them connect to the cellular network, and the same cell tower, and send their cell location data to the cloud at the same time. While you want to show all of these devices on the map, there is only the need to resolve the cell once, and not hammer the nRF Cloud API with thousands of requests. Therefore the cell location resolver needs a caching mechanism that detects requests for the same cell location and does not re-request this data. 4. Visualize approximate device locationNow all data is present to visualize the approximate device location on a map. 4.1. Query location dataThe device cell location results can now be exposed to a web app, e.g. through a REST API.
4.2. Draw circle on mapGiven the latitude and longitude of the the geolocation you can now draw a circle around this location, with the radius in meters given by the accuracy.
The circle represents the approximate area where the device might be, however it could also be outside of the circle. Full diagram
Attachments (Ignore)diagram.dot digraph G {
subgraph c0 {
rank=same
webapp [ shape=component label="Web App" ]
device [ shape=rectangle label="nRF9160" ]
}
subgraph c1 {
rank=same
appapi [ shape=hexagon label="api.example.com" ]
broker [ shape=component label="IoT broker" ]
}
subgraph c3 {
rank=same
ncelldatabase [ shape=cylinder label="%NCELLMEAS reports" ]
digitaltwin [ shape=cylinder label="Digital Twin" ]
}
subgraph c4 {
rank=same
resolver [ shape=component label="Cell Location\nResolver" ]
devicecelllocation [ shape=cylinder label="resolved\ncell locations" ]
servicekey [ shape=plaintext label="Cell Location Service Key" ]
}
subgraph c5 {
rank=same
api [ shape=hexagon label="api.nrfcloud.com" ]
}
device -> broker [ label=" (neigboring)\ncell information " ]
broker -> digitaltwin [ label=" cell information " ]
broker -> ncelldatabase [ label=" neigboring\ncell information " ]
servicekey -> resolver [ dir=back weight=0.1 ]
digitaltwin -> resolver [ dir=back ]
resolver -> api
ncelldatabase -> resolver [ dir=back ]
devicecelllocation -> resolver [ dir=back ]
webapp -> appapi -> devicecelllocation
} |
Beta Was this translation helpful? Give feedback.
-
nRF Connect for Cloud uses an undisclosed source for their data, and it is only available for devices connecting to their AWS IoT broker, so we need a different solution for the Asset Tracker Cloud Example.
Possible sources for A-GPS data are:
Ephemerides can be calculated based on the current sattelite position, which is available here: https://www.nstb.tc.faa.gov/RTData_WaasSatelliteData.htm
Algorithm:
should then be able to calculate the parameters the modem wants in the format specified here: https://github.com/NordicPlayground/nrfxlib/blob/master/bsdlib/include/nrf_socket.h#L767
The Almanac available on https://navcen.uscg.gov/?pageName=gpsAlmanacs is up to date.
Another source is https://www.nstb.tc.faa.gov/ftp-listing.html?directory=/pub/NSTB_data/
DevZone:
Beta Was this translation helpful? Give feedback.
All reactions