TDoA could not provide plausible results in our real physical world, cause the signal doesn’t propagate itself in LoS, so there must be various obstacles standing on their way, like buildings that can make multiple path, reflection, etc… About the RF itself, fainting and echo are also possible. I think we need an or serval algorithms associating with TDoA. Such as mixmal likelihood, least squares. Most of them are statistic technologies that trying to determinate and terminate the ‘negativ’ impacts. More gateways can increase the accuracy of TDoA, but meanwhile more gateways bring more noise as well.
Sorry, maybe Yet Another Recurring Question, but I just saw this:
https://www.elektormagazine.com/news/first-glasgow-then-neuchatel-then
or right from the source:
http://www.csem.ch/Page.aspx?pid=42092
so, any hope to gain practical geolocalization on TTN in future?
Needless to say it would a SUPER plus.
I’m thinking about covering a large sub-urban/rural area with OUTDOOR gateways, so using GPS fix on each of them should be a viable way to gain the necessary time stamps.
Read the message emery02 posted above, follow the link to the article. Also, the CSEM item mentions licensing… Look into the cost involved and the requirements. Would be nice if it could be done but given the expert opinions in this thread I’m not holding my breath…
Geolocation need a new gateway design with FPGA licensed by semtech with improved timestamping. But this new gateway encrypts timestamping metadata. Then you need to pay a fee to allow semtech to desencrypt the timestamping. With this timestamping, semtech provides you a basic solver to calculate the geolocation. If you want a more precise geolocation you must pay for a comercial solver like CSEM who uses 3D floor planing maps to improve geolocation.
4 Likes
After reading the entire thread, my conclusion on the LoRa-based GPS-free geolocation is as follows:
(Please correct me if I’m wrong.)
(1) TTN is not an option today, but could be an option by the end of 2016
If I needed to deploy a geolocation service today based on LoRa triangulation, TTN is not an option. Even if I use a Kerlink gateway which has an on-board GPS module, TTN Network Server does not support triangulation.
But, TTN could be an option by the end of year 2016 with its WiFi BSSID-based geolocation that was published with the The Things Network Roadmap 2016 Q3 - 2017 Q2 announcement.
(2) CSEM’s LoRa-based GPS-free geolocation solution is the only option?
If I needed to deploy a LoRa-based GPS-free geolocation solution today, CSEM would be the only viable solution(??).
But, I can not find any technical documentation on it. Anybody knows what kind of H/W devices, gateways, and the backend network servers are needed for it?
There are only few news articles found but they are mostly marketing pitch. I’m not sure how good it is, and it could be expensive because there is no published pricing.
(3) What else could me my option for a LoRa-based GPS-free geolocation solution if I need to deploy the solution within 2~3 months from today? Should I just put a GPS module on a device and send the GPS coordinates via TTN?
Regarding your points:
-
True. We’re not adding support for it as it’s not worth it in terms of accuracy and development time. Read more about accuracy here
-
That’s just LoRa triangulation (see above)
-
Gateway to node RSSI combined with gateway position (you get this from us), or WiFi BSSIDs lookup, or a GPS module
About the LoRa-based geolocation, as @johan said, it’s not really an option for TTN at the moment and the document he posted as a lot of insights about when/where, if ever, it would be a good option.
But in case you still want to know a bit more: you would need 2nd generation gateways on your network, which very few companies are actually selling through normal supply channels. SagemCom, Kerlink and Cisco apparently have these devices. I couldn’t find technical details about the device, but it seems to be “only” an accurate timestamping mechanism and then encryption of that timestamp on-board.
With that encrypted timestamp, you would need to pay Semtech a license for the decryption keys, and then only you can use CSEM’s solver. I talked to CSEM recently, and they were actually very friendly, but on a non-centrally planned network like TTN, this approach is a very hard to implement.
3 Likes
With “this approach”, are you referring to the licensing thing?
I guess that in theory the accurate time stamping (without encryption/licensing) would be doable in a non-centrally planned network too. But then not all (or only a few…) gateways would offer that, and the location of the privately installed gateways might not be accurate either.
Hi @johan, would you comment on my questions below, if you could? Anyone’s comment is welcomed, too.
Even though TTN does not support the location by triangulation, I guess anyone still can try to make it. It is because some applications may not need a pin point accuracy of a geolocation. Some applications may be ok with 200m error.
I think the triangulation method could be used along with the WiFi-based location method.
So, I’d like to ask a few questions regarding triangulation by TTN.
(1) According to SEMTECH’s article, a geolocation by triangulation requires SEMTECH’s 2nd generation gateway. My question is, if it is still using TDOA (Time Difference of Arrival) and triangulation method to calculate the geolocation of a device, can we still use a TTN gateway software without using SEMTECH’s 2nd generation of gateway software? Because once we add a GPS to a TTN gateway (or just by writing in the location info in the gateway’s configuration file manually), a TTN gateway has the GPS coordinates and it can forward its location info in the JSON file to the TTN backend server.
Then, we can calculate the location of the device based on the gateway’s location coordinates, TDOA, and triangulation. Am I right?
(2) If anyone wants to add a source code module that calculates a device location using TDOA and triangulation to the TTN network server, in which source code file should he/she put it in?
(3) Is there any additional info such as algorithm regarding TDOA and triangulation calculation methods for TTN ?
It might be good if TTN could support ‘location by triangulation’ in addition to the WiFi-based geolocation?
Hi @hoonppark, good questions.
- It is still TDOA. Using the 1st generation Semtech reference design works as well, but is less accurate. In any case, it requires GPS indeed. Not necessarily for the location, because as you say you can put this in config, but for time synchronization.
Note that Semtech’s 2nd generation reference design works with encrypted timestamps. You’d need a license from Semtech to be able to decrypt it.
-
It would be in the Handler, after deduplication and before putting it in a nice packet on MQTT. Currently there’s a chain; look for ConvertLoRaWAN and ConvertFields.
-
Well, you have the metadata from the different gateways in the Handler, so with that it’s not difficult. @Thomas has a model
WiFi-based geolocation is not meant as the holy grail; as with any localization everywhere, it’s good to implement and combine different technologies: LoRa triangulation using TDOA, using signal strengths, using WiFi BSSIDs and signal strengths, using GPS.
1 Like
I did a search on the TTN source code tree, but I couldn’t find ‘ConvertLoRaWAN’ or ‘ConvertFields’ in any of the source files. Should I look for different names?
This is the chain for uplink: https://github.com/TheThingsNetwork/ttn/blob/refactor/core/handler/uplink.go#L45-L49
Thanks, @johan
I found the TTN source I’ve downloaded did not have the ‘handler’ source. I wonder why.
I used the following command to download the TTN source code:
When I compare the source code trees on the web and ones on my computer, they do not match. And, the handler and others were not downloaded. Do you have any idea why?
Please look at that page, it contains instructions in the README.
[quote=“arjanvanb, post:47, topic:435”]
from the Kickstarter Project Update #9:
[ ... ][/quote]Or option 2. Stick to our deadline, and stick to the current reference design we have always been using, make it the cheapest, best working, plug and play, open source LoRaWAN gateway available to start building this network.
We choose option 2 because we are not prepared to accept an uncertain delay for an uncertain design feature; leading us to the conclusion that the use of the GPS chip for this purpose in our gateway has been rendered useless.
@wienke, from my point of view, it’s a pity that you people choose for option 2.
“The Things Network” is/ will be only successful due to their communities. Anno 2016 those communities are groups of early adaptors. People who have a click with LoRa / IoT. The mob will not follow the next year.
And being realistic; In the coming years, these communities are only active in crowded areas. The big city’s or the bigger suburb’s. In these areas, everyone has his own router connected to (fast) internet. So the possibility to ‘connect things’ is already available for citizens. You can easily, if necessary, buy a IoT home router. For Example: ASRock X10 facilitates ZigBee as well as LoRa.
For me, the most added value for an initiative as “The Network thing” is, by far, geolocation.
Once people placed a € 250.00 (ex VAT) gateway, their enthusiasm to replace a newer model after a (few) year(s) is off course very low.
You never get a second change to make a first impression.
2 Likes
@Roel. Agreed.
Option 3:
Include GPS hardware in the gateway. Just because protocol/software/chips are not ready is no excuse not to include the GPS hardware in the gateway. You can always inject the timing/localisation information at a later time in the packets going to the server. Localisation calculations can even be delayed and be done by the application(server) later, as long as gateway location and gps timings of received node data are included in the packets.
Leaving GPS hardware out of the gateway now makes future use of the localisation information very hard, since many (all first generation) gateways are not able to provide this information.
(Too late now anyway I guess)
Hi guys,
Geolocation of sensors without a GPS by triangulation is still a hot topic within the LoRaWan scene. For most of us it is obvious why. 5 month ago KPN announced (future) nation wide Geolocation Services for the Netherlands on its commercial network, recently Semtech LoRa Technology announced a partnership with ZTE. A few interesting highlights:
Semtech’s geolocation functionality uses a hybrid mix of time stamping techniques to locate ensors relative to gateways without requiring additional hardware/space, battery power, and other costly add-ons.
“ZTE’s commitment to bringing commercial IoT solutions with geolocation functionality to market will help accelerate the adoption of IoT applications in China. After extensive testing, we are excited to enhance the current features our ecosystem of LoRa-based IoT applications. Our goal is to deploy over 10,000 gateways and millions of sensors in China and beyond.”
Full article: https://iotbusinessnews.com/2017/04/12/20709-semtech-zte-develop-lora-based-iot-solutions-geolocation-functionality/
Anyone one who can help me.
In case use triangulation, the three GWs should receive the message from one node, question is how make the three GWs keep the spare channel for this node? how do server coordinate among GWs?
The 3+ gateways will receive a message from one node. The message is carried, as any message to the backend. provided the GW have accurate timestamp for the received message, the backend will be able to calculate the location of the node, based one the difference in the time of arrival of the message to the various GW. There is no need to have a spare channel for location. All GW listening to all channels, all messages will be received, as any normal message.
As an indoor gadget, does kickstarter TTN gateway really have a GPS receiver inside? How to receive a GPS signal inside?