[Usman Asghar]

Hi,

did you solve the problem? If yes, Could you share your solution

Best Regards

[Usman Asghar]

Yes, thats exactly my point. I think, “tmst” can be taken as some sort of reference as explained below:-

Conduit #1

x = time_2nd packet – time_ist packet

y = tmst_2nd packet – tmst_1st packet

Following should always hold,
y <= x

Best Regards

[Usman Asghar]

Hi,
thanks a lot for your response. I know the current hardware is not ideal for TDoA implementation, but i wish the multitech would have replied to my query emails which i sent them before placing my order.
Moving on, i am actually confused about how the packet forwarder is providing the received time. As mentioned above, i placed two conduits side by side in one room and sent uplinks from my microchip loRa mote. The data for few of the received packets is as below:-

Conduit #1
“tmst”:3853403091,”time”:”2018-03-09T18:44:54.331625Z” ist packet
“tmst”:3855731740,”time”:”2018-03-09T18:44:56.660275Z” 2nd packet

Conduit #2
“tmst”:4090346955,”time”:”2018-03-09T18:44:54.331626Z” 1st packet
“tmst”:4092675604,”time”:”2018-03-09T18:44:56.660277Z” 2nd packet

Clearly there is difference in the times of arrival at gateways (1usec for 1st packet and 2 usec for the second packet) and it is not helpful at all for TDoA.
Since the “tmst” is based on a counter which is synchronized via gps 1 PPS output signal, i checked the difference of tmst for both conduits.

conduit # 1
tmst_1 = 3855731740 – 3853403091 = 2,328649

conduit # 2
tmst_2 = 4092675604- 4090346955 = 2,328649

This means that if i take tmst values then the 2nd packet is received at exactly the same time, which makes sense because both are at the same spot. This is just an hypothesis and i want you to kindly comment on its validity.

[Usman Asghar]

I have two gateways placed at the same place in one room, both have valid gps time reference, and the gps antennas are palced outside. I am sending uplinks from a distance of approximately 40meters. I was expecting that both gateways would receive the packet at would give time field that would be identical because both are placed at the same time and the clocks are synchroized via gps.
However, to my surprise the time difference (“time”:) was always greater than 1micro second. Some time even 6 micro seconds.
Due to this reason i asked whether we could also use “tmst” field for time difference. It might be possible that the error is being added while the conversion is done.

/* convert packet timestamp to UTC absolute time */
j = lgw_cnt2utc(local_ref, p->count_us, &pkt_utc_time);
By using “tmst” field, could we add some corrective measures.

is it possible to use “tmst field” to compute the time difference of arrival ?

Thanks a lot and Best regards,

[Usman Asghar]

Hi Jason,

