Multitech Conduit with GNSS module

Gateways MultiTech Gateways
1

Hello ,

I have setup the multi tech conduit following the instructions and it is successfully showing the traffic on the things network. However, the time stamp is in MILLI second while the multi systems claim that with semtech packet forwarder it should give minimum of microsecond clock accuracy.
Since, this installation disabled the semtech packet forwarder could anyone guide me how to configure the things packet forwarder ( https://github.com/kersing/multitech-installer/raw/master/installer.sh –no-check-certificate) to achieve the micro second clock accuracy.

The gateway traffic as of now is as below :
{
“gw_id”: “bibagateway”,
“payload”: “QHEtASYAAgAytoY08XQ=”,
“f_cnt”: 2,
“lora”: {
“spreading_factor”: 7,
“bandwidth”: 125,
“air_time”: 46336000
},
“coding_rate”: “4/5″,
“timestamp”: “2018-01-22T14:06:55.802Z”,
“rssi”: -24,
“snr”: 6.75,
“dev_addr”: “26012D71″,
“frequency”: 868500000
}

2

The GPS based microsecond timestamp is in a field called ‘tmst’ which you do not list in your output. It is not a wall clock based value but a value relative to start of the gateway/packet forwarder.

3

Thanks a lot for your response. So, what precisely i have to do in order to get this field in my output.

4

That field is always present in the uplink data. However it is not displayed in the TTN console for gateways using the ttn-gateway-connector protocol.
If you look at the data for a node you will see the value, however it has been renamed to ‘timestamp’ in the node data. (Just to confuse us all)

Example data from a node received using MQTT:

app/devices/nodename/up {"app_id":"app","dev_id":"nodename","hardware_serial":"XXXXXXXXXXXX","port":1,"counter":682,"payload_raw":"CCAKCg==",
"metadata":{"time":"2018-01-22T23:27:41.77379422Z","frequency":868.1,"modulation":"LORA","data_rate":"SF7BW125",
"airtime":51456000,"coding_rate":"4/5",
"gateways":[
{"gtw_id":"tbdev-lorank8","gtw_trusted":true,"timestamp":2617780955,"time":"2018-01-22T23:37:56Z","channel":0,"rssi":-54,"snr":9,"rf_chain":1,"altitude":8},
{"gtw_id":"tbdev-rpi5","gtw_trusted":true,"timestamp":2879164987,"time":"2018-01-22T23:27:41Z","channel":0,"rssi":-34,"snr":7,"rf_chain":1},
{"gtw_id":"mtech-dev","gtw_trusted":true,"timestamp":604046803,"time":"2018-01-22T23:29:29Z","channel":0,"rssi":-59,"snr":8.75,"rf_chain":1},
{"gtw_id":"tb-mp-dev-gw","gtw_trusted":true,"timestamp":139674947,"time":"2018-01-22T23:27:41Z","channel":0,"rssi":-30,"snr":8.75,"rf_chain":1}
]}}
5

thanks for your quick response. Actually, the aim is to implement TDoA algorithm to estimate the position of end device. As far as i understood (please correct me if i am wrong) i cannot use timestamp field (as it is a relative time).
the output from my application console is as below:

{
“time”: “2018-01-23T09:59:23.672659506Z”,
“frequency”: 868.1,
“modulation”: “LORA”,
“data_rate”: “SF7BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “bibagateway”,
“gtw_trusted”: true,
“timestamp”: 1465843379,
“time”: “2018-01-23T09:59:22Z”,
“channel”: 0,
“rssi”: -85,
“snr”: 8.75,
“rf_chain”: 1
},
{
“gtw_id”: “eui-fcc23dfffe0edeea”,
“timestamp”: 2524791987,
“time”: “2018-01-23T09:59:23.66164Z”,
“channel”: 0,
“rssi”: -111,
“snr”: 0.2,
“rf_chain”: 1,
“latitude”: 53.111008,
“longitude”: 8.855645,
“altitude”: 4,
“location_source”: “registry”
}
]
}

