TDoA algorithm Implementation

brocaar · January 24, 2018, 11:13am

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

For getting started with your Conduits, see also:

https://forum.loraserver.io/t/multitech-conduit-ipk-packages/554

Osman · January 24, 2018, 11:59am

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?

brocaar · January 24, 2018, 1:10pm

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

How to flash a factory mLinux image on your Conduit is documented here: http://www.multitech.net/developer/

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

Osman · March 1, 2018, 7:35pm

Hello,

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

brocaar · March 2, 2018, 8:14am

I’m using the

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

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

Osman · March 2, 2018, 9:53am

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

Thanks a lot for your support.

brocaar · March 2, 2018, 10:36am

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: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L117

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.

Osman · March 2, 2018, 11:27am

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 https://dl.loraserver.io/multitech/conduit/lora-packet-forwarder_4.0.1-r5.0_mtcdt.ipk

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

brocaar · March 2, 2018, 11:42am

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/lora-packet-forwarder_4.0.1.bb 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.

Osman · March 2, 2018, 4:25pm

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.

toolchain

Could we do similar work for our multitech conduits ?

brocaar · March 3, 2018, 4:39pm

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

BadBane · April 30, 2018, 3:13pm

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!

brocaar · April 30, 2018, 3:32pm

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

BadBane · April 30, 2018, 4:23pm

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.

Osman · April 30, 2018, 4:48pm

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

brocaar · April 30, 2018, 6:05pm

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

github.com

brocaar/loraserver-yocto/blob/master/layers/meta-semtech/recipes-lora/lora-packet-forwarder/lora-packet-forwarder_4.0.1.bb

DESCRIPTION = "LoRa Packet Forwarder"
HOMEPAGE = "https://github.com/lora-net/packet_forwarder"
PRIORITY = "optional"
LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://LICENSE;md5=22af7693d7b76ef0fc76161c4be76c45"
DEPENDS = "lora-gateway"
PR = "r5"

SRCREV = "v${PV}"
SRC_URI = "git://github.com/Lora-net/packet_forwarder.git;protocol=git \
           file://lora-packet-forwarder-ap1.init \
           file://lora-packet-forwarder-ap2.init \
           file://global_conf.json.MTAC-LORA-H-868.basic \
           file://global_conf.json.MTAC-LORA-H-868.gps \
           file://global_conf.json.MTAC-LORA-H-915.basic \
           file://global_conf.json.MTAC-LORA-H-915.gps \
           file://lora-packet-forwarder-add-spi-dev-path.patch \
"

S = "${WORKDIR}/git"

This file has been truncated. show original

brocaar · April 30, 2018, 6:06pm

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

BadBane · May 1, 2018, 9:01pm

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

1kastner · May 23, 2018, 10:31pm

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!

1kastner · May 28, 2018, 6:48am

Have you found a good source for nanosecond-accurate gateways? Kerlink offers more than one gateway nowadays and I was searching for an appropriate hardware solution.