Collos Location

Anyone testing the collos location service yet?? Would be interesting to see the results of the service, I’ve applied for membership but no conformation email as of yet.

1 Like

nope same here. applied but no confirmation.

Also applied, but no confirmation.

Folks,

let me look into this for you all.
Since we are in preview mode some of the processes are not fully automated yet.
you can also go to http://preview.collos.org/Home/Contact and ask to follow up.

Thanks
Rich

3 Likes

thanks Rich

collos01

looking good :sunglasses:

there has been some kind of failure in the sign-up process. It seems that a lot have ‘gone missing in action’.

We will address this issue.

Sorry for the delay… at least you can feel that you have helped us out already with this preview… :wink:

2 Likes

I signed up today again, got E-Mail and could integrate with Collos. Looks like RSSI method works.
It is visualised in cayenne and also in the ttn console.
grafik

1 Like

cool… if that’s the way I re register:sunglasses:

  • this time you get a confirmation mail :+1:
1 Like

Just reregistered

@RichL just re-registered. As first and simplest bit of feedback: please enable https on the website. Also consider tuning down on the required fields, you certainly don’t need my postal address for this service. And then, not entirely unexpected but the Terms of Service are extremely unbalanced to your side. I understand it’s a preview but the Terms basically say “We retain all rights to do whatever without telling you, we can do almost anything with your data including re-distribution and we’re not liable” (to the maximum extend permitted by law, since you’re placing jurisdiction in Switzerland).

1 Like

Hello Folks,

as you can imagine this is generating a lot of interest and we have now several hundred subscriptions. Something happened to break the sign-up process and that is fixed now- everything was ending up in the database but nothing being forwarded from there. We do, however have all the registration requests stored so they will get processed.

We have a couple of issues exposed with some of the early users in terms of GW naming conventions tripping up the queries causing low success rates in some places. We are working to fix this right now and move a new version into production. I am waiting for a date on this but expect within the next week. We are very keen to ensure that all the new users get up and running with a good stable experience.

We are super-excited to see all you folks anxious to get going and sincerely apologize for the slow ramp-up. We are shaping up and really appreciate your guys patience.

I will have an update email addressed to all those who signed up sent out today.

2 Likes

Thanks for the feedback @gonzalo

Sorry about the legal stuff for now. Essentially while we are in preview we are monitoring carefully the inner workings of the system we need to be able to use the anonimised data that we see to help debug etc.

I will feedback the website comments, and I will get the mandatory fields looked at.

Thanks again.

1 Like

Thanks @RichL for the fast reaction and transparency!

3 Likes

I did the integration for my devices / applications today, too, and it works, i get coordinates for my devices in ttn console. Precision not yet tested, currently it’s too cold here to walk around outside :wink:

In the collos API i see add / update gateway functions. What’s their purpose? Should i try to add my gateways with it?

Interesting. I would like to know the precision of the system with only lora gateways, cause that could make a huge in terms of saving in terms of my intended project.

Though I am still trying to figure out on how to use collos. Can’t seem to find a run down on how to utilise.

1 Like

Hi @Acht How many gateways did you use?

I’m trying to setup the COLLOS integration in the TTN application console for the loraSkyhook endpoint. This is not working… and there’s really no way to debug this. So I have tested the endpoint using the “try it” button and with Skyhook’s test vector as shown below, and it does produce the correct response:
{
“age”: 0,
“macAddress”: “000c4182d88c”,
“signalStrength”: -50
},
{
“age”: 0,
“macAddress”: “000445a0e272”,
“signalStrength”: -50
},
{
“age”: 0,
“macAddress”: “00012255a5a3”,
“signalStrength”: -50
},
{
“age”: 0,
“macAddress”: “000c41a2df52”,
“signalStrength”: -50
}

Date: Wed, 07 Mar 2018 05:18:55 GMT
X-Powered-By: ASP.NET
Content-Length: 113
Content-Type: application/json; charset=utf-8
Expires: -1

{
“result”: {
“latitude”: 42.297083,
“longitude”: -71.233319,
“altitude”: 0.0,
“accuracy”: 99.0
},
“errors”: [],
“warnings”: []
}

Now I’ve constructed the same test vector in my LoRa node and have sent the data up, and used a modified payload decoder to generate the same “wifiAccessPoints” array structure as shown above. So, even with apparently generating the correct structure format and with the same data, the integration is doing nothing as far as I can tell. No location update to the device, and Cayenne receives no GPS data.

@vascode my packets are received by normally 2 gateways. The RSSI method works, TDO not yet, maybe more gateways would be needed.

There are really two types of GW out there: (1) the vast bulk of GW are V1 variants and produce time of arrival timestamps that are only accurate to microsecond level. (2) GW based on the V2 reference design which includes nanosecond level time of arrival hardware.

In a location query to the TDOA endpoint, you will need to provide the accurate timestamp from at least 3 V2 gateways. The V2 gateways generally produce these fine timestamps in encrypted form and in order to decrypt these timestamps, the system needs to associate the GW label with a decryption key.

There are two reasons to provision the GW- (1) to place the GW in a fixed, known location in the database and allow the query to remove the location of the antennae from the query, (2) to provision the fine timestamp decryption key to be associated with that GW.

The TDOA endpoint will fall back to using RSSI (signal strength only) if the receivng GWs are not at least 3 provisioned V2 GWs.

TDOA is generally FAR more accurate than signal-strength based.

Also, it is worth looking into the multi-frame endpoint. This really helps a lot. If you have, for example 8 LoRa frames received without the device moving, then bundling all these receptions into a single call to the multiframe endpoint will result is a much better location

I will ask someone to take a look