TDoA algorithm Implementation

Hello everyone,

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

  1. Whether i could use this server to setup the network?
  2. 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.

Thanks for your help and support


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 :slight_smile:

For getting started with your Conduits, see also:


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?

1 Like

Yes, please see for the install instructions. There is also a ready-to-use docker-compose.yml file that you can use :slight_smile:

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).

How to flash a factory mLinux image on your Conduit is documented here:

Anyway, let’s keep on-topic, your question was about TDoA :wink: Please use the Multitech Conduit topic for Conduit setup questions :slight_smile:

1 Like


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

tcpdump -AUq -i lo port 1700

which gave me some results as attached below:

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

Please correct me if i am wrong.

Thank you

1 Like

I’m using the

RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"

formatting, provided by It could be that that formatting strips zeros when less precision is provided (e.g. from the gateway).

1 Like

Thanks a lot @brocaar for your support. Does this mean that i can never get time field in nano seconds with my multitech conduits? :slightly_frowning_face:
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. tmst

Thanks a lot for your support.

1 Like

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.

The rxpk is specified here:

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.

1 Like

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?

Also with this step

root@mtcdt:~# wget

i have installed the defualt semtech packet forwarder or it is some variation of the original source?

1 Like

It is the default one, except one patch (by Multitech) to support the SPI path configuration in the JSON. See for the build recipe: loraserver-yocto/layers/meta-semtech/recipes-lora/lora-packet-forwarder/ at master · brocaar/loraserver-yocto · GitHub

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.

1 Like

Thanks a lot @brocaar. If it is the default packet forwarder, then how it could possibly give us nano second resolution.

Because in the source

it is bound to give microseconds. Could you kindly clarify this ?

About modification

I have read one document where source (lora-packet-forwarder) has been modified and cross compiled using linux toolchain.


Could we do similar work for our multitech conduits ?

1 Like

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):

RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"

Of course the LoRa Gateway Bridge can’t make it more accurate than what you feed it :slight_smile:

1 Like

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!

1 Like

You need a gateway with fine-timestamp support. You also need to license the key to decrypt this fine-timestamp as it is encrypted.

1 Like

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.

1 Like

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?

Thanks for your help

1 Like

This is the recipe I’m using for the Conduit packet-forwarder package (you can add your own patch there):

1 Like

Kerlink is one of the vendors that have gateways with support for precise timestamps.

1 Like

Perfect thanks, I’ll give it a look and report my findings!

1 Like

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!

1 Like