GNSS module fix

[Usman Asghar]

Hello everyone,
I got MTCDT-247A-868-EU-GB which is a LoRa conduit having GNSS module for geo-location capability. However, i am unable to get the location information about the Gateway location as well the time stamps in nano seconds (both of which should be possible due to built in GNSS module).
I have created a case at multitech support portal about this but they have not replied yet. Does any one encountered similar problem. If yes what is the solution for this?

Thanks a lot

Have a nice day

[Jason Reiss]

The timestamp applied by the packet forwarder will not have sub-microsecond accuracy. It is the time that the packet is read from the FIFO buffer.

The Semtech packet forwarder should attach timestamps to the micro-second.
https://github.com/Lora-net/packet_forwarder

The TTN packet forwarder developers would need to be contacted to get greater precision into their packets.

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

[Jeff Hatch]

Usman,

Do you have the GPS antenna attached? Is the device inside a building? Where is it located? GPS/GNSS signals can vary greatly depending on exactly where the device is located.

Jeff

[Jason Reiss]

For Semtech packet forwarder configuration add this setting to global_conf.json “server_conf” section to enable gps parsing and timestamping.

“gps_tty_path”: “/dev/ttyXRUSB2”,

[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 6 years, 10 months ago by Usman Asghar.
• This reply was modified 6 years, 10 months ago by Usman Asghar.

[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 6 years, 10 months ago by Usman Asghar.

[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
}

[Jason Reiss]

Do you know which packet forwarder is installed?

This one recommends using the Semtech or Kersing version, apparently development has stopped.
https://github.com/TheThingsNetwork/packet_forwarder

Here is Kersing, configuration is similar to Semtech instructions.
https://github.com/kersing/packet_forwarder/blob/master/mp_pkt_fwd/global_conf.json

• This reply was modified 6 years, 10 months ago by Jason Reiss.

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

[Jason Reiss]

https://github.com/kersing/packet_forwarder/blob/cb0f92f1c9a8bd85bf68da0328c2180c9d67dc71/mp_pkt_fwd/src/gwtraf_transport.c

If gps is available then line 347 adds the timestamp
should add timestamp with microseconds (nanos/1000)

[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]

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.

[Jason Reiss]

Without the packet forwarder running can you get data out of the /dev/ttyXRUSB2

Try to read the GPS device
> cat /dev/ttyXRUSB2

Depending on the TTN packet forwarder installed you will have to reach out the maintainer of the code to get support for issues.

Perhaps you are using this version?
https://github.com/kersing/packet_forwarder

[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]

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

[Jason Reiss]

Do you have a USB or SPI MTAC-LORA card?

For USB the gps_pkt_fwd-usb must be used.

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

A work around could be to modify the /etc/init.d/lora-network-server script.
Change basic_pkt_fwd-usb to gps_pkt_fwd-usb near line 56

ln -sf /opt/lora/basic_pkt_fwd-usb $pkt_fwd
to
ln -sf /opt/lora/gps_pkt_fwd-usb $pkt_fwd

[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

[Jason Reiss]

looks like you have it configured correctly and get gps data

what sort of logging happens when you run manually, as described in the above 12:41 pm post.

$ ./lora_pkt_fwd

you can also forward the packets locally to “127.0.0.1” and listen with netcat

$ nc -u -l -p 1700

See what info is in packets going to TTN. After that it is up to TTN to handle the time info once it is forwarded.

[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

[Jason Reiss]

https://github.com/Lora-net/packet_forwarder

If you are still having issues getting time from all gatways through ttn you may want to setup a UDP server to recieve directly from packet fowarders.

[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]

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.

[Jason Reiss]

Looks like that state is temporary.

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.

[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]

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,

[Jason Reiss]

I do not believe it is possible to use the tmst values or timestamps attached to the packets for sub-microsecond TDoA calculations as mentioned in my first response to this thread.

GNSS module fix

There will be a difference in the SNR for each receiver and the demodulators may register a packet done event based on slightly different input levels. The tmst value is the end of the packet demodulation not precisely the start of packet arrival or the end of packet transmission.

tmst | number | Internal timestamp of “RX finished” event (32b unsigned)

A new gateway hardware that provides accurate fine-timestamps is being developed to provide geo-location based on TDoA calculations.

The tmst values are independent internal counters. They maybe sync’d to the PPS to allow transmit on a GPS timestamp to be started on the signal edge.
https://github.com/Lora-net/packet_forwarder

Line 1625 shows the tmst value used to create an accurate timestamp based on the GPS input and sync’d clock.
https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c

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

[Jason Reiss]

Yes, the tmst values should accurately reflect elapsed time as shown in your calculations. I would expect these readings to have some jitter between conduits.

Comparing the “time” values give these differences.

2.328651
2.328650

[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

[Author]

Posts