The time field for “bibagateway” shows time in seconds only, however the Multitech systems said that it should be in at least in microseconds.
My Question is regarding which field in the application console that i can utilize to implement TDoA for estimating the position of the end device.

Thanks a lot once again
have a nice day

6

The Semtech packet forwarder has a time field (line 347) which provides the time in nano seconds.
However, for TTN configuration the the installer does not has any of such fields. I am wondering whether because of this i am not getting the time field in nano seconds.

One thing is clear to me now that in order to implement TDoA algorithm, the relevant field in “time” as it is the time when a packet is received by the gateway.

7

I’ve checked the packet forwarder source, if there is a valid GPS lock the packet forwarder will provide nano second time to the backend. It looks like the backend might not format it with sufficient precision when providing the data. You could check the backend sources for this.

8

Do you mean that, TTN packet forwarder (installed during TTN configuration) also provides “time field” (the wall clock time at which the packet is received by the Gateway) in nano second?
For Example:
“time”:“2013-03-31T16:21:17.528002123Z”

9

Could you kindly clarify about two different time fields which you have pasted above.

  1. “metadata”:{“time”:"2018-01-22T23:27:41.77379422Z"
    2.{“gtw_id”:“tbdev-rpi5”,“gtw_trusted”:true,“timestamp”:2879164987,“time”:“2018-01-22T23:27:41Z”

Which one is relevant for implementation of TDoA algorithm
Thanks :slight_smile:

10

The multi protocol packet forwarder sends the time in nano seconds to TTN back-end.

11

Hi,

I made an ssh conenction with the conduit and ran the following command.
cat /var/config/lora/local_conf.json
The results are below:

{
/* Settings defined in global_conf will be overwritten by those in local_conf /
“gateway_conf”: {
/ gateway_ID is based on unique hardware ID, do not edit /
“gateway_ID”: “00800000A0001FD5”,
/ Email of gateway operator, max 40 chars*/
“contact_email”: “XXXXXXXXXXXXXX”,
/* Public description of this device, max 64 chars */
“description”: “loralocalization”,
“gps”: false,
“fake_gps”: false,
“servers”: [
{
“serv_type”: “ttn”,
“server_address”: “bridge.eu.thethings.network”,
“serv_gw_id”: “bibagateway”,
“serv_gw_key”: “ttn-account-v2.Wqpn9mF_6uD7RZ5AgFFDsad3yCgsCQ6WoSe4gigfvfBEOytsc8qsAKVfTYpx7M5GXhKe0dKxt3IZpOmIadRvrw”,
“serv_enabled”: true
}
]
}
}

It seems that gps is set to false. Is that the reason i am not able to retrieve the location coordinates and proper time field (nano seconds) as per your previous email?

Thank you

12

You certainly have to change “gps” to true and include “gps_tty_path”: “/dev/whatever” as well to make high resolution timestamps available.
With the GPS active the log should show:

### [GPS] ###
# Valid gps time reference (age: 0 sec)

If the second line is missing the GPS is not used by the software.

13

Hello,

Thanks a lot for your kind support :slight_smile: , I have edited the “local_config.json” and added the following two lines.

“gps”: true,
“gps_tty_path”:“/dev/ttyXRUSB2”,

On the TTN application payload, now the GPS coordinates are parsed along with time field in nanoseconds.
I then installed the same packet forwarder on another aep multitech conduit , however, here the time field is always in microseconds (rarely it shows nano seconds). Do you know how to dig in to this matter?

1 Like
14

Does the second gateway show it has a valid gps time reference in the log?

15

Yes, the log showed " Valid gps time reference (age: 0 sec)". It did show the time field in nano seconds, However, it was hardly 2 to 3 times out of 20 uplinks packets received. The older conduit (first one), always presented time field in nano seconds. That was quite strange to me, as in both cases i followed the same steps mentioned in your tutorial

Thanks for your support, Respect from Deutschland !

1 Like