RAK2287 Chirpstack “Enable network geolocation”

LPWAN Developer Gateways / Concentrators RAK2287
1

Issue: Can’t find documentation for “Enable network geolocation”

Setup: RAK2287 on Raspberry Pi 4B

Server: Chirpstack (supplied with RAK2287)

Details: Hello,

I have a RAK2287 running Chirpstack. In my Service Profile I note that there is an “Enable network geolocation” tickbox. I’m keen to use this feature but I’m struggling to find any documentation on how to do so. For example, on this page:
https://www.chirpstack.io/network-server/features/service-profile/
it’s mentioned but not explained.

Can anyone point me in the right direction for some documentation (preferably beginner-friendly!)?

Many thanks

2

Hello Andrew (@aal7),

I’ve been looking on my own, but there doesn’t seem to be much documentation about it. The only thing I could find was:

Given that this is something related to the chirpstack service and not directly related to RAK2287, there is not much I can do on my side.

I noticed you also posted the question in the ChirpStack forum. I hope they can support you out there soon. :smiley:

Cheers,
Maria H.

3

Hi Maria (@anon55548400),

Thanks for your reply. I found that page too. It doesn’t exactly go into detail on how to use the geolocation does it? I find myself constantly frustrated by how little information there is to get going with these things!

Best wishes
Andrew

4

It’s all there: https://www.loracloud.com/documentation/geolocation

5

For the basics, I’d agree. But geolocation with LoRa isn’t trivial - it needs at least two, preferably three gateways and works best with high end gateways with the licensed algorithm that post processes the uplink to calculate the time of the uplink’s nano-resolution transmission time. It can be done with multiple uplinks but still needs two or more gateway records.

And the gateways need to have some significant difference in location - not in the same building, that’s for sure. And the calculated device location can be ±100’s of metres.

I’m not trying to put you off, I’m trying to differentiate between technical levels - the more obtuse stuff tends to be in the heads of consultants (no, not me, not for nano-timestamp locators) who have little time or incentive to document it as the number of implementations & rate of change isn’t worth it.

For building site style asset tracking, deploying BLE beacons that the device listens for and then sends the data via LoRa is pretty effective. The RSSI of BLE is pretty good at narrowing down location of things - unless it’s an Apple iPhone for the UK NHS app - but that was Apple’s fault.

If you really want to know where something is, something like the RAK5205 would be a good start, (minus the random BME680). You can use the onboard LIS3DH to detect motion and transmit location appropriately. For vehicles, I’d use the GPS to detect turns and then transmit once it’s clear the vehicle is making substantial progress in a particularly direction - no point plotting something on a longer route too frequently.

1 Like
6

Thank you for this considered response, @nmcc .

Long term, I’m keen to get an idea of location without using up all the energy a GPS receiver requires. It seems a slighly odd concept to plump for a really low power transmission system and then use all the saved energy (and more!) working out where you are when, according to the marketing material at least, the system you’ve chosen can do it for you (albeit at much reduced accuracy). Having said that, I can see that LoRa geolocation is at least one (and probably many) technical levels above what I’ve been able to achieve so far (much of it with your excellent help, I might add).

I had already found the documentation linked to by @ric2498 above and struggled to make much sense of how I might put it into practice. Perhaps that’s the indication that it’s a step too far, although that has been my initial reaction at most stages of this work and I’ve got there in the end every time!

Out of interest does my RAK2287 have the licensed algorithm to which you refer? I’m kind of guessing it does because of the “Enable network geolocation” tick box.

Thanks for all the support. I appreciate it.

7

I believe the vast majority of LoRa devices, LoRa or LoRaWAN, are pretty static - as in bolted / glued / screwed down. I know most of mine are.

LoRaWAN is almost useless for tracking at the “where’s my delivery” level as it relies on LoRaWAN coverage and for vehicles, you have all the power you can eat to run 2/3/4/5G.

There are GPS based geolocation schemes that can work - you don’t have to have the GPS turned on unless you detect movement and then the GPS can tell you if it’s worth transmitting (ie, are you in at the depot).

If your use case is centred on a dense metropolitan area (I’m thinking London, I believe they are pretty dense down there), you’ve got coverage and if you are happy with an approximate location, then this system is good to go although signal paths would be such a mess I’d not expect it to be hugely useful.

But out in Kansas, with gateways at each of your tractor sheds, where’s Wally starts to make sense on the farm.

Just because it can, means to say it is good for your application.

It’s all a bit like throwing small children in to a swimming pool and shouting instructions from afar …

And believe me, I get a dose of it at least once a week - you’ll not believe the paragraph I had to ferret out to get a power boost circuit to work at the calculated voltage yesterday!

Fundamentally you capture one or more uplinks via TTN with the associated gateway info - which arrives via MQTT or HTTP Integration, some repackaging and send it to LoRaCloud via a web request and get back an approximate location.

I believe you have most of the tools for that, so I’m sure we can take your Python MQTT client and get it finding the location - subject to you having a device that is in range of two or more gateways that really need to be at least 1km apart - which will give you a really useless accuracy as it won’t be able to determine how far left or right of the joining line between the two gateways are - which is why three is the real minimum.

As I’ve just moved, I don’t have a third gateway in range, yet, but I do have two households we are delivering food parcels too that I will get going before year end, plus the neglected university gateway. But I only need to pop to Manchester to get some triangulation going. And in the meanwhile we can fake some test data.

Nope - it’s a very special chip & algorithm implementation on gateways that cost 5x as much. But that’s to capture Time of Arrival (TOA) data which is more accurate than using signal strength as it’s linear and not subject to signal path issues (tall buildings in the way, etc)

That’s not how software developers work / think / design :zipper_mouth_face:

8

Thanks so much for all this. I’m thrashing around in the swimming pool just a little less now!

Having tried again to read the documentation at @ric2498’s link and having read what you’ve written I now think I understand that the process is something link this:

  1. I send a message from my node
  2. Three or more local gateways receive the message
  3. I collect the data from each gateway about its own location and what it saw of my transmission ie signal strength etc but not TOA! (eg using MQTT)
  4. I submit that data in the right format to the LoRa Cloud Geolocation Service.
  5. The Lora Cloud Geolocation Service takes that data, works out a location estimate and sends it back to me.

Is that about right?

Questions:

  • I assume the (three) gateways wouldn’t all need to belong to me?
  • You mention TTN. Do they need to be involved? (for example if I had three gateways of my own all using Chirpstack).

Unfortunately I do not have three gateways within range anywhere near here. In fact the only gateway in range is currently my own. Could I develop my method using just one gateway (accepting that the locations given will be hogwash), and then go somewhere with more gateways for field testing further down the line? Or perhaps, as you’ve hinted, some data can be faked.

TANGENT ALERT
Off on a slight tangent, I know what I said about wasting energy on a GNSS receiver but I’m intrigued by the mention of the LR1110 and its “GNSS sniffs” here:

Am I to understand that this device takes some sort of snapshot of the GNSS signals but doesn’t go as far as converting that to a location? And that, instead, it sends that snapshot to a Cloud Server which generates the location, hence offloading the energy requirement for the conversion process from a small battery-powered device to a big mains-powered server?

9

Yes

Nope, none of them need be yours, you just need the data you already get.

TTN don’t need to be involved - apart from the fact they have lots of community gateways. If you get three or more gateways together, you’ll need a central Chirpstack that they are talking to so that the gateway information is bundled with the uplink.

I don’t think you can submit a request with only one gateway - it may tell you what the rough distance - but you could do that yourself with a short drive in a snail like pattern in your area.

Test data can be generated - but substantially easier to go somewhere with a few gateways and have a little drive around.

The geo-location in the LR1110 is bleeding edge technology of the highest order - to really keep power consumption down, the module will need to know roughly where it is and have a reasonably up to date satellite almanac, most likely delivered over WiFi :scream: at which point you could use the local WiFi signatures to get a rough location - other wise it has to search the sky for signals and then send a message by some means to have it processed. I can see how this may well make a useful chipset once it’s been taken around the block a few times, but the reality is with GPS, if you have an up to date ephemeris, hot fix should be a matter of seconds and if you are supplementing power with solar, you can cherry pick when you run the GPS longer to get an almanac update (in theory, 12.5 minutes) which will keep you going for a couple of weeks of warm fixes. The individual satellite ephemeris data is only for four hours ahead, updated every two hours and takes about 30 seconds to download, so again, some strategy needs to be applied to get the best.

So, overall, detect when you are moving, look at your battery levels and what charge is coming in and time of day. For instance, if the vehicle isn’t moving, shut down. Only get an almanac update when you have lots of solar. That sort of thing.

Trying to fish for applications in broad terms is usually a exercise in futility - but having a real world application to get to grips with brings clarity.

10

Looks like I might need a trip to Cambridge then…

Alternatively, my friend took one of my nodes to Hull in the summer. There are a surprising number of gateways in Hull. I have data from a small number transmissions where a message was collected by more than one gateway. I wonder if I could use that?

11

There is one transmission in particular that was picked up by four gateways. I’m going to see if I can use that data to get a location.

