Collos Location

DenisStenkler · May 15, 2018, 7:33pm

I wrote some thing a little bit confused xD Yes it is working OK. In my console i see the location of my device.
So there is see coordinates of my device shown be side the map. So my main question is how to store or parse or something like that coordinates which are shown be side the map?

I think I should not even mention the HTTP integration because there is no connection here. Let’s just leave that behind.

I really hope that you understand me now?

RichL · May 15, 2018, 8:20pm

Hi,

Seems that some confusion abounds…

What I understand is that

you see GW coordinates in the uplinks from the GWs
Collos integration is working and you see the device on the map in the console
you would now like to subscribe to a feed of the device location directly.

I am not sure if you can/how to do that. But will look into it.

The Collos integration can forward said coordinates formatted as a GPS device to any Cayenne integration that you have though.

DenisStenkler · May 16, 2018, 5:29am

Hi Rich,
First of all thanks a lot Rich.
exactly as they mentioned all those things in 1,2,3.

Ok i will try to do Cayenne integration and I hope this will help me.
If you get any other ways to solve this problem can you please let me know?

DenisStenkler · May 16, 2018, 7:56am

One more thing Rich.
Can you please explain some things a little bit more to me?

How TTN and integration with Collos + Cayenne really works ??

Does TTN calls Collos, etc.?
Does TTN calls Cayenne or Collos calls Cayenne?
What kind of data is transmitted, etc.?

And if it would be possible that Http Intgration payload would include (+ GW) DEVICE COORDINATES ?

Thanks a lot.

DannyE · May 16, 2018, 8:27am

Only Cayenne?? Or any Webhook? (like IFTTT)

RichL · May 16, 2018, 11:48am

Actually it is pretty simple right now…

TTN receives the uplink from one or more GWs and instead of throwing away duplicates it keeps the meta-data from each one (primarily that is RSSI and SNR plus TOA if it is available).
If you have a payload that included WiFi sniff data for example then a payload script can be used to create the WiFi query format for WiFi base location.
TTN then forms a query with all the meta-data plus andy WiFi data that is available.
The Query is posted to the endpoint in Collos that you specify and Collos responds with a location.
TTN console then looks at the locations coming back and, if there are multiple, it posts the most accurate one to the console location.
The Cayenne integration is pretty dumb- firstly you need to add a Cayenne integration to the app (for the rest of the data such as the payload and signal strength etc.) Secondly, when you define the integration you get the option to specify a Cayenne channel number. It will quite simply, place the location returned from that particular endpoint in Collos to Cayenne to mimic a GPS device on the channel number that you specify in the integration.

RichL · May 16, 2018, 11:49am

I dont think we can specify any other Webhook right now, although… of course… that would be our desire…

Oliv · May 16, 2018, 5:31pm

@DenisStenkler, @DannyE : once TTN has queried Collos it coordinates in metadata:{latitude, longitude} fields of the payload.

{
  "app_id":"",
  "dev_id":"",
  "metadata":{
    "time":"2018-05-16T17:25:30.632668968Z",
    "gateways":[
      ...
    ],
    "latitude":45.184284,
    "longitude":5.7182016,
    "location_source":"registry"
  }
}

You can get the payload by MQTT or HTTP, use TTN’s storage or any other integration

DenisStenkler · May 17, 2018, 6:38am

@Oliv & @RichL

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

firmwareguru · May 18, 2018, 6:03pm

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?

paulb · May 25, 2018, 9:43pm

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?

DenisStenkler · June 11, 2018, 3:01pm

@RichL @Oliv

Guys, me again

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.

RichL · June 11, 2018, 9:09pm

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

RichL · June 11, 2018, 9:14pm

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.

firmwareguru · June 11, 2018, 10:30pm

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 So I wrote up a project describing what I did in case anyone wants to repro it for themselves. See the Hackster.io project.

paulb · June 12, 2018, 7:39am

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

github.com

galagaking/Wemos_Node/blob/master/Wemos_Node.ino

/*******************************************************************************
 * Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
 *
 * Permission is hereby granted, free of charge, to anyone
 * obtaining a copy of this document and accompanying files,
 * to do whatever they want with them without any restriction,
 * including, but not limited to, copying, modification and redistribution.
 * NO WARRANTY OF ANY KIND IS PROVIDED.
 * 
 * This uses ABP (Activation-by-personalisation), where a DevAddr and
 * Session keys are preconfigured (unlike OTAA, where a DevEUI and
 * application key is configured, while the DevAddr and session keys are
 * assigned/generated in the over-the-air-activation procedure).
 *
 * Note: LoRaWAN per sub-band duty-cycle limitation is enforced (1% in
 * g1, 0.1% in g2), but not the TTN fair usage policy (which is probably
 * violated by this sketch when left running for longer)!
 *
 * To use this sketch, first register your application and device with
 * the things network, to set or generate a DevAddr, NwkSKey and

This file has been truncated. show original

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
    }

  ]

}


}

Oliv · June 12, 2018, 8:43am

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 ?

BoRRoZ · August 22, 2019, 4:45pm

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

GuillermoGlaria · September 2, 2019, 12:23pm

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

BoRRoZ · September 2, 2019, 1:03pm

read the post above your first post