According to the lora gateway documentation (https://github.com/Lora-net/lora_gateway/tree/master/libloragw), the gateways with GPS receiver have time synchronization i.e, the concentrator’s internal counter is synchronized. Is it the 1PPS output signal from the gps which is used for synchronization? Could you kindly guide me about this?

This counter is used to provide raw time stamps, which appear as “tmst”:4094793619 field in the metadata. If i understood correctly from the lora packet forwarder (https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c) line 1612, the raw time stamp is used to give wall clock time (“time”:”2018-03-09T18:44:58.778293Z) to received packets.
If the above is true then, would the following hold ?
Two packets at different intervals are received by a gateway. let tmst_1 be the raw the time stamp of the old packet and tmst_2 for the new packet. similarly time_1 is the wall clock time for the old packet and time_2 for the new packet. then the difference between the raw time stamps should be equal to difference between the wall clock time ?

tmst_2 – tmst_1 = time_2 – time_1

Best Regards,

[Usman Asghar]

The results from the following code;
$ cd /var/run/lora/1/
$ ls -lah
$ /etc/init.d/lora-network-server stop
$ ./lora_pkt_fwd

Show that GPS signal is disabled for the concentrater’s counter. Does it mean that the concentrator is using its own reference signal for timestamping of the received packets ?

Thanks a lot.

[Usman Asghar]

Hi,

I have noticed something is making trouble. I made ssh connection with the conduit a entered the following commands:-

$ cd /var/run/lora/1/
$ ls -lah
$ /etc/init.d/lora-network-server stop
$ ./lora_pkt_fwd

i got an output which is as below:-

INFO: Disabling GPS mode for concentrator’s counter…
INFO: host/sx1301 time offset=(1518963007s:43415µs) – drift=-622µs
INFO: Enabling GPS mode for concentrator’s counter.

JSON up: {“stat”:{“time”:”2018-02-18 14:11:09 GMT”,”lati”:53.11080,”long”:8.85567,”alti”:1,”rxnb”:0,”rxok”:0,”rxfw”:0,”ackr”:100.0,”dwnb”:0,”txnb”:0}}
INFO: [up] PUSH_ACK received in 34 ms
INFO: [down] PULL_ACK received in 35 ms
INFO: [down] PULL_ACK received in 36 ms
INFO: [down] PULL_ACK received in 35 ms

##### 2018-02-18 14:11:39 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (153 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# Valid time reference (age: 2 sec)
# GPS coordinates: latitude 53.11080, longitude 8.85566, altitude 2 m
##### END #####

JSON up: {“stat”:{“time”:”2018-02-18 14:11:39 GMT”,”lati”:53.11080,”long”:8.85566,”alti”:2,”rxnb”:0,”rxok”:0,”rxfw”:0,”ackr”:100.0,”dwnb”:0,”txnb”:0}}
INFO: [up] PUSH_ACK received in 34 ms
INFO: [down] PULL_ACK received in 35 ms
INFO: [down] PULL_ACK received in 35 ms
INFO: [down] PULL_ACK received in 36 ms
lgw_receive:1125: FIFO content: 1 10 0 5 e
lgw_receive:1144: [3 17]
Note: LoRa packet

INFO: Received pkt from mote: 260114F6 (fcnt=87)

JSON up: {“rxpk”:[{“tmst”:117539035,”time”:”2018-02-18T14:09:52.081978Z”,”chan”:3,”rfch”:0,”freq”:867.100000,”stat”:1,”modu”:”LORA”,”datr”:”SF7BW125″,”codr”:”4/5″,”lsnr”:10.2,”rssi”:-79,”size”:14,”data”:”QPYUASYAVwBCLzqKL80=”}]}
INFO: [up] PUSH_ACK received in 34 ms

##### 2018-02-18 14:12:09 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (14 bytes)
# PUSH_DATA datagrams sent: 2 (384 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# Valid time reference (age: 1 sec)
# GPS coordinates: latitude 53.11080, longitude 8.85564, altitude 2 m
##### END #####

Here you can see for the received uplink, it gives time field in microsecond.

To my surprise, the time field in TTN console was also not empty
{
“gtw_id”: “eui-00800000a0001fd9”,
“timestamp”: 117539035,
“time”: “2018-02-18T14:09:52.081978Z”,
“channel”: 3,
“rssi”: -79,
“snr”: 10.2,
“latitude”: 53.1108,
“longitude”: 8.85566,
“altitude”: 2
},

However once i stopped the ssh, the conduit got disconnected from TTN.

[Usman Asghar]

Hi,

I could not implement your instructions posted at (12:41pm) as i was home at that time (I am in Germany 🙂 ). So, i would update you about this tomorrow.

May be i have written about it earlier, but to clear up the things i want to explain my situation.

I wanted to implement TDoA on LoRa networks to estimate or calculate the position of the end device/node. Since, time synchronization among minimum of 3 gateways was a fundamental requirement, i ordered 4 x GNSS based conduits (247A-868- MTCDT-247A-868-EU-GB). Assuming GNSS modules would enable synchronized clocks which subsequently would provide better location accuracy. My idea was to use “time field” in metadata of application payload to calculate TDoAs between four conduits and apply the algorithm.

I wanted to use the things network (TTN), so on the first multitech conduit i installed the TTN packet forwarder (https://www.thethingsnetwork.org/docs/gateways/multitech/aep.html) but i could not get any success (the TTN packter forwarder’s developer told that if the conduit has a valid gps lock, then the time field must give accuracy in nano seconds. But i got the time field only in seconds). Since, i had no idea about the TTN packet forwarder and could not debug the problem,therefore i dropped this idea.

On the second conduit (the current one), i used the default packet forwarder and connected it to TTN. The default packet forwarder is written to provide time field in microseconds and also writes time stamps. I succeeded in connecting the conduits to TTN but the time field and GPS location parsing from the conduit is still missing.

GNSS module alone is working and providing me very accurate location, the results are posted in my previous post. But its coordinate are neither parsed to TTN console nor the time field contains anything.

I will try your suggestion in the morning and will update you with results.

Thanks a lot,
Have a very nice weekend

[Usman Asghar]

Hi,

Since i am home now, i will update you tomorrow. However, i think i have SPI version of MTAC-LoRa card.
I have checked the specification of “247A-868- MTCDT-247A-868-EU-GB” it says SPI version of LoRa card. (https://www.multitech.com/models/94557550LF)

How should i proceed for SPI version of LoRa card?

Thanks a lot

[Usman Asghar]

What should i add in the configuration file (under LoRa mode –> Packet Forwarder) that these coordinates are parsed in to the TTN.
The next question is about the “time” field which remains empty in the metadata at TTN application console. (as per my limited knowledge if the GPS is present it should give the time according to the format HH:MM:SS.XXXXXX)

Best Regards

Usman Asghar

[Usman Asghar]

No, this multitech conduit is running default semtech packet forwarder (Factory setting without TTN packet forwarder ).
I disabled the packet forwarder and entered the following command
“cat /dev/ttyXRUSB2”

I got the following results:-

$GNRMC,181818.00,A,5306.64921,N,00851.33806,E,0.065,,160218,,,D*67
$GNVTG,,T,,M,0.065,N,0.121,K,D*39
$GNGGA,181818.00,5306.64921,N,00851.33806,E,2,12,1.14,1.5,M,45.6,M,,0000*46
$GNGSA,A,3,25,29,12,32,14,31,,,,,,,2.14,1.14,1.81*1E
$GNGSA,A,3,65,74,83,82,80,73,,,,,,,2.14,1.14,1.81*1A
$GPGSV,4,1,16,02,38,074,,04,,,39,06,19,038,18,12,45,090,20*4A
$GPGSV,4,2,16,14,30,269,40,24,10,152,,25,87,027,43,26,02,279,*76
$GPGSV,4,3,16,29,57,209,50,31,40,302,40,32,21,242,42,33,25,209,36*74
$GPGSV,4,4,16,36,26,152,47,40,16,127,,41,01,103,,49,29,185,38*7A
$GLGSV,3,1,10,65,15,344,21,72,12,299,,73,79,328,32,74,24,311,24*67
$GLGSV,3,2,10,80,41,126,24,81,04,030,,82,51,046,13,83,63,169,41*6E
$GLGSV,3,3,10,84,11,199,26,,,,39*57
$GNGLL,5306.64921,N,00851.33806,E,181818.00,A,D*71

The location coordinates from GNGLL (5306.64921,N,00851.33806,E,) gave me the precise location on the google maps. This concludes that GPS/GNSS module is up and running fine.

[Usman Asghar]

Hi,

I have connected my conduit to the things network without installing TTN packet forwarder. To achieve connection to the TTN network server with default LoRa Semtech Packet forwarder, i have made the following changes in the global_conf.json :
“gateway_conf”: {
“forward_crc_disabled”: false,
“forward_crc_error”: true,
“forward_crc_valid”: true,
“gateway_ID”: “<WILL-BE-AUTO-REPLACED-WITH-LORA-EUI>”,
“keepalive_interval”: 10,
“push_timeout_ms”: 100,
“serv_port_down”: 1700,
“serv_port_up”: 1700,
“server_address”: “52.169.76.203”,
“gps_tty_path”: “/dev/ttyXRUSB2”,
“stat_interval”: 30,
“autoquit_threshold”: 60
}

Now the conduit is up and receive the payload from my end device. The meta data from the conduit is as below:-
{
“gtw_id”: “eui-00800000a0001fd9”,
“timestamp”: 2100437715,
“time”: “”,
“channel”: 0,
“rssi”: -79,
“snr”: 9.5,
“rf_chain”: 1
},

As you can see the “time” field is empty, which should be giving the time (wall clock) in microseconds. Also the GPS coordinates are also not parsed in to the metadata. What does this mean ? My built in GNSS module is not working. The antenna connection is good and i have placed the antenna outside under clear sky.
If someone could kindly help me in this regard.

[Usman Asghar]

Thanks for your support.
If i am getting right i need to reinstall/ change my packet forwarder with the one you provided above.
The installed (https://raw.githubusercontent.com/kersing/multitech-installer/master/installer.sh) doesnot contain any information about the time stamping as you posted above.

[Usman Asghar]

Hello,
I installed packet forwarder using the following command.
wget https://github.com/kersing/multitech-installer/raw/master/installer.sh –no-check-certificate

I also get a reply from the Multitech, they are saying that the conduit with current GNSS module should give microsecond time stamping. However as i posted above it is giving me in MILLI seconds.

[Usman Asghar]

I am having the following response from the things network gateway console

{
“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
}

[Usman Asghar]

Dear Jeff,

Yes i have attached the GPS antenna to it. And set up the gateway with the Things network. The device was inside but i have placed the antenna near window where it had clear view of sky.

Thanks alot for your response

• This reply was modified 7 years, 2 months ago by Usman Asghar.

[Usman Asghar]

Dear Jason,

Thank you for your quick response. Actually, i have set up my multitech conduit with “The things network server” and it has disabled the semtech packet forwarder and installed TTN packet forwarder.
I received these gateways today, so i totally dont know much about them. I just follow the instructions on
However, could you kindly guide me how to add the above line codes?

• This reply was modified 7 years, 2 months ago by Usman Asghar.
• This reply was modified 7 years, 2 months ago by Usman Asghar.

[Usman Asghar]

Thank a lot for your response. But the first problem is that the GNSS module is not showing any location information, which possibly means that it has not fixed to any of the satellites.
Do you have any information if the user has to do some setting in order to run the GNSS module.

Multitech has written the manuals that GNSS modules support time stamping, but my first step is to run the gateway with GNSS module being fixed. However, till now i have no success what so ever.

Thanks a lot once again.

[Usman Asghar]

Hi,

Do you get any success in triangulation with multitech conduits?

Thanks

[Usman Asghar]

Hi,

did you proceed with multitech conduit for geo-location ? Did you get any success?
Currently i am interested in geolocation capability with LoRa so your results might give better insight.

Thanks a lot.
have a nice day

[Usman Asghar]

I bought MTCDT-247A-868-EU-GB, which has a built in GNSS module. I have setup the gateway with
And its running fine except for the time stamps which are dependent on the GNSS module.

When i access GPS module from the multitech conduit, it say no location information.

How could i proceed to get the position and get a fix for the GPS module.

[Usman Asghar]

Hi,

Did you manage to get the position from GNSS module.

[Author]

Posts