How does one get the lat/lon/alt of a TTN gateway?

12

I don’t know about Hull data - is it a rhetorical question? It is useful to know the location of the device at the time of the uplink so you can compare it with the result from LoRaCloud.

Gateway locations are included in the MQTT / HTTP message.

13

I do know the location of the device. It has GPS built in.

I obviously didn’t get all the required info via MQTT/HTTP at the time. I’ll just make estimates for the gateway locations based on their positions on the TTN map. EDIT: just remembered that ttnmapper.org has lat/lon listed for each gateway…

14

OK, I’ve created a Single Frame Invocation file as shown here:

It contains all the data I took from the Hull transmission and the Primary Token from my loracloud.com account.

I naively copied the file to my Pi, set it to executable and did
./myfile.sh
at the command line.

It didn’t work. So… how does one use/invoke the bash script one has created?

15

It didn’t like the blank lines, so I removed those. The problem now is this:
curl: (3) URL using bad/illegal format or missing URL

My curl command looks like this:
curl -k --request POST -H "Ocp-Apim-Subscription-Key: $TOKEN" -H "Content-Type: application/json" -d "$DATA" $SRVURI/api/v3/solve/singleframe

Earlier in the file I have this:
SRVURI=https://gls.loracloud.com

Can anyone spot what’s wrong?

16

Could be a syntax error earlier in the script or the command line shell doesn’t like the syntax just because.

Try copying & pasting the example but using your token to see what happens. That should tell you if your shell (cmd line) is the culprit.

And/or post the script you generated for more detailed inspection.

17

I’ve been messing about on the command line all afternoon. The main issue with that is that I can’t easily replace the $DATA tag in the code with the real data because it’s quite a lot of data!

Here’s the full script (with token xxx’d out):

SRVURI=https://gls.loracloud.com
TOKEN=xxx
read -d '' GATEWAYS << EOF
[{"gatewayId": "eui-b827ebfffe6a6541",
  "latitude": 53.7290416, "longitude": -0.4553487, "altitude": 46},
{"gatewayId": "eui-323433363f001d00",
  "latitude": 53.6955947, "longitude": -0.3545694, "altitude": 4},
{"gatewayId": "eui-3235313217003400",
  "latitude": 53.7656897, "longitude": -0.2911185, "altitude": 4},
{"gatewayId": "hcc-lora-005",
  "latitude": 53.7675007, "longitude": -0.3302812, "altitude": 4}]
EOF
read -d '' FRAME << EOF
[["eui-b827ebfffe6a6541", 0, 110690804, -120.0, -16.8],
 ["eui-323433363f001d00", 0, 2220287732, -117.0, -9.75],
 ["eui-3235313217003400", 0, 2329586397, -116.0, -3.0],
 ["hcc-lora-005", 0, 3810841588, -113.0, -5.0]]
EOF
read -d '' DATA << EOF
{ "gateways": $GATEWAYS, "frame": $FRAME }
EOF
curl -k --request POST -H "Ocp-Apim-Subscription-Key: $TOKEN" -H "Content-Type: application/json" -d "$DATA" $SRVURI/api/v3/solve/singleframe

All I’ve really done is take the example code and put my data into it. I had to delete the blank lines because it didn’t like those, and I had to combine the final line onto a single line instead of using the backslashes to split it across lines (it didn’t seem to like that either!).

18

Works for me!

{"result": {"numUsedGateways": 2, "HDOP": null, "locationEst": {"latitude": 53.731095, "longitude": -0.332635, "toleranceHoriz": 903}, "algorithmType": "Rssi"}, "warnings": []}

I added a shebang/hashbang at the top:

#!/bin/bash

and tell the file system to make it executable:

chmod 777 scriptNameHere.sh

and then run at the command line:

./scriptNameHere.sh

This is on macOS, should be the same on Linux / Raspberry Pi OS

What was the actual device location?

19

How odd.

I did the chmod command, made no difference (same error message about the URL).

Then I added the #!bin/bash at the top. New error message:
-bash: ./myfile.sh: /bin/bash^M: bad interpreter: No such file or directory

I wonder why it won’t work for me??

The actual position according to GPS was 53.7058979,-0.4498016, which I reckon is about 8km away from the estimated position you got back. Interesting that it only used two gateways of the four to do the estimate.

20

I’ve solved it. It’s something to do with creating the shell script on a Windows machine and then moving it to a Linux machine (my Pi), involving line endings.

I’ve installed dos2unix and and run it on my shell script file. It worked immediately, giving the same result you got.

This has never been a problem for me with python files, but shell scripts seem to be a different matter.

Anyway, I got there in the end. Phew!