For a research project, we are using LoRa technology to build IoT networks and position estimation based on TDoA is one of the part. Since time synchronized information on uplink packets was a critical requirement to apply TDoA, we bought 4x Multi tech LoRa conduits with built in GNSS modules. Now the next step is to setup the LoRaWAN network where the uplinks packets should be received from multiple gateways.
I have few questions
Whether i could use this server to setup the network?
Would i able to get the received time information about uplink packets in nano seconds ?
I tried to use the The Things network Server but, due to the things network packet forwarder the application console only displays information about receive time in seconds. However, my requirement is in nano seconds.
The semtech packet forwarder in line 347 provides receive information in nano seconds. I think that the gateway with GNSS module should provide timing information on uplinks in more than seconds.
Yes, I think you can use the LoRa Server for this, but please take into account that most gateway hardware have an error in deciding the exact receive timestamp. This has nothing to do with the GNSS time-source precision, but how the hardware decices the time of arrival. Newer gateway designs are able to define a more accurate time of arrival, but it is encrypted and you need to pay a license fee to decrypt this timestamp…
Anyway, the timestamp provided by the packet-forwarder used as-is in the rxInfo key using nanosecond precision formatting. Then it is only a matter how precise the (GNSS provided) timestamp the packet-forwarder is
Thanks a lot for your quick response. Actually i am totally new to this “LoRa Server”, so i was that the starting point would be to install first all the components on LINUX machine (possibly a raspberry pi). Is this the right way to go?
Secondly, i dont have mlinux version but application enablement (AEP) versions of the multitech conduits will it make any difference?
Yes, please see https://docs.loraserver.io/ for the install instructions. There is also a ready-to-use docker-compose.yml file that you can use
I think the packages should work on AEP too, my experience is that starting with a factory mLinux image makes the setup easier, to avoid conflicts as the pre-installed mLinux or AEP image comes with a lot of software that you might not need (I believe their own network-server is started by default).
After spending some weeks and with the help and support of this forum, i am able to first convert AEP conduit to mlinux and then install the necessary components (lora packet forwarder and lora-gateway bridge) on the conduit. I have also installed the lora server and lora app server on a raspberry pi, but i have not reached to the final point where i could view the data on the web interface.
However, i have used the command on my conduit
Basically i am sending some uplink packets from my microchip lora mote.
The traffic shows that GPS module is working (correct coordinates are parsed) but the time is in microseconds for the received packets. As for my understanding should it not be in nano seconds as here.
A section from the documentation shows
{
“applicationID”: “123”,
“applicationName”: “temperature-sensor”,
“deviceName”: “garden-sensor”,
“devEUI”: “0202020202020202”,
“deviceStatusBattery”: 200, // set when available
“deviceStatusMargin”: 6, // set when available
“rxInfo”: [
{
“mac”: “0303030303030303”, // MAC of the receiving gateway
“name”: “rooftop-gateway”, // name of the receiving gateway
“latitude”: 52.3740364, // latitude of the receiving gateway
“longitude”: 4.9144401, // longitude of the receiving gateway
“altitude”: 10.5, // altitude of the receiving gateway
“time”: “2016-11-25T16:24:37.295915988Z”, // time when the package was received (GPS time of gateway, only set when available)
“rssi”: -57, // signal strength (dBm)
“loRaSNR”: 10 // signal to noise ratio
}
formatting, provided by https://golang.org/pkg/time/#pkg-constants. It could be that that formatting strips zeros when less precision is provided (e.g. from the gateway).
Thanks a lot @brocaar for your support. Does this mean that i can never get time field in nano seconds with my multitech conduits?
As my work is related about implementation of TDoA, i would certainly need nano second accuracy.
Is there any way to achieve it with my current hardware?
Can we convert tmst filed data type (currently unsigned integer) to float data type? As float provides more precision.
The tmst is an internal timestamp, not related to any time-source. Just an internal uint32 counter value of the gateway which can’t be compared to any other tmst.
I’m not sure how the time field is implemented in the packet-forwarder and and at what precision (as in decimals). But please note that when you want to get a really accurate timestamp, you need to have different hardware with support for the fine timestamp. You will also need a license to be able to decrypt this fine timestamp as these gateways will give you an AES encrypted value. The Conduit and most other gateways based on the v1 and v1.5 reference design are not able to define at what time exactly a frame was received, there will always be an error in this measurement.
Yes, i am totally aware of this hardware limitation. Actually, the project work is about experimenting with GPS based gateways to get the maximum achievable accuracy. The final aim is to see if we could improve the measurements by data fusion (RSSI along with TDoA measurements). This means my GPS clock is only able to provide time in microseconds ? The multitech conduit has ublox max-8 (GNSS module).
If you see at line 1616 in the loRa packet forwarder the time stamp is implemented.
In that line if we change %06liZ to %09liZ and (pkt_utc_time.tv_nsec)/1000 to (pkt_utc_time.tv_nsec)
would it not help?
If you see at line 1616 in the loRa packet forwarder the time stamp is implemented.
In that line if we change %06liZ to %09liZ and (pkt_utc_time.tv_nsec)/1000 to (pkt_utc_time.tv_nsec)
would it not help?
I think it would be better to discuss / suggest this at Issues · Lora-net/packet_forwarder · GitHub. The packet-forwarder development is out of my scope and although I would be really interested in the outcome, I’m not sure if I can support you in this.
Sorry, I might not have been clear on this. I never claimed that the packet-forwarder is providing nanosecond precision timestamp, only that the LoRa Gateway Bridge is using the ns timestamp formatting of the Go time package (which is able to parse the packet-forwarder timestamp format, even when less digits are provided):
Hello, I also was trying to figure out how to get nanosecond precision for using TDoA techniques on LoRa. I’ve also read this thesis with changing of the uSeconds to nanoseconds. Did you manage to find a solution for getting nanoseconds resolution after all? I’ve been struggling for days to find a good approach on that!
Thanks a bunch!
Thanks a lot for the quick answer! Any suggestions on Gateways that support precise timestamping? Above you stated that conduit ones don’t really support that.
No, unfortunately i did not try it till now. But as mentioned in the thesis document, we need to cross compile the packet forwarder with the changes mentioned (replace %06 with %09 and remove division by 1000). @brocaar If i want to do the above changes in your created packages listed here, what steps do i need to follow?
My understanding is to download the LoRa default packet forwarder on a liux machine and compile it by making the above mentioned changes. However, i am not sure about this. Could you kindly guide me in this regard?
Have you made any progress? I was also interested in geopositioning and I have read all the way you have already taken. I am very interested in whether you have found a solution and if so, how you did it. Did you find hardware with the fine nanosecond timestamps? Could you enable that granularity as well? Thanks a lot in advance!