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.
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?
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?
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.
[/quote]
@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.
@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)
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.”
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.
Regarding, GPS, you have made a mistake. Due to uncertainty of clock bias between satellite and receiver, you at least require 4 satellite being tracked to produce code phase/pseudorange measurements.
As for LoRa, the end-device first is not expected to have good quality ox(such as better than 5ppm TCXO,) the TOA method cannot resolve the common clock bias term. That said TDOA can be used…
Thanks marmite.
For example in one area covered by 3 GWs, they all listening, if that means at same time at least 3 nodes can get the right of channel to send the message to different GW, and thus the message from one node can’t be received by 3 GWs and then the backend can’t make the positioning due to lack of info?
In TDOA mode, the GW need GPS and good quality OX, all the GWs tracing the sat. And based on the 1PPS to write the time stamp. The assumption here is we think the Basic clock in GWs is synchronized cause they all got from sat.
In LoRaWAN, any node can send a message at any time. This transmission will occur on a randomly chosen channel, with the appropriate SF.
Multiple GW can receive this message (virtually without limit). If the GW have a precise position and clock - i.e. GPS based - the backend will precisely know when each of the GW have received the message. Based on these data, the backend will be able to compute the position of the node to the precision limit.
If at the very same time another node send on the same channel and ‘block’ the message from the initial node to be heard from one or more gateway, it will make difficult the computation.
You need a minimum of 3 gateways to receive the same message to have some data to compute a location.
If the message is transmitted with a too low signal strength, it will limit the number of GW capable of receiving the data, preventing the location computation but still allowing the message to be received by the NW.
