Collos Location

Application Development
64

@Oliv & @RichL

Well you guys solved my problem :smiley: Thanks a lot. Now I see the location in my payload. Thanks again :smiley:

1 Like
65

Thank you @Oliv. Sorry for the delay but I’ve been working on other stuff - now want to finish this up. I ensured the configuration matched yours. I did eventually get the results I expected and you got - the location near Boston corresponding to Skyhook’s test vector. It did not work immediately however - to get the end-to-end location working I had to delete the device in Cayenne and create a new one.

There is some sort of caching going on somewhere in the chain. Now, I have replaced the Skyhook data with real data, that has worked before with Skyhook’s location system. What I’m seeing is that the ‘Metadata’ shown in the Console’s Application Data reports the old Skyhook test data location. See the screen shot below.

Anyways, all I know is that the TTN console still thinks the device is in ‘Needham Heights’. Somebody is caching this old location?

image

66

I have a working node with Collos in the backend and it works.Tested the payload decoder with the sample data and also returns valid data.
What I would like to do next is actually upload ssid payload but I am struggling with the the encoding side.
Does anyone have a an example of an arduino sketch that shows that part and is willing to share?

1 Like
67

@RichL @Oliv

Guys, me again :slight_smile:

Having one problem. Can someone explain how does really Collos work beacuse now i am a little bit confused??

My device see only 2 gateways. So Collos returns the location of one of the gateways (the one the device is closer), but not the correct location of my device. So does Collos works on “triangulation” method or how does it work? Where is the problem here?

Thanks a lot.

69

Hi there,

there are a number of perspectives that one can take when for a location. On one hand, a location of any kind, even if it is simply the closest gateway is desired where others might prefer a location that is based on less than 3 gateways to be suppressed. Right now, the TDOA will suppress anything less than 3 GW and the RSSI will always try to return something.

We are very close releasing a decent improvement to this though!

In the new version, the return codes will include the type of fix attained along with the number of GW that it is based on. This will mean that if you supply 4GW receptions but one of them gets discarded then it will tell you that it received 4GW but only used 3. There are a number of reasons why a GW reception might get discarded which includes noise and interference. Since TDOA algorithm could also potentially fall back to RSSI based then an indication flagging that fact should also be useful.

This means that the solvers will likely try to always return a location but give enough information to allow the requester to determine if they wish to make use of it or not.

On your original question, a packet received by 2 GW only should yield a result someone along the line between the two. A packet received by only 1GW will yield a result that is close to the GW location (with some random noise added).

Rich

1 Like
70

Did it eventually pull through @firmwareguru?
I have seen some confusing caching in the past and I am not 100% sure who is doing what.
R.

71

Hi Rich - well I can’t say for certain that it is all working at any given time - it does not yet seem to behave deterministic - but I did get it working at least once :slight_smile: So I wrote up a project describing what I did in case anyone wants to repro it for themselves. See the Hackster.io project.

72

Allow me to contribute, I have wifi location working on a wemos D1 mini.
For that you need this firmware:


and the following payload decoder:

var hexChar = ["0", "1", "2", "3", "4", "5", "6", "7","8", "9", "A", "B", "C", "D", "E", "F"];

 

function byteToHex(b) {

 return hexChar[(b >> 4) & 0x0f] + hexChar[b & 0x0f];

}

function hexToInt(hex) {

 var num=hex;

 if (num>0x7F) {

   num=num-0x100;

 }

 return num;

}

function Decoder(bytes) {

 var mac1="";

 for (i = 0; i < 6; i++) {

   mac1 += byteToHex(bytes[i]);

   if (i<5) { mac1+=':';}

}

var rssi1=hexToInt(bytes[6]);

 var mac2="";

 for (i = 0; i < 6; i++) {

   mac2 += byteToHex(bytes[i+7]);

   if (i<5) { mac2+=':';}

}

var rssi2=hexToInt(bytes[13]);

return {
  "access_points": [
    {
      "bssid": mac1,
      "rssi": rssi1
    },
    {
      "bssid": mac2,
      "rssi": rssi2
    }

  ]

}


}
2 Likes
73

Hi @firmwareguru, I am not able to see the code on your Github but I guess catching mechanisms/latency are on Cayenne side.

Did you tried to retrieve data from TTN thanks to MQTT ?

74

Collos Sunset, LoRa Cloud Sunrise
Firstly, thank you for using Collos, the location service preview for LoRaWAN.
Over the past year and a half we have been excited to see rapid growth and strong demand for our easy to consume geolocation service for LoRaWAN devices. The time has now come to take the next step and roll the location service into a new suite of cloud APIs which ease the development of LoRaWAN based solutions. This new suite of services includes many features to support Semtech’s LoRaWAN device modem as well as new geolocation services. The geolocation service is offered alongside a highly secure join service and some sophisticated modem application services that open up LoRaWAN to a new breed of fully managed, secured carrier class devices.
https://www.loracloud.com/

One-step Migration
If you are using the Collos V2 API endpoints then you will find that, for almost everyone, you can migrate over to the new service by simply signing up on the new portal at https://www.loracloud.com/ getting your new security token and switching the URL to the new service. Full documentation can be found here: https://www.loracloud.com/documentation/geolocation

Why change?
The adoption of the preview service has helped us to shape the definition of the ongoing services. The new services will be able to address several of the shortcomings of the Collos preview. Collos was architected to be entirely hosted. As such, this suits a lot of applications, however, as LoRaWAN pushes into every corner of low-power wide area network IoT, we need solutions that are easy to deploy in a host of different ways. Collos does not have the flexibility for such a range of deployment options, whereas the LoRaCloud services have been architected for this kind of flexibility from the get-go.

LoRa Cloud services come with other performance benefits for geolocation. While the Collos algorithms have not been updated since the end of 2018, the LoRa Cloud algorithms are regularly updated. We have a new V3 geolocation format that will allow us to offer simple API-based tracking of devices- while still being completely stateless and anonymous.

All of the LoRa Cloud services have free to use options that are limited in capacity but not time. Therefore, trials and experiments are free from costs without time limits and support instant sign-up. Also, since the LoRa Cloud services will all have options for commercial service levels, we can then start to offer service level agreements (SLA) to back them up. As you might expect, the free services come without SLA.

What next?
Collos will cease to accept new users, however the service will remain operational until the end of 2019 to allow plenty of time for users to migrate to the new service.

Best regards,
Collos team

75

Hi BoRRoZ,
I want to test LoRa Cloud integrated with TTN, but I don’t know how could I do it.
Do I have to use Collos Integration link? Add Collos Integration but with diferent URLs?
Is there any specific LoRa Cloud Integration?
Which are the different algorihtm endpoints?
Is there any manual for LoRa Cloud like Collos Quieck Start?
https://www.thethingsnetwork.org/docs/applications/collos/quick-start.html
Thanks,
Guillermo

76

read the post above your first post :upside_down_face: